可观测性与 LLM 追踪

五层读懂一个词。这次拆的是：LLM 可观测性--从「能跑」到「可控」的关键一跃。LLM 调用栈不是传统的请求-响应，而是 LLM 调用 → 工具调用 → 检索 → 又一轮 LLM → 输出——一条链可能十几次 API 调用。可观测性 = 追踪（Trace 每条链的每一步）+ 评估（自动打分）+ 监控（异常告警）+ 调试（定位问题）。核心工具：LangSmith / Langfuse / Weights & Biases / OpenTelemetry。

L1 · 一句话点破

LLM 可观测性 = 分布式追踪 + 质量评估 + 成本监控 + 异常告警的融合。因为 LLM 应用不是单体函数调用，而是一串 LLM/检索/工具调用的 pipeline——你需要看到每一步的输入、输出、延迟、token 消耗、中间结果。LangSmith（LangChain 生态）和 Langfuse（开源、自托管）是当前两大主流方案。没有可观测性，LLM 应用上线就是盲飞。

L2 · 通俗类比

传统应用的监控很简单：

[请求] → [查数据库] → [返回响应]
         ↑
    延迟 10ms，结果 1 条

监控延迟、错误率、吞吐量就够了。

LLM 应用的监控像「团队协作项目」的追踪：

用户: "分析这份财报" →
  [LLM 调用 1: 理解任务, 0.5s, 200 token] →
  [检索: 向量搜索, 0.1s, 5 docs] →
  [LLM 调用 2: 分析文档 1-2, 1.2s, 500 token] →
  [工具调用: 计算器, 0.05s] →
  [LLM 调用 3: 综合所有分析, 0.8s, 400 token] →
  输出: "这份财报显示..."

你需要知道：

每一步花了多少时间？（慢在哪一步）
每一步消耗了多少 token？（成本多少）
检索到了什么？（搜对了吗）
LLM 中途的思考是什么？（中间结果对了吗）
最终质量怎么样？（Faithfulness / Relevance）

LangSmith/Langfuse = 为 LLM 管道装的「行车记录仪」：

记录每一步的输入输出
可视化整个调用链
自动评分
发现问题时可以回放整个 trace

三支柱：

支柱	语言	具体
Trace（追踪）	查调用链	每个请求的完整链路
Evaluate（评估）	测质量	自动打分 + 人工标注
Monitor（监控）	看趋势	延迟/cost/质量曲线

对比：

维度	传统监控（Datadog/Prometheus）	LLM 可观测性（LangSmith/Langfuse）
追踪粒度	服务级（API 延迟）	调用级（每次 LLM/检索/工具）
评估内容	错误率/延迟/吞吐	+ token 消耗 + 质量分数 + 忠实度
调试方式	看日志 → grep	看 trace 树 → 点开每一步
数据形式	JSON 日志	结构化 Trace（input/output/metadata）

代价：

集成成本（框架适配）
额外的延迟（trace 上报有少量开销）
工具成熟度（LLM 可观测性仍在快速迭代）
数据隐私（trace 数据可能包含敏感内容）

适用：

所有 LLM 应用的开发、测试、上线
RAG 管道的质量监控
Agent 系统的行为审计
成本分析（哪个环节最费 token）

L3 · 正经定义

LLM 可观测性（LLM Observability）：指对 LLM 应用的内部运行状态进行结构化记录、可视化和分析的能力。核心包括：

Trace：记录一次请求的完整调用链路（LLM 调用、检索、工具调用、中间结果），树状结构
Span：Trace 中的单个步骤（如一次 LLM 调用、一次检索）
Feedback：对 Trace 输出的人工或自动评分（如 thumbs up/down、RAGAS 分数）
Monitor：在反馈和指标之上构建的监控面板和告警

主流工具：

工具	定位	开源	核心特色
LangSmith	LangChain 官方	❌（SaaS）	LangChain 深度集成
Langfuse	开源可观测性	✅	自托管、OAS 兼容
Weights & Biases	MLOps	部分	Traces + 模型训练
OpenTelemetry	通用标准	✅	厂商中立
Helicone	LLM API 代理	✅	轻量、API 层
Phoenix (Arize)	LLM 可观测	✅	Embedding 可视化
Braintrust	LLM 评估平台	✅	Eval-driven 开发

参考资料：

🔧 LangSmith：https://smith.langchain.com/
🔧 Langfuse：https://github.com/langfuse/langfuse
📝 OpenTelemetry GenAI：https://opentelemetry.io/docs/specs/semconv/gen-ai/
📝 W&B Weave：https://weave-docs.wandb.ai/

