很多人用客服机器人时只看到「问一句、回一句」，一旦答非所问就归罪于「模型太笨」。其实中间有好几道工序，坏在哪一环，表现完全不一样。这篇按顺序把链路拆开：消息进来先做什么、意图怎么判、知识从哪来、答复怎么拼出来、什么时候该转人工。看完你能大致判断自家或采购的系统是卡在理解、资料还是生成上，也能对照站内模型与工具页面去核对具体参数。
很多人用客服机器人时只看到「问一句、回一句」，一旦答非所问就归罪于「模型太笨」。其实中间有好几道工序：接消息、判意图、捞知识、拼答复、决定要不要转人工。坏在哪一环，表现完全不一样——收不到消息是接入层的问题，答得通顺但政策是编的是知识库的问题，转人工后用户还得从头讲一遍是交接没做好。
这篇按顺序把链路拆开讲，每节都给能上手的判断标准和排查动作。看完你大致能判断自家或采购的系统卡在理解、资料还是生成上，也能对照站内页面去核对具体参数。要提数字的地方一律写在站内查，因为各家模型和工具的规格一直在变。
消息进来第一步：接住、清洗、分派
用户的消息不是直接丢给模型的。第一站是渠道接入层，它把网页、App、公众号、电商后台等不同来源的消息统一成一种格式，带上用户 ID、会话 ID、渠道标识。这一步出错的表现是「消息收不到」或者「上下文串台」——A 用户看到 B 用户的对话，这跟模型一点关系都没有，是接入层写坏了。
- 预处理：去掉表情和无意义重复、做拼写纠正、识别语种，长消息要切片，不然超出上下文窗口会被截断。
- 敏感信息如手机号、订单号会被单独抽出来当变量，而不是丢给模型硬读，既省 token 也避免泄露。
- 并发与排队：高峰期机器人排队延迟，用户看到「转圈很久才回」，这属于工程层问题，不是回复质量差。
- 可核对的点：到 AI 模型库（/models） 看同类系统常用的模型规格，再到 接口测速（/tools/speed-test） 量一遍自己这条链路的延迟基线。
意图识别到底在判什么
意图识别的输出不是一句话，而是一个标签加一个置信度，比如「查物流 / 0.82」。这个置信度决定接下来走哪条路：高于阈值就走自动答复，低于阈值就该追问或直接转人工。硬答低置信度的问题，是「答非所问」最常见的来源。
| 路线 | 特点 | 什么时候更合适 |
|---|---|---|
| 规则与关键词匹配 | 快、可控、覆盖窄 | 问题种类少、口径要求严格 |
| 模型分类 | 泛化好、需要样本、边界模糊时容易飘 | 问法多样、有历史会话可训练 |
| 先规则兜底再交给模型 | 兼顾可控与泛化 | 多数实际系统的做法 |
槽位抽取是常被忽略的一环：意图是「改地址」，还得从话里抽出订单号和新区位才能办事，抽不到就得反问补充。什么情况下不适用？用户问题本身就是开放式的、没有稳定意图分布时，强做意图分类反而更差，这类场景更适合直接走检索加生成。
答案从哪来：知识库、检索与拼装
- 固定话术与 FAQ
- 口径统一，适合退换货政策这类有标准答案的问题
- 业务系统接口
- 订单、库存这类实时数据，只能查不能编
- 非结构化文档
- 产品说明、帮助文档，需要检索才能用上
- 检索
- 把用户问题转成向量或关键词，从知识库捞回候选再按相关度排序
- 拼装
- 把检索结果、用户信息和会话历史按模板塞进提示词
捞回来的东西不对，后面生成再强也是错的。模型只负责组织语言，不该由它凭空补充规则里没写的政策。常见故障对照：答得通顺但政策是编的，多半是知识库没有这条却照样生成；答案对但格式乱，多半是拼装模板的问题。工具搭建思路可参考 客服与销售（/ai-nav/category/ai-customer-service） 里的工具目录，概念不熟先查 AI 术语词典（/ai-dict）。
生成答复与转人工的判定
生成阶段能做的约束：限定只能引用检索到的内容、要求给出来源、统一语气和称呼。如果系统允许模型自由发挥，就得接受偶发胡说的概率，这不是 prompt 能完全消除的。转人工触发条件通常有几类：置信度低、用户明确要求、连续追问同一问题、出现退款投诉等高风险词、会话轮次超限。
- 写清转人工触发条件把上面几类条件逐条写成阈值，别留在工程师脑子里。
- 检查人机交接转人工时要把前面聊过什么、已查到什么一起递过去，否则用户得从头再讲一遍。
- 准备一小批真实问法挑几十条真实问法跑一遍，统计「答对、答偏、该转没转」三类比例。
- 别只看顺手挑的样例几条挑出来的好样例说明不了问题，复盘的样本要覆盖高峰期和边缘问法。
转人工不是失败，是链路里设计好的出口；真正做坏的是出口之后用户还得重新讲一遍。
想选型或排查，按这个顺序走一遍
不管你是要自己搭还是采购，都可以按下面这个顺序过一遍，先定场景再看数据接口，最后才看话术这些表面东西。顺序反了容易被演示效果带偏。
- 第一步定场景：售前咨询、售后查询、内部工单，三者的知识源和转人工规则完全不同，先写清最常出现的几类问题。
- 第二步看数据接口：能不能实时读订单和库存，决定机器人是「只能答话术」还是「能真办事」。
- 第三步看可控性：能不能自己加知识、改话术、调转人工阈值，改一次要不要等厂商排期。
- 第四步小范围跑：挑一个渠道、一个时段上线，用真实会话复盘。
对照站内 客服与销售（/ai-nav/category/ai-customer-service） 与 AI 测评榜单（/benchmarks） 上的公开信息核对，具体数字都以站内页面当时显示的为准，不要记这里的口头描述。
下一步选型前先去站内客服与销售的导航页，把候选工具按知识源接入方式和转人工能力列一张表，再决定哪几个进小范围试跑。→常见问题
客服机器人是不是就是套一个大模型？
不完全是。模型通常只负责最后组织语言那一段，前面还有渠道接入、意图判断、知识检索这几道工序。很多「答非所问」的锅其实在检索捞错了资料，或者知识库里压根没这条，换更强的模型也救不回来。
为什么机器人有时候答得很通顺，内容却是错的？
因为它只被要求「说人话」，没被要求「只能照着资料说」。检索没捞到内容时，如果系统没有兜底策略（比如直接说不知道、转人工），模型就会顺着语境往下编。这类问题要从提示词约束和转人工阈值上改，不是换模型。
转人工太频繁或者几乎不转，哪个更麻烦？
两个方向都有代价。几乎不转，用户在一个死循环里被反复绕，投诉概率高；转得太勤，人力成本直接上去，机器人等于白上。可行的做法是把触发条件写清楚、按周复盘误判案例，再慢慢调阈值，具体定多少要看自己的客服排班和人力预算。
