目标是区间可复现
大模型的输出本身带有随机性，追求逐字复现在多数场景并不现实。可操作的目标是「区间可复现」：给定完整记录的条件，重新运行能得到统计上一致的结果——同一输入的多次输出分布相近、指标落在同一区间内。做到这一点，就需要把影响输出的变量全部显式化并归档，而不是靠记忆和聊天记录回看当时的配置。
基本信息
| 需记录字段 | 模型与版本标识、提示词与系统提示版本、采样参数、检索上下文 |
|---|---|
| 上下文快照 | 检索返回的片段内容与顺序要一并存下来 |
| 工具因素 | 工具调用参数、返回内容与时间戳 |
| 时间因素 | 后端可能更新，运行时间点必须记录 |
| 判定标准 | 统计量落在同一区间，而非输出逐字相同 |
| 适用范围 | 故障复盘、版本回归、审计留痕、合规要求 |
典型使用场景
- 故障复盘：客户投诉某次输出异常时，能重建当时的输入与参数
- 版本回归：确认差异来自模型更新还是提示词改动
- 审计留痕：回答「某条结论是如何生成的」，标明来源与条件
- 提示词迭代：每次改版都能对照上一版结果，判断是否真的更好
- 成本核对：把 token 用量与当次配置绑定，解释账单变化
- 数据回流：把复现条件与失败样本一起入库，供后续训练与评测
变量与可固定性
| 变量 | 能否固定 | 替代做法 |
|---|---|---|
| 模型标识 | 可指定版本时能固定 | 不能固定则记录实际版本字段并做快照 |
| 提示词模板 | 完全可控 | 纳入版本管理并记录版本号 |
| 采样参数 | 完全可控 | 写入配置中心，避免散落在代码里 |
| 随机种子 | 部分接口支持 | 不支持时用多次运行看分布 |
| 检索上下文 | 可控 | 保存片段快照与排序，便于重建 |
| 服务端调度 | 不可控 | 用统计量判定一致性，不看单次结果 |
| 后端更新时间 | 不可控 | 记录运行时间点，配合变更台账归因 |
| 推理硬件 | 自托管可控 | 记录部署配置与量化位宽 |
一次调用的留痕记录
一次调用的留痕记录
# 与业务结果一起落库，用于事后重建
call_id: 2026-10-17T14:22:31Z-8f21
model_alias: 供应商/模型别名
model_version: 响应中返回的版本字段
prompt_ver: v7 # 提示词模板在版本库中的标识
system_prompt_hash: 6c1d... # 系统提示指纹，防止被静默修改
params:
temperature: 0.2
top_p: 1
max_tokens: 2048
seed: 20261017 # 接口不支持时留空并注明
retrieval:
snapshot_id: ctx-9931 # 检索上下文快照，含片段顺序
chunk_count: 8
tools: [lookup_order] # 本次实际发生的工具调用
usage: {input_tokens: 1523, output_tokens: 412}
latency_ms: 2680
outcome: pass_or_fail # 业务侧判定结果，便于按条件聚合把提示词当作代码管理是复现性的基础：模板进版本库、改动走评审、运营与研发共用同一版本号。散落在脚本与配置里的提示词一旦被静默修改，所有历史对比都会失去意义。
检索增强场景的复现难点在上下文：向量库内容更新后，同样的查询会召回不同片段。保存召回快照，或在评测环境固定一份语料副本，是让长周期对比仍然成立的关键。
留痕会存下用户输入与检索内容，涉及个人信息与商业数据。设计时要明确保存期限、访问权限与脱敏规则，避免为了可复现性引入合规风险；具体留存要求以所在组织的规定与适用法规为准。