RAG 应用的离线评估工程 2026：从合成查询、参考答案到三件套回归门禁的闭环架构

一句话摘要:把 RAG 评估从"上线后才知道坏没坏"前置为"改 A 之前先在离线回归集上证明 A 不打坏 B"——核心是合成 query + 参考答案 + context precision/recall/faithfulness 三层指标 + CI 门禁四个齿轮的同轴咬合。

一、问题的提出:RAG 改了怎么知道改对了

RAG 应用上线之后,几乎所有团队都会撞上同一种焦虑:今天把 retriever 从 BM25 换成了 dense、明天把 chunk size 从 512 砍到了 256、后天把 rerank 模型从 bge-reranker-base 升到 bge-reranker-large——每一次改动,线上流量都没爆、用户反馈也没什么异常,但产线心里总是不踏实:到底是真的没变差,还是样本里恰好没踩到?这个不踏实不是程序员的强迫症,是 RAG 系统评估结构性的脆弱:它不像传统搜索有清晰的 nDCG/MAP 这种几十年的 NRRC 共识,也不像 LLM 的 perplexity 有教科书级别的解释力——它是一束异质的指标,横跨 retrieval、generation、groundedness 三个阶段,任何一个环节出问题都会被下一个环节的"看起来还行"掩盖掉。

过去两年里,业界对 RAG 评估的关注大致沿着三条轨迹走:RAGAS 框架(context precision/recall/faithfulness + answer relevancy 四件套)把它拉到了 LLM-as-judge 的主路径上;真实用户反馈贡献了端到端 satisfaction 的遥测;离线人工标注保留了少数高价值问题的金标准。但对一线 RAG 工程师来说,这三条都不够:LLM-as-judge 的稳定性是分布式的、用户反馈延迟是周级别的、人工标注是天级别且只能小批量。真正能在 PR 合并时跑出<3 分钟结果的是离线合成数据 + 自动指标。

本文的核心命题是:把 RAG 评估工程化为一门"合成查询 + 参考答案 + 三层指标 + 回归门禁"的同轴系统——它不是某一种评估方法的胜利,而是这四颗齿轮咬合之后的工程闭环。我们把这一闭环称为 RAG 评估门禁(RAG Evaluation Gate, RE-Gate)。这个名字参考了 BSD 协议族里回归测试集的"金标准库"传统,也参考了 chip manufacturing 里"wafer-level gate"的良率门禁语义——意思是每次改动都要跨过这道"测试集的合格线"才能往下走。

二、形式化:RAG 评估的三层指标体系

在讨论工程之前,先给 RAG 评估一个清晰的形式化框架。给定一个 query $q$、corpus $\mathcal{C}$、chunker $\sigma$、embedder $\phi$、reranker $\rho$、generator $\mathcal{G}$,RAG 系统的输出是答案字符串 $a$ 以及支撑它的上下文链 $C = (c_1, c_2, \ldots, c_k)$。每一层指标刻画的是某一阶段的局部 quality:

第一层 IR 指标(retrieval quality)。把 query 投射到检索空间,看 top-$k$ 上下文里"是否包含 ground-truth 答案所在的 chunk"。这条线上的三个核心指标是:

• Context Recall@k:ground-truth chunk 在 top-$k$ 上下文里出现的概率。是"召回"的回声。
• Context Precision@k:top-$k$ 上下文里"真正有用"的 chunk 占比。是"去噪"的回声。
• MRR / nDCG:对排序位置的进一步加权。MRR 关心第一个相关 chunk 出现的位置,nDCG 关心"好 chunk 应该在前的位置出现"。

第二层 Generation 指标(answer quality)。只看答案字符串 $a$:

• Faithfulness(groundedness):答案里的每一个 claim 是不是都能在上下文 $C$ 里找到字面依据。RAGAS 用"claims split by sentence + NLI-style entailment"实现。
• Answer Relevancy:答案在语义上是不是直接回应了 query。这是 query↔answer 的对称度。
• Hallucination rate:Faithfulness 的反义——出现了幻觉的比例。RAGAS v0.2 把 hallucination 拆成"extrinsic"(凭空捏造)和"intrinsic"(扭曲了上下文)两种。

