Langfuse 实战诀窍：5个让LLM观测效率翻倍的操作

如果你正在用Langfuse做LLM应用的观测和调试，别只把它当个日志面板。这玩意儿的Trace和Eval功能，玩透了能让你少掉不少头发。下面这5个技巧，是我在折腾开源LLM项目时实打实榨出来的。

技巧一：用“自定义Score”给每个Trace贴标签，而不是死磕原始日志

很多人把Langfuse当黑盒记录仪，一股脑把Prompt和Response丢进去就完事。其实你完全可以在Trace里注入自定义的Score字段，比如user_satisfaction、latency_tier。具体操作：在代码里调用trace.score()方法，传入一个字典，比如{"quality": 0.85, "cost_conscious": True}。这样在Langfuse的Dashboard里，你可以直接用这些Score做过滤和聚合——比如只看“高成本但低质量”的Trace，比翻原始日志快10倍。我习惯在每次LLM调用后，根据输出长度和用户反馈动态打一个“效率分”，然后跟Token消耗一起看，异常点一目了然。

技巧二：利用“Session”分组，把多轮对话串成一条完整链路

Langfuse默认每个请求是一个独立Trace，但很多场景下，用户跟你的AI助手聊了5轮，每轮都在改上下文。如果你不把Session ID传进去，这5轮就是5个孤岛。诀窍是在初始化Trace时，指定session_id参数，比如trace = Langfuse.trace(session_id="user_abc_20240101")。这样在界面里，你能展开这个Session看到完整的对话树，包括每轮的输入、输出、耗时、Token数。我排查“用户为什么突然不满意”时，直接看Session的时序图，哪一轮开始跑偏，一眼就能定位。

技巧三：用“Generation”记录内部中间结果，别只存最终输出

很多人只记录LLM的最终回复，但中间步骤（比如RAG检索到的文档片段、Prompt模板的渲染结果）才是调试的关键。Langfuse的generation对象可以嵌套在Trace里，你可以在代码里这样写：generation = trace.generation(name="retrieve_docs", input=query, output=retrieved_chunks)。这样在Trace详情里，你能看到每一步的中间产物。有一次我发现模型答非所问，就是因为检索到的文档里混入了无关内容，但之前只看最终输出根本找不到根因。用这个技巧，把每个“思考步骤”都记录下来，调试效率直接拉满。

技巧四：设置“Eval”的自动规则，让系统帮你标记异常Trace

Langfuse的Eval功能不是只能手动打分。你可以写一些简单的规则，比如“如果Response长度超过2000 Token，自动标记为verbose”或者“如果Latency大于5秒，自动标记为slow”。在代码里，用trace.eval()传入一个判断函数即可。我写了个规则：如果LLM的输出里出现“抱歉，我无法回答”这类拒答句式，自动打上refusal标签。然后我在Dashboard里建个视图，只看这些被标记的Trace，集中分析模型在什么场景下会“罢工”。这比事后翻日志省事多了。

技巧五：利用“Public Link”分享特定Trace给同事，不暴露全部数据

团队协作时，你不想把整个Langfuse项目都开放给每个人。Langfuse支持为单个Trace生成一个Public Link，而且可以设置过期时间。操作很简单：在Trace详情页点击“Share”按钮，生成一个只读链接，然后扔到群里。我经常在Code Review时，把出问题的Trace链接贴给队友，对方不用登录就能看到完整的调用链和Score。注意，这个链接默认不包含敏感数据字段（比如API Key），但最好还是手动检查下。这个功能在跨部门沟通时尤其好用，省得截图截半天。

这5个技巧的核心思路就一条：别把Langfuse当被动记录仪，而是主动用它来“打标签、建关系、设规则”。你越主动往Trace里塞结构化信息，后面排查问题就越像在数据库里做查询，而不是在垃圾堆里翻东西。