AI客服答非所问，先改提示词还是知识库？

当用户询问“我的退款何时到账”时，AI助手却给出了通用的政策说明——这种答非所问的现象，其根源可能出现在路由、检索、知识版本或生成环节。本文通过实际案例，详细拆解排查流程，从日志还原到意图识别、知识检索、模型生成，教你用证据定位问题，避免盲目修改提示词。

用户在订单页面提问“我的退款什么时候到”，助手则回复“退款申请提交后，平台会按原支付方式退回，请耐心等待”。用户想要的是个人款项的进度信息，但助手提供的却是通用说明。

遇到这种情况，不要急于操作。答非所问，问题可能出在路由、检索、知识版本或生成环节，甚至可能根本没有调用实时数据。一上来就修改提示词，多半是徒劳。

以这个例子来说，回复内容来自帮助中心的通用退款说明，而该笔订单的退款状态实际是“已完成”，助手在当次对话中根本没有调用订单接口。个人进度查询压根没有进入实时查询步骤。

但这只是一个假设。在线上环境中，需要先确认当时的具体情况。必须查看那一轮对话的记录：用户原始话语和时间、入口和订单上下文、意图和路由结果、检索候选和版本、输入模型的上下文、工具调用和返回、提示词和模型配置版本，以及最终回答。缺少这些信息，只能复现相似的症状，无法说明当初为何答错。

首先，调取那一轮的日志

这条请求可以通过日志还原：从订单页面进入；用户询问退款到账时间；系统路由到政策问答模块；检索返回通用退款说明；未调用退款查询接口；模型基于这些材料组织出政策回复。

顺着这条链路排查，范围就缩小了。订单页面未将上下文传递给客服系统，个人进度查询自然无法启动；上下文传递后，需检查路由是否识别出“查询这笔订单”；路由正确后，再查看退款接口是否被调用及其返回结果。

日志如果没有保留检索结果或接口记录，可以使用授权测试账号和固定订单状态，在测试环境中重放该问题，同时固定知识版本、提示词、模型和配置。重放能说明在当前配置下是否仍会出现相同现象；但线上状态已变化、原配置未存档，它无法证明当时的根本原因。这个分寸需要把握。

他询问的是规则，还是自己的订单

“退款通过后多久到账”是在询问通用规则；“我这笔退款什么时候到”是在查询个人订单。这两句话看似相近，但处理路径可能完全不同。系统若能读取订单页上下文，分类时就必须将上下文纳入考量；用户从公共入口进入，则需先确认订单对象，再决定是否要查询实时状态。

在意图识别方面，不能仅看提问方式，还需查看实际路由结果，并用一组边界相近的问题验证分类：

“退款一般多久到账？”——查询通用规则。

“退款通过后，通常几天能到账？”——查询规则，回答需说明适用条件。

“我这笔退款现在到哪一步？”——查询个人进度，需要订单上下文和业务接口。

“订单号……，这笔退款为什么还没到？”——查询个人进度并解释当前状态；若状态无法解释原因，则转人工核查。

这组问题需要连同入口条件一起测试。仅将提问方式加入样例，并不能说明分类就是根本原因，必须核对当时的上下文、路由输出，以及修改后相邻的规则问题是否仍按原路径处理。

路由正确后，再检查知识检索。需查看检索候选、排序、文档版本，以及最终注入模型的片段。候选中有正确文档但排序靠后，与知识库中根本没有正确内容，是两种不同的情况。检索到新旧两份规则，需先确认哪份有效，再调整版本标记或检索配置。

知识库中存放退款规则、申请条件、办理说明；而某笔订单当前的进度，需要从订单或支付系统查询。两者有时会共同参与回答：先查询订单状态，再引用规则解释该状态。排查时需分清，回答中的事实分别来自何处。

材料无误后，再看模型的表现

当路由、检索候选、输入模型的上下文都符合预期，但回答仍将“审核通过”说成“退款已到账”时，才轮到检查生成环节。

将这一轮输入模型的内容展开来看：用户问了什么，订单状态和更新时间是什么，检索片段是否完整，提示词和模型配置是哪一版，最终回答又多了或少了什么。检索结果正确，并不代表注入的上下文一定完整；片段可能被截断，状态字段也可能在拼接时丢失了含义。

将这些信息放入一条验收样例：

入口与上下文： 已登录用户，从本人订单详情页进入；订单归属校验通过。用户问题： “我的退款什么时候到？”接口返回： 退款已审核通过，退款指令尚未发出；更新时间为10月8日；没有预计到账时间。检索内容： 当前有效退款规则，说明审核通过后的后续处理环节。预期回答要点： 说明审核已通过、退款指令尚未发出；告知更新时间；不补写具体到账日；提供人工核查入口。记录版本： 路由配置、检索配置、提示词、模型版本与接口返回时间。

模型上下文中遗漏了“退款指令尚未发出”，需检查拼接或截断问题；上下文完整但回答仍声称“已到账”，则检查生成指令和模型参数变化；接口字段本身将审核完成和退款完成混为一谈，则需先修改业务字段定义。修改何处，需与证据对应。

修改一处后，回头测试一圈

排查表可以将一次问题留作可复查的记录：

一次修复如果同时修改了知识内容和检索配置，就将这两项作为一组变更记录下来，比较修改前后的候选和回答，并重新运行相关核心样例。提示词、模型或全局配置变更后，也需要运行完整的核心回归集，检查其他意图、状态、人工转接是否有退化。修复后，将样例结果记录下来，下次遇到同类问题就有据可查。

本文来自微信公众号“人人都是产品经理”（ID：woshipm），作者：王蒙，36氪经授权发布。