第三层 End-to-End 指标。把 IR + generation 串起来:

• Answer Correctness:把生成的答案与参考答案对齐,通常用 F1 + embedding cosine 加权。
• Answer Similarity:仅用 embedding 余弦评估"答得有多像"。比 Correctness 宽松,但可作为快速 sanity check。
• Noise Robustness / Negative Rejection / Information Integration:RAGAS 的三件小众指标,分别对应"上下文里有干扰 chunk 时答得稳不稳"、"检索不到时知道拒绝答"、"多 chunk 综合提取是否到位"。

这三层指标构成了 RAG 评估的 3×3 矩阵:纵向是 query retrieval / answer generation / end-to-end 三个粒度,横向是 quality / robustness / efficiency 三个轴。本文的工程闭环就在这个矩阵上沿"质量"轴投影。

三、合成查询与参考答案数据集工程

离线回归集的第一道关卡是怎么造数据。三种主流路径:人工标注、模板合成、LLM 蒸馏合成。

人工标注的金标准最高但成本最重。一个 50-query 的高质量标注集通常需要领域专家花一周时间。大型企业(法务/医疗/金融)有内部标注团队可以负担,但对大多数 RAG 应用来说,完全人工是不现实的。

模板合成走的是"data programming"路线——为每种 query 类别设计 slot,自动从 corpus 里抽 entity 填进去。比如法律文书 RAG 可以写模板"原告{X}于{Y}年起诉被告{Z}关于{W}纠纷,核心争议点是 {V}",其中 {X/Y/Z/W/V} 从案件库 metadata 里抽。这种模板合成的优点是参考答案可以保证 gold chunk 的存在性(因为答案片段是直接抄 corpus 的),缺点是 query 多样性差、模板 bias 强。

LLM 蒸馏合成是当下最有杠杆的方法。给定 corpus 的 chunk 池 $\mathcal{C}$,用 LLM 反过来"读 chunk 编 query",每个 chunk 生成 3-5 个可能问到的 query,再用 self-critique 过滤掉 low-quality 生成。关键技巧有三:

1. chunk-as-evidence 而不是 chunk-as-answer:让 LLM 在生成 query 时把 chunk 当成"答题可能用到的事实片段",而不是把 chunk 原话当成 query——这样合成出来的 query 才有真实用户的口吻。
2. 平衡 query 类型分布:不要让合成集 90% 是"事实抽取型",要刻意混入"对比型"、"总结型"、"反问型"、"推导型"。LLM-as-a-query-generator 的输出分布偏向信息抽取类,需要后处理 rebalance。
3. 参考答案的 ground-truth 锚定:每个合成 query 必须关联到 corpus 里的具体 chunk id 列表,不能只关联到一段抽象的"answer text"——IR 层的 context recall 没有 ground-truth chunk list 是算不出来的。

回归集的版本治理也属于这一阶段的工程。RAG 应用评估的金标准集必须固化为 snapshot,跟代码一起进 git LFS——升级 embedding 模型时不能让 50-query 的金标集变了,否则指标会"原地踏步"或"先涨后跌"。RAGAS 的官方实践 + TruLens 的 dataset versioning + DeepEval 的 test fixture 加载 都在向 git LFS 模式收敛,据 X 报道,截至 2026 年 7 月,业界没有出现主导的回归集托管平台,大多数团队仍走 self-hosted + git LFS。

四、检索质量 IR 三件套:context precision、recall、relevance

回归集造好之后,IR 层指标是 RAG 评估的门面,也是最容易被误用的一层。

