AI 应用的可观测性：从 Tracing 到评估
为什么需要 AI 可观测性
传统应用的可观测性（日志、指标、追踪）对 AI 应用远远不够。LLM 的非确定性、高成本、幻觉风险带来了新的可观测性需求：
- LLM 输出的质量如何，而不只是"是否返回 200"
- 每次调用花了多少 token、多少钱
- Agent 做了什么推理、调用了哪些工具
- RAG 检索到了什么、是否相关
AI 可观测性的四层体系
Layer 1: 调用追踪 (Tracing)
记录每次 LLM 调用的完整链路：
{
"trace_id": "abc123",
"span": [
{"name": "orchestrator.route", "duration": 45ms},
{"name": "rag.retrieve", "duration": 120ms,
"metadata": {"chunks": 3, "sources": ["hr_policy.pdf"]}},
{"name": "llm.generate", "duration": 850ms,
"metadata": {"model": "deepseek-v4-flash", "tokens_in": 2048, "tokens_out": 312}},
{"name": "tool.get_leave_balance", "duration": 30ms},
{"name": "review.check", "duration": 60ms,
"metadata": {"passed": true}}
]
}Layer 2: 质量评估 (Evaluation)
- LLM-as-a-Judge：用另一个 LLM 评估回答质量（事实性、完整性、安全性）
- RAGAS 指标：Faithfulness（忠实度）、Answer Relevancy、Context Precision
- 人工标注：采样回答让人类评分，建立黄金标准
- 对比测试：A/B 测试不同 Prompt 版本的效果
Layer 3: 监控 (Monitoring)
| 指标 | 含义 | 告警阈值 |
|---|---|---|
| Token 消耗 | 每次会话 LLM 调用总量 | 超预算时告警 |
| 检索召回率 | 知识库匹配质量 | <60% 告警 |
| 路由准确率 | Orchestrator 正确分发 | <85% 告警 |
| 工具调用成功率 | 工具执行成功比例 | <95% 告警 |
| 端到端延迟 | 用户感知延迟 | >5s 告警 |
Layer 4: 调试 (Debugging)
- Prompt 回放：重现任意一次推理的完整 Prompt
- Trace 查看器：可视化 Agent 链路的每一步
- Session 重放：回放用户对话 + 系统响应过程
工具选型
| 工具 | 开源 | 特点 |
|---|---|---|
| LangSmith | 否 | LangChain 全家桶，功能最全 |
| LangFuse | 是 | 自托管，支持 Prompt 管理 + Tracing + 评估 |
| OpenTelemetry | 是 | 标准协议，可自定义导出到任何后端 |
| Phoenix (Arize) | 是 | LLM 评估 + 可观测性，Python 友好 |
| MLflow | 是 | 传统实验管理 + AI 追踪 |
最小化可观测性方案
如果不想引入外部工具，最低成本方案：
- JSONL 落盘记录每次对话的 tracing 数据
- CLI 一键运行评估脚本
- 前端展示 Trace 摘要（推理链路流程图）