「ツール検索」から「スキル」へ: AIエージェントアーキテクチャのパラダイムシフト Claudeはスキルルールをリリースし、Codexもスキルのサポートを開始しました。これはAIエージェントの標準機能になりつつあります。すべてのツールをLLMに単純に投入し、LLM自身に選択させる(つまり「ツール検索」させる)のは行き詰まりです。将来的には、機能を独立した信頼性の高い「スキル」としてカプセル化し、より正確な分類メカニズムを通じて呼び出すことが目指されます。 重要な議論: 「ツール検索」はなぜ廃止されたのか? 初期のエージェント開発では、開発者は、辞書を引くのと同じようにモデルが「検索」して適切なツールを選択できることを期待して、大規模なモデルのプロンプト コンテキストに数十、数百もの関数呼び出し定義を詰め込んでいました。 著者は、このモデルには 3 つの致命的な欠陥があると考えています。 • 信頼性が低い: ツールの数が増えるとモデルの注意力が散漫になり、間違ったツールを選択したり、錯覚が生じたりすることが多々あります。 • スケーラビリティが低い:コンテキストウィンドウは限られており、コストもかかります。すべてのツール定義を1つのプロンプトに詰め込もうとすると、トークンが無駄になるだけでなく、モデルの推論品質も低下します。 • 「使用方法」に関する知識の欠如:モデルにツールのAPI定義(例:get_weather(city))を与えるだけでは不十分です。モデルは多くの場合、「いつ使用するか」「どのように使用するか」「エラーが発生した場合の対処方法」といった暗黙的な知識を必要としますが、「ツール検索」パターンはこうしたコンテキストを無視します。 解決策: スキルは新たな標準になりつつあります。「スキル」は単なるツールの名前変更ではなく、よりモジュール化され、より明確なアーキテクチャアプローチを表しています。 「スキル」とは何ですか? • コンテキストをカプセル化: 「スキル」には、ツール自体だけでなく、ツールの使用に関するベストプラクティス、具体的な指示、さらには事前に構築されたナレッジベースも含まれます。 • オンデマンドロード:スキルは常にコンテキストに関連付けられているわけではありません。システムは必要な場合にのみ、特定のスキルをモデルに「ロード」します。 どのように機能しますか?(分類と検索) 著者らは、大規模なモデルに長いリストを盲目的に検索させるのではなく、分類器またはルーティング レイヤーを使用することを提唱しています。 • 意図認識: ユーザーがリクエストを行うと、まず軽量モデルまたは分類器によって意図が判断されます。 • スキルのロード: 分類結果に基づいて、システムは対応する「検索スキル パック」または「プログラミング スキル パック」のみをコンテキストに取得します。 • 正確な実行: この時点では、メイン モデルは現在のタスクに関連性の高いいくつかのツールと詳細な指示のみを認識するため、成功率が非常に高くなります。 要約: AI開発者への影響 エージェント開発は、「プロンプトワードエンジニアリング」から「ソフトウェアエンジニアリング」へと移行しています。 • 古いアプローチ: LLM の一般化機能にすべての希望を託し、混乱の中で適切なツールを見つけられるよう祈る。 • 新しいモデル(スキル):コード作成などの複雑なタスクを分離します。AIにハンマーを与えるだけでなく、「ハンマーのユーザーガイド」も提供し、釘を打つ必要がある場合にのみAIにハンマーを渡します。 この変革により、AIエージェントは「たまに使うおもちゃ」から「安定した信頼性の高い生産性ツール」へと変化しました。エンタープライズアプリケーションにおいては、単にモデルパラメータを積み重ねるよりも、明確かつ明確に定義された「スキル」ライブラリの方が重要な資産となるでしょう。 原文を読む
スレッドを読み込み中
X から元のツイートを取得し、読みやすいビューを準備しています。
通常は数秒で完了しますので、お待ちください。
