第9章: RAGとエージェントを使用したコンテキスト認識推論アプリケーション

この章では、これまで学んだ知識を統合し、コンテキスト認識推論アプリケーションを構築する方法を探ります。そのため、検索拡張生成（RAG）とエージェントについて学びます。また、RAGとエージェントのワークフローの実装と保守を容易にするLangChain、ReAct、PALなどのフレームワークについても紹介します。RAGとエージェントは、多くの場合、生成AIアプリケーションの重要なコンポーネントです。

RAG: 知識の限界を克服する

RAGでは、LLMの知識の限界に対処し、モデルの生成出力の関連性を向上させるために、関連情報をプロンプトのコンテキストに追加します。RAGは、新しいデータがシステムに届くたびにモデルを再トレーニングする必要なく、動的なデータソースをプロンプトコンテキストに組み込むことで、知識のカットオフや幻覚などの課題を効果的に軽減できるため、人気が高まっています。

RAGは、既存のファウンデーションモデルや、生成ユースケースとドメインに特化したファインチューニング済みモデルや人間が調整したモデルに統合できます。

RAGとファインチューニングは併用可能です。互いに排他的ではありません。

RAGの利点と欠点

RAGベースのアーキテクチャの利点は、継続的なファインチューニングを必要とせずに、外部データや動的データにアクセスできることです。これは、継続的なファインチューニングはコストがかかりすぎるため、大きなメリットです。また、RAGベースの手法は、既存のファウンデーションモデルを使用して実装されるため、多くのML専門知識を必要としません。

ただし、RAGベースのアーキテクチャには、データソース接続の管理、外部データソースからのデータ取得、追加のデータ準備、プロンプト拡張などの追加の手順が必要になるという欠点もあります。これらの追加の手順は、レイテンシの増加と全体的なパフォーマンスの低下につながる可能性があります。また、RAGは生成モデルの重みを実際には変更しないことに注意する必要があります。ただし、これは多くの場合望ましいことなので、欠点とは見なされません。

エージェント: 推論と行動の組み合わせ

エージェントは、ファウンデーションモデルを推論エンジンとして使用しながら、ユーザーのリクエスト、ファウンデーションモデル、外部データソース、アプリケーション間でプロンプト完了ワークフローを調整する追加のソフトウェア部品です。

エージェントは、**ReAct（推論と行動）**というフレームワークを利用することが多く、これは、モデルに問題を推論し、解決策を見つけるための行動を決定する方法を示すために、思考の連鎖（CoT）推論を使用してプロンプトを構造化します。行動の一環として、エージェントはRAGワークフローでコンテキスト関連情報を検索したり、アプリケーションAPIを呼び出してタスクを実行したりできます。

LLMの限界

大規模言語モデル（LLM）は、正確な知識と最新の知識に関するいくつかの課題を抱えています。このセクションでは、RAG手法で改善できるLLMの2つの一般的な問題である幻覚と知識のカットオフについて説明します。

幻覚とは、モデルが自信を持って間違った回答を返すことです。たとえば、モデルは「snazzy-fluffykins」という架空の犬種について、誤った情報を含んだ説明を返す可能性があります。

知識のカットオフとは、モデルが最新のデータと一致しない回答を返すことです。すべてのファウンデーションモデルは、トレーニングされた日付を知識のカットオフとして持ち、その日付以降のデータに関する情報は持ちません。たとえば、モデルに最近のNBAチャンピオンを尋ねると、2021年のチャンピオンに関する情報しか返せません。これは、モデルがトレーニングされたデータには、それ以降の情報が含まれていないからです。

RAGのワークフロー

RAGは、LLMにトレーニング中に見ていないデータへのアクセスを提供するためのフレームワークです。RAGにより、LLMベースのアプリケーションは、外部データソースとアプリケーションを利用して、先ほど説明したような知識の限界を克服できます。

RAGは、LLMの「パラメトリックメモリ」に含まれていない追加のデータにLLMをアクセスさせたい場合に役立ちます。これは、組織の内部データストアからの独自情報など、元のトレーニングデータには存在しなかったデータです。モデルにこの情報へのアクセスを許可することで、モデルの完了の関連性を向上させ、幻覚の課題を軽減するのに役立ちます。

知識のカットオフに対処するために、RAGはモデルのトレーニング日付を超えた最新のデータへのアクセスを許可します。この手法により、ドメイン固有の情報を含め、追加の情報をファウンデーションモデルに拡張できます。これは、継続的なファインチューニングなしに可能です。

外部知識ソース

RAGは、モデルに実行時に追加の外部データへのアクセスを提供することで機能します。このデータは、ナレッジベース、ドキュメントストア、データベース、インターネットで検索できるデータなど、さまざまなデータソースから取得できます。

RAGワークフローの詳細

