ベンチマーク — 弱いモデルの底上げを証明する

Chimeraのテーゼは、構造が弱くて安いモデルを底上げするというものです。それを示す正直な方法は、標準ベンチマーク上での統制されたA/Bです: タスクのサブセットとモデルを固定し、唯一の変数をスキャフォールディング(足場)にし、デルタを信頼区間とともに報告する — 「良くなった」という裸の主張ではなく。(独立した研究によれば、同じモデルでもスキャフォールディングだけで約7ポイント揺れることが分かっており、修飾のないスコアはあなたの貢献について何も語りません。)

実験

ベンチマーク: Terminal-Bench 2.0 — Dockerタスク+指示+検証テストで構成され、それらのテストによってpass/failで採点され、エージェント非依存の Harbor ハーネスによって駆動されます。

アームA(ベースライン): Harborの中立的なスキャフォールド内の1つの無料モデル — 「弱いモデル単体」。
アームB(処置群): 同じモデル、同じタスクID、Chimeraによって駆動。
メトリック: pass@1。見出し: Δ = rate(B) − rate(A)、95%信頼区間付き。
正直さのガード: タスクIDのサブセットを固定し(公開する)、3シード以上を実行し、すべてのトランスクリプトを公開し、フロンティアモデルの行は天井の参考値としてのみ追加する — 決して比較対象としてではない。

結果 —— そしてそれは私たちに不利でした

このページは、テーゼを証明するであろう数字を挙げて節を締めくくっていました。「無料モデル単体 = X%、無料モデル + Chimera = Y%、Y ≫ X」。その実験はすでに実施され、Y は X を下回りました。両方の腕で同じモデルを使った事前登録済みの N=40 のスライスで（deepseek-chat-v3.1）：7.5% → 2.5%、 対応のある Δ −5.0 ポイント、95% CI [−5.0%, +1.6%] —— 有意ではない。スキャフォールドは、すでに有能なモデルを押し上げませんでした。両腕とも分散に支配された床にあります。実行前に書かれた事前登録を含む完全な報告：bench/terminal_bench/RESULTS.md。

Y ≫ X を約束した一文は、それを反証した実行より長く生き延びました —— このページと 9 つの翻訳で。黙って削除するのではなくここに記録します。唯一の本当の資産が誠実な計測である企画は、自らの結果と反対のことを予告するページを抱えていられないからです。

実行方法

uv sync --extra bench            # installs terminal-bench (Harbor); also needs Docker
playwright install chromium      # only if a task needs the browser tool

Chimeraは chimera/eval/terminal_bench.py を通じて処置群エージェントとして組み込まれます(make_chimera_tb_agent(model) は、スキャフォールディングフラグ付きで chimera solve を実行するHarborの BaseAgent を構築します)。Harborを固定サブセットと各アームの無料モデルに向けてください。正確な harbor run の呼び出しと --agent-import-path については、Harborのドキュメントを参照してください。

SWE-bench Verified(2つ目のスコアボード) — 4回実行

Terminal-BenchはCLIタスクでテーゼを証明し、SWE-benchは実際のGitHubのバグ修正でそれを証明します — ベースコミット時点のリポジトリとIssueが与えられ、エージェントはインスタンスの FAIL_TO_PASS テストを通過させつつ PASS_TO_PASS を緑のまま保つパッチを生成しなければなりません。「Verified」は人間が検証したサブセットです。

結果

django/django のスライス上での4回の事前登録された実行、deepseek-chat-v3.1、pass@1、Docker内の公式 swebench 4.1.0ハーネスのみによって採点。全文: bench/swe_bench/RESULTS.md。

実行	スライス	ベースライン	+ Chimera	対応差Δ	95%信頼区間
1 (`max_steps=8`)	19	36.8% (7/19)	36.8% (7/19)	+0.0%	[−8.5%, +8.5%]	有意でない
2 (`max_steps=30`)	同じ19	42.1% (8/19)	57.9% (11/19)	+15.8%	[−1.9%, +15.8%]	有意でない
3(再現)	未見の41	34.1% (14/41)	43.9% (18/41)	+9.8%	[−3.5%, +16.7%]	有意でない
プール(副次)	60	36.7% (22/60)	48.3% (29/60)	+11.7%	[+0.8%, +16.4%]	有意でない（正確 McNemar p = 0.065）
4(寄与分解)	実行3の41	34.1%	スキャフォールドのみ 39.0%	+4.9%	[−7.6%, +14.2%]	有意でない

監査済み、再採点はまだ（研究30、S30-35）。 実行3と4で解決されたパッチのうち5件はテストファイルも編集している。5件の編集はいずれも、ハーネスが採点前に元に戻すファイルに対するもので、5件すべてを失敗として数えても符号は反転せず、有意性も取り消されない（監査）。この改善はより強いテストではまだ読まれていない（開発者のフルテストスイート、SWE-ABS）。それらの採点は推定ではなく、未実施の宿題である。

