第10章 评估与反馈闭环

如何测量、比较并持续改进能力？

模型上线之后，最难的问题往往不是“还能不能调用”，而是“这次变化是否真的变好”。数据版本变化、提示模板变化、检索结果变化、模型量化变化、用户分布变化和工具失败，都会让质量指标发生变化。没有数据与评估 Infra，团队只能凭少量示例和主观感受发布模型，问题通常会在生产流量和长期反馈中才暴露。

本章把数据与评估看成一条生产链路：数据进入时有来源、授权、schema 和质量检查；加工时有版本、血缘、去重、采样和分片；评估时有固定回归集、任务指标、裁判校准和统计不确定性；线上运行时有请求 trace、反馈、失败样本和漂移监控；发布时由质量门禁决定是否灰度、回滚或进入人工审查。RDD、MapReduce、LakeFS、TFDV、HELM、BIG-bench、OpenAI Evals 和 RAGAS 等资料分别提供了数据容错、版本治理、统计校验和多维评估的基础 [1][2][4][7][12][13][17][18]。

本章的核心判断是：系统运行正常不等于质量正在改善。第9章关心请求是否稳定交付，第12章关心生产治理和责任闭环，第22章会专门展开 Agent Evals、Guardrails 与可观测性；本章位于它们之间，负责把数据、评估协议、judge、线上反馈和发布门禁变成可复核证据。

10.1 数据与评估平台的对象模型

从数据文件到数据产品

数据平台至少要区分 source、dataset、snapshot、split、sample、manifest、transformation、evaluation set 和 feedback set。source 是外部来源，dataset 是经过处理的逻辑集合，snapshot 是某个不可变时点，split 说明训练、验证、测试或回归用途，sample 是可追踪的样本，manifest 描述内容、统计、权限和 hash。用一个目录同时表示这些对象，会让版本、授权和回滚混在一起。

一个数据产品还要记录 owner、用途、语言、主题、敏感等级、授权范围、保留期限、质量阈值和下游消费者。训练数据、评估数据、线上反馈和人工标注拥有不同生命周期，不能都复制到同一个 bucket。LakeFS 和 Delta Lake 通过版本、提交和时间旅行等机制，为数据快照与可回滚提供了工程参考 [4][5]。

实验、评估与模型制品

experiment 表示一个假设，run 表示一次具体执行，evaluation run 表示在指定数据和运行时上得到的结果，model artifact 表示可部署制品。评估结果必须绑定 model hash、tokenizer、模板、采样参数、数据 snapshot、代码、engine、硬件和评估器版本。只保存一个分数无法证明两个分数可比。

模型注册表应区分 candidate、staged、canary、production 和 retired。评估任务产生 evidence bundle，包括原始结果、聚合指标、失败样本、置信区间、质量门禁和人工结论。MLflow 和 Weights & Biases 的实验跟踪与 artifact 管理体现了这种对象分离 [19][20]，平台可据此建立跨训练、评估和发布的引用关系。

反馈样本与隐私

线上反馈可能来自显式评分、用户重试、编辑、转人工、任务成功、工具失败、投诉和安全拦截。反馈不是天然标签：用户没有点赞可能是没有看到答案，也可能是任务已经完成；重试可能表示质量差，也可能是网络断开。平台要保存 feedback type、来源、时间、request trace、模型版本、数据等级和标注置信度。

反馈样本通常包含 prompt、输出和业务上下文，需要脱敏、访问控制、留存期限和删除机制。默认只保留 hash、长度、错误类型和结果摘要；需要人工标注时通过受控队列读取。数据与评估 Infra 应让“可用于改进”与“可以被任意工程师下载”分开，避免把线上日志变成未经治理的训练集。

10.2 数据版本、血缘与可复现

不可变 snapshot

一个评估集必须能在未来重新读到同样的样本、顺序、字段和标注。数据源可能更新、对象存储路径可能被覆盖、过滤规则可能改变，因此评估任务保存的不是路径，而是 snapshot id、manifest hash、样本 hash、schema、处理版本和排序规则。时间旅行和分支能力让团队可以在新规则上实验，而不破坏旧基线 [4][5]。

不可变 snapshot 不意味着永远保存原始内容。对于敏感或授权受限数据，可以保存受控版本、加密指针、样本 hash 和可复现的变换描述；当删除请求到来时，撤销内容访问并更新血缘。评估结果仍保留“使用过某个版本”的审计证据，但不必无限复制原文。

数据血缘图

血缘图回答数据从哪里来、经过什么变换、进入哪些训练和评估、影响哪些模型。节点可以是 source、raw snapshot、clean snapshot、dedup snapshot、token dataset、eval set、model run 和 report；边记录 transformation、代码版本、参数、执行时间和 owner。发生质量问题或数据撤回时，可以沿图反向查找到受影响的 artifact。

MapReduce 和 Spark 的分区、任务重试与 DAG 经验说明，大规模处理应让中间结果和血缘可重建 [2][3]。血缘不是为了画漂亮的图，而是为了避免“修复一个过滤规则后不知道哪些评估要重跑”。平台可以按 hash 去重相同处理，按下游门禁优先级安排重算。

Schema 与向后兼容

数据 schema 至少定义 id、输入、目标、来源、语言、标签、敏感等级、时间、版本和元数据。字段增加通常可以兼容，字段含义改变、标签定义改变、tokenizer 改变和样本边界改变则需要新主版本。TFDV 和 Great Expectations 的数据统计与断言可用于检测字段缺失、类型变化、分布漂移、空值和范围异常 [7][8]。

schema 校验要分为阻断级、警告级和观察级。输入字段缺失、标签越界和敏感等级未知通常阻断；长度分布轻微变化可以警告；新语言出现可以进入观察并由负责人决定。所有校验结果都写入 snapshot manifest，不能只在 CI 日志中出现，否则后来无法证明某次评估是否经过同一套门禁。

去重、污染与泄漏

训练与评估之间的污染会让分数虚高。精确重复可以通过 hash，近重复可以用 n-gram、MinHash 或 embedding 检测；但去重阈值过强可能删除合法变体，过弱则保留模板和改写。平台应报告重复定义、阈值、候选数量、删除数量和跨 split 的污染数量，不要只显示一个“已去重”。

评估集还可能因公开题目、模型预训练数据、人工标注泄漏和 prompt 模板而被污染。检测到污染时，不应简单继续使用旧分数；可以替换样本、增加私有集、报告污染比例或标记结果不可比较。Llama 3 和 The Pile 的数据工程经验表明，规模化语料管理本身就是模型能力和评估可信度的组成部分 [10][11]。

10.3 数据处理与质量门禁

分区、并行和重试

数据处理 DAG 应将下载、解析、规范化、去重、分词、分桶、标注和统计拆为可重试分区。一个分区失败时只重做该分区，成功分区由 manifest 固化；坏文件进入 quarantine 并记录原因。RDD 的分区与血缘思想适合解释这种容错边界 [1]，MapReduce 的 map、shuffle、reduce 也提供了大规模处理的基本分解 [2]。

