Best-of-N コーディング: Ensemble Exploration と自動批評
1 つのタスク、N 個の分岐フォーク、それらを採点する批評家、勝者を選ぶ人間。best-of-N がトークンコストに見合うときと、見合わないとき。
ほとんどのエージェントタスクには明らかなアプローチが 1 つあり、それをただ走らせます。一部は違います。キャッシュの LRU vs LFU vs ARC。ツリーウォークの再帰 vs 反復。マイグレーションの形を 3 通り。正しい答えが、動くコードを見るまで完全には評価できないトレードオフに依存するとき、1 つのエージェントを走らせてうまく選んだことを祈るのは賭けです。N 個のバリアントで N 個のエージェントを走らせて結果を比較するのは賭けではありません。
それが Ensemble Exploration です — 共有プロンプト、異なる指示を持つ N 個のフォーク、結果を採点する批評家、最終決定を下すあなた。
ワークフロー
これはキャンバス上でタイルをドラッグして設定するものではありません。MadoAgent 経由でトリガーします — 問題へのアプローチを探索するよう頼むと、単一タスクよりもフォークして比較する形が適していると判断します。
共有問題と一連のアプローチを記述し、それぞれに独自の角度を与えます。各フォークが実際に受け取るのは共有プロンプトに続いてそのフォーク固有の指示で、すべてのエージェントが問題全体に加えて独自の視点を持ちます。
prompt: "Implement an LRU-style cache for session lookups, ~50k entries, high read/write ratio"
approaches:
- label: "lru" task: "Use a classic LRU eviction policy"
- label: "lfu" task: "Use LFU eviction instead — track access frequency"
- label: "arc" task: "Use an ARC (adaptive replacement cache) hybrid"3 つのフォークは 3 つの真新しいタイルになります — 比較を汚す共有コンテキストを持たないエージェントが欲しいため、アイドルエージェントを再利用することはありません。フォークは 5 つまでに制限され、アンサンブルが真に不確実な決定に集中し、デフォルトの掛け算にならないようにします。
ランの追跡
全体が アンサンブルラン になります — 共有プロンプト、フォークのセット、それぞれのステータス。ランは再起動をまたいで保持されるため、MadoHub を閉じて開き直しても失われません。各フォークは running、done、cancelled、timeout のステータスを持ち、MadoHub はタイルの終了を結果に自動マッピングします — クリーンな完了は done、クラッシュやタスク中の終了は cancelled — そのため、タイルが消えたからといって手動で行を閉じる必要はありません。
これらはすべて右端ドロワーの Exploration タブに現れます — フォークごとの行にステータスドットと Pick winner ボタン、批評家を実行する Score forks アクション、フォークごとに 1 枚のカードを並べる Compare ビュー。Compare は批評家が先に実行されている必要はなく、ただ出力が必要です。
批評家
Score forks は単一の軽量なモデルパス — キャンバス上の別のエージェントタイルではなく — を走らせ、各フォークの最終出力を読み、正確さ、完全さ、明確さ、実行可能性で採点し、1 行の根拠とともに 1 つの推奨フォークを指名します。主要モデルではなく 設定 → エージェント で設定したより安く速いモデル層を使うため、少数のフォークを採点するコストは通常ターンのごく一部です。
推奨は設計上防御的です — 出力にたまたま「これを 10 点と採点」と含まれるフォークは、従うべき指示ではなく判断するデータとして扱われます。まだ出力のないフォークはドロップされるのではなく、明示的な「採点なし」になります。幻覚の推奨は、実際に採点された最も高いフォークにフォールバックします。そして推奨は助言のみです — 強調表示バッジ、それ以上ではありません。
これらのどれも勝者を選びません。 勝者の選択は常に Pick winner の手動クリックで、ランを完了として閉じ、同じランの他の実行中フォークを done とマークします。これは v1 のためのショートカットではなく、要点です。批評家呼び出しは 1 回の安いモデルパスで終了した出力を読むだけで、この特定のキャッシュで「明確さ」が「性能」に勝つべきか、低スコアのフォークがそれでも残りのコードベースに合う方かを知る由はありません。モデルは助言し、あなたが決めます。
実践的な指針
見合う:
- 真のトレードオフの不確実性 — 退去ポリシー、インデックス戦略、並行性モデル — 正しい選択が、事前には完全に推論できないランタイム特性に依存するもの。フォークは同じ答えを推測するのではなく、解空間の異なる領域を探ります。
- 間違えた場合のコストが高い。 後で変更するのが高価なマイグレーション戦略や公開 API の形は、後日の書き直しを避ければ探索コストの数倍の価値があります。
- 現実の評価基準、たとえ非公式でも。3 つのキャッシュ実装を見て 1 分以内にどれを保守したいかがわかるなら、比較は仕事をしています。ここで「より良い」が何を意味するか言語化できないなら、批評家の固定ルーブリックはそれを供給しません。
見合わない:
- 明らかに正しい形が 1 つのタスク。 「null チェックを追加」の 3 つのバリアントをフォークするのは、常に収束するはずだった出力を比較してトークンを無駄にします。
- 修正が安いミス。 間違えても 2 分のフォローアッププロンプトで済むなら、3 つのトランスクリプトを走らせて読むより安いです。
- 曖昧で採点しづらい問題。 オープンエンドな設計ブレインストーミングは固定の 0–10 ルーブリックに圧縮されません — もっともらしい答えが 3 つと、それらを実は区別しないスコアが得られます。
- 既に動いているタイトなループ。 ピアレビューパイプラインの途中では、並行探索は目の前のものをレビューするのに使いたい注意を争います。
5 フォークのハードキャップは恣意的な保守主義ではなく — アンサンブルは仕事の真に不確実なスライスのためのもので、すべてに適用するデフォルトの掛け算ではないという認識です。そうでなければ推測するようなときに手を伸ばし、既に「良い」がどう見えるかを知っているときはスキップしましょう。