综合阿里云开发者社区的 RAG 幻觉分类与多篇实战复盘：先分清是“没找到、找错、融合错、超范围编”哪一类，再对症下药。通用排查顺序：查召回（日志里看实际命中的片段）→ 查分块 → 查提示词 → 最后才怀疑模型。多数团队的顺序反了，一上来就换更贵的模型，钱花了问题还在。
适用场景：知识库已上线但答错率高、用户投诉“胡说八道”时的系统排查
故障排查 幻觉分类 检索日志 踩坑
操作步骤
- 检索幻觉（问 A 找到 B）：看检索日志的命中片段——不相关就先调分块/混合检索/阈值，别怪生成模型
- 融合幻觉（多份文档说法冲突被揉成一个错数）：加版本/日期元数据过滤，提示词里要求冲突时分列（第 12 条第 3 款）
- 过度推断（资料说“可能”、答案说“一定”）：提示词自检条款 + 低温 + 对数字/条件逐字核对
- 记忆幻觉（用模型旧知识覆盖新资料）：提示词明令禁用资料外知识，并把最新资料的生效日期写进元数据与提示
- 资料本身缺失：问题超出知识库范围——正确表现是拒答（第 12 条），要补的是文档，不是参数
- 延迟/成本翻车：候选塞太多（见第 11 条）、历史轮次太长（FastGPT 案例建议记忆 5–6 轮够用，轮次越高每轮 token 越贵）
接入本站 API：排查时善用 LIN 的 Sub2API 后台用量/日志：按 Key 看调用量与模型分布，能区分“是某个应用在狂刷”还是“全站都慢”；换模型 A/B 时给测试应用单发一个 Key，用量与效果单独核算。
注意事项
- ⚠️ 不看检索日志直接调提示词：召回是空的，提示词写出花也变不出答案
- ⚠️ 一次同时改分块、模型、提示词三样：变好了也不知道是哪样起效，下次还踩（阿里云文强调一次只改一个变量做消融）
- ⚠️ 拿三五条手测代替金标集结论（与第 13 条配套使用）