Lynkr

開示: 私は Lynkr を維持しています。Lynkr は loop-guard ミドルウェアを備えたオープンソースの LLM ゲートウェイなので、この議論に利害関係があります。この投稿は中立的な調査ではなく、議論を呼ぶための提言としてお読みください。

エージェントに関する議論は、プロンプトからループへと移行しています。つまり、モデルが完了したと判断するまで継続される read-act-observe のサイクルです。私が反対する見解は、いわゆる loop engineering の多くが誤った変数を最適化しているというものです。より長く、より豊かなループは通常、仮装した収束の失敗です。 うまく設計されたループとは、いつ停止すべきかを知っている短いものです。

私が反対するコンセンサス

エージェントが失敗すると、デフォルトの対応はループに より多く を与えることです。

  • 諦めるまでのターン数を増やす。
  • ウィンドウに詰め込むコンテキストを増やす。
  • プランナー、批評家、振り返りステップ、サブエージェントを生むサブエージェントなど、より多くの足場を用意する。
  • より多くのフィードバックによるリトライを増やす。

暗黙の理論は単純です。知能は反復を通じて蓄積されるため、ターン数が増えれば収束も増すというものです。時折これは機能しますが、実際のトラフィックではほとんど機能しません — 機能したとしてもコスト構造は残酷です。

コーディングエージェントからの具体例です。力不足のモデルにリポジトリ全体のリファクタリングをさせると、通常「より長く推論して」成功することはありません。依存関係を一つ読み違え、誤ったファイルに固執し、その後数十ターンかけてその誤りを詳細化します。ループはモデルを救っているのではなく、失敗に資金を提供しているのです。

長いループが誤ったものを複合させる理由

ループを通じて複合するのは 2 つのもので、いずれも知能ではありません。

1. ループのコストは急速に増大する。 各ターンは蓄積されたコンテキストを再送します。20 ターンのセッションは、単に 20 回の単一コールを連続実行するものではなく、後続の各ターンは以前のトークンをモデルを通じて引きずります。多くのエージェントワークロードでは、ループが提供予算の中で最も高価なオブジェクトとなり、「ターン数を増やす」は回せる最も高価なノブとなります。

2. 依存ステップ間で信頼性が崩壊する。 楽観的なステップごとの信頼性があったとしても、マルチステップのチェーンは急速に劣化します。長いループは誤りを平均化するのではなく、正しい軌道に留まる確率を乗算します。「ただもっとターンが必要」なエージェントは、しばしば誤った分岐をより深く進むエージェントであり、各ターンが自らの以前の誤りを事実であるかのように条件付けているため、より確信を持って進みます。

以前、コンテキストウィンドウに詰め込むことがエージェントを賢くするのではなく悪化させることについて書きました。注意が希薄化し、検索が誤ったチャンクに固定され、信号が埋もれます。ループ長は時間軸における同じ失敗です。より多くはより多くではありません。

長いループが実際に示していること

エージェントが何かを達成するのに 30 ターン必要とする場合、それは通常ハーネスが賢いということではありません。通常、2 つの失敗のうちいずれかのシグナルです。

  1. タスクが、それを実行できないモデルにルーティングされた。 ループは、そのモデルが苦戦している状態です。足場は力不足のモデル決定を修正することは稀で、通常は失敗をより精緻でより高価なものにするだけです。
  2. タスクに本当に多くのステップがある。 その場合、エンジニアリング上の問題は「より多くのターンを許可する方法」ではなく、「各ステップを安価に検証して、誤った分岐を 30 ターン目に複合させるのではなく 3 ターン目で捕捉する方法」です。

いずれも同じ方向を指しています。ステップをより良いモデルに割り当てるか、ステップを進む前に検証するかのいずれかです。どちらも「ターンを増やして希望する」とは言いません。

ループエンジニアリングが実際にすべきこと

ループがコストと誤差が複合する場所であるなら、良いループエンジニアリングは複合を最小化すべきであり、ターンあたりの能力を最大化すべきではありません。

1. ループを厳格に上限設定する。 すべてのループには、ターン上限とツールコール上限が必要であり、それを超えることは絶対にできません。緊急時のフォールバックではなく、一級の設計制約として扱います。永遠に実行 できる ループは、ある入力に対して、ゴミを生成するために多額の費用を発生させるでしょう。

2. 各ステップを安価に検証する。 ループへの最高レバレッジの追加は、通常、別の推論ステージではありません。実際に観測される失敗モードを捕捉する、高速で決定論的なステップ出力のチェックです。切り捨て、不正なツールコール、空の回答、退化ループ、繰り返しのエコーなどです。予測よりも検出の方が優位です。なぜなら、すでに手元に出力があるからです。

3. 失敗したステップをエスカレートし、セッション全体をエスカレートしない。 ステップが検証に失敗した場合、そのステップ をより良いティアで再実行します。ループ全体により多くのターンを与えて暴れさせるのではありません。エスカレーションは標的的です。より多くのターンは白紙委任状です。

我々にもこの問題が起きた

我々も例外ではありません。Lynkr では、出力トークンを節約するためにモデルをより短い回答に向かわせる terse モードを出荷しました。その後、検証器がこれらの短い回答の一部を低努力の失敗と誤読し、些細なリクエストをより長い、より高価なパスにエスカレートしました。

修正は 1 つの述語でした。しかし、より広い教訓はそうではありません。ループ内のチェック自体が、ループのコストと失敗面の一部です。 「検証を追加する」は無料の美徳ではありません。悪い検証器は、素朴なリトライと同じように熱心にループを延長できます。検証は他のどのターンと同じ疑いを持ってエンジニアリングされなければなりません。

提言、平易に

人気のあるループエンジニアリングの多くは、ターン数を無料として扱いつつ、ターンあたりの能力を最適化しています。これは逆です。実際のトラフィックでは、ターン数はしばしば支配的なコストであり、複合誤差の主要な源です。

タスクにより多くの知能が必要なら、そのステップにより多くの知能を購入します。タスクにより多くの信頼性が必要なら、ステップを検証します。ループが成長し続けるなら、それを洗練ではなく失敗のシグナルとして扱います。

ループを短くする。停止させる。それがエンジニアリングです。

Lynkr は Apache-2.0 でセルフホスト可能です。この投稿の背景にある loop-guard ミドルウェアとステップレベルエスカレーションのアイデアはリポジトリにあります: github.com/Fast-Editor/Lynkr。ループが長くなりすぎるのを見てその理由を知っている方がいれば、ぜひ war story をお聞かせください。