从0到10Wqps，大厂的智能客服平台，如何实现架构演进？

文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录博客园版 为您奉上珍贵的学习资源：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你实现技术自由，完成职业升级，薪酬猛涨！加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领

免费赠送资源宝库： Java 必备百度网盘资源大合集价值>10000元加尼恩领取

从0到10Wqps，大厂的智能客服平台，如何实现架构演进？

尼恩特别说明：尼恩的文章，都会在《技术自由圈》公号发布，并且维护最新版本。如果发现图片不可见，请去《技术自由圈》公号查找

尼恩：LLM大模型学习圣经PDF的起源

在40岁老架构师尼恩的读者交流群(50+)中，经常性的指导小伙伴们改造简历。

经过尼恩的改造之后，很多小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试机会，拿到了大厂机会。

然而，其中一个成功案例，是一个9年经验网易的小伙伴，拿到了一个年薪近80W的大模型架构offer，

惊天大逆袭：8年小伙20天时间提75W年薪offer，逆涨50%，秘诀在这

逆涨50%，那是在去年2023年的 5月。

不到1年，小伙伴也在团队站稳了脚跟，成为了名副其实的大模型架构师。目前，他管理了10人左右的团队，一个2-3人的python算法小分队，一个3-4人Java应用开发小分队，一个2-3人实施运维小分队。

并且他们的产品也收到了丰厚的经济回报，他们的AIGC大模型产品，好像已经实施了不下10家的大中型企业客户。

既然AI+大模型工程架构前途无量，那么，从2024的4月份开始，尼恩开始写《LLM大模型学习圣经》，帮助大家穿透大模型，穿透AI，走向大模型工程架构之路。

注意是AI工程架构师，不是AI算法架构师，不要搞偏了。

大模型的应用场景

大模型在各个领域都有广泛的应用，特别是在以下几个方面：

自然语言处理（NLP）：大模型在自然语言理解、语言生成、机器翻译等任务中表现出色。例如，BERT、GPT等模型在文本理解和生成方面取得了显著的进展。
计算机视觉（CV）：在图像分类、目标检测、图像生成等领域，大模型也取得了巨大的成功。例如，ResNet、YOLO、GAN等模型在图像处理方面取得了显著的成果。
推荐系统：大模型在个性化推荐、广告点击率预估、智能客服等方面发挥着重要作用。例如，YouTube的DNN模型在视频推荐中发挥着重要作用。
生物医药：在药物发现、分子结构预测、疾病诊断等方面，大模型也有广泛的应用。例如，使用大模型对蛋白质进行预测，有助于加速新药的研发。
金融领域：在风险管理、交易预测、信用评分等方面，大模型可以提供更精准的预测和决策支持。例如，使用大模型对金融数据进行分析，可以帮助金融机构提高风险管理能力。

总的来说，大模型在各个领域都有重要的应用，可以帮助解决复杂的问题，提高系统的性能和效率。

此文，尼恩站在巨人的肩膀上，为大家梳理几个智能客服的线上案例，研究和分析大模型在智能客服领域的使用现状。

后面的文章，尼恩持续为大家梳理和总结大模型应用场景，并且收入《LLM大模型学习圣经》系列PDF。

尼恩的《LLM大模型学习圣经》系列PDF，已经发布了第一卷：

《LLM大模型学习圣经：从0到1吃透Transformer技术底座》

这个是一个基础理论篇、核心篇。

另外好戏刚刚开始，后面会有实战篇，架构篇等等出来。

在尼恩的架构师哲学中，开宗明义：架构和语言无关，架构的思想和模式，本就是想通的。

架构思想和体系，本身和语言无关，和业务也关系不大，都是通的。

所以，尼恩用自己的架构内功，以及20年时间积累的架构洪荒之力，通过《LLM大模型学习圣经》，给大家做一下系统化、体系化的LLM梳理，使得大家内力猛增，成为大模型架构师，然后实现”offer直提”，逆天改命。

尼恩《LLM大模型学习圣经》PDF 系列文档，会延续尼恩的一贯风格，会持续迭代，持续升级。

这个文档将成为大家学习大模型的杀手锏，此文当最新PDF版本，可以来《技术自由圈》公号获取。

3个 AI（包括小模型 + 大模型）智能客服平台

言归正传，接下来，我们梳理 AI（包括小模型 + 大模型）在智能客服平台领域的应用

这里从小到大，涉及了3个平台

案例1：B站小型的运营智能客服平台架构
案例2：1Wqps+ 高并发B站智能客服系统的设计与实现
案例3：10Wqps 美团智能客服核心技术与实践

接下来，一个一个来

案例1：B站小型的运营智能客服平台架构

40岁老架构师尼恩提示：这是一个小型的案例，应用场景是解决运营的智能知识库的问题。

原文： https://juejin.cn/post/7324384155231223862

作者: 林晶昱

B站小型的运营智能客服平台的业务场景

一直以来，B站的活动平台一直是运营部门的重要工具。在运营过程中，偶尔会遇到一些疑难问题。

例如，运营人员可能对某个组件功能的使用产生疑问。
或者，线上活动的表现与预期不符。

在这些情况下，运营部门期望产品研发团队能够协助排查问题。老的活动平台的线上问题排查流程，大致如下：

建立一个千人以上的产研运“救火群”。
当运营遇到问题时，他们会在群里提出问题。
研发关注群里的问题，并及时给予响应和解答。
研发需要手动记录每周问题的excel表格。

“拉大群” 的做法依赖人工干预和手动记录，很古老，很普遍，但是这个有很多弊端：

缺乏沉底的弊端：问题及解决方案没法自动沉淀，想要把FAQ记录下来，得靠值班同学费尽心思地手动记录，这不光耗时还超级耗力。
对值班人员能力要求过高的弊端：要解答问题，值班同学得对问题所涉领域有足够的了解，要不然就是哑巴吃黄连，有苦说不出啊。
效率低下的弊端：群消息内容太繁杂了，有时候消息会被其他信息吞没，这可得靠值班同学像蜘蛛侠一样灵活，才能捕捉到问题的“蛛丝马迹”啊。

怎么办？

需要一个可智能对话、可针对性一键拉群、支持FAQ沉淀的智能客服系统。

这就是 B站小型的运营智能客服平台。

B站小型的运营智能客服平台架构

B站小型的运营智能客服平台的整体架构如下：

包括以下几部分构成：

对话界面
会话状态机
数据源模型
统计汇总后台
接入配置

对话界面

运营人员，更愿意、更习惯使用企微原生功能实现对话，排斥跳转到第三方网页或者在活动后台开启对话窗口的形式。

企微目前支持两种对话形式：

服务号提供对话页面的形式
应用号提供对话页面的形式

由于受限于服务号的“无消息回调”，“人工座席与智能服务不能共存”等问题，最终B站小型的运营智能客服平台选择了应用号作为人工客服的主要对话入口。

一个人工客服的对话的例子如下：

整个的对话流程如下，每一个对话都会带有部门flag(小红旗)，实现了不同部门间的流程和数据的隔离。

图中的代理是怎么回事呢？

在测试环境进行调试时，微信无法访问UAT环境内部域名，解决这个问题，团队架了一层代理，开启callback-api服务接口，将外网请求直接转发到uat环境域名上。

