基于LUCENE实现自己的推荐引擎
基于LUCENE实现自己的推荐引擎
14:13:18 |
摘要：采用基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法，推荐引擎常用的Content-Based推荐算法及协同过滤算法（Item-Based、User-based在电子商务推荐系统入门v2.0、电子商务推荐系统入门基础中已经有所阐述。但从实际应用来看，对于大部分中小型企业来说，要在电子商务系统完整采用以上算法有很大的难度。
1、常用 ...
采用基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法，推荐引擎常用的Content-Based推荐算法及协同过滤算法（Item-Based、User-based在、中已经有所阐述。但从实际应用来看，对于大部分中小型企业来说，要在电子商务系统完整采用以上算法有很大的难度。
1、常用推荐引擎算法问题
1）、相对成熟、完整、现成的开源解决方案较少
粗略分来，目前与数据挖掘及推荐引擎相关的开源项目主要有如下几类：
数据挖掘相关：主要包括、、、、 等
文本挖掘相关：主要包括、、、 等，具体可以参考
推荐引擎相关：主要包括、、 ，其他包可以参考
搜索引擎相关：Lucene、Solr、Sphinx、Hibernate Search等
2）、常用推荐引擎算法相对复杂，入门门槛较低
3）、常用推荐引擎算法性能较低，并不适合海量数据挖掘
以上这些包或算法，除了Lucene/Sor相对成熟外，大部分都还处于学术研究使用，并不能直接应用于互联网大规模的数据挖掘及推荐引擎引擎使用。
2、采用Lucene实现推荐引擎的优势
对很多众多的中小型网站而言，由于开发能力有限，如果有能够集成了搜索、推荐一体化的解决方案，这样的方案肯定大受欢迎。采用Lucene来实现推荐引擎具有如下优势：
1）、Lucene 入门门槛较低，大部分网站的站内搜索都采用了Lucene
2）、相对于协同过滤算法，Lucene性能较高
3）、Lucene对Text Mining、相似度计算等相关算法有很多现成方案
在开源的项目中，Mahout或者Duine Framework用于推荐引擎是相对完整的方案，尤其是Mahout 核心利用了Lucene，因此其架构很值得借鉴。只不过Mahout目前功能还不是很完整，直接用其实现电子商务网站的推荐引擎尚不是很成熟。只不过从Mahout实现可以看出采用Lucene实现推荐引擎是一种可行方案。
3、采用Lucene实现推荐引擎需要解决的核心问题
Lucene擅长Text Mining较为擅长，Lucene在contrib包中提供了功能，可以较为容易实现Content-Based的推荐，但对于涉及用户协同过滤行为的结果（所谓的），Lucene目前并没有好的解决方案。需要在Lucene中内容相似算法中加入用户协同过滤行为对因素，将用户协同过滤行为结果转化为Lucene所支持的模型。
4、推荐引擎的数据源
电子商务网站与推荐引擎相关典型的行为：
购买本商品的顾客还买过
浏览本商品的顾客还看过
浏览更多类似商品
喜欢此商品的人还喜欢
用户对此商品的平均打分
因此基于Lucene实现推荐引擎主要要处理如下两大类的数据
1）、内容相似度
例如：商品名称、作者/译者/制造商、商品类别、简介、评论、用户标签、系统标签
2）、用户协同行为相似度
例如：打标签、购买商品、点击流、搜索、推荐、收藏、打分、写评论、问答、页面停留时间、所在群组等等
5、实现方案
5.1、内容相似度
基于Lucene MoreLikeThis实现即可。
5.1、对用户协同行为的处理
1）、用户每一次协同行为都使用lucene来进行索引，每次行为一条记录
2）、索引记录中包含如下重要信息：
商品名、商品id、商品类别、商品简介、标签等重要特征值、用户关联行为的其他商品的特征元素、商品缩略图地址、协同行为类型（购买、点击、收藏、评分等）、Boost值（各协同行为在setBoost时候的权重值）
3）、对评分、收藏、点击等协同行为以商品特征值（标签、标题、概要信息）来表征
4）、不同的协同行为类型（例如购买、评分、点击）设置不同的值setBoost
5）、搜索时候采用Lucene MoreLikeThis算法，将用户协同转化为内容相似度
以上方案只是基于Lucene来实现推荐引擎最为简单的实现方案，方案的准确度及细化方案以后再细说。
更为精细的实现，可以参考Mahout的算法实现来优化。
标签: &&&&&&
版权所有:非特殊声明均为本站原创文章，转载请注明出处：
订阅更新:您可以通过
您可能感兴趣的文章tf(t in d)：Term frequency factor for the term (t) in the document (d)—howmany times the term t occurs in the document.
idf(t) ：Inverse document frequency of the term: a measure of how“unique” the term is. Very common
very rare terms have a high idf.
boost(t.field in d): Field and document boost, as set during indexing (see section 2.5).You may use this to statically boost certain fields and certain documentsover others.
lengthNorm(t.field in d): Normalization value of a field, given the number of terms within thefield. This value is computed during indexing and stored in the indexnorms. Shorter fields (fewer tokens) get a bigger boost from this factor.
coord(q, d): Coordination factor, based on the number of query terms thedocument contains. The coordination factor gives an AND-like boost to documents that contain more of the search terms than other documents.
queryNorm(q)： Normalization value for a query, given the sum of the squared weights of each of the query terms.
阅读(...) 评论()基于LUCENE和LSA的法律咨询系统
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
基于LUCENE和LSA的法律咨询系统
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口，黄河入海流
现在在京东、易迅、亚马逊等看到的主流推荐算法，一般都是基于物品自身相似性（不依赖于用户数据，没有冷启动问题）、基于用户浏览、喜欢、购买等数据的协同过滤推荐（用户纬度和商品纬度）。&br&&br&其实这些推荐算法的核心思路，是很朴素的。&br&一、基于物品自身相似度：例如衣服A和衣服B，对于它们在分类、价格段、属性、风格、品牌定位等等其他属性纬度的表现，来计算它们之间的相似度，如果相似度高，那么在有用户浏览A的时候，就可以推荐B（实际当然没这么简单）。因为衣服的这些属性是不依赖于用户的，所以解决了系统的冷启动问题，正是不依赖与用户的行为数据，因此比较死板，完全没有个性化的推荐。这个算法的思路很多人都清楚，但是越是简单的算法，要达到好的效果就越是难，特别是推荐这种转化率非常低的算法。商品有几十个属性，对不同分类的商品，并不是所有的属性都是有必要纳入相似度计算的，已经纳入的属性但是重要性也是有区别的，这样一来，&b&光光给不同类别商品筛选必要属性以及设置这些属性在相似度计算中的权重值，就是一项非常浩大的工程了。&/b&亚马逊的推荐系统在全球行业中也是最早的，相信他们在这个问题上肯定有自己一套迅速有效的方法。当然要我来说具体是怎么样的，我怎么可能知道呢^_^，知道了也不告诉你。&br&&br&二、基于用户纬度的协同过滤：采集用户的购买（浏览、收藏都行）商品数据，把用户购买的商品列出来，当作用户的属性纬度。例如用户A购买了商品1、2、3、4、5，用户B购买了商品1、2、5、6，那么可以简单的将1分别作为A和B的属性特征字符串，计算A和B的相似度，经过简单的聚类将用户聚成几个类别（邻居）。假设A和B同属于一个聚类，那么可以称A和B有比较相似的偏好，继而可以将A买过而B没买过的其他商品推荐给B。在这一个流程里，可以发挥的地方有很多：&b&1、用户的行为数据需要去噪音&/b&（买了多少商品以下的用户不考虑，有代购的不考虑，如何精准的判断代购，商品时效性的考虑，数据的时间跨度等等）；&b&2、计算相似度&/b&的时候跟第一点中提到的一样，并不是所有商品对用户的描述度都是一样的。可能价格低的重要程度就没有昂贵的商品重要。&b&3、通过聚类计算邻居的时候，聚类算法又是另一门学科了，或者选择分类算法。&/b&然后聚类的门槛选择都是需要很长时间的测试、观察、修改的，需要时间的积累。&b&4、浏览、购买、收藏等历史数据是不是可以协同过滤。&/b&现在很多网站给出的推荐，都不是单一推荐算法的，&b&一个算法的输出可以作为另一个算法的输入，可以是多个算法的输出综合筛选&/b&，这也是一个需要长时间积累的地方。&br&&br&三、基于物品纬度的协同过滤：其实我觉得是和第二点很相似，就是将用户作为商品的属性纬度来看。例如商品A被用户1，2，3，4，5，6购买过，商品B被用户1，3，4，5，7购买过，那么将123456作为商品A的特征属性数据，13457作为商品B的特征数据，然后计算商品A和B的相似度（这里的相似度却别于第一点提到的相似度，似乎叫“相似度”不是很合适）。因为我们有理由认为同一个人群买了A，又买了B，那么A和B一定有某种关联。在这个流程里面可以发挥的地方基本和第二点中提到的差不多。&br&&br&四、强关联规则的应用：重点是同一次购买记录（当然也不是必然的，看自己的选择）。首先收集数据就需要把一单购买一种商品的过滤掉。然后一次对每一条记录中进行成对提取统计，简单的就是两两统计次数，这种提取出来的都是两个商品被同时购买的次数，适用于一对一推荐。还有一种是通过FPTree算法（似乎是这个名字吧，因为我们公司是一对一的需求，所以这个算法我没怎么研究，是我自己写的两两统计），不光是一对一推荐，可以一对二，二对一。在这个流程里面，关联规则（&a href=&/link?url=q-yAvMTfKkdorj_y3CNjdz9SOuFNxosLctWNIivNZDD6GoVi5tR7anbjgMZWYha3fl0WXiXJFTLw-Wn9JOPez_& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&关联规则_百度百科&i class=&icon-external&&&/i&&/a&）挖掘算法非常重要，其中置信度和支持度也是需要不断调整的地方。&br&&br&五、所有推荐系统之间的数据共享、数据的定时自动更新、自动学习。&br&&br&总的来说，推荐算法大部分都是很朴素的，但是需要运用的好，没有长时间的积累是做不到的。仅仅是聘请一些算法工程师，运用一些算法框架，想取得好的推荐效果，基本是不可能的。只有算法与具体业务相结合才能产生化学反应。
现在在京东、易迅、亚马逊等看到的主流推荐算法，一般都是基于物品自身相似性（不依赖于用户数据，没有冷启动问题）、基于用户浏览、喜欢、购买等数据的协同过滤推荐（用户纬度和商品纬度）。其实这些推荐算法的核心思路，是很朴素的。一、基于物品自身相似…
我开始学编程，都是看着书上的代码敲的。不管是以前初学，还是现在工作几年了，每次看着例子敲完的代码、编译、运行通过都会有一种小小的成就感（不怕你们笑话，确实有这个感觉）。正是这种小小的成就感，才促使我不断的学习。我相信，绝大部分爱好开放的程序员都会有这种感觉吧，如果你每次学着例子敲完代码并且编译运行成功，但是丝毫感觉不到高兴或我说的成就感，或许是你学这行不够热爱或者说不是真正的发自内心的喜欢这一行。。&br&&br&个人感觉，如有雷同，纯属知音，如有反对，纯属正常。
我开始学编程，都是看着书上的代码敲的。不管是以前初学，还是现在工作几年了，每次看着例子敲完的代码、编译、运行通过都会有一种小小的成就感（不怕你们笑话，确实有这个感觉）。正是这种小小的成就感，才促使我不断的学习。我相信，绝大部分爱好开放的程…
这是一门让不熟悉的人抓狂，让深爱它的人鸡冻不已的脚本语言。。。过于灵活的语法
这是一门让不熟悉的人抓狂，让深爱它的人鸡冻不已的脚本语言。。。过于灵活的语法
艹云和日云。。。。。。。。。。
艹云和日云。。。。。。。。。。
水笔画的，稍微描了下最外的轮廓，哈哈！&br&&br&名爵的MG6&br&&img src=&/0b50f1b460c6fdf539c98_b.jpg& data-rawwidth=&2286& data-rawheight=&1257& class=&origin_image zh-lightbox-thumb& width=&2286& data-original=&/0b50f1b460c6fdf539c98_r.jpg&&&br&&br&宝马&br&&img src=&/fe7334937a_b.jpg& data-rawwidth=&2261& data-rawheight=&1481& class=&origin_image zh-lightbox-thumb& width=&2261& data-original=&/fe7334937a_r.jpg&&&br&&br&阿斯顿马丁？？&br&&img src=&/bdb85dae7ffb7_b.jpg& data-rawwidth=&2330& data-rawheight=&1247& class=&origin_image zh-lightbox-thumb& width=&2330& data-original=&/bdb85dae7ffb7_r.jpg&&&br&奥迪&br&&img src=&/46dfb6dd1a7_b.jpg& data-rawwidth=&2269& data-rawheight=&1241& class=&origin_image zh-lightbox-thumb& width=&2269& data-original=&/46dfb6dd1a7_r.jpg&&&br&布加迪&br&&img src=&/a7baf3dbe2e7_b.jpg& data-rawwidth=&2592& data-rawheight=&1936& class=&origin_image zh-lightbox-thumb& width=&2592& data-original=&/a7baf3dbe2e7_r.jpg&&&br&&br&玛莎拉蒂&br&&img src=&/a29f9c3d01e7b618c403f4bde9bfd53a_b.jpg& data-rawwidth=&2592& data-rawheight=&1936& class=&origin_image zh-lightbox-thumb& width=&2592& data-original=&/a29f9c3d01e7b618c403f4bde9bfd53a_r.jpg&&&br&从上到下是按时间从前到后的，感觉越画越有心得，慢慢自学会了水笔线条的明暗处理（自己以为的）。&br&&br&绝对业余，个人只是喜欢没事画两笔，懒的找铅笔，也不会素描，所以用了水笔，又怕轮廓比例拿捏不好，所以外轮廓描了几笔，99%是画的，哈哈！
水笔画的，稍微描了下最外的轮廓，哈哈！名爵的MG6宝马阿斯顿马丁？？奥迪布加迪玛莎拉蒂从上到下是按时间从前到后的，感觉越画越有心得，慢慢自学会了水笔线条的明暗处理（自己以为的）。绝对业余，个人只是喜欢没事画两笔，懒的找铅笔，也不会素描，所以…
根据个人对于搜索引擎2年的经验，说说自己的看法：&br&&b&一&/b&、&b&似乎没有看到内部的同义词设定&/b&&br&我搜索关键字“北京大学”，出现的结果都是比较合理（先不考虑结果排序）。一般很多关键字是有缩写的，就像北京大学，口头简称北大，那么来搜索“北大”试试看，结果出现了一个不能忍的结果&img src=&/9b8dbbdf9f0a0555113dab0_b.jpg& data-rawwidth=&716& data-rawheight=&171& class=&origin_image zh-lightbox-thumb& width=&716& data-original=&/9b8dbbdf9f0a0555113dab0_r.jpg&&居然出现了“为什么东北大米这么贵？”的结果，个人感觉这是不是有点不负责任的。&br&关于同义词这一点，其实非常容易搞定。每个问题被提出来的时候，都设定了问题的相关话题，这简直是最直接、准确的内容关键字提要啊，没有用来帮助精确化搜索结果，不是暴殄天物么^_^？&br&&br&下面利用“北大”和“北京大学”这两个同义词关键字来举例同义词功能。&br&“北大”、“北京大学”、“京师大学堂”和“高等学府”这几个词都表示同一个意思，那么对用户来说，无论输入哪一个，希望得到的结果是一致并且准确的。达到这个效果，有两种做法：&br&1、索引阶段的同义词扩展&br& 就是在根据问题内容来简历关键字倒排链表的时候，就将关键字进行扩展。“北大”、“北京大学”、“京师大学堂”和“高等学府”这四个关键字的倒排链表是一样的。简单来说，就是遇到四个关键字中的任意一个，就自动扩展成四个，那么对于任意一个问题，这四个词都是同生共死的，要么一起有，要么都没有。优势就是，&b&在根据关键字建立查询语法树的时候，可以更快，建立的语法树更简单&/b&。最终得到的需要进行NOT、AND、OR操作的倒排链表更加少，那么对应的查询效率就高。劣势就是，同义词设置不够灵活，如果遇到第五个表示“北京大学”的词语，那么需要重建对应问题的索引，才能使新增的同义词生效。&br&&br&2、查询阶段的同义词扩展&br&索引阶段不做任何关于同义词的额外操作。当需要根据关键字“北大”来进行搜索的时候，自动根据同义词库扩展查询树，把“北大”、“北京大学”、“京师大学堂”和“高等学府”这四个关键字的结果一并查出，然后求并集（相对来说效率会比方法一略低，不过都是非常底层的倒排链表操作，可以承受）。&b&相对这点额外的效率消耗，换来的就是非常灵活的同义词设置，因为查询阶段的同义词扩展，可以近乎实时的。&/b&&br&&br&&br&这个时候可能有人会问，这个还是没有解决搜索“北大”出现“为什么东北大米这么贵？”这个问题（因为同义词是并集，^_^小学语文学的，自问自答，写作文可是能加分的手法）。&br&一开始我就说了，问题的相关话题就是一个天然的问题标签，我们只要对用户查询关键字做一个简单的预处理，就可以轻松解决这个问题。当发现用户输入的查询关键字中分词出了“北大”，那么可以自动附加搜索条件“话题=北京大学”，因为“为什么东北大米这么贵？”这个问题没有关联到话题“北京大学”，所以这个问题就解决了。&br&&br&还有一点，个人建议是，索引阶段用最小分词（北京大学的分词结果是“北京大学”、“北京”、“大学”），查询阶段用最大分词（北京大学的分词结果只是“北京大学”）。这样的好处是可以解决关键字“东北大米”的搜索结果问题。&br&&br&&b&二、问题的主体描述和答案似乎没有进行一个全文索引&/b&&br&如果考虑到对问题答案进行索引将会使索引文件大小大大增加，目前没有这个人力来解决大容量索引的问题，那么可以对每个问题中“赞”的数量最多的前几个答案进行索引、或者设定一个“赞”数量的阀值&br&&br&&b&三、搜索结果似乎没有做一个有意义的相关性排序&/b&&br&似乎没有利用到当前用户的关注（收藏、没有帮助、感谢）信息（关注的用户，关注的问题，关注的话题）来对本次搜索结果进行一个个性化的有意义的排序。在符合关键字这个硬指标的前提下，进行类似下面的这种结果个性化排序（重要性排名分先后）：&br&1、首先根据用户关注的话题信息，将结果集中属于用户关注话题的问题（或者直接是用户关注的问题），排在前面&br&2、结果中，如果有当前用户关注的用户进行了答题，那么是否也可以考虑将此问题提前&br&3、当前用户点过没有帮助的问题，是否直接屏蔽（不知道现有的知乎搜索有么有实现这个功能）&br&4、对于其他的知乎所收集的用户行为信息（感谢、分享、收藏、举报），都可以加以利用，因为这些信息都非常直接的表示了用户对某一个问题，甚至是问题对应的话题的一个感兴趣度&br&&br&&b&四、搜索和推荐其实是相辅相成的，很多信息可以共享&/b&&br&&br&一个完备、优质的全文检索引擎，词库的维护是非常重要的，不亚于复杂的排序算法。&br&&br&以上回答纯属个人看法和经验，如有不合理之处，请见谅。&br&&br&===========================================&br&话说最近准备看看好机会，可惜知乎似乎是在北京办公^_^
根据个人对于搜索引擎2年的经验，说说自己的看法：一、似乎没有看到内部的同义词设定我搜索关键字“北京大学”，出现的结果都是比较合理（先不考虑结果排序）。一般很多关键字是有缩写的，就像北京大学，口头简称北大，那么来搜索“北大”试试看，结果出现…
比自己厉害的
比自己厉害的
社会风气这东西，还是和国民素质有关。。不知道英国、美国他们的社会风气是不是比我们差很多？？他们的民众对政府说话底气十足，，，甚至不留情面，是不是风气不好呀
社会风气这东西，还是和国民素质有关。。不知道英国、美国他们的社会风气是不是比我们差很多？？他们的民众对政府说话底气十足，，，甚至不留情面，是不是风气不好呀
个人感觉，首先问题输入框，肯定是基于分词的搜索匹配。&br&应该是中文和拼音都做了分词，而且是分开搜索的，你的关键字只含汉字或只包含拼音，匹配比较准确。而且拼音，应该是完整的严格的全拼，可以按字匹配，但是必须保证输入拼音的先后顺序（已分词词组为单位。例如：sousuo yinqing，和yinqing sousuo都可以搜到相同的结果）。&br&用市面上的搜索引擎框架都很好实现这个功能。例如可以用lucene+pinyin4j。
个人感觉，首先问题输入框，肯定是基于分词的搜索匹配。应该是中文和拼音都做了分词，而且是分开搜索的，你的关键字只含汉字或只包含拼音，匹配比较准确。而且拼音，应该是完整的严格的全拼，可以按字匹配，但是必须保证输入拼音的先后顺序（已分词词组为单…
我们用一门语言，就是要发掘运用它成熟、稳定、优势的地方；至于缺陷，我们需要尽量规避，google一直在大范围使用js，而且效果很好。至于到底成熟与否，都是因人而异，或许很多人，就是喜欢js过于灵活（诡异）的语法。&br&说一句无关的：我们总是对自己在意、喜欢的人或事，挑很多不足、而不懂得赞美。中国的父母大部分都是如此吧，谁家的孩子肿么肿么样好。。。。
我们用一门语言，就是要发掘运用它成熟、稳定、优势的地方；至于缺陷，我们需要尽量规避，google一直在大范围使用js，而且效果很好。至于到底成熟与否，都是因人而异，或许很多人，就是喜欢js过于灵活（诡异）的语法。说一句无关的：我们总是对自己在意、喜…
技巧就是：不去玩！哈哈
技巧就是：不去玩！哈哈
泻药，瘦虫弱精。&br&&br&我觉得各有所难，完整的推荐逻辑过程包括：1、单体样本的分析，2、样本属性模型的建立，3、样本属性的获得，4、样本之间相似度的评估、计算。&br&&br&以下讨论的基本都是基于数据本身，不考虑用户和项目之间的偏好信息，所谓的冷启动推荐系统。&br&&br&一、阅读&br&根据不同领域的文章，来确定不同的关注点。技术类文章需要关注技术名词、技术领域、专家作者；YY小说类，需要关注的是穿越还是现世，东方还是西方，完结还是未完结，细致点还有魔法体系、功法体系，绝对YY还是一般YY等等。散文集需要关注的是作者、内容提要、风格（这东西我完全不懂啊）。&br&如此看来，阅读类的推荐，难点就(过程1)是确定关注领域，(过程2\3)提炼章节大意；还有就是过程4，因为文本的相似度计算需要关注除开那些可以数值化\量化的作者、是否完结、类型之外，更加需要关注文本之间的相似度评估。文本相似度计算到底是采用简单的分词匹配还是建立话题模型，都是难点所在。&br&&br&二、电影&br&其实我觉得，电影和阅读相似度蛮高的，因为有剧本，只是在属性选择面更广了，多出了演员列表（用户关注电影，也有很大程度上是因为演员）。&br&&br&三、音乐&br&个人觉得，最难的就是音乐。&br&音乐的数据模型最复杂，曾经看到过一篇文章，提到了音乐模型：音色、音轨、声调、歌词以及其他音乐专业领域的信息都是可以量化\数值化的，比如提取成一串字符串。至于什么艺术家、歌曲类型等也是需要的。&br&&br&其实要做好推荐，这三个都很难，就看我们自己能不能发现别人没发现的评估点，以及背后需要的庞大算法。
泻药，瘦虫弱精。我觉得各有所难，完整的推荐逻辑过程包括：1、单体样本的分析，2、样本属性模型的建立，3、样本属性的获得，4、样本之间相似度的评估、计算。以下讨论的基本都是基于数据本身，不考虑用户和项目之间的偏好信息，所谓的冷启动推荐系统。一、…
傻子那驾驶的双动力炉可量子化的OO呀
傻子那驾驶的双动力炉可量子化的OO呀
首先，这两个协同过滤的推荐，数据源可以是一致的，都是用户对商品的偏好。&br&&br&基于物品：将用户对物品的喜好，当作是物品的一个属性来看待，也就是说，有多少用户喜欢物品A，那么可以看作A有多少个维度的属性，具体偏好就是维度的属性值。然后通过一些简单的相似度算法，来结算物品间的相似度。当大部分用户购买的商品很少的时候（比如有60%以上的用户只买一件、两件的商品），但是用户数量很多，商品数量相对少，那么这个时候，基于物品的协作过滤效果比较好。因为，对物品来说，会被很多用户购买，那么它的所谓属性维度比较丰富，算出来的相似度可能比较靠谱。劣势是，不够个性化，不管哪个用户来看，只要是同一件物品，得到的推荐基本一致。这个方式的推荐，长尾覆盖可能会好点。个人觉得，有点类似于“买了还买了”。&br&&br&基于用户：其实只是反过来看，将用户购买的物品看作是这个用户的不同维度的属性，很显然，大部分用户买了多件物品的数据，采用这种方法效果比较好。因为一个用户的够买的物品多，表示他是维度丰富，那么通过这种相似度找到的邻居也比较多，而且靠谱。然后可以依据邻居购买的而他每购买的商品，推荐给用户。优势是，更加个性化。但是前提就是，用户与那些跟他喜欢相同物品的人具有相同的口味。主要推荐的商品都是属于热卖型的。&br&&br&这些方式，在mahout中都有实现，但是在实际应用中，单独的推荐远远不能满足需求，需要非常复杂的组合，干预、决策和机器学习。&br&&br&国内互联网在这方面的应用：大部分电商网站基本都有，但是效果我就不知道了，没怎么关注过。似乎都说豆瓣不错。亚马逊中国，做的很好，也很早
首先，这两个协同过滤的推荐，数据源可以是一致的，都是用户对商品的偏好。基于物品：将用户对物品的喜好，当作是物品的一个属性来看待，也就是说，有多少用户喜欢物品A，那么可以看作A有多少个维度的属性，具体偏好就是维度的属性值。然后通过一些简单的相…
js里拿到的document.cookie就是字符串，解析靠自己
js里拿到的document.cookie就是字符串，解析靠自己
仅仅依靠QQ？？&br&qq用户群基础极其庞大，同时在线人数巨多，而且qq界面有qq空间的入口，非常方便。。比所有其他的社交网站入口方便。因为我们早已不把登录qq当作一个额外操作，而是每天打开电脑，自然而然的事。因此，进入qq空间方便，耗时几乎为零哦，亲
仅仅依靠QQ？？qq用户群基础极其庞大，同时在线人数巨多，而且qq界面有qq空间的入口，非常方便。。比所有其他的社交网站入口方便。因为我们早已不把登录qq当作一个额外操作，而是每天打开电脑，自然而然的事。因此，进入qq空间方便，耗时几乎为零哦，亲
当你是一个码农，当你码代码的时候想要偷懒的时候，就会觉得有意义了。&br&&b&不想偷懒的码农不是一个合格的码农！！！！&/b&
当你是一个码农，当你码代码的时候想要偷懒的时候，就会觉得有意义了。不想偷懒的码农不是一个合格的码农！！！！
如果是以前，我会说：根据我3年的电商搜索引擎工作经验，以及对知乎搜索引擎的使用情况，我推测，知乎没有用开源的搜索引擎吧，不然怎么会出现这种莫名其妙的问题？&a href=&/question//answer/& class=&internal&&知乎的搜索功能是不是很弱？ - 白日依山尽的回答&/a&&br&&br&虽然现在貌似没有了“北大”出现“东北大米”的结果，但似乎依旧没有同义词概念，我觉得作为知乎这种高端问答社区网站，不会出现这种问题，不太像是用了开源搜索引擎框架会出现的问题。&br&&br&而且，没有对问题的答案进行分词索引，我copy答案的一句话，搜不到任何答案，可能知乎的工程师把搜索条件进行了AND拼接，关键字多了就没结果，但是搜索引擎默认的会根据匹配程度进行打分排序的，也就是说，基本不会出现无结果，召回率应该很高，顶多准确率会略有下降。我觉得电商的商品搜索，可以严格按照用户的关键字搜索，没有就没有，然后重组关键字；但是问答类的搜索，应该是按照关键字的重要程度，进行匹配打分，然后排序。如果用户输入5个关键字，没有完全符合的结果，那么给出的就应该是，按照匹配度由高到低给出结果，或者给出重组关键字的结果吧，这才是一个搜索引擎应该做的事。&img src=&/d95bb4fff3a62fca5c7f_b.jpg& data-rawwidth=&672& data-rawheight=&391& class=&origin_image zh-lightbox-thumb& width=&672& data-original=&/d95bb4fff3a62fca5c7f_r.jpg&&&br&&br&而且没有所谓的关键字重组搜索（XXX搜索没有结果，我们为你找到XX相关的结果）。&br&&br&个人结论，可能用了搜索引擎的部分概念，可能是知乎的工程师自己按照分词、到排表生成、查询树的生成和匹配、链表的交集并集差集、空间向量相似度计算（余弦定理）、排序而开发的。&br&但是，肯定没用什么开源的搜索引擎，赌5毛！
如果是以前，我会说：根据我3年的电商搜索引擎工作经验，以及对知乎搜索引擎的使用情况，我推测，知乎没有用开源的搜索引擎吧，不然怎么会出现这种莫名其妙的问题？虽然现在貌似没有了“北大”出现“东北大米…
“袖珍”，指的是可以藏在袖口里的大小吧；“迷你”，个人理解应该是针对正常大小的东西来说的。&br&所以说，“袖珍”肯定很小，但是“迷你”可以比“袖珍”大，也能比“袖珍”小，但是肯定比自己正常版本要小吧。
“袖珍”，指的是可以藏在袖口里的大小吧；“迷你”，个人理解应该是针对正常大小的东西来说的。所以说，“袖珍”肯定很小，但是“迷你”可以比“袖珍”大，也能比“袖珍”小，但是肯定比自己正常版本要小吧。
没玩过coreseek或者sphinx，个人目前使用的是solr/lucene，所以一下的功能介绍都是基于solr/lucene的。&br&&br&不过这种全文检索框架，其实对语言的限制不是很大，中文、日文、英文、发文、阿拉伯文其实都没啥区别，因为计算机基本不知道你的语言类型。&br&&br&完整的全文检索分索引和查询两个过程。&br&一、索引&br&就是将非结构化或者半结构化的数据结构化的过程。将网页抓取，数据库查询，文件读入的内容进行一个分词、取无用词（停用词）、词根化、字典排序、建立倒排链表的过程。题主的难点是说日韩文以及sphinx的一元分词。&br&&br&首先说一下分词词典，其实人脑和计算机一样，想要从一句话中提取有意义的词语，都是需要词典库的。例如对于“今年是中华人民共和国成立65周年”这句话，我们人之所以知道“今年”、“人民”、“共和国”等是一个词语，是因为以前我们学到过、接触到过，这个学习接触的过程，其实就是在往你大脑这个词库加入新的分词。那么计算机也是如此，一般的分词算法都建立在一个基本的分词词典文件之上，运行用户扩展自定义。&br&对于楼主所说sphinx是不是只有一元分词，我没用过，不做多说，但我理解的一元分词是不需要分词词典。&br&理解了分词原理之后，其实对于什么语言根本没关系，计算机所做的就是依次扫描。还是上面举的例子，计算机获得的内容是（基于词库的词典树）：&br&&br&“今”：词库里有，但是不是词尾，会继续往后&br&&br&“&b&今年&/b&”：词库里有，“年”可以是词尾，也就是说“今年”是一个词；如果是最大分词，则继续往后判断“今年是”是否在词典里，不在的话，会往回保留“今年”，否则继续往后。（后面不讨论最大分词）&br&&br&“年”：词库有，不是词尾，继续往后&br&&br&“年是”：词库显示，“年”的子节点木有“是”，则舍弃“年”，从“是”开始&br&&br&“是”：词库有，不是词尾，继续往后&br&&br&“是中”：词库显示，“是”的子节点木有“中”，则舍弃“是”，从“中”开始&br&&br&“中”：词库有，不是词尾，继续往后&br&&br&“&b&中华&/b&”：词库显示，“中”的子节点有“华”，且可以是词尾，则保存“中华”，继续往后&br&&br&“中华人”：词库显示，“中”的子节点“华”，他的子节点有“人”，如果“人”可以是这棵词典树的结尾，则保存“中华人”，否则继续&br&&br&“&b&中华人民&/b&”：词库显示，“中-华-人”这棵叔的子节点有“民”且可以是词尾，则“中华人民”可以保存。&br&&br&说的不是很清楚，大概的分词核心就是这个。所以，可以把这句话换成其他语言都没关系，重点是分词词典。&br&&br&接下来说说倒排链表，其实倒排链表也是简单，和书本的章节目录差不多。根据目录内容，确定章节具体的页码，只不过全文检索里面可以做到，根据某个词语（分词词典中的），来确定文档编号（系统自增的文档编号），然后通过文档编号来找到当初建立索引的所有信息。&br&所以一个倒排链表就是一个词语，后面跟着所有包含这个词语的文档的文档编号的从小到大的链表。当然这个链表的内容还有很多，比如文档中出现这个词的频率、位置等。&br&&br&二、检索过程&br&简单的来说，就是把用户输入的检索关键字，进行分词，然后分别从倒排链表中拿出每个分词所对应的文档编号链表，接下来就是链表的交集（AND）、差级（NOT）、并集（OR）了。&br&详细的过程就是分词、词根化、同义词处理、建立query树、链表合并、相似度计算（空间向量算法）、综合文档boost进行排序、facet分组统计。&br&&br&说了这么多，不知道能不能帮上题主。其实全文检索领域还是挺有意思的。
没玩过coreseek或者sphinx，个人目前使用的是solr/lucene，所以一下的功能介绍都是基于solr/lucene的。不过这种全文检索框架，其实对语言的限制不是很大，中文、日文、英文、发文、阿拉伯文其实都没啥区别，因为计算机基本不知道你的语言类型。完整的全文检…