比如在我们熟悉的搜索，我们搜索的时候如果涉及到一条信息对应多个分类的时候，这样搜索结果会比较差，但是如果我们通过意图识别发现用户是个游戏迷，我们就可以在用户搜索时将游戏的搜索结果优先返还给用户，这本身也是很有意义的一件事。
通用搜索和垂直搜索：
因为垂直搜索已经将用户的意图限定在以特定领域了，因此搜索结果的准确率也很高。那如何在通用领域也能做到了解用户的搜索需求即意图呢？那就需要用到意图识别的技术了。
用户输入不规范，输入方式多样化，使用自然语言查询，甚至非标准的自然语言。比如上面提到的“附近的特价酒店”、“上海到扬州高速怎么走”都是自然语言查询的例子，又如“披星()月”、“吾尝终日而思矣,下面“
用户的查询词表现出多意图，比如用户搜索“变形金刚”，是指变形金刚的电影还是游戏？
意图强度，表现为不同用户对相同的查询有不同的需求强度。比如：宫保鸡丁。宫保鸡丁菜，菜谱需求占90%。宫保鸡丁歌曲，歌曲下载需求占10%。又比如：荷塘月色。荷塘月色歌曲，歌曲下载需求占70%。荷塘月色小区，房产需求占20%。荷塘月色菜，菜谱需求占10%。
数据冷启动的问题，用户行为数据较少时，很难准确获取用户的搜索意图。
没有固定的评估的标准，CTR、MAP、MRR、nDCG这些可以量化的指标主要是针对搜索引擎的整体效果的，具体到用户意图的预测上并没有标准的指标。
1.导航类：用户明确的要去某个站点，但又不想自己输入URL，比如用户搜索“新浪网“
2.信息类：又可以细分为如下几种子类型,
3.资源类：这种类型的搜索目的是希望能够从网上获取某种资源，又可以细分为以下几种子类型,
下载型：希望从网络某个地方下载想要的产品或者服务，比如“USB驱动下载”。娱乐型：用户出于消遣的目的希望获得一些有关信息，比如“益智小游戏”。交互型：用户希望使用某个软件或服务提供的结果，用户希望找到一个网站，这个网站上可以直接计算房贷利息。获取型：用户希望获取一种资源，这种资源的使用场合不限于电脑，比如“麦当劳优惠券”，用户希望搜到某个产品的折扣券，打印后在现实生活中使用。
因为意图识别本身也是一个分类问题，其实方法和分类模型的方法大同小异。
常用的有：
1：基于词典模板的规则分类
一种是基于规则模板的分类方法，这种方法比较适用于查询非常符合规则的类别，通过规则解析的方式来获取查询的意图。比如：今天天气怎么样，可以转化为[日期][实体:天气][询问词:怎么样]上海到曼谷的机票价格，可以转化为[地点]到[地点][机票/车票/火车票]价格
如：236.2美金能换多少RMB？[236.2][美金][今天]能换多少[人民币][数字][货币单位][日期]能换多少[货币单位]
★通过知识图表，来替换/对应/归一解析：数量：236.2源货币：美元（不再是“美金”）目的货币：人民币★配合自己建立的一些语言模型，可以比较好的解决召回率比较低的问题模型训练的比较好的话，相对召回也很不错但是比如购物啊什么的，是无法做这种信息模型的
这种方法的对比较明确的规则性强的方式有精确的识别度，缺点是覆盖度低，用户查询稍作变换可能就不match了，另外规则的发现和制定主要靠人工进行。
2：基于过往日志匹配【穷举】（适用于搜索引擎）
这种方法最简单暴力，通过词表直接匹配的方式来获取查询意图，同时，也可以加入比较简单并且查询模式较为集中的类别。查询词：德国[addr]爱他美[brand]奶粉[product]三段[attr]查询模式：[brand]+[product];[product]+[attr];[brand]+[product]+[attr]当然查询模式是可以做成无序的。这种意图识别的方式实现较为简单，能够较准确的解决高频词。由于query一般是满足20/80定律，20%的query占据搜索80%的流量。但是，80%得长尾query是无法通过这种方式来解决的，也就是说这种方式在识别意图的召回可能只占20%。同时，需要人工参与较多，很难自动化实现。
如：北京的天气怎么样啊（停用词替换）-->[北京][天气][怎么样]（查询词归一）-->{城市][关键词][疑问词]（顺序无关）-->{[城市],[关键词],[疑问词]}
3：基于分类模型进行意图识别
这三种方式基本上是目前比较主流的方法，现在进行意图识别的难点主要是两点，
拿到日志数据，一般是不能直接用的，里面会包含很多的噪声数据，无用信息，我们都需要把它给清洗掉。
角度1：
角度2：
查询意图理解的过程就是结合用户历史行为数据对query进行各种分析处理的过程，包括
语义标签等。【querytagging】
下面这张图是一个具体的例子说明queryunderstanding的工作过程
稍微解释一下这张图：
用户的原始query是“michaljrdan”
QueryCorrection模块进行拼写纠错后的结果为：“MichaelJordan”
QuerySuggestion模块进行下拉提示的结果为：“MichaelJordanberkley”和“MichaelJordanNBA”，假设用户选择了“MichaelJordanberkley”
QueryExpansion模型进行查询扩展后的结果为：“MichaelJordanberkley”和“MichaelI.Jordanberkley”
QueryClassification模块进行查询分类的结果为：academic
最后语义标签（SemanticTagging）模块进行命名实体识别、属性识别后的结果为：[MichaelJordan:人名][berkley:location]:academic
对于英文，最基本的语义元素是单词，因此拼写错误主要分为两种：一种是Non-wordError，指单词本身就是拼错的，比如将“happy”拼成“hbppy”，“hbppy”本身不是一个词。另外一种是Real-wordError，指单词虽拼写正确但是结合上下文语境确是错误的，比如“twoeyes”写成“tooeyes”，“too”在这里是明显错误的拼写。
而对于中文，最小的语义单元是字，往往不会出现错字的情况，因为现在每个汉字几乎都是通过输入法输入设备，不像手写汉字也许会出错。虽然汉字可以单字成词，但是两个或以上的汉字组合成的词却是更常见的语义元素，这种组合带来了类似英文的Non-wordError，比如“大数据”写成“大树据”，虽然每个字是对的，但是整体却不是一个词，也就是所谓的别字。
query纠错的具体方案有：
基于编辑距离
基于噪声信道模型
QuerySuggest模块,也即输入下拉提示
根据用户输入的查询词前缀自动提示用户最有可能输入的完整查询词列表。
这里涉及几个问题：
Suggest词条来从哪里来
如何根据当前的输入快速匹配到候选suggest词条列表
如何对候选suggest词条列表进行排序
suggest词条通常主要来自用户搜索历史querylog，但存在数据冷启动的问题，开始时缺少querylog时如何处理？对于一些垂直的应用场景，比如小说搜索中，suggest词条也可以是作品的标题、标签、作家名等，电商搜索中可以是品牌词库、产品列表等。
在电商搜索环境中，同义词分成好几类：
1.品牌同义词：nokia=诺基亚，Adidas=阿迪达斯
3.旧词和新词：自行车->脚踏车
4.南方用词和北方用词：番茄->西红柿。
5.传统的同义词：储物柜和收纳柜。
6.错别字同义词：瑜伽和瑜珈（错误写为斜王旁）
对应英文来说，还有词干提取，如单复数、动词原形和ing形式；英文还有一个特殊的现象，例如两个单词可以分开写，也可以合并在一起，例如keychain和keychian（钥匙链），boyfriend和boyfriend。
近义词就比较多了：包括size大码≈大号；短裤和热裤；边疆和边疆。
上位词：苹果手机上位词是手机。
反义词：宽松和修身。当我们做query改写的时候，改写千万不能改写出反义词。
如果我们仔细观察，我们会发现有的词可以互相替换，有些词是只能单向替换（换一个方向就不对了，例如周杰伦可以替换为周董，但是周董只能在一定情况下替换为周董）。
如何挖掘同义词？
从点击日志上看，如果w1和w2是同义词，那么搜索w1和搜索w2，理论上会有大量的共同点击的商品x1、x2、x3等等。
标题商品标题得到大量的语料，例如投影仪和投影机，拉杆箱(drawbarbox)和旅行箱(luggage)。
通过word2vec，我们可以找出原始词和最相似的10个单词，然后我们统计origin和substitute（原始词和替代词）在标题中的共现次数，通过这种挖掘，我们找到大量的候选词对，这种词通过人工review可以作为同义词的候选。
对这种情况稍微做一些扩展，我们就能得到同义query到同义query之间的对应关系。
统计分析上位词，统计每个商品类目下的产品词，出现次数topn的产品词w，对应到商品的类目词c，那么w->c很可能就是一个上位词关系。
1、计算两个query的编辑距离
2、计算两个query（x和y）在session中的互信息，PMI(x,y)=p(x,y)/(p(x)*p(y))
3、协同过滤
4、稀疏
由于点击数据受到搜索结果的影响，由于排序质量的问题，点击的位置bias，有很多办法来纠正；以及部分Query的点击比较稀疏，商品的点击比较稀疏。
另外github上面有两个代码：
5、用商品向量来表示Query，也有一些方法借鉴了simrank和向量的思想，用词向量来表示Query和Title。
例如yahoo研究院的这篇论文《LearningQueryandDocumentRelevancefromaWeb-scaleClickGraph》。
把Query先和Title先分别用wordhash到一个3万维的空间，然后一层层embedding到一个128维的向量，最后可以简单的用cosin来计算相似性。
Wetestedvectorspaceswithvaryingdimensionalities(dim=100/200/300)andnumberofcontextwords(win=3/6/10),aswellasminimumoccurrencecutoff(min=1/5),negativesamples(neg=1/5)anditerations(iter=1/5).Thesevariationsweretestedtoensuretheobservedpatternsreportedintheexperiments,butwereportnumericalresultsonlyforbestperformingmodels.Inparticular,higherdimensionalvectorswithdim=300producedconsistentlybetteralignmentwithhumanscoringdata.Wealsofoundmin=1,neg=5anditer=5tobetheoptimalparametersettingsacrossallexperiments.
8、目前图计算有很多方法。
我们尝试了用node2vec的方法来计算Query的相似性，也取得了非常好的效果。即把query和item的二部图上面做node2vec。
搜索日志会话局部上下文是指与当前query在同一个会话上下文中的共现query,也是用户对query的查询重构，比如初始query为“变形金刚”，用户在查询会话中可能将query变换为“变形金刚电影”进行搜索，则“变形金刚电影”为原始query的局部上下文。
query的全局上下文挖掘思路：
根据查询词和查询所点击的结果构建二部图，利用随机游走模型计算出每个查询词的文档分布作为查询词的查询向量，再利用KL距离来计算两查询向量之间的相似性。
在关键词做类目预测之前可以做一个预处理提高准确率。如query归一化、纠错、去除价格区间词、中英文翻译对照等等。
通常有基于规则模板的分类方法和基于机器学习的分类方法。
1、一种是基于规则模板的分类方法，
这种方法比较适用于查询非常符合规则的类别，通过规则解析的方式来获取查询的意图。比如：今天天气怎么样，可以转化为[日期][实体:天气][询问词:怎么样]上海到曼谷的机票价格，可以转化为[地点]到[地点][机票/车票/火车票]价格
2、另一种是基于机器学习分类的方法。
如果有确定的查询类别体系，基于机器学习的查询意图分类是一个不错的选择，可以选择SVM作为分类器，关键在分类特征的选择,还有训练样本的准确标注。
这个和我们之前参加过的2014ACMCIKM竞赛的问题类似，那年CIKM竞赛的题目是自动识别用户的查询意图（QueryIntentDetection，QID）：给定一批标注过类别的搜索日志包括查询日志和点击日志作为训练样本，其中也有部分未标注的，类别为unknown。
在特征的选择方面，除了基本的Query的长度、Query的频次、Title的长度、Title的频次、BM-25、Query的首字、尾字等，我们通过对logsession上下文的分析，进行了Query间特征词汇的挖掘，运用了query在相同session中的共现关系，挖掘query之间的子串包含关系，query和点击的title之间的文本特征关系等。
在分类模型的选择方面，我们选择了Ensemble框架。Ensemble的基本思想是充分运用不同分类算法各种的优势，取长补短，组合形成一个强大的分类框架。不过Ensemble不是简单的把多个分类器合并起来结果，或者简单将分类结果按固定参数线性叠加(例如不是a1*ALGO1+a2*ALGO2+a3*ALGO3)，而是通过训练Ensemble模型，来实现最优的组合。
在Ensemble框架下，我们分类器分为两个Level:L1层和L2层。L1层是基础分类器，L2层基于L1层，将L1层的分类结果形成特征向量，再组合一些其他的特征后，形成L2层分类器（如SVM）的输入。这里需要特别留意的是用于L2层的训练的样本必须没有在训练L1层时使用过。
这个模块主要是对query中的命名实体进行识别，比如对电商搜索query中的品牌词、产品词、属性词、地址进行识别。对query，用一个相对准确的词典(品牌词/产品词/属性词/地址词)去标注语料。
比如对于”新西兰安佳奶粉二段“标注语料如下所示：新B-loc西I-loc兰I-loc安B-brand佳I-brand奶B-product粉I-product二B-attr段I-attr实体词识别模型可以通过crf来进行训练。
至此，第二部分如何识别用户搜索意图也讲完了总结一下，我们首先简单说明了用户搜索意图的主要分类：导航类、信息类、资源类，然后对搜索意图识别的主要功能模块查询纠错、查询词自动提示、查询扩展，查询自动分类、语义标签等实现思路分别进行了介绍。
中文自然语言处理的第一步就是分词，分词的结果中，每个词的重要性显然应该时候区别的。TermWeight就是为了给这些词不同的打分，根据分值就可以判断出核心词，进而可以应用到不同的场景。比如，有一个商品的标题为“碗装保温饭盒套装”，通过TermWeight可以得到核心词为“饭盒”。当用户搜"碗"召回这个商品的时候，是可以根据termweight来进行排序降权的。
把上面扩展得到的查询文档利用tfidf向量化，就可以得到一个特征向量，一般情况下，这个特征向量维度会非常高，我们可以利用词频、卡方、互信息等方法进行特征选择，保留更有用的特征信息。我们还可以加入一些数字特征在里面，例如：（1）Query的长度（2）Query的频次（3）Title的长度（4）Title的频次（5）BM-25（6）Query的首字、尾字等
对logsession上下文的分析，
进行了Query间特征词汇的挖掘，
运用了query在相同session中的共现关系，
挖掘query之间的子串包含关系，
query和点击的title之间的文本特征关系一些统计特征也可以考虑，例如论文【2】提到的不同页面点击数DPCN（DifferentPageClickNumber）、异源页面点击数PCNS（PageClickNumberwithoutSubpage）等，其中：（1）不同页面点击数DPCN，表示用户对查询串的返回结果的点击情况统计，因为作者统计发现对于导航类查询，用户目标很明确，通常只点击一两个网页就完成查询了，而对应信息事务型则点击的不同页面数目比较多，例如作者统计显示当不同页面点击数不大于7时，查询串中导航意图的占66.7%，大于7时，信息事务意图的占83%。（2）异源页面点击数PCNS，表示查询串的返回结果中，以点击频次最高的网页为基准，不同页面点击数与其子页面数量的差值。例如对于某个查询串w，不同页面点击数DPCN为17，而点击频次最高的网页子网页出现了15次，那么异源页面点击数就为17-15=2，这样做的目的是为了消除将同一网页的子页面算成不同页面的情况。
在完成特征任务后，接下来就是选择合适的分类器进行训练了，因为意图识别可以看作是一个多分类任务，所以通常可以选择SVM、决策树等来训练分类器。
先说一下Query分析。
最下层词语，比如说搜索五道口附近的钢铁侠3，最上面就会做一些成分识别。
成分是根据业务制订的一些标准体系，比如说五道口是一个地址的核心词，附近其实是地址的修饰词，钢铁侠3其实是店的核心词，店可以理解成商家的产品，比如说电影院里面某一个电影。
再往下就是结构、主体和泛化可做的东西比较多，比如说做一些拓展，五道口可能有华联等等，这个现在是基于图谱来做的。
其实，这个用处非常多，比如说举个例子，就是望京华联搜这个可能出不来结果，但如果做一个扩展之后就可以很顺利的找到它想要的一些结果。
从图谱方面的一些东西可以很好的应用。从内容方面的话，比如说钢铁侠3有一些相似的电影等等，这个其实也是我们的一些泛化。
再往上会对Query做一些概念的识别，主要是电影。
以Query意图识别做为例子。说一个Query，我们对它的类别做一个判别，比如动物园门票就是旅游，全聚德和望京是美食。我们可以分成不同的类别，这些类别有美食、电影、酒店之类的，还有很多二三级的品类。
说到这个场景之后，其实大家脑子里就可以想到这个事情怎么来做。
Query意图识别可以转换成机器学习多分类的问题。机器学习对一个问题有一套标准的流程，做过机器学习的都知道。首先要对问题做一个分析，要分哪一些类别，根据现状制定一个目标。现有数据的支持是否有一些标注的辞典、数据等等，根据这个再来整理数据，比如说如果标注数据不够怎么办，后面会做一些介绍。特征工程需要抽取很多特征，特别是你要考虑到O2O的一些特点，需要做一些事情。特征做完之后再做模型方面的一些选择和分析，最后做一些线下的评估，然后在线上镶嵌看它的效果。这个流程是非常通用的。
摘出几点，有可能和其他地方不太一样的地方做一个介绍。首先就是训练样本怎么获取，这个其实比较难，第一种是人工标注，第二种就是自动标注。思路有几种，可以通过主动学习用模型学习，它的执行度比较高的，作为它已经有了，区分比较低的再来标一下，这样标注的样本量就非常多。还有Query的思想其实也是来扩充执行度比较高的样本作为它的标注数据。
第二个问题就是特征设计，我们会把Query的一些语义的特征，Query扩充的一些信息也会融进来。说一下不一样的，我们Query是有地域区分的，例如黄鹤楼，可能在北京搜更多的是一个酒店饭店；但如果在武汉搜的话，其实就是一个景点。模型尝试的话，（PPT图示）右边就是精准化简单的图，中间两层还做了文本分类的模型。
最后再说一下整体的流程。我们的分类目标就是定一些品类体系，用的话，可能就是在流量分发、统计到排序里面会用；现状有一些辞典的，解决思路其实就是想通过机器学习的方法来解决。数据准备刚才已经介绍了，特征工程也说了一下，最后用DN加很多点，在线上我们在旅游产品上线可以提升5%的水平。
对query的线上处理，如果是较为hot的query，可以以查表为主，可以用hash表，trie树等进行查表，把在线下计算好的数据，通过查表的方式找到对应的结果，附加到给引擎的搜索条件上，并返回。
另外，可以把线下训练好的模型，在线上进行预测，一般的分类算法预测速度都比较快。可以对长尾的query，进行及时的预测。
也可以做一些规则，如我们上面举的例子，“1000元左右”，可以通过正则表达式进行识别，将其转为对应的搜索条件。这些规则如何来定呢，这是比较麻烦的一点，像这类的query，肯定是pv比较低的，属于长尾的query，这些query效果提升可能比较明显，但是对总体搜索系统效果影响会较小。这个问题比较尴尬，如果我们这类query处理的效果好的话，那用户会使用的更多；用户知道了这样的query效果不好，所以就换成了效果好的query。如果要做好规则，那就把长尾的这些query都拿出来，多看看，分下类，再结合实际的问题分类，总结出一些通用的规则，来进行优化。