会话状态机

后端维护了一整套会话管理体系，

会话状态主要如下：

会话开启
对话中
处理中
已结束

状态流转如下图：

会话状态机维护一个状态的延时消息队列。延时队列在用户长时间无响应时，主动二次确认，并保留对会话自动关闭的机制。

每次会话在运营向应用号发消息时开启。在聊天过程中，应用号与后端服务进行交互，执行一系列操作：

1 通过不同类型的消息事件触发开启会话。

2 自动收集会话信息。

3 进行会话识别。

4 进行会话FAQ匹配。

5 回复用户答案。

同时，应用号维护会话状态，并对用户的一键拉群、结束会话等请求进行响应

数据源模型

数据源模型，主要是针对消息内容，进行合理回复的底层数据源选型模型，目前本套智能客服回复支持两种模型，

一种是搜索模式的数据源，比如基于ES搜索的，
一种是生成模式的数据源，比如类似ChatGPT的专业领域学习模型。

搜索模式的数据源

搜索模式的数据源使用基于ES搜索的数据源模型，采用Elasticsearch内置的分词器(Tokenizer)和过滤器(Token Filter)对用户问题进行拆分识别，并匹配FAQ库中匹配度最高的答案，给予返回。

生成模式的数据源：

生成模式的数据源使用 NLP 自然语言处理和机器学习的问答处理模型，对用户问题进行预处理，对原始答案进行语料加工，回答的时候根据上下文场景生成答案。

生成模式的数据源其特点就是问题回答更自然、更人性化。

生成模式的缺点在我们的智能客服项目中也体现的比较明显，在FAQ库、对话信息收集不足够丰富的情况下，模型训练的准确性并不高，甚至模型会有“自由发挥”空间，也就是所谓的大模型幻觉，如果按照甚至会导致运营的错误行为。

解决大模型幻觉的一个策略是使用小模型、专业模型，在这里引入simbert模型，其最大的优势在于在特定专业学习领域里，准确率比其他模型都高，

解决大模型环境的另一个策略，保证训练数据的补给，我们也打通了一条离线数据补给流，对话界面收集到的FAQ及对话信息会通过离线任务同步给训练模型，让训练模型不断“精进自我”，提高回答的准确率。

BERT（Bidirectional Encoder Representations from Transformers）是一种基于 Transformer 结构的预训练模型，由谷歌提出。BERT 通过大规模的无标签文本语料进行预训练，学习文本的语义表示。与传统的单向语言模型不同，BERT 使用了双向的 Transformer 结构，能够同时考虑文本中的上下文信息，从而更好地捕捉文本的语义。BERT 在预训练之后，可以通过微调（fine-tuning）的方式适应各种下游任务，如文本分类、命名实体识别、问答等。由于其出色的表现和通用性，BERT 在自然语言处理领域得到了广泛的应用和认可。

SimBERT 是百度提出的一种基于 Transformer 结构的预训练模型，它是在 BERT 模型的基础上进行了改进和优化。SimBERT 的主要目标是提高文本相似度任务的性能，尤其是在中文文本相似度任务上的表现。SimBERT 在预训练阶段采用了大规模的文本语料进行自监督学习，然后通过微调或下游任务 fine-tuning 来适应特定的文本相似度任务。通过在大规模语料上的预训练，SimBERT 能够学习到丰富的语义表示，从而在相似度任务中取得优异的性能。

搜索模式的数据源和生成模式的数据源的切换

目前智能客服支持两种数据模型的开关控制，随时随地随意切换。

会话管理和统计汇总后台

提供了一套可视化的管理后台，完成对所有会话进行管理、review、统计、。

会话管理界面：

会话详情界面；

会话备注及状态流转；

直接一键上传FAQ，

FAQ数据将供给给ES及语言训练模型，真正实现全流程的闭环及可持续发展。

成果与展望

自系统上线以来，历经几次迭代，从支持单部门到开放至多部门，底层数据源从ES迭代到ChatGPT，智能客服已经成功实践在以下应用中：

使用以来，活动平台姬共解决约1000例运营线上问题，日均解决运营5例咨询问题，ChatGPT上线一个月后，问题智能解决率提高接近7%。

对智能客服现在的应用趋势及使用反馈进行分析，我们也畅想了下未来发展：

更加开放，可以利用企微应用号的回调能力开发智能客服系统，但同时也提供SDK服务，将能力提供给所有有需要的公司内部团队使用，不限于帮助团队灵活的进行对话界面的定制化开发。
接入平台化，现在要接入整个智能客服系统，需要人工对接，后续把对接流程线上平台化，增加一些审核机制，就可以方便的实现服务一键接入。
对转人工进行优化，如果团队使用企微应用号形式进行接入，那么就一定会受限于企微的既有功能，在用户转人工后，需要单独拉群间接实现摇人，整个对话无法在应用号内实现闭环解决，跳出带来的一是用户体验，二是拉群太多增加了管理成本。这一部分我们考虑“花钱”解决，比方说能否以公司身份出面向企微提需，提供更加灵活的功能。

案例2：1Wqps+ 高并发B站智能客服系统的设计与实现

40岁老架构师尼恩提示：这是一个中型的案例，应用场景是解决大量用户客服的问题。

截至2022年，哔哩哔哩（Bilibili）是中国颇具影响力的在线视频平台之一，用户量一直在稳步增长。根据官方公布的数据，截至2021年底，B站的注册用户数量已超过5亿，其中活跃用户规模也持续扩大，达到了2.5亿。

这一数字反映了B站在视频分享、弹幕互动、二次创作等方面的持续吸引力，以及其在年轻人群体中的广泛普及程度。

值得注意的是，随着在线视频行业的快速发展和用户需求的不断变化，B站的用户量也在不断增长和优化。

尼恩提示，按照尼恩3高架构理论，5亿亿用户，吞吐量峰值1Wqps+ ，没有任何问题的

B站智能客服系统的背景

B站昔日所用之客服系统，是外购而得，已用有数载。

然则，此外购之系统，却存诸多弊病：

稳定性乏善可陈，无法妥善延展与扩充，常见诸bug，难以迎击瞬息万变的客流高峰。
与B站产品体系无法沟通，不易根据业务需求进行量身定制。
因系统之逻辑陈旧，稳定性不佳，致效率低下，无法满足提升客服效率之要求。

纵然曾思量采购新客服系统，但亦面临一系列问题：

昂贵之价格，尤其是在当前提倡降本增效之大环境下，为一重要考量。
更为关键者，此系统仍不能与内部系统完美融合，无法支持业务之个性化定制。

因是，B站决意自力更生，启动新客服系统之自研工程。

从0到1，打造一个全新的B站客服系统

在面对如何打造一个全新的客服系统的挑战时，我们首先开始了调研、访谈和体验。

业内调研

我们踏访了一些客服系统领域中驰名有声的企业，从业务和技术的双重视角进行了深入探究。总结归纳，目前客服系统着重关注以下三大关键指标，让我们逐一剖析：

