摘要：术语对齐 TaskBot引擎：核心处理对象是“技能”，我们把技能定义成结构化(query+content)、垂直场景化的任务，比如实时场景查询、工具类、控制类等QABot引擎：包括KG-QA引擎、QAPair引擎、DeepQA引擎。

术语对齐

TaskBot引擎：核心处理对象是“技能”，我们把技能定义成结构化(query+content)、垂直场景化的任务，比如实时场景查询、工具类、控制类等

QABot引擎：包括KG-QA引擎、QAPair引擎、DeepQA引擎。KG-QA主要是百科和围绕全网知识图谱的精准问答；QAPair引擎以问答对生产消费为主；DeepQA引擎基于url索引、分类聚类、焦点词、摘要的多级系统

ChatBot引擎：包括基于检索和生成的闲聊引擎

内容体系

网页搜索与智能对话是信息服务的不同承载方式，在数据、算法、架构上一脉相承。也正因此积累，谷歌等搜索引擎公司可以快速推出其AI平台&产品，以信息服务为基础To B/C。

行业技能库

第一阶段：团队用了半年的时间将大搜索100+的垂直行业进行结构化升级，涉及行业大到大娱乐、大出行、新闻资讯，中到汽车、体育、旅游，小到股票、翻译、古诗词等等
第二阶段：进一步进行技能的结构化升级，精细的Query结构化、多轮对话建设，并输出到天猫精灵音箱

全网知识图谱

阿里唯一全网知识图谱，以知识卡片、实体推荐、精准问答等产品输出；

问答库

社区问答库：基于UGC问答社区的问答库，1B doc的量级；
UPGC生产：神马"骑士团"建立的校园生产体系，骑士团是该项目的code name，充分利用校园对存量知识进行整理、加工、审核，提升问答的生产效率和质量；目前参与学生人数万级别；
高质量库：社区问答库覆盖高但质量参差不齐，社会化生产质量高但数量相对较少，通过机器对社区问答库的清洗和对社会化生产库的扩展，最终沉淀成高质量库；
蛋清库：蛋清是产品策略。用户与bot对话时最希望得到直接的答案即"蛋黄"，但是有时候机器能get(或部分get)到用户的问题但是无法给与完美的答案，这个时候给用户"蛋清"也是一种优雅的手段表示我理解你；目前已完成第一版蛋清上线，主要覆盖“描述/方式”问题类型；

核心库

为了净化互联网环境、提升内容质量，我们以运营+挖掘的方式运转了一套核心库的流程；

技能库+知识库+问答库+闲聊库，构成了信息服务场景下智能对话的基础设施，举几个例子说明下不同库对不同query（询问）的满足，小马同学正在看一场NBA比赛，他说：

"现在火箭领先多少分了？" -> 技能库
"篮球是谁发明的？" -> 知识库
"哈登能进名人堂吗?" -> 问答库
"咱们聊聊NBA吧?" -> 闲聊库

通用信息服务始终在追求问答的覆盖和质量，这也是业界的难点，包括半结构化/非结构化数据的处理、内容生产模式、内容敏感问题、用户满足等等；神马搜索在一年的探索中积累出的多级QA系统、MOPU(Machine/OGC/PGC/UGC)多元化生产、流程化规模化可持续的生产体系走在了业界的前沿；在最近一次天猫精灵理想query集合评测上，触发率达到73%，准确率达到了91%；这个数据是什么概念，可以参考业界代表性产品的指标：

根据Stone Temple最近的调查，谷歌虚拟助理可以回答68％的用户问题，其中90.6％的答案是正确的，而微软Cortana能够回答的用户问题比例为56.5％，准确率为81.9％；而苹果Siri回答的用户问题比例为21.7%，准确率为62.2％，亚马逊Alexa回答的用户问题比例为20.7％，准确率为87％

架构体系

上图为架构体系整体大图。"引擎"负责数据的构建和计算的承载，"平台"负责以引擎为核心构建的闭环解决方案(生产、多租户消费、运营、需求管理等)。系统的落地，得以于搜索多年的积累沉淀。该系统完全与搜索业务解耦，承载了天猫精灵等业务方的流量(以及双十一晚会直播问答)。下面会分别介绍神降临平台、TaskBot引擎、QABot引擎。

神降临平台

神降临平台是TaskBot引擎的平台化延展，解决技能生产、消费、运营等问题。对于外部开发者它是BotFramework；对于外部调用者它是神马整个智能对话的出入口；对于内部RD它是生产和运营平台。目前该平台主要服务集团内部业务。神降临由技能开放平台、技能生产平台、统计分析平台、运营管理平台组成。

技能开放平台

开放有两个层面：内容开放+能力开放。对应的技能开放平台也承担两个角色：
1.能力开放(BotFramework)：对标类api.ai的技能构建平台，外部开发者构建自己的技能；
2.内容消费(OpenAPI)：通过创建应用、选择技能/问答，直接通过API进行智能对话；
目前我们尚未对外主推BotFramework：虽然开放平台产品众多，但目前的模式很难满足开发者需求，一个技能从产品规划到生产可用需要大量和较长链路的工作，不是提交点语料配置点上下文和输出就可以搞定的(简单控制类勉强可以)。在我们技能一期专项完成的20+技能下大约有300+种不同意图，建立了语料收集、标注、审核、建模、测试的完善流程。所以我们的精力主要放在打磨真正可用的内置技能，产生实际的价值。