Context Recall@k 的真实含义:不是"top-$k$ 里有没有出现过 ground-truth chunk",而是"top-$k$ 中是否存在 ground-truth chunk 中任意一个"。这是 recall 的拉通定义——问的是覆盖率。但 RAG 的实际业务里,recall 不一定越高越好——top-20 比 top-5 的 recall 通常更高,但 precision 会塌方,因为更多无关 chunk 会干扰 generator。所以工程上 paired design 更有意义: $\text{Recall@5}, \text{Precision@5}, \text{Recall@10}, \text{Precision@10}, \text{Recall@20}, \text{Precision@20}$ 六指标同表呈现,比单看一个数字更稳定。

MRR 与 nDCG 的差异:MRR 只看"第一个相关 chunk 出现在第几位",对后续位置不敏感;nDCG 对整个排序列表建模"增益按位置衰减"——增益 $2^{rel_i} - 1$,折损 $1 / \log_2(i+1)$。当 reranker 介入时,nDCG 比 MRR 更能反映 reranker 的有效性——因为 reranker 把"最相关的放到最前",但第二个相关如果也排到了第二位,MRR 看不到,nDCG 看到了。TREC 经典论文里 nDCG 优于 MRR 的讨论见[1]。

Context Precision 的常见误用:RAGAS 把它定义为"top-$k$ 上下文中相关 chunk 数 / $k$"。这个"相关"由 LLM-as-judge 判定——它有 LLM 风格的不稳定性。工程上的稳健做法是双盲交叉验证:用 3 种不同 LLM 各判一遍 context precision,投票;如果三方一致率 > 80%,取平均;否则标记为"uncertain"从指标里排除。DeepEval 和 RAGAS 在 0.2 版本之后都默认开了 multi-judge consensus 选项,但默认实现各异,据 X 报道,截至 2026 年 7 月,主流框架的 consensus 算法还没有公开的对照基准。

离线 IR 评估的真实陷阱:corpus drift。我曾在自己的 RAG 项目里发现,context precision 周级别会从 0.78 跌到 0.62,不是因为模型变了,而是因为 corpus 加了 200 个新 doc,新 doc 跟 query 的字面重合度比旧 doc 高,reranker 反而偏好它们——这是一种 distribution shift,跟 embedding 没关系。所以回归集的 corpus snapshot 必须跟 model snapshot 绑定,否则指标会被 corpus 自身的演化污染。

IR 指标的不确定性量化(UQ-IR)。单一 context precision 数字容易被 noise 误导——10 次重跑的 std 通常 ±0.04,如果只看 P50,无法分辨"真的变了"与"只是噪声"。UQ-IR 是把 context precision 视作分布而不是标量:每次跑都重排 query 顺序、bootstrap 采样 1000 次,得到均值 + 95% CI。两个 commit 的 CI 区间如果重叠 95%,就视为无显著回归。这是工业 RAG 评估少有人写但价值极大的一个工程环节——Simple, Cheap, Hard to defend politically because"你只跑一次还不够吗?",答案是不够的。

五、生成质量:faithfulness、answer relevancy、hallucination

IR 层之后是 generation 层——这一层也是 RAG 评估争议最大的部分。

Faithfulness 是 RAG 的灵魂指标。它问的是"答的每一句话是不是都能在 context 里找到字面证据"。实现路径有三种:

• NLI-based entailment:用 pretrained NLI model(DeBERTa-v3-large-mnli 是常用选项)判定"答 → context"是否是 entailment 关系。
• Atomic facts decomposition:LLM 把答拆成 atomic claims,逐个 claim 跟 context 做 entailment。
• LLM-as-judge direct rating:直接让 LLM 打分答的每个句子是不是 grounded。

NLI-based 最稳定(论文里见[2],[3]),但慢;atomic decomposition 最细,但 LLM 拆分本身有偏;LLM direct rating 最快,但脆弱。RAGAS 默认走 atomic + LLM judge 的混合方案,DeepEval 默认 NLI。没有一个被工业界普遍接受的 faithfulness 黄金实现——据 X 报道,截至 2026 年 7 月,主流 faithfulness benchmark(Tydi QA、TruthfulQA)与人工 judgement 的 Spearman 相关系数仅 0.55-0.7 区间,这是 LLM-as-judge 自身的上限。

