客服大模型 ≠ 问答机器人

为什么很多客服大模型，看起来很聪明，却一点也不好用

如果你做过客服相关的项目，大概率会经历一个非常相似的过程。

一开始，大家都很兴奋。
把历史客服文档、FAQ、知识库一股脑丢进 RAG，接上一个看起来很强的模型，测试时效果还不错。大多数常见问题都能答上来，语气也挺自然，看起来“已经能替代人工了”。

但只要一上线，问题就开始接连出现。

模型开始乱承诺
模型开始“过度热情”
模型在不该回答的时候给出非常完整的答案
模型不懂什么时候该升级人工
模型回答本身没错，但业务方看了直摇头

慢慢你会意识到一个问题：
不是模型不够聪明，而是你一开始就把客服这件事想简单了。

客服从来就不是一个“问什么答什么”的系统，它本质上是一个决策系统。而你用问答机器人的方式去做它，几乎注定会出问题。

一个必须先认清的事实：客服的核心目标，从来不是“回答问题”

这是做客服大模型之前，最容易被忽略、但又最关键的一点。

从技术视角看，我们习惯把客服理解为“用户提问 → 系统回答”。
但从业务视角看，客服真正关心的从来不是答案本身，而是风险、成本和结果。

客服要做的事情包括但不限于：

• 避免给出错误承诺
• 避免触发法律或合规风险
• 尽量减少人工介入成本
• 在必要时及时升级人工
• 控制用户情绪，而不是单纯输出信息

这些目标，和“答对一个问题”关系并不大。

一旦你意识到这一点，就会发现：
把客服大模型当成问答机器人，本身就是方向性错误。

为什么“FAQ + RAG + 大模型”的方案天然不适合客服

这是目前最常见的一种做法，也是失败率最高的一种。

逻辑看起来非常顺：
用户提问 → 检索知识 → 模型生成答案 → 完成客服。

问题在于，这套流程默认了一个前提：
“只要知识是对的，回答就是安全的。”

但在客服场景里，这个前提几乎从来不成立。

举个非常常见的例子。
用户问：“如果我现在退款，大概多久能到账？”

知识库里可能有非常明确的说明，但真实情况取决于支付方式、银行、节假日、用户历史行为等多个因素。一个完整、看似专业的回答，在业务上反而是危险的。

人类客服在这种情况下，往往会下意识地模糊表达、加前置条件、甚至直接引导用户走人工流程。但模型如果只是被训练成“尽量回答”，就会非常自信地踩雷。

客服系统真正需要的能力，不是“会答”，而是“会判断”

这是客服大模型和问答系统的本质分界线。

一个合格的客服系统，至少要具备几类判断能力：

• 这是不是一个高风险问题
• 这是不是一个需要人工介入的问题
• 我是否掌握了足够的信息来回答
• 我现在的回答，会不会被用户当成承诺
• 我是不是应该先澄清，而不是直接给结论

这些判断，本质上都不是知识问题，而是策略问题。

而策略问题，靠 RAG 是解决不了的。

客服问题从“知识型”到“策略型”的分布示意图

为什么客服场景几乎一定绕不开微调

很多团队一开始会对“微调”非常抗拒，觉得成本高、周期长、风险大，希望靠 prompt 和 RAG 解决一切问题。

但在客服场景里，如果你不做微调，几乎一定会踩同一批坑。

原因很简单：
你希望模型学会的，并不是“怎么回答某个具体问题”，而是“在什么情况下该怎么表现”。

这类能力，如果没有通过训练显式地教给模型，它是学不会的。

你可以通过 prompt 提示模型要“谨慎”“不要乱承诺”，但在复杂对话中，这种提示的约束力非常有限。一旦上下文变长、问题变复杂，模型还是会回到它最熟悉的模式：尽量给出一个完整、有帮助的回答。

客服微调的数据，和你想象的完全不一样

这是第二个非常容易走错的地方。

很多人一提到客服微调，第一反应是：
“那我是不是要准备很多问答数据？”

