🐥
GoogleのAIエージェントに関するホワイトペーパー「Agents」をきちんと読む
はじめに
この記事は、GoogleのAIエージェントに関するホワイトペーパー「Agents」を読んで、生成AIエージェントの概念、構成要素、機能、および実装について理解をより深めることを目的としています。
NotebookLMを使って学習した内容を備忘録的にまとめたものです。
この記事を読まなくていい人
以下の質問に答えられる人は読まなくてOK
- 生成AIエージェントの最も基本的な定義は何ですか？
- エージェントとモデルの主な違いは何ですか？
- エージェントの認知アーキテクチャを構成する3つの要素を挙げ、それぞれの役割を説明できますか？
- オーケストレーション層における推論フレームワークの種類と役割は？
- モデルは通常、エージェントの特定の構成設定についてどのように訓練されますか？
- モデルの訓練データだけでは不十分な場合に、ツールはどのようにしてエージェントの能力を拡張しますか？
- ツールについて
- エージェントの将来において重要性を増すであろう2つのアプローチは？
本題
1. 生成AIエージェントの最も基本的な定義は何ですか？
- 生成AIエージェントは、目標を達成するために周囲の状況を把握し、推論を行い、利用可能なツールを使用して実世界に作用するアプリケーション
- 人間の介入なしに独立して行動できる、自律的であることが特徴
2. エージェントとモデルの主な違いは何ですか？
- エージェントはモデルの能力を拡張し、外部世界とインタラクションしたり、より複雑なタスクを自律的に実行したりできるようにする上位の概念
- 主な違い3つ
- 知識の範囲:
- モデル：トレーニングデータにあるものに限定
- エージェント: ツールを介した外部システムとの接続を通じて知識が拡張される
- ツールの利用:
- モデル: ネイティブなツール実装はなし
- エージェントアーキテクチャにツールがネイティブに実装されています
- ロジック層
- モデル: ネイティブなロジック層は実装されていない
- エージェント: ReAct, Chain-of-Thought, Tree-of-Thoughts、またはその他の事前構築されたエージェントフレームワーク（LangChainなど）を使用するネイティブな認知アーキテクチャを持つ
3. エージェントの認知アーキテクチャを構成する3つの要素を挙げ、それぞれの役割を説明できますか？
1. モデル (The model)
- エージェントプロセスの中心的な意思決定者として利用される**言語モデル（LM）**
- ReAct、Chain-of-Thought、Tree-of-Thoughtsなどの命令ベースの推論およびロジックフレームワークに従う
- 外部システムとの接続を通じて知識が拡張される
2. ツール (The tools)
- ツールはエージェントが外部データやサービスと相互作用し、基盤モデル単独の能力を超える幅広いアクションを可能にする
- ツールの種類:
1. Extensions
- エージェントがAPIをシームレスに実行できるようにするツール
- Agent-Sideで実行され、エージェント自身がAPI呼び出しを直接行う
2. Functions
- モデルはFunctionの名前とその実行に必要な引数（パラメータ）を出力しますが、live API call自体は行いません
- Functionの実際のロジックやAPI呼び出しの実行は、エージェントではなくClient-Sideのアプリケーションで行われる
- モデルは実行のためのパラメータを生成するのみ
3. Data Stores
- RAGベースのアプリケーションで広く使用される。RAGはData Storesを活用して、ウェブサイトコンテンツ、構造化データ（PDF、スプレッドシートなど）、非構造化データ（HTML、TXTなど）など、さまざまな種類の外部データから情報を検索し、モデルの知識を拡張することで、より正確で最新の情報に基づいた応答を生成
3. オーケストレーション層 (The orchestration layer)
- オーケストレーション層は、**メモリ、状態、推論、計画**を維持する責任を担う
1. メモリ
- 過去のインタラクションや情報を保持する
2. 状態
- タスクの現在の状況を把握し、次に必要なステップを判断
3. 推論
- 論理的な思考プロセスを経て結論を導き出す
4. 計画
- 推論の結果に基づき、目標達成のために一連の行動ステップやツール使用のシーケンスを組み立てる
4. オーケストレーション層における推論フレームワークの種類と役割は？
- 目的：自律的にタスクを遂行するための認知的な構造とガイダンスを提供すること
- 成り立ち：プロンプトエンジニアリングの延長線上で生まれた
- 種類
1. ReAct
- 「推論 (Reason)」と「行動 (Act)」を組み合わせた思考プロセス戦略を提供するプロンプトエンジニアリングフレームワーク
- エージェントがユーザーからクエリを受け取り（Question）、内部推論を行い（Thought）、その推論に基づいて次に取るべき行動（Action）観測結果（Observation）サイクルを構造化
- 例：
1. ユーザーがエージェントに対して質問や指示（クエリ）を送信
2. エージェントがユーザーのクエリを受けて、ReActフレームワークに基づく処理を開始
3. オーケストレーション層は、中心的な意思決定者であるモデル（LM）に対して以下のReActステップを行わせる
1. Question: 元のユーザーの入力クエリ
2. Thought: モデルが次に何をすべきかについての内部推論
3. Action: モデルが次に取るべき具体的な行動の決定
4. Action input: 実行が確定したツールに渡す引数
5. Observation: 直前の「Action」と「Action Input」を実行した結果として得られる観測結果
6. Final answer: モデルの最終的な回答
2. Chain-of-Thought (CoT)
- 言語モデルの推論能力を引き出すプロンプトエンジニアリングフレームワーク
- 特徴は中間ステップを通じて推論を行う点
- 単に直接的な答えを生成するのではなく、論理的な思考の連鎖をたどることで、より正確で信頼性の高い推論を行う
- 例：
1. Q: 「あなたは300円持っています。120円のお菓子と80円のジュースを買いました。残りのお金はいくらですか？」
2. CoT1 :「まず、買ったお菓子とジュースの合計金額を計算します。」
3. CoT2:「お菓子は120円、ジュースは80円なので、120円 + 80円 = 200円になります。」
4. CoT3: 「次に、持っていたお金から使った合計金額を引きます。」
5. CoT4: 「持っていたのは300円で、使ったのは200円なので、300円 - 200円 = 100円になります。」
3. Tree-of-Thoughts
- CoTをより一般化したプロンプトエンジニアリングフレームワーク
- 単一の思考の連鎖をたどるCoTとは異なり、複数の可能性のある思考パスを並行して検討
- Q: 「家族が喜ぶ献立を作って」
- 思考1（肉じゃが）パス:
- 必要な材料（牛肉、ジャガイモなど）を確認する。
- 冷蔵庫にない材料が多い。スーパーで買う必要あり。
- 思考2（チキンソテー）パス:
- 必要な材料（鶏肉、ハーブ、付け合わせ野菜など）を確認する。
- 冷蔵庫に鶏肉あり。玉ねぎ、人参を付け合わせに
- 思考3...
- 思考4...
5. モデルは通常、エージェントの特定の構成設定についてどのように訓練されますか？
- モデルは通常、エージェントの特定の構成設定（ツール選択、オーケストレーション/推論設定など）について訓練されているわけではない。モデルそのものは「一般的な推論力」を学習しているだけで、- 「ツールをいつ使うか」「順番をどうするか」は、人間が設計・制御・アシストする部分である
- ではどうするか？**エージェントのタスクに合わせてモデルをさらに精緻化することは可能**
- モデルのツール選択能力を高めるための「ターゲット学習」
1. In-context learning (インコンテキスト学習):
- 推論時に汎用モデルにプロンプト、ツール、および数ショットの例が提供されます
- 顧客から特定のレシピ（プロンプト）、いくつかの主要な材料（関連ツール）、そしていくつかの例となる料理（数ショットの例）を受け取り、その限られた情報と一般的な調理知識に基づいて、レシピと顧客の好みに最も近い料理を「その場で」準備する方法
2. Retrieval-based in-context learning (検索ベースのインコンテキスト学習):
- いわゆるRAG。外部メモリから最も関連性の高い情報、ツール、および関連する例を取得する
- さまざまな材料と料理本（例とツール）で満たされた、よくストックされたパントリー（外部データストア）から、材料と料理本を動的に選択し、顧客のレシピと好みにうまく合わせる
3. Fine-tuning based learning (ファインチューニングベースの学習):
- より大規模な特定の例のデータセットを使用してモデルをトレーニング
- 新しい料理や一連の料理を学ぶために学校に戻り（特定の例の大規模なデータセットでの事前トレーニング）、将来の未知の顧客のレシピに、より深い理解を持ってアプローチできるようになる
6. モデルの訓練データだけでは不十分な場合に、ツールはどのようにしてエージェントの能力を拡張しますか？
- モデルは外部世界と直接インタラクションする基本的な能力に欠ける
- 実世界の知識は常に進化している
- ツールは基盤モデルと外部世界との間のギャップを埋めることができる
- 外部システムやデータとのインタラクション
- 特定のタスクの実行
- メール送信、購入 など
- 知識の更なる拡張
- 訓練データの範囲を超えた、動的で最新の情報にアクセス
7. ツールについて
- モデルが中心的な意思決定者として、どのツールを使用するかを決定
- オーケストレーション層がツール使用を含む一連の思考、行動、意思決定のサイクルを管理
- 各種類
1. Extensions
- 外部APIを呼び出すためのラッパー
- APIエンドポイントの使い方を例を用いてエージェントに学習させる
- APIコールを成功させるために必要な引数やパラメーターをエージェントに学習させる
- エージェントはモデルと例を使用して、ユーザーのクエリを解決するのに適したExtensionを動的に選択
- Agent-Sideで実行される
- エージェントがAPIと直接インタラクションし、ライブAPIコールを行う
2. Functions
- ユーザーが定義した関数で、特定のタスクを実行するためにエージェントから呼び出される
- モデルは、Functionとその引数を出力として生成
- モデル自体はライブAPIコールを行わない
- Client-Sideで実行される
3. Data Stores
- 構造化データ（CSVなど）や非構造化データ（PDFやテキスト）を含めてあらゆるデータを格納できる倉庫
- スプレッドシートやPDFなどの追加データを元の形式でエージェントに提供可能
- Data Storeは、このデータをベクトルDBの埋め込みに変換
- エージェントは、これらの埋め込みを使用して、必要な情報を抽出
- ユーザーからのクエリに対して、そのクエリを埋め込みに変換し、ベクトルデータベース内のコンテンツとマッチング（検索）し、関連するコンテンツをテキスト形式で取得
- Agent-Sideで実行される
- ExtensionsとFunctionsの使い分け
1. Extensionsを使う時
- 複数のAPI呼び出しを連続して行う場合
- エージェントは、このAPIからの応答（Observation）をその場で直接受け取り、解釈し、次の行動（例えば、一番安いフライトを特定する、関連するホテルを探すなど）をリアクティブに決定
- APIで完結する場合
- APIにないロジックは実行できない
2. Functionを使う時
- 複雑なビジネスロジックの実行が必要な場合
- 外部API呼び出し後のデータの加工など
- セキュリティまたは認証の制限があり、エージェントがAPIを直接呼び出すことができない場合
8. エージェントの将来において重要性を増すであろう2つのアプローチは？
- エージェントの推論能力が向上するにつれて1、エージェントはますます複雑な問題も解決できるようになる
- 将来的に重要性を増すであろう2つのアプローチ
1. エージェントチェーン（Chain of Agents）
- タスクを複数のステップに分割し、それぞれを専門のエージェントが順番に処理する構造
- **特徴**:
- **直列処理**: 各エージェントが特定のサブタスクを担当し、処理結果を次のエージェントに渡します。
- **解釈性**: 各ステップが明確で、プロセス全体の追跡が容易です。
- **柔軟性**: タスクの変更や追加が比較的容易です。
2. Mixture of Agent Experts（MoAE）
- 複数の専門エージェントが並列に同じタスクに取り組み、その結果を統合して最終的な出力を生成する手法
- **特徴**:
- **並列処理**: 各エージェントが独立してタスクを処理します。
- **専門性の活用**: 各エージェントが特定の分野やスキルに特化しています。
- **統合機構**: ゲーティング関数やアグリゲーターが各エージェントの出力を統合します。
用語集
- エージェント (Agent): 目標達成のために世界を観察し、利用可能なツールを用いて行動するアプリケーション。自律性があり、人間による明示的な指示なしに次の行動を推論できる。
- 認知アーキテクチャ (Cognitive architecture): エージェントの行動、アクション、意思決定を駆動する基礎となるコンポーネントの組み合わせ。
- モデル (Model): エージェントのプロセスにおける中心的な意思決定者として機能する言語モデル (LM)。
- ツール (Tools): 基盤モデルと外部世界との間のギャップを埋め、エージェントが外部データやサービスとインタラクションし、広範なアクションを実行することを可能にするもの。
- オーケストレーション層 (Orchestration layer): エージェントが情報を取り込み、内部推論を行い、その推論に基づいて次の行動または意思決定を通知するという、サイクルを管理するプロセス。
- 推論フレームワーク (Reasoning frameworks): プロンプトエンジニアリングの進展により生まれた、言語モデルの推論と計画を導くための構造。例：ReAct, Chain-of-Thought, Tree-of-Thoughts。
- ReAct: 言語モデルがユーザーのクエリに対して推論 (Reason) し、行動 (Act) するための思考プロセス戦略を提供するプロンプトエンジニアリングフレームワーク。
- Chain-of-Thought (CoT): 中間ステップを通じて推論能力を可能にするプロンプトエンジニアリングフレームワーク。
- Tree-of-Thoughts (ToT): 連鎖的思考を一般化し、言語モデルが一般的な問題解決のための中間ステップとして機能する様々な思考連鎖を探求することを可能にするプロンプトエンジニアリングフレームワーク。
- Extensions: APIとエージェントを標準化された方法で橋渡しし、エージェントが基盤となる実装に関わらずAPIをシームレスに実行できるようにするもの。Agent-Sideで実行される。
- Functions: ソフトウェア開発における関数と同様に、エージェントの世界ではモデルが既知の関数セットを使用し、その仕様に基づいていつ各Functionを使用するか、どのような引数が必要かを決定するもの。Client-Sideで実行される。
- Data Stores: エージェントに、静的なトレーニングデータを超えた、より動的で最新の情報へのアクセスを提供し、モデルの応答が事実に基づき、関連性を保つようにするもの。
- ベクターデータベース (Vector database): データをベクター埋め込みの形で格納するデータベース。Data Storesの実装に用いられる。
- ベクター埋め込み (Vector embeddings): 高次元ベクターの一種、または提供されたデータの数学的表現。
- Retrieval Augmented Generation (RAG): エージェントに様々な形式のデータへのアクセスを与えることで、基盤となるトレーニングデータを超えてモデルの知識の幅と深さを拡張しようとするアプリケーション。
- In-context learning: 推論時に汎用モデルにプロンプト、ツール、および数ショットの例を提供することで、特定のタスクに対してそれらのツールをどのように、いつ使用するかを「その場で」学習させる方法。
- Retrieval-based in-context learning: 外部メモリから最も関連性の高い情報、ツール、および関連する例を取得することで、モデルプロンプトを動的にポピュレーションする手法。
- Fine-tuning based learning: 推論に先立ち、より大規模な特定の例のデータセットを使用してモデルをトレーニングする方法。
- エージェントチェーン（Chain of Agents）: タスクを複数のステップに分割し、それぞれを専門のエージェントが順番に処理する構造
- Mixture of Agent Experts（MoAE）: 複数の専門エージェントが並列に同じタスクに取り組み、その結果を統合して最終的な出力を生成する手法
最後に
AIエージェントやAIを用いたプログラミングについて発信しています。
気が向いたらフォローよろしくお願いします。
しば田 | Programming x AI
Discussion