「我在淘天做技术」智能对话新纪元：百万日活对话机器人的LLM落地实践

阿里小蜜家族（阿里小蜜、店小蜜、万象），从2015年发展至今，已经成为了覆盖淘天P-C（平台-消费者）、B-C（商家-消费者）、P-B（平台-商家）全咨询体系的智能对话机器人，日均接待量级在百万（阿里小蜜）到千万（店小蜜）范围。

作为淘天集团乃至行业内最大体量的对话机器人应用之一，阿里小蜜在对话算法能力上持续探索，在2022年chatgpt爆炸性的诞生之后，我们也加快了拥抱LLM技术的步伐。技术飞速发展，小蜜算法团队全力投入LLM在客服域的落地应用中，以端到端直出的方式，覆盖了售后小蜜场景的问题定位、SOP方案播放和沟通追问等环节，以及售前小蜜（自营店/店小蜜商家）的商品问答能力。

对于大模型在对话机器人中的业务&技术价值，我们也有过反复的思考和讨论，但我们对LLM在小蜜中应用的终极目标一直保持不变，也就是用LLM端到端的实现对话生成，这是基于以下的判断：

1. 从技术角度，原有多模型pipeline式的对话链路随着多年的迭代和打补丁已经过于复杂，而大模型可以大幅简化链路，并且一定程度缓解误差传播。

2. 从业务角度，技术升级最重要的还是需要LLM在对话能力上带来体感上的明显变化，才有可能进一步影响业务指标。

3. 对于备受关注的风险问题，大模型出现的生成幻觉问题会不会影响业务效果？这个问题要分情况看，一方面我们从技术角度减少幻觉的产生，一种是从业务角度减少幻觉产生的影响，这需要结合场景的进行设计。

我们从业务视角将一通消费者的客服咨询对话拆分为三个阶段：问题沟通、SOP操作和方案沟通。

在业务分割的基础上，我们分阶段的实现了不同的大模型对话能力（如下图）。同时针对营销活动/购买指南等以FAQ/文档为主的业务场景，我们没有采用多阶段方案，而是直接使用了端到端检索增强的算法来实现对话。

业务背景

1. 对用户表达精确度提出了较高的要求，因为更自然的表达方式往往不一定能定位到准确的解决方案。
2. 为了适配小蜜的单轮问题沟通效果，整体的知识体系中的知识也朝着越来越全、越来越大的模式演进，以保证用户的问题或诉求理解不会偏移。

业务挑战&难点

1. 多轮状态下知识定位的准确性，多轮交互下如何保证能精准理解用户多阶段表达的内容并精确定位到知识
2. 大模型生成内容风险控制，在立项之初，淘天集团内尚未有直接将大模型生成内容用于C端输出的应用可供参考，因此如何在提升对话多样性的情况下控制生成风险是需要解决的问题。

方案设计

• 线上链路设计

• 对齐人工端沟通能力

• 增强模型泛化性

业务应用

业务背景

以上我们讨论了用户进线后问题沟通的能力优化，然而小蜜的问题预测或沟通能力始终和人工有差距，其中一个重要的因素就是进线时小蜜没有任何上下文，而人工小二则可以查阅丰富完整的服务轨迹信息。

业务难点&挑战

在大模型时代之前，算法侧对于case服务轨迹的理解也进行了探索并在首页猜问等场景落地，但受任务定义、模型框架等方面影响，理解内容存在一定的局限性，特别是对于需要进行灵活理解的场景较难适配，导致小蜜对服务轨迹包含的信息利用不够充分。

从用户视角而言，进线后缺乏直接的“被理解”的体感，且在对话中需要重复描述，说明小蜜的“智能”能力存在提升的空间，从平台运营视角而言，对于case服务轨迹理解的不充分，导致较难实现解决方案和转人工策略（如重复进线场景）的差异化运营。

整体case服务轨迹能力的架构设计如下，我们先基于BC语聊在未问先答应用场景进行了试点。

BC语聊在未问先答场景应用

“未问先答”是小蜜推出的新能力，在用户刚刚进线时，根据用户当前状态，立即推送用户可能需要的解决方案，更快地帮助用户路由到问题，减少咨询成本。

业务应用

考虑到信息的抽取结果将会应用到下游丰富的大模型对话场景，而抽取枚举值将会损失丰富的细节信息，因此我们考虑让模型既可以输出自然语言摘要结果，也可以输出对应的枚举值，流程如图所示：

✪ 2.2.3 生成式快捷短语

业务背景

为了让小蜜可以更好的定位到用户的问题，在小蜜整体的交互中，增加了一些以推荐为导向的方法，快捷短语便是其中的一环。快捷短语的目的是生成单个或多个用户可能想了解/输入的内容，让用户通过点击基于知识/问题的快捷短语来与小蜜进行交互，在减少用户输入成本的同时帮助用户快速获取解决方案。