重试应区分瞬时错误和确定性错误。存储超时、节点故障可以指数退避；未知编码、schema 不匹配、恶意超长样本和解析器异常应隔离并限制重试。无限重试会掩盖坏数据并消耗集群。每个分区需要最大重试、超时、错误样本上限和最终状态，控制面通过状态机保证重复完成事件幂等。

统计剖面

每个 snapshot 都应生成统计剖面：样本数、有效 token、语言、主题、长度、空值、重复率、敏感类别、标签分布、来源比例、时间分布和错误率。统计分桶要固定，避免不同版本的 histogram 无法比较。对于生成数据，还要统计输出长度、停止原因、拒答、重复 n-gram、JSON 合法率和工具参数合法率。

统计剖面有三种用途：发现坏数据、解释训练和支持评估可比性。某个版本样本数增加不代表有效 token 增加；某个语言比例下降可能是过滤变化；JSON 合法率下降可能来自模板或 tokenizer，而不是模型本身。平台保存统计的计算代码、输入 snapshot 和结果 hash，避免手工表格成为事实来源。

质量断言与人工抽样

自动断言适合结构、范围、重复和分布；人工抽样适合语义、偏见、毒性、版权和任务可用性。抽样要按来源、语言、长度、标签、风险等级和失败类型分层，不能只随机抽全局样本。人工标注界面显示必要上下文但隐藏不必要隐私，标注结果保存 disagreement、标注者、指南版本和置信度。

人工抽样也应有停止与升级规则。若某类样本出现高比例格式错误、隐私、恶意指令或标签歧义，平台暂停下游处理并通知 owner；不能把所有问题平均化后继续。标注指南要版本化，指南改变后旧标签是否可比需要明确。数据质量门禁是算法质量的上游，不应让评估团队承担所有脏数据成本。

10.4 评估集设计与指标体系

固定回归集

回归集用于检测版本变化，必须小而稳定、覆盖关键能力、具有明确标签和可重复执行。建议分为 smoke、critical、broad、safety 和 adversarial 五层。smoke 在每次提交运行，critical 作为灰度门禁，broad 适合夜间或候选发布，safety 和 adversarial 由受控流程运行。每层保存样本 hash、任务定义、期望输出或评分规则和 owner。

回归集不能长期不变。固定集会被过拟合，生产分布也会变化；可以保留不可变历史版本，同时按反馈抽样创建候选集。新样本经过污染检查、标注和门禁后才进入下一版本。报告同时展示历史基线与当前版本，说明新增、删除和改变样本的原因。

任务指标

确定性分类和结构化任务可使用 accuracy、precision、recall、F1、校准、schema validity 和 exact match；生成任务可使用 ROUGE、BLEU、BERTScore、事实性、引用准确、工具成功和人工偏好；代码任务可使用测试通过、编译、修复成功和安全扫描；对话任务还要看多轮一致、拒答和用户目标完成。没有一种指标适用于所有任务。

指标定义要写清样本权重、缺失处理、长度截断、多个答案、裁判规则和置信区间。平均分可能掩盖少数语言或高价值任务退化，建议按能力、语言、长度、风险和租户场景分层。机器学习教材关于泛化、偏差与误差分解的讨论提醒我们，测试集分数只是对目标分布的估计，不是能力的绝对真值 [24]。

质量、延迟与成本的联合指标

线上发布不能只依据离线质量，也不能只依据 P99。一个版本质量提升 1%，但 GPU 成本增加 5 倍，是否值得取决于业务；一个版本延迟降低 30%，但任务成功降低 10%，通常不应直接发布。评估报告应呈现质量、TTFT、TPOT、成功率、人工接管、token、GPU 时间和单位成功任务成本。

可以把发布门禁定义为约束集合，而不是一个加权总分。例如关键安全指标不得下降，任务成功率不得下降超过容差，p95 不能超过预算，成本增长必须有审批；其余指标用于排序和人工判断。加权总分容易隐藏严重的单项回退，约束集合更适合生产治理。

10.5 LLM-as-Judge 与人工评估

裁判模型的用途

LLM-as-judge 可以在开放式生成任务中提供较便宜的质量评分、pairwise preference、维度解释和样本筛选。G-Eval、MT-Bench 等工作展示了裁判模型在自动评估中的应用 [15][16]。但裁判不是绝对真值，可能偏好更长答案、熟悉风格、特定模型、位置靠前的答案或带有特定格式的答案。

评估平台要保存 judge model、prompt、temperature、候选顺序、schema、评分尺度和原始理由。pairwise 评估随机交换 A/B，避免位置偏差；多次采样测量方差；对高影响发布保留人工复核。裁判的输出只能支持明确的论点，例如“在这组任务上相对偏好提高”，不能泛化为“模型整体更智能”。

裁判校准

校准集由人工高一致样本、边界样本、争议样本和已知失败组成。比较裁判与人工的一致率、相关性、偏差方向和按任务分层的误差。裁判 prompt 改变、模型版本改变或语言分布改变时重新校准。中文、代码、数学、长文档和安全样本可能需要不同裁判或不同评分指南。

人工标注采用双标、盲评、随机顺序和 adjudication。标注者训练、指南版本、时间和 disagreement 写入结果。若人工一致性低，不应直接把裁判当作替代品，而要先澄清任务定义。评估 Infra 的工作不是制造一个漂亮分数，而是把不确定性和偏差显式化。

成本控制

大规模 judge 很昂贵，可以先用规则过滤和小模型筛选，再对边界样本使用强模型和人工。缓存 judge 输入与评分时必须绑定 prompt、候选 hash、评估器版本和数据等级，防止模型升级后误用旧结果。抽样评估的统计置信区间要随采样策略保存，不能把小样本结果显示成精确百分数。

10.6 RAG、工具与 Agent 的评估闭环

RAG 的组件指标

RAG 任务至少拆成检索、重排、上下文组装、生成和引用。RAGAS 等框架提供了 faithfulness、answer relevancy、context precision、context recall 等组件级指标参考 [17]。组件指标不能完全替代最终任务成功，但能帮助定位：答案错可能是没有召回、召回了但排序错、上下文太长、模型忽略证据或引用指向错误。

评估样本要保存 query、允许的证据、检索版本、chunk、score、上下文顺序、最终答案和引用。知识库更新后，旧评估结果是否可比取决于 snapshot；检索器升级后要重新计算上下文指标。线上反馈包含“答案有用”时，不能直接推断检索正确，需要抽样检查证据和引用。

工具调用与工作流

工具评估关心 schema 合法、参数正确、权限正确、执行成功、结果被正确使用、失败后恢复和副作用幂等。单次模型输出 JSON 合法并不等于任务成功；工具可能超时、返回脏数据、重复执行或需要人工审批。评估平台记录 workflow trace，把模型调用、工具调用、状态迁移和最终目标连接起来。

Agent 任务可以使用最终成功、步骤成功、重试次数、人工接管、总 token、总时延和副作用错误作为指标。测试要包含工具不可用、权限不足、部分成功、重复消息、上下文压缩和模型回退。线上回放不能直接执行真实副作用，应使用 sandbox、mock 或 dry-run，并明确哪些结果可迁移到生产。

