阿里妹导读: 智能对话是搜索引擎的未来形态阿里的神马搜索在发展全网搜索国内信息流国际信息流等大数据业务的同时, 智能对话的探索和沉淀也逐渐浮出水面过去一年基于搜索推荐多年的积累, 我们完成了平台架构生产体系算法体系运营体系的建设, 为阿里集团多个业务方提供了智能信息中台服务, 承载了天猫精灵音箱后台的对话问答, 并在个人语音助手上大幅前进本文主要介绍神马搜索智能对话的内容体系和平台架构, 篇幅有限一些细节不做过多展开
术语对齐
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 包装后输出目前资讯播报时区限行历史上的今天单位换算油价日历 nbalbs 等技能天猫精灵上线技能触发率 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-QABaike-QADeepQAPairQA, 它们都是对既有知识的搬运整理, 但是在数据来源 / 要求加工方式匹配方式覆盖场景又不尽相同笔者认为世界的理想终局是结构化的(知识库), 但是这个永远无法真正实现, 比如信息的持续产生和更新以及自然语义处理的难度, 所以需要两个方向同时并行前进
KG-QA 和 Baike-QA 准确高但是覆盖有限, 基于非结构化的 Deep-QA 覆盖高但是污染大, Pair-QA 的社会化生产大幅提升生产力但是需要好的场景和问题, 诸多的挑战决定了问答的难度和壁垒
这里主要介绍 PairQA 和 DeepQA 系统如下图所示:
问题理解问题理解是问答系统理解用户意图的关键一环, 特别是 DeepQA 这里我们复用了大搜索基础 NLP 的能力(语义扩展, 权重分析, 实体识别, 改写纠错等); 问题分类结合机器学习分类算法和人工的方式, 来实现提问的分类, 比如: 无意义闲聊人物组织时间等; 焦点词识别, 主要完成信息需求的精准定位, 指问句的主要背景或者对象有关主题的内容, 能够体现对话题的描述性作用, 比如实体属性动作实例等
信息检索信息检索负责从全局语料中检索相关 / 候选信息, 传递给最终的答案生成模块信息语料的不同, 以及业务场景的不同, 检索的方法也有多种形式, 目前我们主要使用的是基于倒排的文本检索和基于向量的语义检索前者是传统的全文搜索引擎采用的方式, 优点是实现简单准确率高, 但对建库语料依赖大, 后者则是语义搜索引擎一种较好的实现方式, 优点是泛化能力强, 但有一定误触发率两套索引机制各有优缺点, 结合不同的语料和业务场景, 使用不同索引机制, 同时也会相互结合使用, 发挥各自的优势
答案生成基于检索端的候选答案, 需要通过进一步的精排答案抽取置信度计算, 最终得到准确简洁的答案 PairQA, 更多的是通过 CNNDSSMGBDT 等机器学习模型和方法做严格的排序 + 置信度计算; DeepQA, 面向的是非结构化的文档 / 社区语料, 则需要做更深层次的处理, 包括结合 Bi-LSTM RNN 模型的简洁摘要抽取同义问题答案间交叉验证答案相关性验证等
语料建设语料库的建设是 QABot 的基础, 不管是面向特定领域的问答(比如: 母婴三国街舞), 还是面向开放域的问答(比如闲聊), 都离不开高质量语料的支持针对天猫精灵场景, 我们实现了一整套面向口语化问答的数据挖掘和运营生产流程, 包含开放问题挖掘场景问题挖掘社会化答案生产高质量答案自动抽取
图谱引擎
知识图谱是神马搜索的核心基础设施, 借助搜索大数据和自然语言处理深度学习技术打造, 也是历史最悠久的数据产品, 在搜索知识化智能化发展历程中发挥了关键作用基于知识图谱和自然语言理解, 我们构建了知识卡片实体推荐精准问答三个主要产品在智能对话业务, 针对音箱的场景, 还重点建设了菜谱古诗词三国世界之最等特色技能, 输出到天猫精灵而在生产侧, 一方面持续引入知识抽取知识推理的前沿新技术, 另一方面也建立了图谱的社会化生产模式, 来持续建设和补充专业领域的知识, 使知识图谱更好地为业务赋能
详情可阅读这两篇文章:
知识图谱数据构建的硬骨头, 阿里工程师如何拿下?
首次公开! 深度学习在知识图谱构建中的应用
总结
去年一年, 智能对话团队初步完成了从搜索到智能对话的技术升级, 在实战中沉淀出 AI + 信息服务的架构算法运营内容体系感恩时代, AI 对话的路很长, 我们一起努力
你可能还喜欢
点击下方图片即可阅读
知识图谱数据构建的硬骨头,
阿里工程师如何拿下?
如何用架构师思维解读区块链技术?
十年前, 他如何自学技术进阿里?
关注 阿里技术
把握前沿技术脉搏
来源: https://juejin.im/entry/5ab1d0caf265da23945f5b85