过去的一年，黄药师一直负责教育门户网站的搜索引擎算法设计，开发和优化..期间经历了很多，虽然充满曲折，压力很大也很幸苦，不过回归头来看，解决遇到的问题并改进用户体验的乐趣也很多.
先从框架和组件方面的体会说起：
1.搜索部分主要基于Lucene.net,这块已经用到了3.0版本了.虽然没有java版本的更新速度快，但确实也有不少改进.由于是开源的，所以我们可以进行修改并定制.
1.1在对Lucene.net修改方面，由于没有类似java版本那样对分组提供的内置支持，自己花了一段时间，在园子里面找遍了各种资源,虽然没有一个完整的思路，但至少网友们提供了一些修改的方向，后来经过分析和调试，总算实现了，其中最终最重要的是利用到了FieldCache这块..之后就是将统计的代码插入到lucene的数据Collect阶段. 为了确保本次修改便于复用，这些代码我将这些统计代码集中放在Lucene下自己新加的命名空间下. 并在IndexSearch的Search方法上提供了重载方法，以便传入分组的策略配置.最后有了这个东西之后，我们不仅可以在一次搜索过程中获取到各个分组维度下的统计数据，甚至一些范围区间类的统计数据..不但有利于网站的用户筛选资料，也方便了编辑部的同事快速了解哪些栏目缺少数据，以便快速进行补充。
2.中文分词部分用的是国内常用的盘古(Pangu)分词器，再次感谢作者eaglet,在使用这个分词器组件的过程中，越用越能感受到作者设计的巧妙，作者在很多细节方面为开发者考虑了.
2.1字典变更的时候，会自动进行同步加载.
2.2另外作者也提供了分词的自定义接口,这块很自然的给开发者针对自己领域和行业进行优化和定制提供了方便.如果您现在还不明白这个接口的作用，建议你可以查看一下你的搜索日志并了解一下作者分词算法的基本过程. PanGu是针对中文分词，而不面向某一特定领域，因此在处理上不会照顾到一些细节.例如"module 1",分词的时候会把连续的一段英文，数字，中文先粗的进行切分,然后再进行后续处理. 那么module 1自然最后输出来module,1两个词了. 可实际上module 1联合起来才有意义，因为它标示这是"模块一"....怎么办？ 这就需要咱们自己想办法了...类似的问题很多..
2.3在未登录词，多元与精确分词，大小写等各个处理上都有配置.
3.词义处理,这部分其实这部分不是必须的，或者再不同的公司有却叫不同的名字,本来想用语义处理，但严谨的说，语义处理比较专业，是一个博大精深的领域，我暂且叫这里是词义处理吧. 开发期间，我自己根据对用户的搜索日志分析，初步建立了一个模型..
3.1为什么要这块？
首先由于中文分词的复杂性，任何分词器都无法做到准确率百分百,在思路上，很多分词器都引入了概率与统计的处理思路，ICTCLAS分词器应用到了隐马尔科夫模型，而Pangu也有自己的统计学上的应用. 但我们首先就遇到一个问题：我们的词库在维护过程中，词频的设置需要一个好的处理模型.如果随意设计，则分词器作者的算法效果将大打折扣.
其次，只要我们查看一下用户搜索日志，会发现很多诸如同语言的近义词，跨语言的同义词,歧义词,缩写词,变体,范围词,拼写错误，拼音，错误词...
上面的情况会影响到用户的搜索体验，因为我们的用户输入是千变万化，随意性很强的，他们只想表达自己的意向就行了，而我们为了让用户感觉到良好的体验，必须做上很多功夫.还是上面那个关于模块的例子："模块一的单词表","模块1的单词表","module 1的单词表","module one的单词表","模块1-模块2的单词表"....用户其实都想要"模块一的单词表",这里如果需要保证查准率，并且提高查全率,就需要归一化处理了。
最后，黄药师觉得，要进一步改进搜索引擎的查准率和查全率，需要从以下如下几个方面着手(也是我今年需要重点的方向)：
1.尝试在兼容盘古分词器的过程中，融入领域内的一些分词需求的处理特性.最终减少不必要的索引空间和速度消耗.也为提高查准率做好准备.
2.关注并尝试研究内容摘要算法，目前搜索索引过程，依赖的是标题和简介，而简介很多质量并不高，是随意截取前面几句话，这样以来，所建立的索引并没有很好的反应这篇文档，也就很自然的导致用户的搜索意图和前面见的索引term很难匹配了.
3.继续研究词义处理，并开始着手分析相对简单并相对成熟的语义处理方案.
4.在现在按照相似度评分排序，评分排序相同下按日期倒序基础上，提高文档排序的可定制性，以便灵活的结合更多的Field进行排序控制.这样也会为业务和产品的策划提供比较的支持.