検索拡張生成

検索拡張生成（RAG ）は、大規模言語モデル（LLM）が外部データソースから新しい情報を取得して組み込むことを可能にする技術です。 [ 1 ] RAGでは、LLMは指定された文書セットを参照するまで、ユーザーのクエリに応答しません。これらの文書は、LLMの既存のトレーニングデータからの情報を補完します。[ 2 ]これにより、LLMはトレーニングデータでは利用できないドメイン固有の情報や更新された情報を使用できます。[ 2 ]例えば、これはLLMベースのチャットボットが社内データにアクセスしたり、信頼できる情報源に基づいて応答を生成したりするのに役立ちます。

RAGは、応答を生成する前に情報検索を組み込むことで、大規模言語モデル（LLM）を改善します。 [ 3 ]静的なトレーニングデータに依存するLLMとは異なり、RAGはデータベース、アップロードされたドキュメント、またはWebソースから関連するテキストを取得します。[ 1 ] Ars Technicaによると、「RAGは、本質的にLLMプロセスをWeb検索またはその他のドキュメント検索プロセスと融合させることでLLMのパフォーマンスを向上させる方法であり、LLMが事実に忠実になるようにします。」この方法は、AIの幻覚を軽減するのに役立ちます。[ 3 ]チャットボットが存在しないポリシーを説明したり、議論を裏付ける引用を探している弁護士に存在しない訴訟事例を推奨したりする原因となっていました。[ 4 ]

RAGは、LLMを新しいデータで再学習させる必要性を軽減し、計算コストと費用を節約します。[ 1 ]効率性の向上に加え、RAGはLLMが回答に出典を含めることを可能にするため、ユーザーは引用元を検証できます。これにより、ユーザーは取得したコンテンツを相互に確認し、正確性と関連性を確認できるため、透明性が向上します。

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

RAGとLLMの制限

LLMは誤った情報を提供する可能性があります。例えば、GoogleがLLMツール「Google Bard」（後にGeminiに改名）を初めて公開した際、LLMはジェイムズ・ウェッブ宇宙望遠鏡に関する誤った情報を提供しました。この誤りは、同社の株価を1,000億ドル下落させる一因となりました。 [ 4 ] RAGはこれらの誤りを防ぐために用いられますが、すべての問題を解決できるわけではありません。例えば、LLMは事実上正しい情報源から情報を取得していても、文脈を誤って解釈すれば誤った情報を生成する可能性があります。MIT Technology Reviewは、AIが「アメリカ合衆国には、バラク・フセイン・オバマというイスラム教徒の大統領がいたことがある」と回答した例を挙げています。このモデルは、この回答を『バラク・フセイン・オバマ：アメリカ初のイスラム教徒大統領？ 』という修辞的なタイトルの学術書から取得しました。LLMはタイトルの文脈を「認識」または「理解」していなかったため、誤った記述を生成しました。[ 2 ]

RAGを備えたLLMは、新しい情報を優先するようにプログラムされています。この手法は「プロンプトスタッフィング」と呼ばれています。プロンプトスタッフィングがない場合、LLMへの入力はユーザーによって生成されます。プロンプトスタッフィングがある場合、モデルの応答を導くために、この入力に関連するコンテキストが追加で追加されます。このアプローチは、LLMにプロンプ​​トの早い段階で重要な情報を提供し、既存のトレーニング知識よりも提供されたデータを優先するように促します。[ 5 ]

プロセス

検索拡張生成（RAG）は、情報検索メカニズムを組み込むことで大規模言語モデル（LLM）を強化します。このメカニズムにより、モデルは元のトレーニングセットを超えた追加データにアクセスし、それを活用できるようになります。Ars Technicaは、「新しい情報が利用可能になった場合、モデルを再トレーニングするのではなく、更新された情報でモデルの外部知識ベースを拡張するだけで済む」（「拡張」）と述べています。[ 4 ] IBMは、「生成フェーズでは、LLMは拡張されたプロンプトとトレーニングデータの内部表現から情報を取得し、その瞬間のユーザーに合わせた魅力的な回答を合成する」と述べています。[ 1 ]

RAGの主要ステージ

RAG プロセスの概要、外部ドキュメントとユーザー入力を LLM プロンプトに組み合わせてカスタマイズされた出力を取得する

