MakoBench的工作原理：开放式大语言模型基准测试解析

前往 GitHub 上的 CrucibleForge

文中的示例均基于2026年11月7日发布的4.0版测试套件。4.1版测试套件修正了答案并重新计算了所有模型的得分，其评分规则与奖励机制保持不变；关于4.1版的具体改动及最新得分数据，可参阅此处说明。

MakoBench是什么

从模型到评分结果

1. 模型可以是本地运行的模型，也可以是托管在云端的API
2. 标准测试案例所有模型都要回答相同的问题
3. 模型给出的答案这些答案会被保存下来，以便后续重新评分
4. 评分过程代码类任务：将代码与隐藏测试及预期输出进行比对；对话类任务：使用本地运行的评判模型并依据文本规则进行评估
5. 最终得分代码与对话得分相加得出总分，同时会给出误差范围
6. 评分结果展示显示模型的排名、所属类别及相关信息

MakoBench是一个公开的语言模型评分平台，无论模型是本地运行还是托管在云端，都会采用相同的评分标准。它主要评估两项能力：编写可正常运行的代码的能力，以及进行角色扮演或对话交流的能力。MakoBench测试什么以及不测试什么一文详细说明了其评估范围。

该平台的运行引擎为 CrucibleForge，这是一款免费且开源的工具（采用 MIT-0 许可）。您可参照 在自有模型上运行 CrucibleForge 的指南来在自己的模型上使用它。

评分是如何确定的

一次只处理一个案例

单个案例如何获得评分

1. 案例内容一个包含11个步骤的预订流程，其中设置了若干测试点
2. 模型回复模型输出的内容及其调用的工具信息
3. 逐步骤校验使用的工具是否正确？参数是否恰当？是否应直接回应用户而非调用工具？
4. 结果统计通过7步，失败4步；评分：7/11 = 0.64

一个“案例”即一项任务：可能是编写某个函数、预测程序的输出结果、进行工具相关的对话，或是一次较长的角色扮演。每个案例都会被拆分成多个小环节来评分，比如隐藏的测试点或对话步骤；因此即便答案只是接近正确，也能获得大部分分数。每个标准案例仅执行一次。

详情请参阅：所有测试案例列表以及评分代码（graders.py）。

评判器如何给聊天回复打分

评判器如何对聊天回复进行评分

1. 回复内容一次聊天会话中的回复
2. 评判问题“该角色是否履行了承诺？”
3. 评判模型给出“是”或“否”的回答
4. “是”+ 精确的引用内容程序会检查该引用内容：长度至少需达12个字符，且必须与回复中的文字完全一致。
5. 最终结果符合条件则计为“是”；否则计为“否”。
6. 文本规则，无需评判器参与字数限制、禁用短语以及预先设定的事实条件均由程序自行检查；未能通过这些检查的回复即视为不合格。

程序本身无需主观判断。但聊天系统需要这种判断，因此我们会使用另一个语言模型——即评判模型——来对每个回复给出“是”或“否”的答复。在本系统中，我们使用的是 Gemma 4 31B 模型（未经审查的“非正统”版本，采用 Q8 量化方式）；Q8即指权重的8位量化形式。“是”的回答只有在包含与原文完全一致的引用内容时才有效，因为评判模型很容易给出“是”的答复。在每批数据处理前，评判模型必须能够正确识别一个已知的合格回复并识别出一个已知的不合格回复；否则该批次的处理流程便会中止。

如果某个问题本身就可能导致判定失败，那么该问题会被询问三次。只有当大多数回复结果为“是”时才算通过；若出现平局则视为“否”。

详情请参阅：评判器代码（judge.py）以及 聊天会话的运行机制。

代码与对话共同构成总分

代码部分：10分

• 功能实现5共6个程序
• 预测与错误排查2.5共3项任务
• 工具使用2.5共3次对话

对话部分：10分

• 深度角色扮演3共2次会话
• 日常对话3共2次会话
• 角色塑造2共2次会话
• 创意写作2共2次会话

每个评分项都会获得相应比例的分数：例如“功能实现”占76%，即获得5分中的3.8分。这些分数累加后便得到代码与对话两部分的总分。另外还有专门针对成年人的测试项目，它拥有独立的评分页面且不会计入总分。

详情请参阅：评分配置文件 (bench.yaml)，其中列出了所有评分项、对应分数及其具体测试案例。

± 误差范围

误差范围的来源

