検索拡張生成

検索拡張生成は、モデルの学習されたパラメーターよりも外部の情報源から関連情報を検索し、モデルが答えを生成する前に文脈として提供するパターンです [1]。

RAGは、モデルのトレーニングデータに類似した資料が存在するかどうかにかかわらず、生成時に外部から取得した情報をAIの回答に使用する方法です。モデルが学習したパラメータとプロンプトだけで答えを求めるのではなく、システムはまずドキュメントストアを検索し、関連するセクションを取得し、それらのセクションをプロンプトやコンテキストに追加して、それらに基づいてモデルに答えを求めるのです。

これは企業のポリシー、製品ドキュメント、サポート知識ベース、研究ノート、および内部手順に対してAIシステムをより役立たせるものであり、提供された資料に基づいて回答を根拠付けることで一部の誤認リスクを軽減します。ただし、正確性を保証するものではありません。システムは間違ったセクションを検索したり、正しいドキュメントを見逃したり、古くなったコンテンツを使用したり、ユーザーが見えてはいけないデータを暴露したり、検索されたドキュメント内の隠された指示によって操作されたりする可能性があります。

多くの有用なAIタスクは、モデルのトレーニングデータに含まれていない、または頻繁に変化する情報に依存します。サポートポリシーが変更されます。学校のハンドブックが更新されます。製品に新しいセットアップステップがあります。契約テンプレートにはローカルの例外があります。RAGは、モデルを選択された知識に接続する実用的な方法をビルダーに提供し、毎回モデルを再トレーニングする必要はありません。

Lewisと同僚による元のRAG論文は、知識集約的なNLPタスクにおいて検索と生成を組み合わせ、そのアーキテクチャを研究パターンとして示しましたが、真実の保証ではありません [1]。AWSからのベンダーのガイドラインは、検索オプションやアーキテクチャのトレードオフなどの実用的な実装選択に役立ちますが、これは実装のガイドラインとして扱われるべきであり、概念の唯一の中立的な権威としては扱われてはなりません [2]。

組織にとって、RAGは知識源をモデルとは別に管理できるため魅力的です。チームは、新しいファウンデーションモデルをトレーニングすることなく、ドキュメントを更新し、古くなったページを削除し、チャンクを改善し、権限を変更できます。これはRAGを実用的にするものの、答えの品質が通常の情報管理作業に依存することを意味します。つまり、整ったドキュメント、明確な所有権、最新のポリシー、およびテストされた検索が重要です。

基本的なRAGシステムには3つの部分があります。最初は検索です。システムはユーザーの質問を受け取り、ドキュメントや構造化された記録を検索します。これは通常、キーワード検索、ベクトル埋め込み、メタデータフィルター、構造化クエリ、またはこれらの組み合わせを使用します。第二は拡張、より正確にはコンテキストの構築です。システムは検索された資料をモデルのプロンプトに追加し、通常はその使用方法に関する指示を含みます。第三は生成です。言語モデルはユーザーの質問、指示、および検索されたコンテキストを使用して答えを書きます。

RAG回答には引用またはソースラベルが含まれる場合がありますが、出典情報は正確である場合にのみ有用です。引用は検索されたドキュメントを指すかもしれませんが、その文と完全に一致するとは限りません。関連するセクションでも、その主張と一致しない場合があります。モデルは検索されたテキストと支持されていない言葉を混ぜ合わせることもあります。そのため、ソースの検証はワークフローの一部のままです。

RAGはセキュリティとガバナンスの質問も作成します。NISTは、生成AIシステムをライフサイクル全体でリスク管理されたシステムとして扱い、孤立したモデル呼び出しとして扱いません [3]。OWASPの2025年のLLMおよび生成AIアプリケーションのトップ10は、機密情報の漏洩、過度な権限、ベクトルおよび埋め込みの脆弱性、誤情報などのリスクを強調しています [4]。そのプロンプトインジェクションガイドラインは、AIシステムが処理する外部コンテンツに隠された悪意のある指示による間接的な攻撃についても説明しています [5]。取得されたドキュメントは、そのリスクが現れる場所の1つです。

