为什么你的应用日志无法还原 AI 决策
一个 AI 系统将某份求职申请标记为低优先级。候选人提出申诉。法务部门向工程团队询问："请展示模型当时看到的确切内容、检索的文档、触发的策略规则以及生成的置信度分数。"工程师打开日志，发现的是：时间戳、HTTP 200、响应体，以及延迟指标。其余的信息已经消失。
这不是日志记录的失败。按照所有传统标准，日志是完整的。问题在于，应用日志从来就不是为记录推理过程而设计的——而 AI 系统不只是在执行代码，它们做出的是依赖上下文的概率性决策，只有给定决策时刻存在的完整输入上下文，才能被理解。
你的 SRE 团队所监控的内容，与 AI 审计真正需要的内容之间，存在巨大的鸿沟。随着 AI 系统承担越来越多后果性的工作，这道鸿沟还在不断扩大，而且几乎从不被讨论，直到监管机构或诉讼使其变得紧迫。
核心错位：执行 vs. 推理
传统应用日志回答一个特定的问题：系统里发生了什么？它们捕获函数调用、状态转换、错误码、响应时间。对于确定性系统，这已经足够——给定日志，你可以重现完全相同的执行路径。
AI 系统从三个方面打破了这一模式。
首先，它们依赖上下文。模型的输出是其上下文窗口中所有内容的函数：系统提示、对话历史、检索文档、工具输出，以及用户查询的确切措辞。只捕获输入和输出的日志完全跳过了检索文档——恰恰是模型进行推理的材料。
其次，它们是非确定性的。相同的输入，在不同温度或不同模型版本下发送两次，会产生不同的输出。系统提示的 A 版本和 B 版本可能产生孤立看来相似的输出，但追溯到完全不同的推理路径。一条捕获了响应文本但未记录系统提示版本的日志条目，六个月后将无法解释。
第三，它们做出隐式决策。一个在三个工具之间选择的智能体，或者一个 RAG 管道在十个检索块中排名并丢弃八个，在选择了错误选项时不会触发任何错误。错误路径和正确路径在 HTTP 状态码和延迟上看起来完全相同。只有通过检查中间推理——考虑了哪个工具以及为什么，哪个文档在检索中得分最高以及基于什么查询——你才能区分它们。
应用日志实际捕获的内容
以下是一个完善监控的 AI 服务在其标准日志管道中通常输出的内容：
- 请求时间戳和追踪 ID
- 用户 ID 和会话 ID
- 输入文本（用户的消息）
- 模 型响应文本
- Token 数量（提示词和补全）
- 延迟和成本
- HTTP 状态码
这是出色的遥测数据。它告诉你系统在运行、哪些用户处于活跃状态、成本是多少，以及何时出错。对于管理系统正常运行时间的 SRE 团队来说，这已经足够。
对于还原为什么做出某个特定决策，它几乎没有用。当时激活的系统提示版本缺失。检索文档——模型引用或产生幻觉的事实材料——缺失。置信度分数缺失。智能体运行的工具选择历史缺失。策略评估结果（内容过滤器触发了吗？基于什么规则？）缺失。
这在实践中意味着：当出现问题时，你可以确认问题确实发生了（用户在抱怨），但你无法还原产生错误输出的上下文。每次事件调查都要从零开始。
标准日志中缺失的五个字段类别
能够支持调试和合规审查的 AI 审计记录，需要标准日志管道不收集的五类信息。
系统提示版本。 系统提示是 LLM 的主要行为规范。当它改变时，模型的行为也会改变——有时是细微的，有时是剧烈的。如果审计记录中没有版本固定，你就无法知道回归是因为模型变了、提示词变了，还是检索语料库变了。把系统提示当作构建产物来对待：对其进行版本控制，并记录每次请求时激活的是哪个版本。
带评分的检索上下文。 对于任何 RAG 系统，模型看到的文档与模型本身同样重要。幻觉和正确答案在输出层面可能无法区分——只有通过检查相关事实是否在检索上下文中，才能分辨出来。审计记录需要检索到的确切文档 ID、对其进行排名的相关性评分、用于检索的查询，以及检索索引的版本。没有这些，调试幻觉就是在瞎猜。
中间决策和工具调用。 一个选择工具 A 而非工具 B 的智能体，或者决定退出循环的智能体，正在做出不会出现在输入或输出中的决策。这些中间步骤——连同它们的输入、输出和任何失败模式——需要成为审计追踪的一部分。当工具调用静默失败而智能体回退到默认路径时，那个回退就是你需要还原的决策。
策略评估结果。 如果你的系统运行护栏、安全分类器或合规检查，审计记录需要捕获评估了哪些策略、哪些通过了，以及哪些触发了。一个通过审查的响应不能证明没有策略触发——它只能证明没有任何内容被阻止。在审计偏见或安全违规时，这一区别至关重要。
推理时的模型配置。 温度、top-p、最大 token 数，以及确切的模型标识符（包括版本），需要成为记录的一部分。由 Claude Sonnet 4 在温度 0.3 下处理的请求，与在温度 0.9 下处理的相同请求，或者由六个月后部署的量化版本处理的请求，是完全不同的决策过程。
生产中的还原问题
这些字段的缺失，造成了一类在工程师真正遇到之前难以描述的调试问题，因为它们在变得无法解决之前，看起来就像普通的调试问题。
想象一个基于 RAG 的客服系统开始给出关于定价的细微错误答案。输出在语法上是正确的，语气是自 信的。日志中没有错误。Token 数量看起来正常。问题在于，有人在三周前更新了检索语料库中的定价文档，但没有更新其中一个边缘案例部分。对于恰好检索到该部分的查询，模型正在基于过时数据进行推理。
要找到这个问题，你需要确定受影响查询使用了哪些具体的检索文档。如果你的日志不包含检索文档 ID 和检索评分，你就无法建立这种关联。你将花费几天时间测试假设，而不是几个小时阅读审计追踪。
问题在智能体中进一步复杂化。一个执行 15 步工作流的自主智能体有 15 个决策点，每一个都可能是下游错误的来源。应用日志会显示最终输出和一系列 HTTP 调用。它们不会告诉你，第 7 步的哪个工具选择将智能体引上了在第 14 步产生错误结果的路径。没有中间决策日志，你是在调试一个碰巧在最后发出了一个产物的黑盒。
即将到来的合规压力
大多数工程团队将 AI 审计日志视为未来的问题。EU AI Act 正在使其成为当下的问题。
根据第 12 条和第 19 条，高风险 AI 系统——包括用于就业、教育、信贷和其他后果性领域的 AI——必须维护支持人工监督的自动日志。日志必须足以还原任何给定输出的系统决策。"高风险"是由用例定义的，而非技术复杂性；一个小团队的招聘筛选工具符合条件，不是因为它强大，而是因为它在决定什么。
金融服务监管机构正在朝同一方向发展。DORA 要求明确涵盖 AI 的 ICT 风险管理。NYDFS Part 500 将 AI 系统纳入其网络安全项目要求。FINOS AI 治理框架规定，智能体必须支持决策审计和可解释性，以应对监管检查。这些框架不描述实现细节——它们描述结果：你必须能够按需还原任何 AI 决策。
GDPR 以一种产生困难工程约束的方式与此相交。你的审计日志可能包含个人数据，这意味着它们受数据最小化和保留期限的约束。解决方案是架构层面的：使用匿名标识符和关联 ID 存储日志，这些 ID 只能在授权审计期间与个人数据连接，个人数据方面受其自己的保留计划约束。这需要从一开始就在设计日志系统时考虑 GDPR 合规，而不是事后补救。
可观测性平台提供的与你需要构建的
一批工具——LangSmith、Arize Phoenix、Helicone、Langfuse、Weights & Biases——已经涌现出来，专门解决应用日志与 AI 可观测性之间的差距。它们值得了解，因为它们定义了生态系统目前提供的上限，以及差距仍然存在的地方。
LangSmith 擅长追踪多步 LangChain 管道，在结构化追踪中捕获调用、检索和工具调用的完整链条。Arize Phoenix 增加了 OpenTelemetry 原生分布式追踪和漂移监控。Helicone 提供网关层拦截，因此你无需为应用代码添加监控就能捕获每个模型调用。所有这些工具都比标准日志提供更好的可见性。
但它们都无法开箱即用地满足合规要求。它们捕获的是追踪，而非审计记录。这一区别很重要：追踪告诉你系统中发生了什么。审计记录是满足合规要求的不可变、已签名的产物。审计记录需要是仅追加的，与特定身份相关联，并按照定义的 计划保留，该计划兼顾监管最低要求和 GDPR 最长期限。
这在实践中意味着：使用可观测性平台进行调试和监控。为需要满足监管机构的记录构建单独的、以合规为导向的审计日志系统。这两个系统有不同的持久性、访问控制和保留要求。
构建最小可行 AI 审计记录
对于做出后果性决策的系统，最小可行 AI 审计记录有七个组成部分：将所有字段绑定在一起的唯一追踪 ID；确切的用户输入；系统提示版本（哈希或标签，而非完整文本）；带文档 ID 和相关性评分的检索上下文；包含版本的模型标识符；输出；以及任何中间工具调用或策略评估结果。
这不是每次请求的大量数据。昂贵的部分是检索上下文，每次调用可能达到几千字节。对于高流量系统，选择性日志记录——捕获随机样本的完整记录，加上所有标记或异常请求——在不为每次请求存储完整语料库的情况下提供覆盖。
最重要的结构纪律是版本链接。每个引用外部产物的字段——系统提示、检索索引、模型——都应该引用特定的、不可变的版本。如果你的提示词没有进行版本控制，无论你捕获了什么其他内容，审计记录都是不完整的。一条写着"使用了客服提示词"的日志条目是不可复现的。一条写着"使用了 customer_support_v2.3.1"的日志条目给你提供了可以追查的东西。
那场总是来得太晚的对话
在构建 AI 审计日志的团队中，模式是一致的：这场对话发生在出了什么问题之后。要么是合规请求暴露了这个缺口，要么是一次本该花几个小时调试的事件花了几天，因为上下文不在那里；要么是模型更新导致了回归，但工程团队无法定位原因，因为他们无法在相同输入上比较新旧决策路径。
这场对话之所以来得晚，是因为这个缺口在它真正重要之前是不可见的。应用日志看起来是完整的。系统在运行。SRE 指标是绿色的。问题在于，你监控的是执行过程，而非推理过程——对于 AI 系统来说，推理过程才是会出错的那个。
构建 AI 审计基础设施不是一个六个月的项目。一个捕获上述七个字段的结构化日志 Schema，加上对所有外部引用的版本固定，可以在一个迭代周期内实现。可观测性平台使调试部分变得更容易。合规部分需要有意识的设计。两者都需要在出问题之前就决定，还原问题值得去解决。
合规团队会在你的工程团队准备好构建之前提出要求。这就是审计追踪的缺口所在。
