AI 中台——智能聊天机器人平台的架构与应用

随着“中台”战略的提出，目前宜信中台建设在思想理念及架构设计上都已经取得了很多成果。宜信是如何借助中台化的思想打造“AI 中台”及相关的智能产品呢？宜信科技中心 AI 中台团队负责人王东老师分享了宜信 AI 中台的具体实施路径，并重点介绍了 AI 中台的智能产品——智能聊天机器人平台，包括智能聊天机器人平台的背景理念、设计思想、技术架构和应用场景，该平台能提供什么样的能力，以及它如何快速地支持业务方，提供一种以中台化的思想来建设智能产品的实践思路。

一、AI 中台总体设计和实施步骤

1.1 业务演进与广泛的智能化需求

随着业务的不断发展，业务处于不同的发展阶段，对数据的需求也从刚开始的可用-满足 BI 分析，到后来的易用-敏捷化分析，到现在的好用-数据智能化。例如前台系统提出客户细分、个性化推荐、智能问答、模型预测等需求，后台数据探索需要进行关联分析、聚类分析、持续分析等，这些都向我们提出了数据智能化的需求。

• 数据平台化能够解决数据可用性的问题，提供数据的平台化管理、数据存储、数据计算、管理、运维等功能；

• 数据中台化可以解决易用的问题，提供自助化、敏捷化的支持，并为数据的资产化、融合化、运营化提供支持。

• 数据智能化解决了好用的问题：从数据洞察到学习预测，数据驱动创新。

1.2 从数据中台到 AI 中台

数据中台除了提供平台能力以外，还提供了一些更高级的能力，比如把数据变成一种基础服务提供给业务方，业务方可以以自助的方式在数据中台上获取数据、进行数据处理、数据探索、数据挖掘、分析钻取、多维分析、自助化报表、数据共享等，以快速实现自己的商业价值。

随着业务的发展，越来越多智能化的数据需求被提出，这些智能化需求涉及到模型训练、数据标注、特征工程、模型部署、性能监控等，需要使用机器学习、深度学习等算法支持。数据中台的主要目标还是服务数据，对于智能化和模型并不能很好地支持，因此 AI 中台应运而生。

我们把智能服务的需求抽象出来，形成一个独立的 AI 中台层。AI 中台是一个用来构建智能服务的基础设施平台，对公司所需的模型提供分布分层的构建能力和全生命周期管理的服务，鼓励各个业务领域将基础性、场景性、通用性的 AI 能力沉淀到平台中，加强模型复用、组合创新、规模化，最终实现降本增效和快速响应业务方的目的。

1.3 数据中台和 AI 中台的关系

既然提到了数据中台和 AI 中台，很多人会问：数据中台和 AI 中台是什么关系呢？

数据中台和 AI 中台两者是相互依存、承前启后的关系。

首先，数据中台和 AI 中台都对外提供服务，只是侧重点不同。

• 数据中台提供各种数据服务和数据产品，例如：BI 报表应用、数据探索等。

• AI 中台提供各种智能服务和智能产品，并承担复杂的学习预测类智能需求研发、模型训练、特征工程、数据标注等能力。例如：模型预测、智能推荐等。

其次，数据中台和 AI 中台是相互依存，相互支持的。

• AI 中台依托数据中台提供的数据能力和工具集，加速 AI 相关服务的开发和复用，来应对前台智能化的业务需求。有了数据中台清洗好的数据，搭建智能项目能够事半功倍。

• 数据中台也需要使用 AI 中台的智能化能力，使得数据使用更加平民化和智能化。例如增强型 BI 分析：通用自然语言交互方式，降低 BI 使用门槛；通过 AI 分析给出参与建议，帮助普通用户在没有数据专家的情况下有效访问数据；增强型数据管理：利用机器学习来管理数据，包括数据质量、元数据管理、主数据管理等。

1.4 AI 中台需要解决的痛点

在过去，很多算法团队更像是算法外包团队，根据不同业务线的需求，各自构建阵地，逐个攻克目标。这样的形式虽然也取得了很多成绩，但存在重复建设、效率有限的问题。

我们将这些问题总结如下：

• “烟囱式”开发，项目成本高、不易集成，过程重复，缺乏能力沉淀。

• 模型访问方式各异，调用关系错综复杂，缺乏编排优化、协同。

• 手工进行数据操作，缺少统一数据访问渠道，数据获取难、标准不统一。

• 模型研发缺乏标准指导、参与角色众多，缺少协同、自动化辅助，难以有效管理沟通协作。

• 模型交付难，缺少统一的模型运行、监控平台、服务管理接口及更新、维护机制。

• 基础资源分散隔离，无法动态进行资源的分配和管理，造成浪费。

这些都是 AI 中台需要解决的痛点，针对以上痛点，我们希望：

• 对于算法、模型的标准化平台化，对研发过程标准化指导，以提高可复用性。

• 统一的服务接口规范，支持服务的动态编排组合。

• 与数据中台对接，利用数据中台的能力对数据进行标准化处理和预处理。

• 流程优化，清晰角色定义，构建 AI 产品流水线，具备环节内部、环节之间的自动迭代、流转功能。

• 提供统一的模型交付部署、运行环境和监控能力，以及模型更新机制。

• 统一资源管理，包括计算资源、存储资源等，支持资源弹性调度。

总结起来就是：可复用化、服务统一化、对接数据中台、流程角色优化、运行监控化和资源管控化，最终让 AI 中台成为一个强大的 AI 能力支持中心，根据业务需求快速提供火力支援，迅速完成商业价值。

1.5 AI 中台平台架构

下面介绍 AI 中台的平台架构。

最下面是数据中台，提供数据处理、数据分析、数据管理、数据安全、数据服务等能力。最上面是业务前台，包括各条业务线。AI 中台处于数据中台和业务前台的中间位置。

