企业数字化是近年来很热的一个话题，它是指运用人工智能、大数据、云计算等新一代数字技术，改变企业的业务模式，从而推动企业业务产生新的增长。企业数字化一般来说包括业务经营的数字化和企业管理的数字化。本次分享主要介绍企业管理层面的数字化。
信息数字化，简单来说，就是把信息用数字化的方式进行读写、存储和传递。从以前的纸质文档到现在的电子文档以及在线协同文档，信息数字化已经变成了现在办公的新常态。目前阿里使用钉钉文档和语雀文档进行业务协同，在线文档数量已经达到了 2000 万以上。另外很多企业内部会有自己的内容社区，比如阿里的内网阿里内外，以及技术社区 ATA，目前 ATA 社区里面有将近 30 多万篇技术文章，都是非常宝贵的内容资产。
流程的数字化，指的是运用数字技术改造办事流程，提高办事效率。像企业内部行政、IT、人事等会有很多事务型工作。BPMS 流程管理系统可以把办事流程标准化，根据业务规则制定一个工作流，按照工作流自动执行，就可以大大降低人工成本。RPA 主要是用来解决流程中多系统切换的问题，因为它可以模拟人工在系统界面上进行点击输入的操作，所以它可以连接各个系统平台。流程数字化的下一个发展方向是流程的智能化，通过对话机器人和 RPA 来实现。现在任务型的对话机器人可以在几轮对话内就帮助用户完成一些简单的任务，比如请假、订票等等。
业务数字化的目标是通过数字技术建立一个新的业务模式。在企业内部，其实也会有一些业务的中台，比如采购部门的业务数字化，指的是从商品的搜索、采购申请的发起、采购合同的撰写、付款、订单执行等一系列流程的数字化。再比如法务中台的业务数字化，以合同中心为例，实现从合同起草开始，到合同审核、合同签署、合同履约在内的合同全生命周期的数字化。
数字化产生海量的数据和文档会散落在各个业务系统里面，所以需要一个智能的企业搜索引擎，帮助员工快速定位到他想找的信息。以阿里集团为例，企业搜索的场景主要有以下几种：
（1）统一搜索，又称综合搜索，它聚合了多个内容站点的信息，有钉钉文档、语雀文档、 ATA 等等。统一搜索的入口目前是放在阿里的内网阿里内外以及钉钉的员工专属版，这两个入口的流量加起来有达到 140 QPS 左右，在 ToB 场景中属于很高的流量了。
（2）企业员工助手指的是内外小蜜，它是一个面向阿里内部员工的智能服务机器人，汇集了 HR、行政、IT 等多个领域的企业知识问答服务，还有快速的办事通道，包括钉钉的这个入口，以及一些外挂入口在内，一共开放人群有 25 万人左右，也是集团的流量阵地之一。
（3）行业搜索对应上一章讲到的业务的数字化，比如采购有一个门户网站叫做采购商城，采购员可以在采购商城里面搜索，选择商品，提交采购的申请，类似于电商搜索网站，只不过用户是企业的采购员；法务合规业务也有对应的一个门户网站，法务的同学可以在里面搜索合同，进行合同的起草、审批、签署等一系列工作。
一般来说，企业里面每个业务系统或者内容站点会有自己的搜索业务系统，是需要相互隔离的，但是内容站点的隔离会形成信息孤岛的现象。比如一个技术同学遇到了一个技术问题，他可能会先去 ATA 搜索问题相关的技术文章，搜不到的话再去知否、钉钉文档、语雀文档里面搜索类似的内容，一共要进行四五次搜索行为，这样毫无疑问效率是很低的。所以，我们希望能把这些内容集合起来，做成一个统一的企业搜索，只要一次搜索就可以获得所有相关的信息。
另外带有业务属性的行业搜索一般来说是需要互相隔离的。像采购商城的用户是集团的采购员，合同中心的用户是集团的法务，这两个搜索场景的用户量很少，所以用户行为就会比较稀疏，依赖用户行为数据的推荐算法，效果就会大打折扣。采购、法务领域的标注数据也很少，因为需要专业人员来标注，成本很高，所以很难收集到高质量的数据集。
最后是 Query 和文档的匹配问题，搜索的 Query 长度基本在十几个词以内，是短文本，缺少上下文，语义信息不够丰富，针对于短文本的理解，学术界有很多相关的研究工作。搜索的 Item 基本上都是长文档，字符数量在几百到几千之间，对长文档的内容理解和表征也是一个很有难度的任务。
上图展示的是目前我们的企业搜索的基本架构。这里主要介绍统一搜索的部分。
目前统一搜索接入了 ATA、钉钉文档、语雀文档等大大小小 40 多个内容站点。使用阿里自研的 Ha3 引擎进行召回和粗排，在召回之前会调用算法的 QP 服务对用户 Query 进行分析，提供 Query 的分词、纠错、term 权重、query 扩展、NER 意图识别等。根据 QP 的结果和业务逻辑，在引擎侧拼好查询串进行召回。基于 Ha3 的粗排插件可以支持一些轻量级的排序模型，比如 GBDT 等等。在精排阶段可以使用更复杂的模型进行排序，主要用相关性模型来保证搜索的准确性，以及点击率预估模型直接优化点击率。
除了搜索排序之外，还沉淀了其他的一些搜索周边功能，比如搜索下拉框的搜索直达区、联想词、相关搜索、热门搜索等。目前上层支持的业务主要是阿里内外和阿里钉钉的统一搜索、采购和法务的垂直搜索，还有 ATA Teambition OKR 系统的 Query 理解。
上图是企业搜索 QP 的大致架构，QP 服务部署在一个叫做 DII 的算法在线服务平台上。DII 平台，可以支持 KV 表、index 表索引的构建和查询，其整体是一个链式服务框架，需要把复杂的业务逻辑拆分成相对独立和内聚的业务模块。比如，阿里内外的搜索 QP 服务，就拆分成分词、纠错、查询扩展、term weight、意图识别等多个功能模块。链式框架的好处是方便多人协作开发，每个人负责各自模块的开发，只要约定好上下游接口就可以，并且不同的 QP 服务可以复用同一个模块，减少重复代码。此外，在底层的算法服务上面包了一层，对外提供 TPP 接口。TPP 是阿里内部的一个成熟的算法推荐平台，可以很方便地做 AB 实验和弹性扩容，日志打点和监控报警的机制也非常成熟。
在 TPP 侧进行 Query 的预处理，然后组装 DII 请求，调用 DII 算法服务，获得结果之后进行解析，最后返回给调用方。
接下来介绍两个企业场景下的 Query 意图识别工作。
内外小蜜底层是基于达摩院推出的云小蜜问答引擎，它可以支持 FAQ 问答、多轮任务型问答、知识图谱问答。上图右边展示的是 FAQ 问答引擎的大致框架。
用户输入一个 Query 之后，开始会有一个规则干预模块，主要是让业务和运营来设置一些规则，如果命中规则的话，就直接返回设定的答案，如果没有命中规则就走算法。意图识别的模块，把用户 Query 预测到对应的业务线，每个业务线的 FAQ 知识库里面有很多的 QA 对，每个问题会配置一些相似问法。用 Query 去知识库检索得到 QA 对候选集，然后再通过文本匹配模块来对 QA 对进行精排，根据模型打分来判断是答案直出，还是推荐关联问题，还是无答案。除了 FAQ 问答引擎之外，还会有任务型问答和知识图谱问答等其他的问答引擎，所以，最后设计多模块的 ranker 来选择透出哪个引擎的答案给用户。
下面重点介绍一下意图识别这个模块。
通过统计过去一年内外小蜜的用户 Query，发现大部分的用户 Query 字数集中在 0- 20 之间，80% 以上的 Query 字数在 10 以内，所以，内外小蜜的意图识别是一个短文本分类的问题，短文本次数很少，所以如果用传统的向量空间模型表示，会造成向量空间的稀疏。并且一般来说短文本表述会不太规范，简称和不规范用语很多，所以 OOV 的现象也比较多。
小蜜的短文本 Query 还有一个特点，就是会有很多专有名词，一般是内部的平台和工具名，比如欢行、爱豆等等。这些专有名词本身文本也不具备类别相关的语义信息，所以很难学到有效的语义表示，所以我们想到用知识增强来解决这个问题。
一般的知识增强会用开源知识图谱，但是企业内部的专有名词没办法在开源的知识图谱里面找到对应的实体，所以我们就从内部找知识。刚好阿里内外有一个知识卡片搜索的功能，每个知识卡片对应的是一个内网的产品，它和内外小蜜的领域是高度相关的，像这里面的欢行、爱豆都能找到相关的知识卡片，所以就把企业知识卡片作为知识来源。
首先是知识增强，一共有 6000 多个企业知识卡片，每个知识卡片会有一个实体名和一段文本介绍，根据用户的 query 去召回与它相关的知识卡片，把历史 query 也都利用起来，因为有很多 query 是相似的，比如内网 Wifi 连接，Wifi 内网连接等，相似 query 互相之间可以补充语义信息，进一步缓解短文本的稀疏性。召回除了知识卡片实体还有相似 query，连同原始 query 一起送到文本分类模型里面进行分类。
用向量召回的方式，召回知识卡片的实体和相似 query。用 Bert 分别计算 query 和知识卡片文本描述的具象量。一般来说不会直接使用 Bert 的 CLS 向量作为句子表征，很多论文中也有提到，直接使用 CLS 向量作为句子表征效果会很差，因为 Bert 输出的向量会出现表达退化的问题，不适合直接用它做无监督的相似度计算，所以使用对比学习的思想，把相似样本拉近，让不相似的样本尽量均匀分布。
具体来讲，就是在数据集上 finetune 了一个 Sentence-Bert，其模型结构和训练方式可以产出比较好的句向量表征。它是一个双塔的结构，两边的 Bert 模型共享模型参数，两个句子分别输入到 Bert 里面， Bert 输出的 hidden states 做 pooling 之后会得到两个句子的句向量。这里优化的目标是对比学习的 Loss，infoNCE。
正例：直接把样本输入到模型里面两次，但是这两次的 dropout 是不一样的，所以表征的向量也会有些微的差别。
负例：同一个 batch 里面所有其他的句子。
优化这个 Loss，就得到了 Sentence-Bert 的模型，来预测句向量。
我们使用 StructBERT 模型参数来初始化这里面的 Bert 的部分。StructBERT 是达摩院提出的一个预训练模型，它的模型结构和原生的 Bert 是一样的，其核心思想是在预训练任务里面融入语言结构信息，去获得 query 的句向量和知识卡片，通过计算向量的 cosine 相似度，召回最相似的 top k 个知识卡片和相似 query。
上图是文本分类的模型结构，在 Encoding 层使用 Bert 提取原始 query 和相似 query 的词向量的表征，每个知识卡片的实体会维护一个实体的 ID embedding，ID embedding 是随机初始化的。
模型结构图右侧，用来处理 query 召回的实体，得到实体的统一向量表征。因为短文本本身比较模糊，所以召回的知识卡片实体也会有一定的噪声，通过使用了两个 attention 的机制，让模型更加注意正确的实体。一个是 Query-to-Entity 的Attention，目的是让模型更注意和 query 相关的实体。另一个是实体本身的 self Attention，可以把互相之间相似的实体权重提高，降低噪声实体的权重。综合两组Attention 权重，就得到最终实体的一个向量表示。
模型结构图左侧就是处理原始 query 和相似 query，因为观察得到，相似 query 和原始 query 的重合词语一定程度上可以表征 query 的中心词，所以这边计算了每个词语两两之间的点击，得到相似度矩阵做 sum pooling，得到原始 query 中每个词语相对相似 query 的权重，目的是让模型更加注意中心词，然后将相似 query 和原始 query 的词向量一起拼接起来，计算融合的语义信息。
最后上面三个向量再拼接起来，经过 dense 层预测，得到每个类别的概率。
以上是实验结果，超过了 BERT finetune 的结果，编码层不用 Bert 的话，也是超过了所有非 Bert 的模型。
以采购商城为例，采购商城有自己的商品类目体系，每个商品在上架之前会挂载到一个商品类目下。为了提高商城搜索的准确率，需要把 query 也预测到具体的类目，再根据这个类目调整搜索排序结果，也可以根据类目结果，在界面上展示子类目导航和相关搜索。
类目预测需要人工标注的数据集，但是采购领域，标注的成本比较高，所以从小样本分类的角度来解决这个问题。
预训练模型在 NLP 任务上展示了强大的语言理解能力，典型的使用范式是先在大规模的无标注数据集上预训练，然后再在有监督的下游任务上进行 finetune。比如 Bert 的预训练任务，它主要是一个 mask 的语言模型，也就是把一个句子里面的词语随机 mask 掉一部分，输入到原模型中，然后预测 mask 部分的词语，最大化词语的似然。
做 query 类目预测本质上就是文本分类的任务，文本分类任务就是把输入预测到某一个 label ID，而这没有使用 label 本身的语义信息，微调的分类任务和预训练任务是不一致的，不能最大化地利用预训练任务学到语言模型，所以出现了一个新的预训练语言模型。
预训练语言模型的范式叫做提示学习，Prompt 可以理解为给预训练语言模型的一个提示线索，帮助它更好地理解人类的问题。具体来说，在输入文本的基础上额外添加一段话，这段话里面会 mask 掉和 label 相关的词语，然后让模型来预测 mask 这个位置的词语，这样就把分类任务转化成了 mask 语言模型任务，预测了这个 mask 位置的词语之后，往往会需要再把这个词语映射到标签集，采购的类目预测就是典型的小样本分类问题，通过针对类目预测任务构建几个模板，然后 mask 掉的部分就是需要预测的词语。
对于模板，建立了预测词到标签词的映射。
首先，预测词不一定就是标签。因为为了方便训练，每个样本的 mask 字符数是一致的，原本的标签词有 3 个字、4 个字等，这里把预测词和标签词都做了映射统一变成两个字。
另外，在提示学习的基础上，使用自学习的框架，先用有标签数据到每个模板训练一个模型，然后几个模型集成起来进行预测无标签数据，训练一轮，从中选出置信度高的样本作为伪标签数据，加入到训练集中，这样就获得了更多的有标签数据，再接着训练一轮模型。
上图是一些实验结果，可以看到在 zero shot 场景下分类的效果，预训练模型用的是 Bert base，一共是 30 个类，zero shot 已经能达到 16% 的准确率了。在 ten shot 数据集上进行训练，几种模板最高能达到 56% 的准确率，提升还是比较明显的，可以看出模板的选择也会对结果产生一定的影响。
同样的 ten shot 数据集，使用 TextCNN 和 BERT-finetune 也做了实验，效果都是远低于提示学习微调的效果，所以提示学习在小样本场景是非常有效的。
最后，使用全量数据，约 4000 条训练样本，加上自学习，效果达到了 82% 左右。线上再加入卡阈值等一些后处理，可以保证分类的准确率在 90% 以上。
企业场景 Query 理解有两大难点：
（1）领域知识的不足，一般短文本理解会借助知识图谱来做知识增强，但由于企业场景的特殊性，开源的知识图谱很难满足需求，所以使用企业内部的半结构化数据来做知识增强。
（2）企业内部的一些专业领域标注数据很少，0 样本和小样本的场景特别多，这种情况下很自然地可以想到用预训练模型加提示学习，但是 0 样本的实验结果也不是特别好，因为现有的预训练模型里面用的语料，其实并没有覆盖到我们企业场景的领域知识。
所以是不是可以训练一个企业级的预训练大模型，在通用语料的基础上用企业内部垂直领域的数据，比如阿里的 ATA 的文章数据、合同数据和代码数据等进行训练，得到一个预训练大模型，再用提示学习或者是 Context learning，把文本分类、NER、文本匹配等各种任务统一成一个语言模型任务。
另外，像问答 QA、搜索这些事实性任务，如何在生成式语言模型的结果上保证答案的正确性，也是一个需要思考的问题。
A1：模型是自研的，目前还没有论文和代码。
A2：query 和相似 query 是用了 token 维度级别的输入，知识卡片只用了 ID embedding，因为考虑到知识卡片的名字本身，存在一些内部的产品名，在文本语义上并没有特别的有意义。这些知识卡片如果用文本描述的话，只是一段比较长的文本，可能会引入过多的噪声，所以就没有使用它的文本描述，只用了这个知识卡片的 ID embedding。
A3：ten short 确实就只有 50% 左右，是因为预训练的模型并没有覆盖到采购领域的一些比较罕见的语料，并且使用的是参数量相对较少的模型 BERT-base，所以 ten shot 的效果也不是很好，但是使用全量数据的话，可以把准确率做到 80% 以上。
A4：这块目前也是正在探索。主要想法是在语言模型生成之前，运用一些类似于强化学习的思路，加入一些人工的反馈，来调整输出。
在输入的后面，就是大模型输出的后面增加一些预处理，预处理的时候可以加入知识图谱或者是其他的一些知识，来保证回答的准确性。
以上是基于知识增强和预训练大模型的 Query 意图识别的详细内容。更多信息请关注PHP中文网其他相关文章！
