AIエージェントのボトルネックはモデルではなく、アーキテクチャだった。
3ヶ月前、クライアントのワークフローが停止した。
私は、ドキュメントの分類、タグ付け、要約を行うために、1つのエージェントを使用していた。1日50件程度のドキュメントであれば問題なく動作していたが、件数が500件に達したとき、状況が変わった。
エージェントは1バッチあたり40分かかった。スケーラビリティがなく、システムはクラッシュした。
私はより大きなモデルに切り替えるのではなく、エージェントを3つの専門的な役割に分割した。そして、これらの役割を並列で実行させた。
スループットは40分から4分へと劇的に改善した。モデルは同じまま、アーキテクチャを変えただけだ。
多くの開発者は、逐次的な（sequential）エージェントを構築するという間違いを犯す。1つのエージェントがすべてのタスクを順番にこなしていく方式だ。
もし500件のドキュメントがあり、1件につき3つのタスクがある場合、1,500回のLLMコールを一つずつ順番に行うことになる。たとえ1回のコールが2秒だとしても、50分間待つことになる。モデルのほとんどの時間は「待ち」に費やされてしまうのだ。
解決策は、並行して動作する専門特化したエージェントを使用することだ。
- より小さく、焦点を絞ったシステムプロンプトを使用する。
- 独立したタスクを同時に実行する。
- ディスパッチャー（dispatcher）を使用してタスクを管理する。
専門特化したエージェントは、高速かつ低コストだ。特定のタスクにおいては、厳密なプロンプトを用いた小型モデルの方が、大規模な汎用モデルよりも優れたパフォーマンスを発揮する。
ただし、すべてを並列化すればよいわけではない。以下の間違いは避けよう。
- 依存関係のあるタスクを並列化しないこと。タスクBがタスクAの出力を必要とする場合、それらは順番に実行しなければならない。
- 極めて小さなタスクを並列化しないこと。エージェントを管理するためのオーバーヘッドが、タスク自体の実行時間よりも長くなってしまう可能性がある。
- 検索（retrieval）速度を無視しないこと。データベースのルックアップが原因でシステムが遅くなっている場合、LLMコールを並列化しても解決にはならない。
スケーリングさせるには、以下のステップに従うこと。
- まずシステムをプロファイリングする。実際にどこで時間が失われているかを特定する。
- 特定の役割に対して専門特化したエージェントを使用する。
- コードを書く前に、依存関係グラフ（dependency graph）を書き出す。
AIエージェントの構築には、2つの異なる問題がある。1つは「エージェントが何をすることか」、もう1つは「エージェントをどのようにシステムに組み込むか」だ。
本番環境のシステムが成功するか失敗するかは、後者の問題にかかっている。
もし限界に突き当たったら、単に大きなモデルを買うのではなく、まずはシステムのマップを描いてみよう。アーキテクチャこそが真の問題であることに気づくはずだ。
Source: https://dev.to/mrclaw207/my-ai-agent-bottleneck-wasnt-the-model-it-was-the-architecture-2h9m
Optional learning community: https://t.me/GyaanSetuAi