社内ナレッジはRAGかファインチューニングか:導入側のための判断ガイド
社内ナレッジへのAI活用を検討すると、遅かれ早かれ同じ会議で両方の言葉を聞くことになります。「自社文書でモデルをファインチューニングすべきだ」と「RAGを作るべきだ」。同じものに聞こえますが、違います。変更するシステムの部位が違い、維持コストが違い、壊れ方も違います。
正しく選ぶのにML(機械学習)の経歴は不要です。必要なのは、各手法が実際に何を変えるのか、そしてローンチ後に何のコストがかかるのかを知ることです。
それぞれの手法が実際にやること
RAG(検索拡張生成)は、モデルに手を加えず、自社文書への検索アクセスを与えます。質問が来ると、システムが最も関連する箇所を取得し、モデルはそれをもとに回答します—優秀な検索ツールを持つ有能な新人のようなものです。どの文書を使ったかを正確に示せます。
ファインチューニングは、数百〜数千の例でモデル自体を訓練して変更します。トーン、フォーマット、分類ルールといったパターンを、研修を受けた社員のように内面化します。どこで学んだかは引用できず、知識は訓練時点で凍結されます。
導入側の最も多い誤解は、ファインチューニングを「モデルに自社文書を教えること」と捉えることです。それこそが、この手法が確実にはできないことです。事実はぼやけ、出典は消え、更新には再訓練が必要になります。ナレッジに関しては、ファインチューニングは「自信満々に使われる間違った道具」です。
引用つきRAGが正しいデフォルトである理由
データの鮮度。 価格表やポリシーが変わったら、文書を数分で再インデックスするだけ。再訓練もリリースサイクルも不要です。
追跡可能性。 すべての回答に出典文書と該当箇所への引用がつくため、専門家は再調査ではなく数秒の確認で検証できます。このパターンは引用つきナレッジ検索で解説しました。
アクセス制御。 モデルが何かを見る前に、質問者の権限で取得結果をフィルタできます。重みに焼き込まれた知識はユーザー別に隠せません—モデルに入った時点で、モデルにアクセスできる全員のものです。
デバッグ可能性。 間違った回答には目に見える原因がつきます:何が取得されたかを見ればよい。失敗分析は「読む」ことであり、MLの法医学ではありません。
当社のナレッジ検索案件の内部ベンチマークでは、各回答が出典箇所にリンクすると、レビュー担当者によるAI回答の受け入れ率がおよそ2倍になります。モデルは同じです。信頼をつくるのは引用です。
ファインチューニングがコストに見合う場面
大規模なフォーマットとスタイル。 1日数千件の出力を正確な社内フォーマットで—商品説明、コード化された要約、規制対応テンプレート—プロンプトだけでは一貫性が滑り続ける場面。
ラベル付き履歴のある分類。 数年分のラベル付きチケット、請求、文書。小さなファインチューニング済みモデルは通常、フロンティアモデルへのプロンプトより一貫性が高く、1コールあたりのコストが大幅に安くなります。
レイテンシとコストの上限。 狭いタスク1つを小さなモデルに蒸留すると、そのタスクでの品質を保ったまま、コールあたりのコストを1桁下げられることがあります。
制約のある配備先。 小さなモデルしか載らないオンプレミスやエッジ環境で、その小さなモデルが本番品質に届くよう補強が必要な場面。
このリストに無いものに注目してください:「自社ナレッジの追加」です。ファインチューニングが元を取るのは挙動であって、事実ではありません。
ハイブリッドパターン
成熟したシステムは通常、両者を組み合わせ、それぞれに得意な仕事をさせます。
RAG層が、引用と権限フィルタつきで事実を供給する
小さなファインチューニング済み(または厳密にプロンプトされた)モデルが、大量のルーティングと整形を担う
フロンティアモデルが、件数は少ないが重要度の高い統合ステップを担う
サポートデスクが典型例です。小さな分類器がチケットを振り分け、RAGが最新のヘルプ文書に基づく回答案を作り、強いモデルが難しいエスカレーションを起草する。この時点でこれは普通のAIワークフロー自動化です—各ステップに、評価に合格する最も安い部品を割り当てるだけです。
コストと保守の比較
| | RAG | ファインチューニング |
|---|-----|-------------|
| 構築の手間 | 文書パイプライン+検索+プロンプト。2〜4週間で実用 | データ整備+訓練+評価。大半はデータ作業 |
| 知識の更新 | 数分で再インデックス | 再訓練と再評価 |
| 引用 | ネイティブ対応—回答が出典にリンク | 不可 |
| ユーザー別アクセス制御 | 取得時に強制 | 重みの内側では不可能 |
| 継続保守 | インデックスの衛生管理、検索評価 | データのドリフトに応じた定期再訓練 |
| 典型的な失敗 | 検索ミス—見えるので直せる | 自信のあるドリフト—監査まで沈黙 |
| 妥当な初期予算 | 2週間PoCに収まる | 量が証明される前にはほぼ見合わない |
2週間PoCが証明すべきこと
社内ナレッジでの正しい最初の案件は、よく選ばれた1つの文書セットに対するRAG検索を、デモではなく評価セットで判定することです。2週間あれば、次の5点を証明—または反証—できます。
出典の正解が分かっている実際の質問50〜100件のゴールドセットが存在し、合意されている
検索ヒット率:正しい文書がモデルの前に届く頻度
引用の正確性:引用された箇所が、実際にその回答を支えている
誠実な回答拒否:コーパスでは答えられない質問で何が起こるか
現実的な日次ボリュームでの、クエリあたりのコストとレイテンシ
これが当社のQuick DX PoC($12,500-$18,000)の形です:2週間、毎週のデモ、評価レポート、そしてチームが次に動ける引き継ぎ資料—次のフェーズを当社とやるかどうかに関わらず。
手法ではなく、問いを買う
RAGかファインチューニングかの判断は、機械学習の問題というより、ビジネスがどの性質を最初に必要とするかの問題です。回答が最新で、検証可能で、権限を尊重する必要があるなら、それはRAGです—そして社内ナレッジの大半はこれに当たります。必要なのが1日数千回繰り返される正確な出力形式なら、ファインチューニングが元を取ります—通常は後で、狭いステップに対して、量が正当化してからです。
当社が監査するチームの多くは、「RAGは今、ファインチューニングはいずれ必要なら」という結論になります。パッケージの監査週間から始めれば、バズワードで選ぶ代わりに、評価セット、コストモデル、書面の推奨という証拠で決着がつきます。