技能生产平台

技能生产平台用于生产内置技能。它与技能开放平台的角色一致最终都是将物料投递给TaskBot引擎，但用户是内部RD，涵盖了从产品PRD到技能上线的全链路流程，涉及在线编写结构化PRD、需求管理、语料管理、实体管理、技能构建、技能训练、技能验证、技能发布。

为了技能的普适性，每个技能我们都以技能组的方式支持多场景：标准无屏、手机屏、大屏，标准无屏针对天猫精灵音箱类似场景，手机针对神马的个人助理场景，他们在多轮需求、结构化展现、排序策略上都不尽相同；另外内置技能的物料除了实体、语料、剧本之外，支持投递c++动态库以支持不同的排序策略、NLG策略等。

通过该平台将技能建设在线化、PD/RD/QA/运营分工明确pipeline生产。

统计分析平台

多维度的打点统计、报表、指标分析。涉及问题包括生产消费效率(通过统计引导内容生产的方向领域)、内容控制反馈、整体和独立技能的准召。

运营管理平台

运营管理平台分两块：内容运营、应用运营。
内容运营：关键域和模块的实时干预；
应用运营：应用/技能等增删改查以及训练；

注1：中间橙色为TaskBot引擎，下文展开介绍
注2：大图中TaskBot引擎、QABot引擎、ChatBot引擎为逻辑架构；物理架构上QABot和ChatBot级联到TaskBot中，有多个模块进行多路召回和pk判定

TaskBot引擎

TaskBot引擎是技能构建和消费的内核。它涉及离线计算、内容管理、调度、在线服务。

离线计算将外部平台的物料一一构建成对应的内部数据；包括实体词典、分类模型、意图识别&抽槽插件/pattern/模型、NLG策略和模板、DM剧本插件、US排序插件、webHook逻辑插件等等。
内容管理按应用/技能分版本的管理上述数据。内容管理要做到无状态，可快速移植、回滚、分发。
调度分为数据调度、环境管理、服务管理。数据调度负责离线到在线的数据分发，一套SDS引擎包含多个Role，每个Role都会加载对应的数据；环境管理负责迭代、验证、预发、生产环境的自动化管理；服务管理负责运维方面工作包括分行分列(按照应用流量分行，按照技能消耗分列)，扩缩容上下线等；
在线引擎：SDS引擎，见下图

SDS引擎是任务式对话的核心。它接受用户的query，以DM为控制中枢、以NLU为理解中枢、通过US做召回和rank、以NLG包装后输出。目前资讯播报、时区、限行、历史上的今天、单位换算、油价、日历、nba、lbs等技能天猫精灵上线技能触发率97-98%，准确率95%+；

DM(Dialog Manager)：即对话管理，是对话系统的关键部分，负责维护对话上下文，管理对话流程，保持对话过程的流畅。用户的输入通过NLU处理后产生意图、槽位等信息，DM根据这些数据以及当前对话的上下文做出对应的决策和行为，包括调用NLG模块生成自然语言、通过外部服务接口获取对话过程中所需要的额外信息。DM以任务树的方式管理对话，树的每个节点都是一个Agent(询问、执行、回应)；考虑到对话系统的通用性和可扩展性，我们在对话管理模块的设计上，将对话引擎部分和领域相关部分做了明确的隔离，包括可重用的对话Agent组件、可编辑的对话控制选项、通用的外部调用机制等，可方便地自定义不同功能的Agent，实现不同的对话场景。

对话引擎在流程控制上有两个重要的组成部分：

对话执行栈：通过栈的形式维护Agent的执行状态，根据上下文对对话流程进行控制。对话栈将Agent放入栈中，由栈顶的Agent执行并选择出合适的子Agent继续入栈执行。对话栈存储对话的上下文信息，对应着一个具体的对话场景。对话栈顶的Agent可形象的理解为对话焦点，对话栈结合Agent关系树和话题议程表可实现对话焦点的跟踪和管理，可灵活的保持、切换、回溯对话主题。
话题议程表：负责维护和管理对话过程的参数信息，用于收集系统期望得到的用户输入。议程分为多个层次，每个级别对应于对话框堆栈中的一个Agent，因此对于不同的运行栈信息，议程表代表了在这个对话场景下所期望的输入。当用户保持或转移话题时，能找到相应的期望参数并更新。

DM的执行单元是"剧本"，用户在开放平台或生产平台通过拖拽方式构建的剧本树最终会被构建成c++的so被加载执行。目前通过DM与NLU的结合已在多个技能上完成了省略替换、指代消解、话题转移、错误处理等多轮对话。

NLU：NLU有两种不同的设计理念：