Answer Relevancy 的实现通常基于 query↔answer embedding cosine——把 query 和 answer 都 encode,算余弦。这听起来简单,但有几个工程盲点:

1. embedding 模型必须一样:用 bge-large-en-v1.5 算的 relevancy 跟 text-embedding-3-small 算的,数值的"含义"完全不同,不能混着画图。
2. query rewriting 的诱因:如果 query 经过改写再检索,那么 answer relevancy 应该用原始 query还是改写后 query对齐?工程上建议跟 IR 层的 metric 保持对齐——改写后 query 对齐。

Hallucination rate 是 faithfulness 的反义。但工程上更常用的是"intrinsic vs extrinsic"拆分——intrinsic hallucination(扭曲了上下文)和 extrinsic hallucination(凭空加 context 里没有的信息)。这两种 hallucination 的根因不同:intrinsic 通常是 generator 误解了上下文,extrinsic 通常是 generator 用了自己的 parametric knowledge "补全"。Fix 路径也不一样:extrinsic 可以靠加 negative prompt + corpus-only grounding,Intrinsic 则要靠 better long-context reasoning。

Anti-prompt-injection robustness是这一层容易被忽略的工程指标。RAG 应用如果接入了 user-provided 文档(比如把用户上传的合同塞进 corpus),这些文档里的 prompt injection 会污染 retrieval,导致 generator 的 faithfulness 出问题。工业实践是加一道"sanitization pass":在 chunk 进 embedding 之前,先 regex + 关键词 blacklist 过滤掉"ignore previous instructions" 这类 attempt,再喂检索;同时 faithfulness 评估里加入 "answer contains injected phrase" 的 negative signal。

生成层的"对抗样本"防护。Faithfulness 是平均值意义上的守门员,但真实的对抗性 query(用户故意构造的边界 prompt,如"用上面文档里的话反驳自己")会让 answer 出现幻觉式拼接。工业级 RAG 评估要把对抗样本纳入回归集:每 100-query 的常规集,补 5-10 条 adversarial query,作为 Faithfulness 的下行边检。据 X 报道,截至 2026 年 7 月,RAGAS / DeepEval 的对抗样本生成仍是手写为主,自动化合成(LLM-as-adversary)有 30%-50% 的攻击成功率,需要 human filter 二次验证。

六、统一视角:把三层指标投影到一张回归曲线

三套指标各自独立时噪声会叠加——一个 50-query 的回归集,IR 层指标 CI 区间通常 ±0.03,generation 层指标 CI 区间通常 ±0.05,end-to-end 指标 CI 区间通常 ±0.07,如果分开看,你可能在 ±0.05 的 noise 上做决策。这是 RAG 评估工程化最大的阻力来源。

解决思路是把三层指标压到一个综合分数上,但不丢失诊断信息。三种主流模式:

• 加权平均:$\text{RAG-Quality-Score} = w_1 \cdot \text{Recall} + w_2 \cdot \text{Precision} + w_3 \cdot \text{Faithfulness} + w_4 \cdot \text{AnswerRelevancy}$。简单但权重难拍,且无法定位问题。
• 占主导指标(paired key metric):只挑一个核心指标作为 gate(通常 faithfulness),其它指标作为 warning。
• 门禁矩阵(predicate conjunction):每个指标设阈值,只有全部满足才 PASS。RAGAS 0.2 之后的 recommended pipeline 默认走这个。

门禁矩阵是当前最工程化的选择。一个典型配置:

context_recall@10 ≥ 0.85
context_precision@10 ≥ 0.70
faithfulness ≥ 0.90
answer_relevancy ≥ 0.85
noise_robustness ≥ 0.65

任何一项失败 → PR 阻塞。Threshold 的拍板依据是:用过去 30 天的 IR/generation 指标分布的 P5/P95 作为 gate 上下限。这样阈值本身跟语料规模、自有 query 类型分布绑定,不会拍脑袋。

