用户参及及语意搜索final.ppt

用户参与的语意搜索 Networm成员: 李宇梁双刘锋组长) 主要内容 问题的提出 解决思想 碰到的问题 实现设计 学习体会 存在不足 试验结果 问题的提出(碰到的问题) 当我们想搜索一个人的信息的时候,却往往搜索出来了他参加会议,某个活动的信息. 当我们想要搜索某一个某地自助游的信息, 果搜索出来的很多并不是我们想要的内容. 当我们想搜索图灵机的定义的时候,结果搜到的都并非很理想的结果. 问题的提出(为什么?如何解决) 为什么会出现这样的情况? 其中一个很大的原因是用户不能够清楚的表达自己的语意.另外一个原因是系统并没有针对用户的语意做出优化. 所以提出了用户参与的语意搜索包括两个方面,一个是给用户更大的选择权,另外一个是要根据这些选择做出优化. 问题的提出(哪写可以改进?) 哪写内容适合做语意搜索? 语意清晰，容易定义，但是表达多样，用户处理难度较大这种情况。 还有一些情况虽然定义并不容易,但是可以采用机器学习的方法来进行精化,也是可以在某些程度上提高搜索准确率的. 解决思想 使得用户在通用搜索的基础之上可以选择明确的搜索项目.或者在用户没有明确选择的时候可以在返回结果的同时返回可能相关的模版供用户选择. 在服务器端按照已经定义的类型,对每个网页进行分类.每个网页有可能同时属于多个类别.分类之后在对网页进行rank的时候需要加重此类别属性所占的比例. 碰到的问题 如何在增加新类型的时候,可以非常容易的增加进去,效率比较高,而且不影响客户对原系统的使用—可扩充性 虽然增加了类型匹配,但是不能够大幅降低用户搜索代价.需要能够非常快速的将类型权重加入到rank计算当中—高效性 还有许多实际实现时候的问题. 设计实现 为了满足可扩充性,就需要在修改文档类型的时候不影响用户的使用.这就需要独立于用户使用通用查询的数据结构—文档模版数组或者模版文档数组. 而且不同的进程修改的都是不同的数据.这样是对读进程没有任何影响的,可以不用封锁就可以直接修改读取.又因为是独立数据结构,所以更不会影响用户使用通用查询. 设计实现—文档模版数组图示 设计实现—文档模版数组分析 一种是存储’是’或者’否’的结果,这样即使模版数量很大,空间消耗也可以承受.当判断一个文档是否属于用户查询类型的时候,依据文档ID作为下标找到模版数组,再以模版ID作为下标得到是否属于. 一种是存储文件和每一个模版匹配的权重,这样更加精确,但是在实际中是否一定效果就比前一种好,还很难说.而且空间消耗也比较大. 找到文档与用户请求模版是否匹配的时间效率为2.常数量级. 设计实现—模版文档数组图示 设计实现—模版文档数组分析 一种是存储’是’或者’否’的结果,这样即使模版数量很大,空间消耗也可以承受.当判断一个文档是否属于用户查询类型的时候,依据文档ID作为下标找到模版数组,再以模版ID作为下标得到是否属于.时间复杂度也为2,常数量极. 一种是存储和此模板匹配的每一个文件的编号,当模版比较远远少于文档数量的时候,这种存储效率也不一定高.但是时间复杂度就约为M/N. 综上所述,这种方法不是很好.但当模版数量增大的时候,空间效率要求较高的时候可以考虑. 设计实现—主要部分 主要分为crawler,正文处理,切词,建立倒排表,rank,模版匹配,模版建立,用户UI.其中crawler和切词部分是使用其他产品,并非自己开发. 正文处理:处理掉html中的各种标签,并且进行编码转换. 模版匹配:将正文与模版进行匹配,并且得到一个匹配度,用来计算rank使用. 设计的实现—索引部分 倒排表结构 目的是通过关键词快速查找到出现的文档以及位置信息； 采用关键词作为Key，PostingList结构作为Value的哈希表方式，以提高查询的效率； Posting的结构为文档编号＋位置信息； 工作时倒排表结构位于内存中，实现了倒排表文件的存取，方便备份； 设计的实现—索引部分 文档信息索引 目的是通过文档ID快速查找到文档的信息； 采用文档ID作为Key，文档信息结构作为Value的哈希表方式； 文档信息主要包括网页的URL，以及模板的匹配结果； 同样实现了文档信息索引的文件存取，以方便备份； 设计的实现—Page Rank 一个输入“内核编程指南” 怎样能让对输入词组的完全匹配在前面？ ”内核编程指南”作为新词？在本应用中，由于用户输入样本少，挑选新词无法实施。 位置算法。算出单个关键词（“内核”，“编程”，“指南”）在公共页面中的位置，然后计算它们是否属于相连。 在某页面中：如果前两个词相连一次，页面权重+2，前三个词相连一次，页面权重+4，以此类推…… 最后对所有公共页面，对他们的权重进行排序。 设计的实