Retrieval-Augmented Generation

Retrieval-augmented generation（RAG）は、大規模言語モデル（LLM）が外部のデータソースから新しい情報を検索し、組み込むことを可能にする技術である^[1]。検索拡張生成（けんさくかくちょうせいせい）ともいう。RAGを用いると、LLMはユーザーのクエリに応答する前に、まず指定されたドキュメント群を参照する。これらのドキュメントは、LLMが事前に学習したデータを補完するものである^[2]。これにより、LLMは学習データには含まれていない特定のドメイン情報や最新の情報を利用できるようになる^[2]。例えば、LLMベースのチャットボットが社内データにアクセスしたり、権威ある情報源に基づいて回答を生成したりするのに役立つ。

RAGは、回答を生成する前に情報検索を組み込むことで大規模言語モデル（LLM）を向上させる^[3]。静的な学習データに依存するLLMとは異なり、RAGはデータベース、アップロードされたドキュメント、またはウェブソースから関連するテキストを抽出する^[1]。Ars Technicaによれば、「RAGは本質的にLLMのプロセスとウェブ検索やその他のドキュメント検索プロセスを融合させ、LLMが事実に基づいた回答をするのを助けることで、LLMのパフォーマンスを向上させる方法である」という。この手法は、チャットボットが存在しないポリシーを説明したり、弁護士に対して自らの主張を裏付けるために存在しない判例を推奨したりする原因となっているAIのハルシネーションを減らすのに役立つ^[4]。

また、RAGはLLMを新しいデータで再学習させる必要性を減らし、計算コストや金銭的コストを節約する^[1]。効率性の向上にとどまらず、RAGはLLMが回答に情報源を含めることを可能にするため、ユーザーは引用された情報源を検証できる。検索されたコンテンツをユーザーが相互に確認し、正確性と関連性を確保できるため、より高い透明性がもたらされる。

RAGという用語は、2020年の研究論文で初めて導入された^[3]。

RAGとLLMの限界

LLMは誤った情報を提供することがある。例えば、GoogleがLLMツール「Google Bard」（後にGeminiへと改称）を初めてデモンストレーションした際、LLMはジェイムズ・ウェッブ宇宙望遠鏡に関する誤った情報を提供した。このエラーは、同社の株価が1000億ドル下落する一因となった^[4]。RAGはこうしたエラーを防ぐために使用されるが、すべての問題を解決するわけではない。例えば、LLMは事実として正しい情報源から抽出した場合でも、文脈を誤解すると誤情報を生成する可能性がある。MIT Technology Reviewは、「米国にはバラク・フセイン・オバマという一人のイスラム教徒の大統領がいた」というAI生成の回答を例に挙げている。モデルはこれを、『バラク・フセイン・オバマ：米国初のイスラム教徒の大統領？』という修辞的なタイトルの学術書から検索した。LLMはタイトルの文脈を「知る」ことも「理解する」こともなく、誤った文章を生成してしまったのである^[2]。

RAGを備えたLLMは、新しい情報を優先するようにプログラムされている。この技術は「プロンプト・スタッフィング」と呼ばれている。プロンプト・スタッフィングがない場合、LLMの入力はユーザーによって生成されるが、プロンプト・スタッフィングがある場合、モデルの回答を導くためにこの入力に追加の関連する文脈が加えられる。このアプローチは、プロンプトの早い段階でLLMに重要な情報を提供し、事前に学習した知識よりも提供されたデータを優先するよう促す^[5]。

プロセス

RAGは、モデルが元の学習データセットを超えて追加データにアクセスし利用できるようにする情報検索メカニズムを組み込むことで、大規模言語モデル（LLM）を強化する。Ars Technicaは、「新しい情報が利用可能になったとき、モデルを再学習させるのではなく、外部の知識ベースを最新の情報で拡張するだけで済む」（「拡張」）と指摘している^[4]。IBMは、「生成フェーズにおいて、LLMは拡張されたプロンプトと学習データの内部表現から引き出して回答を合成する」と述べている^[1]。