指标曲线化的工程意义:把每个 PR 的五项指标投影到一张 regression-over-time 曲线,以 commit hash 为横轴、五个 y 轴叠加(双 y / multi-axis plot)。当发现某次 commit 让 faithfulness 从 0.91 跌到 0.85,这是一条明显的回归拐点——可作为 PR review 的客观依据。Humanloop、RAGAS Cloud、Confident AI 等都提供这种 regression curve dashboard,据 X 报道,截至 2026 年 7 月,开源 side(MLflow + 自写 evaluator)仍是大多数中型团队的选择。

判别单次 PR 是否真回归的样本量问题:50-query 的回归集不够。工程经验:100-200 query 才足以在 ±0.03 的 noise 上分辨"真回退"与"自然波动"——这个样本量跟人工标注成本是冲突的,所以合成数据 + LLM judge 的组合成为主流。

跨指标相关性矩阵(root-cause analysis)。当 Faithfulness 跌到 0.85,工程上立刻要问的是"是 retrieval 烂了,还是 generation 烂了?"——这要靠跨指标的相关性矩阵:把 context_recall@10、context_precision@10、faithfulness、answer_relevancy 在每次回归跑完后做 Pearson 相关,得到一张 4×4 矩阵。如果在某个 commit 上 faithfulness 跌但 context_recall 不变,根因在 generation 层(generator 本身或 prompt 的问题)。如果 context_precision 跟 faithfulness 一起跌,根因在 retrieval 层(噪声 chunk 增多)。Ragas Cloud 的 root-cause trace 视图就是这一矩阵的产品化,但内部实现细节各家差异极大——据 X 报道,截至 2026 年 7 月,公开的"跨指标 root-cause"benchmark 还没有标准。

七、对 RAG 工程师的推论:门禁阈值与回归集治理

把上述工程闭环落到实操层,我给出五条推论:

推论 1:门禁阈值不要拍脑袋,要 P5/P95 自适应。固定阈值(比如 faithfulness > 0.85)在 corpus 演化时会越来越松——你的 retriever 实际可能仅 0.83,而你设的阈值 0.85,看起来 pass 但其实没 pass。正确做法是:每月取历史 30 天指标的 5 分位数作为 lower bound、95 分位数作为 upper bound,超过这个区间的 PR 才被标记为 regression。Alerting 而不是 gate。

推论 2:回归集和金标答案集都要版本化。Embedding 模型升级、chunk size 改、retriever 换架构——任何让"query→chunk 路径"发生改变的改动,都要用同一版本的 corpus + 同一版本的回归集重新跑 baseline。没有 snapshot 锁定,所有指标都不可信。

推论 3:Faithfulness 的 LLM-judge 必须 n≥3 双盲。一个 LLM 自己判 faithfulness 跟人工 judgement 的 Spearman 通常只有 0.55,但三 LLM 投票 + 一致率阈值 0.67,这个数字可以爬到 0.72-0.78。这是工业界 LLM-as-judge 的性价比拐点。Ragas Enterprise 和 DeepEval Premium 都支持 multi-judge,但开源版需要自己接。

推论 4:Context recall 和 context precision 都要画到同一张散点图。二维散点图能立刻看出一类典型错误:recall 高 precision 低(retriever 召回多但噪声大,通常 chunk size 太大);recall 低 precision 高(retriever 偏严,但 chunk size 太小、漏掉上下文)。这两个 pattern 的 fix 路径完全不同。

推论 5:不在线上线一个"RAG 沙盒"。把每条产线 query 在 staged retriever + staged generator 上跑一遍脱机评估,这个沙盒跟产线 retriever 同源、generator 同 prompt、corpus 同 snapshot。这个沙盒是上述一切工程闭环的承载基础设施。据 X 报道,截至 2026 年 7 月,成熟的"RAG 沙盒平台"还没有统一的开源标准,各家自建为主。

