大規模言語モデル (LLM) の学習データに含まれない知識（各社の特有の書類など）を踏まえてLLMに回答させる際に最早必須となってきたRAG (Retrieval-Augumented Generation)。
今回はそんなRAGのSurvey論文を元に、RAGの変遷や構成要素、新たに出てきた技術を俯瞰していきます。
Survey論文へのリンクはこちら
RAGとは
LLMはそれ単体で回答させると、質問によってはハルシネーションや学習時のデータにはなかった情報を生成時に加味できないといった問題から正しくない回答を生成することが多々あります。例えば世間一般に公開されていない自社の就業規則や業務標準についてをChatGPTに質問しても、正しい回答は得られません。
そのような問題への対応としてRAGが使われます。
「LLM単体で適切な回答を生成できないなら、ユーザーの質問を元にデータベースを検索し、その検索結果を基に回答させる」というような方法が取られます。こうすることで、LLMの学習データに情報がない質問に対しても適切に回答できるようになります。
なおこの論文のAbstractではRAGは以下のように説明されており、上記と同様のことが言われています。
Large Language Models (LLMs) showcase impressive capabilities but encounter challenges like hallucination, outdated knowledge, and non-transparent, untraceable reasoning processes. Retrieval-Augmented Generation (RAG) has emerged as a promising solution by incorporating knowledge from external databases. This enhances the accuracy and credibility of the generation, particularly for knowledge-intensive tasks, and allows for continuous knowledge updates and integration of domainspecific information.
Prompt engineering と RAG と Fine-tuning
この手の話をする際によくRAGと比較されるのがPrompt engineeringとFIne-tuningです。
この論文にも「RAG vs Fine-tuning」という節があり、詳しく説明されています。
まずPrompt engineeringについては「モデル固有の能力を活用するためのもの」とされています。例えば「あなたはプロのコピーライターです」とプロンプトの冒頭に付け加えると付け加えない場合より良いキャッチコピーが出力されたり、「小学生にもわかるように説明してください」とプロンプトの冒頭に付け加えると平易な言葉で説明してくれたり、というようなことがここに含まれます。ここではLLMが持っていない知識をプロンプトに入れることは含まれていません。
RAGは「情報取得用に調整した教科書をLLMに与える」と例えられています。質問に回答する際に、カンペを見ながら回答するようなものとも言えます。
一方Fine-tuningは「学生が時間をかけて知識を内面化していくようなもの」とされています。テストに向けて勉強を頑張るようなものと言えます。Survey論文内では「Fine-tuningは特定の構造、スタイル、フォーマットの再現を必要とするシナリオに適している」とされています。具体的にいうと、以下のブログで「LLMの出力を "ござる" 口調や、シェークスピアの文体に調整する」という事例が紹介されており、このような事例が当てはまると思います。
RAGとFine-tuningの比較において最も気になるのが「どちらの手法が、事前学習にない情報に関する質問に回答できるか」ということだと思います。これに関してはSurvey論文で紹介されているこちらの論文では「教師なしFine-tuningが（Fine-tuning前のモデルと比較して）若干の改善を示す一方で、RAGは、事前学習中に遭遇した既存の知識と全く新しい知識の両方に対して、一貫してFine-tuningのモデルの性能を上回ることを明らかにした」としています。
RAGの方がFine-tuningよりも高い性能を出せるとのことですが、だからといってFine-tuningが不要というわけではありません。Survey論文中でも「RAGとFine-tuningを組み合わせて使用することで、最適なパフォーマンスが得られる場合もある」とされており、後述するModular RAGや下図のようにRetrieverなどのFIne-tuningをRAGと組み合わせることにより、より高度なものにできるとのことです。
RAG の移り変わり
RAGは下図のように "Naive RAG", "Advanced RAG", "Modular RAG" のように変遷してきました。
それぞれの違いを説明していきます。
Naive RAG について
一番左の "Naive RAG" は最も単純な構造で、索引付け (indexing)、検索 (retrieval)、生成 (generation) の3つからなり、"Retrieve-then-Read" とも呼ばれます。単純に「RAG」というと、この方式を思い浮かべる人が多いと思います。
3つの処理を説明します。
索引付け (indexing) ではPDF、HTML、Word、Markdownなどのファイルからプレーンなテキストを抽出し、LLMが受け付けられる長さに分割し、Embeddingモデルでベクトル化などの検索時に役にたつ情報を取得する処理を実施してデータベースに保存します。
検索 (retrieval) ではユーザーからの質問をもとにデータベースを検索し、検索にヒットしたトップ数件をプロンプトに取り込みます。検索方法には全文検索やベクトル検索などあるのですが、Survey論文ではベクトル検索を使うことが前提となっているようです。
（検索方法の違いはそれに特化して紹介しているブログ記事がたくさんあるのでそちらに譲ります。）
生成 (generation) では事前に設定されている固定のプロンプトテンプレートにユーザーからの質問と検索にヒットしたテキストを流し込んで、それをもとにLLMにユーザーからの質問に対する回答を生成させます。
このような処理により、質問に回答するのにLLMの学習データに一切情報がなくても回答できるようになるわけですが、Naive RAGには以下のような欠点があるとされています（元々LLMが内包している問題も含まれます）。
- 検索の課題
- 欲しいテキストが検索にヒットするとは限らない
- 無関係なテキストがかり検索にヒットすることがある
- 生成の課題
- 検索結果にないことを生成する (Hallucination)
- 毒性、偏りの問題
- 補強 (Augumentation) の課題
- 異なるソースから検索した結果を統合すると、回答が支離滅裂になることがある
- 同じような情報が複数ソースから検索にヒットした場合、回答が冗長になることがある
Advanced RAG について
上記のようなNaive RAGの欠点を克服するために改良されたものが "Advanced RAG" とされています。
具体的にはNaive RAGの処理に対して、検索の前処理 (Pre-Retrieval) と後処理 (Post-Retrieval) が追加されています。
まず検索の前処理に関してです。Survey論文内のFig.3を見ると、検索の前処理はユーザーからの質問 (Query) に対する処理のみが対象になっているように見えますが、本文では索引付け (indexing) もここに含まれるとされています。
索引付け (indexing) に対する処理としては、インデックスされるコンテンツの質を高めるために以下のことが行われます。
- データの粒度の改善
- インデックス構造の最適化
- メタデータの追加
- アライメントの最適化
- 混合検索
ユーザーからの質問 (Query) に対する処理としては、ユーザーの元の質問をより明確にし検索タスクに適したものにする以下のことが行われます。
- クエリの書き換え
- クエリの変換
- クエリの拡張 （箇条書きで書いた手法の詳細は、後ろの章で詳しく説明します）
続いて検索の後処理に関してです。ユーザーからの質問（クエリ）にうまく回答するには、検索結果とクエリをうまくくっつける必要があります。そのために以下のことが行われます。
- 検索結果のリランク（並び替え）
- 検索結果の圧縮 （前処理と同様に箇条書きで書いた手法の詳細は、後ろの章で詳しく説明します）
Modular RAG について
Modular RAGはこれら2つのRAGの手法をさらに進化させ、適応性を汎用性を高めたもの、と表現されています。
Modular RAGは以下に示すようなモジュールを新たに取り込んでいます。
Searchモジュール
SearchモジュールはLLMが生成したコードやクエリを使って検索エンジンやデータベース、ナレッジグラフなど様々なデータソースを直接検索できるようにしてくれます。具体的な手法としてRAG Fusionが紹介されており、元のクエリをLLMに言い換えさせたものを複数生成して複数の検索を実行し、結果をリランクして利用する、ということが可能になります。
Memoryモジュール
MemoryモジュールはSurvey論文内での説明がわかりにくいので、引用されている論文を確認すると以下の説明がありました。
この論文で紹介されているSelf Memoryという手法では、LLMが応答生成時にユーザーからの質問に類似するものを会話履歴から引っ張ってくることでより良い回答を生成できるようになります。RAGで生成したものを下図のMemory sectorに入れておき、以降の生成時にユーザーのクエリに類似するものをMemory sectorから取り出して、それを使ってLLMが回答できるようにしているようです。これにより「会話履歴を全て与えなくても良い」となるのは大きいですね。
論文ではSelf Memoryによって、機械翻訳タスク、テキスト要約、対話生成の3つのタスクで性能改善が見られたとのことでした。
「これまでの会話履歴を検索できるようにする」というのは、RAGの性能向上に役立つそうです。
Routingモジュール
Routingモジュールでは、ユーザーのクエリから多様なデータソースのうちどこから調べるのが最適かをナビゲーションしてくれるとのことです。
Predictモジュール
Predictモジュールでは生成時に参照するコンテキストを検索するのではなく、「LLMで生成する」と説明されています。これによって冗長な情報やノイズを減らしつつ、クエリに対する関連性と正確性が高いコンテキストを生成できるとのことです。
引用されている論文によると、一般的なNaive RAGが"Retrive-then-Read"なのに対してこの手法を"Generate-then-Read"と表現しています。
この手法ではLLMにユーザーのクエリの関連文書を読ませて質問の回答になる部分を要約させ、その要約をもとにクエリに回答させます。論文では下図のクラスタリングベースの手法が最も効果的だったとのことです。
TriviaQAやWebQなどのオープンドメイン質問応答タスクで実験を行い、GenReadが最先端の検索して読むパイプラインを上回ったとのことです。
有効な手法ではありますが、関連文書全体をLLMに読ませる都合上、時間もお金もかかりそうな印象ではあります。
Task Adapterモジュール
Task Adapterモジュールは、ユーザークエリに含まれるタスクに合わせて使用するプロンプトを事前にプールしたものから取得し、プロンプトを動的に変えて処理を実行できるようにしています。
ここで引用されている論文では下図のような構造でユーザーからのInput（クエリ）に応じてプロンプトプールから適切なプロンプトを取得するためのEncoderを学習させる方法が紹介されています。
ここでは下式で算出されるLossでEncoderを学習させているとのことです。
これによって読解やClosed-book QA、言い換え検出などのタスクでゼロショットよりも性能を大きく向上できたと報告されています。また言語推論やコモンセンス推論などのタスクでは限られた改善しか見られなかったとされています。
その他の機能
上記のモジュール以外にもさまざまなRAGの機構が紹介されています。
- Rewrite-Retrieve-Read:
強化学習を使ってクエリを書き換えるSLMを学習させ、検索性能向上を図る
論文 - Recitation-Augmented Generation:
LLM内部の知識を引用して回答を生成する
論文 - Hypothetical Document Embeddings (HyDE):
ユーザーのクエリでなくLLMが生成した「仮想的な想定回答」に類似するテキスト探すことで検索性能向上を図る
論文 - Demonstrate–Search–Predict(DSP):
言語モデルと検索モデルを統合し、複雑な問題を小さな問題に分解して処理する
論文 - ITER-RET-GEN:
検索と生成を反復的に行うことで、より関連性の高い知識を取得し、生成結果の精度を向上させる
論文 - Forward-Looking Active REtrieval augmented generation (FLARE):
生成過程で必要な情報を動的に検索することで、言語モデル（LM）の精度とハルシネーションを抑える。生成された用語の確率によって示される生成プロセスの信頼性を監視することによって、タイミング検索を自動化している
論文 - Self-Reflective Retrieval-Augmented Generation (Self-RAG):
検索と自己反省を通じて必要に応じて生成の途中でも検索を行い、生成の品質を高める手法。“reflection tokens”を追加することでこれを実現している
論文
中でも検索を動的に実施するFLAREやSelf-RAGは、従来の固定的な処理しかできないRAGよりも良い性能が得られるのではないかと感じました。このような柔軟なアーキテクチャを扱い始めると、RAGだけでなくFine-tuningや強化学習などの他の技術との統合が重要になりそうです。
Retrievalについて
この章ではRAGの要、Retrieval (検索) についてが紹介されています。
検索データのソース
データ構造
検索対象のデータの構造は、非構造化データ（テキスト）から半構造化データ（PDFなど）、構造化データ（ナレッジグラフなど）に移り変わってきています。
半構造化データの課題の1つはRAGを頻繁に扱っている人にはお馴染みの問題かと思いますが、テキストの分割処理で表が途中で分割されて意味をなさなくなってしまうことです。もう1つの問題は表データを組み込むとセマンティック検索における類似性が複雑になってしまうことです。
これに関してSurvey論文内ではTableGPTのようなデータベース内のテーブルに対してText-2-SQLクエリを実行するLLMのコード機能を活用するアプローチ紹介されていますが、同時に「これでも最適な解決策とは言えず、研究の余地がある」としています。
構造化データとして紹介されているナレッジグラフ (KG) とRAGを統合した例としては、KnowledGPT や、グラフニューラルネットワークと統合したG-retriever が紹介されています。ナレッジグラフのような構造化データを使用することはRAGの回答の正確性向上には貢献しそうですが、構造化データベースの構築から維持に多大な労力が必要となることが問題になっているそうです。この辺りが手軽に使えればより便利になりそうです。
LLMがモデル内に保有している知識を、LLMが生成したテキストなどを通してRAGに活用する方法も紹介されています。前述のGenerate-then-Read やSelf Memoryの他、Self-knowledge guided retrieval augmentation (SKR) が挙げられています。
検索の粒度
検索にヒットするテキストの単位を長くすると余計な部分が多くて冗長になってしまうが、短くすると説明が途中で途切れて文章の意味が通らなくなってしまうという問題があるため、適切な単位で分割する必要があります。
Suervey論文内では分割の単位として、Token、Phrase、Sentence、Proposition、Chunks、Documentなどが挙げられています。Dense X では「どの単位で分割するのが良いか」を深掘りしており、その論文内ではProposition（命題）単位で区切って検索単位として処理するのが良い、と結論づけられています。個人的にはToken単位の分割しかちゃんとは試したことがなかったため、詳細が非常に気になるお題です。
KGにおいても検索粒度は重要とのことで、エンティティ、トリプレット、サブグラフが含まれるとのことです。
Index最適化
検索indexへのデータ格納時に気をつけるべきことがまとめられています。
Chunking
最も一般的な方法はテキストを一定の長さのtokenごとのchunkに分割することです。
問題となるのは「どれだけの長さごとに分割するか」で、chunkを大きくすると多くの情報を捉えられるもののノイズとなる情報も多くなり、chunkを小さくすると必要な情報を十分に盛り込めません。
また一定の長さでchunkを区切ると文の途中で途切れるため、chunk間でオーバーラップさせる対応が必要である。それでも不十分なことからSmall2Bigという文（small）を検索単位として使用し、前後の文を（big）コンテキストとして生成に使用する手法が提案されているそうです。
メタデータの付与
検索時にフィルタリングや範囲を指定するために、ページ番号、ファイル名、著者名、タイムスタンプなどのメタデータを活用できます。 またタイムスタンプに重みをつけることで、新しい情報を検索にヒットさせやすくする、というようなこともできます。
元のテキストに対して「段落の要約」や「想定QA」を生成して付与するような方法も紹介されています。
Indexの構造化
ファイルに親子関係がある場合、階層化index構造としてそれを活用することでどのchunkを抽出すべきか決める際の役に立つそうです。
またドキュメントの階層構造を構築するのにナレッジグラフを活用する方法も紹介されています。これにより異なる概念やエンティティ間のつながりを明確にし、錯覚の可能性を著しく低減する効果や、情報検索プロセスをLLMが理解できる命令に変換することで、知識検索の精度を高め、LLMが文脈的に首尾一貫した応答を生成できる効果があるそうです。
Survey論文内ではKnowledge Graph Prompting (KGP)という手法というナレッジグラフを活用して多文書質問応答に対応する手法が紹介されています。
RAGにおいて複数の文書から回答を生成したい場面によく出くわすので、詳しく読んでみたい論文です。
クエリ最適化
Naive RAGの課題の1つは、検索性能がユーザーからのクエリに左右されるということです。
ユーザーは常に明確で正確に質問を書いてくれるとは限りません。ユーザーは「何かがわからない」からこそ質問しているわけなので、質問内容が曖昧なことの方が多いのではないかと思います。
また前提なく略語を使うことも、混乱を招く一因となります（法律の文脈では「LLM」は「Master of Laws」になるのだとか）。
この章ではそのような問題への対応策が書かれています。
クエリの拡張
クエリを拡張する（言い換える）ことで、文脈を補強できることがあります。 以下の3つの方法が紹介されています。
- Multi-Query:
LLMによるクエリの言い換え - Sub-Query:
複雑な問題を小さくて簡単な問題に分割し、小さい問題に対する回答を1つ1つ作ってから組み合わせて最終的な回答を生成する
論文 - Chain-of-Verification(CoVe):
LLMが自分の生成した回答を検証し、誤りを訂正するプロセスを導入する。回答を検証するプロセスで「回答のチェックポイント」をLLMが設定して検索して確認する方式のため、ここに入れられていると思われる
論文
クエリの変換
「クエリの拡張」との違いが微妙なところですが、以下の手法が紹介されています。
- Rewrite-Retrieve-Read:
強化学習を使ってクエリを書き換えるSLMを学習させ、検索性能向上を図る。「SLMを学習させる」点がクエリ拡張と異なる点か（再出）
論文 - Hypothetical Document Embeddings (HyDE):
ユーザーのクエリでなくLLMが生成した「仮想的な想定回答」に類似するテキスト探すことで検索性能向上を図る（再出）
論文 - Step-back Prompting method:
元のクエリを抽象化し、上位概念の質問をLLMに生成させて回答する。質問の背景知識や必要な物理現象を問うような質問が生成される 論文
クエリのルーティング
クエリによって異なるRAG パイプラインにルーティングすることで、多様なシナリオに対応できるようになります。
そこまで詳しく説明がないですが、以下の2つの方法が紹介されています。
- Metadata Router:
クエリからキーワードを抽出し、そのキーワードとチャンク内のメタデータでフィルタリングを実施し、検索範囲を絞り込む手法 - Semantic Router:
クエリの意味的な情報をを使って検索範囲を絞り込みます。Survey論文で紹介されているgithubのrepositryを見る限り、事前にRouting先（どんな話題に分類してほしいかと、その例の文章）を先に定義しておいて、Embeddingモデルを使って事前に定義した文章とクエリの類似度から「どの話題に分類するか」を決めているようです
Embedding
ここではEmbeddingによるベクトル化の他、BM25などを使った全文検索やBERT系のモデルを使ったセマンティック検索との組み合わせの話が書かれています。
Embeddingモデルの性能比較に関しては、HuggingfaceのMTEBリーダーボードがおすすめとのことです。
ハイブリッド検索
全文検索やベクトル検索などの比較的計算量の軽い検索方法で絞り込んでから、BERT系のモデルリランクするようなハイブリッド検索が紹介されています。
Survey論文ではあまり詳しく説明されていないので、この辺りは他の詳しいドキュメントをあたるのが良いかと。
EmbeddingモデルのFIne-tuning
法律や医療のように専門用語が多く、事前学習のコーパスと大きく乖離している場合、独自のドメイン特化のデータセットでEmbeddingモデルをFIne-tuningすることが不可欠です。
社内独自の用語が多い場合もここに当てはまるでしょう。
以下のようなEmbeddingモデルのFIne-tuningの手法が紹介されています。
- Promptagator:
少数の例からクエリを生成し、それを基にリトリーバーを訓練することで、タスク固有のデータを用いずに高精度な検索を実現
論文 - LLM-Embedder :
報酬の最適化、知識蒸留、タスクごとの微調整、同一バッチ内の負例サンプリングなどの最適化手法を導入し、従来のタスク固有または汎用的なリトリーバーに対して、統一されたEmbeddingモデルを実現
論文 - RePlug:
外部コーパスから関連ドキュメントを検索し、それを言語モデルの入力に追加し、言語モデルのフィードバックを利用して検索モデルをチューニング。言語モデルを教師信号として扱い、特別なクロスアテンションメカニズムを不要に
論文
Adapter
タスクへのアライメントのためにLLMをFine-tiningするには様々な制約があるので、外部Adapterを組み込むというアプローチが取られることもあります。
以下のような手法が紹介されています。API経由で利用する高性能なLLMを「ブラックボックス」なものとして扱い、オープンソースのモデルをFine-tuningすることで回答の根拠に透明性を持たせようとする手法が多いように見受けられます。
- Universal Prompt Retrieval for Improving zero-Shot Evaluation (UPRISE):
ユーザーからのInput（クエリ）に応じてプロンプトプールから適切なプロンプトを取得するためのEncoderを学習させる（再出）
論文 - Augmentation-Adapted Retriever (AAR):
複数のダウンストリームに対応できる、ユニバーサルアダプターを学習させる手法。未知タスクも含め、ゼロショットタスク入力に適したプロンプトを事前に構築されたプロンプトプールから自動的に取得することができる
論文 - Pluggable Reward-Driven Contextual Adapter (PRCA):
Retrieverが検索してきたコンテキストを回答を生成するLLMに渡す際にどう圧縮するかを、「コンテキスト抽出段階」と「報酬駆動段階」の2段階で学習する。文脈抽出段階ではCNN Daily Mail datasetで BART-Large（BERTではない）を事前学習したモデルを使用し、報酬駆動段階では強化学習で最終的な回答がよくなるように学習する。報酬は生成された回答と正解データのROUGE-Lスコアを使用している。検索された情報を改良するAdapterとして紹介されている
論文 - Bridging the Gap between retrievers and LLMs (BGM):
人間にとって有用な情報とLLMにとって有用な情報にギャップがあることを加味して作られた、RetrieverとLLMの間の嗜好のギャップを埋めるための橋渡しモデル。検索結果をLLMが効果的に利用できる形式に変換する
論文 - Parametric Knowledge Guiding (PKG):
オープンソースのモデル (LLaMa 7B) をFIne-tuiningし、ブラックボックスだがより高性能なLLMに渡す情報を適切に加工する
論文
Generationについて
検索にヒットしたものを全てを回答を生成するLLMのインプットとするのは良くありません。
この章では「検索結果の調整」と「LLMの調整」の2つの観点で改善方法が紹介されています。
検索結果のキュレーション
LLMのインプットとする文章が冗長だと、回答に必要な情報を見失ってしまうことがあることが指摘されています。
こちらの論文 では、gpt-3.5-turbo-0613で長いテキストの最初と最後の情報にばかり注目し、途中の情報をうまく活用できないことが指摘されています。
このことから「検索された文章の処理」が重要となります。
リランキング
検索結果をリランキング（再順位付け）する方法が紹介されています
- Open-source Large Language Models are Strong Zero-shot Query Likelihood Models for Document Ranking:
LLaMA-7BやFalcon-7Bを活用したリランキング（ゼロショット）
論文 - DiversityRanker:
検索結果の多様性を高める手法。上位に選択済みのコンテキストの埋め込みの平均との類似度が低いものを順に入れていく
リンク - LostInTheMiddleRanker:
前述の「LLMが長いテキストの最初と最後の情報にばかり注目してしまう」性質に対応するために、コンテキストの最初と最後に検索結果の上位を入れる手法。 10 個のドキュメントを並べ替える場合、 [1 3 5 7 9 10 8 6 4 2] という順番になる
リンク
Contextの選別・圧縮
ここではまず、「RAGプロセスでよくある誤解は、できるだけ多くの関連文書を検索し、それらを連結して長い検索プロンプトを形成することが有益であると考えることである」と断言されています。
ここ最近で受け付けられるコンテキスト長が膨大なLLMが出てきており、「検索対象のドキュメントをすべて入れればいいのではないか」という意見を身の回りで聞くようになり違和感を覚えていたのですが、ここでこれだけそのように断言されているのは興味深いです。
過剰なコンテキストはノイズとなりLLMが重要な情報を認識できなくなるので、ノイズを減らすことが重要であり、以下のような手法が紹介されています。
- LongLLMLingua:
GPT-2 SmallやLLaMA-7Bのような小さな言語モデル（SLM）を利用し、重要でないトークンを検出して削除し、人間には理解しにくいがLLMにはよく理解できる形に変換する。入力が「∼4x fewer tokens」になったとのこと
論文 - Pluggable Reward-Driven Contextual Adapter (PRCA):
Retrieverが検索してきたコンテキストを回答を生成するLLMに渡す際にどう圧縮するかを、「コンテキスト抽出段階」と「報酬駆動段階」の2段階で学習する。文脈抽出段階ではCNN Daily Mail datasetで BART-Large（BERTではない）を事前学習したモデルを使用し、報酬駆動段階では強化学習で最終的な回答がよくなるように学習する。報酬は生成された回答と正解データのROUGE-Lスコアを使用している。（再出）
論文 - RECOMP (Retrieve, Compress, Prepend):
検索にヒットしたものから関連する文を選ぶ「抽出型コンプレッサー」と検索にヒットした複数の文書から要約を生成する「要約型コンプレッサー」の二つを導入し、ドキュメントを要約して必要な情報のみを抽出する。LLMに渡す検索結果のtoken数を1/10以下にしつつ、同等以上の回答品質が実現できているとのこと
論文 - Dense passage retrieval for open-domain question answering:
BERTを活用したベクトル検索
論文 - Filter-Reranker:
SLMが簡単なサンプルをフィルターし、LLMが難しいサンプルをリランキングする手法。「Fine-tuningしたSLMの方がLLMよりも高性能なタスクはSLMにさせる」という思想で作られている
論文 - ChatLaw:
最終的な答えを生成する前に、LLMに検索にhitしたコンテンツを評価させる手法。法的分野におけるモデルの信頼性と性能を向上できたとのこと。
論文
FIne-tuning
LLMの使われ方と想定されるデータの特性に基づいてターゲットを絞り込んでFine-tuningすることで、より良い結果を得ることができる。
LLMに知識を追加したり、入手力の形式を調整できる。
- Retrieval-Augmented Generative Question Answering (R-GQA):
クエリに類似するQAペアを学習データセットから検索し、それをプロンプトとして使用する。これにより類似したデモンストレーションから推論できるようになっている。
（この章で紹介されているが、Fine-tuningでなくFew-shot learningである）
論文 - Structure Aware Dense Retrieva (SANTA framework):
構造化データの効果的な検索を実現するために、事前学習でStructured Data Alignment (SDA) とMasked Entity Prediction (MEP) が用いられる。SDAではmask language modelingだけでは不十分な構造化データを理解できるようになるために、contrastive learningを行い構造化データを非構造化データにアラインさせる。MEPでEntityをマスクし、マスクされた部分を埋めるように継続学習を行う
論文 - Dual-Feedback Knowledge Retrieval for Task-Oriented Dialogue Systems:
RetrieverとGeneratorを分離し、Generatorからのフィードバック（ポジティブフィードバック・ネガティブフィードバック）を使ってRetrieverの学習を行う。ポジティブフィードバックは、検索にhitしたそれぞれのエンティティに対応する応答の条件付き生成確率に基づいて算出される（あるEntityと応答の関連性が高ければ、このEntityに対応する応答の条件付き生成確率も高くなる）。ポジティブフィードバックを利用することで、参照応答からGeneratorが学習した知識に基づいて、Retrieverの学習を行える。ジェネレーターの仮説応答からサンプリングしたネガティブサンプル（高い生成確率を示すが質の低い応答、質はBLEUで算出）に基づいてネガティブフィードバックを構築し、正のフィードバックをキャリブレーションする。
論文 - Retrieval-Augmented Dual Instruction Tuning (RA-DIT):
LLM (Generator) とRetrieverを別々にfine-tuningする。LM-ftでは検索で補強されたプロンプトによる命令が与えられたときの正解の尤度を最大にするようにLLMを更新し、R-ftではRetrieverの確率分布とLLMの出力の確率分布との間のKL-ダイバージェンスを最小にするようにRetrieverを更新する（LLMが正解を生成する可能性を向上させるチャンクにより高いスコアを割り当てられるようになる）
論文
上記の他にGPT-4などの強力なモデルの出力を蒸留するのも効果的と紹介されています。
（https://openai.com/ja-JP/policies/terms-of-use/的に大丈夫か、というのはありますが。。「OpenAIと競合するモデル」の定義次第か。。）
RAGにおけるAugmentationプロセスについて
RAGの標準的な手法は多くの場合一度だけ検索してそれを基に生成するが、これだと限られた情報しか引き出せず、他段階の推論が必要となる複雑な問題に対して不十分となります。ここでは以下の3つの方法が紹介されています。
Iterative Retrival
Iterative Retrivalは最初のクエリとこれまでに生成されたテキストに基づいてデータベースを繰り返し検索するプロセスです。
何度も検索を繰り返すことで、追加の文脈参照を提供し、その後の回答生成の頑健性を高めることが示されています。
こちらの論文では、Iterative Retrieval-Generation Synergy (Iter-Ret Gen) という検索と生成の反復によって大規模言語モデル（LLM）の性能を向上させる手法が紹介されています。
この手法では生成された内容を基に追加の関連情報を検索し、それを次の生成に活用するプロセスを繰り返すことで回答に必要な情報を充実させ応答の質を向上させています。
Recursive Retrieval
Recursive Retrievalでは以前の検索で得られた結果に基づいて、検索クエリを繰り返し改良していきます。
このようなフィードバック・ループを通じて最も適切な情報に徐々に収束させることを目的としています。
具体的な手法としては、以下が紹介されています。
- Interleaving Retrieval with Chain-of-Thought Reasoning (IRCoT):
検索と検索結果を基にしたChain of Thoughtによる検索クエリの改善を繰り返す手法。生成されたCoT文が "answer is: "の文字列を持つか、最大ステップ数4に達したら処理を終了する
論文 - Tree of Clarifications (ToC):
あいまいな質問を明確化するための質問の木を再帰的に構築し、回答を生成する手法。有用でない枝を刈り込む仕組みも取り込まれている
論文 - Chain-of-Knowledge:
固定された知識ソースを使用するのではなく、CoKは異なる知識ソースを動的に適応させ、特定のドメインに関連する知識を効果的に取得する。これを実現するために推論準備（関連する知識領域の特定とCoTによる仮の回答生成）、動的知識適応（検索結果を活用した回答の修正）、回答統合の3つの段階からなる
論文
Adaptive Retrieval
これまでの2つの手法よりも、外部からの知識検索が必要かどうか、いつ検索と生成を停止するかをRAGシステムが自律的に判断できることに重点が置かれています。
ここでは以下のような手法が紹介されています。
- Forward-Looking Active REtrieval augmented generation (FLARE):
生成過程で必要な情報を動的に検索することで、言語モデル（LM）の精度とハルシネーションを抑える。生成された用語の確率によって示される生成プロセスの信頼性を監視することによって、タイミング検索を自動化している（再出）
論文 - Self-Reflective Retrieval-Augmented Generation (Self-RAG):
検索と自己反省を通じて必要に応じて生成の途中でも検索を行い、生成の品質を高める手法。“reflection tokens”を追加することでこれを実現している（再出）
論文 - AutoGPT:
個々の行動ステップごとに「思考」、「推論」、「計画」、「批評」を生成することで自己モノローグ行え、簡単な指示といくつかのツールの使用例によって、様々なツールを活用でき、長期的な自己記憶と記憶検索が組み込まれているエージェント。人間からのステップバイステップのガイダンスを必要とせず、目標の定義や道具の説明をするだけでタスクをこなせる
論文 - Toolformer:
言語モデルが直接外部ツールの使用方法を学習できる手法。使わせたいtoolを呼び出すspecial tokenを新たに追加し、事前学習データ内に挿入する（位置の候補は言語モデルに選ばせる）。挿入後「tool有無によって次token予測のlossが一定以上減少したかどうか」を確認し、lossが現象したspecial tokenのみを残し、事前学習に使用する。これにより、言語モデルが文章生成中に必要に応じてtoolを使えるようになる
論文 - GraphToolformer:
ChatGPTによってさまざまなドメインからの入力グラフデータと簡単な手順を含むfew-shotプロンプトにより、外部グラフ推論ツールのグラフ推論 API 呼び出しを含む大規模なプロンプトデータセットに注釈を付けることで、LLMに対してグラフデータに関する推論能力を付与する手法。検索プロセスを明確なステップに分け、LLMが積極的にRetrieverを使用し、Self-Ask技術を適用し、検索を開始するためにfew-shotプロンプトを使用する。これによりLLMは必要な情報を検索するタイミングを自分で決められるようになる
論文 - WebGPT:
GPT-3モデルをテキストベースのウェブブラウジング環境で行動模倣学習、報酬モデリング、強化学習、およびリジェクションサンプリングを組み合わせてfine-tuningし、GPT-3が検索の実行、リンクのクリック、スクロールなどを実行できるようになる
論文
タスクと評価
タスクとデータセット
下表のようなタスクとデータセットが紹介されています。
評価指標
どのようなことを評価かによって適している評価指標が異なります。
このSurvey論文では以下の表にまとめられています。
Discussion・今後の課題
RAG VS Long Context
LLMの研究開発が進むにつれ、LLMが入力として受け付けられるtoken数が増加しています。
Gemini 1.5は100万ものtoken処理できることで話題を呼んでいます。
ここまで長大なtokenを入力できるようになると「RAGは本当に必要なのか、検索対象の文書を全て入れればいいのではないか」という議論を呼んでいます。
議論は盛り上がるものの、まだRAGはなくなっていません。というのも「検索対象の文書全てをLLMの入力とする」という行為には以下のデメリットがついてくるからです。
- 推論速度の低下
（RAGは検索にhitしたもののみを処理するので、素早く推論できる） - 生成ログを見ても「何を基に回答したか」がわからない
（RAGは検索結果を見れば絞り込める）
一方でこちらの論文によると「コンテキストの拡張はRAGの開発に新たな機会を提供し、より複雑な問題や、回答するために大量の資料を読む必要がある統合的または要約的な質問に対処することを可能にする」とされていて、今後の更なる研究が待たれる話題です。
RAGの頑健性
検索中にノイズや矛盾する情報が存在すると、RAGの出力品質に悪影響を及ぼす可能性があり、この状況は「誤った情報は、全く情報がないよりも悪いことがある」と呼ばれるとのことです。
このような事態への対応として、敵対的または反事実的な入力に対するRAGの耐性を向上させるための研究が盛んになっています。
Survey論文では以下の研究結果や手法が紹介されています。
最後の論文の結果が直感と反しており、更なる研究が待たれます。
- Chain-of-Note (CoN):
取得したドキュメントの関連性を評価し、信頼できる情報を特定する手法
論文 - Making retrieval-augmented language models robust to irrelevant context:
自然言語推論（NLI）モデルを用いて不要なコンテキストを識別し、ファインチューニングによってモデルが不要な情報を無視するようにした手法
論文 - Knowledge-Augmented Language Model Verification:
言語モデルが生成する回答を外部のKnowledge baseと照合し、その正確性を評価し、Knowledge baseからの情報を基に、回答を補強または修正する手法
論文 - The Power of Noise: Redefining Retrieval for RAG Systems:
クエリに関連性のない文書が生成結果に与える影響を評価した論文。関連性のない文書を含めると、予想に反して30％以上も精度が向上するとのこと。
論文
ハイブリッドアプローチ
RAGとFine-tuningの組み合わせは、有力な戦略として浮上しています。
前述のRA-DITのようにLLM (Generator) とRetrieverを別々にfine-tuningする手法のほか、こちらの論文ではSLMが取得された文書の品質を評価し、必要に応じて外部のウェブ検索を利用して情報を補完できるようにFine-tuningするCRAGという手法が紹介されています。
RAGにおけるScaling laws
End-to-EndなRAGモデルやRAGに基づく事前学習済みモデルが出てきていますが、そこにもScaling lawsが成立するのかはまだ不確かとこのSurvey論文内ではされています。
Retro++が「この分野の初期の取り組み」として取り上げられていますが、RAGモデルのパラメータ数はまだまだ小さいとされています。
Production-ReadyなRAG
まずRAGは実用的だが、「LLMによる文書ソースやメタデータの不用意な開示の防止といったデータセキュリティの確保」が解決すべき重要課題と指摘されています。
またRAGにおける重要なツールやライブラリとしてLangChainやLLamaIndexのほか、Flowise AIのようなローコードツールやHayStack、Meltano、Cohere Coralなどが紹介されています。
ソフトウェアプロバイダーやクラウドサービスプロバイダーがRAGを中心としたサービスを拡大していることも紹介されています。
RAGの技術開発においては、以下の方向性があるとされています。
- 特定の要件に合わせてRAGをカスタマイズ
- RAGを使いやすくし、最初の学習コストを減らす
- RAG を最適化して、実稼働環境でのサービス向上
インフラ等の技術スタックの技術革新がRAG技術の促進を促していく点も指摘されています。
Multi-modal RAG
近年テキストの他のmodal（特に画像）を取り込む研究が盛んになっています。
Survey論文内では以下の技術が紹介されています。
Image
- Retrieval-Augmented CM3 (RA-CM3):
CLIPを使用したMulti-modal検索と、LAIONデータセットで学習したCM3 Transformerを組み合わせ、取得したドキュメントを用いてテキストと画像の生成する手法
論文 - BLIP-2:
事前学習済みの画像エンコーダと大規模言語モデル（LLM）を用いて、視覚と言語の事前学習を効率化する手法。ゼロショット画像からテキストへの変換を可能にしている
論文 - Visualize Before You Write:
生成するテキストに一貫性を持たせる目的で、テキスト生成前に画像を生成させてそれに基づいてテキストを生成する手法
論文
Audio と Video
- Generating Synthetic Speech (GSS):
End-to-Endの音声翻訳システムの学習のために、SpokenVocabを用いて機械翻訳データを音声データに変換する手法。SpokenVocabは事前に用意した音声辞書から単語ごとに音声スニペットを取得し、それらを結合することで合成音声を生成する。これにより機械翻訳データをその場で音声翻訳データに変換できるようになる
論文 - Using External Off-Policy Speech-To-Tex (UEOP):
オフラインで更新できる1000万単語/フレーズからなる外部メモリを活用して、End-to-Endの自動音声認識モデルを改善する手法
論文 - Vid2Seq:
人手でアノテーションされたデータセットを学習データとしていた従来手法と異なり、ナレーション付き動画を活用することで大規模データセットでの事前学習を可能とした手法
論文
Code
- Retrieval-Based Prompt Selection for Code-Related Few-Shot Learning:
本文を読めていないですが、アブストによると類似するタスクのコードを検索し、ヒットしたものを例としてコード生成時のプロンプトに盛り込むことでコード生成の性能が向上したとのこと
論文
最後に
今回はRAGのSurvey論文に関してまとめてみました。
最初は「論文1本読むかー」ぐらいの気持ちで始めたのに、Survey論文だけではわからないことを1本引用元まで辿って読んでみたら理解が深まったので「じゃあ他の引用されてる論文も読むかー」と引用元をどんどん辿っていったら、気づけば50本ほど論文を読んでいました。
今回は紹介されている手法をただただ紹介するだけにはなりましたが、ただ列挙するだけでも「こんな手法があったのか」とかなり勉強になりました。
本記事が参考になれば幸いです。
