「エンティティ抽出、SQLクエリ、およびAmazon Bedrockを使用したRAGベースのインテリジェントドキュメントアシスタントの強化」

「エンティティ抽出、SQLクエリ、そしてAmazon Bedrockを活用したRAGベースのインテリジェントドキュメントアシスタントの向上」

近年、会話型AIは急速に進化してきました。特に、命令の微調整や人間のフィードバックによる強化学習などのトレーニング技術によって導入された大規模言語モデル（LLMs）のパフォーマンス改善のおかげで、これらのモデルは適切にプロンプトされると、タスク固有のトレーニングデータなしで一貫した会話を行うことができます。しかし、企業固有の質問には十分に一般化することができません。なぜなら、回答を生成するためには、事前トレーニング中に公開データに依存しているからです。このようなデータには、製薬研究、金融調査、顧客サポートなどのドメインで正確な回答を得るために必要な、現代のビジネスで利用可能な内部ドキュメントに含まれる専門知識が欠けていることがよくあります。

専門的なエンタープライズの知識に基づいた議論ができるAIアシスタントを作成するためには、これらのパワフルで汎用性のあるLLMsを、内部のドキュメントの知識ベースに接続する必要があります。この内部のデータソースから情報を取得してLLMの生成コンテキストを豊かにする方法をRetrieval Augmented Generation（RAG）と呼び、Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasksで示されており、これによってドメイン固有の信頼性の高いアシスタントを生成することができます。RAGの人気の背後にある別の動機は、実装の容易さと、Amazon Kendraなどによって提供される成熟したベクター検索ソリューションの存在です（Amazon Kendra launches Retrieval APIやAmazon OpenSearch Serviceなど）。

ただし、セマンティックサーチのある人気のあるRAGデザインパターンは、質問可能なすべてのタイプの質問に答えることができません。特に、複数のドキュメントを対象とした分析的な推論を必要とする質問には対応できません。たとえば、投資会社の来年の戦略を計画している場合を想像してみてください。候補企業の金融結果と潜在的なリスクを分析し比較することは、重要なステップです。このタスクには分析的な推論の質問に答える能力が必要です。たとえば、”過去2年間で収益最高の5社を教えて、主なリスクも特定してください”というクエリは、セマンティックサーチのリターンのうちのいくつかを使用する一方で、他のものは分析の能力を必要とします。

この記事では、3つのパートに分けて、分析的なマルチステップの推論質問に答える能力を持ったインテリジェントなドキュメントアシスタントの設計方法を紹介します。パート1では、RAGデザインパターンとそれが分析的な質問に対する制約について考察し、これらの制約を克服するより柔軟なアーキテクチャを紹介します。パート2では、構造化データの準備に使用されるエンティティ抽出パイプラインにより詳細に深入りします。構造化データは、分析的な質問に答える際の重要な要素です。パート3では、Amazon Bedrock LLMsを使用してそのデータをクエリし、RAGに分析能力を持たせるLLMエージェントを構築する方法を紹介します。これにより、複数のドキュメントにまたがる複雑なドメイン固有の質問に答えることができるインテリジェントなドキュメントアシスタントを構築することができます。

• 言語モデルを使用したドキュメントの自動要約のテクニック
• 「リトリーバル増強生成（RAG）とファインチューニング、どちらを選ぶべきですか？」
• 詳細に説明されたLlama 2：Metaの大型言語モデル！

パート1：RAGの制約と解決策の概要

このセクションでは、RAGのデザインパターンを再確認し、分析的な質問に対する制約について議論し、これらの制約を克服するより柔軟なアーキテクチャを紹介します。

RAGの概要

RAGのソリューションは、2010年以降のランキング問題（例：推薦と検索）や自然言語処理（NLP）タスクで徐々に採用されてきた表現学習や意味的な検索のアイデアに触発されています。

現在、一般的に使用されている手法は次の3つのステップで構成されています：

