用四层检查定位 RAG 检索质量问题

RAG 答错，问题未必出在生成模型。dev.to 的一篇文章给出了带代码的四层检查方法：从文档与切块开始，依次检查嵌入与索引、黄金问题集检索、最终答案。作者用 MCP 规范搭建示例，展示了一个容易误判的情况：检索命中了正确页面，却没把回答所需的那句话交给模型。

目前能确认什么

示例将 31 页 MCP 规范拆成 536 个切块，使用 text-embedding-3-small 生成嵌入，存入 Chroma。作者编写了 55 道问题，按页面标注答案来源，降低更换切块策略后重新标注的成本。

但页面标签有盲区。50 道可回答问题中，49 道在前 5 个结果里命中了正确页面。其中一道关于能否通过弹窗索要密码的问题，相关页面排在第 2，真正包含答案的切块却排在第 6。生成模型只拿到前 5 个切块，回答了「不知道」。

命中正确页面，不等于检索到了足够的回答证据。

另一项检查是对比近似检索与精确检索：在同一批向量上，用暴力搜索得到精确的前 k 个结果，再计算近似索引返回结果与它的重合比例。这检查的是索引有没有漏掉近邻，与内容能否回答问题是两回事。

我的判断

这套方法最有用的是排查顺序。先确认文档和切块，再检查向量与索引，随后验证检索证据，最后评审答案，能帮助程序员缩小故障范围，避免一遇到错答就调整提示词。

页面级标签适合保留评测集，但还需要检查传入提示词的切块是否包含答案。只看页面命中率，可能把证据缺失误判成生成失败。

作者也明确限定了实验范围：只有一种嵌入模型，未测试托管存储、量化和过滤检索，评审模型只看了六个答案。536 个向量上的近似检索结果，不能证明大规模索引同样可靠。各层完整检查项、答案评审结果及工具比较，当前节选尚未展开，不能据此判断哪种方案更好。