详细解释
LLM Observability（LLM 可观测性 / 大模型链路追踪） 一句话定义：普通后端 API 你至少会监控「QPS、P95 延迟、错误率、CPU、内存」5 个指标，但是 LLM API 比普通 API 复杂 10 倍，每个请求有「输入 token、输出 token、模型、温度、System Prompt、用户输入、LLM 输出、RAG 召回 chunk 列表、Function 调用参数、幻觉检测结果……」20 多个维度，如果这些维度你都没采集、没看板、没告警，你线上模型出了问题（比如突然成本翻倍、延迟翻倍、幻觉率飙升、GPT-4o 偷偷给你走了降级到 GPT-4o-mini），你根本发现不了，等用户投诉了才知道晚了。这就是 LLM Observability 要解决的问题——把 LLM 应用从「黑盒」变成「白盒」。
2024 年是 LLM Observability 的爆发年，三大开源方案（LangSmith 商业版、Langfuse 开源、Arize Phoenix 开源）+ 三大云厂商方案（AWS Bedrock Metrics、Azure PromptFlow、GCP Vertex AI Evaluation）基本形成格局；国内也有我们唯元智创等平台内置了完整的可观测性模块，不需要企业从零搭。
一个合格的 LLM Observability 平台至少覆盖四大支柱：(1) Tracing（链路追踪）——一次用户请求经过的所有 LLM 调用、RAG 检索、工具调用、Guardrails 检查串成一条 Trace，像瀑布图一样展开；(2) Metrics（指标聚合）——Token 消耗、成本、延迟、错误率按日/周/月聚合看板；(3) Evaluations（自动评测）——每条 LLM 输出自动跑「事实一致性、有用性、安全性」3 组打分；(4) Alerting（告警）——成本超预算 20%、P95 延迟翻倍、幻觉率突破 5% 阈值立刻告警到飞书/钉钉。
生产级 LLM Observability 必须采集的 12 个核心字段（别漏了）
很多团队一开始只采「输入输出文本 + 耗时」，后面发现根本没法做归因，按下表 12 个字段起步才够用：
| 分类 | 必须采集字段 | 用途 |
|---|---|---|
| 基础元数据 | trace_id, span_id, parent_span_id, user_id, session_id, request_id | 链路串联、用户维度分析、会话级问题追踪 |
| 模型与参数 | model_id, provider, temperature, top_p, max_tokens, seed, structured_output_schema, tool_list | 归因：是不是换了模型/参数导致问题？ |
| Token 与成本 | prompt_tokens, completion_tokens, total_tokens, cached_tokens（prompt cache命中的）, estimated_cost_usd, estimated_cost_cny | 成本监控、预算控制、缓存命中率分析 |
| 延迟拆分 | ttft_ms（首 token 延迟）, total_time_ms, time_in_rag_ms, time_in_llm_ms, time_in_guardrails_ms | 延迟瓶颈归因：是 RAG 慢了还是 LLM 慢了？ |
| Prompt 版本 | prompt_version, system_prompt_hash, few_shot_count | 新版本 Prompt 上线后指标对比，归因是不是 Prompt 改坏了 |
| RAG 检索细节 | retrieved_chunk_ids[], retrieved_chunk_scores[], rerank_scores[], query_rewrite_version | RAG 质量分析：召回的 chunk 对不对？重排分数够不够？ |
| 输出质量 | guardrails_passed, guardrails_blocked_reason[], hallucination_detection_score, factuality_score, user_feedback(thumb_up/down) | 质量趋势监控：幻觉率是不是突然涨了？ |
| 工具调用 | function_call_name[], function_call_args[], function_return_status, function_return_time_ms | Function Calling 错误率分析、工具延迟监控 |
| 降级与重试 | retry_count, fallback_model_id, fallback_reason, success_after_retry | 降级分析：主模型挂了多少次？靠哪个备用模型顶住的？ |
| 安全与合规 | pii_masked_count, prompt_injection_score, output_category(合规/不合规), moderation_labels | 安全红线监控：越狱攻击拦截率达标了吗？ |
| 上下文长度 | context_window_used, context_window_total_ratio, kv_cache_hit_rate | 上下文效率分析：是不是经常塞了 100K token 只用了前 10%？ |
| 用户级反馈 | user_feedback, user_abandoned, escalation_to_human_agent | 最终业务指标：模型回答不好用户有没有转人工？ |
三大开源 LLM Observability 方案对比（2025 年选型指南）
小团队别自研，直接选开源或 SaaS：
| 方案 | 开源协议 | 部署成本 | 强项 | 弱项 | 推荐团队规模 |
|---|---|---|---|---|---|
| Langfuse | MIT 完全开源 | 1 台 4C8G 服务器 docker compose 一键起 | Tracing 瀑布图体验最好、Prompt 管理集成、SDK 全（Python/TS/REST）、和 LlamaIndex/LangChain 深度集成 | 自动 Evaluations 是付费高级版、自建分析看板略弱 | 5-50 人团队首选 |
| Arize Phoenix | Apache 2.0 | 单机 8C32G 起，支持 K8s 集群 | Embedding 可视化（UMAP 降维看向量分布）、自动 Root Cause 分析、数据集评测能力强 | Tracing 瀑布图不如 Langfuse 直观、UI 偏数据分析风格 | 团队里有专门数据分析师、重点做 RAG 质量优化时选 |
| LangSmith | 商业 SaaS / 私有部署付费 | SaaS 按 Token 计费约 $0.0001/请求，私有部署年付 | 功能最全面、LangChain 官方出品、和 Prompt A/B 实验深度打通、文档生态最全 | 价格贵、全量私有化部署门槛高（年付几十万起）、不开源 | 50 人以上、预算充足、重度依赖 LangChain 生态的团队 |
常见问题
全链路采集会不会吃太多性能和存储成本？比如每次 Trace 存 50KB，100 万请求就是 50GB。
会，但有 4 个标准的分层采样 + 冷热存储技巧，把成本压到原来的 1-5%，99% 的场景够用：（1）采样 + 分级存储——错误请求、慢请求（P95+）、高风险请求（退款/医疗/法律）100% 全量存（热存）；普通正常请求按 5% 采样存（温存）、95% 只存聚合指标（不存原文）；热存 7 天后自动转冷存（对象存储 S3/OSS，成本 1/10），冷存 90 天后自动删除；（2）字段级裁剪——Trace 里的「完整 RAG 召回 chunk 原文」字段默认不展示，按需按 trace_id 回查，DB 里存 chunk_id 列表和 chunk hash 就行，原文存在原始知识库不用冗余存；（3）无损压缩——LLM 文本高度冗余，用 Zstandard 压缩算法对长文本字段做列式压缩，压缩比 1:8 到 1:12，50GB 存下来其实只有 5GB；（4）预聚合指标层——每分钟跑一次流式聚合，生成「模型 × Prompt 版本 × 小时」粒度的聚合表（总 token、平均成本、平均延迟、错误率），日常看板直接查聚合表（毫秒级），原始 Trace 只在排错的时候才捞。按这套组合拳，实测 100 万请求/月全链路可观测的实际存储成本在 5-10GB，服务器月成本 ¥200 以内，完全可以忽略。
可观测平台天天告警「成本涨了」「延迟高了」，但很多告警是噪声，怎么降噪才能不被狼来了喊麻木？
这是所有监控系统的通病，LLM 指标方差更大（自然波动就 ±10%），必须用「同比/环比 + 多维度联合告警 + 分级告警阈值」三件套才能把噪声压到每周 ≤2 条有效告警：（1）不要用「固定阈值告警」（比如成本 > 1000元/小时），要用「同比上周同一天 + 环比过去 7 天均值的 3σ 异常检测」——比如周一 14:00 成本突然比上周一 14:00 高 30%、比过去 7 天同时间段均值高 4 个标准差，才判定为真异常，平峰高峰波动被过滤掉 90%；（2）单指标告警升级为「多维联合告警」——比如只有当「成本同比涨 ≥20% 同时 P95 延迟涨 ≥15% 同时错误率涨 ≥5%」三个信号同时出现时，才判定为严重告警（S 级，@所有人）；两个信号同时出现是 A 级（@oncall 工程师）；单个异常只是 B 级（只记日志不发告警）；（3）分层告警分级处理——S 级（错误率飙升、5xx 爆炸）立刻电话+短信叫醒，A 级（成本超支、延迟偏高）飞书卡片告警，B 级（单一维度轻微异常）只记到每周周报里，人工复盘时看。按这套做法，之前每天 20 条告警的团队，最后压到每周 1-2 条真告警，没有人再麻木。
我是一个 3 人小团队，有必要一上来就上 Langfuse 这种重型平台吗？最轻量的 MVP 怎么做？
3 人团队一开始直接上 Langfuse 是有学习成本的，给你一个「半天搞定的 3 层轻量 MVP 方案」，成本 ¥0/月，覆盖 80% 核心需求，用户量过 10 万再升级：（1）第 1 层 结构化日志——把本页前面列的 12 个核心字段，封装成一个 log_llm_call(data) 函数，在每次调用 LLM 的地方用 JSONL 格式打到 stdout/stderr，只加 1 行代码，其他什么都不动；（2）第 2 层 存储 + 简易查询——如果你用云服务器，直接接一个免费的日志服务（阿里云 SLS 免费额度 500MB/天、腾讯云 CLS 免费额度 1GB/天），或者自建 1 台服务器跑 Vector + ClickHouse 的 docker 组合（1C2G 就能撑 100 万请求/月），日志 JSONL 直接灌进去，SQL 随便查，不需要 UI；（3）第 3 层 指标看板 + 基础告警——用 Grafana 接 ClickHouse/SLS，写 6 个最核心的 SQL 面板：① 每日总 Token/成本趋势图、② 每模型 Token 占比饼图、③ P50/P95/P99 延迟趋势、④ 错误率/降级率每日趋势、⑤ RAG 平均召回分数趋势、⑥ 每日 Top-10 最贵请求 Top 列表（防止有人写了一个循环调了 10 万次模型）；告警接 Grafana 自带的飞书/钉钉 webhook，只设 3 条告警：错误率 >5%、单小时成本 > 过去 7 天同时间段 2 倍、P95 延迟 > 5s。3 层加起来半天搞定，撑到 DAU 过万完全没问题，到时候再无缝迁移 Langfuse，完全不浪费。