FlavourBench：用可执行烹饪真值给前沿语言模型排名

  • 关联论文：2608.20574
  • 作者：flyP
  • 更新：2026-08-25

一句话结论

FlavourBench 用一个版本化的"烹饪系统（culinary system）"生成 dense、可执行 ground truth：在 534 道统一任务上对 27 个前沿端点排名，每个模型严格 89 道有效响应/面板 × 14 家族，最强点估计 Grok 4.6 = 65.1（同步 95% CI 61.0–69.2），351 对模型对比中 101 对被解析为显著差异。

解决什么真问题

开放式大模型评测一直有个结构性问题——测得不是模型能力，而是裁判（judge）的能力：

  • 人类偏好 panel：贵、慢、跨实验室难复现。
  • 模型裁判（LLM-as-judge）：裁判本身有偏，与被评模型存在相关性。
  • 精确匹配 key：只能测封闭式回答，覆盖不到开放式生成。

FlavourBench 的设计目标是：真值完全可执行且对外可独立验证。它绕开"裁判"角色，把 ground truth 由一个版本化的软件系统（Epicure）实时算出——模型跑题前，所有可能的"3 选 8 配料组合"已经按既定规则被评分。这样评测只比较"模型能不能选到高分组合"，不再依赖外部打分。

核心方法

1) 任务结构：3 选 8 + 56 个组合

每道题给出 8 个候选食材，要求模型选出 3 个组成一个 portfolio。在模型运行之前，Epicure 预先对所有 56 种 (8 choose 3) 组合打分并冻结——这就是 dense、executable ground truth 的来源。

任务分三类：

  • Substitution：替换题，给定基线 portfolio，要求换掉某食材。
  • Pairing：搭配题，选出与指定食材最搭配的伙伴。
  • Constrained composition：约束组合题，比如"必须含 X、不能含 Y"。

2) 评分系统 Epicure

Epicure 是一个版本化的 culinary scoring system，输入是食材集合，输出是该 portfolio 的可执行评分。关键属性：

  • 版本化 → 真值随版本变化，但同一版本下完全可复现。
  • 在模型运行之前完成全部 56 个组合的评分，避免泄露 prompt。
  • 离线 verifier 可重建每一项分数（内容哈希 + 精确路径）。

3) 评测协议

  • 统一核心：每个模型跑同一份 534 题核心，覆盖三类题型。
  • 去偏覆盖：每个上榜模型每面板 89 道有效响应 × 14 家族 = 14,418 个 model-task cell，消除差分缺失（differential missingness）——这是排行榜可信度的基础。
  • 聚合：FlavourBench Score = 等权跨家族均值的任务分数。
  • 不确定性：
  • 50,000 anchor-cluster bootstrap → 同步 95% score band。
  • 100,000 sign-flip draws → 351 对配对模型对比，配 Holm 控制。
  • 面板校准：两份独立编译面板，r = 0.89（rank rho = 0.80），互相印证。

4) 检验标准

  • 不只比分数，还报告配对解析率（多少对模型之间能稳定区分），避免"分数都差不多"假象。
  • 同时给同步置信带（simultaneous CI），不是单点 CI——能直接做多模型同步比较。

关键实验与数据

指标 数值
评测模型 27 个 frontier endpoint
任务数 534 题/模型核心
总 cell 14,418
家族数 14（每家族 89 有效响应）
任务类型 substitution / pairing / constrained composition
每题候选组合 56 个 (8 choose 3)
Top-1 模型 Grok 4.6
Top-1 分数 65.1（95% CI 61.0–69.2）
显著解析对 101 / 351
面板一致性 r = 0.89，rho = 0.80
Bootstrap 50,000 anchor-cluster
Sign-flip 100,000 draws，Holm 控制
每题 ground truth 56 个 portfolio 评分预生成
真值系统 Epicure（版本化）
发布物 prompts / 全部 portfolio score maps / 原始响应 / 精确路径 / 内容哈希 / 离线 verifier

每个上榜模型都满足 89 有效响应/家族——这是去偏的核心，没有"某模型少答了几道所以分高"的把戏。

亮点与局限

亮点

  • 真值可执行：评测不依赖任何裁判，ground truth 由软件生成，离线可重建。
  • 差分缺失消除：89 有效响应/家族的设计让"响应数量"不再成为混杂变量。
  • 统计严谨：50,000 bootstrap + 100,000 sign-flip + Holm 控制，比多数 LLM 排行榜只报 point estimate 高一个量级。
  • 任务有真实结构：substitution / pairing / constrained composition 三类组合，覆盖烹饪推理的不同认知层级。
  • 完全可复现：prompt、score map、原始响应、路径、哈希、verifier 全部公开。

