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

作者：智能小蜜团队

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

一、前言

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

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

二、当前落地方案-基于大模型的进化

2.1 从 Pipeline 到大模型直出，将 NLU/DM/NLG 通过大模型端到端替换

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

从技术角度，原有多模型 pipeline 式的对话链路随着多年的迭代和打补丁已经过于复杂，而大模型可以大幅简化链路，并且一定程度缓解误差传播。
从业务角度，技术升级最重要的还是需要 LLM 在对话能力上带来体感上的明显变化，才有可能进一步影响业务指标。
对于备受关注的风险问题，大模型出现的生成幻觉问题会不会影响业务效果？这个问题要分情况看，一方面我们从技术角度减少幻觉的产生，一种是从业务角度减少幻觉产生的影响，这需要结合场景的进行设计。

2.2 阿里小蜜：分阶段、分场景的业务覆盖

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

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

✪ 2.2.1 多轮问题定位

业务背景

作为客服机器人，阿里小蜜需要承接用户表达的问题并进行理解，进而定位到对应的知识或解决方案流程。过去小蜜问题沟通的模式始终没有跳脱出一问一答的形式，长远来源，这样会导致两大类问题：

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

业务挑战 &难点

诚然单轮交互存在着各种问题，但多轮化的改造、尤其是基于大模型的多轮化改造也需要解决以下几个难点：

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

方案设计

线上链路设计

我们在风控上做了较多的把控，对准入和准出都进行了严格的限制，在接入风控模型的基础上，我们还载入了违禁词库对输入文本进行准入控制。

另外，通过判断模型输出不同的标记来区分多轮对话阶段，如“[定位问题]xxxxx”，表示模型判断可以进行知识库检索，我们将模型生成结果进行检索，并定位到对应解决方案，结束问题沟通。而拒识或澄清，我们将会输出话术并与用户进行进一步确认。COT 主要发挥的核心作用是，让模型学习到作为一名淘宝售后客服，回答用户问题的主要思路和模版。

对齐人工端沟通能力

为了建设小蜜问题沟通阶段的多轮能力，最直接的学习目标就是对齐人工端小二沟通习惯。因此我们对人人语聊进行了细致的处理，使得模型尽可能模仿小二进行问题沟通。

增强模型泛化性

训练初期，我们发现模型比较容易过拟合，容易生成高频且带有幻觉的结果，泛化性很差；其次，全部使用人工咨询的 SFT 指令进行训练，模型的通用指令能力似乎丧失了，也难以对通用知识进行拒识，因此我们混合了更多通用数据，对模型进行重新 SFT 训练，增加模型的泛化能力，避免定位到错误的解决方案误导用户。

业务应用

基于大模型的多轮问题定位能力 AB 期间对于自主对话的部分带来了了转人工率的下降和满意度的明显上升，9 月份完成在淘宝小蜜的全量上线。

诉求澄清+信息收集

信息不足反问

✪ 2.2.2 case 服务轨迹理解及应用

业务背景

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

业务难点 &挑战

在大模型时代之前，算法侧对于 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 水平。

【数据层】

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

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

【模型层】

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

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

【训练层】

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

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

实际线上流程

业务应用

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

2.3 店小蜜 &自营小蜜

业务背景

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

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

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

售前商品问答

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

整体链路

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

商品问答大模型效果

模型能力对比

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

业务应用

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

三、总结

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

影响 LLM 业务效果的因素比小模型更复杂：基座模型、Prompt 工程、SFT 数据、训练的 Trick，优化哪个是最有效的？
在垂直领域，单纯依靠无 Finetune Prompting 无法满足业务效果，我们需要进行一定程度 SFT 的前提下，我们发现 SFT 在 LLM 上极容易过拟合。那么此时基座的能力和 SFT 任务的关系是什么？我们是应该选择“能力更好的基座”还是“更容易被 SFT 的基座”？
我们大量的算法工作还是停留在"更换基座->更换 SFT 数据"的循环中，本质是一种“基于 LLM 的监督学习”，如何更有机的结合 Prompt 工程、SFT、甚至 Continue Training 打出一套领域落地的组合拳，还没有清晰的成功路径。
Agent 是否是实现 AGI 的最近靠谱路径？我们能否基于 Agent 架构更进一步逼近拟人、更强泛化和业务推理能力的客服 AI？
....

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