エージェントの能力を決定する 2 つの側面：ツールと計画。
人工知能：現代的アプローチ（1995 年）は、エージェントをセンサーを通じて環境を知覚し、アクチュエーターを通じてその環境に作用するものとして定義しています。
《人工知能：現代的アプローチ》（1995 年）は、エージェントをセンサーを通じて環境を知覚し、アクチュエーターを通じて環境に作用するものとして定義しています。
これは、エージェントの特徴は、その環境と実行できる一連の行動にあることを意味します。ゲーム（例えば、Minecraft、Go、Dota）をプレイするためにエージェントを開発する場合、そのゲームがエージェントの環境です。エージェントがインターネットから文書を取得したい場合、インターネットがその環境です。自動運転車エージェントの環境は、道路システムとその周辺地域です。
AI エージェントが実行できる一連のアクションは、アクセス可能なツールによって強化されます。ChatGPT は、ウェブページを検索し、Python コードを実行し、画像を生成できるエージェントです。RAG システムもエージェントであり、テキストリトリーバー、画像リトリーバー、SQL エグゼキューターがそれらのツールです。
エージェントの環境とそのツールセットの間には強い依存関係があります。 環境は、エージェントが使用できるツールを決定します。例えば、環境がチェスゲームであれば、エージェントが可能な唯一のアクションは有効な手です。しかし、エージェントのツールリストは、その操作可能な環境を制限します。例えば、ロボットの唯一のアクションが泳ぐことであれば、それは水の環境に制限されます。
非エージェントのユースケースと比較して、エージェントは通常、より強力なモデルを必要とします。その理由は 2 つあります：
- 複合エラー：エージェントは通常、タスクを完了するために複数のステップを実行する必要があり、ステップ数が増えるにつれて全体の正確性が低下します。モデルが各ステップで 95％の正確性を持つ場合、10 ステップ後には正確性が 60％に低下し、100 ステップ後には正確性がわずか 0.6％になります。
- より高いリスク：ツールを使用することで、エージェントはより影響力のあるタスクを実行できますが、失敗はより深刻な結果をもたらす可能性があります。
私が一群の人々に自主 AI エージェントについて話すと、必ず誰かが自動運転車について言及します。「もし誰かが車をハッキングしてあなたを誘拐したらどうしますか？」自動運転車の例はその物理的性質から直感的ですが、AI システムは物理的世界に存在しなくても害を及ぼすことができます。
人工知能を利用したいと考える組織は、安全と保障の問題を真剣に考慮する必要があります。しかし、これは AI システムが現実世界で行動する能力を永遠に持つべきではないという意味ではありません。もし私たちが機械を信頼して宇宙に送ることができるなら、いつか安全対策が十分で、自主的な AI システムを信頼できる日が来ることを願っています。さらに、人間も間違いを犯す可能性があります。私個人としては、見知らぬ人に私を運んでもらうよりも、自動運転車を信頼しています。
計画と実行を同じプロンプトで組み合わせることができます。例えば、モデルに段階的に考えるように指示し（思考連鎖プロンプトを使用）、その後、1 つのプロンプトでこれらのステップを実行します。しかし、モデルが 1000 ステップの計画を立てたが、目標を達成できなかった場合はどうでしょう？監視なしで、エージェントは数時間これらのステップを実行し続け、進展がないことに気づくまで時間と API 呼び出しのコストを浪費する可能性があります。
無効な実行を避けるために、計画は実行から切り離すべきです。 エージェントにまず計画を生成させ、計画が検証された後にのみ実行するように要求する必要があります。 計画はヒューリスティックな方法で検証できます。例えば、単純なヒューリスティックな方法は、無効な操作を含む計画を排除することです。生成された計画が Google 検索を行う必要があり、エージェントが Google 検索にアクセスできない場合、その計画は無効です。別の単純なヒューリスティックな方法は、すべてのステップが X を超える計画を排除することです。
計画システムは現在、3 つのコンポーネントを含んでいます：計画を生成するためのもの、計画を検証するためのもの、および計画を実行するためのものです。各コンポーネントをエージェントと見なすと、これはマルチエージェントシステムと見なすことができます。ほとんどのエージェントのワークフローは十分に複雑で、複数のコンポーネントを含むため、ほとんどのエージェントはマルチエージェントです。
タスクを解決するには通常、以下のプロセスが含まれます。反省はエージェントにとって必須ではありませんが、エージェントのパフォーマンスを大幅に向上させることができます。
- 計画生成：このタスクを完了するための計画を立てます。計画は一連の管理可能な行動であるため、このプロセスはタスク分解とも呼ばれます。
- 反省と誤り修正：生成された計画を評価します。計画が不十分であれば、新しい計画を生成します。
- 実行：生成された計画に従って行動します。これは通常、特定の関数を呼び出すことを含みます。
- 反省と誤り修正：行動結果を受け取った後、これらの結果を評価し、目標が達成されたかどうかを判断します。エラーを特定し修正します。目標が達成されていない場合は、新しい計画を立てます。
モデルを計画生成器に変える最も簡単な方法は、プロンプトエンジニアリングを使用することです。例えば、顧客が Kitty Vogue の製品を理解するのを助けるエージェントを作成すると仮定します。このエージェントは、価格で製品を検索し、人気のある製品を取得し、製品情報を取得するための 3 つの外部ツールへのアクセスを提供します。以下は、計画生成のためのプロンプトの例です。このプロンプトは説明目的のみであり、実際の生産環境ではより複雑なプロンプトが必要です。
タスクを解決するための計画を提案してください。あなたは5つのアクションにアクセスできます：
* get_today_date()
* fetch_top_products(start_date, end_date, num_products)
* fetch_product_info(product_name)
* generate_query(task_history, tool_output)
* generate_response(query)
計画は有効なアクションのシーケンスでなければなりません。
例
タスク：「Fruity Fedoraについて教えて」
計画：[fetch_product_info, generate_query, generate_response]
タスク：「先週のベストセラー商品は何でしたか？」
計画：[fetch_top_products, generate_query, generate_response]
タスク：{USER INPUT}
計画：
多くのモデルプロバイダーは、モデルにツール使用機能を提供し、実質的にモデルをエージェントに変えています。ツールは関数です。したがって、ツールを呼び出すことは通常、関数呼び出しと呼ばれます。一般的に、関数呼び出しの動作は次のようになります：
- ツールリストを作成します。モデルが使用したいすべてのツールを宣言します。各ツールは、その実行エントリポイント（例えば、関数名）、パラメータ、およびそのドキュメント（例えば、関数の機能と必要なパラメータ）で説明されます。
- エージェントがクエリに使用できるツールを指定します。異なるクエリには異なるツールが必要な場合があるため、多くの API は各クエリに使用する宣言されたツールのリストを指定することを許可します。
例えば、ユーザーのクエリ「40 ポンドは何キロですか？」が与えられた場合、エージェントはツールlbs_to_kg_toolを使用する必要があると判断し、パラメータ値 40 を渡すかもしれません。エージェントの応答は次のようになります。
response = ModelResponse(
finish_reason='tool_calls',
message=chat.Message(
content=None,
role='assistant',
tool_calls=[
ToolCall(
function=Function(
arguments=**'{"lbs":40}'**,
name='lbs_to_kg'),
type='function')
])
)
計画は、タスクを完了するために必要なステップの概要を示す地図です。地図は異なる粒度レベルを持つことができます。1 年の計画を立てる場合、四半期計画は月次計画よりも高いレベルであり、月次計画は週次計画よりも高いレベルです。
詳細な計画は立てるのが難しいですが、実行は容易です。一方、高レベルの計画は立てるのが容易ですが、実行するのはより困難です。このトレードオフを回避する方法の 1 つは、階層的計画を採用することです。最初に、プランナーを利用して高レベルの計画を生成し、四半期ごとに同じまたは異なるプランナーを使用して月次計画をさらに詳細化します。
より自然な言語を使用することで、計画生成器はツール API の変化に対してより強い適応性を持つことができます。モデルが主に自然言語で訓練されている場合、自然言語の計画を理解し生成するのが得意であり、幻覚が発生する可能性が低くなります。
このアプローチの欠点は、各自然言語アクションを実行可能なコマンドに翻訳するための翻訳者が必要であることです。Chameleon（Lu et al., 2023）はこの翻訳者をプログラム生成器と呼んでいます。しかし、翻訳は計画よりもはるかに簡単で、より弱いモデルでも実行でき、幻覚のリスクも低いです。
制御フローには、順次、並行、if 文、for ループが含まれます。エージェントフレームワークを評価する際には、そのサポートする制御フローを確認してください。 例えば、システムが 10 のウェブサイトをブラウズする必要がある場合、同時に実行できますか？並行実行は、ユーザーが感じる遅延を大幅に減少させることができます。
最良の計画でさえ、成功の可能性を最大化するために評価と調整が必要です。反省はエージェントの運用に厳密に必要ではありませんが、エージェントの成功には不可欠です。
反省と誤り修正は相補的なメカニズムです。反省は洞察を生み出し、修正が必要なエラーを特定するのに役立ちます。 反省は、同じエージェントが自己批評プロンプトを使用して行うことができます。また、特定のスコアを各結果に出力するモデルなど、別のコンポーネントを通じて行うこともできます。
ReAct（Yao et al., 2022）は、推論と行動を交互に行うことがエージェントの一般的なパターンになったと提案しています。Yao らは「推論」という用語を計画と反省を含むものとして使用しています。各ステップで、エージェントはその思考（計画）を説明し、行動を取り、観察結果を分析（反省）するよう求められ、エージェントがタスクを完了したと考えるまで続けます。
マルチエージェント環境で反省メカニズムを実装できます：1 つのエージェントが計画を立てて行動を実行し、別のエージェントが各ステップまたは数ステップ後に結果を評価します。エージェントの応答がタスクを完了できなかった場合、エージェントに失敗の理由と改善方法を反省させることができます。この提案に基づいて、エージェントは新しい計画を生成します。これにより、エージェントはエラーから学ぶことができます。
Reflexionフレームワークでは、反省は 2 つのモジュールに分かれています：結果を評価する分析器と、エラーの原因を分析する自己反省モジュールです。「trajectory（軌跡）」という用語を計画を指すために使用します。各ステップの後、評価と自己反省を経て、エージェントは新しい軌跡を提案します。
計画生成と比較して、反省は比較的実装が容易であり、驚くべきパフォーマンス向上をもたらすことができます。このアプローチの欠点は、遅延とコストです。思考、観察、時には行動が大量のトークンを生成する必要があり、これがコストとユーザーが感じる遅延を増加させます。特に多くの中間ステップを含むタスクの場合です。エージェントがフォーマットに従うように促すために、ReAct と Reflexion の著者はプロンプト内で多くの例を使用しました。これにより、入力トークンの計算コストが増加し、他の情報に利用できるコンテキストスペースが減少します。
より多くのツールはエージェントにより多くの能力を与えます。しかし、ツールが多ければ多いほど、それらを効率的に使用することが難しくなります。 これは、人間が多数のツールを習得する難しさに似ています。ツールを追加することは、ツールの説明を増やすことも意味し、モデルのコンテキストに適応できない可能性があります。
AI アプリケーションを構築する際の他の多くの決定と同様に、ツールの選択も実験と分析が必要です。以下は、決定を下すのに役立ついくつかの事項です：
- 異なるツールセットでのエージェントのパフォーマンスを比較する；
- 消融研究を行い、特定のツールを削除した場合にエージェントのパフォーマンスがどれだけ低下するかを確認する。パフォーマンスを低下させずにツールを削除できる場合は、削除する；
- エージェントが頻繁にエラーを起こすツールを探す。特定のツールがエージェントにとって使いにくい場合、例えば、多くのプロンプトや微調整を行ってもモデルがそれを使用できない場合は、ツールを変更する；
- ツール呼び出しの分布図を描き、どのツールが最も使用され、どのツールが最も使用されていないかを確認する；
異なるモデルとタスクは異なるツール使用パターンを示します。異なるタスクは異なるツールを必要とします。ScienceQA（科学問答タスク）は TabMWP（表形式数学問題解決タスク）よりも知識検索ツールに依存しています。異なるモデルには異なるツールの好みがあります。例えば、GPT-4 は ChatGPT よりも広範なツールセットを選択しているようです。ChatGPT は画像説明に傾く傾向があり、GPT-4 は知識検索に傾く傾向があります。
計画は難しく、さまざまな方法で失敗する可能性があります。最も一般的な計画の失敗パターンはツール使用の失敗です。エージェントは、以下の 1 つまたは複数のエラーを含む計画を生成する可能性があります。
- 無効なツール
例えば、bing_searchを含む計画を生成したが、そのツールはツールリストにありません。 - 有効なツールだが無効なパラメータ。
例えば、lbs_to_kgを呼び出す際に 2 つのパラメータを渡したが、その関数は 1 つのパラメータlbsのみを必要とします。 - 有効なツールだがパラメータ値が不正確。
例えば、lbs_to_kgを 1 つのパラメータlbsで呼び出したが、120 を使用すべきところで 100 を使用してポンドを表現しました。
別の計画の失敗パターンは目標の失敗です：エージェントが目標を達成できないことです。これは、計画がタスクを解決できなかった場合、またはタスクを解決したが制約条件に従わなかった場合に発生します。例えば、モデルにサンフランシスコからインドへの 2 週間の旅行を計画するように依頼したとします。予算は 5000 ドルです。エージェントはサンフランシスコからベトナムへの旅行を計画するか、サンフランシスコからインドへの 2 週間の旅行を計画しますが、費用が予算を大幅に超える可能性があります。
エージェント評価において、しばしば見落とされる一般的な制約は時間です。多くの場合、エージェントがタスクを完了するのにかかる時間はそれほど重要ではありません。タスクはエージェントに割り当てられ、完了後にチェックすればよいからです。しかし、多くの場合、時間が経つにつれてエージェントの役割は低下します。例えば、エージェントに助成金提案を準備するように依頼した場合、助成金の締切後にエージェントが完了した場合、エージェントの助けはあまり役に立ちません。
エージェントは正しいツールを使用して有効な計画を生成することができますが、効率が悪い可能性があります。以下は、エージェントの効率を評価するために追跡したい可能性のあるいくつかの側面です：
- エージェントがタスクを完了するのに平均して何ステップ必要ですか？
- エージェントがタスクを完了するのにかかる平均コストはどれくらいですか？
- 各操作には通常どれくらいの時間がかかりますか？特に時間がかかるまたは高価な操作はありますか？
これらの指標をベースラインと比較できます。ベースラインは別のエージェントまたは人間です。AI エージェントと人間を比較する際には、人間と AI の操作パターンが全く異なるため、人間にとって効率的な行動が AI にとっては非効率的である可能性があることを覚えておいてください。例えば、100 のウェブページにアクセスすることは、一度に 1 ページしかアクセスできない人間にとっては非効率的かもしれませんが、すべてのウェブページに同時にアクセスできる AI エージェントにとっては容易です。