30 秒快速回答

AI 可观测性（AI Observability） 是一套让开发者实时了解 LLM 应用”正在做什么、做得怎么样、哪里出了问题”的工程体系。它不是简单看日志，而是覆盖 Trace（调用链追踪）、Metrics（指标监控）、Evaluation（质量评估） 三层，帮你回答三个关键问题：用户请求走了哪条链路？回答质量有没有退化？Token 成本是否失控？

一句话核心价值：传统 APM 能告诉你接口延迟，AI 可观测性能告诉你为什么模型给出了这个答案，以及这个答案是否可靠。

1. 为什么传统监控不够用？

传统软件监控盯着三个指标：延迟、错误率、吞吐量。但 LLM 应用有完全不同的故障模式：

LLM 应用的不确定性来自三个层面：模型本身的概率性输出、Prompt 的脆弱性、以及 RAG/Agent 中工具调用链路的复杂性。一个典型的 Agent 请求可能涉及：意图分类 → 检索 → 多次工具调用 → 多步推理 → 最终生成，中间任何一个环节出错都可能导致最终答案不可用。传统 APM 对这一整条链路是”盲”的。

2. AI 可观测性的三层架构

业界已形成共识：AI 可观测性 = Trace + Metrics + Evaluation。

2.1 Trace：看清每一次请求的完整链路

Trace 记录一次用户请求从入口到最终输出的每一步。在 LLM 应用中，一个 Trace 通常包含以下 Span：

用户请求
├── Span: 意图分类（调用小模型判断意图）
├── Span: 知识库检索（向量搜索 + 重排序）
├── Span: LLM 调用（含 Prompt 模板 + 完整输入/输出）
├── Span: 工具调用（Function Calling / MCP）
├── Span: 后处理（格式化输出、敏感词过滤）
└── Span: 最终响应

实操示例——用 Python 手动埋点记录一次 LLM 调用：

import time
import json

def trace_llm_call(span_name: str, prompt: str, response: str, 
                   model: str, tokens_used: int, latency_ms: float):
    """简易 Trace 记录，生产环境建议使用 OpenTelemetry SDK"""
    span = {
        "name": span_name,
        "timestamp": time.time(),
        "input": prompt[:500],       # 截断避免日志膨胀
        "output": response[:500],
        "model": model,
        "tokens": tokens_used,
        "latency_ms": latency_ms
    }
    # 发送到可观测平台（LangSmith / Helicone / 自建）
    print(json.dumps(span, ensure_ascii=False))

2026 年的标准选择：OpenTelemetry 的 GenAI Semantic Conventions 已经稳定，主流平台（LangSmith、Helicone、Arize、Weights & Biases）都支持 OTel 协议接入。一次埋点，多平台可用。

2.2 Metrics：量化你的 AI 应用健康度

Trace 帮你排查单次问题，Metrics 帮你发现系统性问题。关键指标分四类：

Token 成本追踪示例：

# 按模型追踪每日 Token 消耗
from collections import defaultdict

daily_tokens = defaultdict(lambda: {"input": 0, "output": 0, "cost": 0.0})

# 主流模型 2026 Q3 定价（每百万 Token，USD）
PRICING = {
    "claude-opus-5":    {"input": 15.0, "output": 75.0},
    "claude-sonnet-5":  {"input": 3.0,  "output": 15.0},
    "gpt-5":            {"input": 2.5,  "output": 10.0},
    "deepseek-v4":      {"input": 0.5,  "output": 2.0},
}

def record_usage(model: str, input_tokens: int, output_tokens: int):
    p = PRICING.get(model, {"input": 0, "output": 0})
    cost = (input_tokens / 1e6) * p["input"] + (output_tokens / 1e6) * p["output"]
    daily_tokens[model]["input"] += input_tokens
    daily_tokens[model]["output"] += output_tokens
    daily_tokens[model]["cost"] += cost

2.3 Evaluation：在用户发现问题之前发现回归

Eval 是 AI 可观测性中最容易被忽略但最关键的一环。核心做法：维护一组标注好的测试用例，每次 Prompt 变更或模型升级后自动跑回归。

典型 Eval Pipeline：
┌──────────┐    ┌──────────┐    ┌───────────┐    ┌──────────┐
│ Prompt   │ →  │ 测试用例  │ →  │ LLM-as-   │ →  │ 评分报告  │
│ 变更触发  │    │ 批量执行  │    │ Judge 评分 │    │ + 阻断规则 │
└──────────┘    └──────────┘    └───────────┘    └──────────┘

四个级别的 Eval 方法：

LLM-as-Judge 实现示例：

EVAL_PROMPT = """你是一个严格的评测员。请对以下 AI 回答评分（1-5 分）。

评分维度：
- 准确性：回答是否事实正确
- 完整性：是否覆盖了问题的所有要点
- 简洁性：是否有冗余或无关内容

用户问题：{question}
AI 回答：{answer}

请返回 JSON：{"accuracy": int, "completeness": int, "conciseness": int, "overall": int}
"""

3. 主流 AI 可观测性工具对比（2026）

选型建议：如果团队已经深度使用 LangChain/LangGraph → LangSmith；如果需要最快接入且预算有限 → Helicone；如果有自建基础设施能力且重视数据安全 → Arize Phoenix 或 Langfuse。

4. 落地路线图：从零搭建 AI 可观测性

最小可行方案（当天可完成）：

# 使用 Helicone 的 Proxy 模式，一行代码零侵入接入
# 将 OpenAI 的 base_url 替换为 Helicone 网关
# 所有请求自动记录 Trace + Metrics + Cost

# 原代码：
# client = OpenAI(api_key="sk-xxx")

# 改为：
client = OpenAI(
    api_key="sk-xxx",
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer YOUR_HELICONE_API_KEY"
    }
)
# 完成。所有调用自动出现在 Helicone Dashboard 中。

总结

AI 可观测性是 LLM 应用从”能跑”到”能放心跑”的分水岭。三个核心要点：

1. Trace 让你”看见”每次请求的完整路径——这是排查幻觉和错误的第一现场
2. Metrics 让你”量化”系统的健康状态——重点关注幻觉率、Token 成本和检索命中率
3. Evaluation 让你”守住”质量底线——每次变更前自动跑回归，不让退化上线

延伸阅读

• 本系列 什么是 RAG？ —— 理解 RAG 架构是做好可观测性的前提
• 本系列 什么是 Agent 记忆系统？ —— Agent 场景下的状态追踪
• 本系列 什么是 MCP 协议？ —— MCP 工具调用的 Trace 埋点
• 官方文档：OpenTelemetry GenAI Semantic Conventions
• 实操平台：LangSmith / Helicone / Arize Phoenix 官方 Quickstart （内容由AI生成，仅供参考）