LLM 应用的评测 —— 如何测试一个 Agent

你能给一个函数写单测:相同输入、相同输出,绿或红。但你没法用同样的方式给 LLM 写单测——同一个 prompt 可能给出不同答案,"正确"是模糊的,一个修好某个用例的改动会悄悄弄坏另外十个。于是团队靠感觉发版:某人试几个 prompt,"好像变好了",就上线了。这不可扩展,还会藏住回归。评测(Evals)就是用测量取代感觉的那套功夫——一种可重复地给 LLM 应用或 Agent 打分的办法,让你靠证据而不是靠希望去迭代。本文讲怎么搭这套:数据集、打分方法、用模型来评判、评测 Agent、以及把它接进 CI 和线上。

为什么要评测,而不是凭感觉

LLM 应用有三个性质打破了常规测试。它们非确定(同一输入会变,所以跑一遍说明不了什么)。"正确"是开放式的(很少有唯一正确字符串——一段摘要可以好在很多方面)。改动有非局部影响(为一个用例改好 prompt 会悄悄拖垮别的)。后果是你必须统计地评估:跑一群用例、追踪成功率,就像追踪一个模型的准确率——而不是盯着单个输出。评测就是团队用一个数字而不是一场争论来回答"这一版到底有没有更好"。

评什么:评测金字塔

别只端到端测整体。像测试金字塔一样混合粒度:大量便宜的组件评测(检索器返回对的文档了吗?路由选对工具了吗?输出能解析成合法 JSON 吗?)、较少的端到端评测(给定用户请求,最终答案好吗?),以及薄薄一层昂贵的人工评审。组件评测能定位失败——端到端掉分时,它们告诉你哪一级坏了——这正是 RAG 或 Agent 这种多步流水线最需要的。

评测数据集

一切都建在数据集上,而好的数据集才是真正的护城河。一个用例 = 一个输入 + 一种判断输出的办法——有时是精确的期望答案,更多时候是一组标准或一个用于对比的参照。用例从哪来?

• 线上轨迹 —— 最好的来源。挖真实用户输入(尤其是失败和点踩),整理成用例。你的评测集应该长得像你的流量。
• 手写边界用例 —— 你知道难的那些棘手输入:歧义查询、对抗 prompt、空/垃圾输入、长尾。
• 合成生成 —— LLM 能起草候选用例来快速铺覆盖率,但必须有人审,否则你是在拿编出来的"真值"打分。

两条规矩让集合保持诚实:标一份你从不调参的保留集(这样你量的是泛化,不是记忆),以及不断从新流量刷新(静态集会随用法漂移而过时)。目标是覆盖输入分布和失败模式,而不是堆数量——几百个精选用例胜过几千个近似重复。

怎么给输出打分

每个用例都需要一个打分器把输出变成分数。有四类,从最便宜最可靠排起:

诀窍是把打分器和标准对上:别花 LLM-judge 去查一个正则就能验的东西,也别假装关键词匹配能抓住"这段解释清不清楚"。很多真实评测会组合打分器——代码查格式 + LLM-judge 评质量。

scores = []
for case in dataset:
    out = system.run(case.input)            # 被测的 app/agent
    s = {
        "format":  is_valid_json(out),         # 启发式
        "correct": run_tests(out, case.tests),  # 代码
        "helpful": judge.score(case.input, out, rubric),  # LLM-as-judge
    }
    scores.append(s)
report = aggregate(scores)               # 每个标准的通过率
assert report.correct >= baseline.correct  # CI 门禁:不许回归

认真做 LLM-as-Judge

对那些模糊标准——忠实度、有用性、语气、"有没有遵循指令"——一个强模型能以人工零头的成本和延迟给输出打分。这就是 LLM-as-judge,它让评测开放式生成变得可行。但天真的 judge 不可靠,所以把它当成一个你要部署的模型来对待:先设计,再验证。

让 judge 可靠

• 给它细则。 别问"这好吗"——给明确标准和量表("忠实度打 1–5:5 = 每条主张都被来源支撑……")。让它先给理由再给分,能提升一致性。
• 能成对就成对。 "A 和 B 哪个更好?"比绝对的 1–5 打分更可靠,而且这正是你对比两版时想要的。
• 知道它的偏差。 Judge 偏爱第一个选项(位置偏差——随机化顺序)、更长的答案(冗长偏差)、以及自己同族的输出(自偏爱)。要缓解,别无视。
• 对齐人工校准。 让人标一批样本,再看 judge 是否一致(如测一致率/相关性)。一个你没验证过的 judge,只是流水线里又一个未经验证的模型。

评 Agent,不只是评答案

Agent(见 Agent 如何工作)把门槛抬高了:一个多步 Agent 可能走着糟糕的路径到达一个好的最终答案——或在中途以"只看最终答案就漏掉"的方式失败。所以要评轨迹,不只是结果:

• 任务成功 —— 它最终达成目标了吗?(端到端指标)
• 工具调用正确性 —— 用对工具、传对参数了吗,某个失败时能恢复吗?
• 轨迹质量 —— 步骤顺序合理、没有无谓循环、不重复一个失败动作。
• 效率 —— 到达目标用了多少步、token、延迟、成本;40 步 $2 成功的 Agent 比 6 步 2 毛搞定的差。

实操上,你记录完整轨迹(每个 prompt、工具调用、观测)并打分——用启发式查工具调用合法性和步/成本预算,用 LLM-judge 评"这计划合理吗"。这就是 harness 工程 和评测密不可分的原因:你是对着轨迹评测来调 harness。

离线门禁与在线评测

评测在两个循环里跑,两个都要。

离线 —— 把关发版

在每个有意义的改动(改 prompt、换模型、调检索)上,于 CI 里跑评测套件。套件报告每个标准的通过率,并与当前基线对比;掉分就挡住合并,跟单测失败一样。这就是让你能无惧地改 prompt 的东西——集合会抓住那些悄悄的回归。

在线 —— 线上永远不等于你的集合

离线评测只覆盖你想到要放进去的,而真实流量总在漂,所以也要在线上评:用真实结果指标对新旧版做 A/B;在抽样的线上输出上跑便宜的护栏评测(在线 LLM-judge 标记不忠实或不安全的回答);采集用户反馈(点赞、编辑、重生成)作为持续但有噪声的质量信号。线上发现的失败,会变成明天的离线用例——闭合上图那个循环。

坑与取舍

• 过拟合评测集。 对着一个固定集合调久了,你提升的是分数不是产品。留保留集、从流量刷新、也看线上指标。
• 未校准的 judge。 不对齐人工就信 LLM-judge,等于把 judge 的偏差烤进每个决定。先验证,换 judge 模型时再验证。
• 污染或陈旧的数据。 从训练数据泄露的用例会虚高分数;不再像流量的用例会误导你。要 curate 和轮换。
• 只优化一个数字。 单个平均会藏住取舍——质量上升的同时成本或延迟可能爆掉,或者均值变好但某个切片回归了。盯一个小看板(按标准、按切片),别只看一个数。
• 评测的成本。 LLM-judge 和大套件费钱费时;分层——每次提交跑快而便宜的检查,完整昂贵套件每晚或发版前跑。