通常、参照対象となるデータは、大規模なベクトル空間の形式で数値表現されるLLM埋め込みに変換されます。RAGは、非構造化データ（通常はテキスト）、半構造化データ、または構造化データ（例えばナレッジグラフ）に使用できます。これらの埋め込みは、ドキュメント検索を可能にするためにベクトルデータベースに保存されます。

ユーザクエリが与えられると、まずドキュメントリトリーバーが呼び出され、クエリを補強するために使用される最も関連性の高いドキュメントが選択されます。[ 2 ] [ 3 ]この比較は、使用されるインデックスの種類に応じてさまざまな方法で行うことができます。[ 1 ]

モデルは、ユーザーの元のクエリを迅速にエンジニアリングすることで、取得した関連情報をLLMにフィードします。新しい実装（2023年現在）では、クエリを複数のドメインに拡張したり、メモリと自己改善を利用して過去の検索から学習したりする機能を備えた特定の拡張モジュールを組み込むこともできます。

最後に、LLMはクエリと取得された文書の両方に基づいて出力を生成することができる。[ 2 ] [ 6 ]一部のモデルでは、取得された情報の再ランク付け、コンテキストの選択、微調整など、出力を改善するための追加ステップが組み込まれている。

改善点

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

エンコーダ

これらの手法は、テキストを密ベクトルまたは疎ベクトルとして符号化することに重点を置いています。単語の同一性を符号化する疎ベクトルは、通常辞書長で、ほとんどがゼロで構成されます。意味を符号化する密ベクトルは、よりコンパクトで、ゼロの数が少なくなります。様々な機能強化により、ベクトルストア（データベース）における類似度の計算方法を改善できます。[ 7 ]

  • ベクトル類似度の計算方法を最適化することで、パフォーマンスが向上します。ドット積は類似度スコアリングを強化し、近似近傍法（ANN）検索はK近傍法（KNN）検索よりも検索効率を向上させます。[ 8 ]
  • 後期インタラクションによって精度が向上する可能性があります。これは、システムが検索後に単語をより正確に比較できるようにするものです。これにより、文書のランキングが精緻化され、検索の関連性が向上します。[ 9 ]
  • ハイブリッドベクトルアプローチは、密ベクトル表現と疎ワンホットベクトルを組み合わせるために使用することができ、密ベクトル演算よりも疎ドット積の計算効率を活用できる。[ 7 ]
  • 他の検索技術は、文書の選択方法を改善することで精度を向上させることに重点を置いています。SPLADEなどのスパース表現とクエリ拡張戦略を組み合わせることで、検索精度と再現率を向上させる検索手法もあります。[ 10 ]

レトリーバー中心の方法

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

  • 逆クローズタスク（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は依然として反応において元の物質に関する幻覚を起こす可能性があるため、RAGは直接的な解決策ではありません。」[ 4 ]

RAGは大規模言語モデル（LLM）の精度を向上させますが、すべての課題を解消するわけではありません。RAGは頻繁なモデルの再学習の必要性を軽減するものの、完全に解消するわけではないという限界があります。さらに、LLMは、信頼性の高い回答を提供するのに十分な情報が不足している場合、それを認識するのが困難になることがあります。特別な学習を行わないと、モデルは不確実性を示すべき場合でも回答を生成する可能性があります。IBMによると、この問題は、モデルが自身の知識の限界を評価できない場合に発生する可能性があります。[ 1 ]

RAG中毒

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