如图所示，整个 AI 中台由几个模块组成：

• AIHub 智能服务：以服务的方式将模型封装起来，提供模型服务运行平台能力。包括模型发布测试、自动部署、模型更新、模型交付、产品封装等。

• AIMon 平台监控：对运行的模型进行监控和预警，提供平台的监控服务。包括性能测试、状态反馈、预警通知等。

• AIKit 智能工具箱：提供轻量级、低侵入的 AI 工具服务，AI 应用团队可以自由选用。例如：通过无缝嵌入 python 语言开发环境，Moonbox 可以提供虚拟查询数据、混算数据等能力。也提供数据标注能力，包括结构化数据，以及文字、图像等非结构化数据的在线标注。

• AIMgt 中台管理：AI 中台的一些通用管理能力。包括：角色权限、租户管理、流程控制、资源管理等。

• AILab 智能试验室：提供标准的模型训练与优化过程支持。包括模型设计、模型训练、特征工程、特征处理、模型追踪、模型评估、算法库、模型库等。

• AIAsset 智能资产：用于模型资产管理，实现 AI 能力沉淀、复用、盘点。

• CUI 会话式 UI：这是我们 AI 中台的一个产品，就是接下来我们要介绍的可用于问答、闲聊、任务、推荐等场景的聊天机器人平台，从机器人平台的角度也包含语音外呼机器人。

1.6 AI 中台的能力架构

上图展示 AI 中台的能力架构。我们以能力的角度来描述 AI 中台对外输出。除了前文介绍的服务运行能力、监控预警能力、资源管理能力（就是图中左边的几个模块）以外，我们把 AI 中台的能力分为 4 层：

1）平台层

比如数据获取能力、在线训练能力、在线标注能力、特征工程能力、自助训练能力等。这些能力是通过 AI 工具集和 AIlab 来实现的。

这层的用户主要包括：

• 算法工程师（AI 中台、AI 团队），他们可以使用 AI 中台提供的平台层能力来进行在线训练、复用算法库、复用平台计算资源、进行各种实验等。

• 高级研发人员、数据分析人员，他们可以使用 AI 中台的自助训练能力，进行自助训练，例如：根据自己已经标注好的数据，自助训练分类模型。

2）AI 技术层

AI 技术层主要提供：AI 基础能力，包括词法分析、语音合成、文章分类、图像识别等，这些本质上是 AI 技术 NLP、语音、图像、视频等大分类里的能力。

3）AI 业务层

AI 业务层主要提供 AI 技术与业务相结合后能提供的能力，比如：评论观点提取、文章标签、卡证类识别、人脸识别、视频审查等。

AI 技术层和业务层的区别在于：AI 技术层主要提供 AI 基础能力，比如 NLP、CV、语音、视频等。而 AI 业务层主要是将 AI 技术与具体的业务场景结合起来，例如身份证识别、学历识别、验证码识别等。

这两层的用户是：业务团队的应用开发人员，可以直接调用智能服务，从而实现业务场景智能化，例如：短文本相似度、语言合成、票据识别等。

4）产品层

这一层以产品的形式对外提供服务，例如：智能机器人产品、知识图谱产品等。

这层的用户是：公司的业务人员或公司的直接客户，他们通过直接使用产品就可以获得结果， 例如：机器人。

上面 3 层都属于 AI 资产。从影响力角度来看，产品层的影响力最大，依次下来是业务层、技术层，最后是平台层。我们在 AI 中台的实施路径上，也会按照这个优先级去构建和实施。

1.7 AI 中台的建设思路-开放性

数据中台的口号是平民化和敏捷化。AI 中台的口号是开放化。

AI 中台的建设思路是希望多方联合，公开透明，广泛参与，协商一致促进 AI 能力沉淀，加强 AI 服务复用，降本增效。

我们更加关注于通用性的 AI 需求，为各个领域的 AI 应用团队提供通用化智能服务。强调平台性和可复用性，鼓励基础类、场景类 AI 服务的通用化、平台化。

广泛支持大中小业务领域 AI 应用团队面临的大量智能业务需求，提供模型学习平台与模型运行监控托管服务以及通用的 AI 工具，方便前台业务快速上线智能应用。在实施过程中也会充分利用包括数据中台在内的现有技术资源，并根据业务需求强弱和重要性来确定实施路线。

我们希望 AI 不再是锦上添花，而是必备的能力，让开发者重新回归到业务的理解和创意的赛道上来，关注自己的业务逻辑。AI 能力将会全部开放给开发者和使用者，这些能力包括语音、视频、自然语言处理、知识图谱等，我们会将这些能力封装好，开发者直接调用就可以。

二、机器人平台的背景、设计理念和技术架构

2.1 智能聊天机器人

基于中台化思想，我们是如何建设机器人平台的？

智能聊天机器人，是一种通过自然语言模拟人类进行对话的程序。

目前，特定场景和领域的聊天机器人已经展现出了很高的自然语言理解与处理能力，例如：小度、Siri、小爱同学等。

智能聊天机器人可以代替企业中相对固化、重复的人力密集型任务或流程，包括：

• 问题咨询：基于业务知识库进行业务问题解答。

• 数据检索：纵跨各业务系统或数据库，检索数据或文档。

• 业务处理：对接相关业务系统转达指令，完成相应业务操作。

典型的应用场景：智能聊天机器人除了可以闲聊以外，还可以用在问答作为问答机器人，回答专业领域的问题；作为任务机器人完成线上，甚至部分线下的任务；作为推荐机器人，推荐文章、音乐、产品；作为助理机器人，集成以上各种功能。

智能聊天机器人可以对外提供客户服务、对内进行业务辅助，实现全方位的效能提升，降本增效。

2.2 智能聊天机器人的本质：会话式 UI

智能聊天机器人的本质是会话式 UI。会话式 UI 是通过会话形式将已有数据、功能、服务展示给用户。

