1：毕业设计任务书上前两个点均已完成并优化，现构建排序工具并展示

2：目前已经使用本机部署solrcloud导入50万项目，返回效果还不错

下一步：

1：熟知ossean的从爬虫之后开始的每一部分的代码

2：用java写一个前端显示界面作为展示项目搜索和帖子搜索，预计项目条数有300万，帖子条数有300万

3：大约下周可以开始撰写论文

项目最终排序分值 = 项目文本相关度 * 项目影响力 

1：项目影响力的计算

项目影响力的计算来自于与该项目相关联的各个帖子关注度之和，帖子关注度中考虑了评论数、浏览数、创建时间三个属性，问题如下：

（1）有些项目由于关联了很多个帖子，会导致影响力很大，会导致最终的排序分值影响远远大于项目的文本相关度，应该在此处设置最大阀值；

（2）有些处于程序bug或者项目自身原因，未关联帖子，项目影响力结果为0，相乘之后导致最终结果为0，应该设置最小阀值；

（3）创建时间和浏览数存在的关系并不是之前单纯的线性，数据统计和论文介绍，平均来看，帖子的浏览量是随着时间往后推移浏览量增长率变得越来越大，最后趋于平缓。

2：其他

（1）项目表中存在synonyms字段，应该做进一步细的处理，才可以更好的返回结果

（2）项目表中有关联帖子数值存在，但是影响力为0的情况，可能是程序bug，还未发现原因

搜索“帖子”工作总结

本文通过建索引和搜索两个阶段来比对原ossean和现已完成的solrcloud工作

一、建索引：

   1：时间效能
     经过使用solrcloud，和调优（tomcat调优、对所建索引字段在solr中存储形式调优、建索引时合并及存取策略调优）对比如下：

2：原ossean建索引时间过长，且solr单机支持定期增量建索引和全量更新很麻烦；

现有采用solr5.2.1+tomcat7.0+zookeeper3.4.6，构建solrcloud。

①Solrcloud可以一边建索引一边查询；

②创建索引时间大大减少，且定时增量建索引可以通过配置和编程实现

二、搜索：

发现ossean相关问题：

1：搜索算法需要改进：
①：仅采用文本相关度搜索，未结合帖子业务本身

②：文本相关度的搜索策略过于简单

2：同义词设置有问题：

关键性词语设置了同义如mysql 和postgresql是同义词，但是搜索时会返回很多用户并不想要且靠前的数据。

3：使用solr默认解析处理器，未加修改，导致用户查询词可能会作为solr内置参数，会出现bug

4：采用or查询，搜索结果集较大，造成查询累赘；

现已解决的相关问题：

1：搜索算法

关键词为文本相关度，关注度，二次排序

（1）根据文本相关度打分（RelScore）返回结果集（Result）的顺序（Ranki）分两部分处理：Ranki（i<=20） 和Ranki(i>20)。

对Ranki(i<=20)的结果集重新排序，按照Score=帖子文本相关度打分（RelScore）+帖子关注度(InfScore)的搜索策略，生成ReRanki的集合，返回结果集Result _{ReRanki（i<=20）} 和Result_{Ranki（i>20）}。

（2）文本相关度打分：具体策略可查看附件中edismax图

帖子关注度打分：

①获取当前文档的solrfieldvalue：评论数review，浏览数view_num，创建时间t；

②对t进行处理，转化为当前时间与创建时间天数之差t0；

③T = t0 / r0, r0为控制时间衰减因子，控制衰减在某一范围内；

④InScore = min（（review + 1） × （view_num + 1） × eT / r1，r2）

r2为根据文档查询权重遍布的影响力阀值，r1,r2共同降低影响力影响最终分值权重，review加1，view_num加1的目的是为了防止由于爬取错误，或者新数据为0的情况。

其中，r0 = 500，r1为2，r2为0.3

2：修改同义词配置，同义词增加在一些不必要的形式和行为上，如variable 和variables，connect和connected。

3：修改solr默认解析处理器，采用solr中edismax方式代替布尔查询。

4：采用and查询，多域搜索，设置权重

①减少结果集的返回

②保证了搜索的多样性

③保证了结果的准确性

爬虫建议：

1：stackoverflow帖子的comments内容并未爬取，显然，这是必要的，上面有很多有用的搜索信息

2：帖子在社区中处于动态变化的，评论数、回复数、浏览数都是爬取一次后一成不变的，这样对搜索策略有影响

目前问题：

接口的搜索算法代码均已实现和部分测试，但是部署接口至测试服务器，由于有一系列问题（安全协议，接口访问，外网配置）暂未完成接口的实现 

solrcloud部署为整个接口的描述

solrcloud安装步骤为具体实现

edismax打分为当前打分

一：stackoverflow

1：在使用搜索时候有一下几种方案：

（1）”info“，此方式只针对比较主流的“特殊关键查询词”，（事先定义一个“特殊关键查询词库”比如：“mysql”，“github”返回功能类似“百度百科”。——该方式在ossean主界面有体现。

（2）当且仅当搜索词没有命中“特殊关键查询词库”时，会出现“relevance”字段，此显示方式主要由于“文本关联度“。大体算法：

  搜索三个字段：title，tags，content；

  搜索方式：AND；

  多词搜索时：

        a：字段设置权重title>tags>>body;

        b：如果输入”张三  李四“，要求”张三和李四词汇“必须同时出现在某一个字段中，字段权重大的优先返回；

        c：若未同时出现在同一个字段中，返回零结果集；

  此处其实可以后期考虑增加votes，评论数，点击率

