术语对齐TaskBot引擎：核心处理对象是“技能”，我们??将技能定义为结构化（查询+内容）、垂直场景任务，比如实时场景查询、工具、控制类等QABot引擎：包括KG-QA引擎、QAPair引擎、DeepQA引擎。KG-QA主要是围绕全网知识图谱的百科全书和精准问答；QAPair引擎以问答为主，用于生产和消费；DeepQA引擎是基于url索引、分类聚类、焦点词、摘要的多级系统ChatBot引擎：包括基于检索的网页搜索和智能对话是承载信息服务的不同方式，它们在同一在数据、算法和体系结构方面。正是因为有了这样的积累，谷歌和其他搜索引擎公司才能快速推出基于信息服务的AI平台和产品给B/C。第一阶段行业技能库：团队用半年时间对BigSearch100+垂直行业进行结构升级，涉及行业从娱乐、旅游、新闻资讯，到汽车、体育、旅游，再到小二股票、翻译、古诗词等：技能进一步结构化升级，精细查询结构化，多轮对话构建，输出至天猫精灵音箱全网知识图谱。知识卡片、实体推荐、精准问答等产品输出；问答库社区问答库：基于UGC问答社区的问答库，1Bdoc量级；UPGC制作：神马“骑士团”建立的校园制作系统，项目代号为充分利用校园对存量知识进行整理、加工、复习，提高制作效率和问答质量；目前有数万名学生参与；优质库：社区问答库覆盖率高但质量参差不齐，社会化生产质量高但数量相对较少。通过社区问答库的机器清洗和社会化生产库的扩容，最终沉淀出优质库；蛋清库：蛋清是一种产品策略。用户与机器人对话时，最希望得到直接的回答，即“蛋黄”，但有时机器能得到（或部分得到）用户的问题，却不能给出最佳答案。这时候，给用户“蛋清”也是一个不错的主意。一种优雅的方式来表明我理解你；蛋清最新版已上线，主要覆盖“描述/方法”题型；核心库采用运营+挖矿的方式运营，净化互联网环境，提升内容质量。核心库的进程；技能库+知识库+问答库+聊天库构成了信息服务场景下智能对话的基础设施。我举几个例子来说明不同库对不同查询的满足程度。小马看一场NBA比赛，他说：“火箭现在领先多少分？”->技能库“谁发明了篮球？”->知识库《哈登能否进入名人堂？》->问答库“我们来谈谈NBA吧？”->聊天库通用信息服务一直追求问答的覆盖面和质量，这也是行业的难点，包括半结构化/非结构化数据的处理、内容生产方式、内容敏感问题，用户满意度等；Whatsmart搜索在一年的探索中积累了多层次的QA体系，MOPU（Machine/OGC/PGC/UGC）多元化生产、流程化、规模化、可持续的生产体系??，走在行业前列；在最新天猫精灵理想查询收藏测评，触发率达到73%，准确率达到91%。这个数据是什么概念，可以参考行业代表性产品的指标：根据StoneTemple最近的调查，谷歌虚拟助手可以回答68%的用户问题，回答正确率为90.6%，而MicrosoftCortana可以回答56.5%的用户问题，准确率为81.9%，而Apple的Siri可以准确回答21.7%的用户问题。准确率为62.2%，亚马逊Alexa回答用户问题的比例为20.7%，准确率为87%。“引擎”负责数据的构建和计算的承载，“平台”负责围绕引擎构建的闭环解决方案（生产、多租户消费、运营、需求管理等）.系统的落地，归功于多年搜索的积累和沉淀。系统与搜索业务完全解耦，承载天猫精灵等业务方流量（以及双十一直播问答）。下面将分别介绍上帝降临平台、Ta??skBot引擎、QABot引擎。神之降临平台神之降临平台是TaskBot引擎的平台扩展，解决技能生产、消耗、运营等问题。对于外部开发人员，它是BotFramework；对于外部调用者，是神马整个智能对话的入口和出口；对于内部研发，它是一个生产和运营平台。目前该平台主要服务于集团内部业务。GodComes由技能开放平台、技能制作平台、统计分析平台、运营管理平台组成。技能开放平台的开放分为两个层次：内容开放+能力开放。相应的技能开放平台也承担了两个角色：1.能力开放（BotFramework）：相对于标准的api.ai技能构建平台，外部开发者构建自己的技能；2、内容消费（OpenAPI）：通过创建应用，选择技能/问答，直接通过API进行智能对话；目前我们还没有对外推广BotFramework：虽然有很多开放平台产品，但是目前的模式很难满足开发者的需求，一个技能需要从产品规划到上线的量大、链条长的工作road不是提交一些语料，配置一些上下文和输出就可以完成的（简单的控制类勉强可以做到）。我们第一期技能完成的20+个技能下大概有300+个不同的意图，建立了语料收集、标注、审核、建模、测试的完整流程。所以我们的精力主要集中在打磨真正好用、能产生实际价值的内建技能上。技能制作平台技能制作平台用于制作内置技能。与技能开放平台的角色一致，最终将素材交付给TaskBot引擎，但用户是内部RD，涵盖从产品PRD到技能上线的全链路流程，涉及结构化PRD的在线编写、需求管理、以及语料库管理、实体管理、技能构建、技能训练、技能验证、技能发布。对于技能的普适性，我们以技能组的形式为每个技能支持多种场景：标准无屏、手机有屏、大屏、标准无屏类似天猫精灵音箱的场景，手机为神马个人助理场景，它们是多轮需求、结构化展示、排序策略不同；除了内置技能的素材，除了实体、语料、脚本之外，还支持c++动态库的传递，支持不同的排序策略、NLG策略等。通过这个平台，技能构建在线，以及PD/RD/QA/运营分工明确，管线生产。统计分析平台提供多维度的管理统计、报表、指标分析。涵盖的问题包括生产和消费的效率（通过统计指导内容生产的方向域）、内容控制的反馈以及整体和个人技能的对齐。运营管理平台运营管理平台分为内容运营和应用运营两部分。内容运营：实时介入重点领域和模块；应用操作：应用/技能的增删改查、训练；注1：中间的橙色是TaskBot引擎，下面会介绍注2：大图中的TaskBot引擎、QABot引擎、ChatBot引擎是一个逻辑架构；物理架构上，QABot和ChatBot级联成TaskBot，多模块召回和pk判断TaskBot引擎TaskBot引擎是技能构建和消费的核心。它涉及离线计算、内容管理、调度、在线服务。离线计算将外部平台的素材一一构造出对应的内部数据；包括实体字典、分类模型、意图识别&槽位插件/模式/模型、NLG策略与模板、DM脚本插件、US排序插件、webHook逻辑插件等。内容管理对以上数据进行管理应用程序/技能版本控制。内容管理应该是无状态的，可以快速移植、回滚、分发。调度分为数据调度、环境管理和服务管理。数据调度负责离线到在线的数据分发。一套SDS引擎包含多个角色，每个角色会加载对应的数据；环境管理负责生产环境的迭代、验证、预发布、自动化管理；servicemanagement负责运维工作包括分枝分列（按应用流量和技能消耗），扩缩容等。线上引擎：SDS引擎，见下图。SDS引擎是任务型对话的核心。它接受用户的query，以DM为控制中心，以NLU为理解中心，通过US召回排序，与NLG打包后输出。目前信息播报、时区、出行限制、历史上的今天、单位换算、油价、日历、nba、lbs等技能天猫精灵触发率97-98%，准确率95%+;DM(DialogManager)：即对话管理，是对话系统的关键部分，负责维护对话上下文，管理对话过程，保持对话过程的顺畅。用户的输入经过NLU处理，生成意图、槽等信息。DM根据这些数据和当前对话的上下文做出相应的决策和动作，包括调用NLG模块生成自然语言，通过对外服务接口获取对话过程的需求。附加信息。DM以任务树的形式管理对话，树的每个节点都是一个Agent（查询、执行、响应）；考虑到对话系统的通用性和可扩展性，在对话管理模块的设计中，对话引擎部分与领域相关部分明确分离，包括可重用的对话代理组件、可编辑的对话控制选项、通用的外部调用机制等，可以轻松定制不同功能的代理，实现不同的对话场景。对话引擎在流程控制上有两个重要的组成部分：对话执行栈：以栈的形式维护Agent的执行状态，根据上下文控制对话过程。对话栈将Agent放入栈中，栈顶的Agent会执行它并选择一个合适的子Agent继续入栈执行。对话栈中存放的是对话的上下文信息，对应特定的对话场景。对话堆栈顶部的代理可以可视化为对话焦点。对话栈结合Agent关系树和话题议程，对对话焦点进行跟踪管理，可以灵活维护、切换、回溯对话话题。TopicAgenda：负责维护和管理对话过程的参数信息，用于收集系统期望的用户输入。agenda分为多个level，每一level对应对话栈中的一个Agent，所以对于不同的runningstack信息，agenda表代表了这个对话场景下的预期输入。当用户保留或更改主题时，可以找到并更新相应的期望参数。DM的执行单位是“脚本”。用户在开放平台或生产平台通过拖拽方式搭建的脚本树，最终会构建成C++so并加载执行。目前，通过DM与NLU的结合，已经在多个技能中完成了省略与替换、引用解析、话题转移、错误处理等多轮对话。NLU：NLU有两种不同的设计理念：NLU围绕BotFramework：将用户查询结构化为Domain/Intent/Slot并将其返回给开发人员（有信心）。有些BotFramework产品需要用户判断是否接受结果，在技能比较多的情况下会比较麻烦，因为这种设计的核心是帮助用户解决围绕对话产品NLU的语义理解问题：结合NLU分类和召回的结果做出多维的NBest策略，这在信息服务场景尤为重要。比如用户提到李白，可能是诗人李白，撒贝宁的妻子李白，或者是李荣浩的《李白》。用户的历史行为甚至可以直接在DM上询问是哪位李白。上面2自然涵盖了1，神马的NLU是2模型。今年NLU系统进行了两次大升级，一次是整个SDS的NBest升级，一次是sub-NLU。sub-NLU允许不同领域根据自身特殊的内部个性化定制意图识别和槽位策略，提高RD并行度。花费。NLG/US/Skill-Gateway不再扩展。QABot引擎行业对于问答有不同的划分维度。按内容维度可分为结构化数据问答、非结构化数据问答、基于问答对的问答。从技术角度来看，业界普遍分为基于检索的问答系统和基于生成的问答系统。前者在大规模对话数据集上构建信息检索系统，通过建立有效的问句匹配和问答相关量化模型，实现对用户问题的合理回复；后者试图建立一个端到端（End-to-end）-End）的深度学习模型，从海量对话数据中自动学习query和response的语义关联，从而达到自动化的目的生成对任何用户问题的响应。我们目前主要做基于海量数据的检索QA系统，在系统层面分为：KG-QA、Baike-QA、DeepQA、PairQA，都是对已有知识的处理和整理，但在数据来源/需求、处理方式、匹配方式、覆盖场景等方面都有所不同。作者认为理想的世界末日是结构化的（知识库），但这永远不可能真正实现，比如信息的不断产生和更新，自然语义处理的难度，所以需要两个方向推进平行线。KG-QA和Baike-QA准确率高但覆盖面有限。UnstructuredDeep-QA覆盖率高但污染严重。Pair-QA的社会生产大大提高了生产力，但需要好的场景和问题。诸多挑战决定了问答的难度和壁垒。这里主要介绍下图所示的PairQA和DeepQA系统：问题理解问题理解是问答系统理解用户意图的关键环节，尤其是DeepQA。这里我们复用了大搜的基础NLP能力（语义扩展、权重分析、实体识别、重写纠错等）；问题分类结合机器学习分类算法和人工方法实现问题的分类，如：无意义、八卦、人物、组织、时间等；焦点词识别，主要完成信息需求的精确定位，指的是问题句子的主要背景或对象，以及话题的内容，能体现话题的描述作用，如实体、属性、actions,examples等InformationRetrievalInformationretrieval负责从全局语料库中检索相关/候选信息，并将其传递给最终的答案生成模块。根据信息语料和业务场景的不同，有多种检索方式。目前，我们主要使用倒排文本检索和基于向量的语义检索。前者是传统全文搜索引擎采用的方法。优点是实现简单，准确率高，但对建库依赖语料库。后者是语义搜索引擎较好的实现方式。优点是泛化能力强。但是有一定的误触发率。这两套索引机制各有优缺点。结合不同的语料和业务场景，采用不同的索引机制，它们也会相互结合使用，发挥各自的优势。答案生成是基于检索端的候选答案，需要进一步细化、抽取答案、计算置信度，最终得到准确简洁的答案。PairQA，通过CNN、DSSM、GBDT等机器学习模型和方法进行更严格的排序+置信度计算；DeepQA，针对非结构化文档/社区语料，需要进行更深层次的处理，包括结合Bi-LSTMRNN模型的Concisesummaryextraction，同义问题答案之间的交叉验证，答案相关性的验证等。QABot的基础。无论是特定领域的问答（如母婴、三国志、嘻哈），还是开放领域的问答（如聊天），都离不开优质语料的支持。针对天猫精灵场景，我们实现了一套完整的口语问答数据挖掘和运营生产流程，包括开放式问题挖掘、场景问题挖掘、社会化答案生产、自动抽取优质答案。GraphEngineKnowledgeGraph是WhatsmartSearch的核心基础设施。它是借助搜索大数据、自然语言处理和深度学习技术构建的。它也是最古老的数据产品，对知识搜索和智能搜索的发展起到了关键作用。基于知识图谱和自然语言理解，我们打造了三大主打产品：知识卡片、实体推荐、精准问答。在智能对话业务上，针对音箱场景，也重点打造菜谱、古诗词、三国志、天下第一等特色技能，并输出到天猫精灵。在生产端，我们一方面不断引入知识抽取和知识推理的前沿新技术，另一方面也建立图的社会化生产模型，不断构建和补充专业领域的知识，让知识图谱更好的为业务服务。授权。总结去年??，智能对话团队初步完成了从搜索到智能对话的技术升级，并在实战中沉淀了AI+信息服务的架构、算法、运营、内容体系。感恩时代，AI对话任重而道远，让我们一起努力。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
