前言
很多团队做 RAG（检索增强生成）时，第一反应是：
- 回答不准 -> 换更强模型
- 幻觉多 -> 再加一层提示词
结果常见现象是：成本上去了，效果只提升一点点，甚至回退。
如果你线上已经有 RAG 服务，这篇想回答一个更实际的问题：
为什么 RAG 的准确率问题，80% 不在模型本身，而在检索链路和评测链路？
下面我用“现象 -> 原因 -> 修复动作”的方式，给你一份可以直接落地的排查清单。
一、先定一个判断标准：你说的“不准”到底是哪种不准？
线上争论最容易卡在这里：
产品说“不准”，算法说“模型没问题”，后端说“日志里没报错”。
先把“不准”拆成三类，你的改造才有方向：
- 没召回到：知识库里明明有答案，但检索结果里没有。
- 召回到了但选错了：TopK 里有正确片段，但排序让错误片段排前面。
- 检索对了但生成歪了：上下文给对了，模型仍然总结错、编造或漏关键信息。
对应指标建议：
- 召回层：Recall@K、MRR、命中率
- 排序层：NDCG、Top1 准确率
- 生成层：Faithfulness（忠实度）、Answer Correctness（答案正确率）
结论先行：没有分层指标，就别谈优化优先级。
二、RAG 最常见的 7 个工程坑
1) 切片策略错位：段太大看不见重点，段太小丢上下文
现象
- 问“退款规则第3条是什么”，模型答得像“总结全文”
- 明明命中相关文档，但答案缺关键信息（时间、版本、条件）
根因
- 固定长度切片，不看文档结构（标题、表格、代码块、条款号）
- overlap 过小导致语义断裂，过大导致噪声重复
修复动作
- 先做结构化切片：按标题层级、段落、列表、代码块分段
- 再做长度约束：例如中文 300-600 字一段，overlap 50-120 字
- 对 FAQ、制度类文档保留“条款编号”字段，便于可追溯引用
2) 向量模型与语料不匹配：你用的是“通用语义”，业务要的是“术语精确”
现象
- 查询“核销”召回到“抵扣”
- 查询“工单升级SLA”召回到“服务介绍”
根因
- embedding 模型对业务术语区分度不足
- 没做同义词、别名、缩写标准化
修复动作
- 给查询前加轻量归一化（术语映射、英文缩写扩展）
- 不同业务域分索引（客服、法务、运维不要混一个库）
- 每次换 embedding 模型，必须跑离线评测集，不要只看几条主观样例
3) 只做向量检索，不做混合检索：关键词问题天然吃亏
现象
- 用户问“报错码 E403 的处理步骤”，却召回不到包含“E403”字样的文档
根因
- 纯向量对精确字符串、编号、时间戳类问题先天弱
修复动作
- 上Hybrid Search（BM25 + Vector）
- 对编号类问题加“精确匹配通道”
- 排序阶段引入规则特征：是否包含关键实体、版本号、错误码
4) TopK 固定写死：复杂问题和简单问题用同一把尺
现象
- 简单问答上下文太长，模型被噪声干扰
- 复杂问答上下文太短，证据不够
根因
- 所有问题统一 TopK=3 或 TopK=5，没有动态策略
修复动作
- 按查询类型动态 K（事实问答、流程问答、多跳问答分开）
- 先粗召回再重排，重排后再截取 token 预算
- 给生成端加“证据引用数量阈值”，避免只靠一段文本硬答
5) 上下文拼接无规则：把检索命中变成了“噪声拼盘”
现象
- 模型输出看起来流畅，但答非所问
- 同一个问题多次问，答案飘忽
根因
- 检索结果直接 concat，不做去重、时间过滤、来源权重
- 旧版本文档和新版本并存，模型随机引用
修复动作
- 上下文组装前做三件事：去重、按时间过滤、按来源打权重
- 强制“新版本优先”，并在 prompt 里声明“冲突时按最新版本”
- 输出要求引用来源（文档ID/标题/版本号）
6) 没有拒答策略：不知道就硬答，幻觉被当成“智能”
现象
- 问库里没有的问题，模型仍给出完整步骤
根因
- 没有“检索置信度阈值 + 拒答模板”
修复动作
- 设最小证据门槛（如命中分低于阈值触发拒答）
- 给出可执行替代动作：让用户补充信息、转人工、列出可查询范围
- 统计拒答率与用户满意度，避免“为了不犯错而全部拒答”
7) 只看在线反馈，不建离线评测集：优化永远靠感觉
现象
- 每次改完“好像更好”，但下周又回退
- 团队无法回答“哪个版本真的提升了”
根因
- 缺少稳定评测集和版本对照机制
修复动作
- 先建一套 50-200 条高价值评测集（按业务场景分层）
- 每次改动必须跑基线对比：召回、排序、生成三层都记录
- 指标之外保留“失败样例池”，定期做错误归因复盘
三、一个可直接复用的 RAG 排查流程（最小版本）
你可以按下面顺序排查，避免来回返工：
- 抽取最近一周差评问题 30 条
- 标注失败类型（没召回/选错/生成歪）
- 跑离线回放，记录三层指标
- 先改召回与重排，再改生成提示词
- A/B 比较新旧版本，至少观察 3-7 天
简化原则：
先修“检索是否拿到对的证据”，再修“模型如何表达证据”。
四、短期动作与长期动作
短期（1-2 周可做）
- 上混合检索（BM25 + Vector）
- 重构切片策略（结构化 + overlap）
- 增加拒答阈值与来源引用
- 建立最小离线评测集（先从 50 条开始）
长期（1-2 个月）
- 建领域术语词典与查询改写服务
- 做多路召回 + 学习排序
- 把线上反馈自动回灌评测集，形成持续评估闭环
结语
RAG 的核心不是“让模型背更多资料”，而是“让系统在正确证据上说话”。
当你把召回、重排、生成、评测拆开看，很多“玄学问题”会立刻变成工程问题。
欢迎大家关注我，一起学习进步~~~