智能问答拦截率(也对应人工处理率)：一款出色的客服系统，良好的智能问答功能至关重要：
实现7*24小时不间断在线服务，无需等待排队，确保用户随时获得迅速回应。
快速应对用户常问问题，提升效率，节省成本，达到更优用户体验和更高资源利用效率。
能够快速解答大部分简单问题，同时为复杂问题留有人工处理的空间，以提高整体问题解决效率和效果。
用户满意度
平均处理时长：主要指客服人员处理一次会话所需的平均时长

这些要紧的指标，为未来的研发指引了明晰的方向。

内部访谈和体验

首先，我们对运营团队/各项功能团队（质检、舆情、机器人、工单、二线、数据等）进行了详细的访谈，旨在深入了解他们的工作情况和需求。

其次，与各个团队的交流中，我们深入探讨了各团队的具体工作内容和挑战，收集了许多珍贵的经验和建议,这对我们如何具体做好产品和之后推动系统的落地起到了巨大的作用。

最后，通过对现有系统的全面体验，我们进一步了解了系统的运行情况和存在的问题，为后续产品的优化和系统的落地提供了重要参考。

B站客服系统整体架构和核心业务流程

客服系统主要功能：

C端入口：进入客服的入口
智能问答：通过机器人与用户进行会话，解决用户的问题
客服坐席调度：给用户选择合适的客服人员同时兼顾客服人员的工作平衡
客服工作台：为客服人员提供便捷的工作界面和工具
知识库：汇集各类常见问题和解决方案，供客服使用
IM聊天基础能力：负责构建用户和客服之间的聊天，进行对话操作(发送文字，图片，视频)等
客服工单：用于跟踪和解决用户提出的问题和需求
权限管理：确保客服系统数据和功能的安全性

还有一些其他的功能如：质检系统，舆情系统，客服工时系统，监控系统等等。

B站客服系统用户入口

首先简单看一下哔哩哔哩智能客服的用户入口。

当用户进入聊天框，首先会经过智能问答环节。

这个环节，就像是大门前的门卫一样，站在用户与问题之间，守护着信息的流通。

如果智能问答不能满足用户的需求，用户还可以选择进一步与人工客服交流，就像是在犹豫着是否要推开大门，踏入未知的领域一样。

B站客服总体功能架构

为了帮助大家从宏观上理解客服系统，以下列出了整体功能的架构图。

B站客服总体功能架构主要包括以下几个方面：

智能机器人客服：利用自然语言处理（NLP）和机器学习技术，实现对用户提出的常见问题进行自动回答。这个系统就像是一位聪明的管家，能够快速、准确地解答用户的疑问，提高客服效率。
坐席调度系统：为用户提供人工客服服务，当智能问答无法解决问题时，用户可以选择与真人客服进行交流。这个系统需要包括在线客服接待、问题处理、对话记录等功能，确保用户能够得到及时、个性化的解决方案。
客服管理后台：提供给客服人员使用的管理后台，包括客服工作台、会话管理、用户信息查看、问题记录等功能，帮助客服人员更好地处理用户问题、管理会话。
数据分析与监控：对客服系统的运行状态进行监控和分析，实时统计客服工作指标、用户反馈情况等数据，并提供报表和可视化界面，为决策提供数据支持。
技术工单系统：负责客服系统的技术支持和维护工作，包括系统的升级、bug修复、性能优化等，确保客服系统的稳定运行和持续改进。

这些功能相互配合，构成了B站客服系统的整体架构，为用户提供了高效、便捷的客户服务体验。

B站客服核心流程

B站客服的核心流程，如下图

B站客服核心功能设计和实现

我们将按照用户一次完整的访问客服系统所需的先后次序，介绍各个核心功能的设计与实现。

用户从用户入口进入，依次会经历智能问答、客服坐席调度以及与客服聊天（工作台）等核心功能。

智能机器人客服子系统

在客服的业务场景中，智能问答扮演着极为重要的角色，其优势堪称人工无法比拟：

首先，它提供了24小时不间断的在线服务，仿佛是一位不知疲倦的守护神；

其次，在高峰时期，用户无需排队等候，享受着犹如鱼得水的畅快感受；

再者，对于用户频繁提出的问题，它能够轻松给出迅速的回答，就像是一位经验丰富的老师一般；

最后，在面对大部分简单问题时，它能够轻松自助解决，就如同得道高僧般游刃有余。

因此，智能问答系统的应用不仅能够提升整体效率，降低成本，更能够创造出更好的客户体验和更高效的资源利用。

目前，哔哩哔哩客服系统在执行智能问答任务时，会根据匹配度的不同提供两种回答方式：

当匹配度较高时，系统会直接给出答案；
而当匹配度只是中等时，系统则会提供一个“您想咨询的问题可能是”的列表。

这个策略的目的是为了提供更准确、更有用的回答，以帮助用户更快地找到他们需要的信息。

机器人问答-直接给出答案	机器人问答-“您想咨询的问题可能是”

机器人问答技术调研

机器人问答技术在实现上主要分为两种类型：检索式和生成式。

检索式：检索式模型通常利用神经网络技术，将大量的预训练语料数据输入到模型中进行训练。在完成训练后，模型能够对新的输入进行分类、匹配和回答问题。这种方案的实现主要依赖于大规模的预训练数据和高效的检索算法。

生成式：另一种类型的是生成式模型，它主要采用深度学习技术以及最新的大语言模型，通过学习大量数据来生成文本。这种方案通常使用循环神经网络（RNN）或变换器（Transformer）等结构，能够处理序列数据并生成新的序列。与检索式模型不同，生成式模型在训练过程中会直接生成目标文本，而不是通过检索匹配。

总的来说，检索式和生成式两种模型各有特点，各有优势，在机器人问答系统中都有应用。

具体选择哪种模型，往往需要根据具体的应用场景和需求来决定。

方案对比：

方案	场景	数据需求	准确性	性能	复杂性
检索式	主要适用于对知识库的检索和筛选，比如问答系统、知识库管理、智能客服等	依赖，需要丰富的结构化语料库	本质上是从已有数据集中检索最匹配的数据，准确性高	毫秒级	低
生成式	主要适用于需要生成自主文本或任务的应用场景，如对话生成、文本创作、任务调度等	依赖，无需结构化	生成的质量可能会受到模型的训练数据和质量的限制，可能会出现不准确、无意义或不一致的输出	秒级	高

在电商客服场景下，回答用户问题的准确性至关重要，宁可选择不回答也不能够回答错误。

相比之下，生成式答案会受到多种因素的影响，导致结果不可控。

而检索式答案来源于知识库，可以提供更加准确的问题解答。

虽然检索式在处理一些长尾问题或者冷门领域的问题时表现不佳，但是可以通过人工干预来丰富知识库进行优化。综合考虑到这些因素，最终选择了检索式实现。

向量搜索和基于Faiss实现的智能问答

向量搜索基本原理

给定一个向量集合:

和一个待查询的向量:

从个向量里面找到距离某种距离（比如 L2 距离）最近的个向量。

其应用包括

从语料库里面找到距离某个语句最相近的一句话。
从图片库里面找到距离某张图片最类似的一张图片。
还能查找别的，比如视频、音频、动图、基因序列、搜索条目等。

这些东西（图片、词语、句子、视频等）都可以用向量表示出来，如下图：

