​心法利器[34] | 报告小结：query理解概述

心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

近期，我再次总结了我的历史文章，累积起来有50w字，百余篇文章了，有兴趣可以拿来看看，获取方式：七夕清流，百余篇累计50w字文章合集发布。

往期回顾

心法利器[29] | 把文本分类任务做成一个系统

心法利器[30] | 算法新人如何在工作中成长

心法利器[31] | 我的算法工程师日常

心法利器[32] | 一些印象深刻的bad case

心法利器[33] | 快速的关键词抽取baseline

昨天已经预告了我会的第一次直播的报告（尝试性地做一次公开分享），这次直播的报告下来，我自己的感觉讲的还行，收获的评价也挺好的哈哈，应大家的要求，我总结一下内容，弥补一些小伙伴没有看到直播的遗憾吧。依旧是建议大家能来看直播，毕竟有一些互动和讨论，欢迎大家参加~

分享的相关链接在这里：直播PPT：/km1994/TopicShare/blob/main/Topic8/QA/%E5%AF%B9%E8%AF%9D%E5%92%8C%E6%90%9C%E7%B4%A2%E4%B8%AD%E7%9A%84query%E7%90%86%E8%A7%A3%E6%A6%82%E8%BF%B0.pdf

直播录屏在这里：/share/init?surl=A_GtJTI3Sk7m0UotBvXy3Q，密码：tn9k

懒人目录：

query理解的背景。

对话搜索的结构。

流程和任务。

常用方案。

调优思路。

那么我来一个个讲吧。

背景

query理解我的感受很大程度上他就是NLP非常大的落地场景，而NLP，本质即使这个L，即语言，语言的本质是信号的传输，目前搜广推领域都大量需要，毕竟需要把信息传递给用户，其中最广泛使用就是搜索了，大部分的搜索都离不开用户输入的Query，这就是Query理解的本源，值得展开的是，搜索不仅只有大家常规意义理解的百度或者谷歌这种开放域的大搜，还有一些垂直领域的搜索，例如音乐软件里面搜音乐，外卖软件里面搜外卖，笔记软件里面搜笔记等等。

另一方面，同样是由于NLP技术的长足发展，人机对话的能力逐步增强，各种领域都有落地相关的产品，类似siri的智能助理，淘宝京东里面的客服咨询，很多医疗产品中的智能问诊等等，这些都是重要的落地场景。

而要完成对话，或者说要机器给出正确的回应，首先应该要保证的就是要理解用户说的是啥，query理解就是干这个的。

搜索与对话的技术架构

我感觉在展开讲query理解之前，还是应该知道对话系统或者是搜索系统整体的架构是什么样的，借助这个架构来了解query理解深层次的意义，或者说，下游需要query理解给出什么东西才能进行处理，这个更有利于我们设计好query理解。

来看3个例子吧，腾讯搜索、微软小冰、平安人寿智能问答。

腾讯搜索

一张图能够完整给我们展示腾讯搜索所涉及的技术和流程。

Client是客户端，大家可以理解为各种入口，除了我们常见的输入框之外，直达、sug、相关推荐等其实都可能会进入到搜索接口中，在搜索接口内的处理中心就是AS，即高级检索，高级检索里面包含了query理解、基本检索（BS）、排序等核心流程。

Query理解，就是我们讲的核心，预处理、拓展、纠错等。

检索召回，核心是文本/字面检索和语义/向量检索，当然这里底层需要各种数据库支持。

排序。结合各种特征，来对召回的结果进行排序。

除了在线模块，还有一些离线的模块，这些内容一个是耗时比较多，另一个是没必要在线重复计算，这种就可以离线完成，例如日志的处理、用户画像构建、模型训练等等。

涉及的链接：

全面理解搜索Query：当你在搜索引擎中敲下回车后，发生了什么？：/p/112719984

前沿重器[4] | 腾讯搜索的Quer理解如何直击心灵：https://mp./s/szWUDvzvqWk0M5hQlY6Igw

微软小冰

微软小冰应该是比较早起步且做的比较好的一款产品了，尤其是他在情感、多轮上的成就，有关论文其实已经给出一些技术方案的思路，在落地和实施上应该就没有那么地摸黑前行了。

可惜的是对整体架构微软小冰的论文没有给出非常完整的介绍，只是给了概念图并介绍了基本的组件，他们之间的协同其实没有很完整地介绍，不过也足够我们理解和吸收学习了。

整体分为3大结构，用户体验层、对话引擎层、数据层。

用户体验层：主要用于获取用户的请求，各个渠道的，如微博、微信、操作系统等，需要对用户输入的内容进行各种处理（甚至包括ASR之类的技术）。

对话引擎层：这一层是对话最关键的一层，包括核心对话单元、技能单元、情感计算单元（微软小冰的核心技术）、对话管理单元（多轮对话的核心，覆盖对话跟踪、对话策略等关键组件）。

