从今天2007年9月5日开始，正式启用 http://guwendong.cn/。http://my.donews.com/clickstone/将停止更新。
请直接浏览 http://my.donews.com/clickstone/ 的朋友，使用新地址 http://guwendong.cn/。
请直接订阅 http://my.donews.com/clickstone/ 的 RSS/Atom 的朋友，将订阅地址改为：http://feed.feedsky.com/beyondsearch。
http://my.donews.com/clickstone/ 上有价值的文章我已经都转移过去了，唯一对不住的是朋友们的回复没办法转过去了，Donews 不给提供搬家功能啊！有了自己的域名和空间，完全自己做主了，以后应该就不会再丢数据了，呵呵！
非常感谢朋友们一直以来对 Beyond Search 的支持，通过他我结识了很多非常棒的朋友！也希望朋友们能够继续支持新的 http://guwendong.cn/。目前 http://guwendong.cn/ 还有一些小问题，我会抽时间尽快完善。
无论如何，还是得感谢 Donews，在 Donews 上我曾经渡过了非常愉快的一段儿时光！
另外，Thoth 的代码已经放到 sf.net上面了，目前还有一些小问题，因此尚未提供下载包，有兴趣的朋友可以直接通过 CVS 查看，http://beyondthoth.cvs.sourceforge.net/beyondthoth/。欢迎交流！
Taste 有着非常清晰的程序架构。看图说话，下面就是一个 User-based Recommender 的例图，说明了各个组件之间的关系。而对于一个 Item-based Recommender，除了不需要使用 PreferenceInferrer 和 Neighborhood 之外，和下图描述的基本架构是非常类似的。
作为一个协同过滤推荐引擎，Taste 包含下列基本要素。
- 用户：即上图中的 User，Taste 组件依据用户的偏好信息向用户进行推荐。
- 推荐项：即上图中的 Item，每个用户都会对多个 Item 进行偏好设定，比如打分。
- 偏好：即上图中的 Preference，每一条偏好数据记录的都是某个用户对某个 Item 的偏好程度。
从上面可以看出，偏好信息是推荐系统的基础，它总是以某种形式进行存储，即图中的 DataModel 和 Data Store。另外，原始的偏好信息可能并不能表示用户确切的偏好。举个例子，对于 5 分制的评分系统来说，有些人可能无论自己多么不喜欢，给的最低的评分都可能是 2 分，并不是 1 分；另外一些人则可能正相反，最喜欢的也就给 4 分。还有一种情况，对于一个 Item，给它评分的用户越少，通常那些用户越“相似”（我们可以理解为嗜好相同）；如果评价的用户特别多，这些用户之间的相似度反而不好判断，对这类偏 好信息通常可以直接忽略。为了解决诸如此类的问题，我们需要对那些原始的偏好数据进行处理，使数据标准化、差异扩大化，以求能够较真实地反应用户的偏好信 息，这正是图中 PreferenceTransform 要做的工作。
经过以上处理，我们就得到了一个 DataModel，一个已经标准化了的用户偏好信息。
对于 User-Based Recommender 来说，下一步，我们就是要找出与目标用户相似的“邻居”（Neighborhood）了。
首先要做的是得到描述目标用户和其它用户之间关系的集合（Correlation），然后从中选择最相似的用户。生成Correlation时，会指定一 个推断规则（PreferenceInferrer），用来描述用户对那些自己没有明确表明过偏好的 Item 的偏好值。在计算用户相似度方面，Taste 提供了皮尔森相关系数（Person Correlation Coefficient）、余弦相似性（Cosine-based Similarity）相似度算法。有了最近邻的用户集合，就可以对目标用户的兴趣进行预测，生成推荐结果。
上面我们结合图描述了一个典型的 User-Based Recommender 的实现过程。总结并提取其中的重要对象，如下。
1、Recommender
Recommender 是 Taste 中的核心对象。给定一个 DataModel，Recommender 就可以生成生成对应的推荐结果。通常情况下，你只需要简单的选择使用 GenericUserBasedRecommender 或者是 GenericItemBasedRecommender 这两个 Recommender 接口的具体实现即可。另外，还可以通过 CachingRecommender 包装使用他们，以提升效率。
2、DataModel
DataModel 是包装用户偏好信息的接口。它的具体实现可以从任何数据源获取这些信息，当然，数据库通常是最常见的选择之一。尽管很多应用程序想编写一个他们自己的 DataModel，但其实 Taste 已经提供了一个 MysSqlJDBCDataModel，可以经由 JDBC 从数据库中获取偏好数据。另外，Taste 也提供了一个基于文件的 FileDataModel。
连同 DataModel 一起，Taste 使用 User、Item 和 Preference 这些概念来描述用户、推荐项和针对推荐项的偏好。自定义的 DataModel 应该实现这些接口以和应用程序匹配－－比如一个 OnlineUser 代表网上商店的用户，一个 BookItem 代表一本书。
3、PreferenceTransform
PreferenceTransform 以某种方式改变偏好的值，通常是将其标准化，或者将其差异扩大化。PreferenceTransform 大多数情况下与 DataModel 一起使用。
4、UserCorrelation, ItemCorrelation
UserCorrelation 定义两个用户之间相似的程度。这是推荐系统中至关重要的一个部份，与 Neighborhood 的实现相关。
ItemCorrelation 也是类似的，只不过它用来描述两个 Item 之间的相似度。
5、Neighborhood
在一个 User-Based 推荐系统中，推荐的意思就是去寻找与给定用户相似的“邻居”。UserNeighborhood 描述了如何去选择那些“邻居”――比如，最相似的10个用户。具体实现时通常需要对 UserCorrelation 进行操作。
Taste/Thoth 系列
1）开源的推荐系统引擎
2）Taste Architecture 概览
3）暂时还没想好，可能会写个例子，或者是把核心组件详细分析一下。看情况定吧~~~
Beyond.Thoth on sf.net，http://sourceforge.net/projects/beyondthoth/
Beyond Thoth Group on google，http://groups.google.com/group/BeyondThoth/
最近比较忙！极具挑战性的任务，且和个人兴趣的完美结合，让我每天都充满斗志，享受工作！甚至连看 blog 的时间都压缩到很低了，呵呵。
六间房购买
Taste 是非常棒的一个推荐系统核心引擎，sf 上可以下载到 Taste 的最新版本。Taste 同时也是 2007 Google Summer of Code 里的一个项目。 当初学习推荐系统开发的时候，遍搜网络，这个是我个人找到的最全面最完整的一个开源包。细读代码之后，虽然没有 Lucene 曾经带给我的那种震撼，但也绝对可以称得上是开源世界里的上佳之作！经常有朋友发 Email 希望我介绍一些推荐系统相关的资料，这个是我必然推荐给大家的一个。
下面翻译自 Taste 文档的 Overview 部分。
Taste 是使用 Java 语言开发的一套灵活、快速的协同过滤引擎。他根据用户(Users)对某些项(Items)的偏好(Preferences)，来推断用户对其他一些项的 偏好程度。举个例子，一个出售书籍或CD的在线零售商（比如amazon/dangdang/joyo），使用 Taste 引擎，可以方便地依据已有的购物篮数据，为用户推荐他可能感兴趣的书籍或CD。
Taste 提供了丰富的组件集，基于其中的算法，你可以定制出自己的推荐系统。Taste 从设计上就力求能够满足于企业级的要求，效率、可扩展性与灵活性是它的设计目标。它为基于 J2EE 的应用提供了一个标准的 EJB 接口。但 Taste 并不是仅限于 Java 平台。它能够以独立 Server 的形式运行，通过 Web Services 和 HTTP 方式向其它（语言开发的）应用程序提供推荐逻辑。
Taste 的顶级包里抽象出了下面这些核心接口。
在 comp.planetj.taste.impl 命名空间下，有这些接口的实现代码。从这些核心接口开始，你就可以搭建你自己的推荐引擎了。简而言之，这就是 Taste！倾向于学术的，Taste 可以支持 Memory-based（即我之前 blog 里提到的 User-based） 和 Item-based 两种推荐形式，提供了包括 Slope One 在内的一些算法的实验性实现。Taste 目前尚不支持 Model-based 推荐。
2007年6月30日，Taste 发布了其最新的一个版本 1.5.5。在这个版本里面，甚至还包含了针对 Netflix 数据的一个实验包。不得不说，Netflix Prize [1] [2]， 真的是一个双赢的活动！本来，推荐领域已经冷清了有些日子，其中一个很大的原因就是大家做实验的基础只有 GroupLens/EachMovie 这两个数据源，搞来搞去想突破也不容易了。Netflix 公开他的数据，使做 Research 的学者们拿到了宝贵的 big data，终于可以跳出 GroupLens/EachMovie 的框框了。随着基于 Netflix 数据所取得的最新研究成果不 断出现，无疑会不断促进着推荐技术下一个热潮的到来。与此同时，学者们的积极参与，也使得 Netflix 越来越接近于其追求的推荐准确率，并且，通过媒体的广泛报道，Netflix 也赢得了高知名度和好的口碑。说实在的，用 1M$ 买到如此多最新的技术成果，同时又获得了不小的商业收益，这个买卖真是值了！
去年，我试着给 Taste 的作者发过几次 Email，希望能加入到 Taste 的开发 Team 里，可一直没有收到任何答复。今年年初，在 Google Summer of Code 上又申请了一次，仍然没有回应。始终入不了高人的法眼，说明自己差距还很大啊。要说开源的推荐引擎，Java 下最多，PHP 有个 Vogoo，Python 下零零散散的也能找到一些，唯独 .Net 下基本没有。基于上两方面的原因，我和一个好朋友商量，准备把 Taste 移植到 .Net 平台下。一来通过移植代码，加深自己的理解；二来也算是为 .Net 社区做点儿贡献，哈哈。
我们的项目暂时命名为 Beyond.Thoth，之所以没有叫 Taste.Net，主要是因为我们打算逐步加入自己的一些实现。改名这事儿对 Taste 可能有些不敬，但我们会在代码里面，明显标出对 Taste 的引用。目前核心代码已经移植完毕，正在进行算法的准确性验证和性能调优。资源在这里，目前还是空的，有发布后我会第一时间在 blog 里通知各位朋友。
预报：Taste Architecture 详解。
Apriori Algorithm 是关联规则领域里最具影响力的基础算法。它是由 Rakesh Agrawal 在 1994 年提出的，详细的介绍在这里《Fast Algorithms for Mining Association Rules》。十几年过去了，不少学者围绕着 Apriori 进行了诸多改良。但与 1994 年相比，目前基于互联网的应用，数据量大了几十倍甚至是几百倍，因此，基于 Apriori 的算法逐渐暴露出其运算成本过高的问题。但不管怎样，对于大师及其做出的贡献，我们也只有高山仰止的份儿。
Apriori 是一种广度优先算法，通过多次扫描数据库来获取支持度大于最小支持度的频繁项集。它的理论基础是频繁项集的两个单调性原则：频繁项集的任一子集一定是频繁 的；非频繁项集的任一超集一定是非频繁的。晦涩的理论我这里就不多写了，有兴趣的可以去看论文。我把里面的例子给翻译一下，图文并茂，简明易懂。
某数据库 DB 里有 4 条事务记录，取最小支持度（min support）为 0.5，则计算频繁项集的过程如下：
| TID |
Items |
| 100 |
A, C, D |
| 200 |
B, C, E |
| 300 |
A, B, C, E |
| 400 |
B, E |
|
扫描DB |
| Itemset |
Support |
| {A} |
2 (0.5) |
| {B} |
3 (0.75) |
| {C} |
3 (0.75) |
| {D} |
1 (0.25) |
| {E} |
3 (0.75) |
|
取满足
最小支持度
项集 |
| Itemset |
Support |
| {A} |
2 |
| {B} |
3 |
| {C} |
3 |
| {E} |
3 |
|
| Itemset |
| {A, B} |
| {A, C} |
| {A, E} |
| {B, C} |
| {B, E} |
| {C, E} |
|
扫描DB |
| Itemset |
Support |
| {A, B} |
1 (0.25) |
| {A, C} |
2 (0.5) |
| {A, E} |
1 (0.25) |
| {B, C} |
2 (0.5) |
| {B, E} |
3 (0.75) |
| {C, E} |
2 (0.5) |
|
取满足
最小支持度
项集 |
| Itemset |
Support |
| {A, C} |
2 |
| {B, C} |
2 |
| {B, E} |
3 |
| {C, E} |
2 |
|
| Itemset |
| {A, B, C} |
| {A, B, E} |
| {A, C, E} |
| {B, C, E} |
|
扫描DB |
| Itemset |
Support |
| {A, B, C} |
1 (0.25) |
| {A, B, E} |
1 (0.25) |
| {A, C, E} |
1 (0.35) |
| {B, C, E} |
2 (0.5) |
|
取满足
最小支持度
项集 |
| Itemset |
Support |
| {B, C, E} |
2 (0.5) |
|
如上可以看出，在海量数据的情况下，Apriori 算法的运算过程有 2 个问题：
- 需要多次扫描数据库，时间成本很高；
- 运算过程中需要产生大量的候选集，空间成本也非常高。
针对 Apriori 算法所做的改进也基本上是围绕着解决这两个问题进行的，如在扫描DB前首先进行以便事务合并和压缩，数据分区或抽样等。
Weka 里有 Apriori 算法的 Java 实现，非常值得一看。
貌似 wikipedia 已经解封了，呵呵！
预报：关联规则(3)，关于 FP-Growth 算法。
上次去 Feedsky，开始说正事儿前，闲聊聊到了 Twitter，说它像个聊天室。没过两天，就看到了吕欣欣的这篇 blog，《不应该只是一个聊天室》。国人向来爱凑热闹，生活里如此，网络里亦是如此，“抢沙发”就是最典型的表现之一。网络是国内网民们宣泄情绪实现和谐的最主要途径，这是聊天室/BBS火爆的根基，也是众国外先烈们最看不懂国内互联网的地方。因此，Twitter 这样的应用——想聊就聊——到了国内不被变成聊天室那才奇怪呢。
keso 说 Twitter 的成功归功于（或部分归功于）它“固执的简单”。我倒是隐约觉得，它固执的不是简单，简单不可能带来成功。貌似简单的 Twitter，其实是在坚持用最简单的信息发布方式和最熟悉的操作习惯，为用户提供无限的可能。看看下面这些 Twitter 的用法，《The Top 5 Ways Smart People Use Twitter》，《5 Ways to Use Twitter for Good》。简单与熟悉带来了自由的可能！一旦用户选择了 Twitter，那么怎么使用它，用户就完全可以自己说了算了，用户可以随心所欲，直到找到让自己最爽的 Twitter 方式。Twitter 与 MySpace 有着异曲同工之妙。MySpace 一个重要的成功因素就是，“给用户更多自由设计他们的 MySpace 主页，让用户能高度地表达自我和与朋友交流”。Freedom！这同样也是 Twiter 杀手们最难于下手的原因，你已经不是在与 Evan Williams 的 Twitter 竞争了，你是在与用户自己的 Twitter 竞争！
叽歪de 是国内新近冒出来的一个类 Twitter 网站。前阵子阅读 blog 的时候，看人提到过这个网站，当时连进去看了一下，第一感觉非常的不好：满屏幕的灌水帖 + 过于娱乐化的 Logo。当然，Twitter 同样是满屏幕的灌水帖，不过由于它是英文的，猛一看看不懂，所以反感没那么强烈，哈哈。Twitter 有的功能，叽歪de 都有，
- 多样的信息发布途径：IM（QQ/MSN/GTalk/skype），手机，Web；
- 同样多样的消息接收途径：IM（QQ/MSN/GTalk/skype），手机，Web。
而且对于 叽歪de 来说，它还具备一个在国内打败 Twitter 的坚实基础：QQ。Twitter 估计一时半会儿还不可能支持 QQ，而 QQ 的用户恰恰貌似是最有可能成为 叽歪de 黏着用户的群体。
对于我个人来讲，作为聊天室的叽歪de，就是垃圾。信息过载、垃圾邮件、骚扰短信、漫天飞舞的广告，已经让我这个每日里需要依托于互联网工作的人不堪忍受 了。我干吗要而且也没有精力，去关心别人是否“去看水浒传”，抑或“美国的国庆日是7月4日”。如果需要打发无聊时光，我一定会选一种“珍爱生命，远离网 络”的方式。叽歪de 所宣扬的六点，都不能成为我使用它的理由。
Twitter/叽歪de出现之前，我一直在这样使用 Gmail——wendell.gu+toread@gmail.com，目的是把想读还没来得及仔细读的文章记录下来。现在，我可以把它转移到叽歪de上面了！
聊天室，抑或是其他？问题的关键在于选择！
Mtime 的一句话影评，倒是叽歪de类应用的一个不错的载体！还记得刚看完《加勒比海盗3》从电影院出来的时候，真想叽歪一下：tmd海盗3把发哥整得太猥琐了！
猜猜 Feedsky 给我的定价是多少？人民币 30 大元，正好我两天的停车费，哈哈！
本来就是想写写话题广告的事情，写着写着就跑题了，所以干脆把名字给改了——从话题广告说开去。老掉牙的标题形式了，哈哈。
写 这篇 blog，是缘于 6.23 参加了 Feedsky 的聚会。在 Feedsky 的办公室里，吃也吃了，喝也喝了，聊也聊了，玩也玩了，所以怎么着也得写点儿啥，对人对己都是个交待。说实话，我不能算是 Feedsky 的高级用户，我最看重的就是 Feedsky 能给我一个永久不变的 Feed 地址，这样，即使不管我的 blog 搬家到那里，我的读者都不会受到影响。我去参加这个聚会是有私心的，我特想撺捣 Feedsky 把 Feed 推荐或者 blog 推荐给做起来。
现 在大家都在讲信息过载的事情，可在我看来，这是相对的。一方面，互联网上每天都在产生着海量的信息；但另一方面，你所能接触到的你真正关心的信息可能又是 相当匮乏的。拿我来说，Google Reader 里订了不少的 Feed，但其中的某些是由于一两篇不错的文章，而一时冲动订阅了整个 Feed。一些 Feed 我现在甚至都想不明白当初为什么要订阅它了。大量的 Feed 产生了大量的未阅读文章，看着那些类似于 100+ 的数字，我常常会无可奈何地“mark all as read”。但是，就我所关心的领域，个性化推荐/Web Mining，我每天google it、百度一下，甚至连 Alert 都用上了，可还是仅能找到寥寥无几的一些新鲜内容。真是苦闷啊~~~
Feedsky 应该能在这个方面给用户提供帮助。它掌握着大量的 Feed 信息，Feed 有个先天的优点就是，它里面的内容都是最纯正的正文！基于 Feed 做文本分析，省去了数据清理、正文提取两个烦人的环节，可以直奔主题！太爽了啊！个人认为，相比于话题广告，这绝对是一件对 blog 产业真正有益的事情！豆瓣9点也在试图解决这个问题，但现在我看来感觉问题可能有两个：1、用户提交的 Feed 数量太少；2、需要引入文本分析技术了。豆瓣最让我佩服的，就是在即使很粗放的产品设计里，也总能够抓住最有效的特征，而且往往还是非常创新的。我始终认 为9点里面“必看”、“有时看”的模式，是找到了一条做 blog 推荐的捷径，不过豆瓣目前似乎还没有非常有效的把这些数据利用起来。总之一句话，豆瓣太有才了！o(∩_∩)o…哈哈
前面是题外话，正式开始说话题广告。我晕~~~，题外话比主题还长！
在 我看来，blog 是其作者的写照，或者是某一方面的写照。比如通过我的 blog，读者大致可以知道，我是个崇尚技术的人，我对推荐系统很有兴趣。经由写作、阅读、评论，在作者和读者之间产生了交互，这样过一段时间，彼此间就 建立起了一种关系。在这种关系中，blog 作者为主、读者为辅，而维护这种关系稳定性的一个重要因素，就是 blog 的“信用”——这种“信用”决定着读者的去留。作者用心去写好文章，可以不断加强 blog 的信用，黏住读者。
话题广告的出现，很大可 能会降低你的信用，搞不好绝对得不偿失。首先它会影响你 blog 的品质，写的少没什么钱拿，写多了 blog 自然就成了垃圾；其次它还考验你的人格，说真话吧怕影响收入（在国内目前的市场环境下，你说广告主的东西不好后果大家估计都能想到），说假话吧良心上又过 不去，被人发现就更恶心了；最后收益还不一定合适，如果恰好是你熟悉的产品，不费什么力气评论两句那还行，但如果是个你根本不了解的产品，你还得花时间研 究试用，这个时间成本也是蛮高的。
当然了，话题广告也绝不是一无是处！任何新生事物从出现到成熟，都需要经历一段儿曲折发展的历程，途中免不了会蹦出几个我这样的唱唱反调。但说句实在话，话题广告要成功，一定绕不过这两点：
- 模式要创新。Feedsky 得多动脑子，不同的产品得有不同的广告策略，纯粹是简单的 blog 软文模式，肯定走不通。
- blog 作者要自律。这点就更难了，有钱能使鬼推磨！以我为例，尽管我在这里冠冕堂皇，但如果 donews 肯给我1w￥，我就能详细给大家介绍一下 donews 优异的稳定性和优雅的用户体验。Feedsky 得建立一种信用评估机制，帮助用户甄别付费评论的可供参考性。
话题广告是把双刃剑，希望 Feedsky 可以好好用，用好它！
1、如何来到 donews？因为读 keso 的 blog，发现了 donews，喜欢上了这个 IT 写作社区。
2、我在这里干什么？通过我在 donews 上的这个 blog —— Beyond Search，我结识了很多朋友。
3、我眼里的 donews？这里是个圈子，热闹过，人声鼎沸过。如今似乎一切依然。
4、我的用户体验？一次次的数据库连接超时，一次次的发布失败。我还在这里已经是个奇迹了。
5、my.donews，这么不着待见？2个多月了，添加一个blog分类，错误依旧。
6、还能忍多久？一直不太情愿自建blog，因为确实有些留恋这里，而且写blog，my.donews曾经也够用了。
7、走，还是不走？踏实的donews才有未来！
8、donews，你还信仰互联网吗？
说到推荐系统，就不能不说关联规则。基于关联规则的推荐，是入门级的推荐技术实现，也是目前应用最广泛的一种推荐形式。
就拿刚上线的“蚂蚁”来说吧，打开《引爆流行》的页面，稍微滚动两下鼠标，你就可以看到这个了——“喜欢此宝贝的会员还喜欢”。豆瓣上也有类似的形式，还看《引爆流行》，豆瓣的是——“喜欢引爆流行的人也喜欢”。是不是很像？但别被形式迷惑了，这两个用的是完全不同的技术实现。豆瓣的之前我说过了，他是 Item-Based 方法；蚂蚁的这个应该就是关联规则方法了。当然我是猜的，不过也不是乱猜。有兴趣的可以刷刷上面那两个《引爆流行》的页面，看一下两个推荐区域的内容会有什么不同。
关联规则起源于数据挖掘领域，人们用它来发现大量数据中项集之间（有趣/有用）的关联。它本身是数据挖掘领域中一个重要的研究课题，近些年来更是由于被业界广泛应用而倍受重视。Rakesh Agrawal 是关联规则领域的大牛，他于 1993 年发表的一篇 paper，《Mining Association Rules between Sets of Items in Large Databases》，是被引用最多的一篇大作。不过让 google fans 们失望的是，他目前就职于 microsoft 的搜索实验室！^_^
关联规则的最典型例子就是购物篮分析。在一家超市里，有一个有趣的现象：尿布和啤酒赫然摆在一起出售。但是这个奇怪的举措却使尿布和啤酒的销量双双增加 了。这不是一个笑话，而是发生在美国沃尔玛连锁店超市的真实案例，并一直为商家所津津乐道。原来，美国的妇女们经常会嘱咐她们的丈夫下班以后要为孩子买尿 布。而丈夫在买完尿布之后又要顺手买回自己爱喝的啤酒，因此啤酒和尿布在一起购买的机会还是很多的。这个故事听起来是不是很酷？没错，这就是技术的力量！
但是，和任何其他经典的故事一样——这事儿听起来带劲儿，做起来很难！真正做过关联规则挖掘的人，一定都有这样的体会：想从浩瀚的记录集里，挖掘一条带劲儿的关联规则出来，简直太难了。（什么，你问有多难？请参照朱广沪~~~）
对于挖掘得到的关联规则，都会制定一些指标来衡量它们的有效程度，最经典的包括，支持度和置信度。简单来讲，
- 支持度是指，商品A、商品B在全部销售订单中所占的比例。
- 置信度是指，购买商品A并且同时购买了商品B的订单，在所有包含商品A的订单中所占的比例。
当然，这里的商品和订单是个泛化的概念，具体指代是的什么，就得具体问题具体分析了。
未完待续~~~
