RAG vs ファインチューニング
RAGは外部知識を検索してプロンプトに組み込むことでLLMの回答を根拠づける手法、ファインチューニングは追加データでモデル自体の重みを更新する手法。知識の最新化のしやすさと、モデル自体の挙動・文体の変更しやすさという異なる強みを持つ。
3行で違いを説明
- RAGはモデルを再学習せず、検索した外部知識をプロンプトに追加して回答させる手法。
- ファインチューニングはモデル自体の重みを追加学習し、特定タスクやドメイン・文体へ適応させる手法。
- 知識の更新頻度が高い場合はRAG、モデルの振る舞いや文体そのものを変えたい場合はファインチューニングが向く。両者を組み合わせる構成も広く使われる。
Comparison Table
| Item | RAG | ファインチューニング |
|---|---|---|
| Purpose | 外部知識に基づく回答の根拠づけ・最新化 | 特定タスク・ドメインへのモデル適応 |
| Developer | 手法(Lewisらが提案) | 手法(転移学習の一種) |
| Release | 2020年(論文発表) | LLM文脈では2018年前後(ULMFiT/BERT)から普及 |
| License | 該当なし(手法) | 該当なし(手法) |
| Open Source | 実装(LangChain・LlamaIndex等)はオープンソースのものが多い | 実装(Hugging Face PEFT等)はオープンソースのものが多い |
| API | ベクトルデータベース・埋め込みAPI・LLM APIを組み合わせて実装 | 各LLMプロバイダのファインチューニングAPI、またはローカルでの学習スクリプト |
| Programming Language | Python(LangChain等)が主流 | Python(Hugging Face Transformers/PEFT等)が主流 |
| Ecosystem | ベクトルデータベース・埋め込みモデル・RAGフレームワークのエコシステム | LoRA・PEFT等パラメータ効率的学習手法のエコシステム |
Architecture
Feature Comparison
| Feature | RAG | ファインチューニング |
|---|---|---|
| モデル再学習の要否 | 不要 | 必要 |
| 知識更新の即時性 | ○ | — |
| 文体・振る舞いの変更 | — | ○ |
| 出典提示のしやすさ | ○ | — |
| 追加インフラ(ベクトルDB等) | ○ | — |
Advantages
RAG
- 検索した根拠に基づくことでハルシネーションを低減
- モデルを再学習せずに知識を更新できる
- 出典の提示に対応できる
ファインチューニング
- 狭いドメイン固有タスクでの性能を向上させる
- パラメータ効率的手法により限られた計算資源でも利用しやすい
Disadvantages
RAG
- 検索精度が回答品質全体のボトルネックになる
- ベクトルDB・インデックス構築など追加のインフラと遅延が発生する
ファインチューニング
- 汎用能力を失う破滅的忘却のリスクがある
- タスク固有の厳選された学習データが必要
Best Use Cases
RAG
社内文書検索や最新情報を反映した回答が必要なチャットボット、頻繁に更新される知識ベースを扱うアプリケーション。
ファインチューニング
特定ドメイン(医療・法律等)への特化や、一貫した文体・振る舞いをモデル自体に持たせたい場合。
Migration
RAGからファインチューニングへ切り替える(あるいは併用する)場合、検索対象の文書群を学習データセットとして整形し直す必要がある。両者は排他的でなく、ファインチューニングで基本的な振る舞い・文体を調整しつつRAGで最新知識を補うハイブリッド構成も広く使われる。
FAQ
RAGとファインチューニング、どちらを使うべき?
知識の更新頻度が高く出典提示も必要ならRAG、モデルの振る舞い・文体・専門用語の使い方自体を変えたいならファインチューニングが向く。両方の要件がある場合は組み合わせて使われることも多い。