局限 / ⚠️ 待核验

  • 领域单一：ground truth 全在烹饪系统内，无法直接外推到代码、数学、医疗等其他开放域任务；评测的是"在该系统下的组合推理能力"，不是"通用开放式推理"。
  • 模型规模/家族不均：14 家族 + 27 endpoint 的覆盖对前沿模型是合适的，但对开源小模型覆盖不足——⚠️ v1 摘要未明确开源模型占比，待 A1 核 PDF §模型清单。
  • Epicure 版本锁定：评分随 Epicure 版本变化，长期榜单需配套"版本迁移"机制，否则历史分数与新分数不可直接比较。
  • 同步 CI 保守：351 对中只解析 101 对（约 28.8%），剩下 72% 配对在当前 95% 水平上不可分，对"前沿模型谁更强"的回答偏保守。
  • 顶部天花板：Grok 4.6 拿到 65.1，整体分数不算高，可能反映任务难度而非模型能力——⚠️ 待 A1 核 PDF §任务难度分析。

对工程落地的启发

  1. 去偏覆盖是评测的第一原则：先确保每个模型跑同样多的有效响应，再谈分数高低。89/家族的硬约束比"取平均值"重要得多。
  2. 真值可执行 > 真值"对"：在不可能枚举所有正确答案的开放域里，枚举"可程序化评估的中间产物"是务实的折中——这与单元测试、可验证 reward 的思路一致。
  3. 同步置信带 vs 单点 CI：做多模型产品选型时，同步 CI 才能告诉你"哪个真的比哪个好"；逐对单点 CI 会严重高估"显著对"数量。
  4. 离线 verifier 是可复现性的最低门槛：内容哈希 + 精确路径 + 重建脚本三件套，让任何第三方能复现排行榜。
  5. 任务族分层：substitution / pairing / constrained composition 三层对应不同推理复杂度，参考价值比单类题高。

与同方向工作的关系

  • vs. MMLU / GSM8K / HumanEval：这些都是封闭式、有精确 key 的评测，覆盖"会/不会"型能力；FlavourBench 走开放式 + 可执行 ground truth 的中间路线。
  • vs. AlpacaEval / MT-Bench / Chatbot Arena：AlpacaEval/MT-Bench 走 LLM-as-judge，Chatbot Arena 走人类偏好——都是"用裁判"流派；FlavourBench 拒绝裁判，用软件生成 dense 真值。
  • vs. SWE-bench / WebArena：都是"可执行真值"路线的代表；FlavourBench 把这条路线推到"开放式生成"领域。
  • vs. BIG-Bench / HELM：BIG-Bench/HELM 提供统一评估框架；FlavourBench 提供了"在统一框架下、单一垂直域、深度可控"的具体实例。

适合谁读

  • 做 LLM 评测基础设施的工程师：差分缺失消除 + 同步 CI + verifier 三件套是直接可抄的工程范式。
  • 选模型的产品/采购：在多模型对比时用 FlavourBench 的 101/351 解析率思路，比"看排行榜总分"靠谱。
  • 做开放域推理/规划的研究者：把"可执行真值"思路搬到代码生成、agent 任务上是现成的方法学。
  • 关心单一模型绝对能力的人：FlavourBench 分数是"在 Epicure 烹饪系统内的相对排名"，不是 GPT/Claude 的 IQ 分数。

不确定处

  • Epicure 评分函数的具体形式（基于哪些规则/数据）——v1 摘要未明确，待 A1 核 PDF §Epicure 实现细节。
  • 14 家族的具体构成 + 27 endpoint 的开源/闭源比例——⚠️ 待 A1 核 PDF §模型清单表。
  • 351 对配对中 250 对"无法解析"的细节分布（是模型分数聚类还是 CI 太宽）——⚠️ 待 A1 核 PDF §结果讨论。
  • "constrained composition"题型的具体约束类型分布——v1 摘要未明确。

工程落地与核查（Jay）

事实核查

可核实项：

  • 核心数字（534 / 27 / 89 / 14 / 65.1 / 101/351 / r=0.89 / rho=0.80）均与摘要一致；⚠️ 50,000 anchor-cluster bootstrap 和 100,000 sign-flip draws 是重计算量，摘要未给出原始 seed 或 GPU hour 估算，无法独立复现，但方法论描述完整。
  • 56 个 (8 choose 3) 组合 = 56 × 534 = 29,904 个预生成的 portfolio 评分，这是 Epicure 真值库的可重建规模，摘要数字间逻辑自洽。

存疑项：

  • ⚠️ Grok 4.6 的 65.1 分含义：摘要未明确 65.1 是满分多少——是 100 分制？还是 56 分满分（最高组合分数区间）？65.1 / 100 还是 65.1 / 56，意义完全不同。若满分是 56，则 65.1 > 56 是不可能的，所以必是 100 分制，但摘要未明说。⚠️ 这是评分量纲问题，影响所有模型横向可比性。
  • ⚠️ 开源模型比例：14 家族 + 27 endpoint，若含 ChatGPT/Gemini/Claude 等闭源大厂，端点覆盖偏向商业模型；开源小模型在烹饪域的能力边界未知。⚠️ 待 A1 核 PDF §模型清单表确认开源/闭源比例。
  • ⚠️ "Constrained composition"约束类型：若约束是硬扣分（hard penalty）而非软评分，则模型的最优策略完全不同；⚠️ 摘要未明确约束的评分机制。