L4 · 原理深挖

4.1 Trace 的核心结构

Trace = 树状的 Span 层级：

Trace (run_id: xxx, user: "alice", session: "chat-123")
├── Span: LLM Call (name: "gpt-4", model: "gpt-4", tokens: 350)
│   input: "分析财报..."
│   output: "我需要先搜索相关数据..."
│
├── Span: Retriever (name: "vector_search", top_k: 3)
│   input: "Q3 财报 营收"
│   output: [{doc_1}, {doc_2}, {doc_3}]
│
├── Span: LLM Call (name: "gpt-4", model: "gpt-4", tokens: 1200)
│   input: [检索结果 + 分析指令]
│   output: "根据财报数据，Q3 营收增长了 15%..."
│
└── Span: Tool (name: "calculator")
    input: "15 / 100 * 100"
    output: "15"

每个 Span 记录：

name：步骤名（LLM 调用 / 检索 / 工具）
input / output：该步骤的输入输出
metadata：模型名、参数、token 数、延迟
parent_span_id：父子关系
error：如果失败，记录错误信息

4.2 LangSmith 集成示例

python

from langsmith import traceable, Client

# 自动追踪
@traceable(name="rag_pipeline")
def rag_pipeline(question: str):
    # Step 1: 检索
    docs = search(question)
    # Step 2: 生成
    answer = llm.generate(question, docs)
    return answer

# 或显式记录
from langsmith import trace

with trace(name="user_query", inputs={"question": question}) as rt:
    docs = search(question)
    rt.add_metadata({"num_docs": len(docs)})

    answer = llm.generate(question, docs)
    rt.end(outputs={"answer": answer, "num_tokens": 350})

在 LangSmith UI 中查看：

Trace 瀑布图（每步的延迟和重叠）
搜索/筛选（找所有 Faithfulness < 0.5 的 trace）
对比两个 trace（查看 A/B 测试差异）
添加人工标注（👍 / 👎 + 理由）

4.3 Langfuse 集成示例

python

from langfuse import Langfuse

langfuse = Langfuse(
    public_key="pk-...",
    secret_key="sk-...",
)

# 创建 trace
trace = langfuse.trace(
    name="rag_pipeline",
    user_id="user_123",
    session_id="chat_456",
)

# 添加 span
span = trace.span(
    name="retrieve",
    input={"query": question},
)
docs = search(question)
span.end(output={"documents": docs})

span2 = trace.span(
    name="generate",
    input={"question": question, "documents": docs},
)
answer = llm.generate(question, docs)
span2.end(
    output={"answer": answer},
    metadata={"model": "gpt-4", "tokens": 350, "latency_ms": 800},
)

# 评分
trace.score(name="faithfulness", value=0.85)
trace.score(name="user_feedback", value=1)  # 👍

Langfuse 的优势：

开源可自托管（数据不出企业）
OpenAI API 格式兼容（可作代理自动追踪）
自带评估功能（可关联 RAGAS/LangChain eval）
成本追踪（按 model × tokens 自动计算花费）

4.4 评估（Evaluation）

在线评估（每次请求自动评分）：

python

# 每次 RAG 调用后自动打分
score = ragas.evaluate(question, answer, contexts)
langfuse.score(
    trace_id=trace.id,
    name="ragas_faithfulness",
    value=score["faithfulness"],
)
langfuse.score(
    trace_id=trace.id,
    name="ragas_relevance",
    value=score["answer_relevancy"],
)

离线评估（定期全量评估）：

python

# 每晚从生产日志中采样 100 条
samples = get_production_samples(n=100)
eval_result = evaluate(samples, metrics)

# 对比上周
if eval_result["faithfulness"] < last_week * 0.9:
    alert("Faithfulness degradation detected")

人工评估（关键 case 人工复核）：

LangSmith/Langfuse 提供标注队列
对自动评分低的 case 做人工复核
积累人工标注数据 → 改进自动评估

4.5 监控（Monitoring）

关键指标：

指标类型	指标	告警条件
质量	Faithfulness	< 0.7 持续 1 小时
质量	Answer Relevance	< 0.6
延迟	P99 LLM 延迟	> 5s
延迟	P99 总延迟	> 10s
成本	每小时 token 消耗	> 预算 × 1.2
成本	每次请求平均成本	> $0.01
错误	LLM 调用失败率	> 1%
错误	检索返回空率	> 5%

Dashboards：

