chimera-carry-the-failure-forward

試行を1回実行し、それを判定し、フィードバックを添えてもう1回実行するループがある場合に当てはまる。検証器付きのエージェント、テストスイートに対するコード修正器、生成してチェックするパイプラインなどだ。予算は2回を超える試行があり、各試行がきれいな状態から始まるよう、試行の間にワークスペースは巻き戻される。

不安定なトランスポート上での冪等なリトライ——送った内容とは無関係な理由で失敗したネットワーク呼び出し——には当てはまらない。そこでは試行1から学べることは何もなく、それを持ち越すのは単なる余計な積荷である。

1. 試行は再代入する変数ではなくリストに保存する。1試行につき1レコードとし、検証器の出力、その試行が実際に書いたパッチ、そして最初にエラーを出したツールステップを含める。
2. パッチは巻き戻しの前に、ワークスペースのスナップショットから取得する——モデルによる変更の説明ではなく、本物の差分をだ。この手順が必要になるのは巻き戻しがあるからである。ツリーが巻き戻されてしまえば、その誤った経路もディスク上のどこにも記録されておらず、次の試行が同じ経路を再び導き出すことを妨げるものは何もない。
3. リトライ用のプロンプトは全レコードから、古い順に組み立てる。各レコードには試行番号と判定を付し、これらはすでに試され巻き戻されたものだと述べる見出しの下に置く。
4. 各レコードに上限を設ける。Chimera はフィードバックする差分を2000文字で打ち切り、マーカーを付けて切り詰める。上限のない3試行分の履歴はプロンプトを占領してしまう。
5. 失敗のシグネチャで重複を除く。2つの試行が同じ形で失敗したなら、1つだけ残し、それが再発したことを記録する——繰り返されたという事実こそが信号であり、2つ目のコピーは新しい情報ではない。
6. シグネチャが繰り返されたら、追記をやめて構造的な何かを変える。蓄積された原因をプランナーのコンテキストとして計画を立て直す(TaskLedger.context() はそれらを "Why earlier attempts failed (do NOT repeat these):" の下にレンダリングする)か、より強力なモデルへエスカレーションする。同じ袋小路についてのフィードバックを増やしても、その袋小路からは出られない。
7. 履歴を注入するたびに数えられるイベントを発行し、ベンチマークの各群が、そもそも注入が発火したことを証明できるようにする。

アンカリングは仮定の話ではなく、登録済みの対立仮説である。モデルに誤ったパッチを見せると、その注意がそのパッチに固定され、別のアプローチではなく死んだアプローチの変奏を生み出しうる。だからこそ Chimera ではこの挙動がデフォルトで有効ではなく、オプトインで測定される形になっている(--diff-feedback)。決着のついた改善としてではなく、自分のタスクで検証すべき主張として扱うこと。

2つ目のコストはコンテキスト予算だ。3つの差分、3つの検証器の出力、そしてマネージャーのレビューは、プロンプトを圧縮の閾値の向こうへ押しやりうる——そして復元を持たない圧縮器は、まさに苦労して積み上げた蓄積履歴を落とすことになる。これを有効にする前にレコードに上限を設け、自分の予算を把握しておくこと。さもないと2つの仕組みが互いに争い、目に見える症状はそのどちらでもないものになる。