反馈采样与主动学习

不是所有线上请求都值得进入标注池。可以按低评分、重试、长延迟、工具失败、安全拦截、模型版本、罕见语言和不确定裁判进行分层采样。主动学习优先选择能最大化信息增益或覆盖新分布的样本，而不是只收集最糟糕的案例。采样策略本身也需版本化，避免反馈集分布被不透明规则改变。

标注后的样本进入候选回归集前，要做去重、隐私、授权、标签一致和污染检查。样本被加入训练集后，再次用于评估会造成泄漏，平台用血缘图阻断这种循环或明确标记不可比。数据与评估闭环必须能回答一个失败样本从生产到标注、修复、回归和发布经历了什么。

10.7 线上评估、漂移与可观测性

线上质量信号

线上质量信号可以是用户评分、编辑距离、重试、转人工、任务完成、工具成功、引用点击、投诉和安全拦截。信号需要按模型版本、模板、租户、语言、长度、路由、adapter 和请求类型分层。延迟、错误和成本是系统信号，不能直接等同于质量，但它们与质量样本结合后可以定位体验变化。

线上指标要处理选择偏差。主动评分的用户与沉默用户不同，只有失败用户才重试，人工接管只发生在高风险任务。平台应保留抽样的未反馈请求作为对照，使用分层或加权估计，报告覆盖率和不确定性。不要把点赞率从 1% 的样本直接当作全量质量。

分布漂移

输入长度、语言、主题、来源、工具类型、用户群和时间可能发生变化。数据剖面比较当前窗口与基线窗口，检测 token 长度、embedding、类别比例、错误、拒答、cache 命中和任务成功的变化。漂移不是一定的质量问题，但会触发扩大评估、增加采样或暂停自动发布。

输出漂移包括长度、停止原因、重复、格式、引用、工具参数、拒答和安全判定。模型没有换版本时输出也可能因上游知识库、prompt、路由和用户分布变化而漂移。OpenTelemetry 和 Prometheus 可以把请求上下文与时间序列指标连接起来 [21][22]；Dapper 的追踪思想帮助定位漂移涉及的下游组件 [23]。

线上回放

回放保存 request manifest、模型版本、模板、检索结果、工具返回、采样参数和输出摘要，但默认不执行真实副作用。可以将请求送到新模型、影子 engine 或离线评估器，比较输出、格式、引用、工具计划、成本和延迟估计。回放要处理时间敏感数据、权限、过期知识和随机性，结果标记为近似而不是事实重现。

回放样本由 trace id、snapshot 和脱敏版本引用，避免复制大量敏感内容。某个版本的失败样本优先进入回归，修复后比较同一批样本；如果样本已经用于训练，报告不可比或使用新 holdout。回放系统应支持按能力、模型、错误和租户查询，成为发布控制器和事故复盘的共同数据源。

10.8 评估任务的调度与运行可靠性

评估 job 的资源模型

评估任务可能是 CPU 规则、单 GPU batch、多个模型 judge、在线 shadow、人工标注或长链路 Agent。job spec 应声明模型 artifact、数据 snapshot、并发、最大 token、超时、重试、GPU、优先级、输出路径和预算。调度器根据资源和 deadline 分配，在线回归不能被大型离线 judge 堵塞。

评估 worker 需要断点游标、分区输出、完成标记和幂等写入。一个分区失败时只重试该分区；已有结果不可被重复覆盖，除非新 run 使用新的 eval id。输出包括样本结果、错误、耗时、token、成本和 evaluator version，聚合任务只读取已提交分区。Spark、Ray 和 Kubernetes 等组件可分别承担 DAG、任务和资源执行，但平台仍要定义统一 job 状态 [3][18]。

评估缓存

评估缓存可以避免重复 tokenizer、embedding、检索、judge 或模型输出，但 key 必须包含模型 hash、数据 sample hash、模板、采样参数、engine、评估器、schema 和权限。只按 prompt 缓存会在模型或模板变化后返回旧结果。缓存命中、失效和质量差异写入报告，以免成本下降被误认为模型更快。

缓存敏感样本需要加密和租户隔离；人工标注结果的缓存还要记录指南版本。缓存可以帮助快速 smoke，但发布前应保留一部分冷跑样本，防止系统只验证缓存路径。评估平台同时报告 cached 与 uncached 的成本和延迟。

失败、超时与部分结果

评估任务遇到模型超时、GPU OOM、judge 不可用、工具 sandbox 故障、样本非法和输出超长时，结果不能简单填 0。应区分 skipped、invalid、timeout、infra_failed、model_failed 和 judged_negative。聚合器报告覆盖率、失败率和有效样本数；质量门禁在覆盖率不足时阻断，而不是把缺失样本当作通过。

部分结果可以用于诊断，但不能默认用于发布。评估 run 完成标记包含 sample count、success count、error count、coverage、数据 hash 和 evaluator hash。若只完成了容易样本，分数可能虚高。失败样本进入重试或人工队列，修复后以新 run 或明确的 retry attempt 关联。

10.9 质量门禁、实验管理与发布

门禁规则

门禁由硬约束、软阈值和人工检查组成。硬约束包括 schema 合法、关键安全指标、工具副作用、数据授权和 artifact 完整；软阈值包括质量变化、延迟、成本、覆盖率和置信区间；人工检查用于裁判争议、重要客户、少数语言和高风险案例。每条规则写明基线、容差、样本、统计方式、owner 和有效期。

门禁结果应可解释。失败报告列出退化能力、样本、模型版本、数据和运行时差异；通过报告列出覆盖范围和剩余不确定性。不能只输出一个绿色或红色状态。模型注册表只接收 evidence bundle 完整的 candidate，灰度控制器读取同一份门禁结果。

A/B、影子与 canary

A/B 比较需要随机化、分桶、实验周期、样本量和停止规则。流量分配要避免同一用户在两个版本间频繁切换；多轮对话和 Agent 任务要按 parent task 分配。影子流量不应触发真实工具副作用，工具结果可以录制或 sandbox。canary 期间同时观察质量、SLO、成本、安全和用户反馈。

统计显著不等于业务重要。一个小指标提升可能没有实际价值，一个高价值任务的少量回退可能必须阻断。报告给出效应大小、置信区间、样本覆盖和业务权重，决策记录由负责人签署。实验结束时归档数据 snapshot、配置和结论，避免无限期占用线上资源。

注册、审批与回滚

模型注册表连接训练、评估、部署和审计。artifact 进入注册表前校验 hash、来源、许可证、质量门禁、兼容矩阵和安全扫描；状态变更记录操作者、时间、原因和证据。回滚选择已验证的旧 artifact、旧模板、旧评估规则和旧路由，而不是只恢复权重。

回滚后要验证线上请求、cache、工具、计费和 trace。新版本产生的反馈不能直接归到旧版本，旧版本回滚期间的请求单独标记。发布控制器保留最近多个健康版本和恢复演练记录，避免“理论上可以回滚”在事故时失败。

