Fable 5 vs. GPT-5.6 Sol: NP困難問題における/goalモードの効果

ブログの要約: ClaudeにFable 5とGPT-5.6 Solに、ネイティブな/goalモードありとなしの両方で、未公開のNP困難な最適化問題を与えました。Fable 5は絶対的な強さを見せ、/goalモードはゲームチェンジャーではありませんでした。 背景: これは元々ハッカソンの学生に提出されたオペレーションズリサーチの問題です。私は数年前にこれを解決するためにC++を書いて費やしましたが、有用な人間のベースラインを持っています。 Fable 5はこのベンチマークで絶対的な強さを見せました。全体として最高のソリューションを生成し、その一貫性は、この問題に対するモデルから見たことのないものでした。これは純粋な生の知性です。信じられないほどです。 もう一つの結果は、/goalが汎用的な「もっと頑張る」スイッチではないということです。それは制御ループと探索パスを変更します。時にはそれがより良い盆地を見つけることがあります。時には、悪いアイデアが成熟するのに時間がかかります。 すべてのコード、プロンプト、結果テーブル、除外事項、および軌跡のメモはCLIArenaにあります。これは、このベンチマークに関する私の最初の記事のフォローアップです。 KIRO問題は、私が2018年に工学部の学生として取り組んだファイバーネットワーク設計問題です。グルノーブル、ニース、パリの有向距離行列が与えられ、ソルバーはいくつかの構造的制約を尊重しながら、ループと短いチェーンを使用して配電ポイントと端末を接続する必要があります。目的は総ケーブル長です。低いほど良いです。 有効なネットワークは、配電ハブにルートされた冗長なループで構成され、それらのループからタワーにぶら下がる短い分岐があります。各タワーは正確に一度だけ出現する必要があり、ケーブルセグメントを反転させるとそのコストが変わる可能性があります。 探索空間の大きさはどのくらいですか？ソリューションは任意の数のループ、可変ループサイズ、および異なるアンカーと順序付けされた分岐を使用できるため、単一の閉形式のカウントはありません。しかし、パリだけでも有用な下限が得られます。 順序と分岐を無視し、532の端末すべてを11の配電ハブのいずれかに割り当てるだけでも、11^532通りの可能な割り当てがあります。 19個のループ（各28個の端末）のみを使用し、分岐なしという、意図的に制限された有効なソリューションのファミリから、より強い下限が得られます。これは19 x 28 = 532であるため、すべての532の端末をカバーしますが、ループの30端末制限を下回っています。 532の端末を順序付けし、その順序を19個の連続したグループに分割し、19!で割ります（ループのセットは順序付けされていないため）、そして各ループに11のハブのいずれかを選択します：(532! / 19!) x 11^19 ~= 10^1223 テストしたこと 主な実験は意図的に狭く設定されました。 設定 値 モデル Claude Fable 5、Opus 4.8、Sonnet 5; GPT-5.6 Sol、Terra、Luna モード Plain; ネイティブ /goal 最適化予算 30分 外部エージェントタイムアウト 1,900秒 推論 各モデルの利用可能な最大設定 実行 Harbor 0.1.43、Docker、サブスクリプション認証 結果 フラッグシップペアに反復処理を集中させる前に、スイープ内のすべてのモデルに対して、ヒントなしのペアを30分間1組実行しました。FableとSolの場合、チャートは複製されたヘッドラインセットのペア1を使用します。他の4つのモデルはそれぞれ1組のペアを持っています。 その後、Fable 5とSolの3組のマッチした実行が得られるまで、フラッグシップの比較を繰り返しました。 モデル | ラン | Plain | /goal | Goal minus plain ------- | -------- | -------- | -------- | -------- Fable 5 | 1 | 32,197 | 31,934 | -263 Fable 5 | 2 | 32,516 | 32,324 | -192 Fable 5 | 3 | 32,446 | 35,178 | +2,732 GPT-5.6 Sol | 1 | 33,581 | 39,371 | +5,790 GPT-5.6 Sol | 2 | 35,539 | 32,703 | -2,836 GPT-5.6 Sol | 3 | 33,663 | 33,313 | -350 マイナスは/goalの方が良かったことを意味します。 Goalは6回の試行中4回勝ちました。したがって、勝率だけでもこの機能は有用に見えます。 平均値はもう半分を伝えます。 モデル | Plain mean | /goal mean | Mean effect | Median effect ------- | -------- | -------- | -------- | -------- Fable 5 | 32,386 | 33,145 | +759 worse | -192 better GPT-5.6 Sol | 34,261 | 35,129 | +868 worse | -350 better 両方のモデルは通常、わずかな利益を得て、時折大きな後退を経験しました。それが/goalがほとんどの実行で勝ちながら、両方の平均を悪化させた理由です。 Fableも明らかに強力でした。そのPlain meanはSolの平均を1,875ポイント上回り、Goal meanはSolの平均を1,984ポイント上回りました。さらに重要なのは、Fable Plainはわずか319ポイントの範囲内に留まったのに対し、Sol Plainは1,958ポイントにまたがったことです。 Fable goalは最高のクリーンなスコアである31,934を生成しました。Fable plainは最も安全な構成でした。 goalコマンドの詳細 同じコマンドが2つの異なるシステムを隠しています。 Claude Code: 別個の評価者 Claude Codeは/goalをセッションスコープのStopフックとして実装しています。各メインモデルのターン後、小さな評価モデル（デフォルトではHaiku）が条件と会話を読み取ります。理由とともに「はい」または「いいえ」を返します。「いいえ」は別のターンを開始し、「はい」はゴールをクリアします。 評価者はツールを使用したりファイルを検査したりできません。トランスクリプトに表示された証拠を判断することしかできません。それは早期終了を捉えることができますが、さらに1000万回のソルバーイテレーションが価値があるかどうかを知ることはできません。 Anthropicのgoalドキュメント claude codeはオープンソースではないため、Anthropicが私たちに伝えることのみに依存していることに注意してください。 Codex: 持続状態とライフサイクルツール ベンチマークされたリリースであるCodex CLI 0.144.4のソースも読みました。 Codexはゴールを持続的なスレッド状態として扱います。TUIはアクティブなスレッドの目的を保存し、SQLiteはそのステータスと予算会計を保存します。 TUI、スキーマ ワーキングモデルはcreate_goal、get_goal、update_goalツールを受け取ります。 ツール仕様 ゴールがアクティブな間にスレッドがアイドル状態になると、Codexは目的と完了監査を含む継続ターンを挿入します。 ランタイム、プロンプト Claudeは完了を別のモデルに委任します。 Codexはワーキングモデルに完了を宣言させ、その後、持続的なゴールがアクティブなままで再開します。 Claudeの評価者は独立していますが、トランスクリプトしか見ません。Codexはファイルとツールを見ますが、効果的に自身の作業を評価します。 /goalがほとんどの実行で勝ちながら、悪いデフォルトになる理由 通常のコーディングタスクでは、進捗はしばしば読み取り可能です。別のターンでテストを修正したり、移行を完了したりできます。最適化は異なります。 エージェントがソルバーを選択すると、追加時間は良い決定または悪い決定のいずれかを増幅できます。それがここで起こったことです。 Goalは、Fableの高速コンパイルされたポートフォリオまたはSolの成功したチェーン再分割を維持するのに役立ちました。Fableが遅いソルバーを構築したり、Solが網羅的なアンカースイープにコミットしたりすると、それは損害を与えました。 中央値はわずかに正しい方向に移動しました。悪いテールははるかに悪い方向に移動しました。 制限事項 これは1つの未公開のNP困難タスクであり、一般的なコーディングリーダーボードではありません。FableとSolのみが3組のクリーンなマッチしたペアを持っています。他の比較は、プロンプト、ラッパーバージョン、および時間制限を混在させており、トライアルはサブスクリプションサービスを通じて順番に実行されたため、ドリフトした可能性があります。 コンテナは、タスクメタデータが1つを宣言しているにもかかわらず8つのCPUを公開しており、これはFableの並列ポートフォリオに有利でした。 スコアリングされたFableとSolのすべての出力は有効でした。これは、ラッパーが早期チェックポイントと最終検証を要求したためです。 ベンチマークは、モデル、CLI、プロンプト、サブスクリプションサービス、およびハーネスを含む完全なシステムを測定します。 再現方法 ベンチマークタスク、ラッパー、分析スクリプト、図生成ツール、および完全な証拠メモはCLIArenaにあります。 生のジョブディレクトリはサイズのためGitから除外されていますが、メモには公開可能なすべてのスコア、都市内訳、経過時間、戦略、除外事項、および実行IDが記録されています。 主なコマンドは次のとおりです。 RUN_ID=article-kiro-YYYYMMDD-clean \ PHASE=nohint-all \ ./scripts/run_subscription_article_matrix.sh uv run python scripts/summarize_subscription_article_results.py RUN_ID... uv run python scripts/analyze_subscription_article_results.py RUN_ID... ヘッドラインに載せるべき結果は、goalが助けるか害するかではありません。それは、永続化機能が個々の試行のほとんどで勝ちながら、観測された平均パフォーマンスを悪化させる可能性があるということです。 困難な最適化問題では、ループの品質よりも、ループが継続して行うことの品質の方が重要です。