RAGとは？検索した資料をLLMの回答へつなぐ仕組み
LLMに社内規程の最新版について質問しても、その規程が入力にないなら、モデルの事前学習だけから正しく答えられるとは限らない。RAG（Retrieval-Augmented Generation）は、質問に関係する資料を先に探し、見つけた内容を回答生成時の文脈として渡す構成だ。モデルの重みを更新せずに、外部の情報を利用できる。
「資料を検索するだけなら普通の検索と同じでは？」という疑問がある。RAGでは、検索結果をそのまま一覧表示するのでなく、LLMが複数の資料を読んで質問への回答を組み立てる。一方で、検索に失敗すれば、生成の段階だけを改善しても根拠のない回答を防げない。
検索と生成は、別々に失敗し得る
典型的な流れは、資料を検索できる形に用意し、質問に関係する断片を選び、質問と断片をモデルへ渡して回答を作る、というものだ。たとえば規程の「休暇申請期限」を尋ねられたとする。古い版の規程を検索してしまえば、モデルがその断片へ忠実でも答えは古い。正しい版を検索しても、例外条件の段落を渡し忘れれば回答は不完全になる。
したがって、評価は少なくとも「必要な資料を見つけたか」と「渡した資料に基づいて答えたか」に分ける。引用元のURLや文書IDを回答と一緒に示せば確認しやすいが、引用を付けただけで内容が正しいと保証されるわけではない。参照箇所が実際に答えを支えているかを確かめる必要がある。
RAGの原論文と、現在の一般的な使い方
Lewisらの原論文『Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks』は、検索器と生成器を組み合わせ、モデルのパラメータに保持する知識と、外部の文書集合から取り出す知識を合わせて使った。論文中のRAGは特定の学習・推論方法を持つモデルである。
現在「RAG」と呼ばれる実務上の構成は、それより広い。文書検索をアプリケーション側で行い、得た断片を既存のLLMへ渡す方式もRAGと呼ばれる。原論文と同じモデルを使うことや、検索器と生成器を一体で学習することは必須ではない。Hugging Faceの資料も、文書集合を検索してから質問への回答に使う構成を示している。
ベクトル検索だけが検索ではない
Embeddingで質問と文書をベクトル化し、近い断片を探す方法はRAGでよく使われる。Dense Passage Retrievalの論文は、質問と文書を密なベクトルで表す検索器を提案した。しかし、RAGという名前にベクトル検索の使用は含まれていない。語句の一致に強い検索、ベクトル検索、その組み合わせ、検索結果の再ランキングなど、目的に応じて方法を選べる。
例えば、製品番号や条文番号のような正確な文字列を探す場合、意味が近い文書だけを選ぶと取りこぼすことがある。逆に、質問と言い回しが違う資料を探す場合は、表層の一致だけでは足りない。どの検索が適切かは、実際の質問と正解資料の組を用意して測る。
外部資料を渡すことの限界
RAGはモデルの知識を恒久的に書き換えない。検索した断片は、その回答時の文脈に入る。Context Windowを超える量の資料はそのまま渡せず、長く渡せても重要な箇所を使い損ねる可能性がある。
さらに、取得資料が誤っていたり、悪意ある指示を含んでいたりする場合もある。検索結果は根拠の候補であり、モデルへの上位命令ではない。アクセス権のある文書だけを検索し、本文中の命令文を無条件に実行しない設計が要る。新しい情報を渡せることと、信頼できる回答を自動的に得ることは同じではない。
RAGを作るときの出発点は、検索器の種類を先に決めることではない。どの質問に、どの資料の、どの箇所が必要かを定める。そのうえで検索の取りこぼしと回答の根拠のずれを別々に測れば、どこを直すべきかが見えてくる。
参照資料
- Lewisほか『Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks』
- Karpukhinほか『Dense Passage Retrieval for Open-Domain Question Answering』
- Hugging Face Transformers: Expanding Chat Templates with Tools and Documents
- Greshakeほか『Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection』