query聚类
目的
query聚类主要有以下两个目的
解决query空间稀疏问题（长尾query）
挖掘用户意图（一条行为包含的意图是稀疏的，当有一簇行为时，意图更明确）
可以说聚类是构建内容模型的重要手段
Content Based聚类
Content based聚类基于query本身，即两个query包含相同的term。优点是可以将形态相似的query聚到一起，但是会遗漏掉意图相同但query形态不同的query。精度高，召回低
Session Based聚类
Session Based聚类基于用户行为，即两个query出现在相似的行为中（用户，点击url，点击title）。优点： 可以将相同主题的query聚到一起；缺点： 用户行为噪声，容易出badcase。
Session Based方法基于Query Log的两个假设：
同一session里用户的意图相关；
top rank文档的相关性好；
从用户访问网站开始每30分钟算一个session，这样构建起来的query-url链接更稠密一些。
注： 如何识别一个用户？
可以利用的信息有：IP、COOKIE、USER_ID、MAC、IMEI、账号打通。
通过挖掘QueryLog，得到一组日志：
SessionID、 UserId、 TimeStamp、 Query、 URL
通过Jaccard距离度量两个query点击url相似度来表征query之间的距离，也即：
容易看出，上式的值域是[0, 1]，是归一化的。
以上方法仍存在文档空间稀疏的问题，需要将query聚类和文档聚类结合起来。
最直接的方法是利用先验知识（文本理解），将文档以簇粒度表示，描述长尾的能力大大加强。但是海量文档聚类，计算量也是很可观的。
另一种方法是二分图的方法（simrank），基于行为，同时进行query聚类和文档聚类。这样，就把文档聚类从内容计算中解放出来了（经验表明，搞文本是最吃力不讨好的事情，组里从query-title出发构建embedding效果不佳，做项目，不应该上来就搞复杂、不可解释的模型，实在是应该先把简单的点击信息抓到，用好，词级别的聚类是不好的，利用行为，进行query-url级别的聚类才是可取的）。
当然，二部图方法仍然有累计噪声、迭代停止条件和相似度置信度的问题。