10.10 数据与评估 Infra 验收

数据治理验收

随机抽取一个训练或评估 snapshot，验证来源、授权、schema、处理 DAG、分区、统计、去重、敏感等级、manifest hash 和删除流程。修改一个过滤规则，确认血缘能找到受影响的模型和评估；撤回一个数据源，确认新的评估不能继续读取而历史审计仍然可查。质量门禁要覆盖自动断言、人工抽样、失败隔离和重试。

评估可靠性验收

使用固定回归集重复运行，验证结果、随机性、judge、缓存、并发、断点和部分失败语义。故意损坏一个分区、停止一个 worker、让 judge 超时、改变模型版本和修改模板，确认系统不会把缺失或旧结果当成通过。评估报告必须包含覆盖率、失败分类、成本、耗时、质量分层和置信区间。

线上反馈闭环验收

从线上 trace 抽取一批失败样本，验证脱敏、权限、采样、标注、去重、污染检查、回归集候选、修复后评估和发布关联。执行一次漂移检测，确认输入、输出、工具和安全指标能分层；执行一次回放，确认不会触发真实副作用。反馈集和训练集交叉时，血缘系统应阻断或显式标记不可比。

交付判断

数据与评估 Infra 的交付标准不是“有一个 benchmark 脚本”，而是每个分数都有来源、版本、覆盖、方法、置信度和可回放样本；每个线上质量信号都能连接到模型、数据和请求；每个发布判断都有门禁和责任人。HELM、BIG-bench、MMLU、MT-Bench 和 G-Eval 展示了不同层次的评估方法，但平台必须根据具体任务选择和校准，而不是盲目追逐单一榜单 [12][13][14][15][16]。

对于后端工程师，可以把这套系统理解为数据仓库、CI/CD、灰度平台、日志追踪和人工审核的组合，只是对象从服务请求扩展到样本、模型输出和质量证据。下一章将把这些数据和评估能力接入 Agent/模型运行时，处理工作流状态、工具、租户和多步任务。

数据集构建的工程路径

一个可复现的数据集构建通常包含 source ingest、格式统一、内容解析、语言识别、敏感信息处理、精确去重、近似去重、质量评分、采样、分片和 manifest 提交。每一步产生输入和输出 hash、参数、软件版本、资源使用和错误摘要。Hugging Face Datasets 等工具降低了数据加载和 map 操作的门槛，但生产平台仍需补充权限、血缘、事务提交和失败重试 [9]。

构建过程采用临时输出与提交标记。分区先写到 run-specific 的临时路径，校验数量、大小、统计和 hash 后，协调者创建不可变 snapshot。下游只读取已提交 snapshot。这样上游任务失败不会产生半成品，下游也不会因为路径存在就误读不完整数据。快照提交记录 owner、时间、授权、schema 和质量结果，支持审计与回滚。

数据修复与重算

发现一批样本错误时，不应直接覆盖原数据。创建修复规则版本、选择受影响分区、生成新 snapshot，并在血缘中记录“修复前—修复后”的差异。训练或评估引用旧 snapshot 的历史结果保持不变，新 run 选择修复后的版本。修复任务需要报告删除、替换、新增和无法修复的样本数量。

修复可能改变数据分布与评估可比性。若只是纠正编码或 schema，可以与旧版本近似比较；若删除大量重复、改变标签或替换答案，应创建新的基线。评估报告显式列出 snapshot diff，发布控制器决定是否重新运行全部门禁。覆盖旧目录会让事故调查失去证据，是数据平台最危险的简化。

标注系统的状态机

人工标注任务可以经历 CREATED、ASSIGNED、IN_PROGRESS、SUBMITTED、REVIEW_REQUIRED、ADJUDICATED、ACCEPTED 和 REJECTED。每次状态迁移保存标注指南、标注者、时间、版本和理由。任务领取需要租约，避免一个标注者离线后样本永远锁住；提交需要幂等，重复提交不能生成两个标签。

标注系统要支持双标和仲裁。标签一致时提高置信度；不一致时进入 adjudication，保留两个原始判断与仲裁理由。标注指南改变时，新旧结果是否可合并由 schema 规则决定。高风险样本可以要求更高等级的标注者或多人确认，不能把所有样本用同一成本和速度处理。

标签质量与弱监督

弱标签可能来自规则、旧模型、用户行为和程序检查，成本低但噪声结构复杂。平台保存标签来源、生成器版本、置信度和是否经过人工确认。模型评估不能把弱标签当作人工真值；可以用于筛选、预标注和发现异常，再通过抽样估计噪声率。数据与评估报告披露标签来源比例，避免分数看似精确却依赖大量伪标签。

标签泄漏也需要检测。若标签字段、未来时间信息、评估答案或模板提示进入模型输入，任务分数会虚高。schema 与血缘检查输入字段，抽样人工审查，训练和评估 split 使用不同的时间或实体隔离策略。机器学习中的泛化与数据划分原则要求测试信息不能通过隐含路径泄露到训练流程 [24]。

样本级可追踪

每个样本生成稳定的 sample_id 和 content_hash，变换后保存 parent_id、transformation_id 和版本。评估结果引用 sample_id，而不是只保存数组下标；模型输出保存 output_hash、模型 hash、采样参数、错误和评分；反馈引用 request_id 和 sample_id。这样某个失败样本可以反查来源、处理规则、评估历史、线上请求和标注。

样本级追踪要控制存储与隐私。高价值或失败样本保存更完整上下文，普通样本保存摘要和 hash；敏感内容使用短期受控访问。删除请求到来时，平台根据 sample lineage 查找所有衍生快照、反馈、评估和缓存，并更新可见性。历史指标可能仍需保留，但要标注数据已撤回和结果不可重新生成。

10.11 评估统计与不确定性

采样误差

评估分数是有限样本的估计。样本量、抽样分布、分层权重和任务相关性会影响置信区间。将一组高度相似的样本当作独立样本，会低估不确定性；从线上失败样本主动采样，会高估失败率但能发现风险。报告包含 sample count、有效样本、分层比例、权重、置信区间和抽样方法。

两个版本分数差异很小时，不应马上宣布提升。可以使用配对样本比较、bootstrap、分层统计和最小实际效应；对裁判或人工标签，报告标注一致和评分方差。发布门禁明确“统计显著”和“业务重要”的区别，避免因为大样本的微小差异触发无意义回滚，也避免小样本的偶然提升进入生产。

长尾与分层

总体平均常被多数的简单样本主导。平台按语言、长度、任务、风险、数据源、用户层级、工具类型和模型路由分层，报告每层样本数、分数和变化。某个少数语言分数下降可能在总体平均中消失，却对产品公平和合规很重要；长上下文任务可能样本少但成本和投诉高。

分层规则要稳定、可版本化。改变分桶边界会改变历史图表，必须同时保留旧分桶或重新计算基线。高维分层会产生稀疏样本，平台标记低置信度而不是输出虚假的精确值。风险门禁可以对高风险层设置最低样本和最低质量要求。

