LLMOps这个词这两年算是彻底火起来了。过去我们聊监控，说的是服务器CPU、接口延迟、错误率这些传统指标，可一旦把大模型应用推上线，情况就完全变了——模型输出质量不稳定、Token消耗难以预估、Prompt一改行为就变，这些问题光靠看监控大盘是看不出来的。我自己的体会是，LLM应用上线后的第一周，团队最缺的不是算法能力，而是一套能看清“模型到底在干嘛”的体系。
这篇文章就围绕两个目前比较主流的开源工具——Langfuse和Opik——来聊聊怎么搭建一套覆盖trace追踪、效果评估、数据集回归的LLM监控与评估体系。适合已经在做LLM应用开发，或者正准备把原型推向生产的工程团队参考，我会把部署思路、核心概念和实际配置过程都过一遍。
1. LLMOps的核心命题：从“能跑”到“跑得稳”
1.1 传统监控手段为什么在LLM应用上失效
先讲个我踩过的坑。早先做基于大模型的客服问答系统，上线前团队按照传统思路配置了一套监控：请求量、P99延迟、5xx错误率、服务器负载。指标全绿，一切看起来都正常，可业务方和用户却在反馈“回答质量明显变差”。排查到最后才发现，是上游数据源字段格式调整后，模型在部分场景下开始输出空内容，但接口返回200、延迟也没变化，传统监控完全感知不到。
这个问题的本质在于：传统APM（应用性能监控）关注的是“服务是否可用”，而LLM应用的核心风险是“模型输出是否正确”。两者之间隔着一条鸿沟。LLM应用的行为不只取决于代码逻辑，还受Prompt内容、模型版本、上下文长度、温度等采样参数、甚至Token限额等多重因素影响。同一个Prompt，模型版本升级后可能输出截然不同的结果；同样一段对话，换一种提问方式质量差异巨大。
所以LLMOps要解决的，本质上是一个“可观测性 + 可评估性”的问题。可观测性解决“发生了什么”，需要精确记录每次模型调用的输入、输出、Token消耗、延迟以及调用链上下文；可评估性则解决“好不好”，需要将模型输出与预期结果比对，或者通过自动评估器判断质量。这两件事组合在一起，才能构成闭环。
1.2 Langfuse和Opik各自解决什么问题
Langfuse和Opik都是这个领域里目前社区活跃度很高的开源方案，但定位和侧重点有差异。Langfuse更偏“全链路可观测与追踪”：它通过Trace（追踪）和Span（跨度）的概念记录每一次LLM调用的完整生命周期，包括输入输出、Token统计、成本估算、延迟分布，还能在链路中嵌入人工标注和自动评估结果。简单说，Langfuse让你能“看清”每一次模型交互的内部细节。
Opik则更偏“评估驱动开发”。它是由Comet ML开源的LLM评估平台，核心能力包含数据集管理、批量实验对比、在线评估（LLM-as-judge自动打分），以及将评估指标与trace关联的能力。Opik解决的是“如何科学地判断模型输出好不好”的问题，尤其适合在开发调试阶段做Prompt和模型版本的系统性比较。
有意思的是，这两者并不冲突，反而能形成互补：Langfuse负责生产环境的全面追踪和持续监控，Opik负责在开发和发布环节构建高质量的评估闭环。实际项目中，如果预算和精力有限，可以先选一个深入；如果团队规模已经到了一定程度，两者组合使用效果会更好。
2. Langfuse部署与核心概念速览
2.1 Langfuse的安装方式与选型建议
说到Langfuse的安装，目前主流的路径有两条：一条是使用Langfuse官方的云端托管服务（Cloud），注册即用，适合想快速验证的小团队；另一条是自托管部署，适合对数据隐私有严格要求的企业。考虑到很多开发团队会优先尝试自部署，我这里给出一个基于Docker Compose的快速安装配置示例。
官方提供了标准的docker-compose.yml文件，拉取后需要重点关注环境变量配置。核心变量包括：
NEXTAUTH_URL：认证回调地址，如果通过IP访问需要配置为http://<服务器IP>:3000NEXTAUTH_SECRET：会话加密密钥，可以通过openssl rand -base64 32生成DATABASE_URL：PostgreSQL连接串，默认配置会指向内置的PostgreSQL容器SALT：用于加密敏感字段的盐值ENCRYPTION_KEY：数据加密密钥
启动命令非常简单：
git clone https://github.com/langfuse/langfuse.git cd langfuse cp .env.example .env # 编辑.env，配置好NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY docker-compose up -d这里要提醒一个容易踩的坑：Langfuse从较新版本开始强制要求配置ENCRYPTION_KEY，如果不配置会直接启动失败。官方文档里有对应的生成方式，别用弱密码替代。
2.2 Trace与Span：理解Langfuse的数据模型
Langfuse的数据模型借鉴了OpenTelemetry的标准，核心就是Trace和Span。Trace代表一次完整的请求链路，比如一次用户对话请求，可能包含检索召回、LLM推理、后处理等多个环节；Span则是Trace中每个独立的操作单元。
在代码集成时，一般有两种方式：一种是使用Langfuse提供的高级SDK包装器，比如Langfuse类的trace()方法创建一个新Trace，然后在其中创建generation()或span()记录具体操作；另一种是直接使用OpenTelemetry协议把数据发送给Langfuse，适合已经有OTel基础设施的团队。
以Python为例，用Langfuse SDK手动埋点的基本结构如下：
from langfuse import Langfuse langfuse = Langfuse() trace = langfuse.trace(name="rag_query", input={"question": "什么是Langfuse?"}) retrieval_span = trace.span(name="retrieval", input={"query": "什么是Langfuse?"}) # 模拟向量检索过程 retrieval_span.end(output={"context": ["Langfuse是开源LLM可观测性平台"]}) generation = trace.generation( name="llm-answer", model="qwen-plus", input={"prompt": "基于上下文回答问题..."}, output={"answer": "Langfuse是..."}, usage={"input": 120, "output": 80, "total": 200} ) trace.update(output={"answer": "Langfuse是..."})关键点在于，Trace的树状结构还原了应用内部真实的调用关系。后续排查问题时，可以直接在Langfuse的UI面板里选择具体Trace，看到检索耗时多少、LLM生成耗时多少、哪一层拖慢了整体响应，结合Token消耗判断成本瓶颈出在哪个环节。
2.3 生产接入的几个细节：采样、分组与成本核算
生产环境接入Langfuse，我强烈建议开启采样。全量上报在大流量场景下会产生巨大的数据存储压力——每个Token消耗、每次完整输入输出都会占据存储空间。Langfuse的SDK支持在初始化时设置sample_rate参数，按比例丢弃部分追踪数据。例如设置sample_rate=0.1表示只上报10%的流量，适合高并发场景做趋势观测；在灰度发布或重要功能上线期间，再临时调整为100%做全量记录。
另一个容易被忽视的功能是Session（会话）分组。Langfuse支持给Trace绑定session_id，把多轮对话中的多次请求关联到同一次会话中，这样在UI界面可以直接回放整个对话过程，而不是一条条孤立地看请求日志。这对客服、对话助手类应用尤其重要。
成本核算方面，Langfuse会自动记录每次调用的模型名和Token用量。建议大家在传usage参数时尽量准确，来自模型API返回的usage字段直接透传即可。如果团队用到了多个模型服务商，可以在Langfuse后台给每个模型配置单价，这样UI上就能自动汇总各模型的费用趋势，月底核算成本省去不少功夫。
3. Opik的评估驱动开发实战
3.1 Opik里“数据集”的构建与管理
Opik的设计理念是“评估驱动开发”。也就是说，在改动任何Prompt或模型之前，先准备一份高质量的数据集作为回归基准，然后用评估器跑一遍分数，用数据代替直觉来判断改动的好坏。
在Opik中创建数据集非常直观。通过Python SDK可以快速把一批测试用例导入：
from opik import Opik client = Opik(project_name="rag-system") dataset = client.get_or_create_dataset(name="rag_eval_set") dataset.insert([ { "question": "什么是Langfuse?", "expected_answer": "Langfuse是一个开源的LLM可观测性与评估平台", "context": ["Langfuse支持追踪、评估、提示词管理等功能"] }, { "question": "如何部署Langfuse?", "expected_answer": "推荐使用Docker Compose进行自托管部署", "context": ["官方提供docker-compose.yml，配置环境变量后启动"] } ])数据集的价值在于沉淀团队的测试资产。以前调试Prompt是一项纯手工活，改一版拿几条数据试一试，感觉差不多就上线，上线后出了问题再回溯是哪次改动引入的。有了Opik数据集，每次改动都能在同一批标准用例上跑回归，长期积累下来，数据集本身就是团队的评估资产。
3.2 在线评估与LLM-as-judge的设置方法
Opik的在线评估功能具备把评估器绑定到Trace上的能力。当应用实际运行时，自动触发评估器对真实用户请求的模型输出进行评分。这弥补了离线评估无法覆盖线上真实分布的短板。
在线评估最常用的方式是LLM-as-judge，即让一个强模型给另一个模型“打分”。比如用大模型对回答的“相关性”“忠实度”“有害性”等维度按1-5分评分。配置方法上，Opik的Python框架可以定义一个判断函数：
from opik.evaluation.metrics import LLMJudge metric = LLMJudge( name="relevance_score", llm_params={"model": "qwen-plus"}, criteria="判断回答是否准确且完整地回答了用户问题，且不包含无关信息", rubric={ "5分": "回答完全准确且信息完整", "3分": "回答基本准确但缺少关键细节", "1分": "回答与问题无关或严重误导" } )定义评估器后，再配合Opik的evaluate()函数对数据集或线上Trace运行批量评估。这种方式非常强大，但也要注意，LLM-as-judge的评分本身就不完全稳定，建议在关键场景搭配人工抽检，形成“机器初筛 + 人工复核”的机制。
3.3 用Opik做Prompt版本对比
另一个让我觉得值回票价的功能是Prompt和模型版本的批量对比。团队经常会遇到这类争议：A说换新版Prompt效果更好，B说旧版Prompt更稳定。在没有评估体系时，争论永远停留在“我感觉”层面。在Opik里，可以在同一个数据集上分别用旧Prompt和新Prompt跑一轮推理，得到两个实验组的结果，再用同一套评估指标打分，差距一目了然。
实际操作时，我一般会把两个实验跑完后的结果表格导出，直接贴到项目文档里作为Prompt变更的依据。这样每次Prompt调整都有评估数据支撑，不再依赖某个人拍脑袋决定。
4. 把Langfuse与Opik组合起来：我的落地实践
4.1 组合方案的整体架构与数据流
Langfuse和Opik的定位差异决定了它们组合使用时的各自角色。我的落地架构分为三层：
第一层是生产追踪层，由Langfuse承担。所有线上请求通过SDK埋点进入Langfuse，记录完整的调用链、Token消耗、延迟指标，并且利用采样策略控制数据量。第二层是评估层，由Opik承担。从Langfuse导出的关键Trace数据，或者直接从业务侧采集的用户反馈样本，流入Opik数据集；然后通过LLM-as-judge和规则评估器进行批量评分。第三层是决策层，把Opik评分结果经过聚合分析，回传给团队。如果评估得分下降，就在Langfuse中对比Trace记录，定位变化来源。
这套组合方案不要求开发大量胶水代码，Langfuse和Opik都提供Python SDK，业务代码中并行初始化即可。
4.2 如何把Langfuse的Trace数据同步到Opik做评估
将Langfuse中的真实数据导入Opik评估，有两种常见做法。数据量不大、团队刚起步时，可以直接调用Langfuse SDK查询Trace，再写入Opik数据集：
from langfuse import Langfuse from opik import Opik langfuse_client = Langfuse() opik_client = Opik(project_name="rag-eval") # 获取最近24小时的关键trace traces = langfuse_client.fetch_traces(limit=100, from_timestamp="2025-01-01T00:00:00Z") dataset = opik_client.get_or_create_dataset(name="production_samples") rows = [] for trace in traces: rows.append({ "question": trace.input.get("question"), "answer": trace.output.get("answer"), "context": trace.input.get("context", []) }) dataset.insert(rows)跑完评估后，可以将结果回填到Langfuse。Langfuse支持通过SDK创建Score对象并关联到Trace和Span，这样在Langfuse界面查看单个请求时，可以看到旁边有Opik给出的质量评分，省去在两个平台来回切换。
4.3 实战中的Prompt版本管理与AI原生评估
再聊一个较新的实践方向——“AI原生评估体系”。这个词其实强调的不只是写几条评分规则，而是把评估本身嵌入到开发和运营的流程里。例如在Prompt模板中预留可控参数（如输出格式、语气、长度上限），当线上出现评估分较低时，能快速定位是Prompt的哪个部分引起的。Langfuse本身也提供了Prompt管理功能，可以直接在Langfuse后台进行Prompt版本管理，将Prompt的改动与发布版本关联起来。
我在实际项目中的做法是：Langfuse里统一维护Prompt模板及版本，每次修改Prompt都记录变更说明；同时将生产环境固定比例的请求追踪标记为needs_evaluation，通过Opik定期批量打分，得到每条Prompt版本对应的线上平均分。这样评估数据反过来又能指导Prompt的迭代方向，形成一条从开发到生产再回到开发的完整闭环。
4.4 实际项目的部署配置参考
最后附上我在一个真实项目中使用的部署配置清单，供参考。服务器配置建议4核8GB以上，内存偏小会导致PostgreSQL和Langfuse容器同时运行时频繁OOM。以下是我整理的部署检查表：
- Docker Compose方式部署Langfuse，附带PostgreSQL和Redis
- 配置
NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY三个核心密钥 - Opik采用Docker Compose部署，内部使用MongoDB存储评估数据
- 设置
sample_rate = 0.2作为默认采样率，特殊时期临时调高 - 定义并固化5-8个关键评估指标，如准确性、忠实度、简洁性、有害性
- 配置监控告警规则，当平均评估分低于阈值时触发提醒
这套配置在日请求量几万次的场景下跑得很稳定，资源占用也在可接受范围内。
5. 常见问题与排查技巧实录
5.1 Langfuse部署与接入故障排查
Langfuse部署最常见的坑是密钥配置不全导致容器启动失败。如果你看到容器不断重启，先检查日志，重点看NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY是否都已经配置，且长度是否符合要求。特别注意ENCRYPTION_KEY必须为32字节以上随机字符串，可以用以下命令生成：
openssl rand -base64 32接入SDK后常见的另一类问题是数据不展示。大多数情况下和网络连通性有关，自部署的Langfuse如果没有配置正确的公网或内网访问地址，SDK上报的请求会失败，而且SDK默认的日志级别是WARNING，很容易忽略。可以在初始化时打开调试日志：
langfuse = Langfuse(debug=True)如果看到HTTP 401或403，则是public_key和secret_key配置错误，到Langfuse项目设置里重新生成即可。
5.2 Opik评估结果不稳定的处理思路
使用LLM-as-judge时，评估结果偶尔出现波动是正常现象。比如同一组数据跑两次，某条用例的得分从4分降到了3分。排查时不要急着怀疑评估器坏了，先看看被调用模型是否出现输出格式变化。Opik的LLM-as-judge通常会在Prompt中要求模型输出JSON格式的评分，如果模型偶尔返回了额外文字或格式不完整，解析就会失败。
我的处理方案是：第一，在评估器定义中加timeout和错误重试机制；第二，对评估跑批任务设计简单的自我一致性检查，对得分波动较大的用例单独抽出人工复核；第三，固定在每天的同一时间段跑批评估，部分第三方模型在高峰期容易出现推理能力波动，固定时段可以降低这类噪音。
5.3 采样策略与数据量的平衡
采样率调低会节省存储，但也会让排查问题时的样本变少。有一次我线上排查一个偶发问题，由于采样率设置为0.05，翻了很久日志都找不到一条相关Trace，最后只能临时调高采样率等待问题复现。这个教训告诉我：采样策略最好按场景区分，而不是全局一刀切。比如普通问答请求采样20%，但带有用户负面反馈标记的请求100%采样。
Langfuse SDK支持在创建Trace时按请求内容动态决定是否上报。可以参考以下伪代码逻辑：
if user_feedback_is_negative or random.random() < 0.2: langfuse.trace(...)这种方式既控制了总体数据量，又保证了对关键样本的完整捕获。
5.4 多模型对比评估的坑
如果团队在同一个应用中接入了多个模型服务商，用Opik做离线评测时有一点需要特别注意：不同模型的输出风格差异明显，同一个评估指标在它们之间的得分不具备直接的跨模型可比性。例如，qwen-plus输出简洁但信息密度高，另一个模型输出详细但冗余多，用一个强调“信息完整性”的评分标准，后者往往得分更高。因此跨模型对比时，建议将评分维度拆得足够细，比如“事实正确性”“逻辑连贯性”“完整性”分开评分，不要混在一个总分里。
6. 我的一点个人体会
前前后后在不同项目里折腾过不少LLM监控方案，我的感触是：工具只是载体，真正重要的是团队是否建立了“用数据评估模型”的意识和流程。无论是Langfuse还是Opik，本身都有一定的学习曲线，网络上教程也不少，但如果只是搭了平台而不去沉淀数据集、不制定评估标准，那这些工具最终只是形同虚设。反过来，哪怕团队暂时只用其中一个工具，只要做到了每一次Prompt改动都有评估记录、每一次线上异常都能追溯到Trace，LLMOps就算真正落地了。
最后再分享一个小技巧：评估体系不要等到生产出问题再搭，建议在第一个POC（概念验证）阶段就开始收集数据，哪怕数据量不大，至少可以建立基线。等到用户量真正上来之后，你会发现那批早期数据是无比珍贵的参照物。