1. 随机重绘案例重复1,000次；某个案例可能出现两次，也可能根本不出现
2. 对每次重绘结果进行完整评分这样就能得到1,000个总分值
3. 取这1,000个总分值中处于中间90%的部分将该区间标记为阴影区域
4. ± 值即为该区间宽度的一半Claude Sonnet 4.5模型的结果为：12.8 ± 1.1

换一组不同的案例，得到的总分值也会略有差异。这个误差范围便体现了这种变化幅度。如果两个模型之间的差值小于各自的误差范围，则它们在统计上可视为平局。该误差范围并未涵盖每次运行时的随机波动，因此哪怕只有一两分的差距，也可视作平局。

详细说明：误差范围的计算代码（headline.py）。

解读评分表

等级划分

• C级10分以下最低等级
• B级10分及以上10到13分之间
• A级13分及以上13到16分之间
• S级16分及以上16到20分；只有获得额外加分才能达到此等级

总分范围：0至20分

• Claude Sonnet 4.512.8 ± 1.1B级
• DeepSeek V4 Flash19.2 ± 0.8S级

关于运行成本、系统环境及其他相关信息，请参阅MakoBench文档页面以及README中的评分表说明。

示例：模型在标准测试集上的表现

代码能力评分：10分中的6.1分

• 功能实现3.8满分5分
• 预测与漏洞排查0.5满分2.5分
• 工具使用能力1.8满分2.5分

对话能力评分：10分中的6.7分

• 深度角色扮演2.0满分3分
• 对话流畅度2.0满分3分
• 角色塑造能力1.3满分2分
• 创意写作能力1.4满分2分

Claude Sonnet 4.5仅参与了标准测试集的评估。以下是其各项评分的具体计算方式。

最终总分为6.1 + 6.7 = 12.8 ± 1.1，属于B级水平。其中表现最好的“功能实现”维度也仅获得了76%的得分，未能达到解锁奖励所需的90%门槛。因此所有奖励项均无法解锁，最终得分仅基于标准测试集得出。目前大多数模型都处于类似情况。

奖励题组

题组如何解锁

某部分的奖励题组解锁流程示例

1. 标准题目例如“函数”这一部分的标准测试题
2. 正确率是否达到90%或以上？否：题组被锁定，得分为0；该部分仍保留原有标准分数。是：第1级题组解锁，每个题组价值1分。
3. 待处理状态已解锁但尚未运行的题组：目前得分为0。
4. 每个题组贡献相应分数题组运行时可贡献0至1分。答对3道题中的2道可获得约0.67分。
5. 所有第1级题组的正确率是否均达90%或以上？否：流程终止，分数保持不变。是：第2级题组随之解锁，以此类推。
6. 部分总分计算方式标准分数加上所有已运行题组的得分之和。

奖励题组是一组难度较高的题目，通常每个部分包含三道。CrucibleForge将其称为“阶梯式题包”。具体规则如下：

• 解锁条件。只有当某部分的标准题目以及所有低级别题组的正确率均达到90%或以上时，对应级别的题组才会解锁。
• 锁定、解锁与待处理状态。锁定：尚未获得；解锁：已获得并可运行；待处理：已获得但尚未运行或评分，目前计分为0。
• 每个题组最多贡献1分。一道题组的分数由所有答题结果共享，允许部分得分：答对3道题中的2道可获约0.67分。若同一题目被测试两次，则取两次结果的平均值。
• 分级机制。同一级别的所有题组会同时解锁，每个题组都会为该部分贡献相应分数。

截至4.1版本，所有题组均为第1级。Code部分共有三个题组（每个部分一个），Chat部分则有五个（其中“深度角色扮演”部分包含两个）。因此Code部分最高可得13分，Chat部分可达15分。若某部分的标准测试题尚未完成，则其对应的奖励题组也无法解锁。

详情请参阅：奖励题组规则、解锁逻辑代码（ladder.py）以及公开的奖励题组示例。

示例：模型成功解锁题组的过程

DeepSeek V4 Flash成功解锁了奖励题组

1. 函数部分：6道标准程序题全部通过，正确率100%，获得5.0分。
2. 正确率超90%：触发解锁机制“函数”部分的第1级奖励题组随之解锁。
3. 3道难度较高的题目，每道均测试两次第1题：两次结果均为0 → 得0.00分；第2题同样为0 → 得0.00分；第3题：一次测试中通过了6组用例中的4组，另一次测试未得分 → 得0.33分。
4. 该题组贡献分数：0.33 ÷ 3 = 0.11“函数”部分最终得分：5.0 + 0.1 = 5.1分。
5. 深度角色扮演部分：正确率74%因未达90%门槛，其对应的奖励题组仍处于锁定状态；该部分得分为2.2/3。
6. Code部分总分：11.2 = 5.1 + 2.7 + 3.3只有借助奖励题组才能突破10分大关。

