著者：Systematic Long Short
翻訳：深潮 TechFlow
深潮の導入：この記事の核心的な主張は一文だけだ。AIエージェントの出力品質は、投入したトークンの数に比例する。
著者は一般的な理論を語るのではなく、今日からすぐに使える具体的な方法を二つ提示し、「新規性の問題」というトークンを構築できない境界を明確に定めています。
エージェントを使ってコードを書いたりワークフローを実行している読者向けに、情報密度と実行可能性が非常に高いです。
導入
まあ、このタイトルは確かに目を引きますが、本気で言っています。
2023年、私たちがLLMで本番コードを実行していたとき、周囲の人々は驚きのあまり口を開けたままだった。当時は、LLMは使い物にならないゴミしか生成できないという認識が一般的だったからだ。しかし、私たちには他人が気づいていなかった事実があった。エージェントの出力品質は、投入するトークン数の関数である。それだけの話だ。
自分でいくつかの実験をすればすぐにわかる。Agentに、制約付き凸最適化アルゴリズムをゼロから実装するような複雑でややマニアックなプログラミングタスクをさせよう。最低思考レベルで実行し、次に最高思考レベルに切り替えて、自身のコードをレビューさせ、どれだけのバグを発見できるか見てみよう。中レベルや高レベルも試してみる。すると、投入されたトークン量に比例してバグの数が単調に減少する様子が直感的にわかるだろう。
これは簡単に理解できますよね？
トークンが多ければ多いほど、エラーは少なくなる。このロジックをさらに進めるなら、これはコードレビュー製品の背後にある（簡略化された）核心的なアイデアそのものだ。まったく新しい文脈で、膨大なトークンを投入する（たとえば、コードを1行ずつ解析し、各行にバグがあるか判断する）——これにより、ほぼすべてのバグ、あるいはすべてのバグを特定できる。このプロセスを10回、100回繰り返し、毎回「異なる視点」からコードベースを検証すれば、最終的にすべてのバグを掘り起こせる。
「多くのトークンを燃焼させればエージェントの品質が向上する」という見解には、もう一つの実証的裏付けがある。エージェントを用いてコードを完全に自動生成し、直接本番環境にリリースできると主張するチームは、基礎モデル提供者自身か、資金が非常に豊富な企業に限られている。
したがって、エージェントがプロダクションレベルのコードを生成できないことで悩んでいるのであれば、正直に言えば、問題はあなたにあります。あるいは、あなたのウォレットにあります。
自分が焼却したトークンが十分かどうかをどう判断すればよいですか？
私は以前、問題はあなたが構築したフレームワーク（harness）にない、シンプルさを保つことで優れた成果を生み出せることを説明する記事を書いた。私は今でもその見解を堅持している。あなたはその記事を読み、それに従ったが、Agentの出力に依然として大きな失望を感じている。あなたは私にDMを送ったが、私は既読にしており、まだ返信していない。
この投稿は返信です。
あなたのエージェントのパフォーマンスが悪く、問題が解決できないのは、ほとんどの場合、使用したトークンが十分でないためです。
問題を解決するために必要なトークンの量は、その問題の規模、複雑さ、新規性によって完全に決まります。
「2+2はいくつですか？」多くのトークンは必要ありません。
PolymarketとKalshiのすべての市場をスキャンし、意味的に類似し、同じイベントの前後に決済される市場を特定し、アービトラージ境界を設定して、アービトラージ機会が発生した際に低遅延で自動取引するボットを作成してほしい——これは大量のトークンを消費する必要がある。
実践の中で、興味深いことに気づきました。
規模と複雑さによって生じる問題を解決するために十分なトークンを投入すれば、エージェントはいずれにせよ問題を解決できる。言い換えれば、非常に複雑で多くのコンポーネントとコード行を含むものを構築したい場合、これらの問題に十分なトークンを投じれば、最終的にすべてが完全に解決される。
ただし、小さなが重要な例外があります。
あなたの質問はあまりに新規性が高すぎます。現在の段階では、どの程度のトークン数を用いても「新規性」の問題を解決することはできません。十分なトークン数は複雑さに起因するエラーをゼロに減らすことはできますが、エージェントが知らないものを空想で生み出すことはできません。
この結論は、実は私たちを安心させました。
私たちは膨大な労力を費やし、非常に多くのトークンを消費して、ほとんどガイドを提供しない状況でエージェントが機関投資プロセスを再現できるかどうかを試しました。この試みの一部の目的は、私たち（数量的研究者）がAIに完全に置き換えられるまでにあと何年あるのかを理解することでした。その結果、エージェントはまともな機関投資プロセスに近づくことさえできないことがわかりました。我们认为この原因の一部は、エージェントがこのようなプロセスをこれまで見たことがない、つまり機関投資プロセスがトレーニングデータに存在しなかったためです。
したがって、あなたの質問が新規性を持っている場合、トークンを積み重ねることで解決しようとしないでください。自ら探求のプロセスを導く必要があります。しかし、実装方法を確定すれば、コードベースの規模やコンポーネントの複雑さに関わらず、トークンを積み重ねて実行することに安心して取り組めます。
簡単なヒューリスティックな原則があります：トークン予算はコード行数に比例して増加すべきです。
どれほど燃やされたトークンは実際に何をしているのか
実際には、追加のトークンは通常、以下の方法でエージェントのエンジニアリング品質を向上させます：
同じ試行の中でより長く推理に時間をかけ、自らの論理的誤りに気づく機会を増やしましょう。推理が深ければ深いほど、計画は良くなり、一度で成功する確率は高くなります。
複数の独立した試行を許可し、異なる解法のパスを試させてください。いくつかのパスは他のパスよりも優れています。複数回試行を許すことで、最適なパスを選択できます。
同様に、より多くの独立した計画を試みることで、弱い方向を諦め、最も有望な方向を維持できます。
より多くのトークンにより、新しい文脈で自らの過去の作業を批判し、ある「推論の慣性」に閉じ込められるのではなく、改善の機会を与えられる。
もちろん、私が最も好きな点の一つは、より多くのトークンがあることで、テストやツールで検証できる点です。実際にコードを実行して動作するか確認することは、答えが正しいことを確認する最も信頼できる方法です。
このロジックが成り立つのは、エージェントのエンジニアリング失敗がランダムではないからです。ほぼ常に、早期に間違った道を選択し、その道が本当に通れるかどうかを確認しなかった、またはエラーを発見した後に回復やロールバックするための十分な予算がなかったことが原因です。
就是这样。トークンは文字通り、あなたが購入した意思決定の質です。研究作業に例えて考えてみてください。誰かに即座に難しい質問に答えてもらうと、時間の圧力が増すほど答えの質は低下します。
研究は、結局のところ、「答えを知る」という基本的なものを生み出すことである。人類は生物学的な時間を費やしてより良い答えを生み出し、エージェントはより多くの計算時間を費やしてより良い答えを生み出す。
エージェントをどのように向上させることができますか
あなたはまだ疑念を抱いているかもしれませんが、これを裏付ける論文は多数存在します。正直に言えば、「推論」調整ノブの存在そのものが、あなたに必要なすべての証拠です。
私が特に気に入った論文では、研究者が少数の精心された推論サンプルで訓練し、モデルが停止しようとする際に「Wait」（お待ちください）を追加することで、思考を継続させる方法を用いた。この手法だけで、あるベンチマークの成績が50%から57%に向上した。
もっと素直に言うと：エージェントが書いたコードがいまいちだとずっと文句を言っているなら、おそらく一度の最高思考レベルでもまだ足りていない。
あなたに2つの非常に簡単な解決策を提供します。
簡単な方法その1：WAIT（待つ）
今日からすぐにできる最も簡単なこと：自動ループを構築する。構築後、Agentに新しいコンテキストでN回レビューさせ、問題を発見するたびに修正する。
この簡単なテクニックであなたのAgentエンジニアリングの効果が向上したと感じたなら、あなたは少なくとも自分の問題がトークン数の問題であることに気づいたということです。それでは、トークンを燃やすクラブに参加しましょう。
簡単な方法2：VERIFY（認証）
Agent は、自分の作業を早期かつ頻繁に検証してください。選択したパスが実際に動作することを証明するためのテストを書きましょう。これは、高度に複雑で深くネストされたプロジェクトにとって特に役立ちます——ある関数は、下流の多数の他の関数から呼び出される可能性があります。エラーを上流で早期に発見すれば、その後の計算時間（トークン）を大幅に節約できます。したがって、可能な限り、構築プロセス全体に「検証チェックポイント」を設けてください。
何かを書き終えた後、メインエージェントが「完了しましたか？」と尋ね、セカンダリーエージェントに確認させます。関係のない思考の流れは、システム的なバイアスの源を覆い隠すことができます。
基本的にこれで十分です。この話題についてもっと多くのことを書けますが、この二つのことを認識し、しっかりと実行すれば、95％の問題を解決できると信じています。私は、シンプルなことを極め、必要に応じて複雑さを追加すると確信しています。
私は「新規性」はトークンでは解決できない問題だと述べましたが、もう一度強調しておきます。なぜなら、いずれあなたはこの問題に直面し、トークンを積み上げても無駄だったと私に泣きついてくるからです。
訓練データにない問題を解決したいとき、あなたが真正に解決策を提供する人である。したがって、ドメイン専門知識は依然として極めて重要である。