実行1は厳密なゼロであり、そのまま変更なく公開されています。実行2はこちら側の不備を2つ修正しました — スキャフォールドが最も強力な仕組みなしで動作していたことと、8ステップのツール呼び出しでは250MBのリポジトリをナビゲートするのに不十分だったことです — その結果、3インスタンス勝利、0敗となりました。

情報を持つ 3 ペアでの 3–0 は、幸運な標本がちょうど作る形であり、事前登録はそれが単なる偶然である確率を3 分の 1 と見積もっていました。そこで実行 3 は、結果を一度も見たことのない 41 インスタンスで、他は何も変えずに繰り返しました：同じアーム、同じモデル、同じステップ予算、同じタイムアウト。効果は再び現れました：+9.8%、登録した +5〜+20 の帯の内側で、しかも実行 2 より難しいスライス（ベースライン 34.1% 対 42.1%）で。続く実行 4 は同じ 41 でスキャフォールドと diff-gate を分離し、それぞれ +4.9%。機構は精度で、パッチ率が動かないまま 50% → 59% → 67% と上がります。

⚠️ いずれもSWE-bench Verifiedのスコアではありません。 これらのスライスは測定に余地を持たせるため意図的に易しく単一リポジトリに限定されています。実際のVerifiedスコアには完全な500件が必要です。個々の実行はどれも有意ではありません。プールした n=60 は有意ですが、見たデータと見ていないデータを混ぜるからこそ副次的として事前登録されており、効果を裏づけるものであって、その大きさを測るものではありません。

私たち自身の予測は、主張したのと同じくらい目立つ形で、途中で2つ撤回されました: 実行1の空のパッチについて追跡していたメカニズム(修正はステップ予算であって、当初非難したdiff-gateではありませんでした)と、実行4が否定した実行2の読み取りです。

実行2はまた撤回も伴います: 実行1の空のパッチについて追跡していたメカニズムは誤りでした(修正はステップ予算であって、当初非難したdiff-gateではありませんでした)。これは、主張されたのと同じくらい目立つ形で訂正されています。

アダプター

アダプター(chimera.eval.swe_bench)はその境界について正直です: 純粋な部分 — インスタンスごとの chimera solve の呼び出し(処置群アーム)と公式評価レポートのパース — はここに存在し、ユニットテストされています。データセットとDocker評価ハーネスはオプトインでバンドルされておらず、pass/failの判定はSWE-bench自身のテストから得られ、自己申告は決してありません。

# 1. Curate a JSONL slice (one instance object per line): instance_id, repo, base_commit,
#    problem_statement, and (optionally) test_cmd. build_solve_command turns each into a
#    `chimera solve <issue> --verify <test_cmd> --repo-map --progress-ledger --replan --checklist`.
# 2. Run both arms through the official SWE-bench harness (model-only vs model+Chimera) on the
#    SAME instance ids, producing two evaluation reports.
# 3. Score the honest A/B:
chimera swe-bench-compare model_only_report.json chimera_report.json --instances mini.jsonl

両方のレポートは共有インスタンスリストに射影されます(欠落したidは未解決としてカウントされます)。そのため、両アームは常に同一のインスタンス上で比較され、同じNewcombe信頼区間の判定が適用されます。

A/Bの採点(ベンチマーク不要)

各アームがタスクごとのpass/failを生成した後、統計処理は1コマンドで済みます — これには追加パッケージが不要なので、正直な報告エンジンは常に利用可能です。

chimera bench-compare baseline.json chimera.json --treatment-name chimera

各ファイルは同じタスクID群にわたるブール値のJSONリスト(または {task_id: bool})です。出力: 各アームのWilson区間による合格率、デルタ、そのNewcombe 95%信頼区間、そしてその差が有意かどうか(信頼区間がゼロを含まない)。有意でない場合、それはそのまま報告されます — より大きなサブセット/より多くのシードが必要か、その機能が本当に数字を動かさないかのどちらかです。

この同じ bench-compare が、以降のすべての機能の物差しです: M14の各追加は、同一のサブセット上でΔを動かすことを示さなければならず、示せなければ削除されます。

正直さの罠(避けるべきこと)

汚染 — 公開されているSWE-benchには解答の漏洩が文書化されています。汚染耐性のあるセットを優先し、その注意点を報告してください。
スキャフォールドの交絡 — 生の「X%のスコアを出した」を決して報告しないでください。A/Bのデルタだけが Chimeraの貢献を切り分けます。
誤ったベースライン/チェリーピッキング — 弱いモデル+Chimeraを、同じ弱いモデル単体と、同一のタスクID上で、シードと完全なログとともに比較してください。フロンティアモデルは天井であって、対抗馬ではありません。

GitHub でこのページを編集