结合小蜜中逐渐落地的大模型能力，配合小蜜的新的表达形式，快捷短语也诞生了新的交互形式变化，即生成式快捷短语。

业务难点&挑战

生成式快捷短语的目的是生成用户可能想要输入的内容，而后用户可以通过点击的方式输入文本，与小蜜进行交互的同时，配合小蜜中的大模型多轮定位等功能， 帮助用户快速定位到需要的解决方案。这就要求快捷短语生成的内容具有如下特点：

• 完整性：可以完整表达用户遇到的问题与诉求，帮助用户快速定位问题；

• 业务相关性：生成的内容有实际的业务相关性，如问题或诉求等相关业务属性的完整描述。

但是在现实中，用户并不会经常做到“一次性输入完整内容”，而是会有如下特点：

• 多次/多轮输入：用户一般要通过多次内容输入才能把自己的问题与诉求表达清楚；

• 同种语义，多种表达：用户对于一些词汇的理解不同，表达上也不统一；

• 表达内容无利于定位：用户的情绪化表达，以及其他一些叙述，无法帮助用户推进解决问题。

生成内容的要求与实际生活中用户的输入有较大的差距，这也给我们带来了挑战。

方案设计

生成式快捷短语的目的是生成用户可能想要输入的内容，配合小蜜中的大模型多轮定位等功能，推进用户对话进展的同时获取解决方案。与之前的绑定知识不同，生成式快捷短语不绑定固定知识，而是让用户以对话的形式走大模型多轮定位获取解决方案。

考虑到大模型的性能问题，实际线上部署的时候，先以前置判别模型进行判别，用以减少大模型调用量。

基于不同场景下需要展示的内容的不同，结合之前已经存在的基于知识/问题的快捷短语，设计了以下链路:

业务应用

从线上AB效果来看，特定场景下生成式快捷短语相比基于固定候选池的推进式短语点击率提升明显，显著降低了用户输入的成本，帮助用户快速获取解决方案。

✪ 2.2.4 多轮追问生成

业务背景

传统的对话机器人设计分为2种类型，1）每轮咨询重新定位方案，导致对话隔离感非常强，几乎没有多轮对话的体感；2）依赖于多轮剧本，通过运营维护多轮剧本，将一个问题完整的解决掉，但是运营成本和维护成本都非常高。

业务挑战&难点

消费者在小蜜机器人咨询问题繁多，包含了闲聊、单诉求和多诉求。而每轮诉求之后，消费者通常会针对小蜜当前所给出的解决方案进行一步咨询，咨询内容大概包含以下3种情况：1）对当前诉求的进一步描述或者对当前答案的进一步询问；2）表达情绪上的不满、催促或者感谢；3）当前诉求完结，跨诉求咨询其他新问题。因此如何精准判别消费者的同诉求追问并给出拟人化的合理性回复是算法面临的挑战。

方案设计

业务应用

我们在淘宝/天猫平台小蜜机器人中，上线应用了多轮追问大模型生成能力，针对消费者单个诉求完成了更好的多轮对话，降低了对话割裂感，最终降低了转人工率、并提升了满意度，让用户能够在小蜜获得更好的对话服务体验。

✪ 2.2.5 基于检索增强的文档问答大模型应用

业务背景

淘宝促销活动期间，用户咨询机器人有关活动问题的量就会暴涨，为了更好的支撑平台的活动，给到消费者更好的购物体验，业务运营耗费了大量的成本消化活动、维护活动FAQ。

业务挑战&难点

活动期间基本处于封网状态（特别是活动量最大的双十一），算法很难基于现有样本重新训练，因此要求算法模型具备较强的ZERO-SHOT能力。

双十一活动的特点是多样性高、时效性强，且规则较为复杂，如何结合淘宝的规则更好的理解消费者的问题，并且给出浅显易懂的回复答案是算法面临的挑战。

方案设计

• 工程链路设计

我们对文档按段落进行拆分，得到文档的段落内容以及对应的各级标题。然后对段落内容以及各级标题分别进行向量化，并保存到向量数据库中。检索时，我们将用户的query也进行向量化，然后与向量数据库中的向量进行匹配，搜索最相似的n条文档段落，最后将这些段落交由大模型进行最终的答案生成。整体流程如下：

文档索引构建可以将文档转为文档索引块（Chunk），主要分为解析（Parsing）和切分（Chunking）两步：

• 算法方案

• Doc向量化

• 【SimCSE模型架构】基于SimCSE模型结构，最后一层将embedding向量投影到256维。