指标漂移与指标博弈

团队可能为了提高某个指标改变 prompt、截断输出、过滤困难样本或增加模板化答案。平台应把指标定义、样本版本和失败样本一起审计，防止只优化可见分数。一个模型输出更短可能降低错误 token，但不一定完成任务；一个 judge 分数更高可能只是更擅长迎合裁判。

指标体系应包含结果、过程和成本：最终任务成功、关键中间步骤、引用或工具正确、重试与人工接管、延迟、token、GPU 和数据成本。不同指标冲突时由产品目标和安全边界决定，而不是让某个单一 leaderboard 决定。HELM 的多维评估思路说明，能力、效率、偏差和安全需要并列观察 [12]。

10.12 数据与评估任务的调度

优先级与资源池

评估任务可分为提交前 smoke、发布门禁、夜间 broad、线上回放、主动学习、人工标注和大规模 benchmark。不同任务的 deadline、GPU、数据、裁判和结果保留不同，应使用不同资源池或优先级。发布门禁不能被一个长时间 benchmark 阻塞，人工标注也不能被无限自动任务淹没。

调度器记录 pending reason、预计完成、使用资源和预算。任务需要 gang 资源时一次性分配，分区评估则可以弹性并行。抢占低优先级任务前保存游标与部分提交结果，恢复时只重做未完成分区。Kubernetes、Ray 和 Spark 各有资源与执行能力，评估平台通过统一 job spec 连接它们 [3][18]。

并发与限流

大量 judge 请求可能压垮模型 serving、网络和成本预算。评估调度器需要按 evaluator、模型、租户和数据 snapshot 限流，使用 token budget 而不是只限制请求数。模型服务过载时，评估任务退避或切换到已批准的低成本 judge，但必须标记 evaluator 变化并重新判断可比性。

评估对线上服务的影子流量也要限流。影子请求不应改变业务状态，不应占用生产租户预算，却会消耗 GPU 和 cache。路由器将影子流量送到隔离池，并把其影响计入容量报告。评估平台和 serving 平台共享 trace id，能说明某次回归是否造成了生产尾延迟变化。

结果存储与聚合

结果存储采用 sample result、partition result、evaluation run 和 report 四层。sample result 保存单样本输入 hash、输出 hash、指标、错误、耗时和 token；partition result 保存分区统计与完成标记；evaluation run 保存配置、覆盖和状态；report 保存聚合、图表、失败样本和结论。每层都有不可变版本，聚合可以重算但不能覆盖原始样本结果。

聚合器处理缺失、重复和重试。同一 sample_id 的多个 attempt 需要选择最终有效结果并保留历史；超时不能当负分；评估器返回非法 JSON 要作为 evaluator_failed；样本被跳过要从分母排除并报告 coverage。报告生成失败不应删除已完成的单样本结果，修复后可以重新聚合。

10.13 质量门禁的设计案例

新模型候选

新模型候选先通过 artifact、schema、安全和加载检查，再运行 smoke；通过后执行 critical 回归与目标任务评估。模型质量与旧版本做配对比较，输入输出长度和模板固定；同时测 token、GPU、TTFT、TPOT 和成本。遇到关键任务回退时自动阻断，普通任务小幅变化进入人工评审。

Prompt 或模板变更

Prompt 变更看似不改模型，却可能改变 token 长度、prefix cache、工具调用和安全边界。评估使用同一模型与同一数据，比较模板前后输入 token、格式、引用、工具成功和质量。灰度按 parent task 分桶，避免多轮任务混合版本。模板 manifest 和回滚路径与权重一样重要。

检索器或知识库变更

知识库更新先生成新的 snapshot，运行检索 recall、precision、context relevance、引用和最终任务；然后用线上历史 query 回放。若文档删除、权限变化或 chunk 策略变化，旧 cache 和评估结果按血缘失效。检索器质量提升但上下文变长，需重新评估 serving 成本和 TTFT，不能只看答案分数。

量化或 engine 变更

量化和 engine 变更固定模型与数据，比较输出差异、结构化合法、工具参数、长上下文、质量、显存和吞吐。失败样本按层、长度和任务分类，定位是精度、kernel、采样还是模板。通过后先影子，再灰度；回滚同时恢复 engine、量化、cache 和路由。评估结果绑定硬件和 driver，跨硬件不能直接复用。

10.14 反馈闭环的安全与治理

反馈进入数据集前

生产反馈先进入隔离区，完成身份去除、敏感信息检测、权限确认、样本去重、来源标记和风险分类。只有满足用途授权与留存策略的样本进入候选集。用户删除请求和数据主体请求要能沿血缘查找所有衍生副本。反馈不能因为“用户公开提交”就自动获得训练授权。

评估结果的访问控制

评估可能暴露模型弱点、敏感 prompt、客户数据、红队样本和内部工具。权限分为结果摘要、失败样本、原始输入输出、标注和 artifact 下载；每次访问审计。跨租户实验不能共享原始样本，模型供应商或外部 judge 只收到最小必要内容，并记录出站处理和删除确认。

红队与对抗集

安全红队样本要有来源、攻击类型、危害等级、预期处理、评估规则和修复状态。对抗集不能只在发布前运行一次；新模型、模板、工具、检索和路由变化都触发相关子集。修复后的模型要确认没有通过简单拒答提升分数而损失正常任务，报告安全和有用性的联合结果。

10.15 评估平台的观测与事故处理

任务级指标

评估平台指标包括等待、执行、token、GPU、judge、cache、覆盖、失败、重试、成本和结果写入。按 evaluation run、partition、evaluator、model、dataset 和 priority 聚合，避免只看一个总耗时。Prometheus 负责趋势与告警，OpenTelemetry 连接控制面、worker、模型服务和存储 [21][22]。

评估事故

典型事故包括数据 snapshot 错误、评估器版本混用、judge 偏差、缓存污染、分母计算错误、结果丢失、线上 shadow 影响生产和敏感样本泄露。事故处理先冻结报告和发布门禁，保留原始结果与 trace，确定影响范围，再重新生成修复后的 run。不能直接编辑一张分数表来“修正”历史。

事故复盘形成质量规则、数据断言、权限策略或回归样本。若一个错误样本导致线上事故，加入 critical 集并记录修复标准；若某个评估器反复超时，调整资源和预算；若缓存造成版本混用，修改 key 和门禁。评估系统自身也需要 SLO 和错误预算。

方法论总结

数据与评估 Infra 的核心不是收集更多数据或堆更多 benchmark，而是建立可追溯、可比较、可解释、可治理的证据链。DVC、LakeFS、Delta Lake 等工具提供版本和 artifact 基础；TFDV 与 Great Expectations 提供 schema 和质量；HELM、BIG-bench、MMLU、MT-Bench、G-Eval 和 RAGAS 提供不同任务层的测量；MLflow、W&B、OpenTelemetry 和 Prometheus 提供运行管理和观测 [4][5][6][7][8][12][13][14][15][16][17][19][20][21][22]。中文教材对数据划分、优化、泛化和训练/验证边界的总结，为数据快照与评估门禁提供了基础理论约束 [24][25][26]。

