/w=3840,quality=90,fit=scale-down)
※本記事は、Stanford Webinar「Agentic AI: A Progression of Language Model Usage」の内容を基に作成されています。ウェビナーの詳細情報は https://www.youtube.com/watch?v=kJLiOGle3Lw でご覧いただけます。本記事では、ウェビナーの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのウェビナーをご視聴いただくことをお勧めいたします。
登壇者のInsop Songは、GitHub Nextの主任機械学習研究者です。以前はMicrosoftに勤務し、機械学習と大規模言語モデルを活用してエンジニアリング生産性を向上させることに焦点を当てていました。彼のプロジェクトには、社内のコードとテキストを使用したオープンソースの大規模言語モデルのファインチューニング、文書支援ツールの開発、さまざまなエンジニアリングタスクへのAIの適用などがあります。現在、Stanford OnlineのプロフェッショナルなAIプログラムのコース開発者および講師を務めています。
スタンフォードのAIプログラムについての詳細は https://stanford.io/ai をご覧ください。
1. イントロダクションと概要
1.1. 言語モデルの基本概念
Insop：今日のウェビナーでは、エージェント型AIについて、言語モデルの使用方法の進化という観点からお話したいと思います。まず言語モデルの基本概念から始めましょう。言語モデルとは、入力されたテキストに基づいて次に来る単語を予測する機械学習モデルです。例えば「the students open their」という入力に対して、言語モデルは次に来る可能性が高い単語を予測します。
言語モデルが大規模なコーパスで訓練されていれば、語彙内の各単語について次の単語として出現する確率を生成できます。この例では「books」や「laptops」が他の単語よりも高い確率を持つことがわかります。そして、全文の補完としては「the students open their books」となり、さらに続けて生成したい場合は、これを新たな入力として言語モデルに与え、継続的に次の単語を生成することができます。
Petra：興味深いですね。つまり言語モデルの本質は、与えられた文脈に基づいて次の単語を予測する確率モデルということですね。これが複雑なテキスト生成の基盤になっているわけですね。
Insop：その通りです。この単純な仕組みが、今日私たちが見ている高度な言語応用の基盤となっています。次の単語予測という単純なタスクから、複雑な対話や文書生成まで発展しているのです。
1.2. 言語モデルのトレーニング（事前学習と事後学習）
Insop：言語モデルのトレーニングは大きく分けて、事前学習と事後学習の2つの段階で構成されています。まず事前学習の部分では、インターネットや書籍、その他の公開テキストから収集された大規模なコーパスを使用して、次のトークンや次の単語を予測するという目標で訓練されます。この事前学習段階が完了すると、モデルは入力に対して次に来る単語を予測することにかなり優れるようになります。
しかし、事前学習されたモデルそのままでは使いやすいとは言えません。そこで事後学習のステップが重要になってきます。事後学習には、指示に従うトレーニングと人間のフィードバックによる強化学習（RLHF）が含まれます。この段階では、特定の指示や質問に対して、ユーザーが期待する回答や出力を生成できるようデータセットを準備します。これにより、モデルはより使いやすくなり、特定の質問に対して適切に応答できるようになります。
さらに、人間の好みに合わせてモデルを調整するために、人間のフィードバックによる強化学習という追加のトレーニング方法が使われます。これは報酬の仕組みを使って、人間の好みにモデルを合わせる方法です。
Petra：なるほど。事前学習で基本的な言語能力を身につけ、事後学習でより人間の期待に沿った応答ができるように調整するということですね。指示に従うトレーニングのデータセットはどのような形式なのでしょうか？
Insop：指示データセットのテンプレートを簡単に見てみましょう。これは指示に従うトレーニングフェーズでモデルを訓練するために使用するテンプレートです。ご覧のように、特定の指示が挿入され、そして期待される出力が挿入されます。これがモデルに入力され、モデルは与えられた指示に基づいて出力を生成する部分だけを学習します。これによって、モデルは自然な指示に対して期待通りの応答ができるようになるのです。
1.3. インストラクションデータセットの構造
Insop：ここで指示データセットの構造を詳しく見てみましょう。これは指示に従うトレーニングフェーズで使用するテンプレートの例です。ご覧のように、テンプレートには特定の指示が挿入される部分と、それに対応する期待される出力が挿入される部分があります。
このテンプレートをモデルに与えると、モデルは指示部分を入力として受け取り、期待される出力部分を生成するように訓練されます。つまり、モデルは与えられた指示に基づいて適切な応答を生成することだけを学習するのです。これが指示に従うトレーニングの本質です。
Petra：そのようなテンプレートを使うことで、モデルはどのような指示にも対応できるように汎用的に学習するということですね。実際の例を見せていただけますか？
Insop：はい、例えば「次の文章を要約してください」という指示があったとします。テンプレートにはこの指示と、実際の要約例が含まれます。モデルはこのパターンを学習することで、新しい文章が与えられたときに適切に要約できるようになります。このようにして、さまざまな種類の指示に対する応答を学習していくのです。
このプロセスにより、事前学習段階と事後学習段階の両方を経た言語モデルは、指示に基づいてテキストを生成する能力を持ち、世界知識を活用して簡単に出力を生成できるようになります。現在、これらのモデルは急速に発展しており、AIコーディングアシスタンスやドメイン固有のAIコパイロット、広く知られているChatGPTや関連する会話インターフェースなど、私たちが日常的に利用するさまざまなアプリケーションドメインで使用されています。
2. 言語モデルの使用方法
2.1. API呼び出しの基本
Insop：言語モデルを実際に利用するための方法として、主にクラウドベースのAPI呼び出しがあります。アプリケーションや特定のツールで言語モデルを使用するには、モデルプロバイダーのクラウドベースAPIを呼び出す方法や、小型のモデルであれば、計算資源が制限された環境でもローカルマシンや携帯端末にモデルをホストする方法もあります。
APIコールによる利用とはどういうことかを説明しましょう。言語モデルは入力テキストを受け取り、出力を生成するものです。つまり、指示や質問として自然言語テキストを特定の形式で準備し、モデルプロバイダーにAPIコールを行います。プロバイダーは通常クラウド環境でこれを処理し、出力を生成してAPIコールに応答します。その後、モデルを基盤とするアプリケーションが出力を解析し、そのまま使用するか、さらに追加のLLM APIコールを行って出力を生成することもあります。
Petra：具体的にAPI呼び出しのフローを理解することが重要ですね。入力から出力までのプロセスはシンプルながらも、適切な形式で指示を準備することが成功への鍵と言えますね。
Insop：その通りです。モデルへの入力は自由形式のテキストですので、プロンプトの準備方法、いわゆるプロンプティングは非常に重要です。効果的なプロンプトを準備するためのベストプラクティスがいくつかあります。例えば、明確で詳細な指示を書くことでモデルが望む出力を生成するのに役立ちます。また、スタイルや形式など、見たい形の例をいくつか含めることもできます。さらに、モデルが依拠できるように参照やコンテキストを提供することも重要です。
モデルにすぐに答えるよう求めるのではなく、推論を可能にしたり、思考の連鎖や同様の方法を使ったりして、考える時間を与えることも効果的です。複雑なタスクを一度に求めるのではなく、それらを分解して順序立てて質問することも良い方法です。また、良いエンジニアリング実践として、体系的なトレースとロギングの方法を持つことがあなたの助けになるでしょう。自動評価も常にアプリケーションの進歩を開発するために不可欠です。
2.2. プロンプト設計のベストプラクティス
Insop：言語モデルへの入力は自由形式のテキストですので、プロンプトの準備方法、いわゆるプロンプティングは非常に重要です。効果的なプロンプトを作成するためのベストプラクティスをいくつか紹介します。
まず、明確で詳細な指示を書くことがモデルの望ましい出力生成に役立ちます。モデルはあなたの考えを読むことができないため、何を求めているのかを詳細に記述する必要があります。これは言語モデルを一般的に使用する際に常に有用です。
次に、例を数個含めることも効果的です。つまり、一貫したスタイルの出力を求める場合、モデルに例の入力と期待する出力を提供します。最終的にオリジナルの質問をすると、モデルは入力に基づいて出力を生成します。このfew-shot examplesは、望む出力を生成するのに常に役立ちます。
また、関連するコンテキストと参照を提供することも重要です。これは事実情報に基づくテキスト生成に関連する多くのケースで非常に役立ちます。LLMは知らないトピックや自信のないトピックについて、不正確な出力、いわゆるハルシネーションを生成することがあります。そのような場合、コンテキストや参照を提供することが常に役立ちます。
Petra：プロンプト設計がモデルの出力品質に大きく影響するということですね。特に詳細な指示と具体例の提供が重要なポイントだと理解しました。他にもベストプラクティスはありますか？
Insop：はい、他にも重要なポイントがあります。モデルに考える時間を与えること、つまり直接質問するのではなく、思考のプロセスを踏ませたり、自分なりの解決策を考えさせてから最終的な出力を比較・生成するよう促すことも効果的です。これはChain of Thought（思考の連鎖）としても知られています。
さらに、複雑なタスクを一度に尋ねるのではなく、シンプルな段階に分けてプロンプトを準備することも有効です。シンプルなプロンプトを準備し、出力を生成し、その出力を次の段階のプロンプトに前置きし、以降も同様のプロセスを繰り返します。これは手動で行うことも、次のスライドで見るようにLLMによって自動化することも可能です。各リクエストに対してシンプルで明確なタスクを設定することが良い方法です。
最後に、多くのエンジニアリングアプリケーションと同様に、良いトレースとロギングの方法を持つことが開発やデバッグ、監査に役立ちます。これは言語モデルベースの開発にも同じ原則が適用されます。また、開発の早い段階から自動評価を導入することも非常に役立ちます。質問と回答のペア、つまりグラウンドトゥルースの回答ペアを準備して、生成された出力と比較できるようにする必要があります。
2.3. 明確かつ詳細な指示
Insop：明確で詳細な指示を書くことの重要性についてもう少し詳しく説明しましょう。左側の例を見てください。短いリクエストではなく、詳細に説明することでモデルが求めているものを理解できるようになります。モデルはあなたの考えを読むことができないため、モデルに何を生成してほしいのかを詳細に説明する必要があります。
例えば、単に「要約してください」と言うのではなく、「以下の文章を300単語以内で要約してください。重要なポイントとキーとなる事実に焦点を当て、専門用語を避けて一般読者向けに書いてください」というように詳細に指示することで、モデルは期待に沿った出力を生成しやすくなります。これは言語モデルを一般的に使用する際に常に有用なテクニックです。
Petra：なるほど。詳細な指示は、モデルが特定の要件やニュアンスを把握するのに役立つわけですね。例えば技術文書を要約する場合と、子供向けに説明する場合では、同じ内容でも指示の違いによって全く異なる出力が得られるということですね。
Insop：その通りです。モデルは非常に柔軟ですが、何を求められているかを正確に理解する必要があります。明確な指示がなければ、モデルは一般的な応答を返すことになり、それはあなたの具体的なニーズを満たさない可能性が高いです。特に専門的なタスクや特定の形式、トーンが必要な場合は、その詳細を指示に含めることが重要です。これにより、モデルはあなたの意図に沿った出力を生成する確率が大幅に高まります。
2.4. 少数例（Few-shot examples）の活用
Insop：少数例（Few-shot examples）を含めることも効果的なプロンプト戦略です。これは、モデルに対して期待する入力と出力の例を提供するという方法です。一貫したスタイルの出力が必要な場合、「どのような一貫したスタイルが求められているのか」を示すために例の入力と例の出力を提供し、最後に本来の質問をします。そうすると、モデルはあなたの入力に基づいて期待通りの出力を生成します。
具体的には、例えば製品レビューを特定のフォーマットで書いてほしい場合、まず「これは良い製品レビューの例です」として例を示し、その後で実際にレビューしてほしい製品について尋ねるというアプローチです。これにより、モデルは示された例のスタイルやフォーマットに沿ったレビューを生成します。
Petra：なるほど、実際の例を提供することで、抽象的な指示よりも具体的に期待するアウトプットの形式やスタイルを伝えられるということですね。これは特にフォーマットが重要な場合に効果的そうです。
Insop：その通りです。Few-shot examplesは、望む出力のスタイルや構造を生成するのに常に役立ちます。特に、表形式のデータ生成や特定の文体、専門的なフォーマットなど、明確な構造が必要な場合に非常に効果的です。モデルは例から学習し、同様のパターンを適用できます。これは人間が例から学ぶのと似た原理です。単に「この形式で書いてください」と言うよりも、実際の例を示す方が効果的なのです。
2.5. 関連する文脈と参照の提供
Insop：関連するコンテキストと参照を提供することは、事実情報に基づくテキスト生成に関連する多くのケースで非常に役立ちます。言語モデルは、知らないトピックや自信のないトピックについて、不正確な出力、いわゆるハルシネーションを簡単に生成してしまうことがあります。そのような場合、コンテキストや参照を提供することが常に効果的です。
こちらに、検索拡張生成（RAG）のようなケースで使用できるプロンプトテンプレートの例を示します。「提供された記事に基づいてのみ回答してください」と指示し、関連する参照を代入できるようにしています。「これらの参照に基づいてのみ回答し、モデルが答えを見つけられない場合は、答えが見つからないと言ってください」と続けます。このようにすれば、モデルはあなたの参照に基づいて回答を生成する可能性が高くなります。
Petra：これは特に事実に基づいた正確な情報が必要な場合に重要なテクニックですね。例えば医療や法律、技術的な分野など、正確さが求められる領域で特に有効だと思います。
Insop：おっしゃる通りです。このアプローチは、ハルシネーションを減らし、モデルが確実に提供された情報だけに基づいて回答するようにするために非常に重要です。特に企業のポリシーや製品マニュアル、研究論文など、特定の文書に基づいた回答が必要な場合に効果的です。モデルに「あなたの知識ではなく、この特定の情報源だけを使ってください」と明確に指示することで、より信頼性の高い回答を得ることができます。これは検索拡張生成（RAG）システムの基本的な考え方でもあり、後ほど詳しく説明します。
2.6. モデルに考える時間を与える
Insop：モデルに考える時間を与えることも重要です。つまり、直接質問するのではなく、モデルに思考のプロセスを踏ませたり、自分なりの解決策を考えさせてから最終的に出力を比較・生成するよう促すことも効果的です。これはChain of Thought（思考の連鎖）としても知られています。
例えば、中規模のモデルでは機能しないかもしれない例として、「学生の解答が正しいかどうかを評価してください」と尋ね、問題の説明と最後に学生の解答を提供するケースを考えてみましょう。システムプロンプトや最初のリクエストが単に「正しいか間違っているかを答えてください」と言っているため、モデルは正確な答えを出せないかもしれません。
しかし、同じモデルでも、「まず自分で問題の解決策を考え、それから学生の解決策と比較してください」というようにプロンプトを準備すれば、モデルは自分自身の解決策を生成し、そうすることで元の入力や生成した出力にしっかりと注意を払う機会を持ち、正しい答えに向かうことができます。このように、推論や思考の連鎖は常に望む出力を生成するのに役立ちます。
Petra：つまり、モデルに思考プロセスを明示的に促すことで、より深い理解と正確な回答を引き出せるということですね。これは人間の教育でも使われる「説明しながら学ぶ」手法に似ていますね。
Insop：その通りです。これは認知科学の観点からも理にかなっています。モデルに単に結論だけを求めるのではなく、推論のステップを踏ませることで、モデルは問題をより深く処理し、関連する知識をより効果的に活用できます。特に数学的問題や論理的推論を必要とするタスクでは、思考の連鎖を促すことで驚くほど結果が改善されることがあります。これは単に正確な答えを得るためだけでなく、モデルの推論プロセスを理解するためにも有用です。「なぜそのような答えになったのか」という根拠を見ることができるのです。
2.7. 複雑なタスクの分解
Insop：こちらは恐らくアプリケーションに実装しやすい興味深い方法です。複数のタスクを含む1つのリクエストを尋ねるのではなく、プロンプトを単純で簡単な段階に準備することができます。具体的な実装方法としては、シンプルなプロンプトを準備して出力を生成し、その出力を次の段階のプロンプトに前置きし、さらに出力を生成します。そして再び前の段階の出力を前置きして第3段階で出力を生成するというように進めていきます。最終的に望む出力を生成します。
このように、手動で行うこともできますし、後ほど説明するようにLLMによって自動化することも可能です。各リクエストに対してシンプルで明確なタスクを設定することが良い方法です。例えば、複雑な文書分析タスクを「1.文書を要約する」「2.主要な論点を抽出する」「3.問題点を特定する」「4.解決策を提案する」というように段階的に分解できます。
Petra：なるほど、複雑な問題を単純なステップに分解するという古典的なアプローチですね。これは特に複雑なワークフローを自動化する場合に役立ちそうです。各ステップの出力が次のステップの入力になるという流れが明確ですね。
Insop：その通りです。これは明白ではないかもしれませんが、多くのエンジニアリングアプリケーションや開発と同様に、良いトレースとロギングの方法を持つことが開発やデバッグ、監査に非常に役立ちます。同じ原則が言語モデルベースの開発にも適用されます。ログを追跡することは常に良いプラクティスです。
また、開発の早い段階から自動評価を導入することも非常に役立ちます。そのためには、質問と回答のペア、つまりグラウンドトゥルースの回答ペアを準備して、生成された出力と比較できるようにする必要があります。人間による評価も可能ですが、通常はコストがかかり、時間もかかります。そこで、言語モデルを審査員として使用することもできます。つまり、言語モデルに対して、グラウンドトゥルース出力と比較しながら、モデルが生成した出力を評価するよう依頼し、生成された出力の品質をスコア化できます。
2.8. システム的なトレースとロギング
Insop：これは明白ではないかもしれませんが、多くのエンジニアリングアプリケーションや開発と同様に、良いトレースとロギングの方法を持つことは開発やデバッグ、そして監査のためにも非常に役立ちます。同じ原則が言語モデルベースの開発にも適用されます。ログを追跡することは常に良い習慣です。
具体的には、モデルへの入力プロンプト、モデルからの生の出力、そして処理後の最終結果など、言語モデルとの各やり取りを記録することが重要です。これにより、問題が発生した場合にどの段階で何が起きたのかを特定しやすくなります。また、システムの挙動を理解し、時間の経過とともに改善するためのデータも収集できます。
Petra：システマティックなロギングはプロダクション環境では特に重要ですね。プロンプトの変更がどのように出力に影響するかを追跡したり、エラーパターンを特定したりするのに役立ちますね。何か具体的な実装方法はありますか？
Insop：良い質問です。具体的には、各リクエストに一意のIDを割り当て、そのIDに関連するすべての情報を構造化された方法で保存することをお勧めします。例えば、タイムスタンプ、入力プロンプト、モデルのバージョン、生成された出力、そして最終的なユーザーへの応答などです。これにより、特定のリクエストの全ライフサイクルを追跡できます。
また、定期的にログを分析して、よくある問題やパターンを特定することも重要です。例えば、特定のタイプの質問でモデルが常に問題を抱えている場合、それはプロンプトの改善が必要なサインかもしれません。このようなシステマティックなアプローチは、言語モデルベースのアプリケーションを継続的に改善するための基盤となります。
2.9. 自動評価の重要性
Insop：開発の早い段階から自動評価を導入することも非常に役立ちます。あなたの開発のためには、質問と回答のペア、つまりグラウンドトゥルースの回答ペアを準備して、生成された出力と比較できるようにする必要があります。人間による評価も可能ですが、通常はコストがかかり、時間もかかります。
そこで、言語モデルを審査員として使用する方法があります。つまり、言語モデルに対して、グラウンドトゥルース出力と比較しながら、モデルが生成した出力を評価するよう依頼し、生成された出力の品質をスコア化できます。これにより、現在開発中のアプリケーションに対して評価を活用できます。
これは非常に重要です。なぜなら、言語モデルは継続的かつ急速に改善されており、言語モデルを開発するために使用する方法論やツールも急速に発展しているからです。つまり、明確な評価なしでは、前進したり、モデルを変更したりすることが難しくなります。モデルが急速に発展しているということは、一部のモデルが急速に時代遅れになることも意味し、アプリケーションで使用している言語モデルを変更する必要に迫られる可能性もあります。したがって、最初から良い評価手法を持つことは間違いなく役立ちます。
Petra：自動評価は継続的な改善と品質保証のために不可欠ですね。言語モデルの生態系が急速に変化する中で、一貫した評価フレームワークがあることで、新しいモデルやアプローチを比較検討する際の基準になりますね。
Insop：その通りです。また、シンプルなアイデアですが、多くのアプリケーションに役立つ方法として、入力プロンプトをそのまま処理するのではなく、意図を検出するソフトウェアやモデルを用意して、異なるプロンプトハンドラーに送信することもできます。これはプロンプトルーターとしても知られています。入力クエリのタイプに基づいて、シンプルなプロンプトと一緒にシンプルな言語モデルを使用することができ、これは運用コストの面でも、より適切な出力を生成する面でも役立ちます。そのクエリタイプにより適したモデルとより関連性の高いプロンプトを組み合わせることができるのです。
3. 言語モデルの一般的な制限
3.1. ハルシネーション問題
Insop：利用可能なモデルには、ここに挙げたような制限がまだあります。例えばハルシネーションは広く知られている問題で、モデルは時に、特に計算や他の特定分野に関連する場合、不正確な情報を生成することがあります。これはアプリケーションドメインで避けたい問題です。
ハルシネーションとは、モデルが実際には存在しない情報や、訓練データに含まれていない事実を「創作」してしまう現象です。例えば、存在しない研究論文を引用したり、架空の統計データを提示したりすることがあります。これは特に事実に基づいた正確な情報が必要な領域では重大な問題となります。
Petra：ハルシネーションは確かに大きな課題ですね。特に企業環境や専門分野での利用において、誤った情報が提供されることのリスクは無視できません。どのような状況でハルシネーションが発生しやすいのでしょうか？
Insop：良い質問です。ハルシネーションは特に、モデルが自信を持っていない領域や、訓練データでカバーされていない新しいトピック、また複雑な計算や推論が必要な状況で発生しやすい傾向があります。モデルは「わからない」と言う代わりに、もっともらしい回答を生成しようとすることがあるのです。
また、非常に具体的な事実や日付、数値に関する質問でもハルシネーションが起きやすくなります。このような問題に対処するための手法は後ほど詳しく説明しますが、主に検索拡張生成（RAG）やツールの使用によって、モデルに正確な情報源へのアクセスを提供することで軽減できます。
3.2. 知識のカットオフ
Insop：言語モデルのもう一つの制限として、データセット準備における知識のカットオフがあります。モデルプロバイダーやモデル作成者はデータセットを準備しますが、ある時点でデータセット収集をカットオフし、それを使用する必要があります。そのため、モデルは事前学習データセットの一部として最新の情報やニュースを見ていない可能性があります。
具体的には、例えば2022年9月までのデータで訓練されたモデルは、それ以降に起きた出来事、発表された研究、または開発された技術については知識を持っていません。このカットオフは、新しい情報が常に発生し続ける世界において、モデルの有用性に大きな制約をもたらします。
Petra：これは特に急速に変化する分野や、最新の情報が重要な状況では大きな課題になりますね。例えば、最新の技術動向やニュースに関する質問では、モデルは単純に回答できないことになります。
Insop：おっしゃる通りです。この問題に対処するためには、モデルを定期的に更新するか、あるいは後で説明する検索拡張生成（RAG）のようなアプローチを用いて、モデルに最新の情報源へのアクセスを提供する必要があります。これにより、基本となる言語モデルの知識を拡張し、最新の情報を取り入れることができるようになります。知識のカットオフは避けられない制約ですが、適切な設計によってその影響を最小限に抑えることは可能です。
3.3. 出典の欠如
Insop：もう一つの制限として、出典の欠如があります。モデルは多くの世界知識の質問に答えることができ、そのような一般的な質問に回答できますが、その回答がどの特定のデータソースから導き出されたのかを教えてはくれません。
例えば、歴史的な出来事や科学的事実について質問した場合、モデルは答えを提供できますが、その情報がどの書籍、論文、またはウェブサイトから得られたものなのかを特定することはできません。これは情報の検証や追跡を難しくします。
Petra：これは特に学術的な文脈や、情報源の信頼性が重要な分野では大きな課題ですね。情報が正確であっても、その出典が不明では価値が半減することもあります。
Insop：その通りです。この問題は、モデルが大量のテキストから学習し、その知識を内部的に統合するという訓練方法に起因しています。訓練の過程でモデルは事実と出典の関連付けを明示的に行うわけではないため、後になって「この情報はどこから来たのか」という質問に答えることができません。
この課題に対しては、後で説明する検索拡張生成（RAG）のようなアプローチが役立ちます。RAGでは、モデルが回答を生成する際に使用した特定の文書やソースを明示的に追跡できるため、出典情報を提供することが可能になります。これにより、情報の透明性と信頼性が向上します。
3.4. データプライバシーの問題
Insop：データプライバシーも重要な懸念事項です。モデル作成者は公開されているデータソースを使用してデータセットを準備します。つまり、モデルはあなたの組織や特定のドメインからの専有データセットを見たことがないということです。
これは、企業固有の情報や非公開のドメイン知識に関する質問に対して、モデルが適切に回答できない可能性があることを意味します。モデルは一般的な知識を持っていても、あなたの組織特有のポリシー、プロセス、または専門的なデータについては知識を持っていません。
Petra：これは企業や特定の専門分野でモデルを活用する際の大きな障壁になりますね。特に医療や法律、金融など、専門的かつ機密性の高い情報を扱う分野では重要な課題です。
Insop：おっしゃる通りです。この問題に対処するためには、いくつかのアプローチがあります。一つは、組織固有のデータで基本モデルをファインチューニングすることです。しかし、これには技術的な専門知識と計算リソースが必要になります。
もう一つのアプローチは、後で詳しく説明する検索拡張生成（RAG）です。RAGを使用すると、モデルを再訓練することなく、組織の専有データをモデルに安全に利用させることができます。モデルはクエリに関連する文書を検索し、それらの文書に基づいて回答を生成します。これにより、プライバシーとセキュリティを維持しながら、専門知識へのアクセスが可能になります。
3.5. 限られたコンテキスト長
Insop：限られたコンテキスト長も重要な制約です。これは急速に増加しているものの、常に微妙なバランスが必要です。より長いコンテキストを提供することでモデルにより多くのコンテキスト情報を与えることができますが、それには運用コストやテキスト生成の遅延という代償が伴います。
コンテキスト長とは、モデルが一度に処理できるテキストの量を指します。これは単語やトークンの数で測定されます。初期のモデルでは数百トークンという制限がありましたが、最新のモデルでは数万トークンまで拡張されています。しかし、このコンテキスト窓が長くなればなるほど、処理に必要な計算リソースも増加し、それに伴って応答時間も長くなります。
Petra：コンテキスト長は特に長い文書や複雑な会話を扱う場合に重要な要素ですね。バランスが重要とのことですが、どのようにして最適なコンテキスト長を決定すればよいのでしょうか？
Insop：それは優れた質問です。最適なコンテキスト長は使用ケースによって大きく異なります。例えば、単純な質問応答では短いコンテキストで十分かもしれませんが、法的文書の分析や長い会話の要約など、より複雑なタスクでは長いコンテキストが必要になります。
一般的なアプローチとしては、必要最小限のコンテキストから始め、必要に応じて拡張していくことをお勧めします。また、後で説明する検索拡張生成（RAG）のようなテクニックを使用すると、すべての情報を一度にコンテキストに入れる必要がなくなります。代わりに、クエリに最も関連性の高い情報だけを選択的に取得することができるため、コンテキスト長の制限内でより効率的に情報を処理できます。
4. 制限への対応手法
4.1. 検索拡張生成（Retrieval Augmented Generation: RAG）
Insop：これらの共通の制限に対処するために、検索拡張生成（Retrieval Augmented Generation: RAG）は一つの有効な方法です。RAGは実際の関連参照を使用することでハルシネーションを減らすことができます。また、参照がどこから来ているかを知っているため、引用も可能になります。これにより、アプリケーション開発者やシステム開発者としては、独自の専有データセットやテキストを使用できるシステムを準備することが可能になります。また、関連データのみを選択するため、少ないコンテキスト長で効率的に利用できます。
RAGの仕組みは次のようになります。まず、独自のデータセットやテキストを事前にインデックス化します。これを小さなテキストチャンクに分割し、埋め込みモデルを使用して埋め込み空間に変換し、データベースやベクターデータベースの一部として保存します。その後、リクエストやクエリが来ると、このクエリを埋め込み空間に変換して最近傍検索を行い、トップKの関連情報や関連テキストチャンクを選択します。そしてこれらを前述のスライドで見たようにプロンプトの一部として配置し、モデルにこの参照のみを使用するよう指示します。
これは独自の専有データを利用する良い方法です。同様の方法がAI検索や他のタイプの検索でも使用できます。インデックス付きデータセットを使用する代わりに、ウェブ検索や他のタイプの検索に依存して、インデックスの一部として情報を提供することもできます。
Petra：RAGは非常に強力なアプローチですね。特に企業や組織が独自のデータを活用しながらLLMの機能を拡張したい場合に有効です。ベクトル検索以外にも検索手法はありますか？
Insop：その通りです。検索拡張生成のための方法やアイデアは多数あります。最も一般的に使用される方法は今説明したもので、テキストチャンクを埋め込み空間に変換し、最近傍検索を行う方法です。しかし、他にも多くの方法があります。
例えば、テキストソースから知識グラフを生成し、それを使用してより関連性の高い情報を抽出することもできます。これはグラフRAGとも呼ばれ、その一部です。ただし、様々な方法があるため、あなたのユースケースに適した方法を調査し、それらを活用する必要があるでしょう。
特に専門的な文書や構造化された情報を持つドメインでは、単純なベクトル検索以上の手法が役立つ場合があります。例えば、ハイブリッドアプローチでは、キーワード検索とセマンティック検索を組み合わせることで、より関連性の高い結果を得られることがあります。RAGの実装方法は多様であり、特定のニーズに合わせて最適化できるのが大きな利点です。
4.2. ツール使用（Tool Usage）と関数呼び出し
Insop：ツール使用は、言語モデルの最も広く使用されている形式がテキスト入力とテキスト出力であることを考えると非常に重要です。これは多くのタイプのクエリに答えることができますが、外部から情報を実行したり抽出したりすることはありません。そこで、この機能呼び出しとも呼ばれるツール使用が救済策となります。
この方法により、リアルタイム情報を取得したり、ソフトウェアコードを生成して実際に計算を実行したりすることができます。具体的な例を見てみましょう。AIチャットボットがあり、「サンフランシスコの天気は？」と質問された場合、モデル自体ではその情報を知ることができません。しかし、もしプロンプトの一部として、天気関連の質問をされたら出力を生成し、その出力を解析してAPIコールを行えるような形式で出力するようモデルに事前に指示しておけば、モデルはここに示すような形式で「これはツール使用のケースです」という出力を生成します。
具体的には「get_weather」という関数と、この関数呼び出しへの入力引数として質問された場所を指定します。そうすると、ソフトウェアはモデルからこのテキスト出力を受け取り、解析して、天気プロバイダーに対して実際のAPIコールを行い、天気情報を取得します。その後、再び言語モデルにフィードバックし、モデルはこのAPI結果に基づいてより人間に親しみやすい有用な出力を生成します。
また、場合によってはモデルがソフトウェアコードを生成し、それがすべてのアクティビティを調整しているソフトウェアの一部として、言語モデルの外部のサンドボックスで実行されることもあります。
Petra：これは非常に強力な機能ですね。モデルがテキスト生成だけでなく、外部システムと連携して実世界のタスクを実行できるようになります。具体的な実装例をもう少し詳しく聞かせていただけますか？
Insop：もちろんです。例えば、ユーザーが「私の先週のフィットネスデータを分析して、運動パターンの傾向を教えてください」と尋ねた場合を想像してください。モデル自体はそのデータを持っていませんが、ツール使用によって次のようなプロセスが可能になります。
まず、モデルはこのリクエストを理解し、「get_fitness_data(start_date, end_date)」という関数呼び出しを生成します。システムはこれを解析し、実際にフィットネスAPIを呼び出してデータを取得します。次に、このデータがモデルに戻され、モデルは「analyze_data(fitness_data)」という別の関数呼び出しを生成するかもしれません。これにより、データ分析コードが生成され、サンドボックス環境で実行されます。最終的に、分析結果がモデルに戻され、モデルはユーザーが理解しやすい自然言語の要約を生成します。
このような関数呼び出しの連鎖により、モデルは純粋なテキスト処理の限界を超えて、複雑なワークフローを実行できるようになります。これはエージェント型言語モデルにとって基本的な機能であり、次のセクションで詳しく説明します。
5. エージェント型言語モデル
5.1. エージェント型言語モデルの定義と特性
Insop：エージェント型言語モデルについて、多くの定義が存在し得ます。一つの定義は、環境と相互作用できるというものです。単純な言語モデルの使用法と比較すると、一般的に見られるように、テキスト入力とテキスト出力がありますが、エージェント型言語モデルの使用では、言語モデルが環境と何かを行うことができます。例えばツール使用や検索リクエストを生成することで、環境から、つまり言語モデルの外部から、言語モデルにフィードバックできる情報や出力を生成することができます。
このプロセス全体、つまりコアに言語モデルを持つエージェント型言語モデルは、これを処理し、会話履歴をメモリとして取り込むこともできます。これがエージェント型言語モデルの定義の一つの方法です。
もう一つの見方は、言語モデルエージェントの使用法を「推論できる」「行動できる」と定義することです。これはReAct（推論と行動）とも呼ばれます。推論部分は、Chain of Thoughtのような方法を使用してモデルに推論を促すことができるものです。そして行動部分は、前のスライドで見たような検索やサーチエンジン、電卓の使用によるAPIコール、または天気APIなどの他のタイプのAPIコール、さらにはPythonコードの生成などの方法を用いて、サンドボックス内で実行できます。
推論と行動を組み合わせることで、モデルは単純な入力と出力のタイプの相互作用よりもはるかに複雑なタスクを実行できるようになります。
Petra：この概念は非常に興味深いですね。言語モデルが単なるテキスト生成エンジンから、環境と相互作用できる能動的なエージェントへと進化しているわけですね。この推論と行動のフレームワークについてもう少し詳しく教えていただけますか？
Insop：もちろんです。推論と行動のフレームワークについてもう少し詳しく見てみましょう。推論部分では、求められたタスクを直接実行するのではなく、タスクを分解して計画を立てるようにプロンプトを準備します。つまり、前のスライドで見たようにあなた自身がタスクを分解するのではなく、モデルにタスクを分解して行動計画を立てるよう依頼します。
言い換えると、モデルに計画させるのです。そして、その分解に基づいて、モデルは外部世界から追加情報を抽出または収集するためにAPIコールやツール使用など、さまざまな行動を生成できます。これらすべてをメモリに組み込み、何が起きているかをモデルが把握できるようにし、最終的にそれに基づいて回答を導き出します。
これにより、言語モデルは単に与えられた質問に応答するだけでなく、問題を分析し、必要な情報を収集し、複数のステップを通じて解決策を導き出すような複雑なタスクに対応できるようになります。これは人間の問題解決プロセスにより近い方法であり、より高度で有用な結果をもたらします。
5.2. 推論と行動のフレームワーク
Insop：推論と行動の詳細をもう少し見てみましょう。推論部分では、求められたタスクを直接実行するのではなく、モデルにタスクを分解して計画を立てるようプロンプトを準備します。以前見たスライドのようにあなた自身がタスクを分解するのではなく、モデルにタスクを分解して行動計画を立てるよう依頼します。
言い換えれば、モデルに計画させるのです。そしてその分解に基づいて、モデルは外部世界から追加情報を抽出または収集するためにAPIコールやツール使用などの異なるアクションを生成できます。これらすべてをメモリに入れることで、モデルが何が起きているかを把握し、最終的にそれに基づいて答えを導き出します。
具体的な例を見てみましょう。カスタマーサポートAIエージェントを持っている場合、どのように機能するかを説明します。顧客が「製品Xの返金を受けられますか？」と尋ねた場合、エージェントシステムはこのリクエストタスクを次の4つの異なるアクションに分解します：返金ポリシーを確認する、顧客情報を確認する、製品を確認する、そして最後に何をすべきかを決定する。
各ステップで、言語モデルはAPIコールを生成して情報を収集します。例えば、返金ポリシーの確認では、言語モデルが事前にインデックス化された会社の返金ポリシーに対して検索システムに要求し、そこから情報を抽出して自身のコンテキストに入れることができます。また、顧客の注文情報についても、チャット形式で顧客に直接質問して情報を収集するか、このチャットシステムの設定によってはシステム内で検索することもできます。
製品についても同様のプロセスを行い、情報を収集します。最後に、ポリシーと製品情報、顧客の注文情報に基づいて結論を導き、APIコールとして要求をフォローアップシステムに送信するとともに、返信の下書きを準備します。
Petra：このフレームワークは非常に体系的ですね。エージェントが問題を構造化された方法で分解し、必要な情報を各ステップで収集し、最終的に統合された回答を提供するプロセスが明確に見えます。このような推論と行動の組み合わせは、より複雑なタスクにも対応できるようになるわけですね。
Insop：その通りです。一般的なワークフローとしては、エージェント型言語モデルシステムでは、言語モデルが文書のテストを確認し、外部ツールを呼び出すことで反復的な呼び出しを行います。例えば、特定の事柄について調査したい場合、エージェントにウェブ検索や他の種類の検索を行わせ、それらを要約し続けながら、最終的にあなたやシステムに報告書を作成することができます。
別の例としては、ソフトウェアアシスタントエージェントがあり、特定のタイプのソフトウェアバグの問題について質問すると、このエージェントはその問題を調査し、関連するコードやファイルを収集して確認し、解決策を提案します。また、サンドボックス環境で実行してそのフィックスをテストし、出力を取得して反復的に修正を見つけようとし、最終的にプルリクエストやユーザーまたは開発者への変更を提案することもできます。
これらは、反復的な言語モデル呼び出しによるエージェント形式で言語モデルを使用する方法です。エージェント型言語モデルの使用がより広く使われるようになっている主な理由と違いは、同じモデルであっても、モデルに直接依頼すると処理できないかもしれませんが、このようなエージェント形式やパターンでタスクを設定すれば、モデルはより複雑なタスクを実行できるということです。これがエージェント型言語モデルが境界を押し広げている理由の一つであり、AIエージェントで実行できる複雑なタスクやアプローチできる異なるドメインが増えているのです。
5.3. 具体的なユースケース（カスタマーサポート）
Insop：カスタマーサポートAIエージェントの具体的な例を詳しく見てみましょう。このエージェントがどのように機能するか説明します。顧客が「製品Xの返金を受けられますか？」と尋ねた場合、エージェントシステムはこのリクエストタスクを次の4つの異なるアクションに分解します。
まず、返金ポリシーを確認します。ここで言語モデルは、事前にインデックス化された会社の返金ポリシーに対して検索システムに要求し、そこから情報を抽出して自身のコンテキストに入れることができます。
次に、顧客情報を確認します。この段階では、チャット形式で顧客に直接質問して情報を収集するか、このチャットシステムの設定によってはシステム内で顧客の注文情報を検索することもできます。
三番目のステップでは、製品情報を確認します。ここでも同様の方法で製品に関する詳細情報を収集します。
最後に、収集したすべての情報に基づいて判断を下します。つまり、ポリシーと製品情報、顧客の注文情報に基づいて結論を導き、APIコールとしてフォローアップシステムに要求を送信するとともに、顧客への返信の下書きを準備します。
Petra：この例は非常に分かりやすいですね。エージェントが単に質問に答えるだけでなく、関連する情報を体系的に収集し、ポリシーを適用して最終判断を下すプロセスが見えます。これは人間のカスタマーサポート担当者の思考プロセスに近いですね。
Insop：その通りです。この例は、エージェント型言語モデルがどのように複数のステップを通して複雑な意思決定を行うかを示しています。重要なのは、エージェントが単一の応答を生成するのではなく、問題を分解し、それぞれのコンポーネントに対して特定のアクションを実行し、それらの結果を統合して最終的な解決策を導き出すという点です。このアプローチにより、より正確で説明可能な回答が可能になります。
また、カスタマーサポートの文脈では、顧客の満足度やビジネスポリシーの適用など、複数の目標のバランスを取ることも重要です。エージェントは柔軟に情報を収集し、適切なポリシーを適用しながらも、顧客体験を最適化するように設計されています。
5.4. ワークフローと反復的なLLM呼び出し
Insop：一般的なワークフローとしては、エージェント型言語モデルシステムは基本的に、言語モデルが文書を確認し、外部ツールを呼び出すことで反復的な呼び出しを行います。これがどのように機能するか、いくつかの例を通して説明しましょう。
例えば、特定のトピックについて調査したい場合、エージェントに調査を行わせることができます。エージェントはウェブ検索や他の種類の検索を実行し、それらの情報を継続的に要約しながら、最終的にあなたやあなたのシステムに報告書を提出します。
別の例としては、ソフトウェアアシスタントエージェントがあります。特定のタイプのソフトウェアバグについて質問すると、このエージェントは問題を調査し、関連するコードファイルを収集して確認します。そしてそれらをレビューし、解決策を提案します。さらに、サンドボックス環境でその修正を実行してテストし、出力を取得します。エージェントは反復的にバグの修正を見つけようとし、最終的にプルリクエストや変更点をユーザーや開発者に提案します。
これらが、エージェント形式で言語モデルを使用する方法であり、反復的な言語モデル呼び出しによって実現されています。
Petra：これらの例は非常に興味深いですね。エージェントが継続的にタスクに取り組み、情報を収集し、解決策を練り上げていくプロセスが明確になります。同じ言語モデルでも、エージェントとして使用すると通常の使用よりも複雑なタスクを処理できるということでしょうか？
Insop：その通りです。エージェント型言語モデルの使用がより広く採用されている主な理由の一つがそれです。同じモデルであっても、直接依頼すると処理できない複雑なタスクでも、このようなエージェント形式やパターンでタスクを設定すれば、より複雑なタスクを実行できるようになります。
これがエージェント型言語モデルが境界を押し広げている理由です。AIエージェントで実行できる複雑なタスクやアプローチできる異なるドメインが増えているのです。エージェントパターンは、言語モデルの能力をより効果的に引き出し、複雑な問題解決や継続的なタスク遂行など、単一のLLM呼び出しでは難しかった領域に適用できるようにしています。
人間の問題解決方法に近いこのアプローチは、より自然で効果的な人工知能のパラダイムを示していると言えるでしょう。
6. 実世界でのアプリケーション
6.1. ソフトウェア開発支援
Insop：ここでは実世界でのアプリケーション例を紹介します。まずソフトウェア開発について、コード生成やバグ修正などの分野は、様々な組織で広く研究されています。また、これらのサービスを提供しようとしている企業も増えています。
ソフトウェア開発支援におけるエージェント型モデルの応用は非常に活発な領域です。例えば、コードレビューエージェントは、開発者がプルリクエストを提出した際に、コードの品質、セキュリティの問題、パフォーマンスの最適化などを自動的に分析できます。エージェントはコードベースを調査し、関連するドキュメントを参照し、ベストプラクティスに基づいて改善提案を行うことができます。
Petra：ソフトウェア開発支援は確かにAIエージェントの応用として非常に有望ですね。特にプログラマーの日常的なタスクを自動化することで生産性が大幅に向上しそうです。バグ修正のプロセスはどのように機能するのでしょうか？
Insop：バグ修正のプロセスでは、エージェントは複数のステップを踏みます。まず、バグレポートとエラーメッセージを分析します。次に、エラーに関連するコードファイルとその依存関係を特定し、その部分のコードを検索して調査します。そして問題の根本原因を特定するために、サンドボックス環境でコードを実行し、様々な入力でテストします。
エージェントは修正案を生成し、その修正が実際に問題を解決するかどうかを検証するためにテストを実行します。最適な解決策が見つかれば、適切な形式（例えばプルリクエスト）で修正を提案します。このような反復的なプロセスは、単一のモデル呼び出しでは不可能だったでしょうが、エージェントパターンを使用することで実現可能になります。
これにより、開発者は単純なバグの修正に時間を費やす代わりに、より創造的で複雑な問題に集中できるようになります。
6.2. 研究と分析
Insop：右側にあるもう一つの応用例は、調査と分析です。これは情報を収集し、合成して、ユーザーに要約を提供する方法です。研究と分析の分野では、エージェント型モデルが特に有効です。例えば、特定のトピックについて包括的な調査を行いたい場合、エージェントは次のようなプロセスを実行できます。
まず、エージェントはウェブ検索や学術データベース検索などを使って、関連する情報源を探します。次に、それぞれの情報源からコンテンツを取得し、重要なポイントを抽出します。その後、複数の情報源からの知見を統合し、矛盾点や合意点を特定します。最終的に、調査結果を構造化された報告書として合成します。
このプロセス全体を通じて、エージェントは継続的に情報を評価し、信頼性の高い情報源を優先し、バランスの取れた見方を提供するよう努めます。
Petra：研究と分析の分野では、情報の質や信頼性が特に重要になりますね。エージェントはどのようにして情報の信頼性を評価するのでしょうか？また、専門的な知識が必要な分野での分析はどのように対応するのでしょうか？
Insop：優れた質問です。エージェントは、情報源の権威性（例えば、査読済み学術誌、公式機関のウェブサイトなど）、情報の一貫性（複数の信頼できる情報源による裏付け）、最新性などの要素に基づいて情報の信頼性を評価します。
専門分野での分析については、エージェントはドメイン固有の知識ベースや専門用語集にアクセスし、その分野特有の評価基準を適用できます。例えば医療情報の分析では、エージェントは医学文献データベースを使用し、エビデンスレベルに基づいて情報を評価するよう特別に設計されています。
また、エージェントは自身の信頼レベルを認識し、高度に専門的な内容や不確実性が高い場合には、人間の専門家の確認を求めるように設計することも可能です。これにより、専門知識を持つ人間とAIの効果的な協力が実現します。
6.3. タスク自動化
Insop：タスク自動化は、エージェント型言語モデルの重要な応用分野の一つです。エージェントは反復的で時間のかかるタスクを自動化し、人間の生産性を大幅に向上させることができます。
タスク自動化の具体例としては、例えば電子メール管理があります。エージェントは受信メールを分析し、重要度に応じて分類し、簡単な返信を下書きしたり、会議のスケジューリングなどのアクションを自動的に実行したりできます。また、データ処理や分析タスクでは、エージェントが複数のデータソースから情報を収集し、クリーニングし、分析して、インサイトを抽出するといった一連のプロセスを自動化できます。
Petra：タスク自動化は多くの業界で大きな価値を生み出せそうですね。特に繰り返し行われる業務プロセスがある企業にとっては効率化の可能性が高いと思います。しかし、こうした自動化の導入には課題もあるのではないでしょうか？
Insop：おっしゃる通りです。タスク自動化の導入には確かにいくつかの課題があります。一つは信頼性の問題です。エージェントがタスクを常に正確に実行できるという信頼を構築する必要があります。特に重要な業務プロセスでは、エージェントの判断が間違っていた場合のリスクを慎重に評価する必要があります。
もう一つは、人間とエージェントの責任分担をどう設計するかという問題です。完全な自動化よりも、人間が最終確認や意思決定を行い、エージェントが情報収集や初期処理を担当するハイブリッドアプローチが多くの場合効果的です。
また、プロセスの透明性も重要な課題です。エージェントがどのような判断基準でタスクを実行しているのか、そのロジックを人間が理解できることが、特に意思決定に関わるタスクでは不可欠です。こうした課題に対処しながら、適切な領域でタスク自動化を進めることで、大きな効率化と価値創出が期待できます。
7. エージェント設計パターン
7.1. 計画立案（Planning）
Insop：エージェント型言語モデルを使用するための設計パターンをいくつか紹介します。計画立案は重要です。なぜなら、モデルにタスクを分解して、より単純または明確なタスクにすることを求めることで、言語モデルが後でAPIコールやツール使用を行いやすくなるからです。
計画立案は、エージェントが効果的に機能するための基礎となります。エージェントに複雑なタスクを与えられたとき、まず最初にそのタスクを実行可能な小さなステップに分解する計画を作成させることが重要です。これにより、エージェントは各ステップを順序立てて実行し、必要に応じて途中で修正することができます。
例えば、「新しい企業向けマーケティング戦略を作成してほしい」というような広範な要求に対して、エージェントはまず以下のような計画を立てるかもしれません：
- 業界と市場の調査を行う
- 競合分析を実施する
- ターゲットオーディエンスを特定する
- マーケティング目標を明確にする
- 適切なマーケティングチャネルを選択する
- コンテンツ戦略を開発する
- 予算と資源の配分を計画する
- 結果を測定するためのKPIを設定する
Petra：計画立案はまさにエージェントのワークフローの基礎ですね。人間の問題解決アプローチにも似ていると思います。このようなプランニングは、エージェントがどのように実装するのでしょうか？特別なプロンプト設計が必要ですか？
Insop：はい、計画立案を促すには特定のプロンプト設計が効果的です。例えば、エージェントに次のように指示することができます：「このタスクを実行する前に、まずステップバイステップの計画を作成してください。各ステップは具体的で実行可能であるべきです。計画が完了したら、承認を求める前に計画を見直し、改善してください。」
このようなプロンプトにより、エージェントは実行に移る前にしっかりとした計画を立てるようになります。また、複雑なタスクでは、計画自体を階層的に構成することもあります。主要なステップを特定した後、各ステップをさらに小さなサブタスクに分解するという方法です。
計画立案は単に効率のためだけでなく、エージェントの行動を予測可能で説明可能にするためにも重要です。計画を明示的に作成することで、ユーザーはエージェントが何をしようとしているのかを理解し、必要に応じて介入することができます。
7.2. 振り返り（Reflection）
Insop：リフレクション（振り返り）は実装が簡単で、良いパフォーマンスにつながるパターンです。具体的な例を見てみましょう。例えばプログラミングコードをリファクタリングしたい場合、モデルにすぐに改善するよう求めるのではなく、このパターンを使うと、例に示すように「ここにコードがあります。コードをチェックして建設的なフィードバックを提供してください」とモデルに依頼します。
そして、そのフィードバックを2番目のプロンプトに取り込みます。この例では、「ここにコードとフィードバック（モデル自身から得たもの）があります。それを基にリファクタリングしてください」と指示します。このようなリフレクションの方法は、コードの修正においてより良い出力を生成する可能性が高いです。
Petra：これは非常に興味深いアプローチですね。モデルに自身の出力を評価させることで、より質の高い結果が得られるわけですね。これは他のタイプのコンテンツ生成にも応用できるのでしょうか？
Insop：はい、このリフレクションパターンはコードに限らず、様々なタイプのコンテンツ生成に効果的です。例えば、エッセイや技術文書の作成においても、モデルにまず下書きを生成させ、次にその下書きに対する批評や改善点を指摘させ、最後にそのフィードバックを基に修正版を生成させるという流れが効果的です。
これは人間の思考プロセスに近いアプローチです。私たち人間も、最初の草稿を書いた後に見直し、改善点を特定してから修正を行いますよね。このパターンを使うことで、モデルは単一のステップで生成するよりも、より洗練された出力を生成できます。
特に、モデルが異なる「視点」や「役割」を取ることで、より効果的なリフレクションが可能になります。例えば、最初は「作家」として内容を生成し、次に「編集者」として批評し、最後に再び「作家」として修正するというアプローチです。これにより、単一のモデル内で異なる視点からのフィードバックループが生まれ、出力の質が向上します。
7.3. ツール使用（Tool Usage）
Insop：ツール使用は、前に見たとおりです。モデルにAPIパターンを生成するよう求めることで、実際のコードとしてAPIの関数プロトタイプを使用できるようになります。また、タスクが実際の計算や別の形式に関連する場合は、モデルに出力としてプログラムを生成させ、言語モデルの周りのソフトウェアやソフトウェアのスキャフォールディングが実行できる安全なサンドボックス環境で実行することもできます。そして、実行出力をモデルに戻し、モデルがそれを合成できるようにします。
具体的には、例えばユーザーが「過去3か月の売上データを分析し、トレンドを見つけてください」と要求した場合、エージェントは次のようなツール使用パターンを実装できます。まず、売上データにアクセスするためのAPIコールを生成します（例：get_sales_data(start_date, end_date)）。次に、分析のためのPythonコードを生成し、サンドボックス環境で実行します。そして、分析結果を受け取り、それをユーザーに理解しやすい形式で要約します。
Petra：このアプローチは、言語モデルの能力を大幅に拡張しますね。ただテキストを生成するだけでなく、実際に計算やデータ処理を行い、その結果に基づいて応答できるようになるわけです。安全性の観点から、サンドボックス環境の実装は重要なポイントですね？
Insop：おっしゃる通りです。ツール使用、特にコード実行を含む場合、安全性は最重要事項です。サンドボックス環境は、実行されるコードが他のシステムやデータにアクセスできないよう厳格に制限されています。また、リソース制限（実行時間やメモリ使用量など）も設けられています。
さらに、ツール使用のもう一つの重要な側面は、エージェントがツールの能力と限界を理解していることです。例えば、データベースアクセスツールを使用する場合、エージェントはそのデータベースのスキーマや利用可能なクエリの種類を理解している必要があります。このため、ツールの使い方に関する明確なドキュメントをエージェントに提供することが重要です。
これにより、エージェントは適切なタイミングで適切なツールを選択し、効果的に活用することができます。ツール使用パターンは、エージェントの機能を大幅に拡張し、現実世界のタスクをより効果的に処理できるようにする重要な設計パターンなのです。
7.4. マルチエージェントコラボレーション
Insop：マルチエージェントは複雑なタスクを実装または達成するための興味深い方法です。タスクを分割し、特定のタスク専用の異なるエージェントにそれらのタスクを割り当てることができます。このコンテキストでのエージェントは、単に異なるプロンプトや異なるペルソナとして考えることができます。通常、プロンプトは「あなたは役立つAIエージェントです」という文で始まりますが、これを異なるペルソナや異なるエージェントに変更することができます。また、使用するモデルは同じでも異なってもよく、タスクに基づいて選択できます。
具体的な例を見てみましょう。スマートホームオートメーション用のマルチエージェントシステムを構築する場合、気候制御エージェント、照明制御エージェントなど、さまざまなエージェントを作成できます。これらは、ペルソナを持つ異なるプロンプトを含むソフトウェア部分であり、外部トリガーも処理します。これらは内部で動作し、これらのエージェントを調整するのは、本質的にはソフトスキャフォールディングと組み合わせたモデルプロンプトです。
Petra：マルチエージェントアプローチは、複雑な問題を異なる専門領域に分割するという点で、組織内のチーム構造に似ていますね。各エージェントが特定の役割や専門知識を持ち、全体として協力する仕組みが興味深いです。これらのエージェント間の通信や調整はどのように管理されるのでしょうか？
Insop：優れた質問です。マルチエージェントシステムでは、エージェント間の通信と調整が成功の鍵となります。一般的に、調整エージェント（またはオーケストレーター）が全体のワークフローを管理し、どのエージェントをいつ呼び出すか、そしてそれらの出力をどのように統合するかを決定します。
エージェント間の通信には、主に構造化されたメッセージパッシングが使用されます。各エージェントは特定のフォーマットで出力を生成し、その出力が次のエージェントへの入力として使用されます。また、共有メモリまたは状態を持つこともあり、複数のエージェントがアクセスして情報を追加または取得できます。
具体的な例として、スマートホームシステムでは、ユーザーが「帰宅モードを設定して」と言うと、調整エージェントがこのリクエストを分析し、照明エージェント、温度制御エージェント、セキュリティエージェントにそれぞれ適切な指示を送ります。各エージェントは自分の専門領域で行動し、結果を調整エージェントに報告します。最終的に調整エージェントがすべての行動をまとめ、ユーザーに統合された応答を提供します。
このようなマルチエージェントアプローチにより、単一のモノリシックなエージェントでは難しい複雑な問題を効果的に解決できるようになります。
7.5. 具体的な実装例
Insop：具体的な例として、スマートホームオートメーションのマルチエージェントシステムについてもう少し詳しく説明しましょう。このシステムでは、異なるエージェントを作成できます。例えば、気候制御エージェント、照明制御エージェントなどです。
これらのエージェントはそれぞれ、特定のペルソナを持つ異なるプロンプトを含むソフトウェアコンポーネントです。また、外部からのトリガーも処理します。これらのエージェントは内部で動作し、全体を調整するのは基本的に、ソフトウェアのスキャフォールディングと組み合わせたモデルプロンプトです。
例えば、気候制御エージェントは家の温度センサーからデータを受け取り、ユーザーの好みや時間帯、在宅状況などの要素を考慮して、エアコンや暖房システムの設定を最適化します。照明制御エージェントは、時間、自然光のレベル、ユーザーの活動などに基づいて照明を調整します。
Petra：このマルチエージェントのアプローチは非常に柔軟性がありそうですね。各エージェントが特定のドメインに特化していることで、全体としての複雑さを管理しやすくなりますね。実際のシステムでは、これらのエージェントはどのように連携するのでしょうか？
Insop：実際のシステムでは、これらの専門エージェントを調整するコーディネーターエージェントが存在します。ユーザーがリクエストを行うと（例えば「映画モードにして」など）、コーディネーターはこれを解釈し、必要な各専門エージェントにタスクを割り当てます。
照明エージェントは照明を調光し、気候制御エージェントは快適な温度を設定し、オーディオシステムエージェントはサラウンドサウンドをアクティブ化するかもしれません。各エージェントは自分の専門領域で最適な判断を行い、その結果をコーディネーターに報告します。
このアプローチの利点は、モジュール性と拡張性にあります。新しい家電やシステムが追加された場合、その機能を管理する新しいエージェントを追加するだけで、既存のシステムに統合することができます。また、各エージェントは独自の判断ロジックを持ち、継続的に学習して改善することができるため、時間とともにユーザーの好みをより良く理解するようになります。
8. まとめと質疑応答
8.1. エージェント型言語モデル使用の位置づけ
Insop：ここでまとめに入りたいと思います。エージェント型言語モデルの使用は、既存の言語モデル使用方法の進化や拡張と言えます。単純なケースに使用してきた言語モデルのベストプラクティスのほとんどは、引き続き適用可能です。しかし、検索、ツール使用などの追加の方法や、異なるタイプのプロンプトやワークフローを準備することで、言語モデルをその核として推論や思考のツールとして使用できます。
また、ツール使用や他の検索メソッドを使用して外部世界と相互作用し、これらの結果を組み合わせることで、単純な入力と出力タイプの言語モデル使用ではなく、複雑なタスクを達成することができます。
Petra：このウェビナーを通じて、言語モデルの基本から始まり、その制限、そしてエージェント型アプローチによってどのようにこれらの制限を克服できるかを体系的に見てきましたね。言語モデルの使用が単純なプロンプトと応答から、環境と相互作用できる複雑なシステムへと進化している様子が分かります。質問をいくつか受け付けましょう。
まず、エージェントの評価についての質問があります。LLMをジャッジとして使用する以外に、エージェントを評価するための良い戦略はありますか？エージェントの評価は通常のLLMよりも複雑であるように思われますが、どのように行うことができるでしょうか？
Insop：素晴らしい質問です。コンテキストを簡単に説明すると、LLMをジャッジとして使用することは、モデルが生成した出力をグラウンドトゥルースの答えや何らかの参照情報と比較して評価するために一般的に使用される方法です。これは非常に効果的であり、私たちも実際に使用しています。
最近試してみた方法の一つは、エージェント型のジャッジング方法です。これは、前に見たようなリフレクションパターンを使用します。LLMにジャッジとして一つの質問をすぐに尋ねるのではなく、まずLLMに初期の参照やフィードバックを提供するよう依頼し、次に別のLLM呼び出しや異なるプロンプトを使って「これはあなたのジュニアエンジニアからのフィードバックです。あなたがシニアエンジニアなら、このジュニアエンジニアの評価をあなたが評価している出力とどのように比較しますか？」と尋ねます。
このリフレクションパターンは、単なる一発のLLMジャッジ出力よりも、より良い評価を得るのに役立つことがわかりました。しかし、エージェントパターンを使用して評価を改善するためのより創造的な方法があるかもしれません。評価は本当に、本当に重要だと強調しすぎることはありません。それがあなたの進歩を早めたり、モデルを変更したり、プロンプトの変更など、さまざまなことを助けるからです。
8.2. エージェント評価の方法
Insop：エージェントの評価についての素晴らしい質問をいただきました。まず簡単な文脈をご説明すると、LLMをジャッジとして使用する方法は、モデルが生成した出力をグラウンドトゥルースの回答や何らかの参照情報と比較して評価するために一般的に使用されています。これは非常に効果的な方法であり、私たちも実際にこの手法を活用しています。
最近試してみた一つのアプローチは、エージェント型のジャッジング方法です。これは、先ほど説明したリフレクションパターンを使用します。LLMに単純に一つの質問をすぐに評価させるのではなく、まずLLMに初期の参照とフィードバックを提供するよう依頼します。次に、別のLLM呼び出しや異なるプロンプトを使って「これはあなたのジュニアエンジニアからのフィードバックです。あなたがシニアエンジニアなら、このジュニアエンジニアの評価をあなたが評価している出力とどのように比較しますか？」と尋ねます。
このリフレクションパターンは、単なる一発のLLMジャッジ出力よりも、より質の高い評価を得るのに役立つことがわかりました。しかし、エージェントパターンを使用して評価を改善するためのより創造的な方法もあるかもしれません。
Petra：評価においてリフレクションを使うという考え方は興味深いですね。複数の視点や異なる役割からのフィードバックを組み合わせることで、より包括的な評価が可能になるということですね。他にエージェント評価に特化した手法はありますか？
Insop：評価は本当に、本当に重要だと強調しすぎることはできません。適切な評価があることで、開発の進歩を早めたり、モデルを変更したり、プロンプトの改善など、さまざまな側面で助けになります。
エージェント評価に特化した他の手法としては、タスク完了率や効率性の測定があります。例えば、エージェントが特定のタスクを完了するのにかかるステップ数や時間を測定したり、外部ツールを適切なタイミングで使用しているかを評価したりすることができます。また、エージェントの自己修正能力も重要な評価基準です。エージェントが問題に直面したとき、どのように対処し、回復するかを測定できます。
さらに複雑なエージェントシステムでは、各コンポーネントエージェントの個別評価と、システム全体としての評価を組み合わせることが重要です。最終的には、ユーザー満足度や実際のビジネス成果といった実世界の指標も含めた総合的な評価フレームワークが理想的です。
8.3. 特定用途のためのAIエージェントの拡張
Insop：AIエージェントを特定の用途向けに拡張することについて、多くの質問をいただきました。これは技術的な側面や適用方法に関連する重要なトピックです。
まず、すでにシンプルなタスクがある場合は、言語モデルの単純な使用法を活用するだけで十分です。しかし、より複雑で関与度の高いタスクに直面した場合は、シンプルなエージェント型テストを実験してみることをお勧めします。エージェント型言語モデルの使用方法は多様に定義できますが、より関与度の高いタスクがある場合、反復的な言語モデル呼び出しを行うだけでも、出力を改善できる可能性があります。
実際のアプローチとしては、タスクの性質に依存しますが、単純なケースから始めて、タスクがシンプルな言語モデル使用で解決できないかどうかを検討することをお勧めします。その観点を逆転させて、このタスクがシンプルなケースでは解決できない理由を考えてみてください。まずシンプルな使用法を適用し、その後、異なるパターンを使って改善を試みるのが良いでしょう。
Petra：具体的なアプリケーション開発の観点から見ると、エージェントを特定のドメインに適応させるためのベストプラクティスはありますか？例えば、特定の業界知識や専門用語を理解させるためのアプローチなど。
Insop：これは少し話が横にそれるかもしれませんが、ファインチューニングのケースも同様です。解決したいタスクがある場合、まず既存のモデルを使用してみて、それが意味があるかどうかを確認することをお勧めします。その結果に基づいて、少数のデータサンプルから始めて、どのような結果が得られるかを素早くテストし、そこから進展させていくアプローチが効果的です。
特定のドメインに適応させる場合、階層的なアプローチが有効です。まず基本的なエージェントフレームワークを構築し、次にドメイン固有の知識ベースや用語集を統合します。そして、特定のユースケースに合わせたカスタムツールやAPIを追加していきます。重要なのは、一度にすべてを実装しようとするのではなく、反復的に開発し、各ステップでテストと評価を行うことです。
専門知識を持つユーザーからのフィードバックを早期に取り入れることも非常に重要です。彼らは専門用語や概念が正確に理解され使用されているかを評価する最適な立場にあります。
8.4. 倫理的考慮事項とハルシネーション回避
Insop：倫理的考慮事項やハルシネーションの回避、非倫理的なデータの使用を避ける方法などについて、多くの質問をいただきました。これは非常に大きなテーマです。
はい、確かに言語モデルは確率的生成の性質上、ハルシネーションは常に存在する問題です。多くの人々がこの問題に取り組んでいますが、生成内容に関する懸念もあります。モデルプロバイダー自身が、生成出力をさまざまなカテゴリーでチェックしています。同様に、アプリケーション提供者である皆さん自身も、何らかのガードレールを追加すべきでしょう。
これらのガードレールとは、小型の言語モデルを使用して出力を迅速にチェックしたり、分類器や何らかの基準を用いてフィルタリングすることを意味します。これにより、実際に出力をフィルタリングして問題がないか確認できます。これは最終生成段階で行うことも、クエリが入力される段階で行うこともでき、リクエストされている内容が合理的であるかを確認します。
このアプローチは時に逆効果になることもありますが、企業やビジネスとしては安全側に立つことが重要です。生成される出力だけでなく、リクエストされるクエリも合理的かつ安全なケースであることを確認するべきです。この分野は進化し続けていますが、基本的には出力を分類器やデコーダー型モデルでチェックして確認するというアプローチが有効です。
Petra：倫理的考慮事項と安全性は非常に重要なテーマですね。特に企業環境では、生成AIの出力が信頼でき、安全であることが不可欠です。技術的な側面以外に、組織的なアプローチとしては何が重要でしょうか？
Insop：技術的なソリューションに加えて、組織的なアプローチも非常に重要です。明確なガイドラインとポリシーを策定し、AIシステムが組織の価値観や倫理基準に沿って運用されるようにすべきです。また、AIシステムの使用に関する透明性を確保し、ユーザーに対してシステムの能力と限界を明確に伝えることも重要です。
ハルシネーションのリスクが特に高い重要な意思決定領域では、「人間が最終確認する」プロセスを導入することも効果的です。AIが提案を生成し、人間の専門家がそれを検証するというハイブリッドアプローチです。
最後に、継続的なモニタリングと監査の仕組みを構築することで、問題が発生した場合に迅速に対応できるようにすることが重要です。AIシステムは時間とともに進化するため、定期的な評価と調整が必要です。
8.5. 始め方とオープンソースモデルの推奨
Insop：始め方やおすすめのオープンソースモデルについての素晴らしい質問をいただきました。ここで私が伝えたいメッセージとしては、シンプルに始めて実験し、反復することが重要だということです。また、エージェント型言語モデルは複雑で洗練されたものに聞こえるかもしれませんが、実際には言語モデル使用法の進化と拡張に過ぎません。
始めるにあたっては、多くの言語モデル使用フレームワークやエージェント型フレームワークが利用可能ですが、まずはプレイグラウンド型の環境を使うことをお勧めします。モデルプロバイダーは通常、プロンプトを入力して出力をすぐに確認できるプレイグラウンドを提供しています。これにより、非常に迅速に実験できます。
これに慣れてきたら、APIを使ってあなたのプログラムから呼び出しを行い、何が起きているかを確認しましょう。この方法で、プロンプト作成のベストプラクティスに関する洞察と経験を得ることができます。その上で、自分のコードベースを継続するか、広く利用可能なライブラリを使用するかを判断できます。
つまり、シンプルに始め、まずはプレイグラウンドで作業し、単純なAPIコールを行い、その後、より拡張されたライブラリを使用するか、独自の方法を継続するかを決定するということです。これは言語モデルの使用法とエージェント型言語モデルの使用法の両方に適用されます。多くのエージェント型言語モデルフレームワークも利用可能です。
Petra：実践的なアドバイスをありがとうございます。確かに、複雑なフレームワークから始めるよりも、基本的な理解を深めてから段階的に進む方が良いですね。この分野は急速に進化していますが、今後の進展を追跡するためのリソースについて何かアドバイスはありますか？
Insop：これは難しい質問ですが、素晴らしい質問です。私自身は、この分野で知られている専門家たちをフォローしています。Twitter（現X）やYouTubeチャンネルなどで彼らをフォローし、そこから最新の情報を得て、自分で詳しく調査しています。
良い出発点を見つけることが重要だと思います。参考文献として、エージェント型使用に関するコースや、スタンフォードを含む様々な機関からの優れたコースが含まれています。これらは良い出発点になるでしょう。画面をスクリーンショットして参照することをお勧めします。これらが良い出発点となり、エージェント型使用法やその他の優れたコースが含まれています。
8.6. 最新情報を得るためのリソース
Insop：分野が急速に進化しているため、最新情報を追跡するためのリソースについての質問は本当に難しいですが、素晴らしい質問です。私自身の方法としては、この分野で知られている専門家を選んでフォローしています。主にTwitter（現在のX）やYouTubeチャンネルなどでフォローし、そこから最新情報を得て、自分自身でさらに詳しく調査しています。
良い出発点を見つけることが重要です。ここに表示されている参考文献を参考にしてください。スクリーンショットを撮っておくと良いでしょう。これには、エージェント型の使用法に関するコースやスタンフォードを含む様々な機関からの優れたコースが含まれています。
Petra：リソースについての情報をありがとうございます。確かにこの分野は非常に速いペースで進化していますね。最後にもう一つ質問があります。LLMとエージェントAIの将来について、特に次の1年間で期待できる発展や進化について、個人的な見解を教えていただけますか？
Insop：私の個人的な見解としては、エージェント型AIは今後も発展を続け、より複雑なタスクをこなせるようになると思います。特に複数のエージェントが協力するマルチエージェントシステムや、長期的な計画立案と実行能力の向上が期待されます。また、エージェントのパーソナライゼーションが進み、特定のユーザーや組織のニーズに合わせて調整されるようになるでしょう。
技術的には、エージェントの信頼性と透明性が向上し、より複雑な意思決定プロセスを説明できるようになると思います。また、エージェントがより多様なツールを使いこなせるようになり、実世界のタスクをより効果的に支援できるようになるでしょう。
しかし、これらの進化に伴い、倫理的・社会的な考慮事項もさらに重要になります。エージェントの行動の監督とガバナンスの仕組みが発展することも期待されます。
Petra：素晴らしい洞察をありがとうございます。本日は非常に有益な情報をご共有いただき、ありがとうございました。参加者の皆様にも、貴重な時間を割いてご参加いただきありがとうございました。
Insop：こちらこそ、ありがとうございました。エージェント型AIについて皆さんと共有できて光栄です。今後もこの分野の進化に注目していきましょう。
