RAGで35%、ファインチューニングで98%——精度とコストの両方で勝てる理由を徹底解説

8月20日、Towards Data Scienceが「How to Fine-Tune an LLM: An End-to-End Guide」と題した記事を公開した。LLMのファインチューニングをいつ・なぜ・どのように実施すべきかについて、実例と数学的背景を交えながら詳しく解説している。本記事はLoRA/QLoRAの仕組みまで踏み込んだ中〜上級者向けの内容であり、入門的な概要を求める読者は先にHugging Face PEFTドキュメント等で基礎を押さえておくと理解しやすい。

RAGで35%、QLoRAで98%——この差がすべてを語る

記事の冒頭で紹介される実例が強烈だ。乳がんの病理報告書テンプレートを自動入力するというタスク——40種類の組織学的サブタイプに応じて条件分岐し、フィールドを厳密な順序で出力しなければならない。一つでも誤れば出力全体が無効になる。

記事で使用されたモデルはClaude Opus 4.6として紹介されている。積極的なシステムプロンプトとRAGを組み合わせた場合、精度は**約35%**。コンテキストには約3万トークンを毎回投入した。その結果は「フィールドの欠落、不要なサブセクション、ハルシネーション」——人間が全文を確認・修正しなければ使えないレベルだった。

Mistral 7BをQLoRAでファインチューニングしたところ、精度は約98%に跳ね上がった。

Prompt + RAG
███████░░░░░░░░░░░░ 35%
QLoRA
███████████████████░ 98%

API呼び出しコストも消滅した。当初フロンティアモデルで運用した場合のコスト見積もりは約32万ドルとされているが、これはRAG運用時のAPI費用の試算であり、ファインチューニング自体の学習コストやローカルモデルの継続的な運用コスト（GPU代・インフラ費用等）は含まれていない。コスト比較の際はその前提条件を考慮する必要がある。

「RAG＋システムプロンプトはファインチューニングが必要な問題を解決しない」——記事はこの一文を強調する。

ファインチューニングが必要なケース

記事では、以下の4パターンでファインチューニングを検討すべきだと整理している。

厳格なフォーマット要件：法的文書・医療フォーム・社内固有テンプレートなど、ハルシネーション1件で全体が無効になる出力
コスト制約：毎回のAPI呼び出しに数万トークンのシステムプロンプトが必要な場合、スケールすると無視できない金額になる
複雑な条件分岐：「AならB、ただしCかつAならD、EがあればDではなくF……」といった爆発的なルールの組み合わせはコンテキスト内学習の限界を超えやすい
特定のトーン・ブランドボイス：カスタマーサービスのトーン定義に2,000トークンを毎回使うなら、コストが積み上がる

逆にRAGが適しているケースは「知識ベースが頻繁に更新される」「少量のシステムプロンプトで行動を制御できる」「高品質なトレーニング例が数百件しかない」場面だ。記事では「実用的なソリューションはRAGとファインチューニングの組み合わせになることが多い」とも指摘している。

LoRA／QLoRAの仕組み——数学的直感

なぜフルファインチューニングはできないのか

70Bパラメータモデルをフルファインチューニングする場合、FP16の重みに加えてAdamオプティマイザの各パラメータ2つ分のモーメントを保持する必要があり、VRAMは1.2〜1.4TBに達する。現実的ではない。さらに既存の知識を破壊するリスクもある。

LoRA（Low Rank Adaptation）の核心

2021年にMicrosoftが発表したLoRA論文（Hu et al.）の洞察はシンプルだ。ファインチューニング時の重み更新は「低い内在次元」を持つ——つまり、モデルを少し方向修正するために全パラメータを更新する必要はなく、より低次元の射影を学習するだけでよい。

具体的には、元のモデル重みを凍結したまま、各重み行列に小さな低ランク行列AとBのペアを追加する。フォワードパスは以下になる：

h = Wx + (α/r) · BAx

元のWは一切変わらない。学習するのははるかに小さなサイドカーだけだ。

例えば4096×4096の重み行列（約1,600万パラメータ）に対し、LoRA（rank 8）では約65,000パラメータの学習で済む。オプティマイザのメモリ消費も同様に激減する。

ここでrankの選択が重要になる。記事はrank 8とrank 32の違いを数値として説明しており、「デフォルトのままコピペするのではなく、数学的直感を持って設定すべき」と強調している。rankが大きいほど表現力が上がるが、過学習のリスクも増す。

QLoRA——コンシューマGPU1枚で動かすための追加工夫

LoRAだけでも重みはFP16（16ビット）でVRAMに乗せる必要がある。2023年に発表されたQLoRA論文（Dettmers et al.）はここをさらに改善し、凍結された元モデルを4ビットに量子化しつつ、LoRAアダプタ自体は16ビット精度のまま学習する。

論文で導入された主な技術要素：

NF4（4-bit NormalFloat）：ニューラルネットワークの重みはほぼガウス分布に従うことを利用し、ゼロ付近に量子化値を密に配置することで量子化誤差を最小化する
Double Quantization：ブロックごとのスケーリング係数自体も量子化することで、パラメータあたり約0.373ビットを追加節約（数十億パラメータ規模では2〜3GBのVRAM節約に相当）
Paged Optimizers：長いコンテキスト処理時のVRAMスパイクによるOOM（Out of Memory）エラーを防ぐNVIDIAのユニファイドメモリ機構を利用した仕組み

実装の流れ

記事ではHugging FaceのPEFTライブラリを中心に、データセット準備・学習ループ・カスタム評価ハーネスまで一通りのコードが示されている。PEFTはLoRA・QLoRA・Prefix Tuningなど複数のパラメータ効率的手法を統一的なAPIで扱えるライブラリで、公式ドキュメントにチュートリアルも充実している。

評価についても「精度を独自に測定するハーネス」を構築することを推奨しており、汎用ベンチマークでは不十分なタスク固有の品質測定に踏み込んでいる。冒頭の医療フォームの例のように、出力の一部が誤っているだけで全体が無効になるケースでは、独自の評価基準なしに品質を把握することは難しい。

詳細はHow to Fine-Tune an LLM: An End-to-End Guideを参照していただきたい。