数据层：存储用户画像、小冰人设画像、日志、问答库等核心数据。

虽然各个模块之间的关系并未清晰，但其实我们只需要进行分析很容易能搭出来，后续我们可以通过实验和探索进一步细化。

涉及的链接：

The design and implement of XiaoIce, an empathetic social chatbot

前沿重器[1] | 微软小冰-多轮和情感机器人的先行者：https://mp./s/rd8E3HfSfatLWmO933yhpQ

平安人寿智能问答引擎

平安人寿的技术分享中给出了算法视角非常完整的流程架构，从用户提问作为输入，预处理、检索、排序、对话策略一应俱全，内不包含的组件和能力也都一一列举，清晰明了。

预处理。这里当然也包括基本的quuery理解。

检索模块，和腾讯搜索里面提到的字面检索和语义检索基本一致，这里肯定是绕不过各种数据库的（这里还有比较潮的知识图谱）。

排序模块，各种答案基于各种策略和特征进行综合排序。

结合现实场景，用户对话的内容，进行对话策略的调整，例如澄清、追问、疑似问之类的策略。

涉及的链接：

ROCLING | 基于深度语义匹配，上下文相关的问答系统：/p/111380177

前沿重器[3] | 平安智能问答系统：https://mp./s/R7TXWjeYUNPmLG0DVGcpJA

小结

看了这么多大厂的案例，其实我们也很容易能看到很多共性的东西，尤其是query理解在这里面的地位，也逐步清晰明显。我们先来总结一下各大厂比较统一的技术架构吧：

首先是各种交互方式，对话里面可能会有很多人机对话的场景，ASR和TTS就比较重要了，说白了就是一个入口。

然后是语言理解，即query理解，也可以说是NLU，里面有各种预处理、表征、意图识别、实体抽取等关键任务。

检索，也可以说是召回。

排序，结合场景、用户习惯和产品设计等各个情况，调整结果给出最优答案。

流程和任务

大家对整个框架有完整的理解，下面我们会到Query理解本身，来看看Query理解是什么样的。

会到完整地腾讯搜索：

Query理解是用户输入内容后的第一个处理模块，他负责从query中提取信息，了解用户的需求，而这个信息，是要给下游的检索模块用的，意图识别和实体抽取决定了下游的搜索要在哪个库里面搜，搜什么字段和内容等。这里举了3个例子：

我想看失控玩家，知道是电影意图并且有电影名失控玩家，数据库是可以直接搜索到准确实体的。

天气，知道是天气意图，但是具体细节不清楚，那我们可以给出北京的（不可获取用户地址的时候）或者是用户所在地的天气。

预训练语言模型是什么，这是个广义的百科概念，我们能定义他的意图，比较厉害的系统可能还可以抽出实体，看具体情况具体查询。

有这个基础后，我们可以拆开这个黑盒了，看query理解里面具体都干了什么事。

我们来看看腾讯搜索给出的整个query理解的流程，模块分得很清晰，不外乎是这么几件事：

预处理。

分词。

改写。

term分析。

意图识别。

敏感识别和人工干预。

这里大部分其实都是比较基础的能力，如预处理、分词、干预等，而且比较通用或者没那么复杂，且对业务的效果影响不会有质的变化，这些在项目初期完成后基本就可以放着了，而在整个项目里，需要花更多时间的，对应的也是NLU（自然语言理解）的三大任务：

意图识别——文本分类。

实体抽取、term分析——命名实体识别。

语义表征——语义相似度。

因此，我会把更多的精力花在这3大任务理解的修炼中。

常见策略

在这里，给大家介绍这3大任务里比较常见的方案，方便大家更好地进行选择。

但是在此之前，还是想和大家强调一下，很多新手，尤其是学校出来的新人，其实很多人会聚焦于模型，从而不停地去优化改善，很容易陷入优化模型中，但实际上工程的应用还需要考虑很多其他问题，在这里简单说一下：

然后我们聊3大任务具体的基线方案和选型思路吧。

分类任务：CLS

文本分类应该是一个NLP里面最简单的任务了，现在也已经有了很多优秀的模型方案，但是在工业界，其实更多还是用可控性高、准确性高的词典方案来做基线，甚至在线的绝大部分流量都是用词典的方式来识别的（高频的甚至会专门整白名单）。

目前，人工特征的机器学习已经退下历史的舞台，但凡想到想用模型了，其实都会考虑上不太深的深度学习，faxttext是一个不需要gpu也能上的方案，textcnn则是个交叉方案，用不用gpu都可以尝试，不会太是性能的短板。HAN的提出主要是设计长文本的理解，可以用到。

基于预训练语言模型应该是综合效果最高的方案，但是与之相应的是上线的代价也会比较高，值得注意的是，如果是想用这个模型上线，需要把性能问题同样考虑其中，一般不会做基线方案，而是一个迭代优化的方案。

另外，之前其实自己有提到以搜代分的方案，用搜索的方式代替分类，具体可以看我的历史文章，下面给的链接也有。

