深色模式
线上效果监控与回归
摘要：传统监控（延迟、错误率、吞吐）只能证明"系统活着"，证明不了"答得对"。本文给出 LLM 可观测的三支柱（trace + 指标/评测 + 真实上下文分析），定义面向质量的 SLO，演示 PII 掩码、抽样评测、失败案例回流闭环，以及模型/供应商更新导致退化的告警与回滚。工具以 LangSmith / Langfuse / Arize Phoenix 为参考。
核心概念：为什么传统 APM 不够
Agent / LLM 是非确定性的：同一输入多次运行可能走不同工具链、检索不同文档、生成不同答案。APM 显示 p95 延迟正常、错误率 0，但 Agent 可能自信地给了错误答案、选了错工具、陷入推理死循环。
LLM 可观测三支柱（LangChain 框架）
- Monitoring & Tracing：实时指标 + 逐步执行路径（每个 LLM 调用、工具调用、检索结果）。
- Metrics & Evals：自动 + 人工质量打分，按你定义的业务标准。
- Real-world Context Analysis：理解用户真实交互（多变意图、仅在生产出现的边缘情况）。
关键指标分层
| 类别 | 技术测量 | 运维意义 |
|---|---|---|
| 工具延迟 | p50/p95/p99 响应时间 | 是否满足 UX 要求 |
| Token 用量 | 每 trace 输入+输出 token | 成本归因到具体步骤 |
| 错误率 | 异常/超时/工具失败 | 基础设施稳定性 |
| 质量/Eval | 自定义质量标准自动打分 | 回答是否真正满足需求 |
延迟低 ≠ 质量好
成本与延迟易测，但"答案质量"必须靠显式 eval。这正是可观测平台把 eval 与基础设施 dashboard 并置的原因。
操作步骤：搭建线上监控
1. 接入 trace（以 LangSmith 风格为例）
python
# 通过环境变量开启 tracing（具体 SDK 依所选平台）
import os
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_API_KEY"] = os.getenv("LS_KEY")
os.environ["LANGSMITH_PROJECT"] = "my-agent-prod"
# 区分环境项目，便于对比基线
# my-agent-dev / my-agent-staging / my-agent-prod1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
不同平台 SDK 不同（Langfuse 用 langfuse decorator，Phoenix 用 openinference），但核心都是把每次运行的结构化 trace（runs）上报。[版本相关：API 随平台版本演进，未实测固定版本号]
2. PII 掩码（入库前强制）
python
from langsmith import Client
client = Client(
hide_inputs=lambda inputs: redact_pii(inputs), # 入参脱敏
hide_outputs=lambda outputs: redact_pii(outputs), # 出参脱敏
)
# 或全局开关（调试更难，慎用）
# os.environ["LANGSMITH_HIDE_INPUTS"] = "true"
# os.environ["LANGSMITH_HIDE_OUTPUTS"] = "true"1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
掩码应在记录前，而非记录后
一旦 PII 写入 trace 存储即为泄露事件。务必在 redact 后再上报；保留其余字段可见以便调试。详见 dataset.md 的脱敏红线。
3. 抽样评测（不要全量）
python
# 仅对 1%-5% 生产流量做自动评测，控制 judge 成本
import random
def should_eval(trace):
return random.random() < 0.05 # 5% 抽样
# 在线评测器：至少覆盖 safety + format 校验
ONLINE_EVALUATORS = ["safety_check", "format_validation", "groundedness"]1
2
3
4
5
6
7
2
3
4
5
6
7
4. 定义质量 SLO 与告警
yaml
# 监控告警阈值（示例，按业务调整）
slo:
p95_latency_s: 2.5
citation_accuracy: 0.90 # RAG 场景引用准确率
safe_response_rate: 0.995 # 安全响应率
groundedness_rate: 0.92 # 有据可依率
alerts:
- "avg_latency > 3s -> Slack"
- "error_rate > 5% -> PagerDuty"
- "cost_per_trace > $0.05 -> Email"
- "eval_score < 0.7 -> 阻断发布"1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
SLO 数值为示例区间 [未实测，需结合你的 UX 与预算]；引用准确率、安全率等来自可观测实践文档（p95 ≤2.5s、safe-response ≥99.5% 等作为参考量级，见 LangChain 资源）。
失败回流闭环（最重要）
让 Agent 越用越好
最值钱的循环：线上失败 → 进数据集 → 离线 eval → 修复 → 离线验证 → 发布。没有这个闭环只在修症状；有它才在积累回归覆盖。有团队把每个被用户拒绝的推荐都加入集，3 个月内匹配准确率从 72% 升到 91%（案例见 LangSmith 生产实践）。
验证
- trace 完整性：构造一条测试请求，确认在 dashboard 看到完整执行树（含工具调用、检索、模型输出）。
- PII 掩码：用含敏感字段的测试输入，确认存储中该字段已被脱敏。
- 评测生效：人为注入一条已知坏答案，确认在线评测器标记 + 告警触发。
- 回滚演练：发布后观察 eval 分下跌，确认能快速回滚到上一稳定版本。
回滚 / 清理
模型/供应商更新是隐性风险
你没改代码，但供应商侧模型更新可能让效果退化（漂移）。对策：① 固定模型版本/pin 部署；② 线上抽样 eval 持续对比；③ 跌破 SLO 立即回滚到上一已知良好版本。
bash
# 回滚到上一稳定部署（示意，依你的发布系统）
kubectl rollout undo deployment/my-agent -n prod
# 或切流量到 pinned 旧模型版本1
2
3
2
3
- trace 数据按保留策略清理，平衡存储成本与排障需要；敏感行业缩短保留期。
- 失败的坏 trace 已回流数据集后可从生产存储降采样，但保留于评测集（脱敏）。
故障排查
| 现象 | 原因 | 处理 |
|---|---|---|
| APM 健康但用户投诉答错 | 缺质量 eval | 上线最小 safety+format+groundedness 评测器 |
| 成本突增 | 某子步骤 token 爆炸/死循环 | trace 定位高消耗步骤，加步数上限 |
| PII 出现在 trace | 掩码在记录后 | 改为记录前 redact，审计已泄露数据 |
| eval 分虚高 | judge 未校准 | 回到 auto-human.md 做 Kappa 校准 |
| 退化但无人发现 | 无抽样 eval | 加 1–5% 抽样评测 + 告警 |
安全与合规
线上监控特有合规项
- PII 入 trace：如上，记录前脱敏，且按最短留存原则清理。
- 评测数据泄露：回流数据集的样本必须脱敏（dataset.md）。
- 提示注入 / 越权：线上需 guardrails 拦截注入与敏感数据出网（见 eval.md 安全红线）。
- 审计留痕：trace 是事故复盘证据，保留期需满足合规要求但不过度收集。
成本 / 性能
- trace 存储：结构化 trace 有存储成本，按保留策略与采样控制；高流量（>1000 运行/天）需采样与分层。
- 抽样评测：仅 1%–5% 流量上 judge，避免全量成本爆炸；核心回归项可提高采样。
- 告警降噪：区分瞬态（限流）与系统性问题，避免告警疲劳；设 runbook 自动回滚阈值。
参考资料
- LangChain：Why LLM observability and monitoring need evaluations
- LangChain：AI Agent Observability: Tracing, Testing, and Improving Agents
- LangSmith in Production: Observability, Evaluation, and Debugging（PII 掩码与 SLO 实践）
- Curotec：LLMOps for AI That's Already Live（可观测工具栈）
- By AI Team：LLM Observability: Trace, Debug, Monitor AI Pipelines（SLO 示例）