1. オフラインのバッチ処理ジョブは入力知識ベースからドキュメントを受け取り、それらをチャンクに分割し、それぞれのチャンクの意味を表す埋め込みを作成します。この埋め込みは、Amazon Titanなどの事前トレーニング済みの埋め込みモデルを使用して生成され、これらの埋め込みを入力として使用して意味的な検索インデックスを作成します。
2. リアルタイムで新しい質問に回答する際に、入力質問は埋め込みに変換され、コサイン類似度などの類似性尺度や近傍最近傍アルゴリズムを使用して、最も類似したドキュメントのチャンクを検索して抽出されます。メタデータフィルタリングによって検索の精度も向上させることができます。
3. プロンプトは、システムメッセージとステップ2で抽出された関連するドキュメントのチャンク、および入力質問自体から構成されるコンテキストとの連結から構築されます。このプロンプトは、LLMモデルに提示され、コンテキストから質問の最終的な回答を生成します。

適切な埋め込みモデルを使い、入力ドキュメントのチャンクと入力質問の正確な意味表現を生成できる能力と、効率的な意味検索モジュールを持っている場合、このソリューションは、ドキュメントのデータベースから既存の情報を取得する必要がある質問に答えることができます。例えば、サービスや製品を持っている場合、FAQセクションやドキュメンテーションをインデックス化して、特定の提供に合わせた初期の対話型AIを作成することができます。

RAGに基づく意味検索の制限事項

RAGは、近代の特定ドメインのAIアシスタントや専門知識ベースを構築するための合理的な出発点として不可欠なコンポーネントですが、特に意味検索に基づいた追加を行っている場合、知識ベース内のすべてのドキュメントをスキャン、比較、推論する必要がある質問には答えることができません。

これらの制限を理解するために、再び財務報告書に基づいてどこに投資するかを決定するという例を考えてみましょう。もし私たちがRAGをこれらの報告書と会話するために使うと、”企業Xが2022年に直面したリスクは何ですか？”や”企業Yの2022年の純収益はいくらですか？”などの質問をすることができます。これらの質問のそれぞれに対して、質問の意味をエンコードした埋め込みベクトルが使用され、検索インデックスで利用可能なトップKの意味的に類似したドキュメントのチャンクが取得されます。これは通常、近似最近接近傍ソリューション（FAISS、NMSLIB、pgvector、その他）を使用して行われます。これらのソリューションは検索速度とリコールのバランスを取りながらリアルタイムの性能を達成するように努力しています。

ただし、先述の方法では、”2022年の純収益が最も高いトップ5の企業は何ですか？”といったすべてのドキュメントを対象にした分析的な質問に正確に答えることはできません。

これは、意味的な検索リトリーバルが入力質問に最も類似したKのドキュメントのチャンクを見つけようと試みるからです。しかし、これらのドキュメントには収益の包括的な要約が含まれていないため、”純収益”や”2022年”といった言及を含むドキュメントのチャンクを返すだけで、最も収益が高い企業にフォーカスするという必須の条件を満たすことはありません。これらのリトリーバル結果をLLMに対してコンテキストとして提示すると、誤った回答を生成するか、回答を拒否することがあります。

これらの制限は、意味的な検索が関連するドキュメントを見つけるためにすべての埋め込みベクトルを徹底的にスキャンしないために発生します。代わりに、近似最近接傍法を使用してリトリーバルのスピードを保ちつつ、埋め込み空間をグループに分割してインデックス化することが効率の重要な戦略です。これにより、リトリーバル中に関連する埋め込みを含む可能性のあるグループを迅速に特定することができます。また、KNNのような従来の最近近傍法でも、すべてのドキュメントをスキャンするだけであり、分析的な推論に必要な複雑な比較には適していません。そのため、意味的な検索を行うRAGは、すべてのドキュメントを対象とする分析的な推論を必要とする質問に対応できません。

これらの制限を克服するために、私たちはメタデータとエンティティ抽出、SQLクエリ、LLMエージェントを組み合わせたソリューションを提案しています。詳細は以下のセクションで説明します。