RAGベースのアーキテクチャには、多くの場合、外部知識ソースからのデータ準備ワークフローなど、複数のコンポーネントが含まれます。高いレベルでは、外部知識ソースからのデータ準備と、そのデータを消費アプリケーションに統合する、2つの一般的なワークフローがあります。

データ準備には、データソースの取り込みと、データソースを説明する重要なメタデータの取得が含まれます。これには、利用されている情報ソースの種類に固有のタスクが含まれる場合があります。たとえば、情報ソースがPDFの場合、これらのドキュメントからテキストを抽出する追加のタスクがあります。データが既に使用可能な形式になっている場合は、これが常に必要なわけではありません。ただし、データ準備は、RAGベースのアーキテクチャにおいて、データを取得のために準備するために、多くの場合前提となります。

アプリケーション統合には、入力クエリに基づいて、意味的に最も類似した情報を取得することが含まれます。この情報は、後でRAGワークフローで使用され、LLMを呼び出す前に追加のコンテキストを使用して入力プロンプトを拡張します。

ドキュメントの読み込み

RAGベースのアーキテクチャはさまざまな情報ソースからデータを取得できますが、ここでは、ドキュメントからの情報取得に焦点を当てます。ドキュメントの検索と取得の一般的な実装には、各ドキュメントが埋め込みモデルによって生成された埋め込みベクトルに基づいてインデックス付けされたベクトルストアにドキュメントを保存することが含まれます。埋め込みベクトルには、ドキュメント内のテキストデータの数値表現が含まれています。

各埋め込みは、データの意味的または文脈的な意味を捉えることを目指しています。ここでの考え方は、意味的に類似した概念は、ベクトル空間内で互いに近くに位置するというものです。その結果、情報取得には、入力クエリに基づいて、入力クエリと意味的に類似していると考えられる埋め込みベクトルを見つけることが含まれます。

各埋め込みベクトルは、埋め込みベクトルが作成された元のコンテンツへの参照などの追加のメタデータとともに、ベクトルストアに格納されます。ベクトルストアは、さまざまなアプローチを使用してベクトルをインデックス付けします。

このインデックス付けにより、ドキュメントを迅速に取得できます。ベクトルストアは、推論時に、入力クエリに基づいて外部情報を効率的に取得するために、プロンプトワークフローで使用されます。

チャンク分割

チャンク分割は、ドキュメントのインデックスを作成し、検索を行う際に使用される一般的な手法です。チャンク分割は、ドキュメントを、サイズが一定のテキストのチャンクに分割します。チャンクは、そのチャンク内で意味的に関連していて、意味のあるコンテキストを持つ情報を含む必要があります。チャンク分割には、さまざまな方法があります。たとえば、一定の数のトークンを使用してデータを分割する固定サイズチャンク分割を使用できます。これは、簡単な方法であり、計算効率が高いです。

ドキュメントの取得と再ランキング

ドキュメントからテキストが埋め込まれ、インデックス付けされると、アプリケーションで関連情報を取得するために使用できます。RAGベースのアーキテクチャでは、取得された情報は、後でワークフローで使用され、LLMを呼び出す前に、追加のコンテキストを使用して入力プロンプトを拡張します。

プロンプトの拡張

関連するコンテキストデータが取得されると、RAGベースのワークフローの次のステップは、取得した追加のコンテキストを使用してプロンプトを拡張することです。

RAGのオーケストレーションと実装

RAGは、モデルを外部知識で拡張するためのフレームワークです。この章では、ドキュメントからの外部知識を組み込むRAGワークフローを例に挙げ、データ取得の準備、取得、再ランキング、プロンプト拡張を消費アプリケーションに統合する方法を説明しました。RAGベースのアーキテクチャを実装するには、さまざまな方法があります。このセクションでは、RAGワークフローをオーケストレーションするための特定の手法について説明します。

RAGベースのアーキテクチャをサポートし、RAGを実装するには、データ準備ワークフローなど、複数のコンポーネントが必要です。データ準備ワークフローには、取得のために最適化された形式でデータを読み込み、準備するために必要なタスクが含まれます。さらに、RAGをアプリケーションに統合するためのワークフローも必要です。

LangChain: RAGのオーケストレーションフレームワーク

RAGをアプリケーション統合の一部として実装するには、入力プロンプトを埋め込み、関連するデータを取得し、プロンプトを拡張し、拡張されたプロンプトを使用してLLMを呼び出すなどの手順が複数必要です。これらの手順にはすべて、図9-8に示すように、必要なタスクをオーケストレーションできるコンポーネントが必要です。

LangChainは、コンテキスト認識推論アプリケーションとエンドツーエンドワークフローの開発をサポートするモジュール、インターフェース、統合で構成されています。これらのワークフローには、ドキュメントの読み込み、チャンク分割、さまざまなベクトルストアからの取得が含まれます。

