RAFTとRAG、標準SFT、DSFTの比較分析。RAFTはRAGパイプラインのLLMをファインチューニングしてretriever出力の文書群からの情報抽出を最適化する手法で、推論コストはRAGと同等だが精度が大幅に向上する。各手法の精度、コスト、レイテンシ、運用負荷のトレードオフを詳細に比較する。
LLMをドメイン固有のQAタスクに活用する手法は大きく4つに分類される。RAG（Retrieval-Augmented Generation）、SFT（Supervised Fine-Tuning）、DSFT（Domain-Specific Fine-Tuning）、そしてRAFT（Retrieval Augmented Fine-Tuning）である。各手法には固有の長所と短所があり、ユースケースに応じた適切な選択が重要である。
| 手法 | 概要 | 知識源 |
|---|---|---|
| RAG | retrieverで文書取得→LLMに渡す | コンテキスト文書 |
| SFT | 汎用QAデータでファインチューニング | パラメトリック知識 |
| DSFT | ドメイン固有データでファインチューニング | ドメインパラメトリック知識 |
| RAFT | RAGコンテキストを含むデータでファインチューニング | コンテキスト + パラメトリック |
この比較では、論文「RAFT: Adapting Language Model to Domain Specific RAG」の実験結果と、実務での経験を踏まえて各手法の特性を詳細に分析する。
論文で報告された主要ベンチマークでの性能比較を以下に示す。数値はタスクとモデルにより異なるが、相対的な傾向を表している。
| 手法 | PubMedQA | HotpotQA | ドメイン固有QA | 汎用QA |
|---|---|---|---|---|
| RAG（ベースLLM） | 中 | 中 | 中 | 中〜高 |
| SFT | 低〜中 | 低〜中 | 低 | 中 |
| DSFT | 中 | 中 | 中〜高 | 低〜中 |
| RAFT | 高 | 高 |
| 中 |
RAFTが他の手法を一貫して上回る理由は、以下の3点に集約される：
ドメイン固有タスクでは、RAFTとRAGの差が最も顕著になる。RAGは汎用LLMのコンテキスト理解能力に依存するため、専門用語や複雑な推論を要するタスクでは限界がある。RAFTはドメイン固有のコンテキストから情報を抽出する能力を直接訓練するため、この限界を大幅に緩和する。
具体的な数値例として、医療QAタスクでは：
この差は、医療文書特有の複雑な表現と、類似症例間の微妙な違いを識別する能力に起因する。
| コスト項目 | RAG | SFT | DSFT | RAFT |
|---|---|---|---|---|
| データセット構築 | 低（文書インデックスのみ） | 中（QAペア作成） | 中（ドメインQAペア） | 高（oracle/distractor割当+CoT生成） |
| 訓練計算コスト | なし | 中 | 中 | 中〜高（系列長増加分） |
| Retriever構築 | 中（Embedding計算） | なし | なし | 中（同左） |
| 合計初期コスト | 中 | 中 | 中 | 高 |
RAFTの初期コストは他の手法より高い。これは主にデータセット構築の工程（oracle/distractor文書の選定、CoT回答の生成）に起因する。しかし、この初期投資は性能向上という形で回収される。
| コスト項目 | RAG | SFT | DSFT | RAFT |
|---|---|---|---|---|
| 推論あたりのAPI/計算コスト | 高（retriever + LLM） | 低（LLMのみ） | 低（LLMのみ） | 高（retriever + LLM） |
| Retrieverインフラ | 中（ベクトルDB運用） | なし | なし | 中（同左） |
| 文書更新時のコスト | 低（インデックス更新） | なし | なし | 高（再訓練が必要な場合あり） |
| モデル更新コスト | なし（ベースLLM変更のみ） | 中（再訓練） | 中（再訓練） | 中〜高（再訓練） |
推論時のコストはRAGとRAFTでほぼ同等である。どちらもretrieverによる文書取得とLLMによる回答生成の2段階を要する。ただし、RAFTは高い精度により再質問や人手修正の頻度が減少するため、総合的な運用コストはRAFTの方が低くなるケースが多い。
| 処理段階 | RAG | SFT | DSFT | RAFT |
|---|---|---|---|---|
| Retriever検索 | 50〜200ms | なし | なし | 50〜200ms |
| コンテキスト構築 | 10〜50ms | なし | なし | 10〜50ms |
| LLM推論（入力処理） | 200〜500ms | 100〜200ms | 100〜200ms | 200〜500ms |
| LLM推論（出力生成） | 500〜2000ms | 500〜2000ms | 500〜2000ms | 800〜3000ms |
| 合計 | 760〜2750ms | 600〜2200ms | 600〜2200ms | 1060〜3750ms |
RAFTのレイテンシはRAGより若干長くなる傾向がある。これはCoT形式の回答を生成するため、出力トークン数が増加することに起因する。ただし、CoT部分を非表示にして最終回答のみを表示する運用であれば、ユーザー体感のレイテンシ差は小さい。
| 要件 | RAG | SFT | DSFT | RAFT |
|---|---|---|---|---|
| ベクトルDB | 必要 | 不要 | 不要 | 必要 |
| GPU（推論） | 必要 | 必要 | 必要 | 必要 |
| GPU（訓練） | 不要 | 必要 | 必要 | 必要 |
| 文書インデックス管理 | 必要 | 不要 | 不要 | 必要 |
| モデルバージョン管理 | 低 | 中 | 中 | 高 |
RAFTはRAGとファインチューニングの両方のインフラを必要とするため、運用負荷が最も高い。ただし、近年のMLOpsツール（MLflow、Weights & Biases、Hugging Face Hub）の成熟により、モデルバージョン管理のコストは低下傾向にある。
| シナリオ | RAG | SFT | DSFT | RAFT |
|---|---|---|---|---|
| 新文書の追加 | 即座（インデックス更新） | 不可（再訓練要） | 不可（再訓練要） | 部分的（インデックス+再訓練推奨） |
| 既存情報の修正 | 即座（文書差替） | 不可 | 不可 | 部分的 |
| 大規模コーパス更新 | 中（再インデックス） | 高（全再訓練） | 高（全再訓練） | 高（全再訓練+再インデックス） |
知識更新の柔軟性はRAGが最も優れている。RAFTはRAGのretriever部分の柔軟性を維持しつつ、定期的なモデル再訓練でLLM側の知識も更新する必要がある。
| ユースケース | 推奨手法 | 理由 |
|---|---|---|
| プロトタイプ/PoC | RAG | 最速で構築可能、初期コスト最低 |
| 汎用QAボット | RAG | ドメインが広く、RAFT訓練のROIが低い |
| ドメイン固有QA（高精度要求） | RAFT | 精度が最重要、初期投資の回収が見込める |
| オフラインQA（retriever不使用） | DSFT | インフラコスト削減、知識更新頻度が低い |
| リアルタイム応答（低レイテンシ要求） | SFT/DSFT | retrieverなしで最速 |
| 頻繁な知識更新 | RAG | 文書差替のみで対応可能 |
| ハイブリッド（精度+更新性） | RAFT + RAG | 定期再訓練 + retriever更新 |
実践的には、RAFTで訓練したモデルをRAGパイプラインに組み込むハイブリッド構成が最も高い性能を発揮する。この構成では：
このハイブリッド構成は、retrieverの進化（より良いEmbeddingモデル、リランカーの導入など）とRAFT訓練の進化を独立に追求できる利点がある。
移行の判断基準は「現在のRAGの精度が要求水準を満たしているか」と「RAFT訓練の投資対効果」の2点である。現在のRAGで十分な精度が得られている場合、RAFTへの移行は必要ない。しかし、ドメイン固有のQAで精度が不足している場合（特に、retrieverが関連文書を取得しているにもかかわらずLLMが正確な回答を生成できないケース）、RAFTによる改善効果が大きい。移行は段階的に行うことを推奨する。まず小規模なドメインサブセットでRAFT訓練のPoCを実施し、性能向上を定量的に確認してから全面移行を検討する。
RAFTはLLM側の訓練手法であり、retrieverには変更を加えない。既存のretriever（BM25、Embedding検索、ハイブリッド検索など）をそのまま使用できる。ただし、RAFT訓練時のdistractor文書の選定を、実際のretrieverの出力パターンに近づけることで、より実環境に即した訓練が可能になる。具体的には、実際のretrieverのtop-k結果を分析し、典型的なdistractor文書のパターンを把握した上で訓練データを構築することが推奨される。
小規模モデル（7B以下）でもRAFTの効果は確認されている。論文ではLlama2-7Bでの実験結果が報告されており、標準RAGと比較して有意な性能向上が見られた。むしろ、小規模モデルの方がRAFTによる相対的な改善幅が大きい傾向がある。大規模モデル（70B以上）はベースラインの性能が既に高いため、RAFTによる追加の改善幅は相対的に小さくなる。コスト効率の観点では、7B〜13Bモデル+RAFTが、70B+標準RAGと同等以上の性能を達成できるケースがあり、推論コストの大幅削減が可能である。
RAFTの主な欠点は以下の3点である。第一に、データセット構築の工数が大きい。oracle/distractor文書の選定とCoT回答の生成は手間がかかり、自動化しても品質チェックが必要。第二に、ドメインの知識が更新された場合、モデルの再訓練が必要になる。RAGなら文書を差し替えるだけで済むが、RAFTは再訓練のコストがかかる。第三に、モデルバージョン管理の複雑さが増す。ベースモデル、LoRAアダプタ、retrieverの3つのコンポーネントを管理する必要があり、MLOps成熟度が低い組織では運用負荷が高くなる。