每次发布都要明确：用什么数据比较，指标测量什么，哪些结果可比，样本覆盖多少，不确定性多大，质量、成本和时延如何权衡，失败后如何回滚。只有把这些问题落到 manifest、状态机、报告和门禁中，评估才从研究脚本变成 Infra。后续运行时章节会消费这些评估证据，决定 Agent 工作流的路由、工具、重试和租户策略。

数据快照的事务语义

数据快照提交需要像数据库事务一样有明确的 prepare、validate 和 commit。prepare 阶段产生分区和临时 manifest，validate 阶段校验 schema、统计、权限、质量和血缘，commit 阶段写入不可变 snapshot id，并把别名从旧版本原子切换到新版本。任何阶段失败都不能让下游读取半成品。Delta Lake 的事务表与时间旅行思路可以帮助实现这种提交语义 [5]。

别名切换也要可审计。latest 不是一个足够可靠的评估输入，任务提交时解析成具体 snapshot，报告保存具体 id。若下游长时间运行，期间 latest 变化也不能影响当前任务；新任务才使用新版本。回滚只是把受控别名指向旧 snapshot，并记录原因，历史 run 仍保留原引用。

数据分支与实验比较

数据分支允许在不破坏主线的情况下尝试新的清洗规则、采样配方或标签。分支从一个已提交 snapshot 创建，变换和新增样本记录 parent，合并前执行冲突、污染、权限和质量检查。分支合并不是简单复制文件，而是生成新的不可变 snapshot。LakeFS 和 DVC 的版本化能力提供了数据分支和实验关联的工程参考 [4][6]。

实验比较要把数据差异与模型差异分开。模型 A 使用旧数据、模型 B 使用新数据时，分数变化无法归因；可以固定模型比较数据，固定数据比较模型，或用 factorial 设计拆分影响。报告列出 data diff、code diff、runtime diff 和 evaluator diff，禁止把所有变化归因于模型规模或训练方法。

测试数据的长期维护

回归集需要 owner、有效期、覆盖标签、风险等级和复审周期。样本可能因知识过时、产品流程改变、工具接口改变或授权到期而失效。定期复审样本，新增线上失败样本，删除或标记过时样本，并保留历史版本。一个永远不更新的回归集会形成过拟合的 CI，而不能代表生产质量。

每次删除样本都要说明原因，区别“样本错误”“任务废弃”“授权撤回”“模型已过拟合”和“迁移到新基准”。指标趋势图同时展示数据集版本，避免读者误以为同一分母。新旧回归集重叠部分可以用于桥接，但不应直接把分数拼接成一条连续时间序列。

评估协议与提示模板

评估协议定义输入格式、系统指令、历史消息、工具 schema、最大 token、采样、超时、重试和评分。模板变化会改变模型看到的 token、角色和约束，必须作为协议版本。评估器执行时打印最终 prompt 的 hash、token 数、模板版本和模型版本，必要时保存脱敏后的渲染结果。

协议还规定错误处理。模型超时、输出截断、非法 JSON、工具失败、judge 失败和数据缺失分别是什么状态，是否重试，是否进入分母。不同协议混用会让“失败率”没有意义。评估平台提供统一协议 SDK，减少各团队手写脚本造成的行为差异。

生成评估的可重复性

temperature 大于零时生成具有随机性，服务端可能使用不同 kernel、batch 或随机数路径。评估可以固定 seed、运行多次取均值、使用 deterministic decoding 或保存完整输出；每种方式有不同成本和代表性。报告保存 sampling、seed、重复次数、输出长度和失败样本，不能只保存最终平均分。

对话和 Agent 任务还存在外部状态随机性：检索索引变化、工具返回变化、时间、权限和用户上下文。回放使用 snapshot、sandbox 和录制结果，必要时标记与生产有差异。可重复性不是强求所有系统位级一致，而是让差异来源可解释，并在质量门限中设置合理容差。

评估结果的可信等级

可以给评估结果分为 exploratory、diagnostic、regression、release-gate 和 audited 五级。探索结果快速、样本小、不能用于发布；诊断结果定位问题；回归结果固定集可比较；发布门禁经过完整配置和覆盖检查；审计结果额外包含人工签署与数据授权。结果对象带有等级和允许用途，防止一个草稿分数被误用为生产证据。

可信等级由覆盖率、评估器校准、样本版本、运行时完整性、人工复核和统计置信度决定。等级不是评价模型好坏，而是评价证据强弱。发布控制器要求足够等级的 evidence bundle，研究 dashboard 可以显示低等级结果但明确标识。

线上反馈的去偏

线上反馈存在曝光、选择和幸存者偏差。只有展示给用户的结果才可能获得评分；只有不满意的用户可能重试；完成任务的用户可能不再反馈。平台可使用随机抽样、分层采样、对照版本、隐式行为与显式评分组合，报告反馈覆盖率和采样策略。不要把低反馈量的高分当作稳定提升。

对不同用户群和业务场景分别估计质量，避免大租户或高频场景淹没少数重要场景。线上实验按 parent task 固定版本，避免一次 Agent 工作流跨多个模型版本。反馈数据入库前保存原始信号、解释和时间，后续重算可以更换聚合方法而不丢失基础事实。

训练数据与评估数据的边界

反馈样本可能同时被用于训练和评估。平台根据 sample lineage 和用途标签阻止同一个样本进入训练后又进入测试，或把结果标记为污染。时间切分、实体切分和文档切分有不同泄漏边界：同一用户、同一文档和同一模板的改写可能仍然高度相关。数据分割规则写入 snapshot manifest，不能只写在实验笔记里。

训练集扩大后，旧 benchmark 可能已被间接看到。平台定期创建私有 holdout 或新鲜时间窗口，并估计污染风险。公开榜单用于横向参考，生产门禁应更多依赖任务相关、私有、受控和可审计的评估集。中文机器学习教材对训练、验证和测试边界的基本原则仍然适用，只是大模型的规模使泄漏检测更复杂 [24]。

评估平台的容量与成本

评估 job 也需要容量模型。每个样本的输入、输出、judge、检索、工具和重复次数决定 token 与 GPU；发布高峰可能同时触发多个模型候选、多个数据集和多个 judge。调度器按 deadline、priority、token budget 和 GPU 资源排队，预留发布容量，限制低优先级 benchmark。评估成本归因到 experiment、team、model 和 dataset，避免免费评估无限增长。

评估缓存可以降低成本，但不能改变证据语义。缓存 key 包括所有输入、模型、模板、评估器、数据、运行时和权限；任何变化失效。报告分别显示 cached 与 uncached，发布门禁保留冷跑样本。缓存命中率很高但结果仍错误时，系统可能把错误长期固化，因此保留随机冷样本很重要。

评估平台的发布接口

