RAGとは？回答する前に関連資料を検索して、LLMへ根拠として渡す

AIに「海外出張ホテルの現在の上限はいくら？」と聞く場面を想像してください。

答えは先週更新された社内規程に書かれているかもしれません。Base LLMは、その最新版を学習していない可能性があります。

そこで使われる代表的な方法が**Retrieval-Augmented Generation (RAG、検索拡張生成)**です。

Open Book Examで考える

Closed Bookの試験では記憶だけで答えます。

Open Bookなら、まず正しいページを探し、それを読んでから回答できます。

RAGも似ています。

Model Weightを必ず変更するのではなく、回答する瞬間のContextへ関連資料を追加します。

典型的なRAG Pipeline

1. Documentを集める
2. Documentを小さなChunkへ分割
3. ChunkのEmbeddingを作る
4. Vector Databaseへ保存
5. User QuestionもEmbedding化
6. 関連ChunkをRetrieve
7. RetrieveしたChunkをLLM Contextへ入れる
8. その資料を使って回答させる

第021回のEmbeddingと第022回のVector Databaseがよく使われます。

なぜChunkへ分ける？

300ページのManual全体を一件として検索すると、必要部分だけを正確に取り出しにくくなります。

小さいChunkは検索精度を上げやすい一方、小さすぎると前後関係が失われます。

そのためChunk Size、Overlap、Heading Structureなどは重要な設計項目です。

Retrievalが外れると回答も外れる

検索段階で間違った文章を取ってきたら、LLMには正しい根拠が入りません。

文章が自然でも、必要な資料を最初から見ていなければ答えは間違います。

RAGを評価するときは、少なくとも、

• 正しいEvidenceをRetrieveできたか
• LLMがそのEvidenceを正しく使ったか

を分けて考えます。

Hallucinationを減らせても、ゼロにはならない

資料を渡しても、LLMが読み違えたり、無視したり、別の文章と誤って組み合わせたりすることがあります。

そのため実用システムでは、

• Evidence不足なら「分からない」と答えさせる
• Citationを表示する
• Retrieved Documentだけを根拠にする
• Rerankerを使う
• Permission / Metadata Filterを入れる

などを組み合わせます。

RAGとFine-tuningの違い

RAGは、頻繁に変わるFactsやPrivate Knowledgeを回答時に渡すのが得意です。

Fine-tuningは、繰り返し現れるBehavior、Style、Task、Output FormatなどをModel Parameterへ反映したいときに使われます。

両方を一緒に使うこともできます。

次の第024回でFine-tuningを詳しく見ます。

今日の一文

RAGとは、回答時に関連する外部情報を検索し、その情報をContextとしてLLMへ渡してから生成する方法です。