查询词聚类技术综述

搜索引擎中的查询词聚类技术有如下应用场景：

• 应对搜索结果mismatch，即零少问题，尤其出现在长尾query中
• 挖掘用户查询意图

 

对于现存查询词聚类技术，有2个基本的思路：

• Content Based， 即两个查询词包含相同的term。
• Session Based， 即两个查询词出现在相似用户的一系列行为中。

 

这2种方法各有优缺点，且各有各的适用场景。总体来讲，Content Based聚类技术往往能将形态相似的查询词聚类在一起；但是实际上包含相同意义的查询词往往有着不同的term形态。与之相比，Session Based聚类技术倾向于将同一主题的查询词聚在一起；但是一个session里往往包含了很多用户行为噪声数据，因为在一个session里用户的关注点和兴趣点可能有多个。所以这2种方向在现实应用场景会被结合着使用。

 

【Content Based聚类技术】

Content Based计算查询词相似度可以简单地表示成如下数学公式(1)：

 

其中，kn(.)代表一个查询词中的term个数，KN(q1, q2)代表2个查询词中相同term的个数。

 

假设查询词中的每个term都是有weight来标识的，那么相似度计算公式可以演变成余弦夹角公式(2)：

 

其中，cwi(q1)代表第i个公共term在查询词1中的weight，wi(q1)代表第i个term在查询词1中的weight。

 

Content Based还能扩展到短语级别(Phrase)，即term由phrase替代。比如查询词“history of China”和查询词”history of the United States”通过term级别的Content Based来计算相似度，只有0.33(去掉of the等停用词后)。但是把”the United States”看成一个phrase来计算相似度，那就会提升到0.5。

 

第3种Content Based聚类技术是基于keyword级别的。该方法将通过变化查询词1到查询词2的过程中，经历的步长(step)看成2个查询词直接的编辑距离(变化包括：插入一个term，删除一个term，替换一个term这3种操作) (3)：

 

其中，edit-distance(q1, q2)代表从查询词1变化到查询词2所需的最短步长。

 

与term级别的Content Based聚类不同的一点是，keyword考虑停用词。所以这种方法的好处是不会忽略掉一些有用的停用词，比如“who”、“where”，下面3个查询词将会被聚为一类：

 

 

第4种Content Based聚类技术被称为Character级别的聚类，其实就是一种拼写纠错技术，因为前面3种非Character级别的Content Based聚类技术都无法解决拼写错误问题，比如keyword级别的Content Based会把拼错一个字符的2个查询词看成编辑距离为1，所得到的相似度就有可能是小于1，而在Character级别Content Based看来相似度就是1。

 

【Session Based聚类技术】

考虑到Content Based聚类技术的缺陷：比如对于短的查询词效果不佳，无法识别语义上相关、形态无关的查询词，Session Based通过捕捉用户意图，则可以较好地弥补这些缺陷。通过积累的海量用户日志(Query Log)，可以挖掘出一批具有这些特质的查询词。

 

当然Session based技术有个很重要的前提假设就是，同一session里用户的点击行为都必须是相关的，一旦出现用户错误地点击了文档，或者在期间变换了搜索兴趣，则意图的相关度就不那么准确了；此外，top rank的文档拥有大部分点击，所以一旦top rank的文档之间相关性很差，则同样使Session based聚类产生偏差；所以越丰富越准确的海量用户日志有助于克服个别的噪声点击。

 

用户Session日志的挖掘有赖于搜索引擎所记录下的用户访问信息，尤其是带Cookie ID的用户访问信息。以下是个Session日志的样例，表(1)：

 

该样例包含了用户Cookie ID、访问时间戳和查询词地址(URL)。

 

整个抽取过程包含2步：

1.     用户识别

2.     Session识别

 

用户识别就是将日志信息，根据不同的Cookie ID划分开来，当然IP也可以作为用户识别的一个标志，但是考虑到IP本身的可信度，以及代理服务器、本地缓存、防火墙改写等因素，Cookie ID作为用户识别的标识较于IP更为准确。还有一种方案是用User ID来识别用户，它比Cookie ID更为精准地识别用户，但是很多场景下用户不需要登录，甚至注册就可以操作网站进行搜索，所以作为识别域，其量过于稀疏。

 

Session识别的目标是根据时间来切分出同一个用户下的连贯行为。最简单的方法就是根据超时时间(timeout)，一般来讲大部分网站都默认设为30分钟。也就是说从用户第一次访问网站的30分钟之内的操作都可以视为是一个session。

 

第1种Session based聚类方法是通过计算两个查询词下点击的相同文档的个数来考量相似度的，公式(4)如下：

 