メタデータ、SQL、およびLLMエージェントを使用したRAGの制限の克服

RAGが失敗する質問について詳しく考察し、効果的に答えるために必要な推論プロセスを追跡できるようにしましょう。この分析によって、RAGを補完するための適切なアプローチを見つけることができるはずです。

以下の質問を考えてみましょう: “2022年に最も収益の高いトップ5の企業は何ですか？”

この質問に答えるためには、次の操作が必要です:

1. 各企業の収益を特定する。
2. 各企業の2022年の収益のみを選択する。
3. 収益を降順で並べ替える。
4. トップ5の収益と企業名を取り出す。

通常、これらの分析操作は構造化データを使用して行われ、pandasやSQLエンジンなどのツールを使用します。もしもcompany、revenue、yearのカラムを含むSQLテーブルにアクセスできた場合、次の例のようなSQLクエリを実行することで簡単に質問に答えることができます:

SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;

関連するエンティティに関する情報を含むSQLテーブルに構造化メタデータを格納することで、正しいSQLクエリを書くことでさまざまなタイプの分析質問に答えることができます。これがなぜ私たちのソリューションで、RAGをリアルタイムのSQLクエリングモジュールと組み合わせて使用し、オフラインプロセスで抽出されたメタデータによって生成されるSQLテーブルと対話するのです。

しかし、このアプローチをLLMベースの対話型AIにどのように実装し統合するのでしょうか？

SQL解析的推論を追加するためには、次の3つのステップが必要です：

• メタデータ抽出 – 無構造化ドキュメントからメタデータをSQLテーブルに抽出
• テキストからSQLへの変換 – LLMを使用して入力の質問から正確なSQLクエリを作成
• ツールの選択 – 質問に対してRAGまたはSQLクエリを使用して回答する必要があるかどうかを特定する

これらのステップを実装するために、まず、無構造化ドキュメントからの情報抽出は、LLMがゼロショットまたはフューショット学習を通じて高い精度を達成することを約束する従来のNLPタスクであることを認識します。第二に、これらのモデルが自然言語からSQLクエリを生成する能力は、2020年のリリースのAmazon QuickSight Qで証明されています。最後に、特定の質問に対して適切なツールを自動的に選択することで、ユーザーエクスペリエンスを向上させ、マルチステップ推論を通じて複雑な質問に答えることができるようになります。この機能を実装するために、後のセクションでLLMエージェントに詳しく取り組みます。

要約すると、私たちが提案する解決策は次のコアコンポーネントで構成されています：

• セマンティックサーチリトリーバルによる生成コンテキストの補完
• 構造化メタデータの抽出とSQLによるクエリ
• 質問に回答するために適切なツールを使用できるエージェント

ソリューションの概要

以下の図は、このソリューションの簡略化されたアーキテクチャを示しています。コアコンポーネントの役割と、それらがフルLLMアシスタントの振る舞いを実装するためにどのように相互作用するかを把握するのに役立ちます。番号は、このソリューションを実装する際の操作の順序と一致しています。

実際には、このソリューションを以下の詳細なアーキテクチャに沿って実装しました。

このアーキテクチャでは、バックエンド（5）、データパイプライン（1、2、3）およびフロントエンド（4）が別々に進化できるように、GitHubでの実装を提案しています。これにより、カスタマイズや改善のためのプロダクションでのソリューションの共同作業が簡素化されます。

ソリューションのデプロイ

AWSアカウントにこのソリューションをインストールするには、次の手順を実行してください：

1. GitHubのリポジトリをクローンします。
2. バックエンドのAWS Cloud Development Kit（AWS CDK）アプリをインストールします：
   1. backendフォルダを開きます。
   2. npm installを実行して依存関係をインストールします。
   3. 現在のアカウントとリージョンでAWS CDKを使用したことがない場合は、npx cdk bootstrapでブートストラップを実行します。
   4. スタックをデプロイするには、npx cdk deployを実行します。
