「哪个 prompt 比较好?」听起来是个简单的问题。实际上,评估 AI 输出结果是应用 AI 领域中最困难的问题之一。人工评估既昂贵又缓慢。像 BLEU 或 ROUGE 这样的自动化指标会遗漏细微差异。而单一评审的 LLM 评估会受到位置、冗长程度和评审模型本身偏好的影响。
我们建立了一个 bakeoff 系统,透过多评审评分、位置随机化和统计信赖区间来解决这些问题。本文将介绍其架构、统计方法以及我们学到的经验。
什么是 Bakeoff?
Bakeoff 是一种结构化的比较方式,用于比较两个或多个 AI「选项」——不同的 prompt、模型、recipe 或 workflow——并对相同的输入进行评估。可以把它想像成 AI 输出结果的 A/B 测试,但使用的是自动化评分而非使用者点击率。
JieGou 支援 6 种 bakeoff 模式:
- Prompt vs. prompt — 相同 recipe,不同 prompt 范本
- Model vs. model — 相同 recipe,不同 LLM 供应商
- Recipe vs. recipe — 完全不同的 recipe
- Workflow vs. workflow — 不同的多步骤 workflow
- Workflow model vs. model — 相同 workflow,不同模型
- A/B test — 即时生产环境路由与使用者回馈
每个 bakeoff 最多可以有 8 个选项和 10 个输入,总计上限为 40 个单元格(选项数乘以输入数),以控制成本。
LLM-as-Judge 评估
每个单元格都由 LLM 评审使用清单式比较方法进行评估。评审不是独立评分每个输出(这会失去相对脉络),而是同时看到所有选项的输出结果,并根据定义的标准进行评分。
评估标准有加权,分数范围为 0 到 100。预设配置使用:
| 标准 | 权重 |
|---|---|
| 相关性 | 30% |
| 完整性 | 25% |
| 清晰度 | 20% |
| 准确性 | 15% |
| 格式 | 10% |
使用者可以自订这些标准或建立自己的标准。权重总和必须为 100%。
评审 prompt 会为每个选项的输出结果标上随机标签(A、B、C…),并要求提供结构化分数。我们使用 invokeLLMStructured() 搭配 Zod schema,确保评审回传有效、可解析的分数。
位置随机化
LLM 评估中一个已知的偏差是位置偏好——模型倾向于偏好最先或最后呈现的输出结果。我们在每次评估呼叫时都会随机化选项到标签的对应关系。选项 1 可能在某次执行中标记为「C」,在下一次则标记为「A」。
这不会消除位置偏差,但会将其随机分布到各个选项中,而不是系统性地偏好某一个选项。经过多个输入后,这种效应会平均化。
多评审共识
单一评审的评估本质上是有杂讯的。不同模型有不同偏好,即使是相同模型在相同输入上也可能给出不同分数。我们在同一评估上并行执行 2-3 个独立评审,并衡量他们的一致性。
Kendall’s tau 透过计算一致和不一致配对来衡量排名相关性。如果两位评审都将选项 A 排在选项 B 之上,这是一个一致配对。如果他们意见不同,则是不一致配对。系数范围从 -1(完全不一致)到 1(完全一致)。
Spearman’s rho 提供了补充性的衡量指标:1 - (6 * 排名差异平方和) / (n * (n^2 - 1))。
我们将一致性分类为:
- 高度一致 — Kendall’s tau ≥ 0.7
- 中度一致 — 0.4 ≤ tau < 0.7
- 低度一致 — tau < 0.4
低度一致性本身就是一个有用的讯号。这通常表示标准不够明确、输出结果太相似难以区分,或任务没有明确的「更好」答案。
共识排名是透过平均所有评审的分数来计算,并汇总每个选项的获胜次数。
统计信心度
对于每个选项,我们计算平均分数的 95% 信赖区间:平均值 +/- 1.96 * 标准差 / sqrt(n),其中 n 是输入数量。
当两个选项的信赖区间重叠时,我们会标记出来——这种差异可能没有统计意义。这可以防止团队基于杂讯做出决策。在 3 个输入上的 2 分差异可能只是随机的。在 10 个输入上且信赖区间不重叠的 15 分差异则值得采取行动。
A/B Test 整合
Bakeoff 回答「理论上哪个更好」。A/B test 回答「在生产环境中哪个表现更好」。
当 A/B test 启动时,传入的 workflow 执行会随机路由到不同选项(50/50 分配)。使用者对每个输出结果提供星级评分(1-5)作为回馈,我们执行卡方检定来确定统计显著性。
测试在满足两个条件时自动停止:p 值 < 0.05 且每个选项至少有 30 个回馈回应。这可以防止过早下结论和不必要的长时间测试。
路由决策在 Redis 中快取,TTL 为 30 秒以保持一致性——同一使用者在快取视窗内重复存取端点时会获得相同的选项。
成本管理
多评审评估会将执行成本乘以评审数量(2-3 倍)。我们在 bakeoff 开始前提供预估成本,使用历史 token 使用量中位数作为基准,并考虑评审乘数。
40 个单元格上限(8 个选项乘以 10 个输入)和 10 个标准限制使个别 bakeoff 保持在可控范围内。对于 workflow 选项,我们使用多步骤 token 预测,考虑每个步骤的模型和预期的输入/输出大小。
我们学到的经验
位置随机化是必要的,而非可选的。 在我们早期测试中没有随机化时,无论品质如何,首先呈现的输出结果在 60-65% 的评估中获胜。随机化将这个比例降至 48-52%,这在杂讯范围内。
两位评审可以捕捉到大多数分歧。 从 1 位增加到 2 位评审大幅提升了可靠性。从 2 位增加到 3 位评审进一步改善,但报酬递减。对于大多数使用案例,2 位评审配合 Kendall’s tau 报告是最佳选择。
信赖区间改变行为。 在我们加入信赖区间报告之前,团队会针对 1-2 分的分数差异进行优化。现在他们看到重叠的区间,并正确地将其解释为「没有有意义的差异」。这节省了原本会花在追逐杂讯上的工程时间。
结构化输出 schema 使评估更可靠。 早期版本使用自由格式的评审回应,并用正规表示式解析分数。这经常失败——模型会添加解释、使用不同格式或跳过标准。切换到 Zod 验证的结构化输出完全消除了解析失败。