RAG -> エージェント RAG -> エージェントメモリ @helloiamleonieさんのブログは特に気に入っています。この記事では、AIシステムにおける情報検索と保存のメカニズムの段階的な進化について考察しています。簡略化されたメンタルモデルに基づいて、静的な検索から動的なメモリ管理への移行を解説し、LLMが外部ツールを用いてコンテキストウィンドウを超えた情報を処理する仕組みを理解するのに役立ちます。この進化の核心は、「読み取り専用」操作から「読み書き可能」機能への移行にあり、これにより、よりパーソナライズされ、適応性の高いAIエージェントが実現されています。 RAG：ワンタイム読み取り専用検索の出発点。まず、2020年に提案され、2023年に普及が進む基盤技術であるRAGについて考察します。RAGは、外部のベクトルデータベースに知識を注入することで、LLMの「錯覚」問題に対処します。RAGのプロセスは2つのステップで構成されます。1つはオフライン段階で文書を埋め込み、保存するステップ、もう1つはオンライン段階でクエリに基づいて関連するコンテキストを取得し、ヒントと組み合わせてレスポンスを生成するステップです。 たとえば、次の擬似コードはそのシンプルさを示しています。 • ドキュメントを保存するときに、埋め込みファイルを生成してデータベースに保存します。 • クエリに回答するときに、上位 k 件の結果を一度に取得し、プロンプトに挿入して出力を生成します。 RAGは錯覚の軽減に優れていますが、重大な限界があります。RAGは「一回限り」の解決策であり、検索の必要性や関連性を評価できません。知識源は単一であり、学習メカニズムがないため、インタラクションから反復学習することはできません。そのため、RAGは単純な質疑応答のシナリオには適していますが、複雑で継続的な対話のシナリオには適していません。 エージェント型RAG：ツール呼び出しによる動的読み取り専用。RAGの硬直性を克服するため、本稿ではエージェント型RAGを導入します。エージェント型RAGでは、検索をエージェントが呼び出せる「ツール」として扱います。エージェントは受動的にデータを取得するのではなく、ツール（データベース検索やWebクエリなど）を呼び出すかどうかを能動的に決定し、結果の関連性を評価します。これによりループメカニズムが導入されます。LLMは応答を生成し、必要に応じてツールを実行し、結果を返します。これは、ツールが不要になるまで続きます。 擬似コードでは、エージェントはツール呼び出し（SearchToolなど）を通じて動的に情報を取得し、メッセージ履歴が徐々に蓄積されます。これにより柔軟性が向上し、エージェントは適切なツールを選択し、無関係な情報の挿入を回避できます。ただし、これは「読み取り専用」レベルのままです。つまり、情報はオフラインでのみ保存され、リアルタイムで変更またはパーソナライズすることはできず、ユーザーインタラクションから「学習」することもできません。 エージェントメモリ：読み書き操作における核心的なブレークスルーは、Agentic RAGを読み書きシステムに拡張するエージェントメモリにあります。WriteToolなどの「書き込みツール」を追加することで、エージェントは情報を取得するだけでなく、保存、更新、削除も行うことができます。これにより、インタラクションから学習する閉ループが実現します。例えば、ユーザーの好み（絵文字の使用習慣など）やイベント（誕生日など）を記録し、その後の会話でそれらを取得することが可能になります。 擬似コードはこのループを示しています。レスポンスで書き込み操作が行われた場合、情報はデータベースに保存され、確認が送信されます。これは、前述の2つのアプローチの問題点に直接対処するものです。動的ストレージはリアルタイム適応をサポートし、パーソナライズされた検索はユーザーエクスペリエンスを向上させます。記事では例として、エージェントが会話の要約や元の履歴を保存することで、「思い出す」だけでなく「記憶する」機能を実現できることを示しています。 単純化モデルの限界と実用上の考慮事項 レオニーは、このモデルが簡略化されており、多元記憶（例えば、手続き記憶：表情の利用、エピソード記憶：ユーザーの旅行計画、意味記憶：事実に基づく知識）や高度な管理戦略（例えば、MemGPTにおける記憶の統合と忘却）を網羅していないことを認めています。このモデルは強力ですが、メモリ破損（古い情報による干渉）や管理負担といった新たなリスクも生じます。実用的な実装には、イベント検出、サマリー生成、その他の技術を組み合わせてスケーラビリティを確保する必要があります。 記事アドレス