3. 必要に応じて、次のようにstreamlit-uiを実行します：
   1. このリポジトリをAmazon SageMaker Studio環境にクローンすることをおすすめします。詳細については、クイックセットアップを使用してAmazon SageMakerドメインに参加を参照してください。
   2. frontend/streamlit-uiフォルダの中で、bash run-streamlit-ui.shを実行します。
   3. デモを開くための次の形式のリンクを選択します：https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/。
4. 最後に、data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynbノートブックで定義されたAmazon SageMakerパイプラインを実行して、入力PDFドキュメントを処理し、LLMアシスタントによって使用されるSQLテーブルとセマンティックサーチインデックスを準備します。

この投稿の残りでは、最も重要なコンポーネントとデザインの選択について説明し、内部知識ベース上で独自のAIアシスタントをデザインする際にあなたにインスピレーションを与えることに焦点を当てます。1番と4番のコンポーネントは理解するのが簡単だと仮定し、コアとなる2番、3番、5番のコンポーネントに焦点を当てます。

パート2：エンティティ抽出パイプライン

このセクションでは、分析的な質問応答に必要な構造化データを準備するために使用されるエンティティ抽出パイプラインにより詳細に掘り下げます。

テキスト抽出

ドキュメントは通常、PDF形式またはスキャンされた画像として保存されます。これらは単純な段落のレイアウトや複雑なテーブルで構成されており、デジタルまたは手書きのテキストを含んでいます。情報を正しく抽出するには、これらの生のドキュメントをプレーンテキストに変換する必要がありますが、元の構造を維持します。これを行うには、デジタルおよび手書きの入力からテキスト、テーブル、フォームの抽出を提供する機械学習（ML）サービスであるAmazon Textractを使用できます。

コンポーネント2では、次のようにテキストとテーブルを抽出します：

1. 各ドキュメントに対して、Amazon Textractを呼び出してテキストとテーブルを抽出します。
2. 以下のPythonスクリプトを使用して、テーブルをpandasのデータフレームとして再作成します。
3. 結果を単一のドキュメントにまとめ、テーブルをマークダウンとして挿入します。

このプロセスは次のフローダイアグラムで概説され、notebooks/03-pdf-document-processing.ipynbで具体的に示されています。

エンティティ抽出とLLMを使用したクエリ

分析的な質問に効果的に答えるためには、文書のナレッジベースから関連するメタデータとエンティティをアクセス可能な構造化データ形式に抽出する必要があります。人気があり、使いやすく、拡張性があるため、SQLを使用してこの情報を格納し、回答を取得することをおすすめします。また、証明された言語モデルが自然言語からSQLクエリを生成する能力があるため、この選択肢も利点となります。

このセクションでは、以下のコンポーネントについて詳しく説明します：

• LLMを使用して非構造化データから構造化データを抽出するバッチプロセス
• 自然言語の質問をSQLクエリに変換し、SQLデータベースから結果を取得するリアルタイムモジュール

次の手順で、分析的な質問をサポートするための関連するメタデータを抽出できます：

1. 抽出する必要がある情報のためのJSONスキーマを定義し、各フィールドの説明とデータ型、および期待される値の例を含めます。
2. 各ドキュメントに対して、JSONスキーマでLLMにプロンプトを与え、関連データを正確に抽出するようにします。
3. ドキュメントの長さがコンテキストの長さを超える場合、LLMとの抽出コストを削減するために、セマンティックサーチを使用して関連するドキュメントのチャンクを取得し、LLMに表示します。
4. JSON出力を解析し、LLMの抽出を検証します。
5. オプションで、結果をCSVファイルとしてAmazon S3にバックアップします。
6. 後でクエリするためにSQLデータベースにロードします。

このプロセスは、テキスト形式のドキュメントをロードし、抽出を実行するPythonスクリプトで実行されるAmazon SageMaker Processingジョブで管理されます。

各エンティティのグループごとに、情報抽出タスクの明確な説明を含み、期待される出力を定義し、関連するドキュメントのチャンクをコンテキストとして含むJSONスキーマを動的に構築します。また、フューショット学習による抽出パフォーマンスの向上のために、入力と正しい出力のいくつかの例を追加します。これは、notebooks/05-entities-extraction-to-structured-metadata.ipynbで示されています。