延迟分布（P50/P90/P99）
成本趋势（按日/按模型/按用户）
质量趋势（Faithfulness/Relevance 随时间变化）
用户反馈（👍/👎 比例）
Token 消耗热力图（哪个环节最费 token）

4.6 成本追踪

LLM 调用的成本不可忽视：

python

# 自动追踪每个请求的成本
cost = (
    prompt_tokens / 1000 * PROMPT_PRICE +
    completion_tokens / 1000 * COMPLETION_PRICE
)

# GPT-4: prompt $0.03/K, completion $0.06/K
# 一个 RAG 请求: 500 prompt + 200 completion + 2 次检索
# = 0.7K prompt tokens × 2 + 0.2K completion × 2
# = $0.042 + $0.024 = $0.066/请求
# 1 万次请求/天 = $660/天 = $20,000/月

成本优化：

用 LangSmith/Langfuse 的 cost 面板识别最费钱的环节
是否检索太多文档（top_k 设太大）
是否 Prompt 太长（减少 few-shot 示例数）
是否 LLM 调用太多（Agent 循环过度）

4.7 调试

典型调试流程：

用户反馈: "RAG 回答不对"

1. 在 LangSmith 搜索该用户的 session_id
2. 找到对应的 trace
3. 展开 trace，查看每一步:
   - 检索到了什么？（Context Precision 低？）
   - LLM 的中间推理是什么？
   - Token 消耗正常吗？
4. 定位问题 → 修复 → 重新部署
5. 对这类 case 添加回归测试

常见问题定位：

现象	在 Trace 中看什么
回答不对	检查检索结果是否包含正确信息
回答太慢	查看 LLM 调用的延迟占比
成本暴涨	查看 token 消耗异常的那一步
Agent 循环不停止	查看循环的 Span 数量和 Thought
输出格式错	查看最后一步 LLM 的 output

4.8 局限

局限 1: 数据隐私。Trace 中可能有用户输入、文档内容等敏感信息。自托管 Langfuse 是更好选择。

局限 2: 额外的延迟。trace 上报增加 ~50-200ms（取决于网络和工具）。对延迟敏感的场景要注意。

局限 3: 工具碎片化。LangSmith/Langfuse/W&B/Helicone/Phoenix——生态不统一，切换成本高。

局限 4: 自动评估的准确性。LLM-as-Judge 评分 ~85% 准确，不是 100%。

局限 5: 只追踪框架内的调用。原生 OpenAI API 调用需要手动插桩。

局限 6: 告警阈值调优。太敏感 → alert fatigue，太宽松 → 漏掉问题。

局限 7: 历史数据管理。Trace 数据量大（每天万级），存储成本高。

局限 8: 隐私合规（GDPR 等）。Trace 中可能有 PII，需要考虑数据治理。

L5 · 沿革与坑

5.1 沿革

2023-07：LangSmith 内测（LangChain），首次提出 LLM 可观测性概念
2023-09：Langfuse 开源，自托管替代方案
2023-12：Helicone 发布，API 层轻量追踪
2024-02：LangSmith GA，添加自动评估和人工标注
2024-03：OpenTelemetry GenAI 工作组成立（标准化 LLM trace 语义）
2024 中：W&B Weave、Arize Phoenix 等加入
2024-2025：LLM 可观测性从「nice-to-have」变为「必备」

5.2 常见坑

坑 1: 上线了 LLM 应用但不加可观测性。出了问题无法排查。上线前就集成。

坑 2: 只追踪 LLM 调用不追踪检索。定位不全面。检索质量是 RAG 的关键。

坑 3: 把 token 消耗等同于用户输入。系统消息、历史对话等都消耗 token。要全量追踪。

坑 4: 监控告警阈值拍脑袋。设了阈值但没验证 → alert 没意义。要基于历史数据设 P95/P99。

坑 5: 不做定期离线评估。在线反馈稀疏（用户很少点 👍/👎），需要离线批量评估补足。

坑 6: LangSmith vs Langfuse 纠结太久。两个都行。要自托管选 Langfuse，和 LangChain 深度绑定选 LangSmith。

坑 7: 忽略 trace 的存储成本。每天几十万的 trace，存储量 TB 级。要设保留策略。

坑 8: 生成评估的 prompt 不看。自动评估用的 prompt 是默认的，可能不适合你的领域。要定制。

坑 9: 用户反馈收集不做结构化。👍/👎 太粗糙。让用户写一句话说明为什么差。

坑 10: 看成本指标但不管。成本涨了 50% 但质量没涨？要分析每类请求的 ROI。