参考文献

  1. ^ a b c d e f「検索拡張生成とは何か？」 IBM 2023年8月22日. 2025年3月7日閲覧。
  2. ^ a b c d e f「GoogleのAI概要が間違った判断を下す理由」 MITテクノロジーレビュー、2024年5月31日。 2025年3月7日閲覧。
  3. ^ a b c dルイス、パトリック;ペレス、イーサン。ピクトゥス、アレクサンドラ。ペトロニ、ファビオ。カルプキン、ウラジミール。ゴヤル、ナマン。キュトラー、ハインリヒ。ルイス、マイク。イー、ウェンタウ。ロックテッシェル、ティム;リーデル、セバスチャン。キーラ、ダウ（2020年12月6日）。知識集約的な NLP タスクのための検索拡張生成。神経情報処理システムに関する国際会議。米国ニューヨーク州レッドフック: Curran Associates Inc. ISBN 978-1-7138-2954-6. 2025年12月9日閲覧。
  4. ^ a b c d「RAGという技術はAIモデルによる捏造を防ぐことができるか？」 Ars Technica 2024年6月6日. 2025年3月7日閲覧。
  5. ^ 「テキスト要約におけるLLM幻覚の緩和」 BBC 、 2024年6月20日。 2025年3月7日閲覧。
  6. ^ Lewis, Patrick; Perez, Ethan; Piktus, Aleksandra; Petroni, Fabio; Karpukhin, Vladimir; Goyal, Naman; Küttler, Heinrich; Lewis, Mike; Yih, Wen-tau; Rocktäschel, Tim; Riedel, Sebastian; Kiela, Douwe (2020). 「知識集約型NLPタスクのための検索拡張生成」 .ニューラル情報処理システムの進歩. 33. Curran Associates, Inc.: 9459– 9474. arXiv : 2005.11401 .
  7. ^ a b Luan, Yi; Eisenstein, Jacob; Toutanova, Kristina; Collins, Michael (2021年4月26日). 「テキスト検索のためのスパース、デンス、およびアテンショナル表現」 . Transactions of the Association for Computational Linguistics . 9 : 329–345 . arXiv : 2005.00181 . doi : 10.1162/tacl_a_00369 . 2025年3月15日閲覧.
  8. ^ 「情報検索」 . Microsoft . 2025年1月10日. 2025年3月15日閲覧。
  9. ^ Khattab, Omar; Zaharia, Matei (2020). 「ColBERT: BERTを介したコンテキスト化された遅延インタラクションによる効率的かつ効果的なパッセージ検索」 .第43回国際ACM SIGIR情報検索研究開発会議議事録. pp.  39– 48. doi : 10.1145/3397271.3401075 . ISBN 978-1-4503-8016-4。
  10. ^ Wang, Yup; Conroy, John M.; Molino, Neil; Yang, Julia; Green, Mike (2024). 「TREC 2024 検索拡張生成トラックにおける分析科学研究室」 . NIST TREC 2024. 2025年3月15日閲覧。
  11. ^リー、ケントン;チャン、ミンウェイ。トウタノバ、クリスティーナ（2019）。」「弱教師付きオープンドメイン質問応答のための潜在検索」（PDF）。
  12. ^ Shi, Weijia; Min, Sewon; Yasunaga, Michihiro; Seo, Minjoon; James, Rich; Lewis, Mike; Zettlemoyer, Luke; Yih, Wen-tau (2024年6月). 「REPLUG: 検索強化型ブラックボックス言語モデル」 . 2024年北米支部計算言語学協会会議録: 人間言語技術 (第1巻: 長編論文) . pp.  8371– 8384. arXiv : 2301.12652 . doi : 10.18653/v1/2024.naacl-long.463 . 2025年3月16日閲覧.
  13. ^ラム、オリ;レヴィン、ヨアヴ。ダルメディゴス、イタリア;ドール・ムルゲイ。シャシュア、アムノン。レイトン＝ブラウン、ケビン。ショーハム、ヨアヴ (2023)。「インコンテキスト検索拡張言語モデル」。計算言語学協会のトランザクション。11 : 1316–1331.arXiv : 2302.00083 。​​土井: 10.1162/tacl_a_00605 。2025 年3 月 16 日に取得。
  14. ^ Borgeaud, Sebastian; Mensch, Arthur (2021). 「数兆個のトークンからの検索による言語モデルの改善」(PDF) .
  15. ^ Wang, Boxin; Ping, Wei; Xu, Peng; McAfee, Lawrence; Liu, Zihan; Shoeybi, Mohammad; Dong, Yi; Kuchaiev, Oleksii; Li, Bo; Xiao, Chaowei; Anandkumar, Anima; Catanzaro, Bryan (2023). 「検索機能を備えた自己回帰言語モデルを事前学習すべきか？ 包括的研究」 . 2023年自然言語処理における経験的手法に関する会議論文集. pp.  7763– 7786. doi : 10.18653/v1/2023.emnlp-main.482 .
「 https://en.wikipedia.org/w/index.php?title=Retrieval-augmented_generation&oldid=1335739515」より取得