パート3：Amazon Bedrockを使用して代理文書アシスタントを構築する

このセクションでは、Amazon Bedrock LLMを使用してデータをクエリし、RAGを分析能力で強化するLLMエージェントを構築する方法を示します。これにより、複数のドキュメント間で複雑なドメイン固有の質問に答えることができるインテリジェントなドキュメントアシスタントを構築できます。このパートで説明されているエージェントとツールの具体的な実装については、GitHubのLambda関数を参照してください。

SQLクエリを作成し、分析的な質問に答える

抽出された関連エンティティを含む構造化されたメタデータストアとSQLデータベースにクエリを実行する方法がわかったので、入力された自然言語の質問から正しいSQLクエリを生成するにはどうすればよいでしょうか？

現代のLLMはSQLを生成する能力に優れています。たとえば、Anthropic Claude LLMを使用してAmazon BedrockからSQLクエリを生成するように依頼すると、妥当な回答が表示されます。ただし、より正確なSQLクエリを生成するためには、いくつかのルールに従う必要があります。これらのルールは、幻覚や構文エラーを減らすために特に複雑なクエリに対して重要です。

• プロンプト内でタスクを正確に説明する
• プロンプト内にSQLテーブルのスキーマを含め、各列とそのデータ型を説明する
• LLMに既存の列名とデータ型のみを使用するよう明示的に指示する
• いくつかのSQLテーブルの行を追加する

また、生成されたSQLクエリをlinter（例：sqlfluff）を使用して書式を修正したり、sqlglotといったパーサーを使用して構文エラーを検出しクエリを最適化したりすることもできます。さらに、パフォーマンスが要件を満たさない場合は、いくつかの具体例をプロンプト内に提供することで、モデルを少ないトレーニングデータでより正確なSQLクエリを生成するように誘導することもできます。

実装の観点からは、AWS Lambda関数を使用して次のプロセスを組織します：

1. 入力質問を使用してAmazon BedrockのAnthropic Claudeモデルを呼び出し、対応するSQLクエリを取得します。ここでは、LangChainのSQLDatabaseクラスを使用して関連するSQLテーブルのスキーマの説明を追加し、カスタムプロンプトを使用します。
2. SQLクエリを解析し、検証し、Amazon Aurora PostgreSQL互換エディションデータベースで実行します。

このソリューションの一部のアーキテクチャは、次の図で示されています。

SQLインジェクション攻撃を防ぐためのセキュリティ考慮事項

SQLデータベースへのクエリを許可するため、AIアシスタントがセキュリティ上の脆弱性を導入しないようにする必要があります。この目的を達成するため、以下のセキュリティ対策を提案します。

• 最小特権IAMアクセス許可を適用する – SQLクエリを実行するLambda関数に対するAWS Identity and Access Management（IAM）ポリシーとロールを使用し、最小特権の原則に従います。この場合、読み取り専用アクセスを許可します。
• データアクセスを制限する – 情報漏洩攻撃を防ぐために、最小限のテーブルと列にのみアクセス権を付与します。
• モデレーションレイヤーを追加する – プロンプトインジェクションの試みを早期に検出し、システム全体に拡散させないようにするために、モデレーションレイヤーを導入します。ルールベースのフィルタ、既知のプロンプトインジェクション例のデータベースとの類似性マッチング、またはML分類器の形式を取ることができます。

シーマンティック検索リトリーバルによる生成コンテキストの拡張

私たちが提案する解決策は、コンポーネント3でシーマンティック検索を使用したRAGです。これを実装するためには、Amazon Bedrockのためのナレッジベースを使用することができます。さらに、Amazon Kendra検索API、Amazon Kendra検索APIなど、RAGを実装するためのさまざまなオプションがあります。

