日本語 RAG をローカル SLM に任せていいか — 4 モデル 15 問ベンチを運用者目線で読む

まず結論 — 「全部ローカル」か「全部クラウド」かではなく、問いごとに分ける

結論から書きます。日本語 RAG（検索した文書を文脈に渡して答えさせる仕組み、Retrieval-Augmented Generation）をローカル SLM（手元の GPU で動く小さめの言語モデル、Small Language Model）に全部任せるか、クラウド LLM に全部投げるか、という二択で考えるとたいてい損をします。問いの性質ごとに「これはローカルで十分」「これはクラウドに通す」と振り分ける方が、品質・コスト・運用負荷のバランスが取りやすい。

きっかけは Zenn の「ローカル SLM とクラウド LLM を日本語 RAG で比較した」記事（haruto_miyakawa） でした。著者は Gemini 2.5-flash（クラウド）と qwen 系のローカルモデル数種を、同じ 15 問の日本語 RAG セットで突き合わせています。私はこれを、自分が API を運用する側として「どこを切れば事故らずにコストを下げられるか」という目線で読み直しました。結果として一番効いた学びは、モデルの大小ではなく問いの仕分けでした。

15 問の日本語 RAG ベンチが示したこと — サイズ順に強いわけではない

このベンチの面白いところは、パラメータ数が大きいモデルほど一律に強いわけではなかった点です。記事では、qwen 系のローカルモデルを複数サイズで比べたところ、中位サイズのモデルがむしろ不安定で、より小さいモデルの方が堅実に答えた場面があったと報告されています。

15 問という規模は、統計的に何かを言い切るには小さい。それでも実務の感覚に近いのは、質問の中身が「事実の確認」「曖昧な伝承の扱い」「キャラクターの一貫性」のように毛色の違うタスクを混ぜている点です。ここで効くのは、平均スコアではなく「どのタイプの問いで崩れたか」という分布の方でした。事実確認はローカルでも十分通るのに、文脈をまたいだ一貫性の問いになると小さいモデルから順に崩れていく。この崩れ方が見えると、振り分けの線が引けます。「5 つのフロンティア LLM が事実判定の 67% で割れる」という話を別の記事で書きましたが、正誤をモデルに丸投げできないのはクラウドでも同じで、ローカルだと崩れる範囲が一段広いと考えておくと安全です。

ローカル SLM が向く問い・クラウド LLM が向く問い

振り分けの基準は、ざっくり「答えが渡した文書の中に書いてあるか」です。検索で引いた文書にそのまま答えが載っている抽出的な問いはローカル SLM が得意で、複数文書を統合したり言外を補ったりする推論寄りの問いはクラウド LLM に通した方が安定します。

具体的には、こう仕分けています。

1. 抽出・要約系はローカル: 「この仕様書のどこに上限値が書いてあるか」のように、根拠が 1 段落に収まる問い。ハルシネーション（もっともらしい嘘）が出ても検証が速い。
2. 統合・判断系はクラウド: 「A の制約と B の制約を踏まえると何を選ぶべきか」のように、複数の根拠をまたいで結論を出す問い。ここで小さいモデルは話を作りがちでした。
3. 一貫性が要る対話はクラウド寄り: 同じ前提を会話の最後まで保てるかは、サイズの差がそのまま出ます。

ローカルを試すなら Ollama で qwen 系を動かすのが一番手早い。私は手元の MacBook で 4B クラスのモデルを動かして、上の 1 番だけをローカルに寄せる構成から始めました。1-bit 量子化で小さいモデルを端末に載せる話は以前 Bonsai Image 4B で書いたとおりで、メモリに載るかどうかが最初のハードルになります。

運用負荷で効いてくる差 — モデル切り替えとリトライ

品質やコスト以上に、地味に効いてくるのが運用負荷です。ローカル SLM は API 課金こそ無いものの、モデルの切り替え直後に応答が崩れる挙動があり、ここにリトライを入れておかないと「たまに空の答えが返る」という再現性の低い障害に悩まされます。

私も最初これで一度ハマりました。Ollama で 2 つのモデルを問いごとに切り替える実装にしたところ、切り替えた直後の 1 回目だけ空応答や途中で切れた応答が返ることがあった。原因を追う前にまず、1 回失敗したら 300ms 待って同じ問いを投げ直す、というだけのリトライを足したら再現しなくなりました。原因の特定はその後でいい、と割り切った判断です。クラウド LLM はこの種のウォームアップ問題が無い代わりに、料金とプロバイダ依存というコストを別の形で払う。単一プロバイダに寄せた構成が突然止まる怖さは、Claude Fable 5 / Mythos 5 が止まった日の話に書いたとおりです。ローカルとクラウドを混ぜておくことは、品質の最適化であると同時に、片方が落ちても全滅しない保険でもあります。

コスト面では、抽出系をローカルに逃がすだけでクラウドへの呼び出し回数がはっきり減ります。「呼ばない」ことでコストを抑える三段防御は別記事に詳しく書きましたが、ローカル SLM はその一番外側の防御壁としても効きます。

私の選び方 — 「下書きはローカル、確定はクラウド」の二段構え

最終的に私が落ち着いたのは、下書きや一次抽出はローカル SLM に任せ、人に見せる確定版や統合判断はクラウド LLM に通す、という二段構えです。これは品質とコストの間を取った折衷で、どちらかに振り切るより事故が少ない。

この構図は、実はこのサイト自体の運用とも重なります。AetherEchoes の記事は AI が下書きを書き、私が公開前に確認・編集してから出していて、「速いが粗いかもしれない一次出力」と「遅いが責任を持てる確定」を役割で分けているわけです。RAG のモデル選びも同じで、安いモデルに最初の仕事をさせ、高いモデルと人の目で最後を締める。15 問のベンチが教えてくれたのは、正解のモデルが 1 つあるという幻想を捨てて、問いごとに担当を割り振るという、わりと当たり前の運用でした。当たり前なのに、つい「一番賢いやつ 1 つで全部」とやりたくなるのが厄介なところです。