会话式 UI 与传统 UI 相比，具有独特的优势。

• 提高用户注意力。在信息碎片化的今天，用户注意力持续集中的时间不多，人们很容易为各种事情分心。在会话式 UI 中，信息是根据用户的指令需求逐步提供的，这样用户就不会被无关的信息干扰。

• 减少用户的挫败感。在会话式 UI 中，用户能进行的操作相对有限，这也避免了因用户行为带来不可控的高错误问题。让用户做简单的选择题，能降低用户思考的成本和系统错误率，最终能够实现让用户快速聚焦他们想要的东西，减少因操作带来的挫败感。

• 更高的投入产出比。会话式 UI 的另一个优势是性价比高。会话式 UI 用户界面上线后立即就能投入工作，不需要刻意进行训练学习，降低了使用成本，并且可以根据商业逻辑及应用情况随时将对话设计进行调整修改。

正如三星实验室高级设计师 Golden Krishna 所说：“最好的界面就是没有界面”。很多人认为语音交互比聊天机器人的干扰更小，能提供更好的使用体验。

这也是导致各种智能音箱在市场反响火爆的原因，语音交互已经走进千家万户、世界各地。

2.3 趋势：会话式 UI 与业务集成

目前会话式 UI 与业务系统紧密集成，是发展的主要趋势。通过集成各个业务系统，可以打造出专属的业务助手。如上图所示，我们可以将报表查看、指令集成、知识图谱查询、查询邮件等诸多服务集成到业务系统中，并且提供权限审核的功能，从而打造一个专属的业务助理。

一些行业预测认为：

• 未来，更成熟的技术使得聊天机器人能够更准确地识别用户的问题和意图。

• 客户服务是聊天机器人的主战场，是产生最大效益的领域。

• 聊天机器人在电商、通讯、保险、金融、旅行等领域广泛应用。

• 以大数据的增强型分析为例，使用自然语言 NLP 等交互方式，BI 使用门槛进一步降低。

Gartner 预测到 2020 年：50%的分析查询会通过搜索、自然语言处理或语音生成，或自动生成。一线业务工作人员通过自然语言处理和会话分析，来进行分析和使用商业智能产品的使用率从 35%提升到 50%以上。

2.4 智能聊天机器人建设过程

接下来详细介绍聊天机器人建设的过程。

智能聊天机器人建设是有难度的，比如机器人的智能化核心开发需要一定的 AI 研发能力；机器人需要全套的模型封装，以及数据管理、任务调度、权限控制等工程能力的支持等；各业务线均有广泛的需求，一个个实施起来将是很漫长的过程。

如果按照一条线一条线建设的方式，如图所示，AI 同事和平台同事支持第一个业务时，没有其他业务线的需求进来，按照项目的支持能够快速响应需求，这时的体验是很好的；而对于第二个业务来说，此时由于 AI 同事和平台同事正在支持第一个业务，第二个业务线的功能就会有所缺失，可以看到图中业务线 B 的机器人少了一条腿，这时就产生了等待；到第三条业务线，已经进入了需求排期阶段，AI 同事和平台同事对该业务线的支持就很有限了；同样的，后续的业务线都将处于等待状态，尽管业务方很生气，可 AI 同事和平台同事已经疲于奔命。

由此可以看出这种烟囱式机器人研发的缺点：耗时长、成本高。

那么如何才能高效地支持这些需求呢？

2.5 机器人工厂

以中台化思维来建设智能聊天机器人平台。通过平台化的建设、复用化的思想，使得我们的聊天机器人成为聊天机器人制造工厂。

• AI 模型复用化：AI 工程师构建通用 AI 模型，仅需少量具体的业务数据即可构建一个个性化的机器人核心。

• 工程能力平台化：平台化建设，提供一套全面的、通用化的机器人管理功能，将各种能力沉淀下来，实现工程模块和能力复用化。

我们在构建智能聊天机器人平台的过程中，将各个业务线的需求和能力都集成到平台中，提供给不同业务线使用，各业务线都复用这些能力，并且提供数据权限的高度隔离。

最后达到机器人流水式生产，管理功能高度复用，业务用户高速接入，迅速赋能全部领域。

2.6 智能聊天机器人平台设计考量

智能聊天机器人平台的设计考量包括以下几个方面。

1）平台化 or 项目制

既然我们用平台化方式去建设，就必然面临一些问题：平台化的好处是可以复用，事半功倍；缺点是难以兼容个性化。所以我们在平台建设过程中，要同时考虑什么样的功能属于平台、什么样的功能属于租户、什么样的功能属于公司，把公共的功能进行沉淀、把租户的功能进行定制化，这样才能既兼顾平台化的事半功倍，又能满足个性化的需求。

2）中台能力

• 多租户。我们以多租户的方式建设智能聊天机器人平台，基于用户角色来定义功能，平台管理员和租户功能进行能力划分。

• 自助化。所有功能自助化，管理和运维工作下放给租户，这样一来，租户就可以对自己的机器人进行相应的管理，平台的维护也会减少很多，而且不用再等排期。

• 隔离和安全。通过资源隔离（包括数据隔离和语科隔离）、算力隔离等将成本分摊计算出来，也可保证数据之间互相不影响。另外，基于功能角色和数据角色的双重角色正交的方式保证数据安全。

3）统一闭环

• 智能机器人平台是一个工程、算法、运营统一的结果。机器人不是一个简单的算法模型，需要模型运行、数据管理、权限控制、人工介入、客户端支持等，还需要运营的支持和鼓励，比如我们平台中引入的积分系统，根据积分情况来开展一些运营活动，鼓励大家使用一些功能。

• 通过运行过程中不断补充问题、在线标注、语料导出、自动训练、自动上线形成平台、数据和模型的闭环。比如我们开发了会话管理来进行在线标注，帮助用户快速补充问题。

