• 搜索引擎(3)——查询理解——不可省词


    1. 倒排求交

    上一篇讲了分词。对用户的query分词之后,得到了一个个独立的词(term)。先设想一个问题,用这些词去索引里搜索时,是不是doc命中query中任何一个term,都可以被搜索出来?(query中只有一个term除外)

    这里涉及好几个问题:
    1. 截断:例如query是5个词ABCDEF,如果只命中F的doc也搜索出来,那用户看起来可能会觉得这个结果相关性太差,与自己想要的结果差太远。所以,需要根据相关性的强弱做个截断,只保证相关性强的结果。
    2. 性能:如果命中ABCDEF中任何一个term的网页都召回,那召回的网页的数量会非常之大,再对每个网页计算得分、排序,性能会非常差。

    基于上述2个原因,一般底层检索时都会做倒排求交。即先取出多个倒排拉链,再对这多个倒排拉链求交集。例如上面的ABCDEF,先取出命中A的doc(假设有1万个),再取出命中B的doc(假设也是1万),那这两个doc集合的交集,可能只有5000。一般交集的数量会远小于并集数量。

    底层搜索一般会分两步:1)倒排求交,2)在求交后的链接集合上,做打分和排序。

    2. 不可省词与可省略词

    用多个term去取拉链求交不麻烦,难的是选几个、选哪些term去做倒排求交。选的不好,会导致结果相关性和性能都很差。

    例如query=北京的天气怎么样,如果取“的”和“怎么样”去做倒排求交,那他们召回的数量会非常之多,计算量巨大,且召回的很多结果都没有命中“北京”和“天气”,结果相关性很弱。这个例子中,可以选“北京”和“天气”去做倒排求交,这2个词可以称为不可省词,“的”和“怎么样”是可省略词。

    具体如何选择不可省词?

    2.1 基于IDF

    一种最简单的方法是基于IDF排序。

    IDF,逆文档频率,描述的是一个词在整个库中是高频词还是低频词。例如像“的”,“了”这样的词,汉语中使用的非常之多,必然会出现得非常多,它的IDF就会很低。而像“倒排”这个词,就有点偏专业小众了,偏向于低频词,IDF会比较大。

    以“北京的天气怎么样”为例,IDF从大到小的排序,可能是:“北京”>“天气”>"怎么样">“的”。再将IDF大的选择几个做为不可省词。具体选择几个,可以通过一些规则或经验调试。

    基于IDF的方法,优点是简单易实现,缺点是准确率不太高,badcase较多。

    2.2 基于日志挖掘

    用户的搜索和点击日志,可以挖掘出很多有价值的信息。

    例如,两个不同的query,搜索结果几乎一样。则这2个query中同时出现的词,就可能是这2个query中最重要的词。可以理解为,2个不同query中,最重要的词,都一样,所以这2个query的结果相似度非常高。

    例如用户搜索“北京天气”和“北京天气怎么样”这2个query,结果应该是高度相似的,原因就是2个query的不可省词都是北京天气。

    另一种情况,2个不同的query,用户的点击结果一样。则也可以认为2个query中同时出现的词是重要的不可省词。

    基于日志挖掘的方法,准确率还可以,缺点是覆盖率可能不全,用户之前从未搜索过的query,第一次搜索时,不可省词无法通过日志挖掘出来。

    2.3 基于模型

    除了基于IDF和日志挖掘,也可以做一个二分类模型,来判断query中的每个term是否是不可省词。

    不可省词肯定会有些共性的特征。模型的方法最核心是特征的设计和选取。可以想像下,一个词是否是不可省词,有哪些影响的因素?例如这个词在句子中的位置,词性,IDF,历史搜索次数,与前后词的句法关系,query的句法类型等等。分类器的选择,SVM、RF等等,区别可能不是太大,更主要还是特征。

    模型可以考虑更多的特征,但是需要人工标注一批训练样本,才能训练出可用的模型。

  • 相关阅读:
    String,StringBuffer和StringBuilder的异同
    博客迁移到reetsee.com
    一个好用的打印插件,功能强大
    html5中使用标签支持视频播放
    Extjs4 中在指定光标处插入值
    Javascript 创建对象方法的总结
    JS中的prototype
    在JS方法中返回多个值的三种方法
    JS ready和onload事件 比较分析
    JS中的“!!”
  • 原文地址:https://www.cnblogs.com/grindge/p/12241855.html
Copyright © 2020-2023  润新知