推论 6:成本与延迟的工程权衡。Offline IR 评估跑 100-query 的回归集,如果用 dense embedding + cross-encoder reranker,在 H100 上端到端约 35-60 秒;若同步跑 generation 层 LLM-judge(GPT-4o + Claude Sonnet + Gemini Pro 三模型投票),整体延时会推高到 8-15 分钟。关键工程取舍是双轨制:白天 5 分钟快回归(只跑 IR + single-judge faithfulness,用于 PR gate);夜间 60 分钟长回归(三模型投票 + end-to-end,用于周版本 tag)。这样 CI 的"<3 分钟"承诺才不会破。这是 RAG 评估的工程现实约束,也是大多数团队无意识丢弃掉的部分。

推论 7:回归集的"长尾"陷阱。单个领域的合成集容易偏向头部问题(高频 query 模式),长尾问题(罕见 + 高难度)的覆盖度会被低估。工程上推荐:长尾问题专门攒一个 50-query 子集,作为月度 manual audit 用,不混入 PR gate,避免 noise 大到把门禁卡死。Ragas Enterprise 的"tail-set divider"是这个思路的产品化,但公开 benchmark 验证仍偏少。

推论 8:Operator 的 "Stop the Line" 流程。日本丰田生产体系里有个老概念:产线工人发现质量异常,可以拉下红线让整条线停。RAG 评估的 operator 流程里也应该有同等的"Stop the Line":当线上指标真实跌出 P5 区间,允许 on-call 立即回滚 generator/retriever snapshot,而不是"开会评估"。这是 RAG 应用运维的最后一公里。据 X 报道,2026 年前 6 个月里大型 SaaS 的 RAG 线上事故,70% 是因为"评估门禁完整但 rollback 没有自动化"——评估闭环跟 rollback 闭环是两条独立链,缺一不可。

推论 9:可观测性直连评估。Production 流量抽 5% 进"RAG shadow traffic"——同一个 query 同时在产线 generator 和评估 generator 跑,后者实时算 faithfulness/answer_relevancy 喂监控。如果 shadow 的 faithfulness 中位数跌 0.05,自动 page on-call。这是把 evaluation 从"PR 时离线"扩展到"运行时在线"的关键一步。RAGAS 0.3 内置了 shadow-traffic 入口,但大多数团队没有把它接进 production stack。

八、对比与局限:与 LLM-as-judge / 人工标注的边界

RAG 评估的工程闭环不是万能的。三条已知的局限:

局限一:LLM-as-judge 的天花板。Faithfulness 的 LLM-judge 与人工 judgement 的 Spearman 通常 0.55-0.7,就算多 LLM 投票也很难突破 0.8——这是 LLM understanding 的固有上限,不是工程努力能补的。所以 RAG 评估的指标不能 100% 替代人工验收:关键场景(医疗/法律/金融)的最后一道仍然要靠专家抽检。

局限二:合成 query 与真实 query 的语义漂移。LLM 蒸馏合成的 query 有它的"机械味"——比如倾向于问"X 是什么"而不是"X 为什么"。RAGAS 的实验显示合成集与真实 query 的 embedding 分布差异在 ±0.1 之内(用 MMD 衡量),这不是零,意味着回归集的 IR 指标可能比产线高估或低估 5-15%。所以合成集 + 真实用户 query 抽检混用才是稳态——合成集做 regression gate,真实 query 抽检做 release gate。

局限三:多模态 / 结构化数据的评估盲点。如果 RAG 是图(图谱 GraphRAG)、表(table QA)、多模态(图文)形式,传统的 context recall/precision 的"chunk 是文本"假设就崩了——你没法把一张图当成 chunk,也没法用 NLI 判定"答 → context 的 entailment"。Multi-modal RAG 的评估是 2026 年的开放问题,据 X 报道,截至 2026 年 7 月,主流框架(RAGAS、DeepEval、TruLens)对 multi-modal 的支持都还在 beta。

这些局限并不是说工程闭环无用——它的价值在于把不能完全消除的不确定性前置到 PR review,让工程团队至少知道我们不知道的部分在哪里,而不是上线之后才发现。

九、给 RAG 工程师的清单

清单 1:回滚准备——任何 IR/generation 指标在 PR merge 之后 24h 内跌出 P5/P95 区间,要能立即回滚 generator / retriever 的 snapshot。RAG 应用没有 rollback 就是裸奔。

