FDE 交付实战营

第九章生产级硬化

9.3 可观测与审计

承前：护栏把"拦得住的"拦住了，可观测性解决另一半问题——"拦不住的，出了事能不能发现、能不能定位、能不能追责"。传统软件有日志指标 trace 三件套的老传统，AI 系统要在这三件套上加一层"语义可观测"：模型为什么这么说、动作为什么被执行、人为什么点了同意。这一节讲三支柱、审计轨迹和 HITL 分层的落地。

9.3.1 三支柱：日志、指标、Trace

可观测的经典三支柱在 AI 应用里各司其职，但内容要按 LLM 特点重新填充：

┌──────────────┬────────────────────────────────┐
│ 日志 Logs     │ 一次事件的详细记录                │
│              │ 谁的会话、什么输入、模型版本、      │
│              │ 工具调用参数、护栏判定、耗时、成本  │
├──────────────┼────────────────────────────────┤
│ 指标 Metrics │ 可聚合的数字，用于告警和大盘       │
│              │ 采纳率、兑现率、P95 延迟、拦截率、 │
│              │ 幻觉抽检率、token 成本/日         │
├──────────────┼────────────────────────────────┤
│ Trace 追踪   │ 一次请求的完整因果链              │
│              │ 用户消息→检索→模型推理→护栏→     │
│              │ 工具调用→确认→执行，每步可见      │
└──────────────┴────────────────────────────────┘

关键理解：**AI 系统的日志不只是排障用，它同时就是审计的证据链。**传统软件里这两个角色常常分离（应用日志 vs 审计库），在 AI 应用里可以合一设计——因为"AI 为什么这样做"既是工程问题也是问责问题。这决定了日志结构必须从第一天就按审计标准建（不可篡改、保留期合规、字段规整），而不是事后补。

Trace 是三支柱里对 AI 最关键的一支。OpenTelemetry 已是事实标准，主流 LLM 观测平台（LangSmith、Langfuse 等）都支持 OTLP 协议接入，OpenInference 规范定义了 LLM 场景的语义属性（模型名、token 数、输入输出）。一次青禾助手的典型 trace：

trace: conv-8817 (会员唤回场景)
├─ span: input_guard        [拦截判定: safe, 34ms]
├─ span: rag_retrieve       [检索 3 篇文档, 210ms]
├─ span: llm_inference      [model=Qwen3-72B, in=1850tk, out=210tk, 1.9s]
├─ span: tool_call          [issue_coupon, 面额¥20, 白名单校验通过]
├─ span: hitl_confirm       [操作人=张三, 结果=同意, 等待 47s]
└─ span: action_commit      [幂等键=uuid-9a3f, 状态=已发券]

有了这条链，"会员投诉说没收到券"从一场考古变成一次 30 秒的查询。没有它，每一次投诉都是一次全员查库。

9.3.2 模型调用、工具调用、关键步骤：三个必须可追溯的节点

大纲给的生产要求很明确，展开为最小可追溯集：

模型调用可追溯：每次 LLM 调用记录模型名+版本、完整输入输出、token 计数、耗时、成本。模型版本尤其重要——模型厂商静默更新模型，行为漂移排查时这是唯一的线索。青禾沙盘里就埋了这个雷：升级到新版推理模型后建议风格变了，采纳率跌了 4 个点，因为日志里有模型版本字段，定位只花了一小时而不是一周。

工具调用可追溯：调用参数、白名单判定结果、幂等键、实际执行结果。工具调用是钱和动作的出口，追溯粒度要到参数级。

关键执行步骤可追溯：护栏每层的判定（拦截/放行/改写）、HITL 确认记录（8.2 的四要素：谁、何时、什么、依据）、降级与重试事件。这些事件决定系统行为却最容易被漏记——多数团队只记正常路径，而事故全在异常路径上。

9.3.3 客户审计字段与审计轨迹

To B 项目里，客户（尤其是合规部门）会要"审计视图"。提前设计客户审计字段——一组双方约定的、可导出的结构化字段，让客户不依赖你的系统也能回答监管问题：

