把 LLM 用于客户支持：最先崩的是什么

客户支持是企业最热门的 AI 首选用例，这不无道理：演示太诱人了。你把模型接上帮助文档，问它一个问题，它就流畅地答了出来。但从那个演示到一套你真能跑起来的系统之间，隔着一道大多数项目都迈不过去的鸿沟。本文按团队通常遇到问题的先后顺序，梳理最先崩的是什么，好让你提前为这些故障做准备，而不是在生产环境里才发现它们。

演示很容易；运营很难

演示之所以成立，是因为它展示的是最轻松的路径：一个清晰的问题，对应一个干净的、就写在文档里的答案。真实的支持流量不是这样的。它充满含糊的问题、缺失的信息、边缘案例、愤怒的客户，以及那些需要执行一个动作、而非给出一个答案的请求。在演示里大放异彩的模型，第一天上线就会撞上所有这些。为演示做规划，等于在为那从来不是问题的百分之五流量做规划。

崩点 #1：它在该不知道的时候照样回答

最先崩的是"自信"。支持模型会去回答那些答案根本不在你文档里的问题，凭空编造出听起来合理的政策、价格或步骤。客户分不清哪个是有依据的答案、哪个是捏造的——两者听上去同样流畅。一个关于退款政策、自信而错误的答案，造成的损失就可能超过整套系统省下的全部成本。

解法是接地与诚实：从你真实的文档中检索，要求模型只依据检索到的内容作答，并在不知道时明确说出来、转交人工。难的不是这条指令——而是接受"我不知道，让我帮您转接同事"是一个好结果，而非一次失败。

崩点 #2：检索漏掉了相关文档

一旦你把答案接地到文档上，下一个故障点就往上游移动了：模型依据了错误的文档、或根本没有文档来作答，因为检索漏掉了那篇相关的。这是每个检索系统都要学到的同一课——大多数故障都是检索故障。如果正确的帮助文章没有摆在模型面前，再流畅的生成也产生不了正确的答案。

这正是那些不起眼的工作开始回报的地方：保持知识库干净、及时更新，把文章合理地分块，并衡量针对真实问题是否真的检索到了正确的文章——这要和"最终答案读起来是否通顺"分开来衡量。

崩点 #3：知识库本身就是错的或过时的

支持模型的好坏，取决于它背后的文档。多数公司在接入模型时才发现，自家帮助中心自相矛盾、描述的功能早已变更、或者客户问得最多的那件事压根没写。AI 并没有制造这个问题；它只是把问题大规模地、当着客户的面暴露出来。成功的团队会把文档清理当作项目的一部分，而不是某个别人会去搞定的前置条件。

崩点 #4：它无法安全地执行动作

回答问题是一回事；去做某件事——发起退款、修改地址、取消订单——是另一回事。支持助手一旦能执行动作，赌注就变了。答错令人尴尬；做错动作则会动到钱或数据。真实部署会划出一条审慎的界线：低风险动作模型可以直接执行，较高风险的需要确认或人工介入，所有动作都要有清晰的审计记录。这种因情境而异的风险管理，正是 NIST AI Risk Management Framework 这类框架所提倡的——让控制措施匹配其后果。

崩点 #5：转交人工很笨拙

没有哪个支持 AI 能处理所有情况，所以转交人工是产品的一部分，而不是事后补丁。它崩在哪里：模型转交时不传递上下文，于是客户得重复一遍、火气更大；或者它拒绝转交，把客户困在一个死循环里。好的转交是无缝的——它带着对话、客户意图以及已经尝试过的方案，让人工一接手就掌握情况。

崩点 #6：没有人在衡量正确的东西

最后一个故障是悄无声息的。团队衡量"分流率"（AI 处理了多少工单）并为此庆祝，却不衡量那些答案是否正确、客户是否反而更愤怒地回来了。没有质量的分流，只是在掩盖问题。能长久运转的部署会衡量解决质量和客户结果，定期阅读真实的对话记录，并把最糟糕的那些答案当作信号——而不是看平均值。

存活者的共同之处

那些能跑通的部署有一个共同模式：它们把模型当作系统中的一个组件，而非系统本身。它们让答案接地、刻意设计好"我不知道"这条路径、保持知识库诚实、为高风险动作设置闸门、让转交优雅顺滑，并衡量质量而不只是数量。这些都不稀奇。它们正是"交付演示"与"运营系统"之间的区别。

总结

支持聊天机器人是最容易做出来的 AI 演示，却是最难真正运转好的系统之一。它会依次崩在：过度自信、检索、过时文档、不安全的动作、笨拙的转交，以及错误的指标上。这每一项都是可以预见的。提前为它们做规划，AI 支持层就会成为一项真正的资产。跳过规划、直接交付演示，那些故障就会由你的客户替你找出来。