ファインチューニングと RAG

なぜ「そのまま」では足りないのか

基盤モデルは膨大な一般知識を持ちますが、次の2つは原理的に苦手です。

• 自社固有・最新の知識：社内規定、製品マニュアル、昨日のニュースなど、学習データに含まれていない情報は知りようがない。
• 決まった振る舞い：常に JSON で返す、特定の口調を保つ、自社のサポート手順に沿うなど、汎用モデルのままでは揺れる。

この「知識を足す」課題と「振る舞いを固める」課題は別物で、効く薬も違います。ここを混同すると遠回りになります。

ファインチューニング：内部を書き換える

入力と理想の出力のペア（例：問い合わせ文 → 模範回答）を数百〜数千件用意し、追加学習でモデルの重みを少しずつ更新します。学習が済めば、その傾向はモデル本体に焼き付きます。

学習データ（例）
  入力: "解約したいです"
  出力: "ご解約の手続きですね。まずマイページの…（自社手順の口調つき回答）"
  ……これを数百〜数千ペア

→ 追加学習 → モデルが「この口調・形式」を体得

得意なのは形式や口調、ドメイン特有の言い回しを安定させること。一方で、新しい事実を覚えさせる用途には向きません。事実が変わるたびに再学習が要りますし、少量の学習データに引っ張られて挙動が偏ることもあります。

RAG：外部知識を検索して渡す

モデルは一切いじりません。代わりに、

1. 手元の文書をあらかじめ細かく分割し、エンベディング（意味のベクトル）にしてデータベースに入れておく。
2. 質問が来たら、その質問に意味が近い文書を検索して取り出す。
3. 取り出した文書をプロンプトに同梱して「これを根拠に答えて」とモデルに渡す。

# RAG のおおまかな流れ（擬似コード）
docs = vector_db.search(query, top_k=3)        # 質問に近い文書を検索
prompt = f"次の資料だけを根拠に答えて:\n{docs}\n\n質問: {query}"
answer = llm.generate(prompt)                   # モデル本体は無改造

知識は外部 DB 側にあるので、文書を差し替えれば即座に最新化でき、再学習は不要。さらに「どの文書を根拠にしたか」を示せるため出典を提示しやすいのも大きな利点です。弱点は、検索がズレると答えもズレること、そして毎回プロンプトが長くなり1回の推論コストとレイテンシが増えることです。

2つの違いを並べて見る

使い分けと、つまずきポイント

判断の軸はシンプルです。

• 足りないのが「知識」（最新情報・社内文書）→ RAG。
• 足りないのが「振る舞い」（口調・出力形式・手順の遵守）→ ファインチューニング。
• 両方（自社知識を、自社らしい口調で）→ 併用。RAG で知識を供給し、ファインチューニングで応答スタイルを整える。

実務でよく踏む地雷もまとめておきます。

• RAG の精度は検索が9割：モデルを変える前に、分割サイズの調整や検索のチューニングで大きく改善することが多い。「答えが悪い＝モデルが悪い」と早合点しない。
• ファインチューニングのデータ品質：少量でも質の悪いペアを混ぜると、その癖まで忠実に学習してしまう。量より質。
• コストの見え方が違う：ファインチューニングは初期の学習費が重く推論は軽い。RAG は初期は軽いが毎回の推論で課金が積み上がる。運用回数まで含めて試算する。

たとえ：新人を即戦力にする2つの方法

新しく入った優秀だが自社を知らない人（基盤モデル）を戦力化する場面を想像してください。

• RAG＝社内マニュアルを手元に置いて、その都度引きながら答えてもらう。マニュアルを更新すればすぐ最新の対応になり、「何ページを見たか」も言える。ただし毎回ページをめくる手間（推論コスト）はかかる。
• ファインチューニング＝何百件もの模範対応を反復練習させ、自社の作法を体に染み込ませる。一度覚えれば即答できるが、ルールが変われば練習し直しで、うろ覚えのまま自信満々に間違えることもある。

多くの現場の答えは「両方」。マニュアル（RAG）で“何を”答えるかを最新に保ちつつ、反復練習（ファインチューニング）で“どう”答えるかを自社流に固める——これが基盤モデルを実戦投入する王道です。