围绕BotFramework的NLU：将用户query结构化为Domain/Intent/Slot后返回给开发者(带上置信度)，有些BotFramework产品需要用户自己判断是否接受这个结果，在技能较多的情况下会更麻烦，因为这种设计下核心帮助用户解决的是语义理解的问题
围绕对话产品的NLU：结合NLU的分类和召回的结果做多维NBest策略，这在信息服务场景尤为重要，比如用户说了个李白，它可能是诗人李白、可能是撒贝宁的妻子李白、也可能是李荣浩的《李白》，这里有不同的处理方式，比如借助大搜索用户点击、借助用户的历史行为、甚至可以DM上直接反问哪个李白

上述2自然涵盖1，神马的NLU是2的模式。今年NLU系统经历了两次大的升级，一次是整个SDS的NBest升级，一次是子NLU化，子NLU可以让不同的Domain根据自身特别内部个性化定制意图识别和抽槽策略、并提升RD并行度。

NLG/US/Skill-Gateway 不再展开。

QABot引擎

业界对问答有不同的划分维度，按照内容维度可划分为结构化数据问答、非结构化数据问答、以及基于问答对的问答。而从技术角度看，业界一般分为基于检索式的问答系统和基于生成式的问答系统。前者是将信息检索系统构建于大规模对话数据集之上，通过建立有效的问句匹配和问答相关度量化模型实现对用户问题的合理回复；后者则试图通过构建端到端(End-to-End)的深度学习模型，从海量对话数据中自动学习query和response之间的语义关联，从而达到对于任何用户问题都能够自动生成回复的目的。

我们当前主要专注于基于海量数据的检索式QA系统，而在系统层面划分为：KG-QA、Baike-QA、DeepQA、PairQA，它们都是对既有知识的搬运整理，但是在数据来源/要求、加工方式、匹配方式、覆盖场景又不尽相同。笔者认为世界的理想终局是结构化的(知识库)，但是这个永远无法真正实现，比如信息的持续产生和更新以及自然语义处理的难度，所以需要两个方向同时并行前进。

KG-QA和Baike-QA准确高但是覆盖有限，基于非结构化的Deep-QA覆盖高但是污染大，Pair-QA的社会化生产大幅提升生产力但是需要好的场景和问题，诸多的挑战决定了问答的难度和壁垒。

这里主要介绍PairQA和DeepQA系统如下图所示：

问题理解
问题理解是问答系统理解用户意图的关键一环，特别是DeepQA。这里我们复用了大搜索基础NLP的能力(语义扩展，权重分析，实体识别，改写纠错等)；问题分类结合机器学习分类算法和人工的方式，来实现提问的分类，比如：无意义、闲聊、人物、组织、时间等；焦点词识别，主要完成信息需求的精准定位，指问句的主要背景或者对象、有关主题的内容，能够体现对话题的描述性作用，比如实体、属性、动作、实例等。
信息检索

信息检索负责从全局语料中检索相关/候选信息，传递给最终的答案生成模块。信息语料的不同，以及业务场景的不同，检索的方法也有多种形式，目前我们主要使用的是基于倒排的文本检索和基于向量的语义检索。前者是传统的全文搜索引擎采用的方式，优点是实现简单、准确率高，但对建库语料依赖大，后者则是语义搜索引擎一种较好的实现方式，优点是泛化能力强，但有一定误触发率。两套索引机制各有优缺点，结合不同的语料和业务场景，使用不同索引机制，同时也会相互结合使用，发挥各自的优势。

答案生成

基于检索端的候选答案，需要通过进一步的精排、答案抽取、置信度计算，最终得到准确、简洁的答案。PairQA，更多的是通过CNN、DSSM、GBDT等机器学习模型和方法做严格的排序 + 置信度计算；DeepQA，面向的是非结构化的文档/社区语料，则需要做更深层次的处理，包括结合Bi-LSTM RNN模型的简洁摘要抽取、同义问题答案间交叉验证、答案相关性验证等。

语料建设

语料库的建设是QABot的基础，不管是面向特定领域的问答（比如：母婴、三国、街舞），还是面向开放域的问答（比如闲聊），都离不开高质量语料的支持。针对天猫精灵场景，我们实现了一整套面向口语化问答的数据挖掘和运营生产流程，包含开放问题挖掘、场景问题挖掘、社会化答案生产、高质量答案自动抽取。

图谱引擎

知识图谱是神马搜索的核心基础设施，借助搜索大数据和自然语言处理、深度学习技术打造，也是历史最悠久的数据产品，在搜索知识化、智能化发展历程中发挥了关键作用。基于知识图谱和自然语言理解，我们构建了知识卡片、实体推荐、精准问答三个主要产品。在智能对话业务，针对音箱的场景，还重点建设了菜谱、古诗词、三国、世界之最等特色技能，输出到天猫精灵。而在生产侧，一方面持续引入知识抽取、知识推理的前沿新技术，另一方面也建立了图谱的社会化生产模式，来持续建设和补充专业领域的知识，使知识图谱更好地为业务赋能。