从可观测三支柱到 AI 专属四支柱：加一个模型质量维度

一、背景与问题

传统可观测性的三支柱是 Metrics（指标）、Logs（日志）、Traces（追踪）。这三支柱覆盖了基础设施和应用的运行状态：Metrics 看趋势和告警，Logs 看事件细节，Traces 看调用链路。对于 Web 服务、数据库、缓存这些传统组件，三支柱足够。

但 AI 推理服务引入了一个新的问题维度：模型质量。推理服务返回 200 OK、延迟 200ms、没有错误日志——从三支柱角度看一切正常。但如果模型输出了不相关的内容、幻觉事实、格式错误的 JSON，用户体验已经崩了。三支柱观测不到这个问题，因为它们只关注"服务是否正常运行"，不关注"输出是否正确有用"。

这不是边缘问题。推理服务的 SLO 不能只有延迟和成功率，必须包含输出质量——否则你可能在一个"指标全绿"的服务后面提供着越来越差的模型输出。模型质量维度是 AI 服务独有的可观测需求，是三支柱到四支柱的必要扩展。

二、四支柱模型

flowchart LR subgraph 传统三支柱 M[Metrics<br>运行指标] L[Logs<br>事件日志] T[Traces<br>调用链路] end subgraph AI 扩展支柱 Q[Quality<br>模型质量] end M --> SLO1[延迟 P99 < 1s<br>成功率 > 99.5%] L --> SLO2[错误日志可检索<br>请求链路可追踪] T --> SLO3[调用链路可穿透<br>瓶颈步骤可定位] Q --> SLO4[输出相关性 > 90%<br>幻觉率 < 5%<br>格式合规率 > 95%] style Q fill:#d32f2f,color:#fff style M fill:#1565c0,color:#fff style L fill:#2e7d32,color:#fff style T fill:#ff6f00

四支柱的关系不是并列，是互补：

Quality 支柱的数据来源和其他三个完全不同。Metrics/Logs/Traces 是运行时数据，从服务本身采集；Quality 是事后评估数据，需要对模型输出做离线或在线评估。

三、模型质量指标体系

3.1 三类质量指标

模型质量不是单一的"好不好"判断，需要拆分为三个可量化维度：

三类指标的采集成本差异很大：

• 格式合规性成本最低：JSON schema 验证是确定性规则，每次推理都能做，不增加推理延迟。
• 相关性成本中等：LLM-as-judge 需要额外一次推理调用（用另一个模型评估输出质量），只能采样做。
• 准确性成本最高：事实性检查可能需要外部知识库验证，人工标注需要人力投入，只能低频做。

采集频率不是越高越好，是根据成本和诊断价值平衡。格式合规率实时采集是因为格式错误直接影响下游解析；相关性每周采样是因为趋势变化慢，每天看一个均值就够了；准确性月度离线评估是因为事实性问题的变化周期更长。

3.2 质量指标接入 Prometheus

质量指标需要接入和其他三支柱同一套 Prometheus，才能做关联分析：

var relevanceScore = prometheus.NewHistogram(prometheus.HistogramOpts{ Name: "inference_output_relevance_score", Buckets: []float64{0.1, 0.3, 0.5, 0.7, 0.9, 1.0}, }) var hallucinationRate = prometheus.NewGauge(prometheus.GaugeOpts{ Name: "inference_hallucination_rate", }) var formatComplianceRate = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Name: "inference_format_compliance_rate", }, []string{"output_format"})

relevance_score用 Histogram 因为它是连续值分布，需要看 P50/P95。hallucination_rate用 Gauge 因为它是离线评估的结果，每次更新一个值。format_compliance_rate用 GaugeVec 因为不同输出格式（JSON、Markdown、纯文本）的合规率不同。

3.3 LLM-as-judge 评估 Pipeline

相关性评估的推荐实现方式：

flowchart LR A[推理输出样本] --> B[采样器<br>10/1000] B --> C[Judge LLM<br>gpt-4o-mini] C --> D[评分: 0.0-1.0] D --> E[写入 Prometheus] A --> F[实时格式检查] F --> G[合规率写入 Prometheus] style B fill:#7b1fa2,color:#fff style C fill:#8e24aa,color:#fff

采样器从推理输出中随机选取 10% 的样本，发送给 Judge LLM 评估相关性。Judge LLM 的 prompt 忺准化：

JUDGE_PROMPT = """ 评估以下模型输出与用户查询的相关性。 评分标准： - 1.0: 完全相关，直接回答了查询 - 0.7: 大部分相关，包含少量无关内容 - 0.3: 弱相关，主要内容偏离查询 - 0.0: 完全不相关 用户查询: {query} 模型输出: {output} 请只返回评分数字（0.0-1.0），不要解释。 """

Judge LLM 用小模型（gpt-4o-mini）而非大模型，原因是评估相关性不需要复杂推理，小模型足够且成本低。每次评估的额外成本约 $0.001（50 token 输入 + 10 token 输出），10% 采样率下每天额外成本约 $1-2，可接受。

四、四支柱关联分析

4.1 质量与运行指标的关联

关键问题：推理延迟飙升时，模型质量是否同步下降？答案不能靠猜测，靠数据：

# 延迟飙升期间的质量变化 inference_output_relevance_score{quantile="0.5"} AND inference_request_latency_e2e_ms{quantile="0.99"} > 1000

实际发现：延迟飙升时质量确实可能下降。原因是 GPU 满载时推理框架会降低精度（FP16→INT8 量化）或减少 KV cache 来保持吞吐，代价是输出质量略降。这个关联只有四支柱数据在同一体系下才能发现。

4.2 质量与模型版本的关联

模型版本更新时，质量指标必须同步监控：

# 新版本的质量对比 inference_output_relevance_score{model_version="v2.0"} vs inference_output_relevance_score{model_version="v1.5"}

如果新版本的 P50 相关性从 0.85 降到 0.72，不管延迟和成功率如何，都应该回滚版本。质量是推理服务的核心交付物，比延迟更重要。

4.3 质量告警规则

质量告警的时间窗口比运行指标告警长（1 天 vs 5 分钟），因为质量变化是渐进的，短窗口内的波动大多是评估采样误差。

五、总结

传统可观测三支柱覆盖了"服务是否正常运行"，但 AI 推理服务还需要观测"输出是否正确有用"。这是四支柱的必要性——不是三支柱不够好，是 AI 服务多了一个需要观测的维度。

三个关键实践：

1. 质量指标分三类：格式合规性（实时检查、成本低）、相关性（采样评估、成本中）、准确性（离线标注、成本高），按成本和价值平衡采集频率。
2. 质量指标接入同一套 Prometheus：和运行指标同一体系才能做关联分析，单独建一套质量监控系统无法和延迟、成功率关联。
3. LLM-as-judge 用小模型：评估相关性不需要大模型推理能力，小模型足够且成本低，10% 采样率下每天额外成本 < $5。

基础设施不需要漂亮话。四支柱不是追求可观测性的完备性，是应对 AI 服务的实际需求——三支柱全绿但输出质量崩了，是推理服务特有的故障模式。观测不到质量，就无法防止这种故障；观测到了，就能在影响扩大前回滚或降级。这不是理论探讨，是生产保障。