AIエージェントのメモリのためにベクトルRAGの代替を構築しました

ホームページに戻るブログに戻るRetrieval-Augmented Generation (RAG) は、言語モデルを外部情報に接続するための標準的な方法の1つになりました。従来の一般的なアプローチは、ドキュメントをチャンクに分割し、埋め込みを生成し、それらのベクトルをデータベースに保存し、モデルに質問する前に最も近いパッセージを取得するというものです。そのアーキテクチャは、初期の重要な問題を解決しました。しかし、AIエージェントは検索が意味することを変化させています。エージェントは質問に答えるだけではありません。ツールを選択し、ソースを比較し、中間結果を検査し、マルチステップワークフローを実行し、十分な情報があると判断したときにアクションを取ります。次世代のRAGは、固定された取得・生成パイプラインから、エージェントがより広範な意思決定プロセスの一部として検索を制御する、エージェント的なRAGへと移行しています。Microsoftはこのシフトを、エージェントが呼び出し、評価し、必要に応じて繰り返すことができるツールとして検索を扱うと説明しています。これは、ベクトルデータベース、埋め込み、またはチャンク化がすぐに消えることを意味するわけではありません。それは、それらがもはや検討に値する唯一のアーキテクチャではなくなり、多くのドキュメント-エージェントワークフローでは、開発者が最初に構築すべきものではなくなることを意味します。AIエージェントのためのRAGとは何ですか？AIエージェントのためのRAGは、エージェントが推論およびアクションを実行する際に外部情報にアクセスできるようにするシステムです。従来のRAGは通常、1つの固定シーケンスに従います。エージェントRAGは、エージェントがいつ取得するかを決定するようにシーケンスを変更します。従来のRAGユーザーの質問 → 質問の埋め込み → ベクトルデータベースの検索 → チャンクの取得 → モデルへのチャンク送信 → 回答の生成エージェントRAGユーザーのタスク → エージェントがタスクを分析 → エージェントが必要な情報を決定 → エージェントが検索またはドキュメントツールを呼び出す → エージェントが結果を評価 → 必要に応じてエージェントが別のツールを呼び出す → エージェントがアクションを実行または応答する重要な違いは、検索がもはや目に見えない前処理ステップではなくなったことです。それはエージェントが利用できる機能になります。LangChainのドキュメントは、この原則を直接説明しています。エージェントは、組み込みの検索チェーンに依存するのではなく、ドキュメントローダー、API、データベースクエリを含む外部知識を取得するために1つ以上のツールを使用できます。従来のRAG対エージェントRAG従来のRAGエージェントRAG検索は生成の前に行われるエージェントがいつ検索するかを決定する通常1つの検索パイプラインを使用する複数のツールとソースを使用できる類似したチャンクを取得するタスクに必要な情報を取得するしばしば単一の回答を返す複数のステップを継続できる固定されたクエリからコンテキストへのフロー動的な計画とイテレーション主に質問応答のために設計された推論とアクションのために設計されたコンテキストは類似性によって選択されるコンテキストはタスクの関連性によって選択される検索はインフラストラクチャレイヤーである検索はエージェントの機能であるしたがって、エージェントRAGは単にエージェントが追加されたRAGではありません。それはエージェント、ドキュメント、および外部ツール間の関係を設計する異なる方法です。固定ベクトルRAGの限界ベクトルベースのRAGは、特に大規模で永続的なテキストコレクションに対して依然として有用です。しかし、標準的なパイプラインは、それがすべてのエージェントのデフォルトソリューションになると、いくつかの弱点があります。チャンク化はドキュメント構造を破壊する可能性がありますチャンク化は、ドキュメントを小さなパッセージに分割して、インデックス作成および取得できるようにします。ドキュメントは、任意のテキストフラグメントのコレクションとして自然に存在するわけではありません。意味は、セクションタイトル、テーブルヘッダー、脚注、前の段落、ページ参照、行間の関係、節とその修正、またはフォーム内の値の位置に依存する可能性があります。列ヘッダーのないテーブル行は、完全なテーブルと同等ではありません。定義セクションのない契約条項は誤解を招く可能性があります。ポリシーから抽出された文は、数段落後の例外に依存する可能性があります。埋め込みは類似性を測定し、ビジネス上の関連性を測定しません埋め込みは意味論的な関係を表します。クエリに似たテキストを特定できますが、類似性はビジネス上のタスクへの関連性と同じではありません。請求書が注文書と一致するかどうかを尋ねられたエージェントは、サプライヤー、製品、数量、単価、税金、合計、通貨を必要とします。ベクトル検索は両方のドキュメントに関するテキストを取得する可能性があります。それは自動的に比較を実行しません。1回の検索呼び出しでは不十分な場合があります固定RAGチェーンは、1回の検索操作で必要なコンテキストを提供できると想定しています。エージェントはしばしば複数のステップを必要とします。契約を見つけ、最新の修正を見つけ、更新条項を確認し、日付を比較し、通知が必要かどうかを判断し、リマインダーを作成します。エージェントは、発見したことに基づいて次に何を検査するかを決定します。固定された取得・生成パイプラインは、そのプロセス向けに設計されていません。ベクトルデータベースはインフラストラクチャを追加しますドキュメントの取り込み、解析、チャンク化、および埋め込み生成。ベクトルストレージ、メタデータフィルタリング、インデックス更新、ドキュメント削除。バージョン管理、アクセス制御、および検索評価。解析の変更時の引用処理と再処理。LlamaIndexやLangChainのようなフレームワークは、このプロセスの部分を簡素化しますが、基盤となるアーキテクチャ上の決定を排除するものではありません。LlamaIndexは、データコネクタ、インデックス作成、クエリエンジンに特に役立ちますが、他のフレームワークはオーケストレーションとツールの使用に焦点を当てています。問題は、これらのツールが価値があるかどうかではありません。問題は、すべてのエージェントが完全なベクトル検索スタックから開始すべきかどうかです。チャンク化、埋め込み、およびベクトルデータベースは、未来のすべてではありませんベクトルデータベース、埋め込み、およびチャンク化が時代遅れであると言うのは単純すぎます。それらは、大規模なドキュメントライブラリ、永続的なエンタープライズナレッジベース、意味検索、類似性発見、レコメンデーションシステム、長期コレクション、および高ボリュームの繰り返しクエリに対して依然として価値があります。真のシフトはアーキテクチャ上にあります。ベクトル検索は、すべてのAIエージェントの普遍的な基盤ではなく、エージェント的な情報システム内の1つのツールになりつつあります。エージェントは、各タスクに最も適切なツールを使用します。請求書の場合は構造化抽出、財務記録の場合はSQL、ライブビジネスデータの場合はAPI、短いファイルの場合はフルドキュメント処理、ケースワークフローの場合はドキュメント比較、関係性の場合はナレッジグラフ、辞書クエリの場合は検索インデックス、意味発見の場合はベクトル検索、曖昧さの場合は人間のレビュー。エージェントRAGとは何ですか？エージェントRAGは、AIエージェントが外部情報にいつどのようにアクセスするかを制御する検索アーキテクチャです。エージェントは、検索が必要かどうかを決定し、ソースを選択し、より正確なサブクエリを形成し、複数のソースから検索し、結果を評価し、フォローアップを要求し、出力を比較し、証拠不十分を検出し、サポートされていないアクションを取る前に停止することができます。MicrosoftのエージェントRAGガイダンスは、このパターンを、単一の固定検索呼び出しではなく、動的なクエリ計画、マルチステップ推論、および自律的な情報収集として説明しています。検索はツールになりますsearch_documents() および query_document() process_multiple_documents() および compare_documents() extract_fields() および query_database() search_web()、get_contract_amendment() および request_human_review()請求書が注文書と一致するかどうかを尋ねられた場合、エージェントは両方のファイルを一緒に処理し、サプライヤーと合計を比較し、異なる場合は例外を返し、結果が不明確な場合はレビューを要求できます。それは、取得されたチャンクに比較が含まれていることを期待する一般的な意味検索を必要としません。エージェントのためのRAGの進化ステージ1: 取得と生成クエリ → ベクトル検索 → チャンク → LLM回答ステージ2: 取得と再ランキングクエリ → ベクトル検索 → 再ランキング → より良いチャンク → LLM回答ステージ3: ハイブリッド検索クエリ → ベクトル + キーワード + メタデータ → 結合されたコンテキスト → LLM回答ステージ4: エージェント的な検索タスク → エージェントが計画 → ツールを選択 → 取得または処理 → 評価 → イテレーション → アクションシステムはもはや1つのデータベースを中心に据えていません。それは、エージェントが情報ツールを使用する能力を中心に据えています。ベクトルベースRAGの代替手段