机器之心原创，作者：邱陆陆

人类从一百二十万年前就开始制造机器了。阿基米德的杠杆给了我们力量，伽利略与达芬奇的动力学给了我们速度与空间，而计算机科学将取之不尽的信息从广阔的世界里吸收过来呈现在我们眼前：它试图让人类更「渊博」，用可以无限扩充的存储帮助大脑去记忆；也试图让人类更「聪明」，能够用可叠加的算力帮助人跨越自身处理大量数据和高维数据的极限。

然而仅仅有存储能力和算力是不够的，当一位保险业务员被客户问到「这个保险可以用来办贷款吗？」的时候，即使保险说明书就存在电脑里，业务员也仍然需要花大量时间才能从数百页长的说明书里找到相应条款，至于实时回应客户的业务咨询，简直是天方夜谭。而当一位银行销售经理想知道「北京客户的年龄分布情况如何？」的时候，即使每一位客户的年龄数据都记录在数据库中，他作为一名没有数据库知识的一线业务人员，仍然需要等待专业分析师以周为单位给出一份未必能够满足要求的报告。

信息存在不等于信息可得，信息可得不等于知识可得，想要让机器真正听懂我们的问题、帮助我们回答问题，机器需要「学习」的还有很多。在平安集团旗下，有一家专攻金融科技的独角兽公司，金融壹账通。在金融壹账通的人工智能实验室 Gamma Lab 里，有两支专攻「让机器听懂人的语言，再把信息变成知识交给人」的队伍，他们选择了两个金融领域里常见的业务情景，研发了可以帮保险业务员做说明书阅读理解的 Gamma eExpert 和可以帮助银行业务员把问题变成数据库查询命令再变成报表的 Gamma Telescope。

最近，机器之心走进 Gamma Lab，与工程师们仔细地聊了聊这两款产品，确切地说是聊了聊，让机器回答一个自然语言问题，到底需要几步。

Gamma eExpert：对保险文档「倒背如流」的业务助手

帮助业务员回答一个客户对一份长度可达数百页的保险文档的问题，需要几步？eExpert 团队给出的答案是：三步。

eExpert 是一个旨在帮助保险业务员读保险文档同时回答客户问题的系统，它把一个来自客户的问题和一篇对应的保险文档视作输入，然后输出一句可以直接回答给客户的话，以及这句话引用的保险条款原文出处。

eExpert 智能阅读理解系统界面截图，下方为保险文档段落，红字部分为阅读理解选出的精准答案

第一步：拆解保险文档，进行段落匹配

以 pdf、word 等形式存储的带有复杂格式的保险文档经过目录结构梳理、表格抽取和文本分段，被拆解成了众多的文本段落。而用户的问题进入系统后，段落匹配模块首先要找出，在整篇保险文档中，与这个问题最相关 N 个段落。

段落匹配主要利用了相似度匹配算法的思路：首先将深度学习表示和符号表示结合起来，得到十几个可以代表这个段落的「特征」，然后再用排序算法对这些特征与用户问题的相关度进行打分，打分最高的 N 个相应的段落就会进入到下一步，段落理解中。

值得注意的是，打分的机制也并不是工程师凭借经验「拍脑袋」想出来的，而是通过「让算法做选择、比较算法的选择与真正的答案之间的差异、据此对参数进行优化」的三段式学习方式找到的，据负责人介绍，最后段落匹配 top3 的准确度能达到 96% 以上。

第二步：进行段落理解

把用户问题和段落匹配阶段选出来的 N 段文本分别输入阅读理解模块，通过由输入嵌入层、嵌入编码层、文本注意力层、模型编码层和输出层组成的深度学习模型之后，得到一个表征「起始点位置」与「终止点位置」的向量，相当于用记号笔高亮了段落中的一个短语或者一句话。

段落理解是 eExpert 系统的核心，为了训练出准确度高、覆盖面广、可迁移性强的模型，团队在模型结构、数据、优化流程上都进行了许多探索。

输入嵌入层对问题和文本分布做词级别的嵌入，同时添加了很多人工特征。嵌入编码层利用多尺度的一维卷积，把不同长度的问题和文本编码为等长的多维向量。文本注意力层对问题和文本做双向的注意力计算：根据问题去文本中找相关内容，同时根据文本去问题中找相关内容。模型编码层以矩阵的形式找到起始点和终止点位置的联合分布。最后，输出层给出多个泛化答案。相比于单个答案，多个泛化答案能够明显提高获得正确答案的召回率。

