Skip to content

필사 모드: LLM 生产监控平台对比:LangSmith·LangFuse·Arize Phoenix 实战运维指南

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
LLM Monitoring Platforms

引言:为什么需要 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 有相当大的差异。

指标类别具体指标说明目标值示例
LatencyTTFT (Time to First Token)到第一个 token 为止的时间< 500ms
LatencyTotal Latency整体响应完成时间< 3s
LatencyTokens per Second每秒 token 生成速度> 50 tokens/s
CostInput Token Count输入 token 数持续监控
CostOutput Token Count输出 token 数持续监控
CostCost per Request单次请求成本< $0.01
CostMonthly Cost月度总成本预算范围内
QualityRelevance Score响应的相关性得分> 0.8
QualityFaithfulness Score对 RAG 上下文的忠实度> 0.9
QualityHallucination Rate幻觉发生率< 5%
QualityUser Feedback用户满意度(thumbs up/down)> 80% 正面
ReliabilityError RateAPI 调用失败率< 0.1%
ReliabilityRetry Rate重试比例< 1%
ReliabilityRate Limit Hit RateAPI 限流触达比例< 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 的后端。

三方对比

功能对比

功能LangSmithLangFuseArize Phoenix
追踪@traceable + wrap_openai@observe + langfuse.openaiOpenTelemetry Instrumentor
提示词管理Hub(提示词注册中心)Prompt Management(版本/标签)不支持(需借助外部工具)
评估(Evals)LangSmith EvaluatorsScore API + DatasetPhoenix Evals(幻觉、相关性)
数据集Dataset + Annotation QueueDataset + AnnotationDataset(基于 DataFrame)
仪表盘内置(LLM 专用)内置(可自定义)内置(对 Notebook 友好)
实时监控实时追踪流实时追踪实时 + 批量分析
A/B 测试Experiment 对比提示词版本对比有限
用户反馈Feedback APIScore API需自行实现

部署与价格对比

项目LangSmithLangFuseArize 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、TypeScriptPython、TypeScript、JavaPython(OpenTelemetry)
框架集成LangChain 原生、通用与框架无关,覆盖广泛基于 OpenTelemetry、通用

性能对比

性能指标LangSmithLangFuseArize 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 服务器的延迟就这样直接传导成了用户侧的响应延迟。

恢复步骤

  1. 把追踪切换为异步(async)模式:设置 LANGSMITH_TRACING_BACKGROUND=true 环境变量
  2. 启用批量发送:不立即发送追踪数据,而是先缓存再批量发送
  3. 引入采样:仅对全部请求的 10~20% 做追踪,把开销降到最低
  4. 应用断路器(Circuit Breaker)模式:追踪 API 故障时自动关闭追踪

故障案例 2:缺乏提示词版本管理导致质量回归

情况:团队成员 A "改进"了提示词并上线部署,但特定语言(日语)输入的幻觉比例从 2% 骤增到 15%。由于没有提示词变更历史,回滚到旧版本花了 3 个小时,期间数百条错误回答已经推送给了用户。

原因分析:提示词是直接在管理后台修改的,而不是通过代码仓库,变更前也没有经过评估。由于只用英文测试用例做了验证,未能检测出日语输入的质量下降。

恢复步骤

  1. 把提示词迁移到 LangFuse/LangSmith 的提示词管理功能中
  2. 对所有提示词变更打上版本标签,并应用 production/staging 标签
  3. 部署前引入针对多语言测试数据集的自动评估门禁
  4. 金丝雀(Canary)发布:新提示词先只应用于 5% 的流量,确认质量指标后再逐步扩大

故障案例 3:自托管 LangFuse 的数据丢失

情况:用 Docker Compose 自托管了 LangFuse,但 PostgreSQL 卷没有配置为持久化卷(persistent volume),容器重启后两周的追踪数据丢失了。

原因分析:在 Docker Compose 的默认配置下,PostgreSQL 数据只存储在容器内部。执行 docker compose down 时卷被一并删除,所有数据随之消失。

恢复步骤

  1. 把 PostgreSQL 数据迁移到宿主机卷或托管数据库(如 RDS)
  2. 设置定期数据备份计划(基于 pg_dump,每日一次)
  3. 在 Docker Compose 配置中显式添加 volumes 部分
  4. 监控:新增 PostgreSQL 磁盘用量、连接数、查询性能等指标

故障案例 4:未被察觉的成本暴涨

情况:开发者出于调试目的,在系统提示词中加入了大量(20 个)少样本(few-shot)示例,部署到生产环境时忘记删除。单次请求的输入 token 从 500 增加到 8,000,导致周度 LLM 成本从 $500 暴涨 16 倍到 $8,000

原因分析:当时没有对 token 用量和成本进行实时监控。成本告警只在月度结算时才会被查看,导致超额成本持续了两周才被发现。

恢复步骤

  1. 把成本追踪类集成到所有 LLM 调用中(参考上文的 LLMCostTracker)
  2. 设置每日成本告警:较前一日增长超过 200% 时立即告警
  3. 设置单次请求的 token 上限:校验输入 token 并使用 max_tokens 参数
  4. 提示词变更时自动计算 token 数量,对异常增长发出警告

选型指南:哪个平台适合我们团队?

什么时候该选 LangSmith

  • 以 LangChain 或 LangGraph 为主力框架的团队
  • 不想承担 SaaS 管理负担、希望快速起步的初创公司
  • 需要通过 Prompt Hub 做集中式提示词管理的团队
  • 数据存放在外部云端也没问题的场景

什么时候该选 LangFuse

  • 数据主权(Data Sovereignty)至关重要的企业(金融、医疗、公共部门)
  • 希望通过自托管来控制成本的团队
  • 需要不依赖特定框架的通用方案的团队
  • 需要开源贡献和自定义能力的场景
  • 在大规模流量下需要可预测成本结构的团队

什么时候该选 Arize Phoenix

  • 希望把 LLM 监控整合进已有的 OpenTelemetry Observability 技术栈的团队
  • 想在 Jupyter notebook 中快速原型验证和分析的机器学习工程师
  • 正在考虑未来扩展到 Arize AX(商业版)的团队
  • Evals 功能(幻觉检测、相关性评估)至关重要的团队
  • 希望不受厂商锁定、自由迁移数据的团队

决策流程图

  1. 数据不能离开自有基础设施吗? -> LangFuse(自托管)或 Phoenix(自托管)
  2. 是否在积极使用 LangChain 生态? -> LangSmith
  3. 是否已有 OpenTelemetry 基础设施? -> Arize Phoenix
  4. 成本优化是否是最优先级? -> LangFuse(开源自托管)
  5. 想快速起步吗? -> 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 测试——这是一条切实可行的落地路径。

参考资料

小测验

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 从根本上不同。

작성 글자: 0원문 글자: 18,250작성 단락: 0/464