ローカルRAGとは？追加学習との違いと最小構成を整理する

RAGは、LLMへ新しい知識を直接「覚えさせる」仕組みではない。

質問を受けたときに手元の文書から関係する部分を探し、その内容を質問と一緒にLLMへ渡して回答を作る方法だ。

社内文書や自分のPDFへ質問したい場合、文書が変わるたびにモデルを追加学習する必要はない。元文書を差し替えて検索対象を更新できるRAGの方が扱いやすい場合がある。

ただし、RAGを使えば誤回答がなくなるわけではない。文書の読み取り、分割、検索、回答生成のどこでも失敗できるため、段階を分けて見る。

図を拡大して見る

図: 主な比較軸を1枚に整理。細かな条件は本文と表で確認する。

RAGは5つの処理に分けて考える

文書
 ↓
1. 文書を読み取る
 ↓
2. 検索しやすい単位へ分ける
 ↓
3. 意味を表す数値へ変換する
 ↓
4. 質問に関係する部分を検索する
 ↓
5. 取得した文書と質問から回答を生成する

1. 文書を読み取る

PDF、Word、テキストなどから検索に使える文字列を取り出す。スキャンPDFならOCRが必要になる場合もある。

ここで文字化けしたり、表の並びが崩れたりすれば、その後の検索方法を工夫しても失われた情報は戻らない。

2. 文書を検索しやすい単位へ分ける

長い文書を、検索へ使う小さなまとまりに分ける。

ページ単位、見出し単位、一定の文字数など方法は複数ある。細かすぎれば前後関係が切れ、長すぎれば関係の薄い情報まで同じまとまりへ入る。

すべての文書に共通する一つの分割サイズがあるわけではない。

3. 文書と質問を意味を表す数値へ変換する

Ollamaの公式資料では、埋め込みを文章の意味を数値ベクトルへ変換し、意味検索やRAGへ利用する仕組みとして案内している。

文書の各まとまりと質問を埋め込みへ変換すると、同じ単語が含まれるかだけでなく、意味の近さを使った検索ができる。

埋め込みの次元数が大きいだけで日本語検索の品質が高いとは判断できない。自分が使う質問と文書で確かめる。

4. 質問に関係する文書を取得する

質問に近い文書のまとまりを検索する。

ここで必要な箇所を取得できなければ、回答を作るLLMへ正しい根拠が渡らない。

「LLMが間違えた」と見える問題でも、実際は検索段階で正しい文書を取れていないことがある。

5. 取得した文書と質問から回答を作る

最後に、検索で得た内容と質問をLLMのコンテキストへ入れて回答を生成する。

LM Studioの文書チャットでも、長い文書では質問に関係する部分を取得してコンテキストへ渡すRAGの経路が公式に案内されている。

この段階にはLLMの生成が入るため、正しい文書を渡しても回答が必ず原文どおりになるとは限らない。

RAGと追加学習は変更する場所が違う

RAGとファインチューニングを「どちらが高性能か」だけで比べると分かりにくい。変えている場所が違うからだ。

方法	主に変えるもの	文書更新への対応
RAG	推論時に渡す外部文書	検索対象を更新する
ファインチューニング	モデルの重みや振る舞い	通常は再学習の工程が必要

手元の規程、手順書、議事録のように「内容そのものを参照させたい」用途では、まずRAGを検討しやすい。

一方、特定の出力文体や作業手順をモデルへ学ばせたい場合は、RAGだけでは目的が違う。

最初は正解箇所を確認できる文書を使う

最初の評価では、答えが原文のどこにあるか人が確認できる文書が向いている。

たとえば、

• 社内規程の期限や条件
• 製品手順書の操作方法
• 会議記録の決定事項
• FAQの既知回答

などだ。

複数文書をまたぐ高度な推論や、原文に答えがない質問から始めると、検索と回答生成のどちらを評価しているのか分かりにくくなる。

10ページ程度の小さなテストから始める

1. 答えを知っている文書を一つ選ぶ
2. 正解箇所が異なる質問を5〜10個作る
3. 検索された文書へ正解箇所が含まれるか見る
4. 回答が原文と一致するか別に見る
5. 「文書に答えがない質問」も一つ混ぜる

これだけでも、「検索できていない」のか、「正しい文書は取れたが回答生成で崩れた」のかを分けられる。

LM Studioで文書を一つ試す場合は、PDFや文書へオフラインで質問する手順へ進める。長い文書がモデルのコンテキストへどう入るかを整理したい場合は、コンテキスト長の基本も確認できる。