RAG 项目为什么效果差？7 个最常见原因和排查顺序

RAG 效果差时，很多团队第一反应是换模型。我的建议相反：先不要换模型，先查数据、切分、检索和评测。大多数“回答不准”的问题，不是模型不知道，而是它拿到的上下文就不对、不全、过期或没有来源。

如果你只能做一次排查，按下面顺序来：先看问题集，再看召回内容，最后再看回答生成。不要一开始就调 Prompt。

先用 20 个真实问题做基线

不要用自己临时想的问题测试 RAG。先从搜索记录、客服记录、内部问答、销售问题里选 20 个真实问题，分成三类：

类型示例目标
明确事实某功能如何开启？看能否找到正确文档
条件判断哪种套餐适合团队？看能否引用限制条件
无答案问题是否支持某未发布功能？看系统会不会编造

每个问题都要写预期答案、可接受来源和失败判定。没有评测集，就无法判断改动是否真的变好。

原因 1：文档源本身不适合检索

很多知识库文档是给人看的，不是给检索系统看的。标题模糊、段落太长、多个主题混在一起，都会导致检索出来的片段不稳定。

排查方法：随机打开 10 个被召回片段，问自己三个问题：

  • 片段里是否包含完整答案？
  • 片段是否能独立理解？
  • 片段是否有标题、来源和更新时间？

如果答案是否定的，先整理文档，不要急着调模型。

原因 2：切分策略破坏了上下文

切分太短，答案缺条件；切分太长，检索噪音增加。更好的做法是按结构切：标题、步骤、表格、FAQ、限制条件分别处理。

内容类型推荐切分方式注意点
FAQ一问一答一个 chunk保留问题原文
操作文档一个小节一个 chunk保留步骤顺序
政策/限制条款级切分保留例外条件
表格行或小表格切分保留列名

原因 3：只做向量检索，没有关键词兜底

用户经常输入产品名、错误码、字段名、版本号。这类查询有时关键词检索比语义检索更稳定。纯向量检索可能把“看起来语义相近”的片段排到前面，但错过精确字段。

建议至少保留：关键词召回、向量召回、重排、来源过滤四步。小项目可以先手工记录每次召回的 top 5 片段，观察错误来自哪里。

原因 4：没有来源引用，导致无法审查

没有引用的 RAG 回答很难维护。你不知道答案来自哪段文档，也无法判断是文档错、检索错还是生成错。

最低要求：每个回答附 1-3 个来源，来源包含标题、URL 或文档 ID、更新时间。对外展示可以简化，但后台日志一定要完整。

原因 5：权限和版本没有进入检索条件

内部知识库尤其容易出问题：用户问到 A 团队的资料，却召回 B 团队的文档；旧政策已经废弃，却仍被检索出来。

排查字段：

  • owner：文档负责人。
  • visibility：公开、内部、团队、个人。
  • effective_date：生效时间。
  • deprecated：是否废弃。
  • source_system：来自帮助中心、Notion、GitHub、客服系统等。

如果这些字段缺失，RAG 很难可靠上线。

原因 6：Prompt 让模型“必须回答”

很多 Prompt 会无意中鼓励编造，例如“请基于资料回答用户问题”，但没有说明资料不足时怎么办。应该明确允许拒答。

可用 Prompt：

你是知识库问答助手。只能根据提供的资料回答。
如果资料不足，请回答“当前资料无法确认”，并列出需要补充的文档类型。
回答必须包含：结论、依据来源、仍需确认的信息。
不要根据常识补全价格、政策、权限、功能限制或发布时间。

原因 7：没有更新和回归测试机制

RAG 不是一次性项目。每次新增文档、修改切分、替换模型或改 Prompt，都可能让旧问题变差。至少保留一份回归问题表，每次改动后跑一遍。

排查顺序

  1. 准备 20 个真实问题和预期答案。
  2. 对每个问题保存 top 5 召回片段。
  3. 判断错误来自文档、切分、检索、重排、Prompt 还是权限。
  4. 只改一个变量，再重新测试。
  5. 把失败问题加入长期评测集。

不适合继续投入的情况

如果核心文档没有负责人、来源经常冲突、权限无法区分，先不要上线 RAG。此时更应该先做知识治理：清理旧文档、补 owner、标记更新时间，再考虑检索系统。

内链和模板

建议继续看：

待核验：如果文章中涉及具体向量数据库能力、价格、托管限制或模型上下文长度，上线推广前需要查看官方文档。
顶部