观测是“能否优化”的前提；调试要支持回放与对比。

🎯 文章目标

• 设计 LLM 应用的观测维度与数据结构
• 给出调试回放流程与工具
• 形成指标看板与报警规则

📚 背景/前置

• LLM 结果具随机性，需要“固定版本/提示”与“采样控制”
• 问题定位依赖“请求上下文/模型版本/模板/工具调用流水”

🔧 核心内容

1) 观测数据模型

• 请求：时间、用户、任务类型、prompt 哈希、模型版本、温度、tokens（in/out）
• 结果：延迟、可执行性（校验通过/失败）、错误类型
• 工具流水：入参、出参、耗时、错误、重试次数

2) 调试回放

• 取历史请求 → 固定环境（模型/提示/温度）→ 回放 → 对比差异
• 支持“替换单步工具结果”，定位问题在“模型/工具/数据”哪一层

3) 指标看板

• 模型维度：延迟、成本、拒答率、错误率
• 任务维度：通过率、平均步数、工具调用次数、最慢 5%
• 版本维度：回归/防回归，异常突增报警

💡 实战示例：请求日志结构

{
  "ts": 1739999999,
  "user": "u123",
  "task": "refund_search",
  "model": "qwen2.5-7b-instruct@2025-01-10",
  "prompt_sha": "abc123",
  "tokens": {"in": 900, "out": 200},
  "latency_ms": 1800,
  "tools": [{"name":"searchTickets","latency":300,"ok":true}],
  "error": null
}

📊 对比/取舍（速查）

• 全量日志 vs 采样：成本与隐私；建议关键任务全量，其它采样
• 页面对比 vs 离线报表：排障 vs 复盘各有侧重

🧪 踩坑与经验

• 不记录 prompt/版本哈希，问题无法复现
• 只看平均值忽略分位数（P95/P99），无法发现长尾问题
• 无对比回放，难以定位“模型 vs 工具 vs 数据”的根因

📎 参考与延伸

• 日志/指标/追踪三板斧（ELK/Prometheus/OpenTelemetry）
• Prompt 版本化与评测平台

💭 总结

• 以“数据模型 + 回放 + 指标/报警”构建可观测与可调试的 LLM 应用