一次回答错了，怎么定位错在数据、检索、工具还是模型？
本文目录
30秒版回答
我会顺着链路从上游往下游排查，和排查数据链路一样：
第一步，看源数据：标准答案所依赖的数据或文档本身对不对、是不是最新的。第二步，看检索/工具输入：Agent 有没有查对地方——问题理解对不对、生成的查询或检索词对不对、权限过滤有没有误伤。第三步，看检索/工具输出：正确的证据有没有被召回、工具返回的结果对不对。第四步，看生成：证据是对的，模型有没有忠实使用，是不是自己编了内容。
前提是每次请求都有完整 Trace。定位之后要分类统计，比如一段时间内多数问题出在检索，那优化重点就是检索而不是换模型。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官：「业务反馈说 Agent 刚才给了一个错误答案。你拿到这个反馈之后，具体怎么排查？怎么判断是数据的问题、检索的问题、工具的问题，还是模型本身的问题？」
这道题是第 11 题的延伸，考的是排障能力。它和“Spark 任务慢了你怎么排查”“Flink 反压你怎么排查”是同一类题，只是对象换成了 Agent。
很多人拿到坏回答的第一反应是“模型幻觉了”，然后去改提示词。实际上，一个错误答案的根因可能在链路上任何一个环节。没有可追溯的 Trace，就只能靠猜；有了 Trace，就可以像排查数据链路一样逐层定位。
面试官在考什么
• 是否有系统化的排查顺序，而不是直接归咎于模型幻觉。
• 是否知道排查依赖什么数据：完整的 Trace、检索结果、工具输入输出、模型版本。
• 能否把错误分类并对应到改进动作。
• 是否会把单个案例的排查沉淀为系统改进。
展开一：排查决策树
拿到坏回答 → 根据 Trace ID 拉取完整调用链
│
├─ Q1: 源数据/文档本身是否正确、最新？
│ └─ 否 → 【数据问题】源数据错误、文档过期、索引未同步
│
├─ Q2: 问题理解是否正确？(意图、时间、实体、改写后的查询)
│ └─ 否 → 【理解问题】时间解析错、实体没匹配、改写偏题
│
├─ Q3: 正确证据是否被召回 / 工具返回是否正确？
│ ├─ 没召回 → 【检索问题】切分、Embedding、过滤条件、TopK
│ └─ 工具报错/返回错 → 【工具问题】工具 Bug、参数错、超时被截断
│
└─ Q4: 证据正确且在上下文中，答案仍错？
└─ 是 → 【生成问题】没用证据、编造、上下文冲突、被截断这个顺序很重要。先排除上游，再怀疑下游。如果源文档本身就是错的，你改提示词改到天荒地老也没用。
展开二：排查依赖的数据——Trace 里要有什么
排查的前提是每次请求都留下足够的证据。我会要求 Trace 至少记录以下内容：
| 阶段 | 必须记录 | 用于判断 |
|---|---|---|
| 请求 | 用户、角色、原始问题、会话上下文、时间 | 复现请求 |
| 理解 | 意图分类、改写后的查询、解析出的时间和实体 | Q2 理解是否正确 |
| 检索 | 检索词、过滤条件、候选列表及分数、重排后结果、文档版本 | Q3 证据是否召回 |
| 工具 | 工具名、输入参数、输出（或摘要）、耗时、错误信息 | Q3 工具是否正确 |
| 生成 | 模型名和版本、完整提示（或其哈希）、上下文 Token 数、输出、结束原因 | Q4 生成是否忠实 |
| 版本 | 提示词版本、索引版本、Agent 版本 | 定位是哪次变更引入的 |
注意最后一行“版本”。很多问题是“上周还好好的，这周突然不对了”，有了版本信息，就能快速关联到某次提示词修改或索引重建。这和数仓排查“数据突然异常”时先看最近的代码发布和上游变更是一个道理。
展开三：常见错误类型和改进动作
| 错误类型 | 典型现象 | 根因示例 | 改进动作 |
|---|---|---|---|
| 数据问题 | 答案和最新事实不符 | 文档过期、索引同步延迟、源数据错误 | 修复数据，监控同步延迟 |
| 理解问题 | 答非所问 | “上周”解析错，“华东”没映射到编码 | 确定性规则、补充同义词 |
| 检索问题 | 说“没找到”或用了不相关材料 | 切分把关键信息切断、过滤条件过严 | 调整切分、混合检索、补元数据 |
| 工具问题 | 数字明显不对 | SQL 少了过滤条件、结果被截断 | 工具校验、结果完整性提示 |
| 生成问题 | 证据对但答案错 | 多份证据冲突时选错、编造细节 | 提示约束、引用校验、换模型 |
展开四：一个典型排查过程
举个智能问数场景的例子：业务反馈“Agent 说上周华东区 GMV 是 1200 万，但看板上是 1350 万”。
1. 拉 Trace：问题理解 → time_range = 2026-09-28~10-04, region = 华东 ✔
2. 看生成的查询：metric = gmv, filters = [region='华东'] ✔
3. 看编译后的 SQL：
SELECT SUM(pay_amount) FROM dws_trade_order_d
WHERE dt BETWEEN '2026-09-28' AND '2026-10-04' AND region = '华东'
4. 对比看板 SQL：看板用的是 region_group = '华东'（包含华东一区、二区）
而 region = '华东' 只匹配到了旧编码的一部分数据
5. 结论：【理解/语义层问题】维度值映射不完整，不是模型幻觉
6. 改进：语义层中"华东"映射到 region_group 维度；该样本加入评测集这个例子的价值在于：如果直接把它当成“模型幻觉”去改提示词，永远也改不好。大量看起来像“模型算错”的问题，根因都在数据和语义层。
展开五：从单案例到系统改进
排查完一个案例只是开始。我会把每个坏案例的排查结论落表，定期做归因分析：
-- 坏案例归因统计：决定下一步优化投入在哪里
SELECT root_cause_type, -- 数据/理解/检索/工具/生成
root_cause_detail, -- 如：维度值映射缺失
COUNT(*) AS case_cnt,
COUNT(*) * 1.0 / SUM(COUNT(*)) OVER () AS ratio
FROM agent_bad_case
WHERE review_date >= DATE_SUB(CURRENT_DATE, 30)
AND reviewed = 1
GROUP BY root_cause_type, root_cause_detail
ORDER BY case_cnt DESC;如果统计结果显示大部分问题集中在“维度值映射”和“切分”，那团队下个月的重点就应该是补语义层和优化切分，而不是去评估要不要换一个更贵的模型。用数据驱动优化方向，这是数据人最自然的思维方式。
追问链
追问一：没有 Trace，只有用户截图，怎么排查？
这种情况只能尝试复现：用同样的问题、同样的用户身份重新请求，看能否得到同样的错误。但因为模型有随机性、数据可能已经更新，复现不一定成功。所以这道追问的正确回答是：这正说明 Trace 是必需的基础设施。我会推动先把 Trace 补上，至少记录问题、检索结果、工具调用和模型输出，否则排查效率会非常低。
追问二：怎么判断模型是不是“没用证据、自己编的”？
可以做自动化的忠实性检查：把答案拆成一条条事实陈述，逐条检查能否在上下文证据中找到依据，找不到的就是可能的编造。这一步可以用程序加 LLM 评委完成。另外要求模型在回答中标注引用，再校验引用的片段是否真的支持该陈述，这样编造会更容易暴露。
追问三：证据之间互相矛盾怎么办？
这通常是数据问题，比如新旧两个版本的文档同时被召回。根本解决是在索引层保证只有有效版本可被检索（第 10 题的版本原子切换）。在生成层可以做兜底：上下文里带上文档的更新时间和版本，提示模型优先采用最新、最权威来源的信息，并在存在冲突时明确告诉用户。
加分说法 vs 减分说法
| ✔ 加分说法 | ✘ 减分说法 |
|---|---|
| 顺着链路从上游往下游排查 | 模型幻觉了，改改提示词 |
| 先排除数据和理解问题，再怀疑模型 | 直接换一个更强的模型 |
| Trace 要记录检索、工具、生成和版本 | 没有 Trace，靠复现碰运气 |
| 坏案例落表做归因统计，驱动优化方向 | 只修单个案例，不做归因统计 |
| 把“模型算错”还原成语义层或数据问题 | 排查完不沉淀到评测集 |
怎么挂到你的项目上
话术模板：“我排查 Agent 坏回答的方法和排查数据链路一样：拿 Trace 顺着链路从上游往下游看——源数据对不对、问题理解对不对、证据有没有召回、模型有没有忠实使用。每个坏案例的根因都会落表，按月做归因统计，用数据决定优化重点。我们发现很多看起来像模型算错的问题，根因其实是维度映射或口径问题。”
总结
排查 Agent 坏回答的核心方法是顺着链路、从上游到下游、逐层排除，前提是有完整的 Trace。把“模型幻觉”还原成具体的数据、理解、检索、工具或生成问题，再用归因统计驱动优化，这是数据开发最擅长、也最能打动面试官的思路。
下一篇聊 Trace 数据本身：Agent 的 Trace 和对话日志进数仓，模型应该怎么建？
你遇到过的 AI 错误答案，最后查出来根因是什么？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长