你的 RAG 评估套件在忠实度（faithfulness）方面达到了 0.89。你向知识库添加了 5,000 个新的支持文档。你重新运行相同的评估，忠实度降到了 0.79。你的团队提交了一个模型退化（model regression）工单。
其实没有任何退化。你的评估只是变成了一个谎言。
这就是 RAG 评估失效悖论：在你更新知识库的那一刻，你针对旧索引构建的评估集就会悄无声息地停止衡量其设计的初衷。大多数团队在几个月后才会发现这一点——在为幻影般的退化消耗了大量的工程周期之后——如果他们真的能发现的话。
为什么评估和索引是耦合的，而非独立的
普遍的假设是评估集是稳定的产物——你编写一次，重复运行，并长期信任这些数据。当你孤立地衡量一个模型时，这没问题。但 RAG 系统不同。针对 RAG 系统的评估包含了对知识库特定版本 的隐式假设。
当你编写一个诸如“我们的数字商品退款政策是什么？”之类的评估查询时，你不只是在测试模型是否生成了正确的答案。你还在测试：
包含退款政策的分块（chunk）是否排在检索到的前 3 个文档中
该分块是否在合适大小的上下文窗口中涵盖了正确的陈述
该分块的相似度评分是否高于你使用的阈值
没有其他排名更高的文档与该答案相矛盾
每一个条件都是索引的函数，而不只是模型的函数。改变索引，你就改变了测试——即使测试文件看起来是一模一样的。
这个问题会由于检索指标对此特别敏感而变得更加复杂。上下文召回率（Context recall）衡量的是“参考答案中有多大比例的陈述得到了检索上下文的支持”。如果你从固定长度分块（fixed-length chunking）切换到递归语义分块（recursive semantic chunking），覆盖特定文档的分块形状就会发生变化。相同的查询现在可能会检索到以不同顺序涵盖正确答案的上下文，或者将其拆分到两个分块中，而这两个分块的召回率得分都不足以计入统计。你的评估现在衡量的是在它被编写的版本中从未发生过的事情。
语料库更新破坏评估有效性的三种方式
分块策略变更
从固定长度分块切换到语义分块不仅仅是检索质量的提升——它对你的评估集来说是一个破坏性的变更。文档边界发生了偏移。以前包含政策文档第 1–3 条陈述的分块，现在可能被拆分为独立的段落，每个段落本身都不足以回答评估查询。比较分块策略的研究显示，段落分组分块（paragraph-group chunking）的 nDCG@5 约为 59%，而原始的固定长度拆分约为 40%。这 19 个点的差距是真实的，但也意味着在你更换策略的那一刻，植入到评估集中的每一个排名假设都是错误的。
大多数团队都认识到分块对检索质量很重要。但很少有人意识到，它追溯性地使旧策略下标记的所有评估都失效了。
嵌入模型升级
当你从一个嵌入模型迁移到另一个时，你得到的不只是更好的嵌入表示。你得到的是一个根本不兼容的向量空间。在模型 v1 下，查询可能会将文档 A 检索到靠前的位置，而在模型 v2 下，文档 B 可能排在第一位——这不是因为模型 v2 更差，而是因为它对语义相似性的编码方式不同。
生产环境的研究表明，仅嵌入模型的选择就能解释检索指标中超过 35 个百分点的差异。一个针对 v1 嵌入空间校准的评估，在你使用 v2 重新建立索引后，衡量的就是一个范畴错误。数据依然会产出——RAGAS 依然会计算忠实度和上下文精度（context precision）——但分母已经变了。你正在比较分母不同的分数。
增量文档添加
这是看起来最不显眼的更新，因此也最危险。你没有改变架构。你只是添加了 500 篇新的支持文章，或者更新了 300 个产品页面。评估集保持原样。指标照常运行。
实际发生的情况是：原本在某些查询中排名靠前的文档被恰好相似度得分更高的新文档所取代。原本能清晰映射到一个权威分块的查询，现在匹配到了多个包含冲突信息的候选文档。你的评估查询在编写时假设某个特定文档是权威的——现在一个新的文档变得更权威了，模型正确地根据新文档进行了回答，但你的评估却说答案是错误的，因为它预期的是旧文档'的措辞。
每月你添加文档时，语料库都会进一步偏离你评估时所假设的基准。在进行了六个月的增量更新后，你那包含 50 个查询的评估集可能是在针对一个有 40% 新内容的语料库进行测试——而你却仍将其结果视为与最初基准具有可比性。
“冻结评估”反模式 (The Frozen Eval Anti-Pattern)
“冻结评估”（Frozen Eval）这一术语描述的是一个针对实时、不断演进的索引持续运行的评估集。它看起来像正常的 CI。它按计划生成数据。但它只是不再具有实际意义了。
这种失败模式非常隐蔽，因为评估集不会宣告自己的失效。它们继续执行，产生看起来合理的指标。唯一的信号是与你所做的任何模型或基础设施更改都不相关的指标漂移——而这种信号很容易被找借口搪塞过去。
“在上周部署后，上下文召回率从 0.87 降至 0.71。可能是新的提示词模板导致的。”但其实提示词模板没问题。两天前的语料库更新替换了评估查询所依赖的文档。
运行“冻结评估”的团队会积累大量的“幻象回归”（Phantom Regressions）——即从未真实存在的性能下降——同时错过了以不同方式呈现的真实问题。评估变成了噪音，最终团队会不再信任它。他们不再修复评估方法，而是开始忽视这些数字，而这正是你最终将质量问题交付给用户的原因。
更深层的问题在于组织层面。评估集被视为开发者产物（Developer Artifacts）——提交到代码库，像测试文件一样维护。索引版本被视为基础设施——单独管理，通常根本没有正式的版本控制。没有任何流程将它们连接起来。当语料库更新时，没有人负责迁移评估集，因为没有人设计过考虑这种耦合的系统。
评估锚定：将索引与评估集同步版本化 修复方法在概念上很简单：将每个评估集视为显式固定在特定索引版本上。评估集和索引是一对匹配的组合——如果索引发生了变化，评估集要么需要针对新索引重新生成，要么你需要承认你正在运行一个过时的评估。
这意味着要为你的索引分配明确的版本。像 docs_index_prod 这样的别名应该指向一个带有版本名称的索引，例如 docs_index_v5_2026-04-01。每次评估运行都会记录它是针对哪个索引版本执行的。当你切换到 v6 时，你会确切地知道哪些评估已经过时了。
配套的规范是评估锚点检查 （Eval Anchor Check）——这是一个在任何语料库更新后运行的自动化步骤，用于标记现有的测试用例是否仍然有效。该检查会询问：对于评估集中的每个查询，当前索引检索到的 Top K 位置的文档，是否仍与编写评估时使用的索引一致？如果超过 N 个查询出现了显著的检索漂移，那么在将其用作回归门控之前，评估集需要重新生成。
这听起来在操作上很繁重。但在实践中，这只是一个 Diff。你在创建索引时快照每个评估查询的前 5 个检索文档 ID。当索引更新时，你重新运行所有评估查询的检索并比较检索指纹。显著的漂移——定义为超过 30% 的查询具有不同的 Top-1 结果——是一个信号，表明在信任针对它的新指标运行之前，你的评估集需要刷新。
随语料库迁移评估集 完整的规范流程如下：
当你准备更新语料库时，伴随新内容生成新的评估查询。新的评估集针对的是新索引。固定在旧索引上的旧评估集仍然保留，用于向后对比。
针对新索引同时运行旧的和新的评估集。结果会告诉你两件事：你的系统在针对新语料库自身的评估中表现如何（一个前瞻性的质量信号），以及旧评估集相对于基准漂移了多少（一个语料库健康信号）。如果旧的评估指标在没有任何模型更改的情况下发生了剧烈变化，那么这种差距就是语料库漂移，而不是回归。
在切换后的固定期限内保持旧索引可被查询。这为你提供了一个稳定的参考点。如果你需要了解指标变化是来自语料库还是模型，你可以针对两个索引版本运行相同的模型并进行比较。只有在你没有在部署时删除旧索引的情况下，这才是可能的。
将此构建到你的 CI/CD 流水线中。每次语料库更新都会运行锚点检查。如果检索漂移超过阈值，流水线会发出警告并触发评估再生。每次模型更新都针对冻结的索引运行，以隔离模型信号。除非你已经为组合状态生成了新的评估，否则绝不允许语料库更新和模型更新同时落地。
犯错的代价 不实施评估锚定的团队会陷入一个可预测的连锁反应：评估变得不可信，工程师不再根据评估采取行动，质量隐形下降，直到用户开始报告问题。到那时，团队是在没有任何仪表监控的情况下进行调试，因为他们已经不再信任自己的仪表了。
更微妙的代价是浪费调试周期。幻象回归——由语料库漂移而非模型行为引起的指标下降——看起来与真实的回归完全一样，直到你花费大量时间排除每一个模型和基础设施的更改。在一个每周发版的快速移动团队中，一个幻象回归周期就可能消耗资深工程师数天的时间。
最糟糕的结果是真实的回归在未被察觉的情况下发布，因为你的“冻结评估”恰好测量的是不受该问题影响的维度。如果你的评估集是为支持知识库编写的，而你添加了新的产品目录却未更新评估，那么评估将顺利通过，而目录查询则会产生幻觉。
知识库和评估集必须同步移动。将它们视为匹配的一对，对它们进行同步版本化，并设计你的更新流程，要求在任何指标被解释为有意义之前，两者必须保持同步。评估不是对模型的测试——它是对系统的测试，而知识库是系统的一半。
从今天开始该做什么 如果你现有的 RAG 系统有评估集（eval set）但没有索引版本控制：
对当前的索引版本进行快照，并为每一次评估运行打上相应的标签。哪怕只是一个时间戳也行 —— 目标是实现可追溯性。
记录每个评估查询（eval query）检索到的前 5 个文档 ID，并将它们与评估结果一起存储。这就是你的基准检索指纹。
在下一次语料库更新之前，针对新索引重新运行检索，并计算 Top-1 结果发生变化的查询比例。如果该比例超过 30%，请计划重新生成评估集。
开始显式地对索引进行版本管理。指向版本化名称的别名（Aliases）会让回滚和对比变得异常简单。
在发布流程中将语料库更新与模型部署解耦。你需要能够隔离任何指标变化的来源。
这些都不需要新的工具。它要求将索引与评估之间的关系视为头等工程问题（first-class engineering concern）—— 尽管此前许多团队都在假装它不重要，但事实一直如此。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
