文档助手可能会在检索系统进行例行修改后停止在规定时间内响应，尽管模型本身没有变化、服务运行正常，部署检查也已通过。原因在于，该修改可能会向模型发送更大的上下文，从而延长生成时间，并增加推理服务器前的请求积压；与此同时，回滚应用容器并不会恢复在其他位置发生变化的检索设置。
这一假设场景说明了运行人工智能应用时的一个实际问题：究竟真正部署了什么？在生成式应用中，仅靠模型版本无法决定系统行为；输入、预处理、提示词、索引、嵌入模型、工具契约和服务设置都可能分别发生变化。
明确发布边界
本文建议从一份经过版本控制的发布声明开始，其中保存所有经过共同测试的组件的引用。这可能包括发布标识符、应用版本、模型版本、提示词版本、索引版本、嵌入版本、分块与重排序流水线、运行设置、评估集，以及之前的版本。
这些引用应指向已保存且可检查的设置或项目，并应存储机密的引用，而不是存储其值。运行版本应覆盖令牌限制、批处理、超时和资源分配。对于调用工具的应用，还应包含工具模式和适配器的版本。
这份声明并不能保证严格意义上的可复现性：外部服务可能发生变化，生成过程可能仍然具有非确定性，而且部分提供商无法提供固定的模型快照。因此，应记录这些限制；当数据持续变化时，还应记录数据采集的时间点和索引设置。依次更新多个设置存储并不构成原子发布。
测试完整任务，而不仅是模型调用
通过 HTTP 请求并不意味着用户获得了正确答案。评估门禁应衡量产品本身的任务，例如引用可访问的来源、遵循正确的产品版本，以及在缺乏证据时避免编造指令。
本文建议使用一个经过版本控制的数据集，其中包括常规问题、以往的失败、含糊请求、缺乏证据的情况，以及试图突破权限边界的请求，同时保留一组未用于调优的数据。可以对模式正确性、工具参数、引用标识符和权限执行进行确定性检查。语义判断则需要明确的标准和人工审查；另一个模型的判断可以帮助排列案例，但不能作为参考真值。
应让该版本经过完整链路运行，从检索到生成和输出验证，然后按照任务切片检查结果，例如输入长度、语言、产品版本以及证据稀缺的情况。此外，还应在看到候选版本之前确定验收标准，包括不得发生任何权限违规、质量下降上限，以及延迟和成本预算。
按照用户感受到的方式衡量工作负载和成本
仅测试每秒请求数是不够的。测试应分布在不同的输入和输出长度、并发水平、访问突发以及冷热内存行为上。对于流式响应，应将首个令牌出现时间与后续令牌速率和完成时间分开，同时测量队列等待时间。
本文建议从全面的请求追踪开始，然后检查检索、重排序、队列、初始化和生成阶段，以及后续调用。不应把不同阶段的百分位数合并后视为一个总体百分位数；每项测量可能描述的是不同的请求。
还应在追踪记录和结构化请求日志中，将同一身份与版本关联起来，并跟踪质量、延迟分布、错误、令牌使用量和转入备用路径的比率。单个请求的成本更低，并不一定意味着完整任务的成本更低；因此，本文建议计算成功任务的成本，同时计入失败尝试，并在使用成功的替代指标时明确说明。
回滚恢复的是依赖项，而不仅是模型权重
可以让候选版本承接一小部分流量，同时保留当前版本可用，但分阶段测试要成功，就必须比较候选版本与对照版本的信号，并确保候选版本覆盖重要的负载切片。应确定决策负责人、停止条件和最低观察期，并在开始发布前执行恢复演练。
如果候选版本在原位置替换了检索索引，那么仅将请求转向旧版应用镜像是不够的。必须保留兼容版本的索引，或设计可逆的迁移，同时考虑当前的删除操作和权限撤销。还应制定正在进行的生成任务的排空或取消策略，并通过幂等性和适当的批准边界，保护发送邮件或修改记录等工具的副作用。
为什么这一方法重要？
这些建议的实际价值在于，它们将人工智能应用管理从“我们使用哪个模型？”这一问题，转变为一个更广泛的问题：能否确定生成错误答案的完整版本，然后恢复一个已知且兼容的版本？这意味着，有用的最低配置可以存在于现有代码库中，由一份发布声明、一项评估任务、一项具有代表性的负载测试、与版本关联的追踪记录，以及实际的回滚培训组成。
限制同样很明显：通过有限的测试集并不能证明不存在安全缺陷或罕见故障，而且生产反馈具有选择性，并不总是等同于答案正确性。因此，人工审查，以及明确应用、平台和数据之间接触点的责任划分，仍然是运行架构的一部分，而不是可以完全自动化的附加功能。