RAGの主要な段階

通常、参照されるデータはLLMの単語埋め込み、すなわち巨大なベクトル空間の形式による数値表現に変換される。RAGは、非構造化データ（通常はテキスト）、半構造化データ、または構造化データ（知識グラフなど）に使用できる。これらの埋め込みは、ドキュメント検索を可能にするためにベクトルデータベースに保存される。

ユーザーのクエリが与えられると、まずドキュメント検索システムが呼び出され、クエリを拡張するために使用される最も関連性の高いドキュメントが選択される^[2]^[3]。この比較はさまざまな方法で行うことができ、その方法は使用されるインデックスの種類に一部依存する^[1]。

モデルは、ユーザーの元のクエリに対するプロンプトエンジニアリングを通じて、この検索された関連情報をLLMに供給する。新しい実装（2023年時点）では、クエリを複数のドメインに拡張する機能や、過去の検索から学習するための記憶や自己改善機能を持つ特定の拡張モジュールを組み込むこともできる。

最後に、LLMはクエリと検索されたドキュメントの両方に基づいて出力を生成することができる^[2]^[6]。一部のモデルでは、検索された情報の再ランク付け、文脈の選択、ファインチューニングなど、出力を改善するための追加ステップが組み込まれている。

改善手法

上記の基本プロセスに対する改善は、RAGのフローのさまざまな段階で適用できる。

エンコーダー

これらの方法は、テキストを密ベクトルまたは疎ベクトルのいずれかとしてエンコードすることに焦点を当てている。単語の同一性をエンコードする疎ベクトルは、通常辞書の長さであり、大部分がゼロで構成される。意味をエンコードする密ベクトルはよりコンパクトで、ゼロの数が少ない。ベクトルストア（データベース）における類似性の計算方法を改善するためのさまざまな強化手法がある^[7]。

ベクトル類似性の計算方法を最適化することでパフォーマンスが向上する。内積は類似度スコアリングを強化し、近似最近傍（ANN）検索はK近傍法（KNN）検索よりも検索効率を向上させる^[8]。
Late Interactionsを用いることで精度が向上する可能性があり、これによりシステムは検索後に単語をより正確に比較できるようになる。これは、ドキュメントのランキングを洗練させ、検索の関連性を向上させるのに役立つ^[9]。
密ベクトル演算よりも疎な内積の計算効率の良さを活かし、密ベクトル表現と疎なワンホットベクトルを組み合わせるハイブリッドベクトルアプローチが使用されることもある^[7]。
その他の検索技術は、ドキュメントの選択方法を洗練させることで精度を向上させることに焦点を当てている。一部の検索方法は、検索精度と再現率を向上させるために、SPLADEのような疎な表現とクエリ拡張戦略を組み合わせる^[10]。

検索システム中心の手法

これらの方法は、ベクトルデータベースにおけるドキュメント検索の品質を向上させることを目的としている。

モデルがドキュメント内のマスクされたテキストを予測することで検索パターンを学習するのを助ける技術であるInverse Cloze Task（ICT）を用いて、検索システムを事前学習させる^[11]。
教師ありの検索システム最適化は、検索確率をジェネレーターモデルの尤度分布と一致させる。これには、与えられたプロンプトの上位k個のベクトルを検索し、生成された回答のパープレキシティをスコアリングし、検索システムの選択とモデルの尤度の間のKLダイバージェンスを最小化して検索を洗練させることが含まれる^[12]。
再ランク付け技術は、学習中に最も関連性の高い検索ドキュメントを優先することで、検索システムのパフォーマンスを洗練させることができる^[13]。

言語モデル

RAGのためのRetro言語モデル。各Retroブロックは、Attention、Chunked Cross Attention、およびFeed Forwardレイヤーで構成されている。黒字のボックスは変更されるデータを示し、青字は変更を実行するアルゴリズムを示している。