2.7 智能机器人平台系统架构

上图所示是智能机器人平台的系统架构。

• 最上面是机器人对外提供的服务，通过 Web、APP、Restful API 对外提供服务。

• 中间是一个微服务层，使用 Spring Cloud 微服务架构，服务都注册在 Eureka 里。微服务包括了网关服务、调度服务、外部服务、商业逻辑服务、数据访问层、统计服务、通讯服务等。其中涉及到算法预测的模块是在 Python 的一个服务里，我们也将 Python 的服务注册到 Eureka 里，这也是我们称之为“模型即服务”的一种思想。

• 外接认证系统包括 LDAP、SSO、PS 等，外接系统包括各种 PC 端、APP 端、报表等。

• 数据存储在 Mongo 中，文档存储在 HDFS 里，检索使用 Eleastic-Search，统计使用 Click-house，人工后台通讯用 Rabbit mq，会话和上下文管理使用 Redis。

• 整个平台是微服务架构，支持容器化，支持使用 Conductor 模型编排，用 MQTT 协议以解决 APP 端网络不稳定的问题。

三、机器人平台的核心原理和主要功能点

3.1 机器人的核心技术

前文介绍了机器人平台的背景、设计理念和技术架构，接下来介绍机器人平台的核心原理和主要功能点。

智能聊天机器人最核心的部分是对话引擎，对话引擎包括：自动语音识别(ASR)、自然语言理解(NLU)、对话管理(DM)、自然语言生成(NLG) 和文本到语音合成(TTS)。

其中，自然语言理解（NLU）的目标是将文本转换成语义表示，文本中的单词语义并不重要，重要的是文本转化成了语义信息。简单来说，就是将人的语言转化成机器可以理解的结构化的完整的语义，让机器理解人的语言。

我们通常说的 NLP 自然语言处理其实是一个大的集合，包含了 NLU 自然语言理解和 NLG 自然语言生成，并且包含了它生成上面的处理部分和下面的应用阶段，所以 NLU 和 NLG 都是 NLP 的一个子集，它们不是平级的关系。

DM 是对话管理系统的大脑，负责更新对话状态。对话引擎的难点在 NLU 和 DM。

总的来说，这些技术都是属于自然语言处理技术（NLP，Natural Language Processing），本质上我们需要使用 NLP 技术来解决聊天机器人的问题。

对于用户的一个问题，需要将这个自然语言问题通过一个模型（这个模型是我们用机器学习基于大量数据训练和归纳得出来的），转换为机器能理解的数据形式(我们将这种数据形式称之为向量)。

NLP 技术除了用于智能聊天机器人以外，还用在很多领域，例如：句法语义分析、信息抽取、文本挖掘、机器翻译、信息检索、对话系统等领域。

3.2 机器人原理

智能聊天机器人是由多个机器人组成，包括问答机器人、闲聊机器人、任务机器人等，人工后台以及文档库之间协作完成任务，最终选择最优答案返回给用户。

如图所示，用户提一个问题过来：

• 首先 ASR 将语音转成文本，这时候涉及到了调度。平台服务和任务调度认为这是一个机器人的问题，就进入预处理阶段。

• 预处理包含分词/去停、词表映射、词性分析、句法分析、实体识别、句子复述、关系提取等；

• 然后进入分析阶段，包括领域分析、问题分类、意图检测以及 bot 识别等；

• 然后转到不同的机器人，比如 QA 机器人-解答用户对事实和非事实类的问题、闲聊机器人-解答用户情感方面的表述和对客观问题的讨论、任务机器人-满足特定场景的任务操作、场景机器人、知识图谱机器人等；

• 之后将结果汇集到融合排序层，进行加权重排答案矫正；

• 最后经过用户权限过滤，生成答案，将答案经过 TTS 合成语音反馈给用户。

如果这个问题机器人不能解答，就会转入人工后台，或转到搜索引擎进入文档的搜索检索，最终将最优答案返回。

3.3 QA 机器人

QA 机器人的本质是：假设用户提了一个问题 Q，QA 机器人需要从已有的 QA 数据库中寻找最合适的 QA 对返回，QA 机器人会进行 QQ 相似度计算和 QA 匹配度计算，通过综合相似度与匹配度，找到最适合的一组 QA 对 (Qi, Ai)，即最佳答案返回。

解决方案 1：NN 模型

常见的网络模型包括 RNN 和 CNN 模型。例如双层编码(Decoder)的长短期记忆模型（LSTM）。这种模型在很多场景下都比较好用，网络模型的主要缺点是需要一定数量的样本。

解决方案 2：拆分成子问题。

在语料比较小的情况下，将问题进行拆分，分为两个阶段：

把问题变成一种短文本语义表征，通常有 tfidf、w2v。

然后再进行语义距离计算，例如计算向量的余弦距离。

它的优点是在语料比较小的情况下效果不错。

3.4 QA 机器人原理(QQ 匹配）

这里以 QQ 匹配来介绍 QA 机器人原理。

QQ 匹配包括几个部分：句向量化、相似度计算、相似度排序。

• 句向量化是使用 BoW 词袋模型和同义词扩展，将句子的词转换成向量；

• 然后再与问题库里的词进行相似度计算，计算出余弦相似度；

• 用余弦距离产生相应的结果，按照相似度大小排序返回答案列表。

句向量我们是通过词袋模型和同义词扩展来表示的。

什么是词袋模型？词袋模型就是忽略文本里的词序、词法、句法，只将它看做一个词的集合，把它当成一个词袋。

还引入了同义词扩展。在实际的问题中，不同的词可能存在不同的问法，但其语义相同，所以进行一些同义词等价，这样就形成了词向量。向量的值是 TF-IDF 值，用于表示权重。

TF-IDF 模型（term frequency–inverse document frequency，词频与逆向文件频率）。TF-IDF 是一种统计方法，用以评估某一字词对于一个文件集或一个语料库的重要程度。TF-IDF 的主要思想是，如果某个词或短语在一篇文章中出现的词频高，并且在其他文章中很少出现，则认为此词或者短语具有很好的类别区分能力，适合用来分类。

TF-IDF 有两个值，一个是词频率，另一个是 IDF（inverse document frequency，逆向文件频率）。如图中的计算方式。

举个例子，库中 10000 篇文档，10000 篇提到“母牛”，其中 10 篇提到“产奶量”，比如一篇关于“母牛的产奶量”的文字，这篇文章有 100 个词，“母牛”出现 5 次，“产奶量”出现 2 次)。