而为了解决专业领域有标注数据匮乏而准确率要求高的问题，团队采用了从通用模型到垂直领域专用模型迁移的方式。在使用近 10 个中、英文通用数据集进行了预训练，确保模型有好的泛化能力后，这样的通用模型在混合通用数据集上大概能取得 36% ~ 48% 的准确率。

随后，Gamma 组织保险领域的专家，耗时半年建立了一个 10 万量级的保险阅读理解垂直数据集，然后利用这个垂直数据集对模型做精调和迭代式改进。第一轮精调后，模型的准确率直接提升都超过了 65%。然而这仍然不是一个「可推广」的模型，因此团队针对错误的回答进行了数据负样本增强。比如「犹豫期内退保是否有损失」和「犹豫期外退保是否有损失」，从语义相似度的角度不过一字之差，答案却截然不同。模型在只有极少针对性训练样本的情况下不能很好区分二者，因此就会扩充带有「犹豫期内」、「犹豫期外」关键词的样本。经过两轮、1 万条左右的数据扩充以及多种模型改进技巧，模型的准确率攀升到 90% 左右。

第三步：筛选答案，智能话术生成

「筛选答案」同样是一个由小组件组成的模块。

首先，对于那些多步推理的问题或者有「较长标准正确答案」的定义类问题，eExpert 将问题和答案以知识图谱三元组的形式组织起来。（比如，「什么是重症疾病？」、「什么是除外责任？」）在筛选答案环节里，系统首先会判断，用户的问题是否是一个有「标准答案」的常见问题，如果是，那么知识图谱提供的答案会有较大概率被选择。一个最典型的适合知识图谱而不是阅读理解回答的问题是「哪些疾病不在该保险的承保范围中？」这个问题的答案通常分散在保险文档的不同段落中，这就为阅读理解模型解决这一问题带来了天然的障碍，而反之，基于知识图谱的问答模型（KBQA）则非常擅长根据条件从文本中进行内容抽取以及整合。

来自知识图谱的答案，对多个段落的总结

然后，对于那些 FAQ 解决不了或者解决得不好的问题，「答案拒绝」组件会对选出来的 N 个段落以及答案做二次审核，如果阅读理解模型优中选优的 N 个答案和问题不存在蕴含关系，拒绝模块会阻止答案进入话术生成，而是告诉「阅读理解」模块，本次回答失败，下次再接再厉。

最后，有的时候，直接读文档给客户会显得非常生硬，业务员在与客户交谈的时候除了需要熟练掌握保险条款，也会运用一定的表达技巧。这一部分 eExpert 也考虑到了，平台总结了一系列业务员常用的话术模版，把找到的标准答案和话术模版融合在一起，让机器生成一个更有「人味」的答案。

红字部分是阅读理解模块选出的答案，蓝字部分是智能话术的答案

Gamma Telescope：随手拯救「表哥」「表姐」

帮助管理人员用一张报表回答一个和数据库相关的自然语言问题需要几步？很巧，Telescope 的团队给出的答案也是，三步。

Telescope 和 eExpert 的服务对象都是金融行业的业务人员，都需要处理自然语言问题，区别在于 eExpert 是从另一份自然语言文本中寻找答案，而 Telescope 则是从结构化数据库中寻找答案。eExpert 把保险文档段落和问题一起输入模型，而跟随问题一起进入 Telescope 模型的是数据表。eExpert 在文档段落中高亮出能够回答问题的部分，而 Telescope 输出一句查询命令，然后把从数据库中返回的查询结果以可视化的形式展现出来。换言之，这是一位业务员专属的数据分析师。

Telescope 界面实例

第一步：语言建模

在第一部分里，数据表的表头（列名，column names）和自然语言问句被视为两个序列，分别用 Bi-LSTM 编码层编码为两个向量，然后利用注意力机制加强问句中与表格更相关的词的重要性，最后得到既包含问题信息，也包含表格信息的一个向量，完成语言建模。Bi-LSTM 编码将表格的位置信息、语言的语序信息也都编码进去了，换言之，调换一下一张数据表中的列的顺序，在模型看来就又是一个完全新鲜的训练数据了。