ビルダーは各部分を別々にテストする必要があります。検索テストでは、正しいセクションが見つかるかを確認します。根拠テストでは、答えがそのセクション内にとどまっているかを確認します。引用テストでは、各ソースマーカーが隣接する文を支持しているかを確認します。権限テストでは、ユーザーがその資料を検索することを許可されているかを確認します。エンドツーエンドテストでは、システム全体が実際のユーザーの質問や失敗ケースを処理できるかを確認します。

ソフトウェア会社のカスタマーサポートアシスタントを想像してください。顧客が「製品が一度もアクティベートされなかった場合、45日後に返金は可能ですか？」と尋ねます。RAGシステムは質問を検索に変換し、返金ポリシーとアクティベーショントラブルシューティングガイドからチャンクを取得し、それらのセクションをモデルのコンテキストに追加します。

その後、モデルは次の応答を生成します。「ポリシーでは通常、返金は30日以内に利用可能ですが、アクティベーションに失敗した場合はレビューのために上級者に引き渡すことができます。アクティベーションエラーと注文IDをカスタマーに尋ねてください。」良いインターフェースは、その答えに使われたポリシーの文章を表示すべきです。人間のサポート担当者は、取得したポリシーが最新であることを確認し、カスタマーアカウントの正しい購入日があるか、そして答えが内部のみのノートを暴露していないかを確認する必要があります。

最大の誤解は、RAGが幻覚を完全に消滅させると考えることです。RAGは、モデルが関連する文脈を持つことで、一部のリスクを軽減する可能性があります。また、ユーザーが検索されたセクションを確認できるため、失敗がより見つけやすくなることもあります。しかし、生成の前、生成中、または生成後にシステムが失敗する可能性もあります。

もう一つの誤解は、ソースリンクがあるということはその答えが証明されているということであるということです。取得されたソースは実際に主張を支持しなければなりません。もし答えが「45日後に返金が可能」と述べているが、ソースは「通常30日以内に返金が可能」と述べている場合、引用は十分ではありません。

検索失敗は最初の主要なリスクです。システムは関係のないページを検索したり、珍しい例外を見逃したり、必要な周囲の文脈が欠如したチャンクを選択したりする可能性があります。古くなったまたは欠落しているドキュメントもリスクです。古いポリシーを完璧に検索しても、依然として古い根拠になります。

アクセス制御も重要です。RAGシステムは、許可されていないユーザーが見ることのできない給与文書、顧客記録、法的ノート、または内部セキュリティ手順を検索してはなりません。検索されたドキュメントにおけるプロンプトインジェクションは別のリスクです。悪意のあるまたは改変されたドキュメントには、システムのタスクを上書きしたり、データを漏洩させたり、答えを変更しようとする指示が含まれる可能性があります。高リスク用途では、RAGにはドキュメントの衛生管理、権限、モニタリング、および人間のレビューが必要です。

もう一つの制限は評価です。デモはいくつかの手作業で選ばれた質問で強力に見えるかもしれませんが、実際のシステムはエッジケース、同義語、長文、矛盾するポリシー、または情報の欠如で失敗します。有用なRAGシステムには、良い回答、悪い検索結果、回答なしのケース、古くなったドキュメント、および権限の境界の例が必要です。チームは、検索結果が弱い、矛盾している、または存在しない場合、製品がどのように動作するかを決定する必要があります。不確実性で答え、フォローアップ質問を尋ね、人間にルーティングする、または弱い証拠から答えを拒否するなどです。

RAGの答えに頼る前に、尋ねてください：正しいドキュメントが検索されましたか？それらは最新ですか？答えは、ソースが支持する範囲に限定されていますか？引用は、正確な主張を支持する正確なセクションに添えられていますか？検索されたドキュメントのいずれかに敵対的な指示が含まれている可能性がありますか？ユーザーはすべての検索されたソースにアクセスする権限を持っていますか？検索で何も見つからない場合、どうなりますか？

低リスクの下書きには、RAGの答えは強力な出発点となることができます。ポリシー、セキュリティ、顧客、法的、金融、医療、または雇用の決定には、ソースのレビューと明確な承認担当者を必要とします。RAGは、証拠をモデルに近づけることでいくつかのリスクを軽減しますが、検証を置き換えるものではありません。良いシステムは、実際の使用やレビュー中に不確実性を隠すのではなく、明確に表示します。