小红书上有篇四千多赞的求助帖，看得人头皮发麻：老板让楼主优化 RAG 效果，Milvus 里躺着 30 万+ 分块，按标题层级切的块。一周时间，他把网上的优化思路试了个遍——内容稠密向量、BM25、摘要向量、HyDE 假设文档匹配、查询改写、多查询，连 bge-reranker 和 Qwen-rerank-8b 两个重排模型都安排上了，结果每一路召回都混进大量不相关内容，重排还经常把最相关的往后排。小红书帖子最后一句是：“rag 这个技术压根落不了底吧。”
评论区一堆人共鸣。但我把最近一个月知乎上几篇带完整实测数据的评测实战文翻完、交叉比对之后，结论正好相反：大多数人 RAG 优化没效果，不是招数试得不够多，而是试的顺序从一开始就错了。
先把丑话说在前面：这篇不科普 RAG 是什么，也不讨论"RAG 死没死"。它服务的是已经把知识库问答搭起来、demo 能跑、但效果卡住的你。
一、你的"测试"可能根本不叫测试
先对号入座一下，你的评测方式是不是这样：上线前随手问十几个问题，答案看起来不错，发布；过两天调了 chunk 参数，再凭感觉问一遍。做离线评测体系的作者把这种方式的偏差拆得很透：提问者自己知道文档内容，提问时会不自觉用原文的关键词；看到接近预期的表述，就忽略了引用其实撑不住结论；失败的问题没被存下来，下个版本无法重放。知乎更麻烦的是，同一个"答错了"，根因可能完全不同——源文档没解析到、相关内容被切断、检索没召回、相关块排在窗口之外、生成器无视证据、证据本身过期。只看最终答案，等于把六种不同的病压成一句"效果不好"，然后随便抓一副药。
知乎上还有个更扎心的案例：一个电商团队花一个多月做完 RAG，指标全绿，老板满意上线。然后用户开始骂——问"怎么退货"，系统答换货流程；问"优惠券为啥用不了"，系统说券已过期，其实用户刚领的，项目直接被叫停。知乎原因一句话：测试集全是"标准问法"，真实用户根本不那么说话。
所以第一步不是调任何参数，而是承认一件事：凭感觉问问题，测不出问题。
二、最小评测闭环：四个指标，各管一段
RAG 是一条串联流水线，评测也得拆开测。我交叉比对了多篇实战文，最小可用的组合是四个指标，检索、生成各两个：
Recall@K（召回率）：该找回来的证据，有几成进了 Top K。衡量"漏没漏"。
Precision@K（精确率）：Top K 里真正相关的占几成。衡量"纯不纯"。
Faithfulness（忠实度）：答案里的每句主张，能不能被检索到的上下文支撑。衡量"编没编"。
Answer Relevancy（答案相关性）：回答的是不是用户问的事。衡量"跑没跑题"。
举个实操算法：某问题有 2 个相关 chunk，检索 Top 3 返回 [相关A, 无关X, 相关B]，那么 Recall@3 = 2/2，Precision@3 = 2/3，Hit Rate@3 = 1，第一个相关结果就排在第一位。知乎覆盖和纯净度是两个独立的问题，不能互相替代。
关键是，这四个指标各有各的盲区，单看哪个都会被骗：召回率 100%，但返回的 5 条里 3 条是废话，模型照样被噪声带偏，这是缺精确率；忠实度 100%，模型一字没编，但答非所问——你问"DDS 是什么"，它答"DDS 是一种很厉害的协议，在很多领域用了很多年"，没错，但不切题。知乎
还有人做过一个反直觉实验：把知识库文档清洗了一遍，预期 RAGAS 分数大涨，结果两版几乎没差异。不是清洗没用——是测试集太"软"了：5 份文档取 Top 3，包含答案的 chunk 几乎必中；8 个问题全是单跳直问，多跳问题一个没有。满分只说明检索质量高于测试集的辨别能力，换一个更难的测试集，分数可能立刻现形。因为 RAGAS 的 Context Precision 本身是 LLM 判出来的，而 LLM 倾向于找任何借口认为一个 chunk"有用"。知乎
三、定位决策树：答案错了，先别碰 Prompt
有了指标只是知道"好不好"，真正值钱的是"哪里不好"。这里给一张我综合了几篇实战文整理的定位顺序，从上往下走：
第一步：相关 chunk 进 Top K 了吗？ 没有的话，问题在检索链路之前，按顺序排查：源文档解析有没有丢内容、chunk 切分是否把关键段落拦腰切断、查询改写是否丢掉了用户原意、embedding 模型是否匹配你的语言场景——有个经典坑：用户说"退钱"，检索捞不到"退货退款"的文档，因为两个词在向量空间里离得远，加一层同义词映射三天解决。知乎注意，这一步的解药全在检索侧，别去动生成提示词，那是治错了病。
第二步：chunk 进了 Top K，但没进最终上下文？ 查去重逻辑、上下文压缩、token 截断和排序——相关证据被挤出了窗口，跟没检索到是一个效果。
第三步：证据完整进了上下文，答案里还是出现无依据内容？ 这才轮到生成层：缩小无关上下文、强化引用和拒答指令、对比不同基座模型。
第四步：每句话都有依据，但答案违反当前业务规则？ 那不是幻觉，是知识库版本过期了，或者业务规则本身没进库。
给一个真实案例感受一下这套流程的价值：有位作者测出 recall 只有 0.334，第一反应是"知识库文档太少，得补文档"，差点就动手了。他忍住了，挑了 3 个高 recall 和 3 个低 recall 的问题，把检索返回内容和期望答案摆在一起对比，发现检索永远只返回文档开头的标题加概述，正文里的关键对比段落一次都没被捞回来——根因不是知识库不全，是切片太大。把文档按章节拆小重新上传后，recall 直接翻倍。知乎
如果他没做定位、直接去补文档，这个坑可能永远填不上。
四、比指标更容易翻车的三件事
1. 测试集必须来自真实日志，不能自己编。 从客服记录、搜索日志里脱敏抽取，再人工标注相关 chunk 和参考答案。模型辅助生成的问题可以补充覆盖面，但它们天然沿用原文词汇，会让检索任务变得过于简单，不能单独当评测集。知乎
2. 一定要放"无答案问题"。 知识库之外的问题，系统应该明确拒答，而不是从相似片段里拼出一个流畅的结论。会编造的 RAG 比答得慢的 RAG 危险得多。
3. 把开发集、冻结测试集、挑战集分开。 如果团队天天盯着同一批问题调参数，这批问题很快就会从"测试题"变成"训练题"——指标一路涨，换个问法全露馅。知乎冻结集只在候选版本准备发布时跑，挑战集专门收多跳推理、表格计算、否定条件、版本冲突这类硬骨头。另外按文档类型、查询类别、风险等级做切片统计：整体准确率 90%，"退货退款"这类高频意图可能只有 60%，而用户只关心他问的那一个。
知乎上有条回答把这个逻辑说到极致：一个 2 通道 RAG 加 100 个高质量评测集，比 5 通道 RAG 加 10 个随便写的测试问题强 100 倍。知乎架构可以朴素，标尺不能没有。
五、行动清单：从 30 个问题开始
如果你现在一头乱麻，建议按这个最小路径起步：
从真实用户问题里挑 30 条，人工标注每条的相关 chunk 和参考答案，再塞进 5-10 条知识库里根本没有的问题；
先跑检索侧两个指标（Recall@K、Precision@K），纯脚本就能算，不花一分钱；
分数异常时按上面的决策树逐层走，一次只动一个旋钮；
改完用同一评测集回归，逐题对比"修好了哪些、新增了哪些失败"，而不是只看均值——平均 recall 提升，可能恰好掩盖了某类表格问题全部退化；
每周自动跑一遍，badcase 持续回流进评测集。
最后说句题外话。这两天知乎上"传统 RAG vs Agent RAG"的对比文一篇接一篇，Agentic RAG 确实是肉眼可见的趋势。但升级架构之前，不妨先用这把标尺量一下现在的系统：如果卡在检索层，换成 Agent 也只是让一个更贵的系统继续检索不到；如果卡在生成层，那值得先算算 Agent 化的代价——有团队把单 Agent 升级成多 Agent 调度后，多跳对比查询的端到端延迟在 20 秒量级，token 消耗更是翻着倍涨。知乎
RAG 优化不是玄学，是排除法。分数低了不可怕，可怕的是不知道为什么低。
