Langfuse 评估（Evals）
约 917 字大约 3 分钟
LangfuseLLM ObservabilityEvals
2026-09-01
为什么需要评估
Tracing 解决了「看得见」，但没有解决「做得好不好」。改 prompt、换模型之后，回答到底变好还是变坏了？缺少客观指标，就只能靠感觉。
Langfuse 的 Evals 能力就是给 LLM 应用打分：用数据集存样本，用评分器（judge）给输出打分，让优化变成「看分数涨跌」而不是「拍脑袋」。
核心组件
| 组件 | 作用 |
|---|---|
| Dataset（数据集） | 一组「输入 + 预期输出」的样本，是评估的基准 |
| 评分器（Scorer / Judge） | 给一条输出打分的逻辑，可以是 LLM-as-judge 或纯代码 |
| Experiment（实验） | 对某个 prompt/模型版本跑一遍数据集，汇总分数 |
典型流程：
收集样本 → 建数据集 → 写评分器 → 跑实验 → 对比分数 → 决定是否上线构建数据集
数据集由 item 组成，每个 item 有 input 和可选的 expected_output：
from langfuse import Langfuse
langfuse = Langfuse()
# 如果之前已经配置好了（见下方说明），可以直接这样创建
langfuse.create_dataset(name="qa-bench")
# 往数据集里追加样本
dataset = langfuse.get_dataset("qa-bench")
dataset.add(
[
{
"input": "什么是 Langfuse？",
"expected_output": "一个开源的 LLM 可观测性平台",
},
{
"input": "Langfuse 支持自托管吗？",
"expected_output": "支持，可通过 Docker Compose 自托管",
},
]
)样本来源通常是生产里的真实 trace——把用户反馈差、模型翻车的 case 攒进来，最有价值。
两种评分器
1. 代码评分器（确定性规则）
对答案格式、关键词、长度等可客观判断的场景，用代码直接判：
def correctness(item):
score = 1 if item.expected_output in item.output else 0
return {"score": score, "reason": "基于关键词匹配"}2. LLM-as-judge（用模型评模型）
让另一个（通常更强的）模型当裁判，评估相关性、简洁性、正确性等主观维度：
from langfuse import Langfuse
langfuse = Langfuse()
# 以「相关性」评估为例，judge 提示词告诉模型如何打分
RELEVANCE_PROMPT = """请你基于「输入」和「预期参考答案」，
判断这条输出是否相关，只返回 1（相关）或 0（不相关）。"""
def relevance(item, llm):
answer = llm.invoke(
f"{RELEVANCE_PROMPT}\n\n输入：{item.input}\n"
f"预期：{item.expected_output}\n输出：{item.output}"
)
return {"score": int(answer.strip())}LLM-as-judge 适合处理「语义层面对不对」这种代码难以判断的场景。
跑实验
把「任务函数 + 数据集 + 评分器」组合起来跑一遍，得到每个样本的分数：
def my_pipeline(item):
# 你的真实应用逻辑：拿到 input，产出 output
return {"output": generate_answer(item.input)}
# 对数据集里的每条 item 跑 pipeline 并打分
results = []
for item in langfuse.get_dataset("qa-bench").items:
result = my_pipeline(item)
for scorer in [correctness, relevance]:
results.append(scorer(result))（具体 API：Langfuse 提供 run_experiment 及 langfuse evaluate CLI 来批量执行，这里演示核心思路。）
关键点：每次改 prompt 或换模型，都用同一套数据集 + 评分器重跑，分数可横向对比。评估结果会存回 Langfuse，直接在 UI 上看到平均值、分布和每条明细。
评估的最佳实践
- 样本要来自真实分布：生产 trace 的 bad cases 比人工编造更有代表性
- 组合多种评分器：客观（代码）+ 主观（LLM-as-judge）结合，单一维度容易误判
- 固定基准：数据集和评分器要保持稳定，否则分数不可比
- 关注分数分布：平均分之外，还要看极端 case，平均分可能掩盖失败样本
小结
Evals 把「LLM 应用的迭代」从玄学变成了工程：样本 → 数据集 → 评分 → 对比。配合 Tracing 收集样本、Prompt 管理 做版本切换，就形成了一条完整的「观测 → 评估 → 优化」闭环。