通过计算发现，虽然“母牛”的词频率很高，但 IDF 值很低，最后“母牛”的 TF-IDF 很低，也就是说这个词不具太大的标识度。而“产奶量”这个词的词频率不高，但它的辨识度很高，最终它的 TF-IDF 也很高。

具体执行过程如图所示。

• 首先拿到一个语句，进行分词、去停用词、去重，得到一个词序列。然后遍历每一个词进行 TF-IDF 计算，如果在同义词表里，就计算词 TF-IDF 并求平均值；如果在词库中，就计算 TF-IDF 值；如果不在词库中，就直接忽略，最后形成词对应的 TF-IDF 值，并将 Value 向量单元化。

• 接下来我们要计算向量和向量之间的距离，这里我们采用余弦距离。计算方式如图所示。

• 当两个词向量的余弦值接近 1 的时候，两个词向量相似，也就是两个句子相关。否则就不相关。通过计算余弦值来最终达到判断句子的相似度。

上文介绍的 QQ 匹配是属于一种基于检索的聊天机器人，另一种对应的分类是基于模型生成的表情机器人。

基于检索的聊天机器人：

• 特点是回复数据是预先存储且知道（或定义）的数据。

• 优点是问题与答案都经过人工总结，保证了数据库中的答案正确性，表述自然、易于理解。

• 缺点是用户提问的各种问题，机器人都试图在库上寻找答案；问题数有限，无法覆盖用户的所有问题；需要不断总结、扩展，争取覆盖大多数问题。

生成模型的聊天机器人：

• 特点是创造出崭新的、未知的回复内容（模型没有见过），类似机器翻译技术。

• 优点是不需要预先存储且定义好的数据，比起检索模型更加的灵活多变。

• 缺点是生成效果不佳，生成的答案可能有一些语法错误和语义无关的内容；生成式模型需要海量的训练数据，且难以优化；结果无法控制。

目前的现状是，在商业领域，工业级标准还是会使用基于检索的机器人，适合特定领域内、问题集合有限，还有一些变体，比如知识图谱、基于 KG 的机器人、基于搜索引擎的机器人。而生成模型的机器人，是学术界研究的重点，在商业领域，它会作为检索式机器人的补充形式，两者结合使用，

3.5 闲聊机器人原理

闲聊机器人主要是进行客观话题讨论，用户对聊天机器人进行一些情感表达，回答问候、情感和娱乐等信息。闲聊处理由两个组件组成：

• 基于预置规则匹配：公司合规用语要求。

• 基于聊天库中海量闲聊语料：满足大多数闲聊应答。

海量的闲聊语料，可以从在线论坛、微博对话、甚至别的通用机器人爬取，虽然从各个地方爬取，也需要审核，以满足用户需求。

闲聊机器人的要求是：简单闲聊、结果可控、快速开发。所以实现上我们基于 AIML 构建闲聊机器人。

AIML 是由 Richard Wallace 发明的一种语言。他设计了一个名为 A.L.I.C.E.（Artificial Linguistics Internet Computer Entity 人工语言网计算机实体）的机器人，并获得了多项人工智能大奖。AIML 是一种为了匹配模式和确定响应而进行规则定义的 XML 格式。

AIML 的能力很灵活，如图所示，可以基于模板匹配、任意字符匹配、元素提取、一个问题多个答案、划分主题等。

AIML 来作为知识载体的好处是灵活、人性化强。缺点是在知识的编写方面门槛高，比如闲聊库的扩充方面的问题等。

好在有现成的 AIML 编辑软件，如：SimpleAIMLEditor，GaitoBotAIMLEditor 等。

AIML 语言的规范也在不断升级，最新版本 AIML2.0。

3.6 任务机器人原理

任务机器人（Task-Bot） 的关键技术是基于意图识别与语义槽提取。举个例子，A 说“帮我订一个今天下午 3 点到 4 点的会议室吧？要大一点的。”机器人识别出来这是一个任务，而这个任务要完成必须三个语义槽：时间、地点、大小。

经过分析发现 A 的任务请求中缺乏一个语义槽-地点，于是触发机器人反问“请问您要预订哪个职场的会议室？”，A 补充了地点后，机器人联动会议预定系统，进行会议室预定，完成任务并反馈结果给 A。

这个过程涉及了：意图识别、关键参数提取、多轮对话 &对话管理、配置化、对接外部系统。

以上图的一个实际例子来看，这个例子是根据身份证号查询归属地。

首先配置可能的问法，这里可以看到，设置的可能问法越多，越能帮助机器人识别意图。这里主要涉及到意图识别和设置可能问法。

然后配置需要提取的槽值，槽值来自一个实体，这里的槽值是身份证。并且配置如果没有提取到的话，需要追问的问题。可以在线进行测试槽值提取。

接下来配置触发的外部系统，这里支持常见的 post，get，将相应的槽值发送给系统，然后获得返回值，再从返回值中提取必要信息，用于显示正确情况和错误情况。

最后看到的效果如上图所示，整个过程涉及到多轮对话和话题追踪。

3.7 场景机器人原理

场景机器人可以说是任务机器人更高级的版本，它是基于预置规则驱动完成场景任务。