这个事情看起来很简单，但是当我们的数据库变得特别大时，这件事情就变得比较困难了。

因此这里就专门来研究如何做这样的向量搜索。

Faiss简介

Faiss(Facebook AI Similarity Search) 是 Facebook AI 开发的用于高效相似性搜索和向量聚类的库。

Faiss(Facebook AI Similarity Search) 提供了一系列高性能的算法和数据结构，用于处理大规模的向量数据，特别是在推荐系统、语义搜索、图像搜索等领域具有广泛的应用。

Faiss支持基于内存和基于GPU的索引构建和查询，能够在大规模数据集上快速进行近邻搜索、相似性匹配和聚类操作。通过高效的索引结构和算法设计，Faiss可以大大加速相似性搜索的过程，提高系统的性能和效率。

Faiss 总体使用过程可以分为三步：

构建训练数据（以矩阵形式表达）；
挑选合适的 Index （Faiss 的核心部件），将训练数据 add 进 Index 中；
Search，也就是搜索，得到最后结果。

详细解释，即为：首先根据原始向量构建一个索引文件，再根据索引文件进行查询。初次查询前需要进行train和add过程，后续若要进行索引的添加可以再次使用add添加索引，如下图所示：

基于Faiss实现的智能问答

在实现检索式的过程中，主要任务是找到与用户提问语句最相似的问法，从而获取对应的答案。这个过程包括以下步骤：

数据准备：建立知识库，包含标准问、相似问以及对应的答案。每个标准问有多个相似问，并对应唯一的答案。

文本向量化：使用BERT模型将问题和相似问转化为向量表示。BERT模型采用预训练方式，能够将输入的文本转化为对应的向量表示。公司已有基于社区数据训练的bert-embedding服务，体验效果满足需求，因此使用该服务进行文本向量化。
相似度计算：使用Faiss库进行相似度计算。Faiss库是一种针对聚类和相似性搜索的工具，为稠密向量提供高效相似度搜索和聚类，支持十亿级别向量的搜索，是目前最为成熟的近似近邻搜索库。
搜索匹配：将用户问题向量传入Faiss库中，使用相似度计算方法对问题进行匹配，找到最相似的TopN问题向量(或者说相似问)。
答案选取：根据相似度结果高低，直接给出问题对应的答案或者“您想咨询的问题可能是”列表。如果相似度很低，则会转接人工。

基于Faiss的智能问答如下图所示

Faiss索引选择实践

Faiss提供的索引很多，需要根据数据集的大小和机器的性能来选取合适的索引。

基于准确查找

仅有IndexFlatL2索引可以提供确切的结果，但是性能上会比较差，仅适用数据量比较少的情况，通常为其他索引准确度提供基准。

基于内存限制

a. 由于所有的Faiss索引都将向量存储在内存中，如果内存是限制因素，那么就需要将准确度和性能进行折衷：

b. 不关心内存则使用"HNSWx"，通过"efSearch"参数平衡准确度和性能，该参数越大越准确，同时性能越差；

c. 有一点关心内存则使用"..,Flat"，"..."的含义是聚类，聚类后，"Flat"的含义是不压缩，存储大小与原始数据集相同，通过"nprobe"参数平衡准确度和性能；

d. 很关心内存则使用"PCARx,...,SQ8"，PCARx指将维度降x，SQ8指将每8bit向量压缩到1bit；

e. 非常关心内存则使用"OPQx_y,...,PQx"，PQx使用输出x-byte的量化器压缩向量。x通常<= 64，对于较大的代码，SQ通常是准确和快速的。OPQ是向量的线性转换，使它们更容易压缩；

基于数据集限制

a. 如果低于1M个向量： "...,IVFx,..."，直接倒排索引，x范围在 4sqrt(N)~16sqrt(N)之间，N是数据集大小，x是k-means聚类后的数量；

b. 如果1M - 10M："...,IVF65536_HNSW32,..."，结合IVF和HNSW，用HNSW进行聚类；

c.如果10M - 100M： "...,IVF262144_HNSW32,..."；

d. 如果100M - 1B： "...,IVF1048576_HNSW32,..."；

由于我们数据集在10M以内，最终选取了"IVF{IVFK}_HNSW32,Flat"，如果小于10M，IVFK根据依据4sqrt(N)~16sqrt(N)动态算，如果大于10M，则IVFK为65536。

部分代码如下：


if len(x) < 1000000:
     ivfK = findIVFK(len(x))
 else:
     ivfK = 65536
 factory_str = f'IVF{ivfK}_HNSW32,Flat'
 
 
 def findIVFK(N: int):
    sqrtN = math.sqrt(N)
    print(sqrtN, 4 * sqrtN, 16 * sqrtN)
    i = 2
    while True:
        i *= 2
        if 4 * sqrtN <= i <= 16 * sqrtN and N // 256 <= i <= N // 30:
            return i
        if i > 4096:
            return 512

大语言模型尝试和探索

当前备受关注的大语言模型我们也进行了探索。‘

我们与公司AI部门合作，将客服与用户的真实聊天记录以及知识库作为训练数据，给大模型进行训练，并且进行了测试。

总体上，我们学到了客服的回答风格，使回答更为流畅自然，与检索式问答相比，这种方式更容易让客户在心理上接受，并能够做出一些决策。

情绪抚慰

意图识别

自我决策

当然，我们也遇到了强制回答和回答无法解决问题的情况。

要解决问题，需要根据客户的具体问题和订单状态来回答。

不过，大型语言模型是未来的趋势，值得我们进一步探索。

除了智能问答领域，目前大型语言模型还可以应用于智能话术场景，或者在一些偏向咨询的场景中试用。

此外，业内也有在偏向咨询的电商售前场景和互联网教育咨询场景中使用大型语言模型的案例

新系统落地效果如何

在核心指标上，新客服系统都取得了显著的提升：

智能问答拦截率：与原有系统相比，新系统的智能问答拦截率有了巨大的提升，达到了业内先进水平。
用户满意度：也有显著的提升，表明用户对新系统的满意度较高。
平均处理时长：尽管新系统需要适应的过程，但平均处理时长仍有减少，这一点非常不易。

此外，新客服系统的落地还提高了客服工作效率，实现了与内部业务系统的无缝对接，优化了客服功能工具，验证了自主研发的能力。

接下来，我们将从技术角度，整体和分细节方面对新客服系统进行介绍。

案例3：10Wqps 美团智能客服核心技术与实践

40岁老架构师尼恩提示：这是一个中型的案例，应用场景是解决海量场景，海量用户智能客服问题。

美团平台涵盖吃、住、行、游、购、娱等200多个生活服务品类，目前，美团的年交易用户量为6.3亿，服务了770万生活服务类商家。

尼恩提示，按照尼恩3高架构理论，6.3亿用户，吞吐量峰值10Wqps+

此外，在美团优选业务中还有一个很大的团长群体。

面对以上这些需求，如果都是通过人力进行实现，显然不符合公司长远发展的目标，这就需要引入智能客服。

美团平台智能客服提供了六大智能客服核心能力：

问题推荐。
问题理解。
对话管理。
答案供给。
话术推荐。
会话摘要。