この解決策では、SQLクエリとベクトル検索の両方が必要なため、Amazon Aurora PostgreSQLとpgvector拡張機能を使用することに決めました。したがって、次のアーキテクチャでシーマンティック検索RAGコンポーネントを実装します。

前述のアーキテクチャを使用して質問に回答するプロセスは、2つの主要な段階で行われます。

まず、オフラインバッチプロセスとして、SageMaker Processingジョブとして実行される次のようにしてシーマンティック検索インデックスを作成します：

1. 定期的にまたは新しいドキュメントを受け取ると、SageMakerジョブが実行されます。
2. Amazon S3からテキストドキュメントをロードし、オーバーラップするチャンクに分割します。
3. 各チャンクについて、Amazon Titan埋め込みモデルを使用して埋め込みベクトルを生成します。
4. PGVectorクラスを使用して、埋め込みとそのドキュメントチャンクとメタデータをAmazon Aurora PostgreSQLに取り込み、すべての埋め込みベクトルでシーマンティック検索インデックスを作成します。

次に、リアルタイムで、新しい質問ごとに次のように回答を構築します：

1. 質問は、Lambda関数で実行されるオーケストレータによって受け取られます。
2. オーケストレータは、同じ埋め込みモデルで質問を埋め込みます。
3. PostgreSQLのシーマンティック検索インデックスから上位K個の関連ドキュメントチャンクを取得します。オプションでメタデータフィルタリングを使用して精度を向上させることもあります。
4. これらのチャンクは、LLMのプロンプトに入力質問と一緒に動的に挿入されます。
5. プロンプトはAmazon BedrockのAnthropic Claudeに提示され、利用可能なコンテキストに基づいて入力質問に回答するように指示します。
6. 最後に、生成された回答がオーケストレータに送信されます。

推論と行動を行うことができるエージェント

これまでの投稿では、RAGまたは分析的な推論を必要とする質問を別々に扱う方法について説明しました。しかし、多くの現実世界の質問では、最終的な回答にたどり着くために、場合によっては複数の推論ステップを経て、両方の機能が必要です。これらのより複雑な質問をサポートするために、エージェントの概念を導入する必要があります。

LLMエージェント（Amazon Bedrockのエージェントなど）は、現在のコンテキストを使用してLLMを推論および適応させ、オプションリストから適切なアクションを選択することができる有望な解決策として最近登場しています。 LLM Powered Autonomous Agentsで議論されているように、LLMエージェントをサポートするための複数のプロンプティング戦略とデザインパターンがあります。

そのようなデザインパターンの一つがReason and Act（ReAct）であり、ReAct: Synergizing Reasoning and Acting in Language Modelsで紹介されています。ReActでは、エージェントは質問としての目標を入力として受け取り、それに答えるために不足している情報のピースを特定し、利用可能なツールの説明に基づいて情報を収集するための適切なツールを反復的に提案します。特定のツールから回答を受け取った後、LLMは、完全な回答に必要な情報をすべて持っているかどうかを再評価します。必要な情報がない場合、さらに推論ステップを実行し、他のツールを使用して情報を収集します。最終的な回答が準備できるか、制限に達するまで、このプロセスを繰り返します。

次のシーケンス図は、「過去2年間で最高の収益を上げた上位5社を教えてください。また、最も上位の企業に関連するリスクを特定してください」という質問に対してReActエージェントがどのように機能するかを説明しています。

このアプローチをPythonで実装する詳細は、カスタムLLMエージェントで説明しています。私たちのソリューションでは、以下に示す部分アーキテクチャでエージェントとツールが実装されています。

入力された質問に回答するために、AWSのサービスを以下のように使用します：

