LLM 应用的追踪：当什么都没崩时，该记什么日志

传统应用出问题时会崩溃。LLM 应用出问题时会返回一个自信的错误答案，并把成功计数器加 1。你标准的可观测性栈——指标、trace、异常追踪——会告诉你请求在 1.2 秒内完成，其余什么也不报告，而用户读到的是一个结构没问题、事实上却错了的回答。

值得记录的信号

至少对一部分采样流量记录完整的 Prompt 和响应文本——不是哈希——并按你领域适合的方式处理 PII。记录模型版本、temperature、top-p，以及任何 system prompt 的修订标识。把 token 数作为独立字段记录，而不是只记总成本。当一个工具被调用，把参数和工具结果都作为结构化字段记录。OpenTelemetry 这类追踪库负责传输；真正的工作是决定 span 里要塞什么。

拿到信号之后

采集只是一半的工作。另一半是把 trace 采样到一个审阅队列里——一小部分生产流量，加上所有被用户点踩或下游分类器标记的 trace。每周审阅五十条 trace，能抓到任何指标都抓不到的漂移。我见过的能稳定上线 LLM 应用的团队都在做这件事；挣扎的团队总把 trace 审阅当成”等我们有时间”再开始的事。

检测隐性失效最便宜的方式，是读自己的 trace。最贵的方式，是等用户告诉你。