这些能力旨在实现与用户进行沟通的目标，即以低成本、高效率和高质量的方式提供服务。

美团智能客服的业务场景

在平台服务的售前、售中、售后各个环节，都有大量信息咨询、订单状态获取以及申诉投诉等沟通诉求。

首先，我们看看日常生活中几种最为常见的客服场景。

售前场景：比如消费者在平台选择入住酒店，对房型价格、酒店设施、入退房政策等，下单前都有很强的信息咨询诉求。
售中场景：比如外卖催单还没到，添加备注不要辣、加开发票等咨询等等，售前和售中场景主要发生在消费者和商家或平台之间。
售后场景：比如外卖场景投诉菜品少送、骑手送餐超时、要求退款等，酒店场景投诉酒店到店无法入住等，售后往往涉及到客服座席、消费者、骑手和商家，需要多方协同解决。
办公场景：比如IT、人力资源、财务、法务等咨询，产运研对提供的接口产品的咨询答疑，产品对销售顾问的答疑，以及销售顾问对商家的答疑等等。

智能客服平台对话类型分类

智能客服背后的技术主要是以对话交互技术为核心。

常见的对话任务可分为闲聊型、任务型和问答型：

闲聊型：通常是不关注某项特定任务，它的主要的目标是和人进行开放领域的对话，关注点是生成流畅、合理且自然的回复。
任务型：通常是帮助用户完成某项任务指令，如查找酒店、查询订单状态、解决用户的退款申请等等。用户的需求通常比较复杂，需要通过多轮交互来不断收集任务所需的必要信息，进而根据信息进行决策，执行不同的动作，最终完成用户的指令。
问答型：侧重于一问一答，即直接根据用户的问题给出精准答案。问答型和任务型最本质的区别在于，系统是否需要维护一个用户目标状态的表示和是否需要一个决策过程来完成任务。

在技术实现上，通常又可以划分为检索式、生成式和任务式：

检索式：主要思路是从对话语料库中找出与输入语句最匹配的回复，这些回复通常是预先存储的数据。
生成式：主要思路是基于深度学习的Transformer 架构，从大量语料中习得语言能力，根据问题内容及相关实时状态信息直接生成回答话术。

40岁老架构师尼恩提升，关于Transformer 架构，请参见尼恩的大模型学习圣经 LLM大模型学习圣经：从0到1吃透Transformer技术底座

任务式：就是任务型对话，通常要维护一个对话状态，根据不同的对话状态决策下一步动作，是查询数据库还是回复用户等等。

闲聊、问答、任务型对话本质都是在被动地响应用户需求。在具体业务中还会有问题推荐、商品推荐等来主动引导用户交互。

在美团的业务场景里主要是任务型和问答型，中间也会穿插一些闲聊，闲聊主要是打招呼或者简单情绪安抚，起到润滑人机对话的作用。

用户的沟通对象两个:

跟机器人沟通
跟人工沟通。

跟人工沟通, 如果是找客服场景人工就是客服座席，如果是找商家场景人工就是商家。

跟机器人沟通, 机器人的能力主要包括:

问题推荐
问题理解
对话管理
答案供给。

衡量机器人能力好坏的核心输出指标是：

不满意度，衡量问题解决的好坏，
转人工率，度量能帮人工处理多少问题。

而在人工辅助方面，我们提供了话术推荐和会话摘要等能力，核心指标是ATT和ACW的降低，ATT是人工和用户的平均沟通时长，ACW是人工沟通后的其它处理时长。

一个智能机器人多轮对话客服案例

什么是智能机器人多轮对话？

智能机器人的多轮对话是指机器人与用户之间进行连续交流，通过多个对话轮次来完成一个或多个任务或目标。

在多轮对话中，机器人需要能够理解用户的意图、回答用户的问题、提供相关信息，并根据对话的上下文进行适当的回应和行动。

多轮对话通常涉及以下几个关键方面：

意图识别和理解： 机器人需要能够识别用户的意图，理解用户的提问或请求，并据此采取相应的行动。这可能涉及自然语言处理（NLP）和自然语言理解（NLU）技术。
上下文管理： 在多轮对话中，机器人需要能够维护对话的上下文，以便理解用户的意图和回答问题。上下文管理可以包括跟踪先前的对话历史、记忆用户提供的信息和状态等。
信息检索和知识库查询： 机器人可能需要访问信息库或知识库，以获取与用户查询相关的信息。这可能涉及到信息检索和知识图谱等技术。
回答和反馈生成： 机器人需要能够生成自然、流畅的回答，以回应用户的提问或请求。这可能涉及到自然语言生成（NLG）技术。
对话流程管理： 机器人需要能够管理对话的流程，引导用户完成任务或目标。这可能涉及到对话管理和对话策略设计。

通过智能机器人能够实现更加智能和人性化的多轮对话，从而提供更加个性化和高效的服务。

机器人多轮对话，用户跟机器人沟通, 机器人的能力主要包括:

问题推荐
问题理解
对话管理
答案供给。

下面，是一个真实的多轮对话的例子。

当用户进入到服务门户后，机器人首先进行问题的推荐：

先选择了一个推荐的问题“如何联系骑手”，在下面的消息框中，“如何联系骑手” 的问题就会发送到后端，机器人给出了联系方式致电骑手。

同时为了进一步厘清场景，机器人进行问题的推荐：

这两个问题，主要用于询问用户是否收到了餐品，用户可以进行下一轮的选择。

当用户选择“还没有收到”的时候，结合预计送达时间和当前时间，机器人再一次进行问题的推荐：

发现还未超时，给出的方案是“好的，帮用户催一下”，或者是“我再等等吧”，

这时候，假设用户选择了“我再等等吧”。

机器人再做最后一次进行对话的推荐。

智能机器人能力1: 问题推荐

机器人多轮对话，用户跟机器人沟通, 机器人的能力主要包括:

问题推荐
问题理解
对话管理
答案供给。

如前面多轮对话的例子所示，当用户进入服务门户后，机器人首先是要如何引导用户精准地表达需求，这样即可降低用户迷失或者直接转人工服务，也降低了若机器人不能正确理解时带来的多轮澄清等无效交互。

该问题是一个标准的曝光点击问题，它的本质是推荐问题。

我们采用了CTR预估任务经典的FM模型来作为基础模型，同时结合业务目标，期望用户点击的问题的解决方案能够解决用户问题，该问题最终定义为“曝光、点击、解决”问题。

上面提到 CTR预估任务模型和 FM模型，尼恩给大家加点基础的学习材料。

CTR（点击率）预估模型是用于预测用户对广告、推荐内容等点击的概率的模型。在在线广告、推荐系统等领域，CTR预估是一项重要的任务，它能够帮助系统根据用户的历史行为和属性，预测用户是否会点击某个广告或推荐内容，从而优化广告投放或内容推荐策略，提高点击率和用户体验。

CTR预估模型通常基于大量的用户行为数据和广告/内容属性数据进行训练，其中包括用户的历史点击数据、浏览行为、搜索记录等，以及广告或内容的特征信息，如广告的位置、展示次数、内容关键词等。这些数据被用来构建模型的特征，以便模型能够学习到用户行为和广告/内容之间的关联。

