Memdoor team-solve: 5つのQwen3.8-27BエージェントがLiveCodeBench HardでFable 5に匹敵
Memdoorのteam-solveワークフローは、GVS5Hのマルチエージェント手法をQwen3.8-27B上で再現し、LiveCodeBench Hardの最初の10問を5回実行した平均で10点中9.8点を記録しました。これは、原作者のハーネスの9.6点、Fable 5単独の8.0点と比較されます。この結果が重要なのは、規律あるマルチエージェント・ハーネスに包まれた小さなオープンウェイトモデルが、難しいコーディングベンチマークでフロンティアモデルに匹敵することを示しているからです。しかも、1回の実行あたり約0.39ドル、モデル時間の中央値40分で達成されています。
このワークフローはmemdoorリポジトリの公開サンプルであり、Hacker Newsで発表され、385ポイントと188コメントを集めました。議論は、ローカルモデルの同等性への熱意と、10問というサンプルの少なさへの懐疑に分かれました。
team-solveの実態
team-solveは、プログラミング問題のためのマルチエージェント・ハーネスで、Memdoorワークフローとして書かれています。プランナー、2人のアイデア出し、ソルバー、マネージャーの5つの役割に加えて修復ワーカーが、それぞれ新しいコンテキストから始まり、ディスク上のファイルを通じてのみ通信します。実行が成功したかどうかを判断するのはモデルではなくシェルスクリプトです。
この手法はGVS5H（Lee, 2026）に由来します。この論文では、5つのQwen3.8-27BモデルがLiveCodeBench HardでFable 5に匹敵すると報告されています。Memdoorの貢献は、そのループを独自のワークフローエンジン内で再実装し、著者とまったく同じプロンプトを使用したことです。
ワークフローファイルは、2026年10月25日に、コーダー自身が手法の説明から生成したもので、誰も手書きしていません。
ベンチマーク数値
MemdoorはGVS5Hのハーネスを、同じモデル（Qwen3.8-27B、128K応答上限、著者のプロンプトとループ）でMemdoorワークフローとして再構築し、彼らのLiveCodeBench Hardリストの最初の10問を5回実行しました。すべてのプログラムは、著者の修正済みグレーダーで、すべての公開テストと非公開テストで採点されました。
| パス | Memdoorワークフロー | 著者の27Bハーネス | Fable 5単独 |
|---|---|---|---|
| 1 | 10 / 10 | 9 | 7 |
| 2 | 10 / 10 | 10 | 8 |
| 3 | 10 / 10 | 10 | 10 |
| 4 | 10 / 10 | 9 | 8 |
| 5 | 9 / 10 | 10 | 7 |
| 平均 | 9.8 | 9.6 | 8.0 |
著者の列は、彼らのリポジトリの再採点結果ファイル（q38_multiagent_pN、fable5_single_pN）からのもので、論文の数値と一致しています。全50回の実行はbench/results/parity-5pass/に公開されており、すべてのリクエストと応答、生成されたプログラム、グレーダーの完全な出力、各呼び出しのコストとサービングホスト、およびカウントされなかったすべての試行が含まれています。
50回の実行のうち49回が問題を解決しました。カウントされた50回の実行のコストは35.79ドル（1530万出力トークン）でした。時計で打ち切られた16回の試行、修正のために停止された試行、一時停止された試行を含めると、合計は38.77ドルでした。実行のモデル時間の中央値は40分で、最長は4時間、コストは約0.39ドルでした。
元のハーネスと同一の点、異なる点
Memdoorのパリティテストlib/test_parity.pyは、著者のmultiagent_solveとMemdoorワークフローを、スクリプト化された1つのモデルに対して実行し、各リクエストを比較します。4つのケースはバイト単位で同一であり、1文字の変更で違いが生じます。
一致する設定は、温度（プラン0.3、アイデア出し0.4、マネージャーとワーカー0.2）、top_p 0.95、top_k 20（著者のvLLMがモデル自身の設定から適用したもの）、128K応答上限、最大10ラウンド、打ち切られたワーカーの要約、テキストなしの応答に対する推論による応答です。
主な違いはホストです。著者は独自のvLLMをFP8で実行しました。MemdoorはOpenRouter上で実行し、Modal、CoreWeave、Parasail、Waferの順にホストを要求し、Modalが14トークン/秒に遅くなるまで続け、その後FP8ホスト（Wafer、Parasail、CoreWeave）に制限しました。呼び出しのうち203件はModal、27件はCoreWeave、115件はWaferが処理し、FP8のみの順序ではすべての呼び出しがWaferに送られました。3回の実行は、完了したステップを保持したまま途中で移動され、log/host-switch.txtに記録されています。
問題文が難しい部分だった
Memdoorの最初のバージョンは、各問題の周りに独自のタスクファイルを作成しましたが、27Bモデルは、著者の正確なLiveCodeBenchテキストからよりも、そのタスクファイルから計画を立てるのが下手でした。問題arc196_cでは、書き換えたタスクテキストでは計画が2回中0回成功したのに対し、元のテキストでは2回中2回成功しました。
ワークフローが著者のハーネスとまったく同じ質問をするためには、Memdoorに4つの変更が必要でした。
- タスクがテキストを生成しなかった場合、モデルの推論で応答する。
top_pとtop_kをモデル行に設定できる。mark_cutoffが上限で打ち切られた応答を処理する。- 呼び出しが独自の4時間の時計で実行できる。
ワークフローが失った点
両方の失敗は、モデルではなく、著者のループの同じ2つのギャップに起因しています。
- パス5、
abc399_e（44の非公開テストのうち32）: ラウンド1のプログラムは正しかった。マネージャーが誤った期待値を持つ反例を発明し、チームはプログラムを書き直し、新しいバージョンは公開サンプルを通過しましたが、そのサンプルはそのケースをカバーしていません。 - パス4、
arc196_cとarc196_d: すべての非公開テストに合格したプログラムが、マネージャーが作業完了を宣言しなかったため、後のラウンドで上書きされました。両方ともループが終了する前に正しいプログラムを回復しました（arc196_dはラウンド8、arc196_cは最終呼び出し）が、それぞれ3.44ドルと4.24ドルで、最も高価な2回の実行となりました。
Memdoorは、両方ともメソッドを変更せずに修正可能であると指摘しています：マネージャーの反例を小さな入力でのブルートフォースと照合し、サンプルに合格した最後のプログラムを保持することです。どちらの修正も報告された数値には含まれていません。
ワークフローの構造
ステップグラフは、Memdoorの基盤となるエンジンmarioの形式を使用したsteps/内のYAMLファイルのDAGです。
plan ──┬── ideate-a ──┬── solve ── test ── review ── repair ── verify
└── ideate-b ──┘
| ステップ | 種類 | 読み取り | 書き込み |
|---|---|---|---|
plan |
エージェント | task.md |
plan.md、およびアイデア出しごとに1つのアンカーを持つnotes.md台帳 |
ideate-a、ideate-b |
エージェント、並列 | task.md、plan.md、notes.md |
独自のアンカーに提案：Aは最も直接的な証明可能なアルゴリズム、Bは異なる技術ファミリーからのもの |
solve |
エージェント | 両方の提案 | notes.mdの決定、solution.py |
test |
コマンド | tests/ |
test-output.log、test-status.txt（実行を失敗させることはない） |
review |
エージェント | キャプチャされたテスト出力（モデルの主張ではない） | review.md、notes.mdの修復指示 |
repair |
エージェント | マネージャーの指示 | 修正されたsolution.py、またはサンプルが合格した場合は何もなし |
verify |
コマンド | tests/ |
final-test-output.log；非ゼロ終了は実行を失敗させる |
すべてのエージェントプロンプトは、モデルに新しいコンテキストから始め、ファイルを読み、チャット履歴に依存しないように指示します。論文は、その台帳の規律が改善の原因であるとしています。修復ラウンドは1回で、人間のゲートはありません。最終的なverifyステップがすべての判定です：check-samples.shを実行し、final-test-output.logを書き込み、サンプルが1つでも失敗すると非ゼロで終了します。
実行方法
curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter # または anthropic、openai、gemini、chatgpt
# またはキーなし：memdoor connect local # このマシンのOllama、llama.cpp、vLLM、LM Studio
git clone --depth 1 https://github.com/guregodevo/memdoor
mkdir -p ~/.memdoor/workflows
cp -r memdoor/examples/workflows/team-solve ~/.memdoor/workflows/ # ライブラリ：任意のプロジェクトが参照可能
mkdir my-problem && cd my-problem
cp -r ../memdoor/examples/workflows/team-solve/sample/* . # task.md + tests/1.in … 5.out
memdoor workflow run team-solve --wait # 進行状況はstderrに、すべてのサンプルが合格するとexit 0
memdoor tuiの/workflowは同じ実行をライブで描画します。カスタム問題の場合は、task.mdを置き換え、ペアのtests/N.inとtests/N.outファイルを追加します。プログラムはsolution.pyで、stdinから読み取られ、diffでサンプルと比較されます。Python 3とbashが必要です。ワークフローを単一のリポジトリ内に保持するには、フォルダをそのプロジェクトの.memdoor/workflows/にコピーします。プロジェクトのコピーが優先されます。
ステップはモデルを指定しません。/modelに固定されているものが呼び出しに応答します。memdoor connect localで接続されたローカルランタイムも含みます。
最初の実行でわかったこと
同梱のサンプルは、アルファベット{a, b, c}上の部分文字列で、各文字の数が等しいものを数える問題で、文字列は最大200,000文字です。OpenRouter経由のデフォルトのラダーでは：
- 8ステップ中8ステップ、5サンプル中5サンプルが合格しました。ソルバーはアイデア出しAのプレフィックス状態法を選択しました：O(N)で(a−b, a−c)ペアの辞書を使用。その後、300のランダム文字列に対するブルートフォースで不一致は見つからず、プログラムはN = 200,000で0.04秒で実行されます。マネージャーは修復すべきものを見つけませんでした。
- 1つのアイデア出しのプロバイダーが応答の途中でストリームを切断しました。コーダーは
max_retries: 0と書いていたため、実行はそこで終了しました。エージェントステップにはmax_retries: 1が付与され、実行は--partitionで再開され、プランナーと他のアイデア出しの作業が保持されました。 - アイデア出しプロンプトは元々サンプルの特定のメソッド（A：ストリーミングプレフィックス状態カウント、B：プレフィックス状態のソート）を指定していましたが、これは他の問題を誤った方向に導く可能性があります。現在は、Aには最も直接的な証明可能なアルゴリズム、Bには異なる技術ファミリーからのものを求めています（2026-10-28）。
- 最初の試行は、「coderという名前のエージェントがいない」という理由で、すべてのステップが0秒で失敗しました。これは、実行が自分のワークスペース内でのみエージェントを検索したためです。これは同日、ゲートウェイのv1.692.0で修正されました。
著者が明確に述べている注意点
この結果は、著者の100問ではなく、10問を5回実行したものです。コンテストは2025年3月29日から4月6日までで、モデルがトレーニング中にそれらを見た可能性があり、汚染を排除できません。Fable 5の列は、著者の結果ファイルからの問題ごとの単一呼び出しであり、このハーネス内で実行されたものではありません。ループは公開サンプルのみを見ますが、スコアは非公開テストで測定されます。
Hacker Newsの議論が追加したもの
サンプルサイズへの懐疑
最も一般的な反対意見は、10問では強い主張を支えられないというものでした。@zihotkiは書きました：
このベンチマークは「彼らのLiveCodeBench Hardリストの最初の10問」しかないので、結論を出す前にさらに多くのベンチマークを待つべきです。そしてLiveCodeBench Hardは数年前のベンチマークです。非常に飽和している可能性があります
同じ問題に数週間費やしたと報告した@jbellisは、一般化リスクを直接的に述べました：
私の見解：単一の評価を改善するハーネスを構築するのは非常に簡単で、一般化するハーネスを構築するのは非常に困難です。
@0xbadcafebeeは計算トレードオフの議論をしました：結果は、多くのリクエストと大きなトークン予算を持つ小さなモデルが、1つのリクエストと小さなトークン予算を持つ大きなモデルを打ち負かすというもので、それ自体は驚くべきことではありません。
チーム構造が機能する理由
@topspinは、興味深い変数はモデルではなくハーネスであると主張しました：
私の推測では、分業が個別のコンテキストをより効果的にしていると思います。これはコンテキストの限界に対する最適化です。その一部は単純にコンテキストの正味量です：各チームメンバーがコンテキストを持つので、正味のコンテキスト量はチームメンバーの数だけ乗算されます。
@yurimoは、メカニズムを解の盆地の探索として説明しました：複数のモデルと異なる意見が、単一のモデルが十分に強くない場合でも、システムをより良い答えに押しやることができます。
@CharlieDigitalは、この設計をエモリー大学のマルチエージェント進化に関する論文と結び付け、役割の分離により、ノイズの多い思考トークンとツール呼び出しが下流のエージェントのコンテキストから除外され、後続の各エージェントがより小さく焦点を絞った入力を受け取ると主張しました。
@robertkluinは、同様のファイルベースのアーキテクチャを本番環境で実行していると報告しました（プランナー、リサーチャー、実装者、レビューアー、実装者はヘルパーを生成可能）が、フロンティアモデルを使用している同僚は出力の違いを見分けられなかったと述べました。
@mchusmaは、より安価なモデルが強力なモデルが生成した計画とコードをレビューする混合モデルレビューループを説明し、小さなモデルが何かをキャッチすることがどれほど多いかに言及しました。
ローカルモデルの重要性
いくつかのコメントは、同等性が所有ハードウェアでモデルを実行することに何を意味するかに焦点を当てました。@roenxiは、Bonsai 2量子化を使用すると、Qwen 27Bは手頃な価格のゲーミングマシンで約50トークン/秒で実行でき、Steamハードウェア調査の16GB VRAMと32GBシステムメモリの数値を引用しました。
@novaRomは完全にローカルモデルに切り替えたと報告し、27Bモデルは64GB RAMの最新のPCまたはラップトップで提供でき、主な欠点は256Kコンテキスト制限による定期的なコンパクションであると述べました。
@fedpostは、この作業をプロバイダー支配へのヘッジとして位置付けました：
ローカルモデルをハイパースケーラーと競争力のある状態に保つことが緊急に必要です。彼らとその気まぐれに永遠に縛られたくありません。
@cloudkingはベンチマーク中心の熱意に反対し、ローカルモデルで実際のユーザーを持つ質の高い本番アプリやゲームを構築した人がいるかどうか尋ねました。
書き方自体への反対
@vessenesは、作業日誌形式は読みにくいとし、短い人間が書いた要約を求めました。@StilesCrisisは、テキストがモデル生成の散文のように読めると主張しました。両方の批判は、公開された実行アーティファクトではなくプレゼンテーションを対象としています。
明らかなフォローアップ質問
複数のコメントが自然なコントロールを尋ねました：5つの小さなモデルが1つの大きなモデルを打ち負かすなら、5つの大きなモデルは何をするでしょうか？@conceptionは「5つのfableモデルのチームはすべてのベンチマークを粉砕するはずだ」と述べ、@ameliusはFable 5がすでにスウォームではないことを誰が知っているのかと尋ねました。公開された実験はどちらの質問にも答えていません。Fable 5は問題ごとに単一の呼び出しとしてのみ実行されたからです。
まとめ
Memdoorのteam-solveワークフローは、5つのQwen3.8-27Bエージェントと修復ワーカーをファイルベースのハンドオフで実行し、LiveCodeBench Hardの最初の10問を5回実行した平均で9.8/10を記録しました。これは、元のGVS5Hハーネスの9.6、Fable 5単独の8.0と比較されます。
Sources
関連
- Dispatch
- Dispatch
- プロジェクト
- Dispatch