评估了错误的 RAG 管道环节

你的 RAG 评估仪表盘显示为绿色。忠实度（Faithfulness）为 0.91，回答相关度（Answer Relevance）为 0.88，你花了两个迭代周期构建的 LLM-as-judge 评估框架显示系统运行良好。与此同时，一位用户刚刚问了一个问题，而答案就在你的检索器（retriever）从未提取出的文档中，你的模型写下了一个自信、结构清晰但完全没用的回答，内容与问题相关但风马牛不相及。评判员给了它高分。它读起来很顺畅。它基于模型 确实 获取到的片段。它只是用与用户需求无关的内容回答了一个错误的问题。

这是大多数团队评估检索增强生成（RAG）时存在的隐性结构缺陷：他们给文章打分，却从未检查学生是否拿到了正确的书。RAG 系统是两个连接在一起的机器——一个是决定 模型能看到什么 的检索器，另一个是决定 如何处理这些内容 的生成器。几乎生产环境中的每一个评估框架都只衡量第二个机器。第一个机器，也就是真正决定答案质量上限的那个，却在未经监控的情况下运行。

其后果不仅仅是一个盲点。一个综合评分实际上 掩盖 了故障。当检索性能下降时——由于你更换了嵌入模型、重新对语料库进行了分块，或者索引悄悄过期了——生成指标吸收了这种损害。模型继续生成流畅、忠实于上下文的答案。忠实度保持平稳。回答相关度下降了一两个点，完全在噪声范围内。没有人收到告警。而当仪表盘上的每一个仪表都显示正常时，你的检索召回率（retrieval recall）已经从 0.9 下降到了 0.7。

为什么单一评分会导致两个环节都无法调试​

端到端评分之所以诱人，是因为它看起来像是一个真实的指标。用户体验到的是最终答案，所以为什么不衡量最终答案呢？因为一个综合数字只会告诉你 出错了，而永远不会告诉你 哪里 出错了。在两阶段的流水线中，“哪里”才是核心问题。

考虑在任何给定查询中可能发生的四种情况：

• 检索良好，生成良好 —— 答案正确，原因也正确。
• 检索良好，生成糟糕 —— 包含答案的分块就在上下文中，但模型仍然搞砸了，产生了幻觉或忽略了它。
• 检索糟糕，生成糟糕 —— 模型根本没有机会；垃圾进，垃圾出。
• 检索糟糕，“生成良好” —— 模型写出了一个简洁、忠实且基于错误文档的答案。这是最危险的情况，因为在所有下游指标看来，它 像是 成功的。

端到端的忠实度评分无法区分这些情况。更糟糕的是，忠实度特别奖励第四种情况。忠实度会问：答案是否得到检索到的上下文的支持？如果检索带回了错误的段落，而模型尽职地对其进行了总结，那么答案是非常忠实的——只不过是忠实于错误的来源。你构建了一个指标，只要谎言与产生它的错误保持内部一致，它就会给自信的谎言打出最高分。

所以当你的单一指标下降时，你就陷入了困境。是检索器漏掉了文档？是重排序器（reranker）顺序错了？是分块大小（chunk size）不对？还是模型忽略了给定的上下文？是提示词（prompt）不好？你无法分辨，因为你测量的是总和，而现在你正试图反向推导加数。你最终针对一个完全存在于向量索引中的问题进行提示词 A/B 测试——这就像是凭着一个仪表飞行，试图通过调整油门来纠正导航错误。

独立评估检索环节​

解决方案是停止将检索视为隐形的上游依赖，并开始将其作为一个具有自身指标、自身标注数据和自身仪表盘的一等公民系统来评分。归根结底，检索是一个信息检索（IR）问题——搜索引擎几十年来一直在对其进行严谨衡量——而且这些指标已经存在。你只需要实际去计算它们。

基础是一个 标注集（labeled set）：一组具有代表性的查询，每个查询都配有实际包含答案的文档或分块。这是吃力不讨好且昂贵的部分，也是团队会跳过的部分。但如果没有标准答案（ground truth），你就无法判断检索是否成功——你只能靠猜。几百个精心挑选的“查询-黄金分块”对就足以开始，这也是整个评估栈中杠杆率最高的人工产物。一旦你拥有了它，这些指标几乎可以信手拈来：

• Recall@k —— 在所有相关分块中，有多少比例出现在你检索的前 k 个结果中？这是最重要的一个，因为它回答了决定上限的唯一问题：答案是否出现在模型看到的上下文窗口中？ 如果 Recall@k 是 0.7，那么有 30% 的时间，你的生成器被要求根据不包含答案的材料进行回答。任何提示词工程都无法修复这个问题。
• Precision@k —— 在你检索到的内容中，有多少是实际相关的？低精确率意味着你在上下文中塞入了噪音，消耗了 Token 并稀释了模型必须寻找的信号。
• MRR (平均倒数排名) —— 第一个相关结果排在第几位？这很重要，因为位置并非中立的；模型对上下文顶部附近的材料关注得更可靠。
• nDCG@k —— 一个考虑排名的评分，奖励将最相关的分块放在最前面的行为。这个指标能够真实反映你的重排序器是否发挥了作用。