常见的CTR预估模型包括但不限于：

逻辑回归模型（LR）：LR模型是一种经典的二分类模型，常用于CTR预估任务。它通过线性加权的方式对各个特征进行组合，然后通过sigmoid函数将结果映射到0到1之间，表示点击的概率。
因子分解机模型（FM）：FM模型通过建模特征之间的交互关系来进行预测，具有较好的性能和可解释性。它通过对特征的交叉项进行因子分解来建模特征之间的交互关系，从而降低了模型的复杂度和参数量。
深度学习模型：近年来，随着深度学习技术的发展，越来越多的深度学习模型被应用于CTR预估任务，如多层感知机（MLP）、卷积神经网络（CNN）、循环神经网络（RNN）等。这些模型能够自动地学习到数据中的复杂特征和模式，从而提高了预测的准确性。

CTR预估模型的选择通常取决于具体的场景和需求，需要综合考虑模型的性能、效果、可解释性等因素，并根据实际情况进行调优和选择。

一个典型的推荐系统架构如下图所示：
在这里插入图片描述

一般会划分为召回和排序两层。

召回负责从百万级物品中粗选出千级数量物品，常用算法有协同过滤、用户画像等，有时候也叫粗排层；
排序负责对召回层召回的千级物品进行精细排序，也叫精排层；

CTR，Click-Through-Rate，也就是点击率预估，指的是精排层的排序。所以 CTR 模型的候选排序集一般是千级数量。

CTR 模型的输入（即训练数据）是：大量成对的 **(features, label) **数据。

何为 features？可以分为如下四类：

用户本身特征，例如用户的年龄、性别等；
用户行为特征，例如点击过的物品、购买过的商品等；
上下文特征，例如用户登录设备(IOS or Android)、当前时间等；
待排序物品特征，例如物品 ID、物品被点击次数、物品的点击率等；

可以看到，上面所有的 features 都是我们能够收集到的信息，其中有离散型特征（如物品 ID），也有连续型特征（如点击率）。

但是，计算机只能处理数字编码，所以需要对 features 进行编码。常用的编码手段有：

离散型特征使用 one-hot 或embedding；
连续型特征可以不处理，也可以分段离散化，再使用 one-hot 编码；

关于 one-hot 和 embedding，这里简单介绍一下。One-hot 编码和 Embedding 是常用于表示分类数据的两种方法。

One-hot 编码：
- 概念：将分类变量表示为一个由 0 和 1 组成的向量，其中每个维度代表一个可能的取值，只有对应分类的维度为 1，其他维度为 0。
- 优点：简单直观，易于理解和实现；适用于分类变量取值较少的情况。
- 缺点：维度灾难，当分类变量的取值较多时，导致生成的向量维度过高，占用内存空间大。
Embedding：
- 概念：通过将每个分类变量映射到一个低维的连续向量空间中，实现对分类变量的表示。这些向量通常在模型训练过程中学习得到，每个维度代表一个特征。
- 优点：能够更好地捕捉分类变量之间的相似性和关联性；能够处理高基数分类变量，降低维度灾难问题。
- 缺点：需要大量的训练数据来学习嵌入向量；可能需要调节向量维度和嵌入表大小等超参数。

选择使用 One-hot 编码还是 Embedding 取决于数据的特点、模型的需求以及实际情况。

一般来说，如果分类变量的基数较低且取值稀疏，可以考虑使用 One-hot 编码；
如果分类变量的基数较高且取值稠密，或者希望通过模型学习到变量之间的关联性，可以考虑使用 Embedding。

40岁老架构师尼恩提升，关于Embedding，请参见尼恩的大模型学习圣经 LLM大模型学习圣经：从0到1吃透Transformer技术底座

再看 CTR（点击率）预估模型里边的 FM模型：

FM模型是一种经典的CTR（点击率）预估模型，用于预测用户对物品的点击率。FM模型通过建模特征之间的交互关系来进行预测，具有较好的性能和可解释性。

FM模型的全称是Factorization Machines（因子分解机），其核心思想是将特征的高维交互关系通过低维的因子分解来表示，以降低模型的复杂度和参数量。FM模型主要包括两部分：一阶特征和二阶交叉特征。

一阶特征：一阶特征指的是每个特征的单独作用，即特征本身的权重。在FM模型中，一阶特征由线性模型表示，对每个特征分配一个权重，用于衡量该特征对预测结果的贡献程度。
二阶交叉特征：二阶交叉特征表示特征之间的交互关系，即特征对之间的组合效应。FM模型通过对特征的交叉项进行因子分解来建模特征之间的交互关系，这种因子分解的方式可以减少参数量，提高模型的泛化能力。

FM模型通过将一阶特征和二阶交叉特征相加得到最终的预测结果，其中二阶交叉特征的计算通过特征的隐向量表示进行。FM模型相比于传统的线性模型，能够更好地捕捉特征之间的高阶交互关系，从而提高了预测的准确性。

CTR（点击率）预估模型和FM（Factorization Machine）模型的关系，二者是点击率预估领域常用的两种模型，它们之间存在密切的关系：

FM 模型：
- FM 模型是一种经典的用于处理稀疏特征的模型，它能够有效地捕捉特征之间的交叉关系。
- FM 模型通过学习特征的隐向量表示，以及特征之间的交叉项来建模特征之间的关联性。
- FM 模型的优点在于参数规模较小、计算效率高，尤其适用于处理高维稀疏特征。
CTR 预估模型：
- CTR 预估模型是用于预测用户对广告、推荐内容等点击行为的模型，通常用于在线广告投放、推荐系统等场景。
- CTR 预估模型的目标是根据用户的历史行为和特征信息，预测用户对当前内容的点击概率。
- CTR 预估模型通常会使用多种模型来进行预测，其中包括 FM 模型、LR（逻辑回归）模型、DNN（深度神经网络）模型等。

关系：

FM 模型可以作为 CTR 预估模型中的一个组成部分，用于处理特征之间的交叉关系。
在 CTR 预估任务中，FM 模型通常会和其他模型结合使用，例如将 FM 模型的输出作为其他模型的输入，以提高整体预测性能。
由于 FM 模型具有参数规模小、计算效率高等优点，因此在 CTR 预估任务中得到了广泛的应用，成为了该领域的经典模型之一。

在CTR预估任务中，FM模型被广泛应用于点击率预测、广告推荐等场景，通过对用户行为和物品属性的建模，实现了对用户行为的精准预测，从而提高了广告点击率和推荐效果。

最终的美团的智能机器人问题推荐的模型是结合多目标学习的ESSM-FM模型，对有效交互的转化率、转人工率和不满意度等指标上都带来了提升。

什么是 ESSM-FM 模型？

ESSM-FM（Enhanced Semantic Matching and Feature Fusion Model）是一种用于推荐系统的模型，结合了语义匹配和特征融合的方法。该模型旨在提高推荐系统中用户与物品之间的匹配准确度，从而提高推荐的效果。

ESSM-FM模型主要包含两个组成部分：语义匹配模块和特征融合模块。