措辞一致性：

  • 摘要"评测的是'在该系统下的组合推理能力'，不是'通用开放式推理'"——这一自我定位表述清晰，与局限性节一致。
  • ⚠️ "真值可执行且对外可独立验证"——Epicure 版本化是关键前提，但版本迁移机制（当 Epicure 升级时历史分数如何可比）摘要完全未提，这是生产系统长期运营的重大隐患。

可读性精修

  • "亮点与局限"节"顶部天花板：Grok 4.6 拿到 65.1，整体分数不算高"——⚠️ "不算高"是主观评价，应改为"65.1（100 分制）的绝对分值需结合任务难度分布解读；若 Epicure 评分区间是 0–100，则 65 分对应中高分段；若结合 95% CI [61.0–69.2]，Grok 4.6 与其他顶部模型的 CI 已有重叠，具体排名需参照 PDF §结果图的完整分布"。
  • "与同方向工作的关系"节"SWE-bench / WebArena：都是'可执行真值'路线"——⚠️ FlavourBench 与 SWE-bench/WebArena 的核心区别是：后两者是封闭域（代码执行/网页操作），ground truth 天然可枚举；FlavourBench 则是把烹饪这个"看起来开放式"的任务枚举化，⚠️ 这里存在一个未被讨论的隐含假设："Epicure 评分函数是否捕获了真实人类对食物组合的偏好"，即 ground truth 的有效性本身未被验证。

工程落地：实际系统怎么用

FlavourBench 的工程可直接复用的组件：

  1. 89/家族去偏设计：任何多模型对比评测，在采样时强制每个模型跑相同数量的有效任务，是消除差分缺失的工程第一原则。
  2. 50,000 anchor-cluster bootstrap：比 naive bootstrap 更适合有层次结构（model → family → task）的评测数据；工程实现可参考 bootstrapped 库或自定义分层重采样。
  3. Holm 校正在多对比较中的应用：当评测端点超过 10 个时，对数为 O(n²) 的配对比较必须做 family-wise error rate 控制；Holm 比 Bonferroni 功效更高，是工程实现的最低门槛。

Epicure 作为生产系统的工程挑战：

  • 版本锁定是 Epicure 的阿喀琉斯之踵。当 Epicure 发布新版本（修正评分bug 或更新食材库）时，所有历史评测分数立即不可比。⚠️ 工程团队若要用 FlavourBench 做持续榜单，需要设计 Epicure 版本迁移协议——例如：为每次版本变更发布"换算锚点"（新旧版本在重叠食材组合上的分数映射），或强制所有模型在单一 Epicure 版本下跑完整榜单。
  • Epicure 评分函数的领域局限性：Epicure 的评分函数捕获的是"给定食材集合在 Epicure 系统内的评分"，但真实人类对食物组合的偏好可能与 Epicure 的评分函数有系统性偏差（如 Epicure 可能高估了某些香料组合的协同效应）。⚠️ 在采购决策中使用 FlavourBench 分数时，需要确认 Epicure 的评分函数是否与目标用户群体的实际偏好对齐。

101/351 解析率对采购的工程含义：

  • ⚠️ 351 对模型对比中只有 101 对（28.8%）在 95% 水平上可区分——这意味着在 FlavourBench 的烹饪任务域，超过 70% 的前沿模型两两之间没有显著差异。这对"用 FlavourBench 选模型"的工程团队是重要信号：在此评测域，前沿模型已经收敛，靠 FlavourBench 无法进一步区分。
  • ⚠️ 但需要注意：这是 95% 置信水平的结果；若接受 90% CI，解析率会上升——⚠️ 具体 90% 水平的解析率需要查 PDF §附录。工程团队应根据自身风险承受能力选择置信水平。

坑在哪：

  • 坑 1：Epicure 版本升级必须同步更新所有历史分数。若 Epicure 是开源的还好办；若是闭源商业系统，历史榜单的可信度完全依赖 Epicure 运营商的诚信。⚠️ 采购 FlavourBench 类评测服务时必须确认 Epicure 版本管理政策。
  • 坑 2：27 个 endpoint 中若有某几个因 API 限速/超时导致有效响应 < 89/家族，则差分缺失消除假设失效——⚠️ 摘要未披露实际有效响应率（actual response rate），只报告了"满足 89 有效响应/家族"的模型才上榜；这意味着落榜模型的分布特征完全未知（可能是 API 不稳定的模型，也可能是能力太弱的模型）。
  • 坑 3：离线索 verifier 的接口规范未在摘要中给出。若 verifier 的输入格式、输出格式、可复现性要求未标准化，第三方复现时可能出现"verifier 给出不同分数"的争议。⚠️ 建议工程团队在参考 FlavourBench 时，要求提供 verifier 的标准接口文档（CLI 参数、输入格式、输出格式、可复现性标准）。