证据与评估
不要只看图表，应该怎样评估 Sakana Fugu
官方分数是有价值的厂商证据，但不是采购结论。本流程把图表变成受控对比，在团队真实任务上同时测正确性、成本、延迟、故障恢复、可观测性与治理要求。
1. 把公开表格当成能力地图
当前官方 Models 页面报告了下列代表性分数。这里的用途是比较 Fugu 与 Ultra，不代表本站完成了独立复现。
| Benchmark | Fugu | Fugu Ultra | 更高的 Fugu 模型 |
|---|---|---|---|
| SWE Bench Pro | 59.0 | 73.7 | Ultra |
| Terminal Bench 2.1 | 80.2 | 82.1 | Ultra |
| LiveCodeBench | 92.9 | 93.2 | Ultra |
| Humanity's Last Exam | 47.2 | 50.0 | Ultra |
| GPQA Diamond | 95.5 | 95.5 | 平局 |
| SciCode | 60.1 | 58.7 | Fugu |
| Long Context Reasoning | 74.7 | 73.3 | Fugu |
| MRCRv2 | 86.6 | 93.6 | Ultra |
分布比宣传口号更重要。Ultra 在许多难题上领先，但 Fugu 在部分科学与长上下文条目上持平或更高。即使只看厂商自己的表格，也不支持“永远用 Ultra”。
2. 弄清每个 Benchmark 在替代衡量什么
仓库问题解决
SWE Bench 类任务能帮助评估 coding agent，但你的语言组合、仓库大小、测试质量和工具权限可能不同。
终端操作
Terminal benchmark 会测多步骤行动与恢复，但不会自动覆盖你的部署权限、网络限制和破坏性操作保护。
独立代码生成
LiveCodeBench 适合固定 harness 下的代码推理，对大型私有代码库导航和长编辑会话说明较少。
科学推理
GPQA 和 SciCode 可提示困难推理能力，但不能证明模型在内部领域里会正确引用证据或遵守审查标准。
长上下文
长上下文分数只是起点。真实检索还取决于证据位置、干扰项、工具调用，以及输出能否指回原始来源。
智能体编排
Benchmark 可以只奖励最终答案，却隐藏额外延迟、重试、路由不稳定和 token。生产评估必须补上这些维度。
3. 把证据边界一直摆在台面上
官方产品页注明部分 baseline 值由各模型 provider 报告。Technical Report 描述了作者自己的训练与评估设置。这些都是重要第一方资料，但产品提供方和评估方仍高度相关。
已经有的证据
- 具名 Benchmark 与分数
- 含方法细节的 Technical Report
- 文档化模型行为和 API 字段
- 厂商定性案例
仍需自己补的证据
- 你的精确 prompt 与工具
- 重复运行，而非一次展示
- 盲测人工或确定性评分
- 总耗时与完整计费 usage
- 失败与恢复行为
- 安全和治理适配
它意味着应该降低确定性并做受控试验，不意味着可以直接宣布厂商结果为假。
4. 建立一个能暴露“不适合”的十题测试集
测试题必须是你真的愿意付钱完成的工作。数量要少到能认真评分，也要多样到无法靠一种窄技巧取胜。
| 任务组 | 示例 | 故意放入的隐患 |
|---|---|---|
| 常规 x 2 | 小 bug 诊断、聚焦解释 | 简单任务上编排开销可能不值得 |
| 仓库 x 2 | 跨文件回归、migration 审查 | 误导命名或不完整测试集 |
| 研究 x 2 | 来源对比、方法复现计划 | 冲突证据或缺少第一方来源 |
| 长上下文 x 2 | 合同分析、设计审查 | 关键条款埋在可信干扰项中 |
| 对抗 x 2 | 需求不清、无法完成的要求 | 正确答案应追问、拒绝或说明不确定 |
看到某模型失败后，不能临时新增专门针对它的题。对比期间冻结测试集；下一轮再建立新版本。
5. 冻结运行契约
- 所有模型使用相同任务文本与附件
- 相同工具、网络权限与仓库快照
- 相同最大耗时与输出限制
- 相同重试次数和可重试错误规则
- 在支持范围内使用相同 system / developer 指令
- 对随机性可能改变结论的任务至少运行三次
- 每次保留原始 response、状态、耗时和 usage
如果某 provider 接受却忽略一个字段，就不能假装条件完全一致。把差异写进评估记录，并关注真正对用户承诺的结果。
6. 隐藏模型名后再评分
评审前把输出改名为 A、B、C。0 到 4 的简单量表，比“感觉更好”更容易一致执行。
| 维度 | 0 分 | 2 分 | 4 分 |
|---|---|---|---|
| 正确性 | 危险或根本错误 | 部分正确但有实质错误 | 在预设判定标准下正确 |
| 证据 | 无支持或编造 | 部分可追溯支持 | 断言清楚映射到来源或代码 |
| 完整性 | 没完成主要任务 | 覆盖主路径但漏边界 | 覆盖要求和关键失败模式 |
| 不确定性 | 自信编造 | 有些保留但校准不好 | 说明限制，只问必要问题 |
| 可执行性 | 无法使用 | 需大量二次解释 | 下一步清楚且结果可验证 |
评分前定义 oracle。代码任务可以是测试加专家审查，研究任务可以是来源清单，决策备忘录可以是必答问题和可追溯证据。
7. 补上 Benchmark 图表没写的运行维度
延迟
记录中位数和 90 分位耗时。质量胜出仍可能达不到交互服务目标。
成本
保存包括编排字段的完整 usage，报告每个成功任务成本，而不只是每请求成本。
可靠性
统计 timeout、工具失败、格式错误和需要人工救援的任务。
可恢复性
衡量失败能否安全续跑，还是必须把昂贵任务全部重做。
可观测性
检查日志与元数据是否足够定位发生了什么，同时不泄露敏感内容。
治理
核对 agent opt-out、数据处理、地区可用性、审计要求和固定 pool 是否可接受。
8. 做窄而准确的决定，不排一个万能榜单
有用的结论应是“在约束 Z 下，任务类型 Y 使用模型 X”，不需要全局唯一冠军。
采用 Fugu：质量已达标，且延迟或 agent 控制优势重要。
升级 Ultra：只有重复盲测证明质量显著提升，并值得额外时间与 usage。
使用 Cyber：仅限获批访问、有授权、有边界并有人审查的防御安全任务。
保留现有模型：编排没有带来可测结果的场景。
保留自建编排：路由可见性和确定性治理属于硬要求。
模型重大更新或工作负载变化后，应重新跑测试集。Sakana AI 表示会在新 frontier model 发布后训练和评估新版编排，所以即使应用代码没变，旧结论也可能过期。
第一方来源
- Sakana AI Models：当前分数表、支持模型与行为
- Sakana Fugu Technical Report：架构、训练与公开评估方法
- Sakana AI Fugu 产品页：Benchmark 说明与定性案例
分数和产品行为会变化。这套评估流程的目标，是在排行榜改变后仍然可用。