字段组	字段示例	回答什么问题
主体	operator_id, role, department	谁做的
时间	timestamp, session_id	何时
行为	action_type, params, result	做了什么
AI 参与	model_version, ai_suggestion, ai_confidence	AI 给了什么建议
人的决策	human_decision, decision_reason, latency	人工做了什么决定
依据	data_sources, rule_refs	决策基于什么

这张表回答的是审计轨迹的三个终极问题，大纲原文表述得很准——**谁何时做了什么、AI 给了什么建议、人工做了什么决策。**对监管行业（金融、医疗），这三个问题就是检查组进场后问的前三句。9.7 的 Tampa General 案例会展示医院场景里这套轨迹的真实分量。

设计要点：**AI 建议和人工决策必须分开记录、可关联但不可混淆。**出了错要能分清"AI 建议错了人没看出来"还是"AI 建议对了人改错了"——责任矩阵（第 3 章的责任划分原则在生产阶段的延续）靠这个区分才有意义。同理，同意和拒绝都要记录（8.2 讲过拒绝理由的规则采集价值，在审计侧它还是"人工监督有效"的证据：如果日志里全是同意、零拒绝，等于告诉监管"这个 HITL 是橡皮图章"）。

9.3.4 HITL 分层：放权深度 × 风险等级

9.2 讲了三层防御里的 HITL 兜底，这里把它落成可运营的分层矩阵。两个轴：放权阶段（8.3 的只读/建议/执行）× 动作风险等级（可逆性 × 金额 × 影响面）：

                低风险动作            中风险动作            高风险动作
只读期      （无动作，不适用）
建议期      建议不执行            建议不执行            建议不执行
执行期      自动执行+抽检 5%      自动执行+实时确认      永不自动，双人审批
           （标签打标）          （发券 ≤ ¥20）        （批量群发、大额）

放权加深 = 矩阵整体左移；数据恶化 = 右移一档并通知客户

分层规则写进配置而非代码（9.2 原则的重申）。每层的抽检结果要回流：抽检发现错判，除了纠正这一单，还要进 bad case 库进下一轮评估（7 章评估集闭环在生产侧的延伸）。这样 HITL 就不只是安全网，还是持续学习的数据源——生产中的每一次人工纠错都在让下一版的抽检率可以更低。

9.3.5 告警与大盘：把"被动审计"变"主动运营"

可观测建设完成前最后一步：让指标主动报警。AI 应用最值得配的几条告警（阈值示意，按客户业务校准）：

采纳率 7 日滑动均值跌 5 个点——模型行为漂移或规则变更的前兆（青禾沙盘里模型升级事故的第一信号）；
输出拦截率突增——可能在被攻击，也可能是护栏误报泛滥；
拒答率异常——从不拒答（幻觉风险上升）或疯狂拒答（检索坏了）都是坏信号；
单用户 token 成本超日预算——死循环或滥用，9.6 成本工程会展开。

告警有了，还要有"每周运营看板"给客户：采纳率趋势、兑现率趋势、拦截分布、抽检纠错数、成本。这份周报是 8.1 沟通节奏的生产版延续——可观测的最终产品不是日志系统，是客户对系统的持续信心。

9.3.6 日志留存与合规：保留多久、谁能看、怎么防篡改

审计设计里最容易被评审会追问、也最容易留到上线后才补课的，是留存与权限。三个问题 IT 负责人一定会问：

**一，日志里有什么不能留的。**可观测的第一直觉是"全记"，但日志里很快会堆满敏感内容：用户原始输入（含会员手机号）、模型输出（可能带 PII）、检索到的业务数据。合规的正确姿势是分级记录：原始输入做脱敏（手机号掩码、证件号哈希）后落日志，完整原文只在 trace 的加密存储里按需调取，且调取本身留审计记录。否则你的排障日志库会变成客户最大的数据泄露风险点——这在金融、医疗客户那里是一票否决项。

**二，保留多久。**行业常见口径：排障类日志 30-90 天滚动，审计类轨迹按客户合规要求存 1-3 年甚至更长（医疗行业通常更长），模型输入输出样本（用于回归评估）另设保留期并做匿名化。保留期本身写进配置和合同附件，别靠"磁盘没满就不删"。

