用户报告“昨天同一个提示词结果不同”时，团队常常只问 temperature 是多少。实际上，模型别名可能已指向新快照，系统提示词可能更新，工具返回和检索网页也会变化。没有完整记录，就无法判断是正常随机性、配置漂移还是系统缺陷。
记录输入之外的变量
一次可回放的调用至少包含模型名和快照、系统提示版本、用户输入哈希、temperature、top_p、seed（若支持）、最大输出、工具 schema、工具结果摘要、检索文档版本和调用时间。对于图像或视频任务，还应记录尺寸、参考资产、采样器和工作流版本。
seed 可以降低随机差异，但不是万能重放按钮。供应商实现、批处理顺序、模型更新和硬件推理可能仍带来变化。因此报告应区分“完全位级复现”“语义相近复现”和“无法保证复现”，不要让用户误以为一个 seed 就能锁定生产结果。
用回放样本定位差异
将高影响请求保存为最小化回放包：脱敏输入、配置、预期属性和验证方法。发现输出变化后，先固定旧模型与旧工具结果，再逐项替换变量，找出差异来自哪里。不要直接在生产流量上反复重跑，尤其是涉及写入工具或付费任务时。
通过 top-api.cc 统一多上游调用，可以记录模型、路由和请求 ID，帮助重建调用链。但完整复现仍需业务系统保存提示词、检索和工具版本，网关不应长期存放不必要的敏感正文。
评测指标
- 固定配置下多次运行的结果稳定性；
- 模型别名和快照变化后的差异；
- 工具、检索和时间数据变化的影响；
- 回放包能否在隔离环境复现关键属性；
- 哪些任务要求严格复现，哪些只要求语义一致；
- 无法复现时是否能给出变量差异说明。
可复现性不是消灭随机性，而是让随机性和变化来源可追踪。对于评测、合规、计费和自动化动作，这种可解释性比单次回答更重要。
参考资料：各模型 API 的 seed 与版本策略、评测框架的实验追踪文档。供应商未承诺固定快照时，应明确标记复现限制。
在 top-api.cc 保存调用元数据后，再用自己的配置仓库管理提示词和工具版本，能更可靠地定位输出为何改变。
Leave a Reply