8.0
热点
AI SCORE
编程提效2026-08-10 10:38
RAG评估实战：从黄金数据集到LLM-as-Judge
dev.to · AI#RAG#LLM#评测
Editor brief · 编辑速览
系统阐述RAG评测方法：将检索和生成分开评估，用确定性代码验证精确值，用LLMJudge评判自由答案，输出可重复的决策系统。
一个检索增强生成（RAG）系统可能在多个相互独立的环节同时出错，却仍能输出一段流畅的回答。它可能检索到了错误的证据、遗漏了必需的文件、误读了正确的上下文、答非所问，或者编造了一个从未出现在任何来源中的数值。单一的「准确率」分数无法解释这些失败，也无法定位需要改进的组件。
可靠的评估将 RAG 视为一条流水线。检索和生成分别接受不同的指标考核。精确值通过确定性代码进行校验。自由格式的回答则依据明确的标准进行评判。每一次模型、提示词、分块策略和排序规则的改动，在发布前都必须在同一数据集上完成评估。
目标不是产出一个令人印象深刻的面板数字，而是建立一套可重复的决策系统，用以回答三个运营问题：
系统是否检索到了回答问题所需的证据？
生成的回答是否正确使用了这些证据？
相比其成本和延迟，所提议的改动是否带来了足够大的质量提升？
将检索与生成分离
RAG 至少有两个主要的失败面。
检索层负责选择上下文。它可能返回无关的片段、遗漏必需的段落，或检索到过时版本。生成层负责解释这些上下文。它可能忽略证据、错误地组合事实，或添加不支持的声明。
这些失败需要不同的修复手段。如果正确的发票行从未进入上下文，更改回答提示词无法修复检索问题。如果正确的行已存在但模型报告了错误的单价，增加向量 top-k 也无法修复生成问题。
因此，评估应当保留这些阶段之间的边界。
上下文精确率（Context Precision）衡量检索到的上下文中有多大比例与问题相关。精确率低意味着提示词中包含噪声。即使相关证据同时存在，无关的片段也会消耗 token 并可能干扰生成器。
精确率还应当考虑排名顺序——如果一个相关片段埋在第 8 位，而前 7 位都是无关片段，这表明检索器的表现比原始相关性比例所显示的更弱。
例如，对于一个关于产品 PRD-482 退货条件的问题，关于保修时长的条款可能在主题上相关，但并不能回答该问题。检索评估必须区分一般相似性与带答案的证据。
上下文召回率（Context Recall）衡量回答所需的所有证据是否都被检索到了。这对于需要多个来源或表格行的题目尤为重要。
假设请求是计算三个行项目的总成本。检索到两个正确的行会产生看似很高的精确率，但召回率是不完整的。生成的总金额不可能正确，因为一个必需的输入从未到达模型。
当数据集标明了预期证据时，还可以使用诸如 recall@k、Mean Reciprocal Rank（平均倒数排名）或 normalized Discounted Cumulative Gain（归一化折扣累积收益）等指标来评估排序。这些指标揭示了正确答案是否存在于候选集中，以及它的排名有多靠前。
k 的取值应当反映实际流水线。如果一个正确答案排在第 40 位，这只有在候选生成器向下传递至少 40 个条目的情况下才有意义。如果应用只向模型发送前 5 个片段，那么 recall@5 比 recall@100 在操作上更有意义。
忠实度（Faithfulness）询问回答中的声明是否由提供的上下文支持。一段回复可能流畅、相关，但仍然不忠实——如果它引入了一个价格、日期、条件或结论，而检索到的证据并不支持这些内容。
在可行的情况下，应当逐条声明地评估忠实度。一段多句回答可能包含三个有支持的陈述和一个不支持的结论。单一的二值标签会掩盖这种区别。
回答相关性（Answer Relevancy）询问回复是否针对用户的实际请求。一段回答可能复述了上下文中的正确信息，同时回避了所请求的比较或计算。
例如，一段列出产品描述的回复并不能回答「哪个产品的单价更低」这个问题。内容可能是有依据的，但与所请求的决策无关。
精确校验与结构化校验
并非所有回答都需要语言模型来评判。发票编号、产品代码、数量、单价、日期、货币和总计应当被规范化后通过确定性代码进行比较。
结构化校验可以验证：
基于代码的评估比让模型评判已有正式表示的事实更便宜、更快且更具可重复性。
开源评估框架使这些校验更容易落地。Ragas 和 DeepEval 提供了现成实现的忠实度、回答相关性、上下文精确率和上下文召回率；TruLens 和 Arize Phoenix 则暴露了密切相关的预构建 RAG 评估器，用于有依据性或忠实度、回答相关性以及检索相关性。他们的默认配置是有用的起点，但评判模型、评分标准和阈值仍需要针对目标领域进行校准。
指标独立性至关重要
检索指标和生成指标不可互换。上下文召回率可能完美而忠实度很差。模型可能收到了正确的发票行，却仍然从自己的先验知识中报告了一个数值，或者混淆了两列相邻的数据。
反过来也可能发生。模型可能对不完整的上下文保持完全忠实。它的回答准确地反映了检索到的片段，但遗漏了一个必需的产品——因为检索层漏掉了它。
下图是一个有用的诊断矩阵。这是一种简化的启发式诊断方法，而非正式或标准化的框架。
这种分离将评估从计分转变为诊断。
设计黄金数据集
黄金数据集是一个带有已知期望的精选测试用例集。每个示例应当包含的内容远不止一个问题和参考答案。
一条实际记录可能包括：
{
"id": "price-lookup-014",
"question": "What was the March unit price of PRD-482?",
"expected_answer": {
"product_code": "PRD-482",
"unit_price": 125.50,
"currency": "EUR"
},
"required_sources": [
"invoice-2026-0148-line-04"
],
"category": "exact_lookup",
"answerable": true
}
数据集应当代表真实的查询分布，同时刻意包含困难案例：
分类使回归测试可以被定位。新嵌入模型可能在语义问题上表现更好，同时损害精确产品代码检索。单一的聚合分数可以掩盖这种权衡。
测试拒绝能力
一些黄金问题应当在可用语料库中故意设计为不可回答。预期行为是明确声明信息不可用，而不是给出一个看似合理的回答。
不可回答的案例测试：
负面示例至关重要——因为一个仅在可回答问题上评估的系统，可以表现得准确，但在证据缺失时仍然不安全。
弃权可以作为一种分类任务来衡量。定义弃权精确率（abstention precision）为正确弃权数 / 所有弃权数，衡量每次拒绝有多少是合理的。定义弃权召回率（abstention recall）为正确弃权数 / 所有不可回答案例，衡量有多少应该被拒绝的问题实际被拒绝了。这些指标应当与回答覆盖率（answered cases / all cases）以及已回答案例的准确率一同报告——这样系统就不能通过拒绝所有请求来提升其拒绝得分。
保持数据集的活力
黄金数据集不是一次性的基准。它必须随语料库和生产流量一同演进。
新文档应当引入新问题。否则基准只衡量旧查询是否仍然有效，无法检测最近添加信息上的失败。生产事故和用户报告的错误在验证了正确答案和来源后，应当成为回归用例。
人工反馈作为评估循环
差评等显式反馈应当创建一个审查项，而不是作为孤立的分析事件存在。审查者可以对原因进行分类：
问题纠正后，该问题、已验证答案及其来源将成为回归测试。这形成了从生产失败到永久覆盖的完整闭环。
人工审查也可以对部分质量问题进行标注。响应可能使用了正确的来源但遗漏了请求的字段。捕获结构化的失败原因比仅存储点赞或点踩标签更有用。
谨慎使用 LLM-as-Judge
语言模型评判器适用于难以用精确规则编码的质量维度，如忠实度、完整性、清晰度和相关性。但它们并非天然可靠。
有效的评判依赖于：
在信任自动化评判之前，应当由人工和评判器对代表性样本分别评分。应当按类别而非仅用一个总体百分比来衡量一致性。评判器在忠实度上可能可靠，但在写作质量或部分完整性上可能不一致。
已发表的研究结果说明了为何按指标进行校准很重要。在原始 RAGAS 论文中，自动化指标与人工偏好的一致率在 WikiEval 成对忠实度比较中达到 95%，在答案相关性比较中为 78%。这些数字是针对某一 50 题评估设置上的准确率，并非对其他领域、评分标准或评判模型的通用保证。
低一致率表明评分标准、提示词或评分定义需要改进。应当重新校准评判器并再次测试。然后人工审查可以聚焦于不确定案例、有分歧的案例、高风险类别以及用于监控评判器漂移的样本。
确定性数值应当排除在此流程之外。代码比较应当验证 125.50 EUR 与预期价格是否匹配。评判器可以评估周围解释是否忠实且相关。
在质量、延迟和成本之间权衡
检索配置是一个多目标优化问题。增加检索的 chunk 数量可能提高召回率，但也会增加延迟、token 使用量和噪声。添加重排器可以改善排序但会增加推理成本。更强的生成器可能提高忠实度但也会增加响应时间。
每种候选配置应当在相同的黄金数据集上运行，并生成对比表：
下面第一行是说明性的、现实的示例，而非基准测试结果。生产报告应当用目标环境的实际观察值替换它以及每个带测量值的占位符。
表格应当使用目标环境的观察值。决策应当遵循明确的规则。如果成本下降而质量保持在可接受范围内，则变更可以推进。如果质量降至类别阈值以下，仅凭较低成本不足以支撑决策。
路由可以改善这种权衡。简单查询可能使用更少的检索阶段和更小的模型。复杂比较可能需要更广泛的检索、重排和更强的生成器。每条路由应当有自己的服务质量等级和质量目标。
当正确上下文存在时的调试
当检索评估确认所需证据已到达生成器但答案仍然错误时，调试应当转向生成层。
接地指令
系统提示词应当明确要求模型仅使用提供的证据，并在证据不足时声明。模糊的"使用以下信息"请求并不能明确禁止无依据的补充内容。
上下文位置与结构
长提示词会导致中间的相关段落获得的注意力减少。最强的证据应当放置在突出位置，chunk 应该有清晰的边界，来源元数据应当区分文档和表格行。
使用较低温度或更强的模型重复测试有助于将采样变异性与结构性提示词问题区分开。如果相同的错误在不同模型和确定性解码下持续存在，则上下文表示或指令更可能是责任方。
要求每个事实性声明都附带来源引用会使无依据内容更容易被检测。引用应当在程序上验证：被引用的来源必须存在，且被引用的段落必须包含该值或声明。
最后的忠实度检查可以比较生成内容与上下文中的声明。结构化答案还应当通过 schema 和算术验证。这一层比修复提示词或上下文布局更昂贵，因此它应当作为早期控制的补充而非替代。
当评估控制发布时，它才成为可操作的。对分块、嵌入、提示词、模型、路由或索引参数的更改应当触发相关测试套件。
发布门槛可以强制执行以下要求：
未通过的门槛应当阻止部署，直至回归被理解。目的不是防止每个分数波动，而是防止未经验证的质量下降到达用户。
基于风险的阈值与分数聚合
并非每个查询类别都有相同的后果。产品文案中的轻微措辞差异不等同于错误单价或缺失合同限制。评估阈值应当反映输出的风险。
关键精确值路由可以要求确定性相等性、完整的来源覆盖和成功的算术验证。语义摘要可以使用分级相关性和忠实度评分。不可回答的问题可以要求高弃权率和零个无依据的数值声明。
例如，基于风险的门槛可能要求关键精确值路由达到 100% 确定性匹配，包括标识符、单位和大小的算术验证。低风险的语义摘要路由可能要求忠实度 >= 0.85 且答案相关性 >= 0.80。这些是示例起始点，而非通用默认值；它们应当通过人工审查、实际应用的错误成本观察和分数分布来校准。
因此，发布报告应当同时展示汇总和按类别的结果。宏平均给每个类别相等的影响力，而流量加权平均反映当前使用情况。单独使用两者都可能产生误导。罕见但关键的计算类别可能淹没在强劲的整体分数中。
硬性门槛保护这些情况：
当生成具有不确定性时，置信区间或重复运行很有用。基于小数据集的单点变化可能是噪声而非改进。测试集大小、类别覆盖率和运行方差应当与报告的分数一起附上。
评估还应当检测仅在类别之间转移错误的改进。增加 top-k 可能提高召回率同时降低上下文精确度和忠实度。更强的模型可能提高答案质量但违反延迟目标。新的路由可能降低成本同时将一小部分聚合问题发送至错误工具。
决策规则应当在查看结果之前定义。例如，候选方案可能要求无关键回归、目标类别达到最低质量提升，并符合成本和延迟预算。预定义规则减少了在实验后为偏好配置找理由的诱惑。
质量阈值是操作契约。它们将抽象的评估分数转化为明确的条件，用以判断系统是否适合发布。
RAG 评估最有价值的之处在于将测量与行动连接起来。低上下文召回率指向数据摄取、分块、嵌入、过滤器或排序环节。低忠实度（但上下文很强）指向提示词工程、上下文呈现、模型行为或验证环节。高延迟而质量不变指向不必要的阶段或过大的模型。
黄金数据集、确定性检查、校准过的语言模型评判器以及人工反馈提供了互补的证据。它们共同用可重复的实验取代主观争论，并将生产环境中的错误转化为永久性测试用例。
在 RAG 系统的失败被分离、标注并在发生层面被测量之前，它无法被可靠地改进。
Ragas metrics documentation - 开箱即用的 RAG 评估指标
DeepEval RAG 评估指南 - 含实现示例的检索器和生成器指标
TruLens RAG Triad - groundedness、answer relevance 和 context relevance
Arize Phoenix 预构建指标 - 用于忠实度和检索相关性的开源评估器