跳到主要内容

观测、审计、回放，为什么是 AI 系统的基础设施

· 阅读需 4 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-20 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多 AI 系统前期都把预算优先给了模型、Prompt、工作流和界面，等到线上开始出问题，团队才发现真正缺的是另外三样东西：

  • 观测
  • 审计
  • 回放

这三件事听起来像“运维附属项”，但我现在越来越把它们看成 AI 系统的基础设施。因为没有它们，系统一旦出错，你几乎无法回答最关键的几个问题：

  • 这次到底发生了什么
  • 为什么会发生
  • 影响了哪些请求
  • 新版本和旧版本比，差异到底在哪

普通系统没有日志很痛苦，AI 系统没有这三层则会很快失去可治理性。

为什么 AI 系统特别需要这三层​

因为它的错误通常不像普通接口那样“明确炸掉”，而更像：

  • 回答变差了
  • 结构化字段偶发错位
  • 某类请求突然变贵
  • fallback 比例变高
  • 某个工作流开始更容易半路失败

这些问题往往没有一条单独的异常栈能完整解释。

观测解决的是“现在系统长什么样”​

我这里说的观测，不只是打几条日志，而是让团队能看到：

  • 请求量
  • 成功率
  • 超时率
  • fallback 比例
  • 模型分布
  • 平均 token
  • 成本变化

也就是把系统的运行状态变成可读的。

没有这层，你甚至不知道问题到底是局部异常，还是系统性漂移。

审计解决的是“这次决策是谁、基于什么做的”​

AI 系统一旦开始参与：

  • 审核
  • 路由
  • 工单建议
  • 自动发布

就必须能回答责任问题。
这时只靠普通日志是不够的，还需要审计记录：

  • 当时用了哪个模型版本
  • 输入是什么
  • 输出是什么
  • 是否有人工批准
  • 哪个节点执行了副作用

审计不是为了“事后看热闹”，而是为了当结果有争议时，系统能给出可追责证据。

回放解决的是“能不能把问题再放一次”​

这是我觉得最容易被低估的一层。
很多团队能看到错误，也能知道版本，但就是没法稳定复现。结果每次排查都像猜谜。

回放的价值在于，它能让你拿着历史请求重新比较：

  • 老版本 vs 新版本
  • 原始路由 vs 新路由
  • 原始 Prompt vs 修改后 Prompt

这会直接改变排查效率。

这三层最好长什么样​

我现在比较理想的请求记录会至少保留：

{
  "requestId": "req_123",
  "route": "content_review",
  "model": "model-a",
  "promptVersion": "v17",
  "inputDigest": "sha256:...",
  "retrievalDocIds": ["doc_1", "doc_8"],
  "outputSnapshot": {
    "riskLevel": "high",
    "shouldEscalate": true
  },
  "humanDecision": "approved",
  "costUsd": 0.023,
  "latencyMs": 1840
}

真正重要的不是字段名，而是这条记录能同时服务三件事：

  • 观测统计
  • 审计追溯
  • 回放重跑

一个常见误解：日志多不等于可观测​

很多系统也会输出很多内容，但问题在于它们只是“很多字”，不是“可分析的字段”。

例如你记录了一大段文本，却没有：

  • requestId
  • 模型版本
  • promptVersion
  • 路由结果
  • fallback 原因

那后面依然很难聚合、回放和比较。

所以我现在更在意结构化事件，而不是堆更多自由文本日志。

为什么这三层应该在前期就做​

因为越往后补，代价越高。
等系统上线一段时间才发现没有这些能力，往往意味着你要回头补：

  • 事件模型
  • 日志字段
  • 数据脱敏
  • 请求关联
  • 存储和留存策略

这些都不是一句“多记点日志”就能补齐的。

总结​

观测、审计、回放，为什么是 AI 系统的基础设施？因为它们决定了系统出了问题之后，团队能不能看见、能不能解释、能不能重现。

对 AI 系统来说，真正可持续的不是“先跑起来再说”，而是从一开始就让关键行为可追踪、关键决策可审计、关键请求可回放。只有这样，系统才不只是会工作，而是能被长期维护和持续改进。