RAG 系统回答不准，很多人的反应是换模型、改提示词、增加 Top-K。但实际问题往往不是模型不会回答，而是正确资料根本没有进入上下文。

文档解析丢字、切块破坏语义、Embedding 版本不一致、过滤条件过严、索引没有更新，都会让一个正常模型“看起来不聪明”。与其反复调参，不如沿着检索链路逐层检查。

一、先区分检索故障和生成故障

拿到错误答案后，先确认三个问题：

1. 知识库中是否存在正确答案？
2. 正确内容是否进入召回结果？
3. 正确内容进入上下文后，模型是否仍然答错？

如果正确内容没有进入上下文，重点检查解析、切分、索引、向量、过滤和排序；如果上下文已经包含明确证据，再检查提示词、上下文顺序和生成策略。

检索不到资料时，继续优化提示词通常没有意义。

二、检查文档解析和切分

RAG 实际检索的不是原始 PDF、网页或数据库，而是解析后的文本块。

双栏 PDF 可能左右错序，扫描件可能 OCR 失败，表格可能丢失表头，代码块也可能被拆散。源文件肉眼正常，不代表进入知识库的内容正常。

抽样检查时重点看：

• 标题是否与正文保存在一起；
• 表格是否保留表头、单位和适用条件；
• 代码是否保留完整函数和错误信息；
• 每个文本块脱离全文后，是否仍能独立表达含义。

切块不是越大越好。块太小会丢失上下文，块太大又会混入多个主题。固定长度、按标题切分和语义切分没有统一答案，应使用真实问题进行比较。

三、确认查询和文档使用同一套 Embedding

Embedding 维度一致，只能证明数组长度相同，不能证明向量可以混用。

查询和文档必须使用相同的模型、维度、预处理规则和版本。两个模型即使输出相同维度，坐标含义也可能不同。文档使用旧模型、查询使用新模型时，数据库未必报错，但召回质量会下降。

升级 Embedding 时，不要直接覆盖旧索引。更稳妥的流程是：创建新索引、用新模型重新向量化原文、运行固定评测、小范围切换查询，验证通过后再正式迁移，并保留回滚能力。

不要通过补零、截断或缩放把旧向量“改造”成新向量。向量不是可以随意转换的普通数组。

四、逐项排查过滤条件

向量检索通常还会叠加租户、权限、语言、状态和时间范围等条件。条件缺失可能造成越权，条件过严又会把正确资料提前排除。

排查时记录每个条件加入前后的候选数量。如果加入某个条件后结果突然归零，就能快速定位问题。重点检查大小写、时区、空值、枚举值、发布时间和权限继承。

权限条件不能为了提高召回而直接关闭。正确做法是在隔离环境中使用有权限的样本逐项对照。

五、关键词检索和向量检索要互相补充

向量检索擅长理解相近语义，关键词检索更适合错误码、接口路径、版本号、类名和缩写。

技术知识库只使用向量检索，容易漏掉精确标识；只使用关键词检索，又可能无法理解口语表达。更实用的方式是分别获取关键词结果和向量结果，再通过排名融合形成候选列表。

Top-K 也应分阶段设置：初始召回负责扩大覆盖，重排负责调整顺序，最终上下文负责控制长度和重复内容。重排只能优化已经召回的候选，无法找回从未进入候选集的资料。

六、生成接口和检索能力必须分别核验

很多项目会使用 OpenAI 兼容接口完成生成，但“兼容 Chat Completions”不代表同时提供 Embedding、向量数据库或重排能力。

相关接口配置入口：https://178.nz/can 。接入时仍应分别确认生成接口、Embedding 服务和向量检索组件的实际能力，不要因为聊天接口可以调用，就默认整套 RAG 链路都已兼容。

建议在配置中明确记录接口地址、模型、向量维度、预处理版本和索引版本。更换任意一项后，都应重新运行检索评测。

七、用固定评测集代替“感觉变好了”

准备一组真实问题，并为每个问题标注正确文档或文本块。每次调整切分、Embedding、过滤、Top-K 或重排后，都使用同一组问题重新测试。

重点关注：正确资料是否进入前 K 个结果、首个正确结果排在第几位、无结果比例、重复块比例，以及最终答案是否引用真实证据。

最终答案偶尔正确，不代表检索系统健康。模型可能依靠自身知识猜对，也可能在错误上下文中碰巧得到正确结论。只有保留原始查询、召回结果、重排结果和最终上下文，才能判断改动究竟优化了哪一层。

结语

RAG 排错的核心不是寻找一个“万能参数”，而是建立完整证据链：原文是否存在，解析是否正确，切块是否完整，向量是否一致，过滤是否误伤，正确资料是否进入候选，最终上下文是否真正发送给模型。

只要能回答“正确证据在哪一步消失”，RAG 问题就会从模糊的“模型不聪明”，变成一个可以复现、定位和修复的工程问题。!