我要设计一个 AI 监控平台，第一张图应该怎么画
核心判断
AI 监控平台不能只是在传统监控上多加几个 token 指标。
真正要解决的问题是：一次 AI 调用从请求进入、模型调用、Prompt 拼装、RAG 召回、Tool 执行、业务结果、质量评估到安全审计，能不能被同一条链路串起来。
没有贯穿全链路的 trace_id，AI 监控平台最后会变成几块互不相认的看板。
传统监控能告诉你服务有没有挂、接口有没有报错、延迟有没有升高。AI 系统更麻烦的地方在于，很多问题没有 error。接口 200，延迟正常，成本正常，模型也正常返回，但业务结果已经错了。
所以 AI 监控的分层，不应该按组织分，也不应该按工具分。它应该按故障从“有声”到“无声”的路径分。
分层架构
L5 安全审计层
谁在用、有没有被注入、有没有泄露、留痕全不全
L4 质量评估层
这次输出到底好不好，和基线比有没有退化
L3 业务结果层
任务有没有完成，字段全不全，业务规则有没有遵守
L2 Prompt / RAG / Tool 层
Prompt 用了哪版，召回了什么，工具调用成功没有
L1 模型调用层
token、延迟、缓存、模型版本、成本、finish_reason
L0 基础可用性层
endpoint 存活、GPU/显存、配额、排队深度、探活到首 token
L0 和 L1 是有声故障层。它们通常会带来错误码、延迟突增、429、重试、fallback、成本异常。
L2 是半无声层。Tool 超时可能有错误，但召回内容变差、context 被截断、Prompt 版本不一致，往往不会直接报错。
L3 和 L4 是无声退化层。系统全是 200，用户看到的结果却越来越差。
L5 是竖切所有层的安全审计轴。它不应该单独躲在另一个系统里，只在出事后查日志。它需要消费 L1 的输入输出、L2 的召回文档和工具调用、L3 的业务动作，给每条 trace 打安全标签。
L0 基础可用性层
这一层回答的问题很朴素：模型服务是不是真的能工作。
传统探活只看 HTTP 或进程状态，对 AI 不够。一个 endpoint 可以返回 200，但模型排队很深、配额快满、GPU OOM 后吞吐下降，用户体感已经很差。
需要采集的字段：
{
"endpoint": "provider-a-shanghai-1",
"region": "cn-east",
"provider": "provider_a",
"gpu_util": 0.82,
"vram_used": 0.91,
"queue_depth": 128,
"rate_limit_remaining": 3200,
"health_token_latency_ms": 850
}
核心指标：
- endpoint 可用率
- 探活到首 token 延迟
- GPU / 显存水位
- 排队深度
- 配额剩余量
- 429 / 限流趋势
典型异常：
- 自建推理节点 OOM 后吞吐下降
- 供应商某区域异常
- 配额快打满
- endpoint 还活着，但 token 出不来
这一层和上一代基础设施监控最像，但探活方式要变。AI 的健康检查不能只问“接口在不在”，还要问“能不能在合理时间内吐出第一个 token”。
L1 模型调用层
这一层记录一次模型调用本身。
需要采集的字段：
{
"trace_id": "trc_123",
"model": "gpt-4o",
"model_version": "gpt-4o-2024-08-06",
"provider": "openai",
"channel": "official",
"prompt_tokens": 1800,
"completion_tokens": 420,
"cached_tokens": 900,
"ttft_ms": 480,
"tpot_ms": 28,
"total_latency_ms": 3100,
"http_status": 200,
"finish_reason": "stop",
"retry_count": 1,
"fallback_path": ["anthropic", "openai"],
"cost": 0.012
}
核心指标：
- TTFT，首 token 延迟
- TPOT，每 token 延迟
- 总延迟
- token 数
- 缓存命中率
- 重试率
- fallback 率
- 截断率
- 单次调用成本
- 模型版本变化
典型异常：
- 同名模型背后版本变了
- 缓存失效导致成本上涨
finish_reason=length增多，输出被截断- fallback 率上升，表面成功率正常，实际已经降级
- 某个 channel 的 429 或延迟异常
这一层是 AI 监控的地基。它告诉你模型调用有没有异常，但还不能告诉你输出有没有真的满足业务要求。
L2 Prompt / RAG / Tool 层
这一层进入 AI 应用自己的逻辑。
模型调用前，系统做了什么？用了哪版 Prompt？召回了哪些文档？context 有没有被截断？模型调用了哪个工具？工具入参对不对？
需要采集的字段：
{
"trace_id": "trc_123",
"prompt_template_id": "customer_refund_reply",
"prompt_version": "v7",
"rag_query": "退款政策",
"retrieved_doc_ids": ["doc_18", "doc_22", "doc_31"],
"retrieval_scores": [0.83, 0.79, 0.74],
"recall_count": 3,
"rerank_scores": [0.91, 0.87, 0.65],
"context_tokens": 1200,
"truncated_docs": ["doc_31"],
"tool_name": "order_lookup",
"tool_status": "success",
"tool_latency_ms": 120
}
核心指标：
- Prompt 版本占比
- 召回空率
- 平均召回分数
- 召回分数分布漂移
- context token 占比
- context 截断率
- tool 成功率
- tool 超时率
- 最终输出引用了哪些召回文档
典型异常：
- 向量库重建后，相似度分数尺度变化，阈值失效
- 知识库文档下架，召回为空
- context 过长，关键文档被截断
- tool schema 改了，模型仍按旧格式调用
- 召回有结果，但结果不相关
这一层是传统监控最难覆盖的地方。数据库查询成功，HTTP 也成功，但召回内容可能已经错了。
L3 业务结果层
这一层看 AI 输出有没有满足业务契约。
客服回复、合同摘要、销售线索提取、工单分类、代码生成，每个任务都应该有自己的业务校验。AI 输出不能只看“有没有文字”，还要看结构是否正确、字段是否完整、规则是否遵守、用户最后有没有采纳。
需要采集的字段：
{
"trace_id": "trc_123",
"task_type": "refund_reply",
"business_id": "ticket_8891",
"schema_valid": true,
"required_fields_present": true,
"format_valid": true,
"business_rule_pass": true,
"refused": false,
"downstream_action": "sent",
"user_action": "accepted"
}
核心指标：
- schema 通过率
- 必填字段完整率
- 格式合规率
- 业务规则通过率
- 拒答率
- 人工接管率
- 用户采纳率
- 用户编辑率
- 用户丢弃率
典型异常：
- Prompt 改版后开始漏字段
- 模型换版后格式不稳定
- 某类问题拒答率升高
- 输出看起来通顺，但业务规则不通过
- 用户大量编辑 AI 结果，说明质量在退化
AI 应用最常见的线上问题，通常不是接口报错。更常见的情况是，结果还能用，但越来越不好用。这一层就是把这种退化变成指标。
L4 质量评估层
这一层把“好不好”变成可监控的数字。
评估可以来自规则、LLM judge、人工标注、用户反馈，也可以来自固定回归测试集。它既用于上线前的发布门禁，也用于上线后的持续抽样。
需要采集的字段：
{
"eval_id": "eval_456",
"trace_id": "trc_123",
"eval_type": "judge",
"reference_set_id": "refund_reply_baseline_v3",
"score": 0.89,
"dimension_scores": {
"factuality": 0.92,
"relevance": 0.88,
"style": 0.90,
"safety": 0.95
},
"baseline_score": 0.88,
"delta": 0.01,
"regression_flag": false,
"human_label": null
}
核心指标：
- 质量分均值
- 质量分分位数
- 相对基线 delta
- 质量漂移
- 回归门禁通过率
- judge 与人工一致性
- 按模型、Prompt 版本、RAG 版本切片的质量变化
典型异常：
- 换模型后通用能力变强，业务质量下降
- RAG 引用更多，但事实命中更差
- Prompt 改版后风格更稳定，事实性变差
- judge 模型升级后打分尺度漂移
- 线上真实样本质量低于测试集
这层既是监控，也是测试。上线前跑回归，上线后按 trace_id 抽样持续评估。
L5 安全审计层
安全审计不应该是单独的孤岛。它要竖切所有层。
输入里有没有敏感信息？Prompt 有没有注入风险？RAG 召回的文档用户有没有权限？Tool 有没有越权执行？输出有没有泄露字段？出事后能不能顺着 trace 查回来？
需要采集的字段：
{
"trace_id": "trc_123",
"user_id": "u_001",
"tenant_id": "tenant_acme",
"pii_detected": true,
"redaction_applied": true,
"injection_detected": false,
"jailbreak_score": 0.12,
"retrieved_doc_permission_ok": true,
"tool_permission_ok": true,
"output_leak_flag": false,
"policy_id": "policy_customer_data_v2",
"audit_log_id": "audit_789"
}
核心指标：
- PII 命中率
- 脱敏覆盖率
- prompt 注入命中率
- 越权 tool 调用次数
- 越权文档召回次数
- 敏感输出命中率
- 审计链完整率
典型异常：
- 用户输入注入劫持 system prompt
- RAG 召回了用户无权访问的文档
- Agent 被诱导调用高权限工具
- 输出泄露敏感字段
- 出事后 trace 断了，审计追不回来
安全审计层消费的是全链路数据。它不只是多加一张“安全看板”，还要给每一次 AI 调用补上身份、权限、策略和留痕。
一条完整调用怎么串起来
以客服工单自动回复为例。
① L0
网关选择 endpoint-A，配额够，探活到首 token 正常。
② L1
生成 trace_id=T1。
调用 model=X，version=2026-05。
prompt_tokens=1800，其中 1200 是 RAG context。
ttft=400ms，finish_reason=stop，cost=0.012。
③ L2
prompt_version=v7。
rag_query=“退款政策”。
召回 5 篇文档，最终引用 doc_18 / doc_22。
调用 order_lookup 工具成功。
④ L3
task_type=refund_reply。
必填字段：金额、时效、凭证，全部存在。
business_rule_pass=true。
客服未编辑，直接采纳。
⑤ L4
近线抽样评估。
事实分 0.92，相关性 0.88，风格 0.90。
相对基线 delta=+0.01，没有退化。
⑥ L5
输入包含订单号，已脱敏。
召回文档权限通过。
工具调用权限通过。
审计链完整。
如果某天质量分下降，顺着 trace_id 查：
- L4 看到事实分掉了
- L3 看到字段还全，所以普通业务校验没报
- L2 看到召回分数下降，引用文档变了
- L1 看到模型版本也变了
症状可能出现在顶层，根因经常藏在底层。
这就是分层设计的价值。
架构图
flowchart TB
REQ[一次请求 trace_id = T1]
subgraph L0[L0 基础可用性层]
A0["endpoint 存活 / GPU 显存 / 配额 / 排队深度<br/>探活到首 token 延迟"]
end
subgraph L1[L1 模型调用层]
A1["model_version / token / cache<br/>TTFT / TPOT / finish_reason / cost"]
end
subgraph L2[L2 Prompt · RAG · Tool 层]
A2["prompt_version / 召回文档与分数<br/>引用命中率 / tool 成功率 / context 截断"]
end
subgraph L3[L3 业务结果层]
A3["schema 校验 / 字段完整 / 规则遵守<br/>拒答率 / 用户采纳 / 编辑 / 转人工"]
end
subgraph L4[L4 质量评估层]
A4["judge / 规则 / 人工<br/>维度分 / vs 基线 delta / 漂移 / 回归门禁"]
end
subgraph L5[L5 安全审计层]
A5["注入 / PII / 越权 tool / 数据驻留<br/>审计链完整率"]
end
REQ --> L0 --> L1 --> L2 --> L3
L3 -. trace_id join .-> L4
L5 -. 读输入输出并打安全标签 .-> L1
L5 -. 检查召回文档权限 .-> L2
L5 -. 检查敏感输出和业务动作 .-> L3
L4 == 反哺发布门禁 ==> L2
A4 -. 症状常在顶层可见 .-> A1
A1 -. 根因常在底层发生 .-> A4
后续拆篇方向
这篇可以作为总览篇，先把全路径立住。
后面再拆：
- L0 + L1：基础可用性和模型调用层，讲 token、延迟、缓存、版本、成本、截断、fallback。
- L2：Prompt / RAG / Tool 可观测，重点讲召回漂移和工具调用。
- L3 + L4：业务结果和质量评估，讲如何把“变差”变成指标。
- L5：安全审计如何竖切所有层。
写作前需要查证的点
正式成文前，需要查证：
- OpenAI、Anthropic 等供应商的
finish_reason/stop_reason字段名和枚举。 - usage 字段：
prompt_tokens/completion_tokens与input_tokens/output_tokens的差异。 - 缓存字段与价格折扣口径。
- 限流 header，如
retry-after、x-ratelimit-*。 - 模型别名与快照版本机制。
seed支持情况，以及供应商是否承诺可复现。
这些会影响后续 L1 和 L2 的细节。总览篇可以先讲架构，正式深入单层时再逐项核对。
如果你正在建设企业 AI Gateway、多模型管理、可观测、评估或安全审计体系，欢迎交流。