（3）“newest”，对同时命中一个字段的所有文档进行时间排序，返回最新时间；

（4）此外还有“votes”，“frequent”等类似。

二：现有搜索

（1）对Title，Tags，Body字段建索引并搜索；

（2）采用AND搜索；

（3）字段设置权重：Title：2.0，Tags：1.0 Body：0.1

（4）在三个字段中采用“or”的搜索方式：如果输入”张三  李四“，要求”张三“和”李四“词汇必须出现在这三个字段（哪个均可）中，字段权重

大的优先返回；

（5）对于一个字段中同时命中“张三 李四”的情况，solr中coord分值给的要高。

三：跟stackoverflow对比

优点：

（1）由于title（标题）和tags（标签）大都反应了文档中心，即使出现搜索”张三 李四“时，”张三“出现在Title，“李四”出现在“Tags”中也基本符合情况，保证了结果集的返回；

（2）Body权重设置较小。有两点优点：

        a：保证部分标签或主题并未给全文档描述信息，给予补充；

        b：保证结果集的返回；

    没有采用or的方式，其实感觉对帖子搜索使用or或者and差别不大，因为title和tags里面信息提取都精确，而且body设置权重较低，不会出现常用词匹配过多的问题，而且采用suggest的方式，用户搜索的时候可以提示搜索词的正确性和多量性，具体带研究。

（3）打分排序时，coord给的分值参与决定排序，所以跟stackoverflow中同时命中一个字段的效果一样。

四：下步想法

（1）大规模测试数据集，现在数据源较少（爬虫只取了700万stackoverflow），想要使用测试版服务器进行初步建索引尝试比对结果。

（2）定义查询语法，如用户输入”+“关键词，则相应的在用户输入的短语查询中，对应的词给予权重加成。此处也可以事先针对计算机领域的一些关键词建库加权重，先对用户搜索短语检索是否出现在库中，然后进行搜索。

（3）加入评论、创建或更新时间、投票数，觉得这三点没必要加入文本相关度打分中，这三点影响不够大，可以单独劈出一块，让用户手动选择，然后返回结果。

（4）在打分中加入点击率，url链接数，觉得这两点是可以考虑加入打分系统的。

（5）针对计算机领域，手工或者根据用户搜索设置一些扩展词，主要是解决一些分词不准确的问题。

（6）设置同义词，解决比如用户输入中文，但是相关信息在stackoverflow中也有体现。

（7）根据用户检索词建立搜索记录，对搜索关键词缓存建表，关键词之间又建立关系，给用户返回另一种体验，也可以考虑加入搜索排序中（就像百度一样那样的，一个是最下方提示相关，一个是直接在返回结果中体现）。

（8）情感分析，自然语言处理了吧，这一块其实可以往后放一下。

（9）关于集成问题，还有很多方面待研究，比如xml（其他格式也行，看前端要求）返回至前端，其中包括suggest、高亮、返回排序、统计数等。

之前遗留的问题：

采用and查询，如在两个字段内搜索张三李四，某个字段同时出现张三李四才会返回结果，而不是字段一出现张三，字段二出现李四也能返回，减少了结果集的返回

解决：

1：编译IK源码，解决结果集数量的返回问题。

2：分词问题，添加基本扩展词库、停用词库、同义词库，并进行了相关测试，后续还待补充。

3：debug模式下调试每条记录搜索对应的总打分，总分是lucenc评分机制。

现对Title，Tags，Body三个字段建立索引并设置权重为10，8，2

现有问题：

由于分词原因和lucene评分机制问题，返回最优结果不是完全匹配度高的文档，而是分词加权后分值高的文档

预计解决方案：

第一种：多次调试，设置最优分值

第二种：修改lucene评分机制，先进行完全匹配设置相关权重，其次再进行分词匹配，保证最优结果

预计解决时间：

周三之前

今日和雅蓉学姐验证了搜索输入到返回的效果，并讨论了ossean目前的一些问题。

solrcloud配置模糊查询还需再行处理，关于之前提的要在用户搜索词设置权值的功能由于solr的封装性，仍需一点时间。

工作：

感谢王涛老师昨日的指导和鞭策

1：完成了对stackoverflow表的索引的建立，以及cloud和单机solr的对比

2：完成增量索引的测试

3：对数据表对多词查询有了基本认识

规划：

明日之前可以初步完成多词简单搜索匹配的完成，由于牵扯词库、算法可能后期还要对搜索进行优化

观ossean：

之前本地装了ossean版本，但是只导入了一个表，今日与帅气的老师、学长，漂亮的学姐讨论，具体观察了在线版的ossean：

构架超前、合理

界面布局规整又不乏精美

设计资源丰富而又具有代表性

针对开源又别有新意

深深的震撼感。。

开始对mysql中较大数据进行建索引，出现问题，查摆过程中，服务器内存使用率过高。师兄在跑python程序，调配了tomcat和对部分数据进行优化，发现不是内存影响的问题，主要是因为同时对mysql数据访问的问题，后来继续查摆问题发现：建索引若是通过mysql数据表建的话比较麻烦，费时，可以用solr API 接口solrj直接对xml文件解析建索引。明日开始编程实现。