1. ユーザーはUIを介して質問を入力し、Amazon API GatewayでAPIを呼び出します。
2. API Gatewayは質問をエージェント実行者を実装したLambda関数に送信します。
3. エージェントは、利用可能なツールの説明、ReActの指示形式、入力質問を含むプロンプトを使用してLLMを呼び出し、次のアクションを解析して完了させます。
4. アクションには、使用するツールとアクションの入力内容が含まれています。
5. ツールとしてSQLを使用する場合、エージェント実行者はSQLQAを呼び出して質問をSQLに変換し実行します。その後、結果をプロンプトに追加し、元の質問に答えることができるか、さらにアクションが必要かをLLMに再度呼び出して確認します。
6. 同様に、使用するツールがセマンティックサーチである場合、アクションの入力内容が解析され、PostgreSQLのセマンティックサーチインデックスから取得に使用されます。結果をプロンプトに追加し、LLMが答えられるか、別のアクションが必要かを確認します。
7. 質問に回答するために必要なすべての情報が利用可能になったら、LLMエージェントは最終的な回答を作成してユーザーに送信します。

さらなるツールでエージェントを拡張することができます。GitHubで入手可能な実装では、前述のSQLエンジンとセマンティックサーチツールに加えて、検索エンジンや電卓を追加する方法を示しています。会話履歴を保存するために、Amazon DynamoDBテーブルを使用しています。

これまでの経験から、成功するエージェントのための以下の要素が重要であることを確認しています：

• ReAct形式で推論が可能な下位LLM
• 利用可能なツールの明確な説明、使用するタイミング、入力引数の説明、および入力と期待される出力の例
• LLMが従う必要のあるReAct形式の明確な概要
• LLMエージェントが使用するための適切なツール
• LLMエージェントの応答から正しく出力を解析すること

コストを最適化するために、最も一般的な質問とその回答をキャッシュし、定期的にこのキャッシュを更新して、下位LLMへの呼び出しを減らすことをおすすめします。例えば、先述のように最も一般的な質問でセマンティックサーチインデックスを作成し、新しいユーザーの質問を先にインデックスと照合してからLLMを呼び出すことができます。他のキャッシュオプションを探索するには、LLMキャッシュ統合を参照してください。

ビデオ、画像、音声、3Dファイルといった他のフォーマットのサポート

この解決策は、画像、ビデオ、音声、CADやメッシュファイルのような3Dデザインファイルといったさまざまな情報のタイプにも適用することができます。これには、ファイルのコンテンツをテキストで説明するための確立されたMLの技術を使用し、それを前述のソリューションに取り込む必要があります。このアプローチにより、これらの多様なデータタイプに対してQAの対話を行うことができます。例えば、画像、ビデオ、音声コンテンツのテキストの説明を作成することでドキュメントデータベースを拡張することができます。また、これらのフォーマット内の要素の分類やオブジェクト検出によってプロパティを特定することにより、メタデータテーブルを強化することもできます。この抽出されたデータがメタデータストアまたはドキュメント用のセマンティックサーチインデックスにインデックスされた後、提案されたシステムの全体的なアーキテクチャは大部分が一貫したままです。

結論

この投稿では、LLMsをRAGデザインパターンと組み合わせて利用することが、特定のドメイン向けAIアシスタントの構築には必要だが、ビジネス価値を生み出すためには十分ではないことを示しました。そのため、私たちはRAGデザインパターンをエージェントとツールの概念と組み合わせることを提案しました。ツールの柔軟性により、従来のNLP技術と最新のLLM機能の両方を使用して、情報の検索やビジネス問題の解決を効率的に支援するオプションを持つAIアシスタントを実現できます。

このソリューションは、あなたの知識ベース全体にわたるさまざまな種類の検索、分析的推論、および複数ステップの推論に答えることができるLLMアシスタントへの設計プロセスを示しています。また、あなたのLLMアシスタントがユーザーをサポートするために期待される質問とタスクの種類から逆算することの重要性も強調しています。この場合、設計上の旅は、セマンティック検索、メタデータの抽出とSQLクエリ、LLMエージェントとツールの3つのコンポーネントを備えたアーキテクチャに私たちを導きました。このアーキテクチャは、複数のユースケースに対して一般的で柔軟性があり、最適な機能を実現するためにこのソリューションからヒントを得てユーザーのニーズに深く立ち入ることでより進化させることができると考えています。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!