其中，dn(.)代表一个用户查询词1下点击的文档个数，DN(q1, q2)代表一个用户在查询词1、2下共同点击的文档数。比如用户在搜索引擎中搜索“原子弹”与“核武器”这2个词，用户很有可能点击了这2个词都检索出来的有关原子弹的文档。但是如果用户搜索”Java”和”Java Island”则很大程度上不会点击相同的文档，因为一个代表Java编程语言，而另一个是太平洋上的一座岛屿。

 

但是假如用户搜索了“曼哈顿计划”和“原子弹”这2个词，很有可能用户在“曼哈顿计划”下点击了“美国历史：曼哈顿计划”这样的文档，而在“原子弹”下只点击了“原子弹：维基百科”这样的文档。那怎么将这2个查询词聚在一块儿呢？

 

要解决这个问题，那就需要将查询词聚类和文档聚类结合在一起看了，如图(1)所示：

 

其实在文档空间内，“原子弹：维基百科”可以和“美国历史：曼哈顿计划”看成是一类文档，那么不同的查询词最终点击到这2篇文章后，在查询词空间内是否也可以看成是一类查询词。对于这种结合的方案，也有2种流派：单向聚类和双向聚类。

•  单向聚类

一种直接的方法就是当用户通过“原子弹”搜索，造成了“原子弹：维基百科”的点击，而通过“曼哈顿计划”造出了“美国历史：曼哈顿计划”的点击之后，考察“原子弹：维基百科”和“美国历史：曼哈顿计划”这2篇文档是否在一个文档簇里面，如果是，则认为点击了同一篇文档，Session Based的公式(4)仍旧有效。

细致点的做法就则是将2篇点击的文档之间的相似度分值作为查询词相似度计算的一部分，如公式(5):

 

其中s(di, dj)代表文档i和文档j直接的相似度，di和dj分别代表查询词1和查询词2带来的点击文档。假设，“原子弹：维基百科”和“美国历史：曼哈顿计划”这2篇文档的相似度为0.5，且是2个查询词各自点击的唯一文档，则根据公式(5)，它们的查询词相似度也为0.5(0.5 = (0.5/1+0.5/1)/2)。

•  双向聚类

文档本身的聚类手段会参考海量的文档内容数据来进行，计算量惊人。但是与单向聚类思想类似，文档之间的聚类也可以参考来自不同查询之间的相似关系。假设大量用户在使用同样的查询词后都点击了同样的一批文档，那我们可以肯定地认为这批文档是非常相关的。这种思想在Amazon的书籍推荐和Citeseer的论文引用中已经应用到了。也就是说，文档的聚类可以借鉴查询词空间的相似度，查询词的聚类也可以借鉴文档空间的相似度，两者可以互为因果，相辅相成。

具体算法，参见二分图(2)：

 

左侧节点代表查询词，右侧节点代表点击过的文档，中间的连线代表通过左侧哪个查询词造成了右侧文档的点击关系。

 

这种算法是一种迭代式聚类过程，每个迭代周期里，查询词聚类和文档聚类都会被触发，但是过程是交错进行的。第一步合并2个相似的查询词到一个查询词空间里，第二步合并相似的文档，重复一、二步直到图上每个节点都至少有个连接。上图(2)就代表一个迭代过程的终止态。

      使用双向聚类，可以将文档聚类从内容计算中解放出来，所以非常有应用价值。但是这种迭代的做法，同样也会积累噪声和异常值，还有终止态的确定的规则是什么？查询词的相似度，比文档内容本身信息计算出来的相似度就更可信么？这些都是悬在双向聚类领域上的乌云，有待验证。

 

Session中的查询词共现是Session Based的第3种聚类方法。看表(2):

 

其中WW2和second war，world war 2都出自一个session日志中，变称之为共现。甚至再严苛一些，我们认为连续的搜索行为暗示性更强。当然这种方法同样也面临如何从一个用户日志中切分出完整的一个session行为。

 

讲完了Content Based和Session Based这两大聚类方法，相信聪明人不难发现可以简单地把两类方法的成果结合使用起来，比如通过公式(6)：

 

给Content Based和Session Based两种聚类方法计算出来的相似度各赋一个权重。当然α和β的取值还需要根据不同的数据和应用场景去探索合理的范围，在这里暂且不表。

 

最后还是要提几点应用中的注意事项：

• 当用户日志海量时，计算成本随之增加，需要合理地过滤不必要的计算量来优化算法。
• 很多数据都是每日更新的，每日的增量是合并到过往的全量数据中，还是做成日快照一日一计，需要依据场景规划。
• 低频、长尾的查询词不是聚类的重点。