上图示例中，销售人员 G 想查客户李国强的信息，机器人给出相应信息后，根据预设的场景，触发后台配置的一个业务推荐流程，根据这个流程，销售人员可以获得适合李国强客户的产品推荐、了解相关产品情况、进行话术演练等，本来只是一个聊天过程，跳转到特定的场景以及业务相关的联动，这就是场景机器人。场景机器人的场景和相关业务跳转都是可以配置的，这样可以达到动态化地支持不同的场景。

场景机器人与场景绑定、结合场景相关话术和跳转规则，可以做：客户画像查询、产品信息查看、场景演练、面见话术等，还可以进行交叉销售、客户关联查询。

3.8 KG 机器人原理

KG 机器人，即知识图谱机器人，本质上是一种语义网络，其结点代表实体或者概念，边代表实体、概念之间的各种语义关系。KG 机器人是基于知识图谱推理给出结果，也是基于检索型机器人的一种。

相较于纯文本，知识图谱在问答系统中具有以下优势。

• 数据关联度：语义理解程度是问答系统的核心指标。在知识图谱中，所有知识点被具有语义信息的边所关联。从问句到知识图谱的知识点的匹配关联过程中,可以用到大量其关联结点的关联信息。这种关联信息无疑更为智能化的语义理解提供了条件。

• 数据精度：回答准确率高，知识图谱的知识来自专业人士标注，或者专业数据库的格式化抓取，这保证了数据的高准确率。

• 数据结构化：检索效率知识图谱的结构化组织形式，为计算机的快速知识检索提供了格式支持。

这些优势都促使我们在构建智能聊天机器人平台时使用知识图谱来作为问答系统的知识来源。

举个例子，这是保险的知识图谱，包含了：查询实体属性-平安境内旅行险一个月多少钱？查询关系以及属性-能保骨折，且承保时间在 5 年以上的保险有哪些？查询简单关系-平安境内旅行险能保意外骨折吗？查询复杂关系-想买一个能保骨折，并且能够在海口市的三甲医院报销的保险。

这些本质上都是在进行图查询，查询实体的属性，查询实体和实体之间的关系等。

知识图谱机器人构建过程中：

首先第一步是定义知识图谱的领域知识，上述例子中我们相当于在面向对象定义实体、属性、关系等，三元组（实体、属性、关系）的关系定义好了以后，才可以构建图谱模型。

接下来是提取信息，这个过程涉及到大量的训练、在线标注等，需要从现有的表单、文档中将需要的信息提取出来，并将提取的信息导入第一步构建的模型中。

接下来是知识问答。需要从问句中提取实体、属性、关系。在这个例子中，重大疾病险的等价词是重疾险，重疾险是一个实体，结肠癌也是一个实体。

最后问句就被转换为一个实体和实体之间关系的预测。

当用户问问题时候，把问句转化成图计算，机器人通过知识图谱进行查询计算，并转化为答案反馈给用户。

3.9 模型编排

除了上述各种机器人之外，聊天机器人平台还涉及到模型编排和模型管理的部分。比如有的业务只需要 QA 机器人，这时通过预处理，调用 QA 机器人，经过角色权限过滤就可以提供服务了。有的场景可能需要多种机器人进行合作，这就涉及到路由/群发，群发机器人的结果还要进行融合合并。

模型编排，将不同的模型进行组合，以可视化的方式对调用的模型顺序进行编排，支持拖拽式配置。

模型本身是需要服务化的。我们的实际模型本身是一些 python 服务，我们将这些 python 服务进行封装，进行服务的统一管理，这样的话就可以对模型定义统一的接口，还可以进行自动化的更新，比如通过定时模型训练去更新此模型，其他模型不受影响，如上图所示的模型手动更新和自动更新。同时我们可以进行单元测试和链路测试。

3.10 智能聊天机器人能力

目前平台已能够支持：

• 多类型机器人集成功能，包括问答、任务、闲聊等；

• 复杂情景会话：包括多轮对话功能、话题追踪功能等；

• 多渠道机器人交互终端；

• 统一的机器人管理框架；

• 完善的人工客服能力支持；

• 全面的数据记录与统计。

3.11 机器人平台功能

聊天机器人平台主要功能包括以下几个方面。

• 聊天机器人平台。聊天机器人平台的前台有机器人应答、QA、文档检索、关联检索、离线消息、会话历史、常见问题、问候语等功能。后台包括搜索引擎是否介入、反馈设置、外观设置、场景设置、模型配置等功能。

• 人工后台。人工后台包括客服工作台（在线会话、会话历史、会话转单、会话排队、邀请会话、客户信息显示、快捷回复等功能）、客服管理、技能组管理等。

• 会话管理。浏览会话导出、查询历史会话、对历史会话进行在线分类评分，添加 QA 问题。

• QA/文档管理。浏览编辑、全文检索、问题分类、等价问题、批量上传语料、生成水印、查看文档权限。

• 任务管理。对于任务机器人来说，功能包括任务配置、实体管理、任务更新、模型配置等。

• 闲聊管理。对于闲聊机器人，功能包括闲聊库管理、全文检索、语料导出、模型更新管理。

• 报表统计。包括会话统计、文档/QA 统计，人工后台服务分析、用户提问句云活跃度排名、用户积分、用户行为覆盖等。

• 模型管理。包括模型编排、模型启停更新、自动维护发布上线、模型预测等测试环境功能。

• 认证支持/外部系统对接。包括 PS 对接、LDAP 对接、SSO 对接/各种外部系统对接。

1）机器人前台

机器人预置了 web 交互页面，支持机器人全部的功能。包括对话、留言反馈、转人工、查看历史消息；可直接嵌入 PC 端和 APP 端业务系统等。