三，怎么防篡改。审计轨迹要经得起"事后被改过吗"的质疑，最低成本方案是追加写 + 哈希链（每条记录含前一条的哈希，改任何一条历史都会断链）或定期把日志哈希锚定到外部（客户侧的审计服务器）。沙盘里 IT 负责人只问了一句："这些记录你们的工程师能改吗？"——你的答案是"追加写、链式哈希、运维侧无更新接口"，这一关就过了。

这三件事的工程量都不大，但必须从第一天的日志 schema 设计里就带着，事后补意味着停机迁移历史数据。

9.3.7 排障演练：从"会员没收到券"到根因的 30 分钟

可观测体系建好后要验证。上线前安排一次排障演练：由同事扮演报障的运营——"华东 7 号店的王店长说，昨天下午有会员投诉没收到唤回券"——值班 FDE 从零开始定位，全程计时。正确路径应该长这样：

T+3m   按会员手机号/时间窗查审计日志 → 定位到 action_type=issue_coupon
       result=fail 的记录（日志层）
T+8m   取出 trace_id → 展开 trace：hitl_confirm 显示"已同意"，但
       tool_call span 是 fail，错误码 CONN_TIMEOUT（trace 层）
T+15m  对比同门店同时段连接器成功率 → 该时段客户 CRM 网关抖动，
       重试策略只设了 1 次未成功（跨指标层）
T+25m  结论: 非误判、非漏发,是执行链路超时; 幂等键显示该请求
       未实际落券 → 可安全重发; 建议把重试 1→3 次并加告警

这条路径走通了，说明三支柱真正闭环：日志找到"哪一次"、trace 找到"哪一步"、指标找到"为什么是这一片"。任何一环断掉（比如 trace 里的工具调用 span 没记错误码），演练就会卡住——卡住的环节就是上线前要补的观测盲区，这比巡检清单更能暴露真实短板。

再补一条经验数据点：这类演练建议每季度做一次（客户运维交接后改为客户主导、你观摩）。第一次演练 30 分钟，第二次通常 10 分钟——不是因为系统变好了，是因为人和流程熟悉了路径。排障能力 = 系统可观测性 × 人对路径的熟悉度，后一项只能靠演练。

9.3.8 要点总结

三支柱按 AI 特点重填：日志即审计证据链（从第一天按审计标准建）、指标含语义指标（采纳率/兑现率/拦截率/拒答率）、Trace 用 OpenTelemetry + OpenInference 贯穿全链路。
三个必须可追溯的节点：模型调用（含版本）、工具调用（到参数级）、关键执行步骤（护栏判定、HITL 确认、降级重试）。
客户审计字段六组，回答"谁何时做了什么、AI 给了什么建议、人工做了什么决策"；AI 建议与人工决策分开记录、同意与拒绝都留。
HITL 分层 = 放权阶段 × 风险等级矩阵，写进配置，抽检结果回流评估集形成学习闭环。
告警盯语义漂移信号（采纳率、拒答率、拦截率），周报大盘的最终产品是客户的持续信心。

参考资料

OpenTelemetry Documentation — CNCF 官方文档，trace/span/attributes 语义与 OTLP 协议，三支柱的技术底座。
Trace with OpenTelemetry — LangSmith Docs — LangSmith 官方 OTLP 接入指南，LLM 场景 trace 属性（模型、token 数、输入输出）的工程实现。
OWASP Top 10 for LLM Applications — OWASP 清单，LLM02 敏感信息泄露与 LLM09 不实信息等风险对审计字段设计的直接输入。
NeMo Guardrails | NVIDIA Developer Docs — NVIDIA 官方文档，护栏轨迹（tracing）与配置化 rails，支撑"拦截事件可追溯"。

第九章 生产级硬化 ​

9.3 可观测与审计 ​

9.3.1 三支柱：日志、指标、Trace ​

9.3.2 模型调用、工具调用、关键步骤：三个必须可追溯的节点 ​

9.3.3 客户审计字段与审计轨迹 ​

9.3.4 HITL 分层：放权深度 × 风险等级 ​

9.3.5 告警与大盘：把"被动审计"变"主动运营" ​

9.3.6 日志留存与合规：保留多久、谁能看、怎么防篡改 ​

9.3.7 排障演练：从"会员没收到券"到根因的 30 分钟 ​

9.3.8 要点总结 ​

参考资料 ​