RAG は過渡期の技術か

過渡期の技術ではありませんが、使う場面は狭まっています。文書の量が少なければ、検索の仕組みを作らずに全部をモデルに渡すほうが早く確実になりました。一方で、渡す量が増えるほどモデルは読み落としを増やすので、量が多い文書や毎日増える記録には、必要な部分を探して渡す検索の仕組み（RAG）が残ります。モデルそのものを調整する方法は、知識を足すためより、書き方や判断の癖を合わせるために使うものです。

RAG とは何だったか

RAG（検索拡張生成）は、2020年に Lewis らが論文で示した方法です。モデルが学習で身につけた知識（パラメータの中の記憶）と、外部の文書の索引（パラメータの外の記憶）を組み合わせて文章を作ります。論文では Wikipedia を索引にしていました。業務では、社内の文書を索引にして、質問に関係する部分だけを探してモデルに渡します。

全部渡せば足りる場面

この方法が考えられたころ、モデルが一度に読める量は少なく、文書を全部渡すことはできませんでした。2026年10月時点では、Anthropic の Claude Opus 5.5 や Sonnet 5.5 は100万トークンの文脈を扱え、Google の Gemini にも100万トークン以上の文脈を持つモデルが多くあります。

Anthropic は2024年の記事で、知識の元になる文書が20万トークン（約500ページ）より少なければ、検索の仕組みを作らずに全部をプロンプトに入れればよい、と書いています。同じ文書を繰り返し渡す費用は、キャッシュで下げられます。Claude の文書では、キャッシュから読み込む入力の料金は通常の入力の10%（Opus 5.5 では5%）です。

作業標準書や品質マニュアルのように、量が数百ページまでで、たまにしか変わらない文書なら、まず全部渡す方法を試すべきです。

長く渡せばよいわけではない

ただ、長く渡すほど読み落としが増えます。2023年の Liu らの研究は、関係する情報が入力の最初か最後にあるときに性能が最も高く、長い入力の真ん中にあると大きく下がることを示しました。Anthropic の文書も、文脈は多ければよいわけではなく、トークン数が増えると正確さと想起が落ちる「コンテキストの劣化」が起きると書いています。Google の文書も、探したい情報が複数あるときは同じ精度が出ないこと、取り出したい情報を正しく取り出すことと費用のあいだにはトレードオフがあることを認めています。

過去10年分の不具合報告や、毎日増える作業日報のように、量が多く、増え続ける記録は、全部を渡すより、質問に関係する部分を探して渡すほうが正確で安くなります。

検索の質は工夫で上がる

RAG の弱点は、検索が外れると答えも外れることです。Anthropic が2024年に示した方法では、文書を細かく分けた断片それぞれに、元の文書の中での位置づけを短く書き足してから索引を作ることで、上位20件の検索の失敗率が5.7%から3.7%に下がりました（35%の削減）。キーワード検索（BM25）を組み合わせると2.9%（49%の削減）、さらに並べ替え（リランキング）を加えると1.9%（67%の削減）でした。

製造業の文書で言えば、品番や設備番号のような記号は、意味で探す検索より、キーワード検索のほうが確実に当たります。両方を組み合わせるのが基本です。

モデルを調整する方法の役割

モデルを自社のデータで追加学習させる方法（ファインチューニング）もあります。OpenAI の文書は、プロンプトの工夫だけで十分な結果が得られることもある、としたうえで、調整を考える場面として、文脈に収まらないほど多くの例を学ばせたいとき、プロンプトを短くして費用と待ち時間を減らしたいとき、小さく安いモデルで同じ仕事をさせたいとき、などを挙げています。

調整は、最新の在庫や昨日の不具合のような、変わり続ける事実を覚えさせるのには向きません。覚えさせた時点で古くなるからです。向いているのは、社内の書式に揃えて書かせる、決まった分類に振り分けさせる、といった振る舞いを合わせる仕事です。社外に出せない文書を扱うために小さなモデルを社内で動かす場合も、調整の出番があります（ローカルLLMは製造現場に置けるか）。

製造業での使い分け

もう一つ大事なのは、検索や全部渡す前に、記録そのものをデータにしておくことです。不具合報告から設備や現象を取り出してあれば（不具合報告と作業日報をデータに変える）、「2号機のクラックは今年何件か」には、文章を探すまでもなく集計で答えられます。言語モデルに読ませるのは、集計では答えられない部分だけで足ります。