涉及的链接：

Fasttext: /abs/1607.01759，

TextCNN: /abs/1408.5882

HAN: /anthology/N16-1174.pdf

BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding

RoBERTa：A Robustly Optimized BERT Pretraining Approach

ALBERT: A Lite BERT For Self-Supervised Learning Of Language Representations

/p/110648517

/p/183852900

我的分类文章：

https://mp./s/WZZ8Qtxxd_TpSzgMhfAcSA

https://mp./s/KrblC_JcjmPOZji4E1yaHg

https://mp./s/DMkC0olB5KF_MsPlPr36nQ

实体抽取：NER

命名实体识别是一个落到词汇级别，需要分析的内容要到句子内部的任务，难度会提升。

这里不再提这个机器学习了，词典规则直接就到深度学习，再加一波预训练语言模型，方案的流派其实挺固定的，并且也给出一套来自网上大神的实验，大家可以结合需求对比一下。

这里想展开的是一些trick吧：

可以加入一些额外的特征来协助完成任务。

数据增强可以补充一些样本和模板。

类别不平衡可以通过词典等方式来对样本进行补充。

嵌套实体这个问题其实看到很多任务都有，但值得注意的是，好像都不见得是高频问题，我们需要分析这是不是主干问题再来确定是否可以解决。

链接：

/p/166496466

/p/163256192

/p/77868938

任务方案思考NER篇：https://mp./s/1cUpjTm6l6IIoC_iNSsFhw

语义相似度：SIM

语义相似度应该是这里面难度偏高的，一方面是因为句子间的对比除了总体含义还有细节都需要了解，另一方面业务的影响对两个句子相似度的判定会有影响。

这里是提供了几个方向比较突出的方案，大家可以根据自己的实际情况进行选择，统计文本这块的方法还是优先推荐大家选择，毕竟不需要模型训练，顶多做一些tfidf的统计就好了，难度不是很高。

语义相似度模型主要分为两个大的派别，表征式和交互式，表征式是把句子表征成向量后，在进行简单的如欧氏距离、余弦距离等，而交互式则在计算过程中不会出现明显的这种向量表征，而是在内部通过类似attention的方式进行两两对比从而完成相似度计算，要这么分的核心原因之一就是只有表征式能完成语义匹配任务，即向量召回。

链接：

21个经典深度学习句间关系模型｜代码&技巧：/p/357864974

基于深度学习的短文本相似度学习与行业测评：https://mp./s/6VqFTj2MVF24yF2KwPOcpQ

小布助手登顶百度千言短文本相似度的秘诀：https://mp./s/uYfmkebEAPqMrgAx_2qLRQ

心法利器[13] | 任务方案思考：句子相似度和匹配：https://mp./s/JKpK9S_pZkIHoGx2zAV0xg

心法利器[18] | cqr&ctr：文本匹配的破城长矛：https://mp./s/Qnq6qR0ytSmohqg2skt0fw

调优思路

OK，介绍完各种基线方案以后，也给大家介绍一下我的有关效果调优的方案，这些思路是非常有利于解决实际问题的，当然这些思路我自己本身还没成熟，还需要思考和打磨，但也算是给大家一些启发吧。

首先，也是我最希望大家能建立的意识就是bad case分析的意识，只有足够熟悉数据，熟悉问题，我们才能够对症下药。

要分析，那其实我们就是要看每个错误的结果都有什么问题，有什么特点，这些特点是逐个分析得到的，是否具有哪些性质，例如长度、句式等等，具体策略其实PPT列举的听清楚的，大家可以结合各种情况进行总结，这个其实非常考验一个人的功底，合理的归因能让你更快更准地找到解决方案，从而更好地解决问题。

在分析完case的问题后，要知道什么是关键问题，就去统计一下各个问题的占比吧，占比高的，大概率就是当前问题的关键点，有了这个东西，就可以进一步地开展效果优化了。

这里之所以提效果调优而不是该模型，是因为在特定应用场景下，受益更大的并非调模型，而是有更多手段能够实现。

首先，受益最大的肯定是数据层面的优化，提升标注质量，正负样本内的特殊数据，特定知识的输入等，训练集和测试集本身也可能存在问题。

其次，一些小trick其实可以尝试，但是当然这只能是很小的提点优化，如果效果不足60%这些trick其实用了和没用没太大区别。

做了很多，最终才是考虑更换模型，我想说的是，不行就换，一一个个模型轮流试的那种思维要尽早抛弃，一方面我们应该更多地去感受模型的区别，另一方面是去看看现在所存在的问题的核心，从而找到甚至是搭建模型来抽取自己需要的特征，这才是关键的。

总结

本次，给大家介绍了搜索与对话系统中的query理解的概况，并且对核心的三大任务进行了一一的概述性介绍，给大家一些学习方向和思路，同时在落地的时候，也能多一些自己的思考，开拓视野吧，希望对大家有用。