知识库问答答错了，很多人的第一反应是换一个更强的大模型。但错误的原因经常不在生成端，而在检索端：正确的资料压根没被搜出来，模型只能靠猜。RAG 评估要做的，就是把「先检索、再生成」这条链条拆成两段，逐段检查——先确认资料找没找到，再判断答案写得对不对。分不开这两段，调优就只能在黑暗里试错。
为什么先查检索，再查生成
RAG 系统分两步工作：先从知识库里检索相关资料，再把资料交给模型组织成回答。最终答案错了，可能落在两处：一是检索没找到，正确资料不在结果里；二是检索找到了，模型却没把资料用对。这两种情况的解法完全不同——前者要改分块方式、检索策略或查询改写，后者要改提示词甚至换模型。如果只是笼统地觉得「效果不好」，很可能在检索有问题的情况下反复换模型，钱花了，命中率还是原地踏步。
评估检索：命中率与排序
评估检索要先准备一个小测试集：收集一批真实问题，人工标注每个问题的答案在哪份资料里。有了标注，才能看两个指标。一是命中率：检索结果里有没有包含那份正确资料。二是排序：正确资料排在第几位。排序经常被忽略，但它很关键——排在十名开外的资料，对后续生成的作用和没找到差别不大，因为模型对靠后内容的注意力会明显下降。
如果命中率低，问题就锁定在检索环节，排查方向有三个：分块是不是把一段完整的话切碎了；检索方式（关键词还是向量）跟问题形态匹不匹配；用户的原始问题有没有改写的空间——口语化的长问题经常需要先改写成检索友好的短查询。
评估生成：依据、编造与答点
检索确认没问题之后，再看生成质量，同样看三处。有没有依据：回答的内容是否来自检索到的资料，还是模型自己补的。有没有编造：资料里明明没有的数字、条款、结论，它有没有顺势写出来。有没有答到点上：用户问的是付款节点，它回答的是付款方式的背景介绍，资料再对也没用。
一条能直接照做的排查顺序
实际排查按固定顺序走。第一步，把检索结果打印出来，人眼过一遍——这一步最原始，也最能定位问题，很多「模型不行」的案例在这一步就现出原形：正确资料根本不在结果里。第二步，对照检索结果看回答用了什么，确认模型有没有用对找到的资料。第三步，前两步都干净，才轮到考虑换模型。顺序反了，成本会翻好几倍。
场景对照：问题出在哪一段
| 问题表现 | 先查什么 | 判断标准 |
|---|---|---|
| 回答完全答非所问 | 检索命中情况 | 正确资料没进结果前列，先改检索再谈其他 |
| 回答内容与资料对不上 | 生成是否引用资料 | 资料里有答案但它没用，改提示词要求只依据资料作答 |
| 资料里确实没有答案 | 知识库覆盖范围 | 该补资料，不是模型的问题 |
| 长文档问答经常断章取义 | 分块大小与边界 | 一段话被切碎，按章节或条款重新分块 |
这张表的用法是先对号入座：拿一个真实答错的案例，按「问题表现」找到对应行，照「先查什么」执行，用「判断标准」确认方向对不对。
它做不到的部分
RAG 评估量得出「资料找没找到」，量不出「资料本身对不对」。知识库源头内容过期、写错、互相矛盾，评估指标全绿，回答照样是错的。测试集的质量也决定评估的可信度——标注本身有偏差，或者测试集问题跟真实用户问题的分布不一致，测出来的结论就会失真。另外，命中率达标不等于万事大吉，真实用户的问法千奇百怪，测试集覆盖不了的问法，评估同样覆盖不了。
RAG 评估速查
- 先把检索和生成拆开，别笼统说效果不好
- 测试集用真实问题，人工标注答案出处
- 命中率看有没有找到，排序看排第几
- 排查顺序：查检索结果、查回答引用，最后才换模型
- 排在结果后面的资料，约等于没找到
三个常被问到的问题
- 测试集要准备多少条才够用？：几十条起步就够，关键是真实和高频。从客服记录、历史提问里挑出现次数多的问题，比凑数量重要得多。跑顺之后再逐步补充边角场景。
- 检索命中了，答案还是错，说明什么？：说明问题在生成端或者资料本身。先看资料原文写得清不清楚，语义混乱的资料换什么模型都读不顺；资料没问题时，再改提示词，要求只依据资料作答。
- 没有人力做标注怎么办？：先用自己日常真实问过的问题充当测试集，答案出处你自己知道，标注成本接近零。判断标准也简单：你已知答案的问题，它答对了多少。
检索环节的调优往往牵动整个系统设计。知识该进模型还是进知识库，微调和 RAG 的选择里有明确的分界；当 RAG 只是智能体流程中的一环时，检索结果怎么交接给下游，可以参考Agent 间通信的交接方式；整套系统跑起来之后，Agent 可观测性提供的是持续盯住执行过程的手段；给检索质量定一条及格线，思路接近服务等级承诺里的约定方式——先定标准，再看实测。
