追踪与回放是什么
为每次生成记录一条可复现的链路：trace 标识串起渲染、调用、校验各环节，同时记下提示版本、模型与采样参数、输入输出摘要与哈希。线上出问题时用相同输入回放定位原因。要注意模型输出本身带随机性，回放结果不同不能直接判定为回归，应比较多次结果的分布而不是单次差异。
基本信息
| 链路字段 | trace 标识、span 名称、耗时、状态 |
|---|---|
| 可复现字段 | 提示版本、模型标识、温度与 top_p 等参数 |
| 内容字段 | 输入与输出摘要、长度、哈希 |
| 隐私 | 正文按需采样，敏感字段脱敏后再落库 |
| 回放口径 | 固定参数多次重跑，比较分布与关键结论 |
典型使用场景
- 质量投诉排查：按 trace 定位到具体版本与参数，复现用户看到的问题
- 发布前后对比：同一批输入在新旧版本上回放，看差异落在哪些样本
- 耗时分析：按 span 拆解渲染、调用、校验各占多少时间
- 评测集构造：把线上真实 trace 脱敏后转入回归集
- 回归判定：对同一输入跑多次，比较通过率而不是单次输出
追踪字段示例
追踪字段示例
trace_id: 7f3a91c2
span: prompt.render / model.call / output.validate
prompt_version: summarize@1.3.0
params: {temperature: 0.2, top_p: 1.0, max_tokens: 800}
input_hash: 3c91... output_hash: a7d2...
latency_ms: {render: 12, model: 2380, validate: 8}
回放: 同参数重跑 5 次，比对通过率与关键字段，而非逐字比对字段与用途
| 字段 | 排错时的用途 | 缺失后果 |
|---|---|---|
| 提示版本 | 判断是否由发布引起 | 说不清线上跑的是哪一版 |
| 模型与参数 | 复现同一生成条件 | 回放结果不可比 |
| span 耗时 | 定位慢在哪一环 | 只能看到总耗时 |
| 输入输出哈希 | 校验回放是否同输入 | 无法确认是否同一请求 |
追踪数据里常含用户原文，落库前必须脱敏并设保留期，否则排错方便换来一份长期留存的数据风险。
回放要用同一次真实请求的原始输入，不要用手工整理的近似版本：输入差一个标点，结论就可能完全不同，排错方向也会跟着跑偏。