搜索，亦称之为查找。查者，考察也；找者，以手拾戈，选择也。

在很久很久以前，当大家交流全靠吼的时候，兵器库中仅有少量的兵器，王让侍卫去取，侍卫取来了所有；慢慢的，收获慢慢变多，兵器库慢慢丰富，王让侍卫去兵器库取，侍卫去取所有合格的；到后来，兵器库中已经堆满了兵器，王让侍卫去取最漂亮的，侍卫取来了王所钟爱的。简单来说，搜索就是侍卫，把兵器库中的所有信息都掌握住，当王提出自己的要求时，能以最快的速度给出最准确的结果。

背景

如上面的故事一般，互联网世界中搜索引擎的发展也和信息量息息相关。 早期的搜索引擎把互联网中的资源链接（URI）收集起来，按照类型的不同分组，供网民进行资源搜寻，表现形式为网址导航等。 然而，随着互联网信息几何增长，导航式的查询方式已经慢慢让网民们开始挣扎：不知道要找的东西哪里有，也无法浏览这么多的网页。在这迷茫时刻，真正的搜索引擎应运而生。它以文档（Doc）作为存储单元，以词元（Term）作为查询单元，用户只需要在搜索框内输入查询词（Query），搜索引擎就可以查找出所有符合条件的文档。 通常来说，全文搜索已经能够满足大部分用户的需求。但是，侍卫服侍的王可能明察秋毫，也有可能不分五谷。那么，作为一个合格的侍卫，需要掌握的不仅仅是服从命令，还需要能够准确抓住王的想法，这就是我们今天所讲内容——用户意图识别。

用户意图识别

用户的意图总的来说可以分为两大类：精确需求和泛需求。对于目的性很强的用户来说，他明确的知道自己想要的是什么，需要搜索引擎返回他想要的东西，越匹配越好，比如搜索 “战狼 2 预告片”。对于另外一部分用户，他可能并没有那么强的目的，比如闲来无事想看电影，会去搜索 “电影”；或者带上自己的喜好，会去搜索 “国产电影”；也有可能只是一只小白，并不知道自己要找的是什么，只能通过描述表达，比如搜索 “吴京的新电影”。 识别用户的需求可以从三个角度去考虑，第一个角度是理解用户查询词（Query Undertanding），第二个角度是评价页面内容（Doc Scoring），第三个角度是评价查询结果匹配度（Matching）。

本文将从 Query 理解的角度来聊聊怎么识别用户的需求。

用户搜索调查

用户的搜索行为是没有约束的，带来的后果是 Query 的不规范。在这里，我们以一些典型的搜索词为例，分析用户搜索的意图。

• “上海徐汇暑期家教”：这个 Query 的主体是 “暑期家教”，需要定位到上海徐汇附近

• “四轮托车”：这个看起来是一个精确需求，但是却不是一个正确的查询 Query。猜测用户可能的查询需求是 “四轮拖车” 或者 “四轮摩托车”

• “三轮车司机”：这是一个精确需求，是用户在寻找一个 “三轮车司机” 的工作。但是从数据角度来讲，发帖招聘的人可能发布的是 “三轮车驾驶员”，因此需要 “三轮车司机” 和 “三轮车驾驶员” 并行地去查找

• “6.8”：这是一个特定词，是指厢式货车的厢长。在这种情况下，我们需要在有条件的情况下定位，将 Query 限定为货车条件下的 “6.8”

• “sijihuayuan”：这是一个输入错误，猜测用户可能搜索的是 “四季花园”

识别措施

上面我们分析了用户的一些搜索词，针对以上的一些情况，我们给出以下应对措施。

• Suggestion，Query 提示模块：这个模块会在用户输入少量词的时候，推荐一些比较常见热门的搜索词，一方面可以让用户更快速的输入，另外一方面减少了用户的输入错误