如何对表头和自然语言问题进行编码

第二步：用预测的方法把问句转换为 SQL 语句

在 Telescope 的视角里，一个 SQL 语句由语句类型、操作维度、以及条件过滤器三部分组成。系统的第二部分任务就是把「SQL 语句生成」这个大问题拆分成多个小问题，通过一系列的预测，确定 SQL 语句的不同组成部分，从而完成语句的生成。

首先进行预测的是语句的形式。Telescope 把自身会用到的语句类型分成多个类别，并确定自然语言问句对应哪一种 SQL 语句类别。例如「学历分布」、「年龄分布」、「销售额分布」就都属于「分布」类问题。

其次进行预测的是操作维度，系统会预测在数据的众多列中，问句最有可能是针对哪一列数据进行提问，并把可能性最大的列名加入查询范围中。

最后进行预测的是条件过滤器相关的一系列内容，包括过滤器的数量、类别、条件列名以及条件值。其中前三者的预测方式和语句类型以及操作维度的预测方式相似，而条件值部分则采用了指针网络（Pointer Network），用于将原文中的专有名词复制到问句中。例如在「上海地区 30 岁及以上男性借款人的学历分布是什么样的？」一个问句中，过滤器就会把「地区是上海」，「年龄大于 30 岁」两个条件识别出来。

针对金融企业里每一个职能部门可能出现的数据表以及业务人员可能对这份数据提出的问题，团队为数千个自然语言问题按照上述范式给出了标注，根据这份标注，可以自动生成一句能够提取相应数据的 SQL 语句。

第三步：查询可视化与返回

获得数据之后，如何针对数据特性找到最有助于辅助决策的可视化方式，是一类机器尚不如人类表现的问题。因此在这里，产品团队从现实的需求场景出发，针对每一种「语句类型」提供了推荐的可视化方式。例如，针对「分布」这一语句类型，系统给出了「柱状图」和「词云」两个可视化选项。

值得一提的是，「语句类型」里除了「分布」这样的明确意图之外，还包含了「是什么样的」这样未指明意图的情况。自然语言查询对于提问者的约束远小于传统分析工具，因此，经常会出现「北京的客户是什么样的？」这样未指明意图的模糊问句。针对这样的问题，Telescope 也会尝试猜测和「北京」、「客户」相关的查询，把「北京客户的逾期情况」、「北京客户的借贷机构数情况」、「北京客户的多头借贷情况」以图表报告的形式呈现给查询者，让查询者选择他们关心的方向。

而从语句类型的设定到从可视化选项的选择，都来自平安内部一线业务人员的标注与反馈意见。这也确保了多样化的真实场景下的真实需求都得到满足。

自然语言问题中的「大象」与「冰箱」

回到最初的问题：通过段落匹配、阅读理解和智能话术生成三步，eExpert 就能回答一个保险咨询问题，而通过语言建模、SQL 语句预测和查询可视化三步，Telescope 就能生成一张业务分析图表，然而和「把大象装进冰箱里需要几步」一样，「回答一个自然语言问题需要几步」是一个看似可以用一句话概括，但实际近乎不可能的任务。完成这样一个任务时，需要进行大量基于实务经验的产品设计的问题。

「有人说，想要获得足够高的问答准确度，有百万量级的专业语料就好了。但是当客户说希望有一个能通过自然语言问答查询数据的工具时，我们不能对客户说，你先把百万标注语料拿出来。我们要做的是不是让场景适应技术，而思考如何把问题拆分、把技术组装，去达到一个真实的目的。」Telescope 的负责人说。

因此在了解 eExpert 与 Telescope 系统的结构、每一个部分的原理、必不可少的数据标注工作之外，我们也透过这些描述，看到了 Gamma Lab 在这条让机器「理解人的问题，再把信息变成知识交给人」的路上，遇到的障碍与跨越障碍的种种努力。

这些经过了反复探讨的流程设计，反复试验、失败、再试验最终得以保留的方法与技巧，才是客户能够毫不费力地用最自然地方式得到想要的答案的原因。

他们改变了「大象」，也改变了「冰箱」，然后给了用户一个简单至极的答案。