客服后台接入AI大模型，最初几天往往很安静。问题少了，回复快了，坐席似乎能腾出手来做别的事。可再过一阵，一些细小的异常会冒出来：客户问的是上周刚调整的退换货规则，模型却按旧版本回答；一段多轮对话里，客户已经说明“不是这个订单”，模型仍沿着上一轮的错误前提往下走。回答读起来很顺，但不一定对。
这类场景让我意识到，模型在客服中的角色，常被误解成“更聪明的知识库”。它确实能组织语言、理解模糊表达，也能把零散信息拼成一段像样的回复。但它并不天然知道企业昨天改了什么规则，也不保证每一轮对话都记得住上下文。把模型接进系统，只是第一步；让它稳定地做对事，靠的是模型之外的工程。
先分清“会说”和“知道”
AI大模型的强项在语言生成，不在事实存储。企业知识如果只靠训练阶段灌进去，更新会非常慢；而客服场景偏偏对时效敏感。更现实的做法，是把知识检索放在模型前面：用户问题先经过检索，找到相关文档或工单，再把有限材料交给模型组织回答。检索增强听起来不新鲜，但真正难的是文档切分、权限过滤、过期内容清理，以及检索不到时怎么让模型承认“不知道”。
我见过一种常见误区：把产品手册整本丢进向量库，就以为知识库完成了。实际使用中，客户问的是具体场景，手册写的是功能列表，两者之间隔着一步转译。检索增强不是把文档搬进数据库，而是把“客户会怎么问”和“企业怎么规定”对齐。否则模型只能拿到一堆看似相关却不够具体的段落，回答自然发虚。
上下文不是越长越好
多轮对话里，上下文管理比模型参数量更容易被低估。把整段历史都塞给模型，成本会上升，噪声也会增加；只保留最近几轮，又可能丢掉关键前提。比较务实的做法，是把对话状态显式记录下来：客户身份、订单阶段、已确认的条件、尚未解决的问题。模型每次生成前，拿到的是经过整理的状态，而不是一长串原话。
这听起来像传统软件工程，确实也是。模型并没有让系统设计消失，反而把状态管理、权限控制、失败回退这些老问题放大了。模型输出不稳定，系统就需要有校验和兜底；模型可能编造，界面就需要给出处或转人工。把这些工作做完，模型才像一个可用的组件，而不是一个演示玩具。
评测要贴着业务走
很多团队上线前会跑一批通用评测，分数看起来不错，到了真实业务里却频繁出错。原因不复杂：通用评测测的是语言能力，业务评测测的是“在这个流程里有没有做对”。客服场景的评测集，应该来自真实问题，覆盖规则变更、边界条件、模糊表达和恶意提问。评测指标也不只是回答是否流畅，还要看是否引用了正确文档、是否越权承诺、是否在不确定时转人工。
这件事没有一劳永逸的答案。业务在变，知识在变，模型版本也在变，评测集需要持续维护。与其追求一次上线就稳定，不如把评测当成日常动作：每次知识更新、每次提示词调整，都拿同一批难题回测。这样做的成本不低，但比在客户投诉里发现问题要低。
人工坐席的位置变了
回到开头那个场景：接入AI大模型后，人工坐席是不是可以关掉？我的判断是，短期内不太现实。模型适合处理高频、规则清晰、容错空间大的问题；一旦涉及例外、情绪安抚或责任判断，人工仍然不可替代。更合理的变化，是坐席从“逐条回复”转向“处理模型拿不准的会话”，同时承担知识校正的工作。
这对组织流程提出了新要求。模型答错时，谁来标记？标记之后，知识库多久更新？坐席发现规则冲突，向谁反馈？如果这些路径没有打通，模型只会在同一个地方反复犯错。技术团队能调模型，业务团队能改规则，两者之间需要一条短反馈链。很多落地卡住，不是模型不够强，而是反馈链太长。
所以，AI大模型进客服后台，真正值得先问的不是“能不能替代人工”，而是“哪些环节可以由模型承担，哪些必须留给人”。回答流畅只是表面，稳定、可解释、可回退，才是它进入生产系统的门票。人工坐席未必需要关掉，但它的工作内容，大概率会被重新分配。