• 【效果评估】我们在小蜜数据集上对我们的模型进行测试，并与其他开放的模型进行对比。

• Doc重排

在进行重排优化策略时，我们针对数据层、训练层和模型层均进行了针对性实验及优化。

• 【效果评估】

我们在小蜜自己的重排benchmark数据集上评估了模型效果







为了验证模型的泛化性，我们在开源的数据集上也进行了评估，我们的large版本已经可以达到当前的SOTA水平。

• SFT

【数据层】

1. 少量高质量的业务域问答数据+大量的高质量通用域问答数据;

2. Role Prompt采用[Human, Assistant]的方式。

    【模型层】

1. 基座选择Qwen7b，文档问答的prompt都非常长，采用较小的基座来兼容效果并能实际在业务落地；

2. 更长的context并不会带来效果上的提升，我们尝试过8k版本或者自己训练的4k版本，发现评测效果相比2k没有带来明显的提升。

    【训练层】

1. 训练采用全参训练，经过我们的多次实验，7b模型的全参相比lora能取得更好的效果；

2. 对于训练的超参，我们发现对于训练的超参进行业务域的微调带来的提升并不明显且成本高。

• 实际线上流程

业务应用

我们在淘宝/天猫平台小蜜中，分别上线应用基于FAQ检索增强的大模型生成和基于文档检索增强的大模型生成,通过AB实验对比，对满意度和转人工都带来了正向提升。

业务背景

店小蜜是一款服务于消费者、人工客服、训练师和商家运营的全链路客服机器人，日承接对话3000万轮次。

店小蜜零售大模型旨在提高大模型在零售场景的服务问答场景（包括但不限于商品问答能力、营销导购能力、商品文案以及图片生成能力、服务诊断能力等）以及店铺运营水平。

以下是用户在店小蜜的服务流程

售前商品问答

商品问答是基于商品知识库、商品详情页等数据源，来回答消费者提出的商品属性相关的问题，这类问题通常可以交给智能机器人处理，节省售前咨询人工成本。

• 整体链路

如图所示，商品问答大模型整合了多种知识源侧信息，包括商品知识库、IC库等，将各个源的信息进行整合形成商品知识文档作为模型输入。考虑到线上RT限制，在将商品知识文档传给大模型之前先进行多源商品知识召回，将各个源头与消费者咨询最相关的知识给到大模型，在保证回复内容准确的同时兼顾回复的响应时间。

商品问答大模型效果

模型能力对比

可以看出，大模型的精准率、覆盖率基于小模型分别提升17pt/2pt。从实际消费者问答参评满意度看，消费者对大模型返回答案的认可度更高，大模型也带来了商品咨询转化率的提升。

业务应用

在商品问答场景，大模型的优势主要有：更强的检索能力、更丰富的外部知识、更强的理解推理能力。详细可以见下表的case梳理。

小蜜对话能力全面拥抱大模型，我们也初步看到了LLM在服务对话领域巨大的应用潜力。与此同时，LLM也带来了算法方法论的完全变革，也涌现了一系列的问题值得我们进一步的探索：

1. 影响LLM业务效果的因素比小模型更复杂：基座模型、Prompt工程、SFT数据、训练的Trick，优化哪个是最有效的？

2. 在垂直领域，单纯依靠无Finetune Prompting无法满足业务效果，我们需要进行一定程度SFT的前提下，我们发现SFT在LLM上极容易过拟合。那么此时基座的能力和SFT任务的关系是什么？我们是应该选择“能力更好的基座”还是“更容易被SFT的基座”？

3. 我们大量的算法工作还是停留在"更换基座->更换SFT数据"的循环中，本质是一种“基于LLM的监督学习”，如何更有机的结合Prompt工程、SFT、甚至Continue Training打出一套领域落地的组合拳，还没有清晰的成功路径。

4. Agent是否是实现AGI的最近靠谱路径？我们能否基于Agent架构更进一步逼近拟人、更强泛化和业务推理能力的客服AI？

5. ....

上面的每一个问题，在LLM时代目前都还是Open Problem，它带来的既是兴奋，也有挑战，小蜜也将持续走在LLM业务应用的最前沿。

阿里小蜜+店小蜜作为承载淘天P、B、C三方沟通的全场景对话机器人业务，也是LLM进行业务落地的最佳场景之一，在“聊天”的基础上为客户真正的“解决问题”，也对机器人的能力提出了更高的要求。我们还将持续在基于大模型的对话机器人领域探索，以实现真正“类人”的对话能力和丝滑的客服体验为目标。

欢迎对相关领域感兴趣，有追求的同学加入我们，简历请发至elsa.ge@taobao.com。

你的所有算法成果都将能直接影响百万级的消费者体验：）

欢迎留言一起参与讨论~