著者 | パトリック・ドハティ 編纂者：岳陽 01 「エージェント」とは何か？（定義）この記事の主題を議論する前に、この記事で言及されている「エージェント」とは何かを明確に定義する必要があります。あるTwitterユーザー[1]の言葉を借りれば、
簡潔な定義を与えるために最善を尽くしました。 この定義は、OpenAIがChatGPTで言及した「生成的事前学習モデル（GPT）」の概念、およびOpenAIのAPI [2]における「アシスタント」の概念にほぼ相当します。しかし、エージェントはこれらの機能に限定されるわけではありません。論理的推論を実行し、ツール呼び出しを実行できるモデルであれば、AnthropicのClaude** [3]、CohereのCommand R+ [4]など、多くのモデルがこのタスクを実行できます。 注記 ツール呼び出しは、get_weather_forecast_info(seattle) や wikipedia_lookup(dealey plaza) などの関数を呼び出すなど、モデルが実行する特定の操作を表現し、その操作の結果を取得する方法です。 エージェントの構築には、わずか数行のコードが必要です。このコードは、明確な目標を持ち、システムプロンプトに導かれる対話プロセス、モデルが実行したいツール呼び出しの処理、これらの操作をループ処理し、目標が達成されたら停止するといった処理が可能です。 このプロセスを説明するには、次の図が役立ちます。 「エージェント」を構築するための基本的な手順の概要 02 エージェントシステムプロンプトの例AI エージェントに関して明確にする必要があるよくある誤解を次に示します。
03 コンテキストAIエージェントプロジェクトの開発1年目には、エンジニアやUXデザイナーと連携し、製品全体のユーザーエクスペリエンスを何度も最適化する貴重な経験を積むことができました。私たちの目標は、お客様が当社の標準化されたデータ分析エージェントを活用し、それぞれの業務タスクやデータ構造に合わせたカスタムAIエージェントを開発できるプラットフォームを構築することです。SnowflakeやBigQueryなどのデータベースとの安全な統合を実現するために、セキュリティメカニズムを組み込みました。このプラットフォームは、データベースの内容を記述するメタデータ層でRAG（Retrieval Enhancement Generation）ツールを呼び出し、SQL、Python、データ可視化対応のデータ分析ツールを用いてデータを分析します。 どのアプローチが実現可能で、どの視点が不十分かを判断するために、このプラットフォームは独自の評価だけでなく、お客様からの率直なフィードバックも活用しています。当社のユーザーは主にフォーチュン500企業の従業員で、社内データの詳細な分析に当社のAIエージェントを日々利用しています。 04 エージェントについて学んだこと4.1 知識の量よりも推論能力が重要です。この一文がここ一年間私の心の中で反響し続けています。
AIエージェントは、この視点に対する論理的な回答です。AIエージェントを構築する際には、以下のロジックを採用します。 AI エージェントが「知っている」ことにあまり重点を置くのではなく、むしろ「考える」能力に焦点を当ててください。 SQLクエリの記述を例に挙げてみましょう。SQLクエリは頻繁に実行に失敗します…そしてこれはよくあることです。私がデータサイエンティストだった頃、SQLクエリの実行に失敗した回数は、成功した回数をはるかに上回っていました。 複雑なSQLクエリを、初めて慣れていない実際のデータに対して実行したときに、うまく実行できたとしても、私たちは「わあ、完璧！うまくいった！」と自信を持って考えるのではなく、「ああ、何か問題があるかもしれない！」と驚き、疑念を抱くべきです。モデルが単純な問題をクエリに変換できるかどうかを評価するテキストからSQLへのベンチマーク[6]でさえ、その最高精度はわずか80％です。 したがって、モデルのSQL文作成能力がせいぜいB-しか達成できないと認識したとしても、その推論能力をどのように向上させることができるでしょうか？重要なのは、エージェントが最初の試行で正しく答えることを期待するのではなく、エージェントが「考える」のに十分なコンテキストを提供することです。AIエージェントが作成したクエリが失敗した場合、すべてのSQLエラー情報と可能な限り多くのコンテキスト情報をフィードバックする必要があります。これにより、AIエージェントはほとんどの場合に問題を自ら修正し、SQL文を正しく実行できるようになります。また、エージェントに多数のツール呼び出しを提供することで、人間と同様に、新しいクエリを作成する前に、データベースの情報スキーマとデータ特性（分布や欠損値のデータ）を調査・分析できるようにします。 4.2 パフォーマンスを向上させる最善の方法は、エージェント コンピュータ インターフェイス (ACI) を継続的に最適化することです。「ACI」（プリンストン大学の研究[7]に由来）という用語は比較的新しいものですが、この1年間、その改良は私たちの日々の業務の中心的焦点となってきました。ACIとは、AIエージェントが使用するツール呼び出しの特定の構文とアーキテクチャを指し、AIエージェントによって生成される入力と、APIによってレスポンスとして返される出力が含まれます。これらは、エージェントが必要なデータを取得し、進捗を促進し、作業目標と整合を図るための唯一の方法です。 基盤となるモデル（gpt-4o、Claude Opusなど）はそれぞれ独自の特性を持っているため、あるモデルに最適なACIが、別のモデルには必ずしも適さない場合があります。つまり、優れたACIを構築するには「科学と芸術」の融合が必要であり、単にソースコードを書くというよりも、究極のユーザーエクスペリエンスを創造するようなものです。ACIは常に進化しており、小さな変更がドミノ倒しのように連鎖反応を引き起こす可能性があるからです。ACIの重要性はいくら強調してもし過ぎることはありません。私たちはAIエージェントを何百回も繰り返し開発してきましたが、名前、数量、抽象化レベル、入力形式、出力レスポンスのわずかな調整でさえ、AIエージェントのパフォーマンスに大きな変動を引き起こす可能性があります。 ACIがいかに重要で困難であるかを鮮明に示す具体的な例を以下に示します。gpt-4-turboのリリース直後、AIエージェントに対して多数のテストを実施したところ、厄介な問題が発見されました。AIエージェントがレスポンス情報（ツール呼び出しレスポンスを通じてエージェントに通知または渡そうとしていたデータ）を処理する際に、特定のデータを完全に無視していたのです。OpenAIの公式ドキュメントから直接抽出したマークダウン形式の情報を使用していましたが、同じデータセットのgpt-4-32kで完璧に動作しました。AIエージェントが「無視」されているデータ列を認識できるように、マークダウン構造にいくつかの調整を試みましたが、どのように変更してもエージェントは応答しませんでした…そこで、戦略を完全に変更し、情報形式をマークダウンからJSON（OpenAIモデルのみ）に変換することにしました。奇跡的に、すべて正常に戻りました。皮肉なことに、応答に JSON を使用すると構文文字の数が多いためにトークンの消費量が多くなりますが、このステップは必要なだけでなく、エージェントがモデルの応答を正しく解釈できるようにするためには極めて重要であることがわかりました。 ACI の最適化プロセスは重要ではないと思われるかもしれませんが、実際にはエージェントのユーザー エクスペリエンスを向上させる効果的な方法の 1 つです。 4.3 AI エージェントの機能は、使用するモデルによって制限されます。基盤となるモデルはエージェントの脳のようなものです。モデルの決定が不十分であれば、どれほど魅力的に見えても、ユーザーを満足させることはできません。私たちは、gpt-3.5-turboとgpt-4-32kをベースモデルとしてテストした際に、このことを直接体験しました。GPTバージョン3.5を使用した場合、いくつかのテストケースでは次のような結果が示されました。
同じ指針に基づいてGPT-4上でエージェントを実行すると、劇的に異なる結果が得られます。誤ったアクションを即座に実行して時間を無駄にするのではなく、整然としたツール呼び出しの実行スケジュールを慎重に計画し、それに厳密に従って実行します。より複雑なタスクを実行する場合、2つのモデル間のパフォーマンスの差がさらに大きくなることは容易に想像できます。GPT 3.5は高速ですが、製品ユーザーは明らかにGPT-4の優れた意思決定能力と分析能力を高く評価しています。 注記 これらのテストを通して、私たちは重要な洞察を得ました。エージェントが幻覚を示したり、実行に失敗したりした場合、その状況を非常に注意深く観察し、その原因を特定する必要があるということです。AIエージェントはしばしば一種の怠惰性を示します（おそらく、人間の怠惰性が基盤モデルの学習データに深く学習されていることに起因しているのでしょう）。そのため、不要と判断したツールは容易に呼び出されません。同様に、ツールを呼び出す場合でも、引数の指示を理解していない場合は、多くの場合、手抜きをしたり、必要なパラメータを無視したりします。これらの失敗モードには、豊富な情報が含まれています。AIエージェントは、ACI（エージェント呼び出しインターフェース）がどのように設計されることを期待しているかを実際に伝えています。可能であれば、最も直接的な解決策は、その希望に従い、エージェントのニーズに合わせてACIを調整することです。もちろん、システムプロンプトやツール呼び出し指示を変更することでエージェントの性質に対抗する必要がある場合も少なくありませんが、ACIを調整するだけで解決できる問題については、直接的な変更によって作業を大幅に簡素化できます。 4.4 モデルを微調整してエージェントのパフォーマンスを改善しようとするのは無駄です。モデルの微調整[8]は、特定のアプリケーションドメインでの例を提供することにより、モデルのパフォーマンスを最適化する方法です。現在の微調整方法は、特定のタスクを特定の方法で実行するようにモデルに教えることには優れていますが、モデルの推論能力を向上させるのには効果的ではありません。私の経験では、微調整されたモデルを使用してAIエージェントを駆動すると、実際には推論能力が低下する可能性があります。これは、AIエージェントが「チート」する傾向があるためです。つまり、微調整プロセス中に遭遇した例が常に最適な処理戦略とツール呼び出しシーケンスを表していると誤って信じ、問題について独自に推論するわけではないためです。 注記 微調整は、スイスアーミーポケットナイフの貴重なツールであり続けます。例えば、AIエージェントによる特定のツール呼び出しを処理するために特別に設計された、微調整されたモデルを使用するという効果的なアプローチがあります。特定のデータセットに対するSQLクエリの作成用に特別に微調整されたモデルがあると想像してみてください。AIエージェント（強力な未調整の推論モデル上で動作）は、実行したいSQLクエリをツール呼び出しで表現でき、この要求をSQLクエリ用に特別に微調整されたモデルに委任することで、独立した処理が可能になります。 4.5 製品開発プロセスでは、LangChain や LlamaIndex などの抽象化ツールの使用を慎重に検討する必要があります。モデルへのすべての呼び出し、特に入出力の詳細を完全に制御できる必要があります。このコアとなる制御をサードパーティのライブラリに委ねてしまうと、新規ユーザーのオンボーディングプロセス、問題のデバッグ、ユーザー数の増加、AIエージェントのアクションのログ記録、ソフトウェアの新バージョンへのアップグレード、AIエージェントの行動の背後にある動機の理解など、AIエージェントと連携する必要がある際に、私たちは深く後悔し、不便を感じることになるでしょう。 注記 純粋な製品のプロトタイプ段階にあり、AIエージェントがタスクを完了できるかどうかを確認することが唯一の目的である場合は、お気に入りの抽象化ツールを選択して、すぐに実践を開始することもできます。[9] 4.6 AIエージェントは堀ではないAIエージェントを活用して人間の知識ベースのタスクを自動化または拡張することは大きな可能性を秘めていますが、優れたAIエージェントを構築するだけでは十分ではありません。AIエージェントを市場に投入し、ユーザーにサービスを提供するには、真に効率的な運用を確保するために、AI以外の様々なインフラに多大な投資を行う必要があります。そして、まさにこの点こそが、差別化された競争優位性を生み出すことができるのです。
注記 このリストはスタートアップ企業への正式な要請書[10]と考えてください。リストに記載されている製品要件に基づいて開発された製品は、うまくいけば新たな業界標準や主要コンポーネントとなり、AIエージェントが「物事を次のレベルに引き上げる」のに役立つことが期待されます。 4.7 大規模モデルの進歩が止まると想定しないでください。エージェントを構築する際には、基盤となるプライマリモデルへの過剰なバインディング関数を開発したいという誘惑に常に駆られ、その結果、エージェントの推論能力に対する期待を意図せず低下させてしまうことがあります。この誘惑には注意し、克服することが大切です。プライマリモデルの開発の勢いは止められません。現在の「高速軌道」に永遠にとどまることはないかもしれませんが、その開発速度は歴史上どの技術革命よりもはるかに速いでしょう。顧客は当然のことながら、お気に入りのプライマリモデルで実行できるAIエージェントを選ぶ傾向があります。ユーザーが最も期待しているのは、AIエージェントで最先端かつ強力なモデルをシームレスに体験できることです。例えば、GPT-4oがリリースされた後、私はOpenAI API[11]を使用してわずか15分で製品にGPT-4oを適応させました。異なるモデルプロバイダーに柔軟に適応できることは、間違いなく大きな競争優位性となります。 読んでくれてありがとう！ このブログを楽しんで、新しいことを学んでいただければ幸いです。 パトリック・ドハティ Rasgoの共同創設者兼CTO。AIエージェント、最新のデータスタック、そしてたまにはオヤジジョークなどについて書いています。 終わり 記事内のリンク [1]https://x.com/savvyRL/status/1795882798454288715 [2]https://platform.openai.com/docs/assistants/overview [3]https://docs.anthropic.com/en/docs/tool-use-examples [4]https://docs.cohere.com/docs/command-r-plus [5]https://lexfridman.com/podcast/ [6]https://yale-lily.github.io/spider [7]https://arxiv.org/abs/2405.15793 [8]https://platform.openai.com/docs/guides/fine-tuning/fine-tuningを使用するタイミング [9]https://www.youtube.com/watch?v=O_HyZ5aW76c [10]https://www.ycombinator.com/rfs [11]https://www.loom.com/share/f781e299110e40238d575fa1a5815f12?sid=73bb6158-216d-4de6-b570-881e6a99ebd2 オリジナルリンク: https://medium.com/@cpdough/building-ai-agents-lessons-learned-over-the-past-year-41dc4725d8e5 |
