很多团队做 RAG 知识库问答，第一版效果差时会立刻换模型、换向量数据库、换 embedding。其实大多数问题不在模型，而在文档切块、召回策略、上下文拼接和答案校验。模型只是最后一环，前面任何一步做错，最后都会表现成“模型胡说”。

如果你的知识库问答经常答非所问、找不到资料、引用错文档、或者回答看起来很自信但和原文不一致，先不要急着调 prompt。按下面这个流程查。

先确认问题属于哪一类

RAG 失败不是一种问题，而是一串问题。先分类，才能排查。

表现可能原因
答案完全无关召回错文档
答案缺关键细节切块太粗或召回数量不够
答案引用错来源chunk 元数据或引用拼接错
答案编造内容prompt 没限制来源，或上下文不足
答案重复啰嗦召回 chunk 重复，去重不足
答案前后矛盾多版本文档混在一起

不要只看最终回答。RAG 排查必须把中间结果打印出来：用户问题、召回 chunk、分数、来源、拼接后的上下文和最终回答。

文档切块是第一道坑

切块不是把文档按固定长度切开这么简单。切块方式决定模型能不能拿到完整语义。

常见错误有：

  • 按固定字符数硬切，打断标题和段落；
  • chunk 太大，召回后上下文噪声太多；
  • chunk 太小，答案需要的信息被拆散；
  • 没保留标题、章节、路径和更新时间；
  • PDF / Word 转文本后表格结构丢失；
  • FAQ 问题和答案被切到不同 chunk。

比较稳的做法是按文档结构切：标题、段落、列表、表格、FAQ 项。每个 chunk 都带上来源路径、标题层级、更新时间和文档类型。

召回不是越多越好

很多人觉得召回数量越多，模型越不容易漏答案。实际情况是：召回太多会污染上下文，让模型在多个相似片段里摇摆。

排查召回时，至少看三件事：

  1. Top 1 是否命中正确文档；
  2. Top 5 是否包含必要信息；
  3. 是否召回了大量相似但错误的旧文档。

如果 Top 1 经常错，问题在检索；如果 Top 5 有答案但模型没用，问题在重排或 prompt；如果 Top 5 全是旧版本，问题在数据管理。

重排和过滤很关键

向量相似度只能告诉你“语义接近”，不能保证“回答当前问题最合适”。

例如用户问：

这个 API 的免费额度是多少？

向量检索可能召回：

  • API 产品介绍；
  • 价格页；
  • 旧版价格更新；
  • FAQ；
  • 一篇博客教程。

真正有用的可能只有价格页和最新 FAQ。这里就需要重排、时间过滤、文档类型优先级和去重。

简单规则也有用：

  • 价格问题优先官方价格页；
  • 安装问题优先文档；
  • 报错问题优先 issue / FAQ；
  • 概念问题可以用教程和博客；
  • 过期文档不要和新版文档同时进入上下文。

上下文污染会让模型变笨

RAG 最常见的误区是：把所有可能相关的 chunk 都塞给模型。上下文越多不等于答案越好。

上下文污染通常来自：

  • 相同内容重复召回；
  • 不同版本文档混合；
  • 搜索结果摘要和正文同时出现；
  • 无关但关键词相似的 chunk；
  • 长表格被截断后丢失列名；
  • 系统提示、工具输出和用户问题混在一起。

拼接上下文时，应该让模型知道每个片段的来源、时间和可信度。不要只拼一大段无标记文本。

答案必须能回到来源

一个可用的 RAG 系统，不应该只返回答案，还应该能解释答案来自哪里。

最基本的输出应该包括：

  • 使用了哪些文档；
  • 每个关键结论对应哪个 chunk；
  • 哪些问题没有找到可靠来源；
  • 如果来源冲突，选择了哪个版本；
  • 是否需要人工确认。

如果模型回答得很漂亮，但无法指出来源，那不是可靠的知识库问答，而是普通聊天。

一个开发者排查流程

建议你给 RAG 系统加一个 debug 模式，每次查询输出：

query：用户问题
rewritten_query：检索用问题
retrieved_chunks：标题、分数、来源、更新时间
context_tokens：3200
answer：最终回答
citations：引用来源

然后按顺序判断：

  1. 查询改写有没有改变用户意图；
  2. 召回结果有没有正确来源；
  3. chunk 是否完整；
  4. 是否有旧版本或重复文档；
  5. 上下文长度是否过大；
  6. 模型是否只使用了给定来源；
  7. 答案是否能引用回原文。

这比盲目换模型有效得多。

FAQ

RAG 效果差，先换模型有用吗？

不一定。先看召回和上下文。如果正确资料没进上下文，再强的模型也只能猜。

chunk 多大合适？

没有固定答案。技术文档通常按标题和段落切更稳；FAQ 要保证问题和答案在同一个 chunk。

向量数据库是不是越高级越好？

不是。检索策略、元数据、重排和数据治理往往比数据库品牌更重要。

怎么判断 RAG 是否可靠？

看它能不能把关键结论追溯到来源，并在找不到证据时明确说不知道。