エージェント

ユーザーに旅行に関するアドバイスを提供し、航空券とホテルを予約できる生成AIベースの旅行アプリケーションを考えてみてください。

このためには、ユーザーのリクエスト、ファウンデーションモデル、外部データソースとアプリケーション間でプロンプト完了ワークフローを調整するエージェントと呼ばれる追加のソフトウェア部品が必要です。

エージェントは、ファウンデーションモデルを推論エンジンとして使用します。第2章で学んだ思考の連鎖（CoT）プロンプティングに基づいて、一部のモデルは、Web検索、SQLクエリ、Pythonベースの電卓スクリプトなどのツールによって実行される段階的な行動計画を生成できます。

ReAct: 推論と行動の構造化されたプロンプト

エージェントは、モデルにユーザーのリクエストを推論し、段階的な行動計画を作成する方法を示すために、CoTプロンプトと類似した構造化されたプロンプトを自動的に構築します。エージェントは、外部システムから取得した情報を自動的にプロンプトに拡張して、モデルがよりコンテキスト認識的で関連性の高い完了を生成するのに役立ち、最終的な応答をユーザーに返します。

エージェントの実装は、LangChainエージェントやHugging Face Transformersエージェントなど、多くの一般的なオープンソースライブラリで利用できます。AWSでは、Amazon Bedrockのエージェントなど、フルマネージドサービスを選択することもできます。

PAL: コードインタープリターの接続

CoTでは、モデルの算術やその他の数学演算を実行する能力は制限されています。生成ファウンデーションモデルは、数学を行っているのではなく、プロンプトを完成させるために最も可能性の高い次のトークンを予測しているだけです。

この制限を克服するために、モデルをPythonインタープリターなどの計算に優れたアプリケーションに接続できます。**プログラム支援言語モデル（PAL）**フレームワークは、まさにこれを行います。

PALは、CoT推論を使用して、指定された問題を解決するのに役立つ中間推論ステップでプログラムを生成します。これらのプログラムは、インタープリター（たとえばPythonインタープリター）に渡され、インタープリターはコードを実行し、結果をファウンデーションモデル（FM）に返します。

FMOps: 生成AIプロジェクトライフサイクルの運用

ますます多くの生成モデルが重要なアプリケーションを動かしています。その結果、これらのモデルを本番環境で構築、展開、運用するためのより信頼性が高く、効率的で、繰り返し可能なメカニズムを構築する必要性も高まっています。このセクションでは、生成AIワークロードを効率的かつ確実に配信するための重要な考慮事項を紹介します。

この分野の用語は、まだ確立されていません。GenAIOps、FMOps、LLMOpsなどの用語が使われています。これらはすべて、既存のMLOpsの慣行を基にしています。

実験の考慮事項

実行可能なユースケースが特定された後、最初のステップは通常、既存のファウンデーションモデルを試して、先に進むための最良の候補を特定することです。このステップは、新しい最先端のモデルがリリースされるたびに、ユースケースのパフォーマンスを別のモデルで改善できるかどうかを判断するために、継続的に実行することも重要です。

開発の考慮事項

生成AIプロジェクトライフサイクルのこのステップでは、ターゲットタスクに対してパフォーマンスの高いモデルを作成または拡張することに重点が置かれます。

本番展開の考慮事項

生成AIプロジェクトライフサイクルの初期には、通常、プロトタイプを作成します。しかし、プロトタイプを超えて生成AIアプリケーションを本番環境に展開することを検討する場合、いくつかの重要な考慮事項があります。

まとめ

この章では、LLMを拡張し、幻覚と知識のカットオフというLLMの一般的な知識の限界を軽減するために、RAGという一般的なフレームワークについて説明しました。外部情報ソースへのアクセスを提供することで、これらを軽減します。

また、RAGベースのアーキテクチャをサポートするワークフローと、それらのワークフロー内のステップについて説明しました。LangChainのようなフレームワークは、これらの複雑なワークフローの実装時間を短縮し、RAGやエージェントなどの強力な取得と拡張技術を使用したLLMベースのアプリケーションを迅速に構築、展開、テストすることを可能にすることを学びました。

ファウンデーションモデルは、アプリケーションにおいて、驚くべき推論エンジンとして機能することを学びました。その「知性」を活用することで、エキサイティングで実用的なユースケースを実現できます。

また、エンドツーエンドの生成AIアプリケーションを構築する際に考慮すべき、重要なコンポーネントについても説明しました。これらのアプリケーションの構築に使用できる、AWSのより広範なサービスの例をいくつかご紹介しました。

最後に、生成AIプロジェクトライフサイクル全体で、繰り返し性、信頼性、運用効率を構築するための考慮事項をいくつか簡単に説明しました。