语义匹配模块：该模块通过对用户和物品的语义信息进行建模，实现了更深层次的语义匹配。这通常涉及到使用词嵌入（Word Embedding）技术来表示用户和物品的文本信息，并通过神经网络模型来学习用户和物品之间的语义关系。
特征融合模块：该模块将语义匹配模块中得到的语义特征与传统的特征进行融合，以提高模型的综合表现。这些传统特征可以包括用户的行为历史、物品的属性信息等。特征融合通常采用一些融合策略，比如加权平均或者拼接等，将不同来源的特征整合到一个统一的特征向量中。

ESSM-FM模型在推荐系统中的应用可以有效地提升推荐的准确性和覆盖度，尤其是在处理复杂的用户行为和物品属性时具有一定的优势。该模型的结合了语义匹配和特征融合的思想，使得推荐系统能够更好地理解用户和物品之间的关系，从而提供更精准的推荐结果。

那么，ESSM-FM 模型与 FM模型的关系是什么呢？

大致如下：

ESSM-FM 模型（Entire Space Multi-Task Model with Factorization Machine）是在 FM 模型（Factorization Machine）基础上进行了改进和扩展的一种模型。以下是它们之间的关系：

基于 FM 模型的改进：

ESSM-FM 模型是对 FM 模型的改进和扩展，它在 FM 模型的基础上引入了更多的特征交叉和任务间的信息共享，以提高模型的性能和泛化能力。
特征交叉：

FM 模型主要处理低阶特征交叉，即二阶特征组合，而 ESSM-FM 模型引入了更高阶的特征交叉，可以处理更复杂的特征关系。
任务间信息共享：

ESSM-FM 模型还引入了多任务学习的思想，可以同时处理多个相关但不同的任务，通过任务间的信息共享和交互来提高模型的性能。
模型结构：

在模型结构上，ESSM-FM 模型通常会包含 FM 模型的部分作为基础模型，并在此基础上添加更多的层和模块，以实现特征交叉和任务间信息共享的目的。

总的来说，ESSM-FM 模型可以看作是对 FM 模型的一种扩展和改进，通过引入更多的特征交叉和任务间信息共享，提高了模型的表达能力和泛化能力，适用于更复杂的场景和任务。

智能机器人能力 2: 问题理解

这个例子背后的机器人是怎么工作的呢？

首先当用户输入“如何联系骑手”的时候，问题理解模块将它与知识库中的拓展问进行匹配，进而得到对应的标准问即意图“如何联系骑手”。

然后，对话管理模块根据意图“如何联系骑手”触发相应的任务流程，先查询订单接口，获取骑手电话号码，进而输出对话状态给到答案生成模块，根据模板生成最终结果，如右边的红框内容所示。

在这个过程中涉及到要先有意图体系、定义好Task流程，以及订单的查询接口，这些都是业务强相关的，主要由各业务的运营团队来维护。

那么，对话系统要做的是什么呢？

一是将用户的输入与意图体系中的标准问进行匹配，

二是完成多轮交互里面的调度。

问题理解是将用户问题与意图体系进行匹配，匹配到的拓展问所对应的标准问即用户意图。

问题理解的工作过程实际是要做召回和精排两件事情。

召回用现有检索引擎实现，
精排对召回的千级物品进行精细排。

美团自研的智能客服系统是从2018年开始搭建的，在建设的过程中，我们不断地将业界最先进的技术引入到我们的系统中来，同时根据美团业务的特点，以及问题理解这个任务的特点，对这些技术进行适配。

2018年之前，问题理解使用了DSSM 双塔模型。

这里的问题理解和搜索引擎和搜索广告类似，主要还是涉及在两个方面：召回和排序。

召回负责从百万级物品中粗选出千级数量物品，常用算法有协同过滤、用户画像等，有时候也叫粗排层；
排序负责对召回层召回的千级物品进行精细排序，也叫精排层；

DSSM 双塔模型，Deep Structured Semantic Model 由微软研究院提出，利用深度神经网络将文本表示为低维度的向量，应用于文本相似度匹配场景下的一个算法。因为效果不错并且对工业界十分友好，被各大厂广泛应用在推荐领域。

2018年年底，问题理解从DSSM 双塔模型升级到 BERT 模型。

当2018年底BERT（参见《美团BERT的探索和实践》一文）出现的时候，我们很快全量使用BERT替换原来的DSSM模型。

后面，又根据美团客服对话的特点，我们将BERT进行了二次训练及在线学习改造，同时为了避免业务之间的干扰，以及通过增加知识区分性降低噪音的干扰，我们还做了多任务学习（各业务在上层为独立任务）以及多域学习（Query与拓展问匹配，改为与拓展问、标准问和答案的整体匹配），最终我们的模型为Online Learning based Multi-task Multi-Field RoBERTa。

经过这样一系列技术迭代，我们的识别准确率也从最初不到80%到现在接近90%的水平。

智能机器人能力3: Task流程设计

理解了用户意图后，就对应到了一系列的标准问，如下图：

每一个标准问，都对应一个task流程，是跟业务强相关的，需要由业务的运营团队来进行定义。

如右边任务流程树所示，我们首先提供了可视化的TaskFlow编辑工具，并且把外呼、地图以及API等都组件化，然后业务运营人员可以通过拖拽的方式来完成Task流程设计。

对话引擎在与用户的真实交互中，要完成Task内各步骤的匹配调度。

比如这个例子里用户如果不是点选”可以但影响就餐了…”这条，而是自己输入说“还行，我要部分退款”，怎么办？

这个意图也没有提前定义，这就需要对话引擎支持Task内各步骤的模糊匹配。

我们基于Bayes Network搭建的TaskFlow Engine恰好能支持规则和概率的结合，这里的模糊匹配算法复用了问题理解模型的语义匹配能力。

这是另外一个例子，在用户问完“会员能否退订”后，机器人回复的是“无法退回”，虽然回答了这个问题，但这个时候用户很容易不满意，转而去寻找人工服务。

如果这个时候我们除了给出答案外，还去厘清问题背后的真实原因，引导询问用户是“外卖红包无法使用”或者是“因换绑手机导致的问题”，基于顺承关系建模，用户大概率是这些情况，用户很有可能会选择，从而会话可以进一步进行，并给出更加精细的解决方案，也减少了用户直接转人工服务的行为。

这个引导任务称为多轮话题引导，具体做法是对会话日志中的事件共现关系以及顺承关系进行建模。

如右边图所示，这里原本是要建模句子级之间的引导，考虑到句子稀疏性，我们是将其抽象到事件之间的引导，共现关系我们用的是经典的协同过滤方式建模。

另外，考虑到事件之间的方向性，我们对事件之间的顺承关系进行建模，公式如下：

并通过多目标学习，同时考虑点击指标和任务指标，如在非转人工客服数据和非不满意数据上分别建模顺承关系，公式如下：

最终，我们在点击率、不满意度、转人工率层面，都取得了非常正向的收益。

美团平台涵盖吃、住、行、游、购、娱等200多个生活服务品类，当用户是从美团App或点评App等综合服务门户入口进入服务时，需要先行确定用户要咨询的是哪个业务，这里的一个任务是“判断用户Query是属于哪个业务”，该任务我们叫做领域识别。

若能明确判断领域时，则直接用该领域知识来解答；
当不能明确判断时，则还需要多轮对话交互与用户进行澄清。