实际上，单纯的问答数据，对客服微调的价值非常有限。

真正有价值的数据，往往来自这些地方：

• 模型不该回答，但历史上回答过的问题
• 人工客服选择拒答或升级的对话
• 业务明确要求“只能这样说”的场景
• 同一个问题，不同处理策略导致不同结果的案例

这些数据，表面上看起来“啰嗦”“不标准”，但它们恰恰包含了客服系统最需要学习的东西：边界。

客服微调真正困难的地方：不是模型，而是“态度”

这是一个很多技术团队低估的问题。

在客服场景里，模型的“态度”往往比“内容”更重要。

太冷漠，会激怒用户
太热情，会抬高预期
太肯定，会变成承诺
太模糊，会被投诉敷衍

而这些东西，几乎没办法通过规则完全控制。

这也是为什么很多团队在 SFT 之后，模型依然“看起来不对劲”。它每一句话都没错，但组合在一起，就非常不像一个合格的客服。

这个时候，引入偏好对齐类方法（比如 PPO 或 DPO），往往会有明显改善。

客服场景下，PPO/DPO 到底在对齐什么

在客服微调里，PPO 或 DPO 很少是用来“让模型更懂业务”的，它们更多是在做一件事：
强化某些表达方式，压制另一些表达方式。

比如：

• 在不确定时，偏向澄清而不是直接给结论
• 在高风险问题上，偏向升级而不是解释
• 在用户情绪激动时，优先安抚而不是输出信息

这些偏好，很难用硬规则描述，但非常适合通过对齐训练来完成。

在实际工程中，常见的做法是：

• 先用 SFT 让模型“像个客服”
• 再用 PPO/DPO 把“客服边界”一点点拉清楚

客服微调中 SFT 与 PPO/DPO 分工示意图

一个真实的工程经验：客服大模型一定要“允许它说不知道”

这是我在多个项目里反复验证过的一点。

如果你的客服大模型从来不说不知道，那它迟早会出问题。

人类客服在面对复杂或高风险问题时，说“不确定”“需要确认”“我帮你转人工”，是一种非常成熟的职业行为。但模型如果没有被训练过这种行为，会天然倾向于“尽力回答”。

所以在客服微调数据中，我会刻意保留大量“拒答样本”和“升级样本”，并且在对齐阶段给它们非常明确的正反馈。

一个被忽略的事实：客服大模型的成功标准，从来不是“命中率”

很多团队在评估客服大模型时，依然沿用问答系统的指标：

• 回答是否正确
• 是否命中知识
• 用户是否得到答案

但在客服系统里，更重要的指标往往是：

• 投诉率有没有下降
• 人工介入是否更合理
• 高风险问题是否被拦截
• 用户情绪是否被有效缓解

如果你只盯着“答得准不准”，那你很可能会把一个高风险模型推上线。

实践层面的建议：别一开始就想“完全自动化”

这是最后一个我特别想强调的点。

很多客服大模型项目失败，并不是因为技术不行，而是因为目标定得太激进。一上来就想“完全替代人工”，反而让模型承受了它根本不该承担的责任。

更现实、也更安全的路径，往往是：

• 先做辅助型客服
• 再做低风险自动回复
• 逐步扩大模型的决策范围

在这个过程中，微调和对齐不是一次性任务，而是一个持续过程。

在这种逐步演进的节奏下，能够快速验证不同微调和对齐策略、反复对比模型行为变化的工具，会比“一次性大工程”更适合大多数团队。像 LLaMA-Factory online 这种在线方式，在早期阶段能明显降低试错成本。

总结：客服不是技术问题，而是边界问题

写到这里，其实可以很明确地说一句：
客服大模型失败的原因，90% 都不是模型不够强，而是你让它做了不该做的事。

一旦你把客服从“问答系统”里抽离出来，开始认真对待它的风险、边界和策略，你会发现很多之前看起来很难的问题，其实都有解法。

而真正难的，从来不是算法，而是你是否愿意承认：
客服大模型，永远不只是一个会回答问题的模型。