从可观测三支柱到 AI 专属四支柱加一个模型质量维度一、背景与问题传统可观测性的三支柱是 Metrics指标、Logs日志、Traces追踪。这三支柱覆盖了基础设施和应用的运行状态Metrics 看趋势和告警Logs 看事件细节Traces 看调用链路。对于 Web 服务、数据库、缓存这些传统组件三支柱足够。但 AI 推理服务引入了一个新的问题维度模型质量。推理服务返回 200 OK、延迟 200ms、没有错误日志——从三支柱角度看一切正常。但如果模型输出了不相关的内容、幻觉事实、格式错误的 JSON用户体验已经崩了。三支柱观测不到这个问题因为它们只关注服务是否正常运行不关注输出是否正确有用。这不是边缘问题。推理服务的 SLO 不能只有延迟和成功率必须包含输出质量——否则你可能在一个指标全绿的服务后面提供着越来越差的模型输出。模型质量维度是 AI 服务独有的可观测需求是三支柱到四支柱的必要扩展。二、四支柱模型flowchart LR subgraph 传统三支柱 M[Metricsbr运行指标] L[Logsbr事件日志] T[Tracesbr调用链路] end subgraph AI 扩展支柱 Q[Qualitybr模型质量] end M -- SLO1[延迟 P99 1sbr成功率 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四支柱的关系不是并列是互补支柱观测对象核心问题数据来源Metrics服务运行状态是否正常是否快PrometheusLogs事件细节发生了什么LokiTraces调用链路谁调了谁卡在哪Jaeger/TempoQuality模型输出质量输出对不对好不好评估 pipelineQuality 支柱的数据来源和其他三个完全不同。Metrics/Logs/Traces 是运行时数据从服务本身采集Quality 是事后评估数据需要对模型输出做离线或在线评估。三、模型质量指标体系3.1 三类质量指标模型质量不是单一的好不好判断需要拆分为三个可量化维度质量维度指标名采集方式采集频率相关性Relevanceoutput_relevance_scoreLLM-as-judge 评估每 1000 次推理采样 10 次准确性Accuracyhallucination_rate事实性检查 人工标注每周离线评估格式合规性Formatformat_compliance_rate规则检查JSON schema / 正则每次推理实时检查三类指标的采集成本差异很大格式合规性成本最低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[采样器br10/1000] B -- C[Judge LLMbrgpt-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.00150 token 输入 10 token 输出10% 采样率下每天额外成本约 $1-2可接受。四、四支柱关联分析4.1 质量与运行指标的关联关键问题推理延迟飙升时模型质量是否同步下降答案不能靠猜测靠数据# 延迟飙升期间的质量变化 inference_output_relevance_score{quantile0.5} AND inference_request_latency_e2e_ms{quantile0.99} 1000实际发现延迟飙升时质量确实可能下降。原因是 GPU 满载时推理框架会降低精度FP16→INT8 量化或减少 KV cache 来保持吞吐代价是输出质量略降。这个关联只有四支柱数据在同一体系下才能发现。4.2 质量与模型版本的关联模型版本更新时质量指标必须同步监控# 新版本的质量对比 inference_output_relevance_score{model_versionv2.0} vs inference_output_relevance_score{model_versionv1.5}如果新版本的 P50 相关性从 0.85 降到 0.72不管延迟和成功率如何都应该回滚版本。质量是推理服务的核心交付物比延迟更重要。4.3 质量告警规则告警条件级别响应格式合规率低compliance_rate 90% 持续 10mP2检查输出 schema 配置相关性下降relevance P50 0.7 持续 1dP2检查模型版本和 prompt幻觉率升高hallucination_rate 5%P1紧急评估考虑回滚质量告警的时间窗口比运行指标告警长1 天 vs 5 分钟因为质量变化是渐进的短窗口内的波动大多是评估采样误差。五、总结传统可观测三支柱覆盖了服务是否正常运行但 AI 推理服务还需要观测输出是否正确有用。这是四支柱的必要性——不是三支柱不够好是 AI 服务多了一个需要观测的维度。三个关键实践质量指标分三类格式合规性实时检查、成本低、相关性采样评估、成本中、准确性离线标注、成本高按成本和价值平衡采集频率。质量指标接入同一套 Prometheus和运行指标同一体系才能做关联分析单独建一套质量监控系统无法和延迟、成功率关联。LLM-as-judge 用小模型评估相关性不需要大模型推理能力小模型足够且成本低10% 采样率下每天额外成本 $5。基础设施不需要漂亮话。四支柱不是追求可观测性的完备性是应对 AI 服务的实际需求——三支柱全绿但输出质量崩了是推理服务特有的故障模式。观测不到质量就无法防止这种故障观测到了就能在影响扩大前回滚或降级。这不是理论探讨是生产保障。