- 引言:为什么需要 LLM 监控
- LLM Observability 核心指标
- LangSmith 架构与实战
- LangFuse 架构与实战
- Arize Phoenix 架构与实战
- 三方对比
- 提示词版本管理与 A/B 测试
- 评估流水线自动化
- 故障案例与恢复策略
- 选型指南:哪个平台适合我们团队?
- 运维注意事项
- 结语
- 参考资料
- 小测验

引言:为什么需要 LLM 监控
"只改了一个提示词,回答质量突然就变差了。"只要在生产环境运营过基于 LLM 的服务,团队大概率都遇到过这种情况。传统软件只要不改代码,同样的输入就保证得到同样的输出。但 LLM 从根本上不同。
非确定性(Non-deterministic)输出:即使用同一个提示词、同一个输入,LLM 的响应每次都会不同。这与 temperature 设置有关,但即便设为 0,也不能保证完全一致。这意味着仅靠传统的单元测试,无法验证 LLM 应用的质量。
隐藏的成本暴涨:GPT-4o 的输入 token 成本是 $2.50/1M tokens,输出是 $10.00/1M tokens。一条提示词若包含系统提示词、对话历史、RAG 上下文,单次调用就可能消耗数千个 token。若生产流量达到每秒 100 次请求,没有监控的话,月度成本可能高达数万美元。
提示词回归(Prompt Regression):提示词看似被"改进"了,实际上却在某些场景下质量下降。假设提示词 A 摘要质量出色但代码生成能力弱,提示词 B 恰好相反,要定量判断哪个才是"更好"的提示词,就离不开一套系统化的评估流水线。
幻觉(Hallucination)监控:LLM 自信地生成非事实内容的幻觉现象,是生产服务中最危险的问题。尤其在金融、医疗、法律领域,幻觉会直接转化为业务风险。
正因如此,LLM Observability(可观测性)已从可选项变为必需品。本文将结合实战代码,对比 2026 年当下使用最广泛的三大 LLM 监控平台——LangSmith、LangFuse、Arize Phoenix,并给出团队选型的判断标准。
LLM Observability 核心指标
LLM 监控中需要追踪的核心指标,与传统 APM 有相当大的差异。
| 指标类别 | 具体指标 | 说明 | 目标值示例 |
|---|---|---|---|
| Latency | TTFT (Time to First Token) | 到第一个 token 为止的时间 | < 500ms |
| Latency | Total Latency | 整体响应完成时间 | < 3s |
| Latency | Tokens per Second | 每秒 token 生成速度 | > 50 tokens/s |
| Cost | Input Token Count | 输入 token 数 | 持续监控 |
| Cost | Output Token Count | 输出 token 数 | 持续监控 |
| Cost | Cost per Request | 单次请求成本 | < $0.01 |
| Cost | Monthly Cost | 月度总成本 | 预算范围内 |
| Quality | Relevance Score | 响应的相关性得分 | > 0.8 |
| Quality | Faithfulness Score | 对 RAG 上下文的忠实度 | > 0.9 |
| Quality | Hallucination Rate | 幻觉发生率 | < 5% |
| Quality | User Feedback | 用户满意度(thumbs up/down) | > 80% 正面 |
| Reliability | Error Rate | API 调用失败率 | < 0.1% |
| Reliability | Retry Rate | 重试比例 | < 1% |
| Reliability | Rate Limit Hit Rate | API 限流触达比例 | < 0.01% |
系统化地采集并可视化这些指标,正是 LLM Observability 平台的核心作用。
LangSmith 架构与实战
LangSmith 是 LangChain 团队开发的官方 LLM Observability 平台。它最大的优势是与 LangChain 框架的原生集成,但即便不使用 LangChain 或 LangGraph 的项目,也能独立使用它。
核心架构
LangSmith 以 追踪(Trace) -> 运行(Run) -> 跨度(Span) 三层结构采集数据。一次用户请求对应一个 Trace,其中的每次 LLM 调用、工具执行、链式步骤都作为 Run 记录下来。
Python 代码示例:LangSmith 追踪配置
import os
import openai
from langsmith import traceable, Client
from langsmith.wrappers import wrap_openai
# 1. 环境变量设置
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_API_KEY"] = "lsv2_pt_xxxxxxxxxxxx"
os.environ["LANGSMITH_PROJECT"] = "production-chatbot"
os.environ["LANGSMITH_ENDPOINT"] = "https://api.smith.langchain.com"
# 2. 用 LangSmith 包装 OpenAI 客户端(自动追踪)
client = wrap_openai(openai.Client())
# 3. 用 @traceable 装饰器追踪自定义函数
@traceable(
name="RAGPipeline",
run_type="chain",
tags=["production", "rag"],
metadata={"version": "2.1.0"}
)
def rag_pipeline(user_query: str) -> dict:
"""RAG 流水线:检索 -> 构建上下文 -> LLM 调用"""
# 检索阶段(自动记录为子 Span)
context_docs = retrieve_documents(user_query)
# 构建提示词
system_prompt = """당신은 기술 문서 기반 Q&A 어시스턴트입니다.
주어진 컨텍스트만을 바탕으로 답변하세요.
컨텍스트에 없는 내용은 "해당 정보를 찾을 수 없습니다"라고 답하세요."""
context_text = "\n\n".join([doc["content"] for doc in context_docs])
user_message = f"컨텍스트:\n{context_text}\n\n질문: {user_query}"
# LLM 调用(通过 wrap_openai 自动追踪)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_message}
],
temperature=0.1,
max_tokens=1024
)
result = {
"answer": response.choices[0].message.content,
"sources": [doc["source"] for doc in context_docs],
"model": "gpt-4o",
"token_usage": {
"input": response.usage.prompt_tokens,
"output": response.usage.completion_tokens,
"total": response.usage.total_tokens
}
}
return result
@traceable(name="DocumentRetrieval", run_type="retriever")
def retrieve_documents(query: str) -> list:
"""从向量数据库检索相关文档"""
# 实际实现中会用到 Pinecone、Weaviate 等
# 这里为了示例做了简化
from langsmith import get_current_run_tree
run = get_current_run_tree()
run.metadata["retriever_type"] = "pinecone"
run.metadata["top_k"] = 5
# ... 向量检索逻辑 ...
return [{"content": "검색된 문서 내용", "source": "docs/guide.md", "score": 0.95}]
# 4. 用 LangSmith 客户端记录反馈
ls_client = Client()
def record_user_feedback(run_id: str, score: float, comment: str = ""):
"""将用户反馈记录到 LangSmith"""
ls_client.create_feedback(
run_id=run_id,
key="user_satisfaction",
score=score, # 0.0 ~ 1.0
comment=comment
)
# 5. 执行
if __name__ == "__main__":
result = rag_pipeline("Kubernetes Pod의 OOMKill 원인은?")
print(f"답변: {result['answer']}")
print(f"토큰 사용: {result['token_usage']}")
LangSmith 的 wrap_openai 会自动追踪 OpenAI 客户端的所有调用。无需额外改动代码,模型名称、token 用量、响应时间就会被自动记录下来。@traceable 装饰器为自定义函数添加追踪,run_type 用来区分 Span 的类型。
LangFuse 架构与实战
LangFuse 是一款开源的 LLM Observability 平台,最大的差异化点在于支持自托管(self-hosting)。只需一条 Docker Compose 命令即可部署到自有基础设施上,并且保证与云端版本的功能对等性(feature parity)。2025 年 6 月发布的 Python SDK v3 基于 OpenTelemetry 重写,提供了更稳定的追踪能力。
Python 代码示例:基于装饰器的 LangFuse 追踪
import os
from langfuse import observe, get_client
from langfuse.openai import openai # LangFuse 包装的 OpenAI
# 1. 环境变量设置(自托管时需修改 LANGFUSE_HOST)
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-lf-xxxxxxxxxxxx"
os.environ["LANGFUSE_SECRET_KEY"] = "sk-lf-xxxxxxxxxxxx"
os.environ["LANGFUSE_HOST"] = "https://cloud.langfuse.com" # 自托管:http://localhost:3000
# 2. 用 @observe 装饰器追踪
@observe()
def chatbot_pipeline(user_message: str, session_id: str) -> dict:
"""
LangFuse 的 @observe 装饰器会自动把函数的输入输出、
执行时间记录为一条 Trace。
"""
# 加载对话历史(自动生成子 Span)
history = load_conversation_history(session_id)
# LLM 调用(使用 langfuse.openai 模块时自动追踪)
response = openai.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "당신은 친절한 고객 지원 챗봇입니다."},
*history,
{"role": "user", "content": user_message}
],
temperature=0.3,
langfuse_prompt_name="customer-support-v3", # 提示词版本追踪
)
answer = response.choices[0].message.content
# 记录质量得分
langfuse_client = get_client()
langfuse_client.score(
name="relevance",
value=evaluate_relevance(user_message, answer),
comment="자동 평가"
)
return {
"answer": answer,
"session_id": session_id,
"tokens": response.usage.total_tokens
}
@observe()
def load_conversation_history(session_id: str) -> list:
"""按会话加载对话历史"""
# 从 Redis 或数据库查询对话历史
# ...
return []
@observe()
def evaluate_relevance(question: str, answer: str) -> float:
"""用 LLM-as-a-Judge 评估相关性"""
judge_response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[{
"role": "user",
"content": f"""다음 질문에 대한 답변의 관련성을 0.0~1.0 사이 숫자로만 평가하세요.
질문: {question}
답변: {answer}
점수:"""
}],
temperature=0.0,
max_tokens=5
)
try:
return float(judge_response.choices[0].message.content.strip())
except ValueError:
return 0.5
# 自托管 Docker Compose 执行方式:
# git clone https://github.com/langfuse/langfuse.git
# cd langfuse
# docker compose up -d
LangFuse 的 @observe() 装饰器与 LangSmith 的 @traceable 类似,但有几点差异。LangFuse 会自动把嵌套的函数调用映射为父子 Span 关系,并通过 langfuse.openai 模块以即插即用(drop-in)的方式追踪 OpenAI 调用。此外,langfuse_prompt_name 参数可以把提示词版本直接与 Trace 关联起来。
Arize Phoenix 架构与实战
Arize Phoenix 是 Arize AI 开发的开源 AI Observability 平台。它以 OpenTelemetry 原生方式设计,采集追踪数据时不会产生厂商锁定,可以在本地 Jupyter notebook 到 Kubernetes 集群等各种环境中运行。截至 2026 年 2 月,arize-phoenix-evals v2.11.0 已发布,评估功能得到了大幅增强。
Python 代码示例:Arize Phoenix 集成
import os
import phoenix as px
from phoenix.otel import register
from openinference.instrumentation.openai import OpenAIInstrumentor
from openai import OpenAI
# 1. 启动 Phoenix 服务器(本地开发时)
# px.launch_app() # 在本地启动 Phoenix UI (http://localhost:6006)
# 2. 基于 OpenTelemetry 的追踪配置
tracer_provider = register(
project_name="production-chatbot",
endpoint="http://phoenix-server:6006/v1/traces", # Phoenix 服务器端点
)
# 3. 启用 OpenAI Instrumentor(自动追踪)
OpenAIInstrumentor().instrument(tracer_provider=tracer_provider)
# 4. 常规的 OpenAI 调用 - 自动采集追踪
client = OpenAI()
def generate_summary(document: str) -> dict:
"""生成文档摘要 - Phoenix 自动追踪"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "주어진 문서를 3줄로 요약하세요."},
{"role": "user", "content": document}
],
temperature=0.2
)
return {
"summary": response.choices[0].message.content,
"input_tokens": response.usage.prompt_tokens,
"output_tokens": response.usage.completion_tokens,
}
# 5. Phoenix Evaluation:幻觉检测
from phoenix.evals import (
HallucinationEvaluator,
OpenAIModel,
run_evals,
)
# 评估模型配置
eval_model = OpenAIModel(model="gpt-4o-mini")
# 幻觉评估器
hallucination_eval = HallucinationEvaluator(eval_model)
# 基于数据集运行评估
# 将 Phoenix UI 中采集的追踪导出为 DataFrame 后再评估
import pandas as pd
eval_df = pd.DataFrame({
"input": ["Kubernetes의 최대 Pod 수는?"],
"output": ["Kubernetes 클러스터당 최대 150,000개의 Pod를 지원합니다."],
"reference": ["기본 설정에서 노드당 최대 110개의 Pod, 클러스터당 최대 150,000개의 Pod를 지원합니다."]
})
# 运行幻觉评估
hallucination_results = run_evals(
dataframe=eval_df,
evaluators=[hallucination_eval],
provide_explanation=True
)
print(hallucination_results)
Phoenix 的核心差异化点在于其 OpenTelemetry 原生架构。只要注册了 OpenAIInstrumentor,OpenAI 客户端的所有调用都会被自动记录为 OpenTelemetry Span。这些 Span 不仅能发送到 Phoenix 服务器,还能发送到 Jaeger、Grafana Tempo 等任何兼容 OpenTelemetry 的后端。
三方对比
功能对比
| 功能 | LangSmith | LangFuse | Arize Phoenix |
|---|---|---|---|
| 追踪 | @traceable + wrap_openai | @observe + langfuse.openai | OpenTelemetry Instrumentor |
| 提示词管理 | Hub(提示词注册中心) | Prompt Management(版本/标签) | 不支持(需借助外部工具) |
| 评估(Evals) | LangSmith Evaluators | Score API + Dataset | Phoenix Evals(幻觉、相关性) |
| 数据集 | Dataset + Annotation Queue | Dataset + Annotation | Dataset(基于 DataFrame) |
| 仪表盘 | 内置(LLM 专用) | 内置(可自定义) | 内置(对 Notebook 友好) |
| 实时监控 | 实时追踪流 | 实时追踪 | 实时 + 批量分析 |
| A/B 测试 | Experiment 对比 | 提示词版本对比 | 有限 |
| 用户反馈 | Feedback API | Score API | 需自行实现 |
部署与价格对比
| 项目 | LangSmith | LangFuse | Arize Phoenix |
|---|---|---|---|
| 开源 | 否(仅 SaaS) | 是(MIT 许可证) | 是(Apache 2.0) |
| 自托管 | 否 | 是(Docker Compose) | 是(Docker/K8s) |
| 免费额度 | Developer(5,000 traces/月) | Hobby(5 万次 observation) | OSS 免费 / Cloud 免费额度 |
| 付费价格 | Plus $39/seat/月 | Pro $59/月起 | AX Cloud:需另行咨询 |
| 数据保留 | 14 天(Developer) | 无限(自托管) | 无限(自托管) |
| SOC2 认证 | 有 | 有(Cloud) | 有(AX Cloud) |
| SDK 语言 | Python、TypeScript | Python、TypeScript、Java | Python(OpenTelemetry) |
| 框架集成 | LangChain 原生、通用 | 与框架无关,覆盖广泛 | 基于 OpenTelemetry、通用 |
性能对比
| 性能指标 | LangSmith | LangFuse | Arize Phoenix |
|---|---|---|---|
| 追踪写入速度 | 快 | 一般(约 327s/批次) | 快(约 170s/批次) |
| SDK 开销 | 低 | 低 | 极低(OTel 原生) |
| 大规模流量处理 | SaaS 弹性伸缩 | 自托管时需自行扩容 | 自托管时需自行扩容 |
| 查询性能 | 快 | 一般 | 快(ClickHouse) |
提示词版本管理与 A/B 测试
提示词版本管理相当于 LLM 应用的"代码管理"。提示词的改动等同于应用行为的改动,所以必须像 Git 提交那样,对每一次变更都能追踪和对比。
LangSmith 的 Prompt Hub
LangSmith 通过 Prompt Hub 集中管理提示词。为提示词赋予版本号,代码中通过提示词名称和版本号来引用,无需重新部署即可切换提示词。
LangFuse 的提示词管理
LangFuse 用版本和标签(production、staging 等)来管理提示词。代码中动态加载提示词使用,每条 Trace 都会自动记录所使用的提示词版本。
A/B 测试实现模式
提示词 A/B 测试是对相同输入应用不同版本的提示词,并对比质量指标。借此可以用数据驱动的方式判断"哪个提示词更好"。
评估流水线自动化
要持续保证 LLM 应用的质量,评估必须自动化。人工评估在规模变大后既不现实,也无法保证一致性。
LLM-as-a-Judge 评估流水线
最广泛使用的自动评估方式,是把 LLM 当作评估者(Judge)。用成本较低的模型(如 GPT-4o-mini)作为评估器,自动为生产环境的回答打分。
import json
from langfuse import observe
from langfuse.openai import openai
from typing import Literal
# 定义评估标准
EVAL_CRITERIA = {
"relevance": "질문과 답변의 관련성 (0.0~1.0)",
"completeness": "답변의 완전성 - 필요한 정보를 모두 포함하는가 (0.0~1.0)",
"faithfulness": "주어진 컨텍스트에 충실한가 (0.0~1.0)",
"conciseness": "불필요한 내용 없이 간결한가 (0.0~1.0)"
}
@observe(name="AutoEvalPipeline")
def auto_evaluate(
question: str,
answer: str,
context: str = "",
criteria: list[str] = None
) -> dict:
"""
LLM-as-a-Judge 自动评估流水线。
同时对多个质量标准进行评估。
"""
if criteria is None:
criteria = list(EVAL_CRITERIA.keys())
criteria_text = "\n".join([
f"- {name}: {desc}" for name, desc in EVAL_CRITERIA.items()
if name in criteria
])
eval_prompt = f"""당신은 LLM 응답 품질 평가 전문가입니다.
다음 질문-답변 쌍을 평가 기준에 따라 채점하세요.
## 질문
{question}
## 컨텍스트 (제공된 경우)
{context if context else "없음"}
## 답변
{answer}
## 평가 기준
{criteria_text}
## 출력 형식 (JSON)
각 기준에 대해 score(0.0~1.0)와 reasoning(한국어 1문장)을 포함하세요.
```
json
{{
"scores": {{
"기준명": {{"score": 0.0, "reasoning": "이유"}}
}},
"overall_score": 0.0,
"summary": "전체 평가 요약 (한국어)"
}}
```"""
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": eval_prompt}],
temperature=0.0,
response_format={"type": "json_object"}
)
eval_result = json.loads(response.choices[0].message.content)
# 将评估分数记录到 LangFuse
from langfuse import get_client
lf_client = get_client()
for criterion, data in eval_result.get("scores", {}).items():
lf_client.score(
name=f"eval_{criterion}",
value=data["score"],
comment=data["reasoning"]
)
return eval_result
# CI/CD 中的评估门禁:部署新提示词前自动评估
def prompt_deployment_gate(
new_prompt: str,
test_dataset: list[dict],
min_overall_score: float = 0.7
) -> bool:
"""
验证新提示词质量是否达标的部署门禁。
从 CI/CD 流水线中调用。
"""
scores = []
for test_case in test_dataset:
# 用新提示词生成响应
response = openai.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": new_prompt},
{"role": "user", "content": test_case["question"]}
],
temperature=0.1
)
answer = response.choices[0].message.content
# 运行自动评估
eval_result = auto_evaluate(
question=test_case["question"],
answer=answer,
context=test_case.get("context", "")
)
scores.append(eval_result["overall_score"])
avg_score = sum(scores) / len(scores) if scores else 0
passed = avg_score >= min_overall_score
print(f"평가 결과: 평균 {avg_score:.2f} / 기준 {min_overall_score}")
print(f"배포 게이트: {'PASS' if passed else 'FAIL'}")
return passed
这套流水线可以集成到 CI/CD 中,在提示词发生变更时自动对测试数据集运行评估,并在未达到质量标准时作为门禁阻止部署。
成本追踪自动化
LLM 成本监控是生产运维中不可或缺的一环。虽然各平台都会在 Trace 中记录 token 用量,但成本计算逻辑往往需要自行实现。
from dataclasses import dataclass
from datetime import datetime, timedelta
from collections import defaultdict
# 各模型的 token 价格(截至 2026 年 3 月,每 1M tokens 的美元价格)
MODEL_PRICING = {
"gpt-4o": {"input": 2.50, "output": 10.00},
"gpt-4o-mini": {"input": 0.15, "output": 0.60},
"gpt-4-turbo": {"input": 10.00, "output": 30.00},
"claude-3-5-sonnet": {"input": 3.00, "output": 15.00},
"claude-3-5-haiku": {"input": 0.80, "output": 4.00},
}
@dataclass
class UsageRecord:
timestamp: datetime
model: str
input_tokens: int
output_tokens: int
endpoint: str
user_id: str = ""
class LLMCostTracker:
"""LLM 成本追踪与预算告警"""
def __init__(self, monthly_budget_usd: float = 5000.0):
self.monthly_budget = monthly_budget_usd
self.records: list[UsageRecord] = []
def record_usage(self, record: UsageRecord):
self.records.append(record)
cost = self._calculate_cost(record)
# 检查预算超支告警
monthly_cost = self.get_monthly_cost()
budget_pct = (monthly_cost / self.monthly_budget) * 100
if budget_pct > 90:
self._send_alert(
f"LLM 비용 경고: 월 예산의 {budget_pct:.1f}% 소진 "
f"(${monthly_cost:.2f} / ${self.monthly_budget:.2f})"
)
return cost
def _calculate_cost(self, record: UsageRecord) -> float:
pricing = MODEL_PRICING.get(record.model, {"input": 0, "output": 0})
input_cost = (record.input_tokens / 1_000_000) * pricing["input"]
output_cost = (record.output_tokens / 1_000_000) * pricing["output"]
return input_cost + output_cost
def get_monthly_cost(self) -> float:
now = datetime.now()
month_start = now.replace(day=1, hour=0, minute=0, second=0)
monthly_records = [r for r in self.records if r.timestamp >= month_start]
return sum(self._calculate_cost(r) for r in monthly_records)
def get_cost_breakdown(self) -> dict:
"""按模型、按端点的成本分析"""
by_model = defaultdict(float)
by_endpoint = defaultdict(float)
for record in self.records:
cost = self._calculate_cost(record)
by_model[record.model] += cost
by_endpoint[record.endpoint] += cost
return {
"by_model": dict(by_model),
"by_endpoint": dict(by_endpoint),
"total": sum(by_model.values())
}
def _send_alert(self, message: str):
# 通过 Slack 或 PagerDuty 发送告警
print(f"[ALERT] {message}")
故障案例与恢复策略
故障案例 1:追踪开销导致响应延迟
情况:将 LangSmith 追踪以同步(synchronous)模式部署到生产环境。每次 LLM 调用都要额外花时间把追踪数据发送到 LangSmith API,导致 P99 响应时间从 200ms 增加到 800ms。
原因分析:在默认配置下,若追踪数据的发送以同步方式执行,主线程会一直阻塞到 API 调用完成为止。LangSmith API 服务器的延迟就这样直接传导成了用户侧的响应延迟。
恢复步骤:
- 把追踪切换为异步(async)模式:设置
LANGSMITH_TRACING_BACKGROUND=true环境变量 - 启用批量发送:不立即发送追踪数据,而是先缓存再批量发送
- 引入采样:仅对全部请求的 10~20% 做追踪,把开销降到最低
- 应用断路器(Circuit Breaker)模式:追踪 API 故障时自动关闭追踪
故障案例 2:缺乏提示词版本管理导致质量回归
情况:团队成员 A "改进"了提示词并上线部署,但特定语言(日语)输入的幻觉比例从 2% 骤增到 15%。由于没有提示词变更历史,回滚到旧版本花了 3 个小时,期间数百条错误回答已经推送给了用户。
原因分析:提示词是直接在管理后台修改的,而不是通过代码仓库,变更前也没有经过评估。由于只用英文测试用例做了验证,未能检测出日语输入的质量下降。
恢复步骤:
- 把提示词迁移到 LangFuse/LangSmith 的提示词管理功能中
- 对所有提示词变更打上版本标签,并应用 production/staging 标签
- 部署前引入针对多语言测试数据集的自动评估门禁
- 金丝雀(Canary)发布:新提示词先只应用于 5% 的流量,确认质量指标后再逐步扩大
故障案例 3:自托管 LangFuse 的数据丢失
情况:用 Docker Compose 自托管了 LangFuse,但 PostgreSQL 卷没有配置为持久化卷(persistent volume),容器重启后两周的追踪数据丢失了。
原因分析:在 Docker Compose 的默认配置下,PostgreSQL 数据只存储在容器内部。执行 docker compose down 时卷被一并删除,所有数据随之消失。
恢复步骤:
- 把 PostgreSQL 数据迁移到宿主机卷或托管数据库(如 RDS)
- 设置定期数据备份计划(基于 pg_dump,每日一次)
- 在 Docker Compose 配置中显式添加
volumes部分 - 监控:新增 PostgreSQL 磁盘用量、连接数、查询性能等指标
故障案例 4:未被察觉的成本暴涨
情况:开发者出于调试目的,在系统提示词中加入了大量(20 个)少样本(few-shot)示例,部署到生产环境时忘记删除。单次请求的输入 token 从 500 增加到 8,000,导致周度 LLM 成本从 $500 暴涨 16 倍到 $8,000。
原因分析:当时没有对 token 用量和成本进行实时监控。成本告警只在月度结算时才会被查看,导致超额成本持续了两周才被发现。
恢复步骤:
- 把成本追踪类集成到所有 LLM 调用中(参考上文的
LLMCostTracker) - 设置每日成本告警:较前一日增长超过 200% 时立即告警
- 设置单次请求的 token 上限:校验输入 token 并使用
max_tokens参数 - 提示词变更时自动计算 token 数量,对异常增长发出警告
选型指南:哪个平台适合我们团队?
什么时候该选 LangSmith
- 以 LangChain 或 LangGraph 为主力框架的团队
- 不想承担 SaaS 管理负担、希望快速起步的初创公司
- 需要通过 Prompt Hub 做集中式提示词管理的团队
- 数据存放在外部云端也没问题的场景
什么时候该选 LangFuse
- 数据主权(Data Sovereignty)至关重要的企业(金融、医疗、公共部门)
- 希望通过自托管来控制成本的团队
- 需要不依赖特定框架的通用方案的团队
- 需要开源贡献和自定义能力的场景
- 在大规模流量下需要可预测成本结构的团队
什么时候该选 Arize Phoenix
- 希望把 LLM 监控整合进已有的 OpenTelemetry Observability 技术栈的团队
- 想在 Jupyter notebook 中快速原型验证和分析的机器学习工程师
- 正在考虑未来扩展到 Arize AX(商业版)的团队
- Evals 功能(幻觉检测、相关性评估)至关重要的团队
- 希望不受厂商锁定、自由迁移数据的团队
决策流程图
- 数据不能离开自有基础设施吗? -> LangFuse(自托管)或 Phoenix(自托管)
- 是否在积极使用 LangChain 生态? -> LangSmith
- 是否已有 OpenTelemetry 基础设施? -> Arize Phoenix
- 成本优化是否是最优先级? -> LangFuse(开源自托管)
- 想快速起步吗? -> LangSmith(SaaS)或 Phoenix(pip install)
运维注意事项
追踪配置:
- 追踪是否已设置为异步模式
- 生产环境的采样比例是否设置得当(10~100%)
- 是否应用了断路器(Circuit Breaker),避免追踪 API 故障影响服务
- 是否对 PII(个人身份信息)做了脱敏处理,避免混入追踪数据
成本管理:
- 是否搭建了按模型、按端点划分的成本看板
- 是否设置了每日成本告警
- 是否设置了单次请求的 token 上限
- 月度预算超支时是否会自动告警
质量管理:
- 自动评估流水线是否已集成到 CI/CD 中
- 多语言测试数据集是否已准备好
- 是否在实时监控幻觉发生率
- 是否已实现用户反馈收集机制
基础设施(自托管场景):
- 数据库卷是否挂载在持久化存储上
- 是否已设置定期备份
- 是否已设置磁盘容量监控
- 是否已制定水平扩展策略
结语
LLM 监控不是"锦上添花",而是生产级 LLM 服务生存所必需的基础设施。如果无法定量衡量一次提示词改动对服务质量和成本的影响,最终只能依赖直觉去运营,而这必然会带来不可预测的故障和成本暴涨。
LangSmith、LangFuse、Arize Phoenix 各有鲜明优势。LangSmith 的核心是与 LangChain 生态的紧密集成,LangFuse 的核心是开源和自托管带来的灵活性,Phoenix 的核心是 OpenTelemetry 原生架构和强大的评估能力。团队应根据自身的技术栈、数据策略、预算来选择最合适的平台,但无论选哪一个,都应先立下"没有监控就没有 LLM 生产环境"这条原则。
建议从小范围起步,逐步扩展。先搭建追踪,记录全部 LLM 调用,再加入成本追踪,接着构建自动评估流水线,最后再发展到提示词版本管理和 A/B 测试——这是一条切实可行的落地路径。
参考资料
- LangSmith - AI Agent & LLM Observability Platform (LangChain) - LangChain 官方 LLM Observability 平台,集成追踪/评估/提示词管理
- LangFuse - Open Source LLM Engineering Platform (GitHub) - 开源 LLM Observability,MIT 许可证,支持自托管
- Arize Phoenix - AI Observability & Evaluation (GitHub) - OpenTelemetry 原生 AI Observability,Apache 2.0 许可证
- LangFuse Decorator-Based Python Integration - LangFuse Python SDK v3 @observe 装饰器官方文档
- Langfuse Alternatives: Top 5 Competitors Compared 2026 (Braintrust) - 2026 年 LLM Observability 平台综合对比
- Best LLM Observability Tools in 2026 (Firecrawl) - 2026 年最新 LLM 监控工具对比分析
- Choosing the Right AI Evaluation and Observability Platform (Maxim AI) - AI 评估与 Observability 平台深度对比
小测验
Q1:"LLM 生产监控平台对比:LangSmith·LangFuse·Arize Phoenix
实战运维指南"主要讲的是什么?
LLM 生产监控平台三巨头(LangSmith、LangFuse、Arize Phoenix)综合对比指南。涵盖追踪(trace)采集、提示词版本管理、评估流水线、成本监控、质量看板构建,以及实战选型标准,并配有代码示例。
Q2:LLM Observability 核心指标是什么?
LLM 监控中需要追踪的核心指标,与传统 APM 有相当大的差异。系统化地采集并可视化这些指标,正是 LLM
Observability 平台的核心作用。
Q3:请说明 LangSmith 架构与实战。
LangSmith 是 LangChain 团队开发的官方 LLM Observability
平台。它最大的优势是与 LangChain 框架的原生集成,但即便不使用 LangChain 或 LangGraph
的项目,也能独立使用它。
Q4:请说明 LangFuse 架构与实战。
LangFuse 是一款开源的 LLM Observability 平台,最大的差异化点在于支持自托管(self-hosting)。只需一条
Docker Compose 命令即可部署到自有基础设施上,并且保证与云端版本的功能对等性(feature parity)。
Q5:请说明 Arize Phoenix 架构与实战。
Arize Phoenix 是 Arize AI 开发的开源 AI Observability
平台。它以 OpenTelemetry 原生方式设计,采集追踪数据时不会产生厂商锁定,可以在本地 Jupyter
notebook 到 Kubernetes 集群等各种环境中运行。
현재 단락 (1/464)
"只改了一个提示词,回答质量突然就变差了。"只要在生产环境运营过基于 LLM 的服务,团队大概率都遇到过这种情况。传统软件只要不改代码,同样的输入就保证得到同样的输出。但 LLM 从根本上不同。