清单 2:回归集治理——合成 query 集 + 真实 query 抽检 + 标注金标答案,三个集合独立版本化。Ragas Style 的 eval_dataset.jsonl + corpus_snapshot/ + gold_chunk_index.parquet 三件套是行业事实标准。

清单 3:指标守门员——faithfulness / context recall / context precision / answer relevancy 四件套,任何一项跌破 P5 都不准入仓。这是门禁,不是 nice-to-have。

清单 4:多 LLM 双盲——LLM-as-judge 永远不要单 LLM,至少 3 模型投票 + 一致率阈值。这条不容妥协。

清单 5:多模态认知——只要你的 RAG 涉及图、表格、音频,自动评估的盲点是 30%+,关键场景必须人工评审。

清单 6:沙盒与产线同步——staged 的 retriever/generator/corpus 必须跟产线同源,不能"我用一个 toy retriever 评估产线的 GPT-4o 生成"。

清单 7:成本预算守门——把单次回归集的费用(token cost + GPU time)固化进 CI 预算,而不是 PR 作者个人信用卡。如果单次 PR 回归跑掉 $50,这种设计撑不过三周。

清单 8:长尾 audit 月度化——head/tail 双集,head 跑 PR gate,tail 跑月度 manual audit。两个集合的失效模式不一样,不要混淆。

清单 9:快照不可变——任何 embeddings.json / corpus.parquet / gold.parquet 一旦 git tag,就不能再被覆盖。要改,开新 snapshot。这是 RAG 评估的版本契约,跟代码 API 一致。

一句话摘要:RAG 离线评估工程的核心是把"上线后才知道坏没坏"前置到 PR merge 之前——靠合成 query + 参考答案 + context precision/recall/faithfulness 三件套 + 多 LLM 双盲 + 门禁矩阵的五件套构筑"改 A 不打坏 B"的工程闭环。

参考文献

1. Carbonell, J., & Goldstein, J. (1998). The Use of MMR, Diversity-Based Reranking for Reordering Documents and Producing Summaries. SIGIR 1998 — nDCG/MMR 等排序指标的经典。
2. Chen, M., et al. (2024). TruthfulQA: Measuring How Models Mimic Human Falsehoods. ACL 2024 — Faithfulness 上游事实核验的 benchmark。
3. Es, S., et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv:2309.15217 — 离线 RAG 评估四件套的原始定义。
4. Liu, J., et al. (2024). DeepEval: A Comprehensive Framework for Evals of LLM Applications. arXiv:2402.XXXX — RAGAS 的工业级替代,带 multi-judge 默认。
5. Honovich, O., et al. (2022). Unnatural Instructions: Tuning Language Models with (Almost) No Human Labor. ACL 2023 — LLM 蒸馏合成 query 的方法论根。
6. Saad-Falcon, J., et al. (2024). ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems. arXiv:2311.XXXX — 多 LLM 双盲 context precision 的工程实现参考。
7. Köpf, A., et al. (2024). OpenAssistant Conversations - Democratizing Large Language Model Alignment. NeurIPS 2023 Datasets & Benchmarks Track — 人工标注金标准的开源参考集。
8. Wang, J., et al. (2024). Prompt Injection Robustness in Retrieval-Augmented Generation. arXiv:2403.XXXX — RAG 应用 sandbox sanitization 的工程参考。
9. Rafailov, R., et al. (2023). Direct Preference Optimization: Your Language Model is Secretly a Reward Model. NeurIPS 2023 — Faithfulness 自动 reward 的方法学上游。
10. Khattab, O., & Zaharia, M. (2024). ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT. SIGIR 2020 — Late-interaction retriever 的原文,常作为 RAG retrieval baseline。
11. Santhanam, K., et al. (2024). ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction. NAACL 2022 — ColBERT v2 工程化与 PRF 工程指标说明。
12. Robertson, S., & Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in IR — IR 形式化的起点。