AI・機械学習
いつ止めるかを知る:ループを収束させる技術
Knowing When to Stop: The Art of Making a Loop Converge (a16z.com)
要約
AIモデルが作業完了をどのように判断するかという問題に対し、人間がテストや承認、締め切りなどの外部信号に頼るのと同様に、AIシステムも「完了」の定義を外部システムに依存する必要があると論じています。ループエンジニアリングでは、AI自身が試行錯誤を繰り返すサイクルを設計しますが、その成功は検証プロセス、変更の局所性、そして明確な停止条件にかかっています。
全文翻訳
いつ止めるかを知る:ループを収束させる技術
AIモデルは、その作業が終わったとどうやって知ることができるのだろうか?まあ、人間はいつ自分の仕事が終わったと知るのだろうか。プログラマーはテストが緑になるのを待つか、チームからのPRレビューを待つ。デザイナーは構図を調整し、少し離れてから戻ってきて、残りの不完全さはもはや重要ではないと判断する。作家は、文章が客観的に最終的な状態に達したからではなく、締め切りが来たか、あるいは編集者が受け入れたから、ドラフトを提出する。「完了」は、その仕事自体の性質であることはめったにない。それは、その仕事を取り巻くシステムによって生成される判断である。人間は「完了」のための普遍的な検出器を持っていない。私たちは、テスト、仕様、先例、承認、締め切り、リスク、そして収穫逓減点を見つけるといった、さまざまな信号に頼っている。それぞれの場合において、完了は仕事そのものの外部から来る。
永遠に続けられるモデル
AIモデルは、ほぼ常に別の答えを生成できる。段落をもう一度修正できる。別の実装を試すことができる。より詳細で、異なる照明、そしてより力強い構図の画像をさらに生成できる。それは仕事に疲れることはない。私たちが何らかの方法で気づかせるようにしない限り、最後の3回の修正で結果が異なったが、必ずしも良くはならなかったことに気づかない。これが、最近のループエンジニアリングという考え方が非常に魅力的な理由の一部である。人間がモデルにプロンプトを与え、結果を検査し、何が悪かったかを説明し、再びプロンプトを与える代わりに、システム全体でそのサイクルを実行するように依頼できる。人はもはや各ターンの中に座っている必要はない。エージェントは作業を発見し、それをモデルに与え、結果をチェックし、次に何が起こるべきかを決定する。
Peter Steinberger 🦞 @steipete
コーディングエージェントにプロンプトを与えるのはもうやめるべきだという、毎月のリマインダーです。エージェントにプロンプトを与えるループを設計すべきです。
2026年6月7日 午後6時58分
8.5M 1,796 1,414 19,839
しかし、ループを書く際のニュアンスは、ループはその各ステップの検証者と同じくらいしか良くならないということだ。ループエンジニアリングについて話し始める前から、すべてはすでにループとして実行されていたが、非常に高価なツールコール、つまり人間の手によるプロンプトと検証者としての役割を介していた。ループから人間を取り除くとき、各ステップで何を検証すべきかを設計することがループの状態を進歩させる鍵となり、現実はそれらを機能させるのが難しいということだ。標準的なコーディングエージェントのループを例にとってみよう。テストがパスするまで作業を続ける。これはほぼ完璧に検証可能に聞こえる。しかし、テストはタスクの単なる代理にすぎない。SpecBenchでは、フロンティアエージェントは、同じ機能を一緒に実行する保留中のテストに失敗しながら、見えるテストを日常的にパスした。あるエージェントは、単にテスト入力を記憶した2,900行の「コンパイラ」を生成した。ループは収束したが、検証者に対してだけであり、ユーザーの意図に対してではなかった。検証者は単なる停止条件ではない。それはループが進行と見なすものも定義する。信号が不完全であれば、ループはタスクが改善するのではなく、チェックに合格することに長けるようになる。ループエンジニアリングは、エージェントに再試行させる練習ではない。それは、各サイクルが現在の状態と望ましい状態の間の距離を縮める練習である。ループはまだ方向ではない。
収束したループ
うまく機能した最初のループはコーディングループだった。これは偶然ではない。コードは編集可能であり、実行可能でもある。エージェントは1つの関数を変更し、プログラムを実行し、テストの失敗を読み、再び試すことができる。環境は、何が壊れたかについて比較的明確な信号を返す。ループは、行動するための正確な方法と、進行を測定できる検証者の両方を持っている。私は、視覚的なコード生成において同様のパターンについて書いた。SVGは単なる画像ではない。パス、形状、テキスト、グラデーション、レイアウトを含んでいる。Blenderシーンは単なるレンダリングではない。ジオメトリ、マテリアル、カメラ、ジョイント、制約を含んでいる。これらの表現は、エージェントに検査してローカルに変更できるものを提供する。1つの曲線が間違っていれば、パスを変更する。1つのオブジェクトが配置ミスであれば、そのオブジェクトを移動する。成果物は、最初から再生成されるのではなく、イテレーションを通じて改善できる。しかし、編集可能性は問題の半分にすぎない。オープンエンドな画像生成では、別のイテレーションはしばしば別のサンプルを生成し、最良のものを選ぶことを意味する。フィードバックはグローバルであり、「これがより悪く見える」ということを、1つの正確な編集にマッピングするのは難しい。SVGとBlenderのループは、ターゲットが参照、ジオメトリ、制約、または関節オブジェクトの機能的動作として表現できる場合に収束できる。ターゲットが単に「それをより良く、より良い味で作成するが、人間には尋ねられない」という場合、それらは苦労する。視覚的なループは不可能ではない。それらはしばしば検証が非常に難しい。
完了の条件
検証者がループに方向を与える場合、ループが収束するために必要なものは何か?さまざまな分野のエンジニアや研究者との多くの会話に基づいて、4つのものがあると思う。
1. ターゲット状態
システムは、「完了」が何を意味するかの表現を必要とする。コードの場合、これはテストスイート、仕様、または一連のパフォーマンス制約である可能性がある。SVGの場合、参照画像、寸法、色、およびレイアウトルールである可能性がある。「より良くする」はターゲット状態ではない。それは別のプロンプトである。
2. 観測可能な現在の状態
システムは、現在存在するものを検査する必要がある。それはファイル、差分、テスト結果、トレース、DOMツリー、SVG構造、またはBlenderシーングラフを意味する可能性がある。レンダリングされた出力だけではしばしば十分ではない。システムは、エラーの原因を特定できるように、基盤となる構造を見る必要もある。
3. 変更を加えるための正確な方法
エージェントは、他のすべてを再生成することなく、エラーの原因となっている部分を変更する必要がある。1つの関数を変更することは、リポジトリを書き直すことよりも優れている。1つのSVGパスを編集することは、新しい画像を生成することよりも優れている。Blenderシーンで1つのオブジェクトを調整することは、シーンを最初から再構築することよりも優れている。編集がよりローカルであるほど、ループはすでに機能しているものを維持する可能性が高くなる。実際には、これは人々が正しく行うのに苦労する部分である。私が話したほぼすべての研究者は同じことを言った。彼らのループは、適切なツール呼び出しと中間プロンプトのセットを見つけたときに機能し始めた。ループを有意義に進めるツールをどのように発見するか?現時点では、誰も事前に知らない。それはほとんど試行錯誤である。これは不快な含意を示唆している。ループはそのスタックに調整されている。ループを収束させたツール呼び出しは、そのコードベースに関する仮定をエンコードしており、それらの仮定はどこか他の場所では当てはまらなくなる。誰かにとってうまく機能したループは出発点であり、保証ではない。特注のループは無料で一般化しない。そしてこれが、議論の両面を見る理由である。魔法のようなループを見つけた人もいるが、公開されているループを使用するとまったく機能しないことがわかった人もいる。
4. 停止ルール
システムは、停止を指示する条件を必要とする。条件はジェネレーターの外部から来るべきである。テストの合格、制約の満た、スコアが閾値を超える、またはレビュー担当者が結果を承認する。停止条件はコストも考慮する必要がある。500回の試行後に正しい答えに到達するループは、技術的には収束するかもしれないが、経済的にはそうではないかもしれない。
これらを2つの軸、つまり成果物の編集可能性と結果の検証可能性に沿って考えるのは有用な方法である。コードはしばしば右上隅に位置する。編集が容易で、比較的強力な検証者を持っている。オープンエンドな画像生成はしばしば左下隅に位置する。システムは別の画像を生成できるが、特定の決定を容易に修正したり、結果がユーザーの意図に近づいていることを検証したりすることはできない。重要な特性