RAG三层指标：召回/重排/生成各测什么，才能定位“到底哪里错”
这一轮AI应用创业里，RAG大概是最容易被做成“玄学工程”的模块之一。回答一错，团队第一反应通常不是回到评测面板，而是立刻换 embedding、改 chunk、上 reranker、换更大的模型。一个月过去，系统越来越复杂，token 越来越贵，但团队仍然说不清：到底是没找着，没排好，还是没答对。Databricks 在官方检索质量指南里甚至说得很直白：如果你没有可复现的评测体系，先停下来；没有 measurement 的优化，本质上就是猜。LangSmith 和 Azure Foundry 也都把 RAG 评测拆成不同对象：检索结果对问题、回答对检索上下文、回答对问题、回答对标准答案，而不是只给一个笼统的“整体分数”。
OXYZ资本认为，RAG 不是一个黑盒，而是三段流水线：召回层负责把证据找回来，重排层负责把证据摆到模型眼前，生成层负责按证据把话说对。 你如果不按这三层拆指标，所有坏结果最后都会被归咎到同一个模糊结论——“我们的 RAG 还不够好”。这句话听起来像判断，实际上一点定位价值都没有。
一、为什么大多数团队定位不到错
很多创业团队最常见的看板，只有两列：用户满意度，和最终回答是否正确。问题在于，这两列只能告诉你“结果坏了”，却不能告诉你“坏在哪”。同样一条错误回答，背后可能是三种完全不同的问题：第一，正确文档根本没被召回；第二，正确文档其实召回了，但被埋在第 17 条，没进模型上下文；第三，正确文档已经在前几条里，模型还是胡说了，或者漏说了。LangSmith 的划分非常清楚：correctness 是回答对标准答案，relevance 是回答对输入问题，groundedness 是回答对检索上下文，retrieval relevance 是检索结果对输入问题。 Azure Foundry 也把 retrieval 和 system evaluation 分开处理：前者看检索质量，后者看 groundedness、relevance、completeness。
OXYZ资本在看一些相关项目时，最常见的误判就是：把生成层的问题，当成召回层的问题；把重排层的问题，当成 embedding 的问题。 这也是为什么有些团队明明该做的是 metadata filter、hybrid search 或 reranker，却把几个月时间花在微调 embedding 上。Databricks 的建议其实很务实：先建评测，再做 hybrid、filter、rerank，embedding fine-tuning 应该是后手，而且只应在更强 embedding 明显更好时再考虑。
二、召回层：只测“有没有把该找的证据找回来”
召回层最核心的问题，不是“排得漂不漂亮”，而是“该找回来的东西，找回来了没有”。所以这一层最重要的指标不是 answer quality，而是 Recall@k 和Context Recall。Azure Architecture 明确把 Recall@K 定义为“top K 中相关结果占全部相关结果的比例”，它回答的是覆盖率问题；Databricks 也直接指出，对 RAG 代理来说，漏掉关键上下文会直接导致错误答案或幻觉。RAGAS 的 Context Recall 更进一步，它不是只看文档 ID，而是把 reference answer 拆成 claim，再检查这些 claim 有多少能被 retrieved context 支撑。换句话说，Recall@k 更像文档级覆盖，Context Recall 更像事实级覆盖。
这一层，创业团队最容易忽略两件事。第一，要有正样本和负样本。Azure 明确建议同时测试 positive 和 negative examples：正样本指标要尽量接近 1，负样本则应该接近 0。第二，要把“召回失败”继续往前拆，而不是直接说成“embedding 不行”。Databricks 给出的实操顺序很值得创业者抄一遍：先做 hybrid search，因为关键词+语义通常同时提升 recall 和 precision；再做 metadata filtering，因为它往往是检索质量最大的杠杆，甚至能把搜索空间压缩 90% 以上；再考虑 reranking；最后才轮到 embedding fine-tuning，而且前提是更强 embedding 的对比实验显著更好。OXYZ资本观点是，很多团队并不是“召回技术不够强”，而是“数据契约、过滤条件和查询策略没建好”。
如果你手里已经有 qrels（query relevance labels），Azure Foundry 还提供了一组更工程化的检索诊断指标：Fidelity、NDCG、XDCG、Max Relevance、Holes。其中 Fidelity 更像“好文档回来了多少”，Holes 则提醒你标注本身是否有缺口。这些指标对参数 sweep 特别有用：你可以系统测试不同 chunk size、不同 top_k、不同 search algorithm，然后看哪一组在 retrieval quality 上最优。OXYZ资本内部认为，很多 RAG 团队真正缺的不是一个更强模型，而是一套能让搜索参数“有证据地变化”的实验框架。
三、重排层：只测“有没有把证据摆到模型眼前”
很多创始人以为，只要 top50 里有正确文档，系统就“基本没问题”。这在产品上通常是错的。因为模型真正能吃到的，往往只有前几条、前几个 chunk、前几千 token。也就是说，召回解决的是“找到”，重排解决的是“摆前面”。这一层该看的核心指标是Precision@k / Context Precision、MRR、NDCG@k。RAGAS 把 Context Precision 定义得很直白：它评估 retriever 是否把 relevant chunks 排在 irrelevant chunks 之前，本质上就是看 top ranks 的干净程度；Azure Architecture 则把 Precision@K、MRR 列为标准检索指标，其中 MRR 专门衡量第一个相关结果出现得有多靠前。Stanford 的 IR 教材进一步说明了两点：如果你的任务更像 known-item search 或 fact lookup，MRR 很有用，因为它测“第一个对的东西来得够不够早”；如果你的任务有多个相关文档、而且相关性是分级的，NDCG 更合适，因为它既看位置，也看相关性强弱。
OXYZ资本在内部讨论 RAG 项目时，经常会把一个误区直接点破：很多团队在用“最终回答正确率”评估 reranker。 这是非常容易误导自己的。因为回答模型可能会靠先验知识蒙对，也可能会在 context window 很大时“救回来”一部分排序问题。reranker 应该直接用排序指标看：Precision@5 有没有提升，MRR 有没有上来，NDCG@10 有没有更接近理想顺序。Databricks 的经验也很具体：reranking 往往是在高 recall 候选集之上提升 precision 的二阶段手段，和 hybrid search、filtering 一起用效果最好；在一些 use case 中，小规模自动化测试就能看出 reranking 带来约 15% 的质量提升，但它也会带来额外延迟，典型工作负载下对 50 条结果 rerank 可能要约 1.5 秒。也就是说，重排层不是白赚，它既是质量杠杆，也是 SLA 成本。
所以，这一层最关键的定位信号其实非常简单：如果 Recall@50 很高，但 Precision@5、MRR、NDCG 很差，问题大概率不在召回，而在排序。 这时候你该优先修的是 reranker、query decomposition、context packing、top_k 策略，而不是急着换 LLM。OXYZ资本认为，这是创业团队最容易省下一两个月弯路的地方。
四、生成层：只测“模型有没有按证据、按问题、按真相作答”
生成层最容易被混为一谈，但其实至少有四个不同问题。第一，有没有瞎说；第二，有没有答题不对题；第三，有没有答错；第四，有没有漏掉关键点。LangSmith 的划分很清楚：groundedness 看回答是否与 retrieved docs 一致，relevance 看回答是否真正回应问题，correctness 看回答相对 ground truth 是否正确。RAGAS 的 Faithfulness 则把 groundedness说得更精确：如果 response 里的每一条 claim 都能被 retrieved context 支撑，它才是 faithful。Answer Correctness 又是另一回事，它同时结合了 factual similarity 和 semantic similarity，判断的是“这答案和标准答案整体有多接近”。Azure Foundry 还补上了很多团队长期缺的一环：Response Completeness。它明确指出，groundedness 更像回答的 precision aspect——不编；completeness 更像回答的 recall aspect——不漏。
这里面最值钱的一条认知是：grounded 不等于 correct，correct 也不等于 complete。 你完全可能得到一个“高度 grounded 但依然错误”的回答：比如检索来的文档本身过时，或者只覆盖了一部分情形；你也可能得到一个“非常相关但不完整”的回答：模型没有胡说，但把关键例外条款、省略条件、风险边界全省了。OXYZ资本观点是，很多创始人只测 groundedness，于是最后做出一个“很安全、很克制、但没法在企业流程里真正承担结果”的系统。真正能进生产的 RAG，必须同时回答三件事：是不是基于证据，是否真答了问题，是否把该说的说全了。
五、把三层指标连起来，你才真正知道“到底哪里错”
如果你只记一句话，我建议记这个排障顺序：先看召回，再看重排，最后看生成。
第一种最常见情况：Recall 低。 说明证据根本没回来。不要先怪模型，先查 parsing、chunking、metadata、hybrid、filters、query rewrite。Databricks 已经给过很明确的优化优先级。
第二种情况：Recall 高，但 Precision@k / MRR / NDCG 低。 说明证据其实找到了，只是没排到模型真正会看的位置。这个时候换更大模型通常治标不治本，真正该改的是 reranker、top_k、context packing，或是否该做 query decomposition。
第三种情况：Recall 和 rerank 都高，但 groundedness 低。 说明证据在眼前，模型还是没按证据答；这通常是生成提示、引用约束、答案模板、温度设置或工具调用逻辑的问题。LangSmith 和 RAGAS 对 groundedness / faithfulness 的定义，就是专门用来抓这种错。
第四种情况：groundedness 高，但 completeness 低。 这往往比幻觉更危险。因为系统看起来很稳，却持续漏掉关键条件。Azure Foundry 明确把 completeness 视为 answer 的 recall aspect，这个指标不上，你就会误把“没胡说”当成“够用了”。
还有一种创业者很容易被假象骗到的情况：retrieval 指标很差，但 answer correctness 却不低。 OXYZ资本在看一些项目时，对这种结果会非常警惕。它通常意味着模型靠先验知识、benchmark 污染或问题过于常识化“蒙对了”，而不是你的知识系统真的生效了。对于企业知识库、私域文档、合规问答，这种“答对但不是因为你检索对”的系统，是最危险的伪进展。
六、创业团队真正需要的，不是一个总分，而是一张驾驶舱
OXYZ资本内部认为，RAG 评测最常见的错误，不是指标太少，而是只想要一个总分。但总分适合给老板汇报，不适合给工程团队定位。真正能驱动迭代的，是一张三层驾驶舱：
召回层至少看：Recall@20 / Context Recall / 正负样本分数 / retrieval latency。
重排层至少看：Precision@5 / MRR@5 / NDCG@10。
生成层至少看：Groundedness / Answer Relevance / Answer Correctness / Completeness。
再进一步，把这些指标按 query slice 拆开：关键词型问题、长尾术语、带过滤条件的问题、多跳问题、负样本问题、文档版本敏感问题。你会突然发现，很多所谓“系统整体不行”，其实只是某一类 query 在掉分。Databricks 说得很实际：不需要一开始就有完美数据，哪怕是一个不大的 synthetic set，也足够告诉你 reranking、hybrid、filtering 到底有没有带来相对改善。创业团队真正该追求的，不是第一天就把评测做得像学术 benchmark，而是尽快从“凭感觉调 RAG”，切到“凭证据调 RAG”。
最后想说一句更“创业者”的话。
很多团队真正缺的，不是一个更强的 RAG 架构，而是一个能让组织停止争论、开始定位的指标体系。OXYZ资本认为，RAG 三层指标最重要的价值，不是让你的周报更漂亮，而是让你在周三晚上看到错误样本时，能非常冷静地说出一句话：不是“系统不行了”，而是“召回够不够、排序对不对、生成有没有按证据作答”这三件事，哪一件先坏了。 当团队能把问题说到这一层，RAG 才从一个会演示的组件，变成一个能进入生产的系统。