在上图的例子中可以看到，前面部分是我们的常见问题列表，用户问了一个问题，然后找到一个匹配该问题的答案。如果用户给出的问题比较简单，如上图，只给出“宜人贷”，就没办法命中一个独立的问题，这时除了匹配答案以外，还会给出一些与该问题相关联的问题，这种我们称之为关联问题。也可以转到搜索引擎，通过搜素引擎的相关问题。

实际上，对于检索模型的聊天机器人而言，当 FAQ 中没有合适的答案，我们返回的是 FAQ 中与问句最相近问句-答案对中的问句，而不是答案。这样可以从用户提问中得到更多信息，以便返回更真实的答案。我们在实践中发现，用户通过这样的关联，只需要几次点击就能找到真正想要的答案，其满意度会得到提升。

2）知识库

这是机器人的知识库，知识库包含了一些分类信息，支持相应的数据角色、文档的数据颜色格式，还包含浏览编辑、全文检索、问题分类、批量上传、语料生成、水印生成等功能。

3）人工后台

这是机器人的人工后台。人工后台上线后，用户可以跟人工后台的客服人员聊天，在这个过程中也可以上传图片。与机器人问答不同的是，机器人模式中用户只能发文字，而与客服人员聊天，可以上传文档、插入表情、请求评价等。在这里还可以做快捷回复、查看知识库、文档库、客户本身的信息，还有一些智能回答。

这是客服工作台的功能，可以从队列里调出相应的客户进行会话，解决不了的问题可以转交给别的工作台的客服解答。

4）会话管理

接着来看会话管理。上图左边是这个人对应的历史聊天信息，我们可以检索并定位到他认为回答不好的问题，进行在线快速补充添加新问题。每一个问题的评分都会显示，既能帮助算法同事，也能帮助运营同事进行在线信息维护。

5）统计分析

机器人平台还提供数据统计和分析功能，这一功能是基于 Davinci 数据可视化工具完成的，可以自定义数据指标，比如机器人服务时长、服务执行度等。还可以进行报表统计：会话统计、文档 QA 统计，人工后台服务分析、用户提问句云、活跃度排名、用户积分、用户行为覆盖、使用明细。

6）模型管理

机器人平台还提供通用化模型运行托管平台，它是一个高可用运行架构，可以进行模型封装、发布、启停、更新管理，还包括自动数据更新机制、统一服务访问接口等。

7）多租户和角色权限

机器人平台提供多租户和角色权限管理的功能，并且在公司里提供用户的自动导入，通过配置相应的角色和权限，自动导入成机器人的用户角色权限。这样一来，就不用维护用户本身了，可以跟不同的业务系统直接对接。

机器人平台的其他功能，诸如任务配置、闲聊配置、积分管理、对接外部系统等功能此处不一一展开。

3.12 机器人发展阶段

如图所示为智能聊天机器人平台的发展阶段，我们已经完全了前面阶段的机器人功能建设，包括问答、人工后台等。目前我们处于第三阶段向第四阶段演进的过程，最终我们希望达到业务领域系统性 CUI 整合，即通过机器人会话，以场景式机器人的方式展示给客户，成为机器人助理。

四、智能聊天机器人平台的应用场景

4.1 智能客服机器人

智能客服机器人的初衷是解决客服管理部的痛点。

宜信有很多线下门店，这些门店中的销售人员有大量的问题，涉及到政策、法规、流程、管理等众多方面，这些问题都会通过内部沟通工具蜜蜂或邮件集中到客服管理部来解答。

沟通的过程中，因为人数和问题量太大，重复工作多、问题难跟踪，知识难沉淀、缺乏问题的统计、无法针对性的培训。

对于门店客服和销售人员而言，人工回答等待时间很长，影响工作效率，客服容易情绪急躁，人工解答也不标准。

对于客户来说，等待时间较长，影响客户体验、解答不标准、影响品牌认知。

引入智能客服机器人以后，80%的问题被机器人拦截，剩下的 20%转到人工后台，减轻了客服管理人员的压力。

智能客服机器人目前服务于所有一线的客服同事，成为客服管理重要的日常工具。客服人员只需要通过手机就可以操作，实现了运营管理智能化从 0 到 1 的过程，帮助运营人员减轻压力，提升运营效率。

4.2 财富智能助手机器人

财富销售过程中涉及到很多产品（基金、保险等），需要了解产品知识、政策法规、销售话术等。同事希望能有一个知识型的助手，协助解答在销售过程中遇到的诸多知识盲点，提高专业度。

我们计划使用聊天机器人小助手与现有手机 app 结合，实现产品、客户、知识一站式服务。

如上图所示，财富智能助手并不是直接调用机器人平台，而是通过 API 方式调用机器人平台，然后去询问各种支持销售的问题。

目前财富智能助手机器人覆盖所有一线销售和业务支持人员，解决投前、投中、投后、销售政策等问题，提高了业务专业度、响应速度，提升业务拓展效率。

4.3 保险智能机器人

第三个场景是保险智能机器人。微信用户存在大量相关问题咨询，使用人员来回答的话疲于应付，回答也不专业，人力成本很高，希望通过机器人对售前类问题提供咨询服务，代替人工，完成售前信息交互，大幅减少人员成本，提高回答准确的和精准度。

如图所示，保险智能机器人基于第三方知识库提供查询：包括保险类术语查询、疾病库查询、险种查询、医院库等保险知识大全；基于知识图谱和推理的 1~3 度内查询等，例如：条款明细请问这款产品有犹豫期吗？我孩子 5 岁可以买这款产品吗？重疾险都包那些疾病？还可以做常见售前售后意图判断、保险费用预计算。

4.4 AIOps 运维机器人

最后一个场景是 AIOps 智能运维机器人，AIOps 是一个很大的话题，涉及到海量数据的存储、分析和处理。数据包括：历史数据、流数据、日志数据、时序数据、异常数据等。整个系统由许多小工具集成成为一个大系统。AIOps 还包含自动模式发现和预测、异常检查、根因分析等需要模型支持等方面。

