LLM 可观测性 (LLM Observability)

概述

LLM 可观测性 (LLM Observability) 是指在生产环境中对 LLM 应用进行全面监控、追踪和分析的能力。不同于传统的软件可观测性（主要关注延迟、错误率、吞吐量），LLM 可观测性还需要追踪生成质量、token 消耗、幻觉率、安全性、用户满意度等 AI 特有的指标。到 2026 年，LLM 可观测性已成为生产级 LLM 应用的必备基础设施，而非可选项。

可观测性三大支柱

Tracing（追踪）

记录每个请求的完整执行路径，包括：

• API 调用链（LLM 调用、工具调用、检索步骤）
• 每个步骤的输入/输出
• Token 消耗和延迟
• Prompt 和 Completion 的完整内容

Monitoring（监控）

实时或近实时地追踪聚合指标：

• 延迟分位数 (P50, P95, P99)
• 错误率（按错误类型分类）
• Token 消耗速率和成本
• 用户反馈趋势
• 速率限制使用情况

Evaluation（评估）

对 LLM 输出进行质量评估：

• 基于规则的评估（格式正确性、长度、关键词存在性）
• 基于 LLM 的评估（准确性、相关性、有用性）
• 人工评估（用户反馈、标注数据）
• 对比评估（A/B 测试，不同模型/模板/参数对比）

需要追踪的关键指标

性能指标

成本指标

质量指标

主流 LLM 可观测性平台对比

LangFuse（推荐用于自托管场景）

LangFuse 是 2024-2026 年增长最快的 LLM 可观测性开源项目。

核心功能：

• Tracing：嵌套的 trace 结构，支持 agent、chain、tool 等多层嵌套
• Prompt Management：版本化 Prompt 管理，支持 A/B 测试和回滚
• Evaluation：内置评估器，支持自定义评估模板
• Datasets：从生产 trace 中构建评估数据集
• Playground：基于 Prompt 模板和数据集进行交互式调试
• Cost Tracking：自动计算各模型和 provider 的成本

LangFuse Trace 结构示例：

Trace: user-query-123
├── Span: Retrieval (150ms)
│   ├── Generation: HyDE query expansion (800ms, 234 tokens)
│   └── Generation: Vector search (45ms)
├── Span: LLM Generation (2.3s, 512 tokens)
│   ├── prompt_tokens: 1234
│   ├── completion_tokens: 512
│   └── model: gpt-5.5
├── Span: Guardrail Check (50ms)
│   └── score: 0.98 (safe)
└── Observation: User Feedback (thumbs_up)

Helicone（推荐用于快速启动）

Helicone 是最简单的 LLM 可观测性工具，只需修改 API Base URL 即可接入。

核心功能：

• 一行代码接入：将 api.openai.com 替换为 oai.helicone.ai
• Prompt 实验：A/B 测试不同 Prompt 模板
• 成本仪表盘：实时成本追踪和预算告警
• 速率限制管理：跨模型的速率限制监控
• 缓存分析：缓存命中率追踪

Arize Phoenix（推荐用于深度分析）

Arize Phoenix 是 Arize AI 开源的 LLM 可观测性工具，专注于深度分析和调试。

核心功能：

• Embedding 可视化：将 trace 嵌入向量可视化，发现集群和异常
• RAG 检索分析：检索质量评估，相关性分数分布
• 漂移检测：数据漂移和模型性能退化检测
• 检索-生成对齐：分析检索结果与生成内容的关系

LLM 可观测性架构

推荐的观测架构

                    ┌──────────────────┐
                    │   LLM Application  │
                    │  (LangChain/       │
                    │   LlamaIndex/      │
                    │   自定义)           │
                    └────────┬───────────┘
                             │
                    ┌────────▼───────────┐
                    │   Observability SDK │
                    │  (LangFuse/         │
                    │   OpenTelemetry)    │
                    └────────┬───────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
    ┌─────────▼─────┐ ┌─────▼──────┐ ┌────▼──────┐
    │  LangFuse      │ │  Prometheus │ │  Logging   │
    │  (Trace/成本/   │ │  (指标)     │ │  (ELK/     │
    │   评估)         │ │             │ │   Loki)    │
    └───────┬────────┘ └──────┬──────┘ └─────┬──────┘
            │                 │               │
            └─────────┬───────┴───────────────┘
                      │
              ┌───────▼────────┐
              │   Grafana       │
              │  (统一仪表盘)    │
              └────────────────┘

2026 年：可观测性是生产 LLM 应用的必备条件

为什么可观测性不再是可选项

1. 成本控制：LLM API 成本可占应用总成本的 40-70%，没有可观测性就无法优化。
2. 质量保障：LLM 输出是非确定性的，必须持续监控质量退化。
3. 合规要求：欧盟 AI Act 等法规要求对 AI 系统进行监控和审计追踪。
4. 用户信任：追踪每次交互，为争议提供可回溯的证据。
5. 快速迭代：Prompt 优化、模型切换、RAG 策略调整都需要数据驱动决策。

2026 年趋势

1. OpenTelemetry 标准化：LLM 可观测性正在向 OpenTelemetry 标准靠拢，实现跨平台互操作。
2. AI-Native 可观测性：使用 LLM 来分析 LLM 的 trace 数据，自动发现异常和模式。
3. Guardrails 集成：可观测性平台与 Guardrails（如 Guardrails AI、NVIDIA NeMo Guardrails）深度集成。
4. 实时干预：不仅是监控，还能在检测到质量问题时实时触发修正（如自动切换模型、回退 Prompt）。
5. 成本优化自动化：基于可观测性数据自动选择最便宜的模型、调整缓存策略、优化 token 使用。

相关笔记

• 第21章 . MLOps 基础 — MLOps 全流程，可观测性是其中的关键环节
• LLM 通用评估：怎么给 AI 打分 — LLM 评估方法与可观测性中的评估组件
• 深挖 LangSmith — LangSmith 作为 LangChain 生态的可观测性平台
• 语义缓存 (Semantic Cache) — 语义缓存的可观测性监控
• Self-RAG 与 Corrective RAG — Self-RAG 的检索质量评估与可观测性集成

来源

• LangFuse Documentation: https://langfuse.com/docs
• LangFuse GitHub: https://github.com/langfuse/langfuse
• Helicone Documentation: https://docs.helicone.ai/
• Arize Phoenix GitHub: https://github.com/Arize-AI/phoenix
• OpenTelemetry: https://opentelemetry.io/
• MLflow: https://mlflow.org/
• Weights & Biases: https://wandb.ai/