AI News HubLIVE
サイト内リライト2 分で読了

AIエージェントを数ヶ月かけて構築したが、その後削除した

Runnitチームはモデルのコンテキスト制限により複数の専門AIエージェントを構築したが、新しいモデルのコンテキストウィンドウが大きくなったことで、単一インテリジェンスアーキテクチャの方がシンプルで効果的であると気づき、全エージェントを削除した。

ソースHacker News AI著者: marktolson

ここ数ヶ月、私たちはRunnitにAIエージェントを組み込むことに多くの時間を費やしてきました。複数のエージェントを構築し、それぞれに特定の責任を持たせました。計画担当、調査担当、スケジューリング担当、執筆担当です。それぞれに慎重に作られたプロンプト、異なる動作、専門分野がありました。当時はそれが正しいアーキテクチャだと感じていました。初期のLLMはコンテキストウィンドウが小さく(64k-128k)、作業を専門エージェントに分割することは、よりクリーンであるだけでなく、半ば正確な結果を生み出すために必要でした。各エージェントは1つの問題だけを理解すればよく、利用可能なコンテキストをより効果的に使えました。

しかしモデルが改善されるにつれ、私たちは依然として過去の制限に合わせて設計していることに気づきました。より大きなコンテキストを持つ新しいモデルをテストするほど、それらが異なる種類の作業を自然に切り替えられることに気づきました。同じ会話の中で計画、執筆、調査、推論ができ、適切な情報が適切なタイミングで提供されれば、完全に別のアシスタントになる必要はありませんでした。その結果、私たちはシンプルな質問を自問せざるを得ませんでした。「これらは本当に別々のエージェントである必要があるのか?」

結局、答えは「いいえ」でした。そこでエージェントを削除しました。増え続ける専門エージェントのコレクションを維持する代わりに、必要なときに機能をロードする単一のインテリジェンス(Ruと命名)を中心にアーキテクチャを再構築しました。調査はエージェントではありません。スケジューリングはエージェントではありません。執筆はエージェントではありません。それらは能力と指示であり、タスクのためにロードされ、作業が終わればアンロードされる専門知識の断片です。この変更は小さく聞こえますが、ほぼすべてを簡素化しました。

ビジネスの一貫した理解、1つの会話、1つのメモリ、組織の知識が存在する1つの場所があります。速度が重要な場合、同じインテリジェンスは単に自身の並列インスタンスを作成し、各インスタンスが自身の作業に必要な指示をロードしてからすべてを統合します。外部から見ると依然として並列に動作しますが、内部では同じインテリジェンスが問題の異なる部分を解決しています。また、驚くほどの複雑さを削除していることにも気づきました。数十の個別プロンプトを維持したり、別々のエージェント間の引き継ぎを調整したり、エージェントが進化するにつれて徐々にずれていくことを心配する必要がなくなりました。

これは専門エージェントが時代遅れになったことを意味するわけではありません。作業を分離したり、異なるモデルを使用したり、権限を分離したりする正当な理由は依然としてあります。しかし、私たちの多くは、もはや存在しないモデルのために下されたアーキテクチャ上の決定を引きずっていると思います。もし今日Runnitを再び始めるとしたら、「どのエージェントを構築すべきか?」と尋ねることはないでしょう。代わりに別の質問から始めます。「単一のインテリジェンスにはどのような能力が必要か?」時には進歩は別のレイヤーを追加することではありません。時には、もう必要ないことに気づくことです。