比如用户输入“我要退款”，在多个业务里都存在退款意图，这个时候就需要我们先判断是哪个业务的退款意图，如果判断置信度不高，则给出业务列表让用户自行选择来进行澄清。

领域识别模型主要是对三类数据建模：各领域知识库的有标数据、各领域大量弱监督无标数据和个性化数据。

依据从各领域知识库的有标数据中学习得到的问题理解模型信号，可以判断用户输入属于各业务各意图的可能性。
我们注意到除了美团App、点评App等综合服务入口涉及多个业务外，还有大量能够明确业务的入口，比如说订单入口，从商品详情页进来的入口，这些入口进来的对话数据是有明确业务标签信息的。因此，我们可以得到大量的弱监督的各业务领域的数据，基于这些数据我们可以训练一个一级分类模型。
同时，有些问题是需要结合用户订单状态等个性化数据才能进一步明确的。比如“我要退款”，多个业务里都会有。因此，又要结合用户状态特征一起来训练一个二级模型，最终来判断用户的输入属于哪个业务。

最终，该二级领域识别模型在满意度、转人工率以及成功转接率指标上都取得了非常不错的收益。

智能机器人能力4: 答案供给

售后客服场景通常问题较集中，且问题的解决多依赖业务内部系统数据及规则，通常是业务部门维护知识库，包括意图体系、Task流程和答案等。

但在售前场景，知识多来自于商户或商品本身、用户体验及评价信息等，具有用户问题开放、知识密度高、人工难以整理答案等特点。

比如去哪个城市哪个景点游玩，附近有哪些酒店，酒店是否有浴缸，酒店地址在哪里等，都需要咨询”决策”，针对这些诉求，我们通过智能问答来解决咨询以及答案供给问题。

智能问答就是从美团数据中习得答案供给，来快速回答用户的问题，基于不同的数据源，我们建设了不同的问答技术。

针对商家基础信息，比如问营业时间、地址、价格等，我们通过图谱问答（KBQA）来解决。利用商家基础信息构建图谱，通过问题理解模型来理解问题，进而查询图谱获取准确的答案。
针对社区数据，即商户详情页中“问大家”模块的用户问用户答的社区数据，构建社区问答（Community QA）能力，通过对用户问题与问大家中的”问答对”的相似度建模，选择相似度最高的作为答案，来回答用户的一些开放性问题。
针对UGC评论数据以及商户政策等无结构化数据，构建文档问答（Document QA）能力，针对用户问题利用机器阅读理解技术从文档中抽取答案，类似我们小时候语文考试中的阅读理解题，进一步回答用户的一些开放性问题。

最后，针对多个问答模块给出的答案，进行多答案来源的答案融合排序，来挑选最终的答案，此外这里还考察了答案真实性，即对“相信多数认为正确的则正确”建模。

这部分的详细介绍大家可以参考《美团智能问答技术探索与实践》一文。

智能机器人能力5: 话术推荐

在客服座席职场调研过程中发现，座席在与用户的对话聊天中经常回复相似甚至相同的话术，他们一致期望提供话术推荐的能力来提高效率。

此外，建议与商家直接沟通，下用户与商家直接沟通会使得解决问题更高效，而沟通效率不仅影响到消费者的体验，也影响到了商家的经营。

总之，无论是客服座席还是商家，都有很强的话术推荐诉求。

那么，话术推荐具体要怎么做呢？

常见的做法：

先准备好常用通用话术库，
部分座席或商家也会准备个人常见话术库，
然后系统根据用户的Query及上下文来检索最合适的话术来推荐。

我们根据调查发现，这部分知识库维护得很不好，既有业务知识变更频繁导致已维护的知识很快不可用因素，也有座席或商家本身意愿不强的因素等。

另外，针对新客服座席或者新商家，可用的经验更少。因此我们采用了自动记忆每个座席及其同技能组的历史聊天话术，商家及其同品类商家的历史聊天话术，根据当前输入及上下文，预测接下来可能的回复话术，无需人工进行整理，大大提升了效率。

我们将历史聊天记录构建成“N+1”QA问答对的形式建模，前N句看作问题Q，后1句作为回复话术A，整个框架就可以转化成检索式的问答模型。

在召回阶段，除了文本信息召回外，我们还加入了上文多轮槽位标签，Topic标签等召回优化，排序为基于BERT的模型，加入角色信息建模，角色为用户、商家或者座席。

整个架构如上图所示，分为离线和在线两部分。

另外上线后我们也加入了一层CTR预估模型来提升采纳率。

当前多个业务的话术推荐平均采纳率在24%左右，覆盖率在85%左右。话术推荐特别是对新座席员工价值更大，新员工通常难以组织话术，通过采纳推荐的话术可以来缩减熟练周期，观测发现，3个月内座席员工的平均采纳率是3个月以上座席员工的3倍。

美团智能客服的对话平台“摩西”

构建一个怎么样的对话平台，才能提供期望的没有NLP能力的团队也能拥有很好的对话机器人呢？

首先是把对话能力工具化和流程化。

如下图所示，系统可分为四层：应用场景层、解决方案层、对话能力层、平台功能层。

应用场景层：在售前应用场景，一类需求是商家助手，如图中所列的美团闪购IM助手和到综IM助手，需要辅助商家输入和机器人部分接管高频问题能力；还有一类需求是在没有商家IM的场景需要智能问答来填补咨询空缺，比如图中所列的酒店问一问和景点问答搜索；另外售中、售后以及企业办公场景，各自需求也不尽相同。
解决方案层：这就要求我们有几套解决方案，大概可以分为智能机器人、智能问答、商家辅助、座席辅助等。每个解决方案的对话能力要求也有所不同，这些解决方案是需要很方便地对基础对话能力进行组装，对使用方是透明的，可以拿来即用。
对话能力层：前面也进行了相应的介绍，六大核心能力包括问题推荐、问题理解、对话管理、答案供给、话术推荐和会话摘要。
平台功能层：此外，我们需要提供配套的运营能力，提供给业务方的运营人员来日常维护知识库、数据分析等等。

其次，提供“一揽子”的解决方案，还需要针对处在不同阶段的业务提供不同阶段的解决方案。

有些业务只希望维护好常用的问答，能回答高频的问题就好，那么他们只需要维护一个入门级的机器人，只需要在意图管理模块来维护它的意图，意图的常见说法以及答案就可以了。
而对于有运营资源的团队，他们希望不断地去丰富知识库来提升问答能力，这个时候可以使用知识发现模块，可以自动地从每天的日志里面发现新意图及意图的新说法，运营人员只需要每天花一点时间来确认添加及维护答案即可，这是一个进阶的业务方。
还有一些高级的业务方希望调用他们业务中的API来完成复杂问题的求解。这个时候他们可以使用TaskFlow编辑引擎，在平台上直接注册业务的API，通过可视化拖拽的方式来完成Task编辑。

此外，为了进一步方便更多的业务介入，我们也提供了一些闲聊、通用指令、地区查询等官方技能包，业务方可以直接勾选使用。另外，随着我们不断在业务中沉淀，也会有越来越多的官方行业技能包。整体方向上是逐步让业务方使用的门槛变得越来越低。