演示环境里的对话通常很顺。提问干净、上下文完整、答案在文档里躺着。等到真正接进客服系统，第一周就会冒出一类新问题：模型的回答没错，但答的不是用户问的那件事。
这不是模型突然变笨，而是提问的人变了。演示时提问的人知道自己在测什么；上线后提问的人带着情绪、错别字、没说完的半句话，还有一肚子前置条件。
顺，是因为提问被筛过
做内部评审时，大家习惯挑几个典型问题试。这些问题的共同点是：有明确答案，且答案就在手边的资料里。真实场景里的问题往往相反——没有标准答案，需要先确认身份、订单状态或者上一轮沟通的结论。
所以评估一套AI大模型能不能用，看它在干净提问上的表现意义有限。更有价值的是看它在模糊、矛盾、信息不全的提问上，会不会主动追问，还是硬着头皮编一个看起来合理的答案。
真正的成本落在边界上
很多团队最初的预算表里只有调用费用和开发人力，落地之后才发现，最耗神的是一堆说不清的边界：哪些问题必须答，哪些必须转人工，转的时候怎么措辞才不让人觉得被踢皮球。
拒答比回答难写。一句“我无法回答”会直接把用户推走。更常见的做法是给模型一个明确的动作集合——继续追问、给出条件性回答、转交、结束对话——让它在动作之间选，而不是在文字之间自由发挥。这些规则写下来很枯燥，但AI大模型的边界，其实取决于团队愿不愿意为它把规则写清楚。
知识库不是把文档塞进去
文档堆进去，检索未必好用。同一份制度可能在三个版本里存在，旧版本没删；产品参数更新了，模型还在引用半年前的口径。这类问题不会在测试集里暴露，只会在某次对话里突然冒出来，让客服同事事后花半小时解释。
可行的办法不复杂：给资料标上生效时间，定期清理过期内容，让检索结果带上来源，方便人工复核。这些是工程活，不好看，但决定体验的下限。
评价标准得自己长出来
公开的评测集大多和你的业务无关。真正有用的是把过去半年的真实对话拿出来，人工标一批：哪些回答合格，哪些勉强，哪些明显不该出现。几百条就够用，关键是持续补充——每次线上出问题，就把那一段对话收进去。
这件事没有捷径。标准长在自己的业务里，别人替不了。
几条务实做法
- 先限定场景，别一上来就让它处理全品类问题，从一个明确的任务开始。
- 把“转人工”当成正常路径设计，而不是失败兜底。
- 给回答留出处，让客服能在几秒内判断该不该采信。
- 记录每一次人工改写，那是最真实的反馈数据。
回到开头那个问题。把一个AI大模型接进流程，远不是买一个功能那么简单，它更像一次小的基础设施改造：资料要理清，边界要写下来，责任要有人接。模型只是其中一环，而且不是最难的那一环。
值得提醒的是，别把上线当成终点。上线只是让问题变得可见，真正的工作从看见问题才刚刚开始。