検索システムを念頭に置いて言語モデルを再設計することにより、25分の1のサイズのネットワークでも、はるかに大きなモデルと同等のパープレキシティを得ることができる^[14]。この手法（Retro）はゼロから学習されるため、元のRAGスキームが回避していた高い学習コストが発生する。この仮説は、学習中にドメイン知識を与えることで、Retroはドメインへの焦点を減らし、より小さな重みリソースを言語の意味論のみに割り当てることができるというものである。再設計された言語モデルがここに示されている。

Retroは再現性がないと報告されており、そのため再現可能にするための修正が加えられた。より再現性の高いバージョンはRetro++と呼ばれ、インコンテキストRAGを含んでいる^[15]。

チャンキング

チャンキングには、検索システムがその中の詳細を見つけられるように、データをベクトルに分割するためのさまざまな戦略が含まれる。

異なるデータスタイルには、適切なチャンキングが活用できるパターンがある。

チャンキング戦略の3つの種類は以下の通りである^[要出典]。

重なりを持つ固定長。これは高速で簡単である。連続するチャンクを重ねることで、チャンク全体で意味的文脈を維持するのに役立つ。
構文ベースのチャンクは、ドキュメントを文に分割することができる。spaCyやNLTKなどのライブラリも役立つ。
ファイル形式ベースのチャンキング。特定のファイルタイプには自然なチャンクが組み込まれており、それらを尊重するのが最善である。例えば、コードファイルは関数やクラス全体としてチャンク化およびベクトル化するのが最適である。HTMLファイルでは、<table> や base64 エンコードされた <img> 要素をそのままにしておくべきである。PDFファイルでも同様の考慮をすべきである。UnstructuredやLangchainなどのライブラリがこの方法を支援できる。

ハイブリッド検索

ベクトルデータベースの検索では、ユーザーの質問に答えるために必要な重要な事実を見逃すことがある。これを軽減する一つの方法は、従来のテキスト検索を行い、ベクトル検索から検索されたベクトルにリンクされたテキストチャンクにそれらの結果を追加し、組み合わされたハイブリッドなテキストを生成のために言語モデルに供給することである^[要出典]。

評価とベンチマーク

RAGシステムは一般的に、検索可能性、検索精度、および生成品質をテストするために設計されたベンチマークを使用して評価される。人気のあるデータセットには、多様なドメインにわたる情報検索タスクのスイートであるBEIRや、オープンドメインのQA用のNatural QuestionsまたはGoogle QAが含まれる^[要出典]。

課題

RAGはLLMにおけるハルシネーションを防ぐわけではない。Ars Technicaによれば、「LLMは回答において依然としてソース資料の周辺でハルシネーションを起こす可能性があるため、これは直接的な解決策ではない」という^[4]。

RAGは大規模言語モデル（LLM）の精度を向上させるが、すべての課題を排除するわけではない。一つの限界は、RAGが頻繁なモデルの再学習の必要性を減らす一方で、それを完全になくすわけではないということである。さらに、LLMは信頼できる回答を提供するための十分な情報が不足している場合、それを認識するのに苦労する可能性がある。特定の学習を行わない場合、モデルは不確実性を示すべき時でさえ回答を生成してしまうことがある。IBMによれば、この問題はモデルが自身の知識の限界を評価する能力を欠いている場合に発生する可能性があるという^[1]。

RAGポイズニング

RAGシステムは事実として正しいが誤解を招くような情報源を検索することがあり、解釈の誤りを引き起こす。場合によっては、LLMが文脈を考慮せずに情報源から記述を抽出し、誤った結論に至ることもある。さらに、相反する情報に直面した場合、RAGモデルはどの情報源が正確かを判断するのに苦労する可能性がある。この制限の最悪の結果は、モデルが複数の情報源からの詳細を組み合わせ、古い情報と最新の情報を誤解を招くような方法で融合させた回答を生成してしまうことである。MIT Technology Reviewによれば、これらの問題はRAGシステムが検索したデータを誤って解釈する可能性があるために発生するという^[2]。