发布控制器通过 API 提交 evaluation request，指定 candidate artifact、baseline、dataset snapshot、protocol、metrics、threshold、deadline 和 evidence level。评估平台返回 run id，异步上报状态、分区、结果和最终 report。控制器不读取内部数据库，避免与实现耦合；评估平台也不直接修改生产路由，只提供可验证证据。

接口包含 idempotency key 和 report hash。重复提交返回同一个 run 或明确创建新 attempt；部分结果不覆盖已提交结果；报告生成后不可变，修订通过新版本关联旧报告。这样发布、回滚和审计可以使用稳定引用，避免“页面上分数变了但不知道为什么”。

评估失败的降级策略

当 judge 模型不可用时，可以暂停、切换已批准的 judge、使用规则子集或转人工，但必须改变 evidence level，并重新判断门禁。不能为了按时发布而静默跳过困难样本。数据存储故障时可以使用镜像 snapshot，记录 replica；模型服务故障时可重试分区，记录重复成本。所有降级写入 run metadata。

如果评估覆盖不足，结果状态应为 INCOMPLETE 而不是 PASSED。发布控制器默认阻断 incomplete；人工可以在明确风险和补救计划下批准，并记录期限。错误预算和发布节奏不能成为降低质量证据的理由，最多决定是否推迟或选择安全的旧版本。

小结：证据先行

数据与评估平台的核心对象是可追踪的样本、可复现的 snapshot、可解释的指标和不可变的 evidence bundle。数据版本解决“用的是什么”，评估协议解决“怎么测的”，统计与裁判校准解决“分数多可靠”，线上反馈解决“生产是否改变”，质量门禁解决“是否允许发布”。DVC、TFDV、HELM、G-Eval、RAGAS 和实验跟踪工具可以提供组件，但平台仍需自己定义状态、权限、血缘和回滚。

对于后端工程师，最重要的迁移思维是把评估当作生产流水线：有任务、有队列、有幂等、有事务提交、有重试、有状态、有权限、有监控和有审计。只不过它的结果不是一个二进制包，而是一份决定模型能否进入生产的证据。下一章运行时 Infra 将依赖这份证据来控制工作流和租户，而不是在运行时临时猜测模型是否可靠。

数据质量事件

数据质量事件应具有独立的类型和生命周期，例如 SCHEMA_BREAK、DISTRIBUTION_SHIFT、DUPLICATE_SPIKE、LABEL_CONFLICT、PRIVACY_FINDING、SOURCE_EXPIRED 和 SNAPSHOT_INCOMPLETE。事件包含 source、snapshot、partition、rule、severity、owner、发现时间和处置状态。发现质量问题时，平台可以阻断新 snapshot、冻结相关评估、通知 owner，并保留历史可读性。

事件处置可能是重跑分区、修改规则、补充标注、隔离来源、撤回 snapshot 或接受风险。每个动作产生新版本和审计记录，不能直接把事件标记为 resolved 而不说明证据。数据质量 dashboard 显示开放事件、平均处理时间、重复发生率和受影响模型，帮助团队把数据问题纳入工程计划。

评估器的依赖治理

评估器本身可能依赖 tokenizer、模型、检索器、规则库、外部 API 和人工指南。每个 evaluator artifact 有版本、输入 schema、输出 schema、随机性、资源需求、适用任务和已知偏差。升级评估器要用历史样本重跑，报告分数变化是模型变化还是 evaluator 变化。评估器不可用或输出异常时，任务进入 evaluator_failed，不应自动给负分或正分。

裁判模型的版本也要纳入模型注册。若 judge 变强或 prompt 改变，历史分数可能不可比；可以保留旧 judge 做桥接，或在报告中说明迁移。高风险门禁使用人工复核和独立规则，避免候选模型和 judge 共享相同偏差。评估平台的可信度取决于对评估器自身的治理。

回归样本的优先级

回归集样本可以按风险、业务价值、历史失败、频率、代表性和修复状态排序。高风险安全样本、核心交易任务和最近事故样本每次提交运行；低频探索样本按夜间任务运行；大规模 benchmark 用于周期性趋势。优先级写在 sample metadata 中，发布控制器根据门禁级别选择子集。

新增样本要经过候选、复核、接受和退役状态。失败样本直接加入生产门禁可能造成过拟合，先确认问题可复现、期望行为明确、数据可授权、没有与训练泄漏，再决定放入哪一层。样本的修复状态也进入 dashboard，避免团队只追求增加样本数量而不处理模糊定义。

在线与离线指标的校准

离线指标与线上指标之间需要桥接集。桥接集包含过去生产请求的脱敏、分层和标注样本，比较离线分数、线上反馈、任务成功和人工判断。若某个离线指标长期与线上成功无关，就降低它在门禁中的权重或重新定义；若线上出现新的失败模式，就加入候选回归集。桥接不是一次性相关分析，而是持续校准。

线上指标受流量、用户、时间和下游系统影响，离线指标受 snapshot、协议和采样影响。报告分别标记 measurement layer，避免把两个数字放进同一个总分。模型发布时可以要求离线硬约束和线上 canary 约束都满足，任何一层失败都触发暂停或人工判断。

数据处理的可观测性

数据 job 的 metrics 包括输入分区数、输出分区数、样本数、token、处理速率、等待、重试、坏样本、内存、存储和成本；trace 连接 source、transform、partition 和 snapshot commit；日志记录错误样本 hash、异常类型、规则版本和处置。Prometheus 和 OpenTelemetry 提供采集与关联的基础 [21][22]，平台应补充数据语义字段。

可观测性也要保护数据。metric label 不放原文、用户 id 或自由文本；trace event 使用 sample hash 与敏感等级；错误日志按规则脱敏。权限不同的用户看到不同粒度，质量 owner 可以看聚合和受控样本，平台 operator 可以看资源和错误但不一定看内容。观测系统本身不能成为数据泄漏路径。

成本与质量的决策表

发布评审可以使用质量—成本—时延决策表。若质量提升、成本降低、延迟不变，自动通过；若质量提升但成本显著增加，要求业务审批；若质量不变但成本降低，优先灰度；若质量下降但时延降低，只在低风险场景评估；若安全或关键任务下降，无论成本和延迟如何都阻断。表格不是替代判断，而是把预先接受的取舍公开化。

成本包括数据处理、标注、评估、judge、serving、存储和人工。某个模型在 benchmark 上更便宜，但如果失败导致更多重试和人工，单位成功任务成本可能更高。报告用同一场景比较成功任务、token、GPU、标注和人工时间，避免只看云账单的一部分。预算超限触发停止或降级，不应让评估无限运行。

评估平台的灾备

数据 snapshot、manifest、评估结果和报告需要备份与恢复演练。原始敏感内容可能不可复制，但 manifest、hash、授权和报告至少应有跨故障域的可恢复副本。评估 worker 可以重建，结果不可重算或成本极高的 evidence bundle 需要更高保留等级。灾备测试验证恢复后的 hash、权限、版本和报告可读。

发布事故时，平台需要能读取最后一个已批准报告、模型 artifact、数据 snapshot 和门禁配置，即使评估集群不可用。否则无法判断是否回滚。灾备不等于把所有内容复制到所有区域，依然要遵守数据驻留与删除策略。恢复路径写入 runbook，并定期演练。

