关于k12领域Lucene.net+pangu搜索引擎设计开发的一些回顾

在中国最大的教育资源门户网站两年期间, 黄药师负责学科网搜吧的设计与开发…正好赶上了公司飞速发展的阶段.. 作为专注于k12领域内容与服务的互联网公司的一员，同时整个公司又在积极提升用户体验的氛围中,黄药师对自己的工作感到责任重大，并为之激动不已，工作时自然百倍投入..

闲话先说到这里了^^，如果有兴趣，可以关注一下黄药师的微信公众号： e尚派 .以后会和大家一起探讨..也很期待一起交流，共同成长…另外本文假设读者您已经对Lucene有了基本的了解,具体到笔者自己，用的是lucene.net 3.0.2+盘古分词器组件..

刚接手时， 搜索引擎已经可以跑起来，但是搜索结果并不理想…我们都知道搜索引擎里面搜索结果的查准率和查全率是两个重要的指标…但搜索引擎作为一个门户网站的重要组成部分，其地位和意义如人的动脉血管一样… 试想一下，我们的教师和学生用户在网站上通过点击栏目版块，以及版块列表页分页查找….那会是一个多么让人无法忍受的事情…

毫无疑问，我们要解决问题概括起来就是：在平台千万用户积累近10多年的教学资料里面..如何让用户快速找到自己想要并且相对比较新的资料呢 ？

我们知道要做好lucene全文检索，首先要对倒排表结构和评分机制要有基本的了解..在此基础上我们所做的优化改进处理才不会偏离方向..

A.用户搜索过程查全率不高甚至出现没有结果，常见的原因汇总起来有：

跨站get请求内容编码问题//乱码了，有结果才怪..

分词错误// “去年初中”如果分词为”年初”就有问题了.

数字类问题 //编辑上传”..1月..”,用户搜索 “一月”

拼音问题 //百度的习惯，用户会用拼音来检索，如果没有处理就悲剧了

错别字问题 //用户搜索”七年级其中考试”,其实要”七年级期中考试”

公式问题 //用户搜索数理化公式时，部分字符被当停用词..

缺域转换处理//搜索免费的资料，应等效于资料价格属性=0,不管标题是否体现

缺简繁体处理//台湾，香港地区的用户会用繁体检索…没处理就悲剧了..

缺乏语义处理.//module1,模块一，模块1，module one,module1-2…不能硬匹配..

简写缩写 //”11-14年理(数)高二下”就是”2011-2014年理科数学高二下册”

文章摘要问题 //用作索引的信息，如果本身不能体现资料，则很难被搜索到…

查询策略不是最优 //查询策略不优秀，很多功夫都会前功尽弃

缺人工智能 //用户搜索”告诉我，到哪里得到下载积分,我很急”,我想人工回答^^..

…….此处还有很多…黄药师的一个感觉就是：很多东西不是某一个算法就能解决的，我们需要在运营中不断研究用户的搜索日志，不断找出高频率的问题，解决了，我们就会一个提高和进步….也就是前辈经常说的“好的产品不是开发出来的，而是运营出来的”

B.用户搜索过程中查准率不高的常见原因汇总起来有：

分词歧义 //”2014年初中考试”可能会分为“2014，年初，中考”意义不对..

排序方式不对//如果最优的结果没有排在最前面，用户会觉得不准确…

同上述A中影响查全率中的因素..

既然原因大家都有一定的了解了， 下面，黄药师就几个重要的问题和大家做一下分享：

1) 如何突破现有第三方中文分词的局限性?

首先，盘古分词器是一个优秀，并且很亲民的中文分词器组件，它的分词效果，总体上兼顾了质量和性能…盘古的作者也有预见性的为我们提供了一个自定义处理接口(ICustomRule).. 在日常开发过程之中，本人也经常与之打交道…至于原因，读者童鞋可以回顾一下我们上面讲的，导致查全率和查准率不好的常见原因^^..

至于怎么做，我们很显然可以根据对搜索日志的统计，观察, 先从最常见，频次最高的问题着手，因为解决了它们，往往能收到立竿见影的效果…我们看过盘古分词组件的童鞋应该知道，盘古分词器分词结束之后，分词结果是以双向链表的形式存储着..我们要做的就是针对上下文，确定需要怎么调整双向链表上的结点… 举例说明：对于”一月”,”元月”,”1月”这种不同形式，同种语义的，我们可以进行归一化，也就是无论用户上传时写的是其中的任何一种，其他用户搜索时，用其中任何一种搜索习惯都可以检索出所有的结果…原理参考倒排表…

2) 如何设置排序策略?

不同的场景，往往需要不同的排序策略….尤其是遇到第一排序，第二排序维度的时候甚至更多….. 而需要我们注意的是，涉及相似度评分的排序，我们需要关注Similary这个类，更准确地说是要理解lucene评分公式…因为什么时候考虑匹配的关键词的个数，什么时候考虑词的位置，间隔，倒包含频率…什么时候考虑权重…这些都直接影响了后面的系列优化…

3) 如何有效提高查准率?

通过设计一些工具，首先汇总和找出用户不满意的（搜索不准确）的搜索文本，这样我们就可以有针对性的着手优化..在解决了上述列出来的问题之后，我们在查询时也需要着重考虑..因为如果你用过多的must （boolean查询）,则无结果率大量增加，如果用过多的shuold，则排序讲面临巨大的挑战….并且我们的用户要求准确地，并且是较为新的资料…这时候考虑的因素就更多，因此一个综合一点的办法就是，我们可以通过某种机制，动态的判断某些term在 query中是重要的，对重要的，进行boolean must查询，对于不重要的则进行相似度或查询… 因为这样我们可以既保证结果不至于太偏离主题，又让用户看到的结果记录数很多（提高了查全率）..

4) 如何解决多维度分组统计的问题?

处理该问题的过程中，如果你用的是java 版本的lucene，则应该有官方推荐的办法，但用lucene.net则需要自己做一些处理，因为官方并没有将最新的java版本移植到.net版本…

其实这个问题，我们也有办法，我们先自己想一下，对于分组统计，我们的lucene检索过程和sqlserver不一样的地方在于，lucene是开源的，我们在它的collect document的过程中，可以进行汇总统计..思路很简单，但是出于性能考虑，我们又要用到lucene内部提供的field缓存，这样我们也不需要从磁盘上进行加载处理，那样代价确实太高了..

5) 如何提高用户的搜索体验?

用户的搜索体验是无穷无尽的，只要产品还在运营中我们就会发现我们还有很多事情需要去处理…

最基本的，我们的用户中老中青都有，另外天南海北，学生老师家长都有 …用户的搜索习惯和水平也千差万别…而我们要做的就是尽可能的做到简单，百度有一句话说的好，就是：简单，可依赖…具体的做法，当聪明的您看到了黄药师上面列出的常见原因，应该就有方向了，对不….

如果您想和黄药师有更多的交流，希望您能拿起您的手机关注：e尚派 .或者加入到e尚派官方群: 378053304