エージェント・アーキテクチャは計算リソース配分の問題である
最近、3つの独立したグループがAIエージェントの設計において同じ結論に達しました。
Anthropicは「アドバイザー戦略（advisor strategy）」に関するブログ記事を公開しました。彼らはメインループの実行に安価なモデルを使用し、安価なモデルが行き詰まった場合にのみ高価なモデルを呼び出します。BrowseCompにおけるこの構成は、すべてを最上位モデルで行う場合のコストのわずか15%で、41.2%の精度を達成しました。
ShopifyのTobi Lutke氏は、Xで同様の構成を共有しました。彼はリサーチにローカルモデルを使用し、アドバイザーとしてフロンティアモデル（frontier model）を使用しています。開発者たちは、これらオープンソース版を数時間以内に構築しました。
HazyResearchは「コンプレッサー・プレディクター（compressor-predictor）」フレームワークに関する論文を発表しました。小規模なモデルがコンテキストを蒸留し、大規模なモデルがそれに基づいて推論を行います。彼らのシステムは、コストの26%で精度の99%を回復しました。
この収束は偶然ではありません。それは特定の設計法則、すなわち「コスト曲線フレーム（cost-curve frame）」に従っています。
私はこのシリーズを通じて、3つのレイヤーにわたってこのフレームワークを論じてきました。
- レイヤー 1 (Retrieval): なぜほとんどのコードタスクにおいてツールループ（tool-loops）がRAGよりも優れているのか。
- レイヤー 2 (Storage): なぜシンボルグラフにおいてSQLiteがベクトルデータベースよりも優れているのか。
- レイヤー 3 (Orchestration): なぜモデル選択においてアドバイザー戦略が勝るのか。
ロジックは同じです。ほとんどのエージェントのタスクは、多くの低価値な操作と、少数の高価値な決定で構成されています。
すべてのトークンに高価なモデルを使用すると、コンテキストの読み取りやテキストのフォーマットといった日常的な作業に資金を浪費することになります。アドバイザー戦略は、これらの経路を分離します。大部分の作業には安価なエグゼキューター（executor）を使用し、重要な意思決定ポイントにのみ高価なアドバイザーを使用します。
エージェントを構築している場合は、以下の3つのエンジニアリング上の課題に注意してください。
- データ流出 (Data Egress): コンテキストをリモートのアドバイザーに送信すると、機密データが漏洩する可能性があります。秘匿化レイヤー（redaction layer）を使用してください。
- エスカレーション・ポリシー (Escalation Policy): アドバイザーをいつ呼び出すかを決定するのは困難です。早すぎるとコストが無駄になり、遅すぎると時間が無駄になります。
- ハンドオフ設計 (Handoff Design): アドバイザーは完全な解決策ではなく、簡潔な計画を提供すべきです。
このパターンが実在するのは、それが効率的だからです。それらを必要としないトークンに対して、フロンティアモデルの料金を支払うのはやめましょう。
Optional learning community: https://t.me/GyaanSetuAi