DeepSeek V4 Flash顺利完成了全部6道“函数”部分的标准测试题，从而解锁了对应的奖励题组：该组题要求从零开始编写三个程序，每个程序均需测试两次。模型仅部分完成了其中一个程序的编写：一次测试中通过了6组用例中的4组，另一次测试则未得分，因此该题得分为0.33。该题组最终贡献的分数为(0 + 0 + 0.33) ÷ 3 = 0.11分。Code的其他两个部分以及创意写作部分也相继解锁了各自的奖励题组。最终Code部分的总分达到11.2分，突破了10分的基准线；整个测试的总分则升至19.2 ± 0.8分。

不过在“深度角色扮演”部分，模型的正确率仅为74%，因此该部分的奖励题组依然处于锁定状态。每个部分的解锁流程都是独立的。

测试是如何构建的

保持案例的时效性

案例发生变更时会触发什么？

• 如果问题或其测试内容发生变化生成新答案所有模型都会重新生成答案
• 如果评判标准或规则发生变化重新评判评判器会重新读取已存储的回复内容
• 如果文本校验规则或答案本身发生变化重新评分重新进行评分，无需调用模型
• 如果没有任何变化维持原状已存储的答案依然有效

每个已存储的答案都带有其所对应的案例标识信息。当案例发生变更时，只有受该变更影响的部分才会被重新处理；旧答案与新答案绝不会混杂在一起。详情请参阅：案例标识相关代码 (version.py)。

4.1版答案集的审核流程

4.1版答案集的审核过程

1. 所有公开的答案集共63个案例
2. 两名审核员审核员A和审核员B各自阅读每一个案例。
3. 逐一验证每个答案代码类案例：运行参考程序与测试；聊天/工具类案例：与各模型预先存储的答案进行比对。
4. 对答案进行分类约190个答案被确认为正确，并据此调整得分；约95个答案被判定为错误，每个都有书面理由说明。
5. 对所有修正结果进行二次核查“拒绝作答不应获得加分；难度高的任务依然保持原有评分标准。”
6. 重新运行程序并重新评分所有被修改过的案例均需重新处理。

答案集可能存在两种错误：要么接受了错误的答案，要么因要求超出了任务范围而否定了正确的答案。在4.1版中，两名审核员各自独立审阅所有公开的答案集；任何修改前均需将相关答案与预先存储的标准答案进行比对。此外，拒绝作答也不会获得加分——没有任何案例会将“拒绝回答”视为加分依据。4.1版：有哪些变化一文列出了所有修正内容。

从初始套件到新数据包

目前的套件情况

1. 3.0满分100分
2. 3.9新增奖励数据包
3. 4.0代码与对话类题目各10道
4. 4.1答案核对完成

全新的奖励数据包开发流程

1. 撰写阶段多个模型分别起草测试案例
2. 攻击测试另一模型尝试破解各个测试用例
3. 评判验证正确答案能通过，但那些看似不错实则有缺陷的答案则无法通过
4. 试点测试由若干性能强劲的模型参与测试
5. 优化修正根据试点测试结果进行调整与修复
6. 正式发布经审核后正式投入使用

3.9版本中新增了奖励数据包，目的是避免所有优秀模型都获得满分。旧版测试套件的内容在套件历史记录中保持不变，而每次引擎更新详情则记载于 CrucibleForge更新日志中。

当模型在某一类测试中开始频繁获得满分时，就需要更难的奖励数据包（即新的测试包）。每个新数据包的开发流程均如上所述。其中“评判验证”环节最为关键：如果评判系统无法区分正确答案与那些看似不错实则有缺陷的答案，那么该数据包便无法被公正地评估。

我为何创建这个工具

我厌倦了无法区分不同模型的情况。我希望能有一个任何人都能使用的快速基准测试工具，适用于任何模型，并能给出用户可以自行验证的数值结果。我觉得这样会很有价值。

如果您觉得这个工具有用，不妨捐款以支持其持续更新。您也可以投票选出我们接下来要测试的模型。

相关阅读：CrucibleForge的工作原理。