坑 11: 离线评估用不同模型。评估用的 LLM 和生产环境不同 → 指标不可比。要统一。

坑 12: A/B 测试不做可观测性对比。换了个 RAG 策略但不知道效果。要在 trace 上加 tag 区分。

5.3 面试怎么考

LLM 可观测性包含什么？ 答：Trace（完整调用链记录）、Evaluate（自动/人工评分）、Monitor（指标趋势+告警）、Cost（token 消耗）。四者融合，不是单独的日志系统。
LangSmith 和 Langfuse 的区别？ 答：LangSmith 是 LangChain 官方 SaaS，与 LangChain 深度集成；Langfuse 开源可自托管，兼容 OpenAI API。前者方便，后者灵活。
一个 RAG Trace 里有哪些 Span？ 答：用户请求 → LLM 规划 → 检索（向量搜索）→ LLM 生成 → （可选工具调用）→ 最终回复。也有评估 Span（事后打分）。
可观测性怎么帮助调试？ 答：用户反馈问题 → 搜 session 找到 trace → 展开每一步的输入/输出 → 定位问题（检索错误？LLM 编造？）→ 修复 → 回归验证。
Cost 追踪为什么重要？ 答：LLM 应用的成本是隐藏的（token 消耗），不同请求成本差异大（Agent 循环 vs 简单 QA）。追踪成本才能优化 ROI。

速记卡

可观测性三支柱 + 成本：

Trace（追踪）: 树状记录每个请求的完整链路
Evaluate（评估）: 自动打分 + 人工标注
Monitor（监控）: 指标趋势 + 异常告警
Cost（成本）: token 消耗 + 费用归因

Trace 树示例：

Trace
├── Span: LLM Call (0.5s, 200 tok)
├── Span: Retriever (0.1s, 5 docs)
├── Span: LLM Call (1.2s, 500 tok)
├── Span: Tool (0.05s)
└── Span: LLM Call (0.8s, 400 tok)

主流工具：

工具	开源	特点
LangSmith	❌ SaaS	LangChain 深度集成
Langfuse	✅	自托管，OAS 兼容
W&B Weave	部分	Traces + 模型训练
Helicone	✅	API 层轻量
Phoenix	✅	Embedding 可视化

关键监控指标：

维度	指标
质量	Faithfulness, Relevance
延迟	P50/P99 LLM延迟, 总延迟
成本	Token消耗/请求, $/天
错误	LLM失败率, 检索空率

一句话记忆：LLM 可观测性 = Trace（完整调用链）+ Evaluate（质量评分）+ Monitor（指标告警）+ Cost（token 成本）。因为 LLM 应用是多步 pipeline（LLM→检索→LLM→工具→LLM），需要看到每一步的输入、输出、延迟、token。LangSmith（SaaS + LangChain 深度集成）和 Langfuse（开源自托管 + OpenAI 兼容）是两大主流。没有可观测性 = LLM 应用盲飞。用于开发期调试、上线期监控、迭代期 A/B 对比。局限：数据隐私、额外延迟、自动评估 85% 准确、工具碎片化。

上一篇：RAGAS RAG 评估框架 -- RAGAS 测 RAG 质量，可观测性把它集成到生产监控中。下一篇预告：多模态专题 -- ViT / CLIP / Stable Diffusion / 多模态 LLM，从文本走向视觉。

可观测性与 LLM 追踪 ​

L1 · 一句话点破 ​

L2 · 通俗类比 ​

L3 · 正经定义 ​

L4 · 原理深挖 ​

4.1 Trace 的核心结构 ​

4.2 LangSmith 集成示例 ​

4.3 Langfuse 集成示例 ​

4.4 评估（Evaluation） ​

4.5 监控（Monitoring） ​

4.6 成本追踪 ​

4.7 调试 ​

4.8 局限 ​

L5 · 沿革与坑 ​

5.1 沿革 ​

5.2 常见坑 ​

5.3 面试怎么考 ​

速记卡 ​

可观测性与 LLM 追踪

L1 · 一句话点破

L2 · 通俗类比

L3 · 正经定义

L4 · 原理深挖

4.1 Trace 的核心结构

4.2 LangSmith 集成示例

4.3 Langfuse 集成示例

4.4 评估（Evaluation）

4.5 监控（Monitoring）

4.6 成本追踪

4.7 调试

4.8 局限

L5 · 沿革与坑

5.1 沿革

5.2 常见坑

5.3 面试怎么考

速记卡