私有 AI 升级需要验收记录

升级评审应包含两种配置：已被任务接受的配置和拟替换的配置。没有两者的证据，团队只能描述新软件，却无法解释其自身工作流程中的变更。我们的建议是在旧配置消失之前，将验收记录作为升级的一部分。

这篇八月补充文章于九月调研并发布。它提出了一种实用的评审方法；并非报告经过测量的客户部署，也不承诺特定改进。

保留旧决策

从现有配置被接受的原因开始。定位模型身份、运行时版本、测试输入和评审标准。如果该记录不存在，写下仍可验证的内容并标明缺失部分。不要凭记忆重构成功测试并将其作为观察结果呈现。

在评估候选版本期间，通过组织的正常变更流程保持旧配置可用。这可能需要记录的不仅是模型文件：文档集合、提示模板和应用设置也可能影响任务。记录与拟议变更相关的部分。

对于共享 AI Server 部署，请列出依赖该服务的应用工作流。对一个工作流有益的更改，可能需要对另一个工作流做出不同的验收决策。将服务用户视为评审边界的一部分，而非假设一次演示代表所有用户。

升级应有具体理由。团队可能寻求受支持的运行时、已知故障的修正，或特定任务上的更好结果。以可检验的形式写下该理由。“使用更新模型”是行动描述，不定义预期收益。

NIST 的 AI RMF 概述描述了在 AI 系统设计、使用和评估中对可信度的考虑。[1] 我们应用该原则，将评估与变更保持关联。先前的验收决策不应无声地成为从未参与测试的配置的证据。

还应说明必须保持可接受的内容。如果工作流导出结构化数据，导出仍需满足接收方合同。如果评审依赖源引用，引用仍需支持答案。这些条件应与期望改进并列，而非遗忘在单独的检查表中。

对旧配置和候选配置使用保留的输入集。应用相同的评审标准。记录对任务重要的输出变化，包括新出现的失败。评估者不应猜测有利结果是来自升级还是替换了难测的测试输入。

MLCommons 定义了具有特定工作负载和质量条件的推理基准。[2] 对内部评审来说，可借鉴的经验是关注条件的重要性，而非有权借用外部性能结果。应测量实际工作流程并记录其运行方式。

将正确性审核与时效分开。提前到达但遗漏必需项的响应不符合验收规则。较长的响应如果没有提供额外有用的证据，不应仅因文本更多而被视为改进。

使用包含异议记录的表格。如果两位评审对输出有不同的解读，应保留有争议的示例并解决验收标准。通过平均处理分歧可能会掩盖任务本身的歧义。

审核可以做出有限的决定：接受该候选者用于测试的工作流程，重复指定的测试，或保留现有配置。请描述支持该决定的证据及仍存在的限制。一次文档集的成功试验不应被描述为对服务器上所有应用的批准。

在部署前定义回退路径。明确谁有权做出决定以及哪些证据会触发回退。保持流程具体明确，以便在压力下执行。我们的配套文章关于模型选择记录解释了为什么在这里准确的候选人身份很重要。

该企业平台概览可以帮助构建部署讨论。升级决策仍应关联到一个具体的观察任务、其验收规则以及供他人检查的记录。