交付的验收问答

验收人员可以抽查一个生产模型并追问：它由哪个训练 run 产生？使用哪个数据 snapshot？该 snapshot 如何校验？哪些评估集决定发布？评分方法和 judge 版本是什么？有多少样本失败或跳过？线上反馈如何采样？最近一次漂移是什么？回滚到上一版本需要哪些 artifact？如果这些问题不能从注册表、manifest、报告和 trace 中回答，说明评估 Infra 仍依赖个人记忆。

再抽查一个失败样本，确认可以从 request trace 找到模型和模板，从模型找到 evaluation run，从 evaluation run 找到样本与数据血缘，从样本找到标注和修复，从修复找到新的回归结果。这个闭环比一张总分表更能证明系统真实可运营，也能为后续运行时的重试、路由和人工接管提供可靠依据。

当数据、评估、发布和反馈都使用不可变版本与统一 id 时，平台就能把一次线上退化变成一个可处理的工程事件：冻结受影响版本，定位差异，重放样本，修复数据或模型，运行门禁，灰度验证，再更新生产路由。整个过程不依赖“感觉变好了”，而依赖可复核证据；这正是数据与评估 Infra 对模型开发效率和生产可靠性的核心贡献。

评估结果的价值也不在于制造排行榜，而在于帮助团队做出可承担的选择。它需要告诉我们哪个能力改善、哪个能力退化、代价是多少、证据有多强、风险由谁接受，以及下一次需要补什么数据。只有做到这一点，评估才真正参与系统设计，而不是发布前的装饰步骤。

因此，章节交付时应同时交付数据 manifest、来源—论点映射、评估协议、固定回归集、质量报告、失败样本、门禁结果和发布记录。任何一个环节缺失，都可能让后续团队无法复核分数、无法定位退化或无法安全回滚。完整的证据链比单个更高的评估数字更值得长期维护。

平台还要定期复查来源和评估器：链接是否仍然有效，文献是否真的支撑当前论点，数据授权是否仍然成立，裁判偏差是否发生变化，指标是否仍与业务目标相关。来源池不是一次性工作，而是随着模型、数据和运行时演进的长期资产。

当来源、数据、论点、指标和发布结果能够相互引用时，评估平台就成为模型系统的知识账本，而不只是一个跑分服务。

它让团队能够区分事实、测量、推断和决策：来源提供事实，评估提供测量，平台结合任务作出推断，负责人基于风险作出发布决策。四者被明确分开，后续复盘才不会把一次实验结果误写成普遍规律。

在生产系统中，这种区分还可以降低协作成本：算法团队读取质量与样本，平台团队读取资源与任务，业务团队读取成功与成本，安全团队读取风险与审计，而所有团队引用同一个版本化报告。

这使评估从一次性的模型验收，变成贯穿数据、开发、发布和运营的持续基础设施。

章节完成时，来源核验、论点映射、数据快照、评估协议、门禁规则和最终报告应作为同一交付包保存，确保读者能够从结论回到证据，再从证据回到可执行的工程动作。

这也是本章的最终验收条件。

并且应在后续数据与模型变更时重新核验。

复核结果进入新的证据包。

证据包保留版本和责任人。

历史报告保持只读。

修订通过新版本关联。

新的版本必须重新执行相关门禁。

门禁失败时保持旧版本服务。

旧版本继续使用已验证证据。

新版本重新生成完整报告。

报告保存样本覆盖和失败原因。

失败样本进入后续回归。

回归结果再反馈发布门禁。

门禁状态随版本归档。

参考资料

[1] Zaharia, M., et al. Resilient Distributed Datasets. NSDI, 2012. https://www.usenix.org/legacy/events/nsdi12/tech/full_papers/Zaharia_new.pdf 访问日期：2026-09-22

[2] Dean, J., & Ghemawat, S. MapReduce: Simplified Data Processing on Large Clusters. OSDI, 2004. https://research.google/pubs/mapreduce-simplified-data-processing-on-large-clusters/ 访问日期：2026-09-22

[3] Apache Spark. Spark Documentation. https://spark.apache.org/docs/latest/ 访问日期：2026-09-22

[4] lakeFS. lakeFS Documentation. https://docs.lakefs.io/ 访问日期：2026-09-22

[5] Delta Lake. Delta Lake Documentation. https://delta.io/ 访问日期：2026-09-22

[6] DVC. DVC Documentation. https://dvc.org/doc 访问日期：2026-09-22

[7] TensorFlow. TensorFlow Data Validation. https://www.tensorflow.org/tfx/guide/tfdv 访问日期：2026-09-22

[8] Great Expectations. Documentation. https://docs.greatexpectations.io/ 访问日期：2026-09-22

[9] Hugging Face. Datasets Documentation. https://huggingface.co/docs/datasets/ 访问日期：2026-09-22

[10] Gao, L., et al. The Pile. 2020. https://arxiv.org/abs/2101.00027 访问日期：2026-09-22

[11] Dubey, A., et al. The Llama 3 Herd of Models. 2024. https://arxiv.org/abs/2407.21783 访问日期：2026-09-22

[12] Liang, P., et al. Holistic Evaluation of Language Models (HELM). 2022. https://arxiv.org/abs/2211.09110 访问日期：2026-09-22

[13] Srivastava, A., et al. BIG-bench. 2022. https://arxiv.org/abs/2206.04615 访问日期：2026-09-22

[14] Hendrycks, D., et al. Measuring Massive Multitask Language Understanding. 2020. https://arxiv.org/abs/2009.03300 访问日期：2026-09-22

[15] Liu, Y., et al. G-Eval. 2023. https://arxiv.org/abs/2303.16634 访问日期：2026-09-22

[16] Zheng, L., et al. Judging LLM-as-a-Judge with MT-Bench. 2023. https://arxiv.org/abs/2306.05685 访问日期：2026-09-22

[17] RAGAS. Documentation. https://docs.ragas.io/ 访问日期：2026-09-22

[18] OpenAI. OpenAI Evals. https://github.com/openai/evals 访问日期：2026-09-22

[19] MLflow. ML Tracking Documentation. https://mlflow.org/docs/latest/ml/tracking/ 访问日期：2026-09-22

[20] Weights & Biases. Documentation. https://docs.wandb.ai/ 访问日期：2026-09-22

[21] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-09-22

[22] OpenTelemetry Authors. OpenTelemetry Documentation. https://opentelemetry.io/docs/ 访问日期：2026-09-22

[23] Sigelman, B. H., et al. Dapper. 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-09-22

[24] 周志华：《机器学习》。清华大学出版社，2016。https://cs.nju.edu.cn/zhouzh/zhouzh.files/publication/MLbook2016.htm 访问日期：2026-09-22

[25] 邱锡鹏：《神经网络与深度学习》。https://nndl.github.io/ 访问日期：2026-09-22

[26] 张量网络与深度学习：《动手学深度学习》。https://zh.d2l.ai/ 访问日期：2026-09-22