这里我们主要关注入口：文本输入。

在日常运维中，当出现异常时，运维同事收到手机、邮件或短信报警，希望通过手机 APP，以自然语言方式查看获得当前系统状态、随时随地了解当前系统，甚至可以通过运维执行命令来解除故障。

比如可以通过手机 APP 调用任务机器人去查询后台系统中网络占用的一个时序图，把这个图以报表的方式返回到前端。使用机器人可以有效降低信息过载问题，调用相关接口，直接找到目前最重要的问题并返回。当发现系统出现故障时，可以通过机器人发送命令，重启服务解除故障。

五、总结

基于 AI 中台的思想和实践。智能聊天机器人采用平台化建设方式，使得机器人可以快速复制。第一个机器人从研发到上线用时 6 个月，接下来是 5 个月上线，4 个月上线，2 个月上线，6 周上线，最新的项目是 3 周完成上线。

支持多业务线、系统无缝对接，同时响应个性化需求。产品从立项以来支持公司普惠金融、财富管理的诸多重要业务方，支持 PC 端、APP 端、restful api 接口对接。

覆盖同事广，服务时间长。支持一线同事数万人，累积回答问题数十万次以上，累积会话时长近千小时。

运营效果好，节省人力。据统计，有效回答（机器人回答占总回答比例）在 80%以上，错误反馈率在 5%以下(反馈无用的比例)。

产品种类全。包括问答机器人、闲聊机器人、任务机器人、知识图谱机器人、以及基于场景的交互式机器人（如产品推荐、问卷调查、催收销售等）。

提供工程、算法和运营统一的一站式智能聊天解决方案。比如在线查看标注会话和知识更新、自动化语料导出和模型更新、数据、算法和运营形成闭环。

六、Q & A

Q1：语音外呼机器人如何用数据驱动做话术质量评估？比如：要定位哪些话术节点高频发生客户无回应、打断或投诉等，但机器人语音播报里是含多个变量参数的，而且文本会话存储是按 ASR 识别音转文的，和配置机器人时的固定话术格式不一样，这样一来导致句子量级非常庞大，这种如何统计呢？

A：语音外呼机器人其实是一个统称，一般来说会具体到一个领域，并且和特定场景相结合。比如：电销促销机器人、售后快递送货机器人、语音催收机器人等。

以售后快递送货机器人为例，机器人通过语音电话通知客户，将快递送到家或者指定快递柜等。

在这种特定场景里，主要是要进行话术编排，费时间的也是在话术编排上，需要充分结合业务场景特点，由机器人向客户发问，对客户可能回答的方式进行归类（与具体业务方一起根据现有人工话术可能的回答进行分类）和统计，这样就方便对无回应、投诉等话术进行评估了。

最终用户的回答都会被引导到有限的话术逻辑中，从而达到电话外呼的目的。句子量级庞大，但话术是有限的，不会特别巨大（我们目前场景中的话术都是和业务方一起合作总结的）。

另外，这种场景机器人的配置页面与分享中提到的任务机器人还不完全一样，有其单独的话术编排配置。

Q2：老师提到使用 similarity 的 chatbot，请问这样的 chatbot 只是做 intent 识别吗，对于 slots 的填充是怎样处理的呢？

A：基于相似度的模型用于问答和闲聊机器人。任务机器人的处理基于专门的意图识别模型和实体识别模型来做。

意图识别模型，由于我们要做的是通用化、自助化、弹性化，所以设计了一个轻量级的自训练意图识别框架，基于用户提出的少量语料，通过句子成分分析提取特征，并对特征进行分析而成，其中主要涉及到语言学知识，少量统计学习方法，优点是自训练需求算力很少、解释性强、准确率高、用户完全可以随意添加各类新的任务。

槽值提取基于 NER 和意图识别中的句子成分分析开展。NER 自带通用的时间、地点、人名、组织等实体识别，通用实体由于语料充足，其识别利用了 ML、DNN 等模型。此外考虑到专业领域里的专有槽值实体（例如合同号、公司内部部门名称、员工编号等等），我们允许用户自行配置列表实体、正则实体等。

Q3：第二种使用模型对 intent 和 slots 识别，请问里面的 slots 识别是 character-level 的还是 word-level 的？如果是 word-level 的,怎样处理 cut-word 不准带来的问题?

A：槽值中通用实体的识别基于 word-level，专有的实体识别比较复杂，常见的情景中如果是列表实体，那么我们在分词阶段已经将列表实体名称加入分词表；正则实体直接做正则匹配。

之所以采用这种 NER 方式，主要就是降低用户每次新建任务、实体后模型框架自训练的开销，使其可以迅速动态加载新的意图识别和槽值提取 task。

Q4：第一个机器人从开发到上线用了六个月，机器人平台开发用了多久呢？

A：因为是按照平台化的思维去建设，实际上第一个机器人开发的时候，机器人的模型部分和机器人平台是同步进行的，团队成员包括算法同事和平台研发同事，以两周一个小版本的速度，在与第一个客户一直保持密切交流的情况下，随时改善用户体验，总共花了 6 个月的时间，第一版的机器人模型和平台同时完成。

第一版主要包含 QA 机器人、QA 库管理、文档库管理、会话管理、模型自动更新等主要功能。闲聊机器人、任务机器人等都是后面版本迭代增加的。

其实机器人模型、QA 库不断完善、模型自动更新、问题反馈、统计报表等都是一个统一的整体。单纯只重视任何一方面，例如只重视算法模型，忽略特定业务场景的语料，忽略运营的支持，都会导致机器人不好用，体验差。在实际运营中，算法、平台和运营都需要形成闭环，进行有效沟通。这样才能把平台和机器人建设得更好用。

本文转载自公众号宜信技术学院（ID：CE_TECH）。