• Extension，Query 扩展模块：这个模块会根据用户的 Query，帮用户识别出拼音、拼写错误等，给出最可能的搜索需求；也可以识别出同义衍生的词，扩展出一些同义词的查询

• Classification，Query 分类模块：由于一些词汇具有比较强的倾向性，可以在识别之后将 Query 划归到某个类别，从而限定在这个范围内进行搜索

• Association，Query 联想模块：实际上，很多时候 Query 中会包含一些命名实体（Named Entity），而往往这些命名实体和后面的一些语义可以把比较泛的搜索需求转变为比较强的精确需求，这个模块可以联想出具体的查询条件并进行扩展

本文中，我们将简单讲 Extension 模块的实现方案。

Extension

同义词模块 —— synonym

同义词指的是具有相同含义或者相同指代的词语对，一般来说是等位的，比如在生活中比较常见的：司机等同于驾驶员，驾驶本等同于驾照。但是还有一部分词在某些特定条件下同义，比如阿姨和保姆。

在百姓网的实践中，同义词是按照城市和类别两个维度来进行限定的，要进行同义词扩展首先要定位到具体的城市、类别下。在技术实现中，同义词的命中使用的是 Aho–Corasick（https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm）算法；同义词替换的前提是保留足够多的原始信息。

另外，同义词的词典建设也是一个比较需要关注的事情。除了一些基础的同义词典之外，有两种方案可以用来生成自己的同义词词典。一种方式是根据线下的语料利用相关技术如 word2vec（https://en.wikipedia.org/wiki/Word2vec）等进行训练筛选，另外一种则是根据用户 Query 输入和点击行为进行识别。

拼音模块 —— pyconvert

拼音识别是指识别 Query 中正确拼写的拼音，并将拼音转换为相应汉字的过程。通常来说，用户的 Query 中出现的拼音的情况中，整个 Query 都是拼音的情况比较多，但不排除有汉字、拼音混合的情况。在第一种情况下只需要直接进行识别，第二种情况下则需要考虑把汉字作为限定的条件。

在百姓网的实践中，拼音识别采用的是 Hidden Markov model（https://en.wikipedia.org/wiki/Hidden_Markov_model）模型对离线语料进行训练，获得相应模型。在查询时，模块对 Query 中的拼音进行识别、提取、切分，代入模型获得推荐的 Query。由于在输入中拼音不会带上声调，而汉字拼音的总数量并不多，所以一般拼音都会给出多种推荐 Query。要保证拼音推荐的质量，除了特定的离线训练语料之外，热门 Query 通常可以带来一个比较好的结果。

纠错模块 —— correction

虽然有智能输入法的辅助，用户能够大幅度地减少输入错误，但是之前做的一份统计分析表明，约有 3% 左右的 Query 存在拼写错误。进一步的研究发现，因为拼音相同而出别字的概率比较高，因地域拼音模糊而出错的概率次之，因认错字而出错的概率最小。

在百姓网的实践中，纠错采用的是 Levenshtein distance（https://en.wikipedia.org/wiki/Levenshtein_distance）算法，获取编辑距离最小的备选 Query。另外，一点点改进措施是，利用出错和拼音相关这一特点，计算编辑距离时采用加权的思想，对于拼音相同、相近、无关等尺度分别赋予不同的权重，最终得到的编辑距离更为客观。

实际上纠错模块的质量和线下的纠错词库息息相关。纠错词主要有两个来源，一个是 Query 计算得到的热词，一个是对文档数据计算得到的高信息熵的词。前者负责预测用户更可能的输入是什么，后者倾向于探求用户希望搜索什么内容，把握好这两块就可以得到一份优秀的纠错词库。

总结

用户是王，作为侍卫的我们需要竭尽所能去理解王之意图，不仅要覆盖到王之意图的方方面面，更需要理解到王之意图的关注所在，这就是我们的追求。

本文仅为作者个人观点，不代表百姓网立场。

（题图来源：Pixabay）