8.0
热点
AI SCORE
技术实践2026-08-23 21:12
AI可观测性：记录决策而非仅监控模型
dev.to · AI#AI可观测性#审计#生产安全
Editor brief · 编辑速览
作者因Agent静默批准$240万非覆盖流程事故反思，指出传统遥测只能回答"是否运行"，而审计需要能回答"哪个action、何版本prompt、哪些上下文、能否复现"的完整证据链，并给出了最小数据记录格式。
大多数 AI 可观测性栈回答的是"它还活着吗"。很少有人回答"它做了什么，你能证明吗"。
这个区别对我来说不再只是学术问题，当我负责的一个智能体在六周内静默批准了 240 万美元的不报销程序时。整个期间 uptime 都是绿色的。CFO 在月末审查中才发现。审计管道从未发现。
这篇文章讲的是你需要的最少记录是什么，以及为什么同样的记录能让你按结果计费。
标准遥测捕获请求、延迟、状态、token 数量。这只能告诉你系统运行了。它不能告诉你做了什么决策、基于什么证据、在哪个版本的任何东西上。
在实践中，这个差距是这样的。客户对输出提出异议。你需要回答四个问题，而你在有人要求更新之前有九十分钟。
哪个行为产生了这个？
哪个模型、哪个提示词或策略版本是生效的？
使用了哪些输入和检索到的上下文？
你能重放它并得到相同的结果吗？
如果以上任何一项需要考古挖掘，你就没有证据层。你只有日志。
不是框架。是形状。任何捕获这些字段的记录都能在大多数争议中存活。
from dataclasses import dataclass, asdict, field
from typing import Any
import hashlib, json
@dataclass(frozen=True)
class DecisionRecord:
decision_id: str # stable, referenced on the invoice line
action: str # "approve_claim", "resolve_ticket"
outcome: str # "approved" | "escalated" | "refused"
billable: bool # did this become a charge?
model_id: str # provider + exact version, never "gpt-latest"
policy_version: str # your prompt/rules version, semver
input_digest: str # hash, not the payload
context_refs: list # document ids + revision, not the text
confidence: float | None
ts: str # RFC3339, UTC
def digest(payload: Any) -> str:
canonical = json.dumps(payload, sort_keys=True, separators=(",", ":"))
return hashlib.sha256(canonical.encode()).hexdigest()
其中三个选择是承重的。
哈希输入，不要存储它。你获得篡改证据和重放验证，而不需要承担保留和隐私问题。如果哈希在重放时匹配，输入就匹配。
billable 是一个一等公民字段，不是后续推导的。一旦计费逻辑存在于决策记录之外，两者就会漂移，在续约时协调比原始问题更糟糕。
固定精确的模型版本。"gpt-latest" 不是版本。当提供商在别名后面静默更新模型时，你的重放不再是重放，你无法解释为什么行为在三月发生了变化。
如果你在不规范编码的情况下哈希字典，键顺序变化会破坏相等性，你的篡改证据就变成了噪音。
def record_digest(rec: DecisionRecord) -> str:
d = asdict(rec)
d.pop("decision_id", None) # id is assigned after hashing
return digest(d)
sort_keys=True 加上紧凑的分隔符在大多数情况下就足够了。如果你以后要对这些记录签名，使用真正的信封格式而不是自己发明一个。DSSE 加上 PAE 编码有完善的规范，实现也很小。
这是把治理产物变成收入产物的部分。
def billable_units(records, period_start, period_end):
"""One charge, one decision_id. No aggregate-only billing."""
return [
{"decision_id": r.decision_id,
"action": r.action,
"outcome": r.outcome,
"ts": r.ts}
for r in records
if r.billable and period_start <= r.ts < period_end
]
重要的规则：发票上的每一笔收费都能精确地追溯到一个 decision_id。不是计数。不是汇总。如果客户质疑第 4127 行，你就返回那条记录。
做不到这一点的供应商最终只能为总数辩护而不是交易，这是一个你会慢慢输掉的争论。
看看 AI 客服市场现在的收费方式。
同类产品。不同的单位。按结果计费的供应商自己承担了失败率，他们之所以能这样做，是因为他们能够证明结果。
一家领先供应商报告 8000 多客户平均 76% 的解决率。独立报告将同一指标放在 42% 到 50% 之间。这个差距不是欺诈。这是当计费单位没有可验证定义时会发生的情况。
Zendesk 的回应不是打折。他们在 2026 年 5 月重新构建，只对 72 小时内由独立评估模型确认的解决进行计费。他们增加了一个审计员，消除了争论。
客户能看到这个单位吗？Tokens 是你的问题。一个解决的工单是他们的。
你能无争议地测量它吗？像采购会读它一样写定义，因为最终他们会的。
它随他们的价值而不是你的成本而扩展吗？与计算挂钩的单位让你成为推理转售商。
九个月后你能为账单辩护吗？哪个行为、哪个版本、什么证据，按需提供。
大多数团队通过第 1 和第 3 项，在第 2 和第 4 项上失败。
把重建时间加到你的仪表板上。如果客户今天对输出提出异议，你需要多长时间才能准确显示它是如何产生的？
这是可测量的，instrument 成本很低，而且它比准确率更能预测你的下一个糟糕的季度。以我的经验，团队发现的答案是按天计算的，而且是在争议期间而不是之前发现的。
这是一个形状，不是库，我有意保持小巧。签名、保留策略、context_refs 中的 PII 处理以及非确定性运行时下的重放确定性都是这个草图没有解决的真实问题。RL rollouts 的确定性今年作为 beta 标志随 vLLM 发布，延迟大约增加一倍，几乎没有人开启它，这告诉你对严格版本有多大胃口。
如果你在生产环境中正确构建了它，我想知道记录 schema 首先在哪里崩溃了。我的在上下文引用上崩溃了，因为文档修订不是稳定的标识符，而我以为它是。