独自知識をLLMに渡す3つの方法
社内文書やFAQをLLMに使わせる方法は、大きく分けて3つあります。
1つ目は、文書をプロンプトに直接入れる方法です。文書が多いときは、ロングコンテキストのモデルに丸ごと渡します。ロングコンテキストとは、一度に読み込める入力の長さ(コンテキストウィンドウ)が大きいモデルのことです。2つ目はRAG(検索拡張生成)です。質問のたびに文書から関連する部分を検索し、その部分だけをプロンプトに添えて回答させます。3つ目はファインチューニングです。自社のデータでモデルを追加学習させ、モデルそのものを変えます。
3つの方法は組み合わせることもできます。たとえば、RAGで検索した結果を、回答形式を整えるためにファインチューニングしたモデルに渡す構成があります。
判断を分ける4つの条件
選び方は、文書量、更新頻度、予算、求める精度の4つで決まります。最初の分かれ目は、文書がモデルのコンテキストウィンドウに収まるかどうかです。収まるなら、直接入れる方法がいちばん手早く済みます。収まらなければRAGが基本になります。更新が多い場合は、そのたびに再学習が必要なファインチューニングは向きません。回答の根拠を示す必要がある業務では、出典を返しやすいRAGか直接入力が候補になります。
注意したいのは、ファインチューニングが「知識を覚えさせる」用途では効率が悪い点です。追加学習が得意なのは、口調や出力形式、決まった作業手順を身につけさせることです。個々の事実を正確に覚えさせるのは難しく、もっともらしい誤り(ハルシネーション)も残ります。知識を足したいなら、まず検索や直接入力で済まないかを考えるのが一般的です。
6つの観点で比較する
| 観点 | 直接入力・ロングコンテキスト | RAG | ファインチューニング |
|---|---|---|---|
| 初期コスト | 低い。文書を整えて渡すだけ | 中程度。検索の仕組みづくりと文書の分割・インデックス化が必要 | 高い。学習データの作成と学習の費用がかかる |
| 継続コスト | 質問のたびに全文を送るため、トークン課金がかさみやすい | 検索基盤の運用費がかかる。1回あたりの入力は小さく抑えられる | 推論時の入力は短くて済む。ただし更新のたびに再学習の費用がかかる |
| 更新のしやすさ | 文書を差し替えるだけ | インデックスを更新するだけ | 再学習が必要 |
| 正確さと出典 | 原文を直接読むので正確になりやすく、出典も示せる。ただし長文の途中を見落とすことがある | 検索で正しい部分を拾えれば正確で、使った文書も示しやすい。拾い損ねると誤答する | 出典は示せない。事実を正しく再現できるかは安定しない |
| 実装難度 | 低い | 中〜高。検索精度の調整が必要 | 高い。データの準備と評価の設計が必要 |
| データ量の上限 | コンテキストウィンドウの大きさで決まる | 検索基盤しだいで、実用上は大量の文書を扱える | 量の上限より先に、どこまで正確に覚えられるかが問題になる |
直接入力・ロングコンテキストの強みと弱点
執筆時点では、主要なモデルの多くが数十万トークンの入力に対応しています。一部は100万トークン級です。日本語の文書なら、数百ページ分を一度に渡せる規模です。対応長はモデルごとに違い、頻繁に変わるため、各社の公式ドキュメントで確認してください。
弱点はコストと応答速度です。毎回全文を送るので、利用者が増えるほど費用が膨らみます。プロンプトキャッシュを使うとこれを軽くできます。同じ前置き部分を再利用して、料金と待ち時間を下げる機能で、主要なAPIの多くが提供しています。ほかにも、入力が非常に長いと途中の情報を見落としやすい傾向があります。全員に同じ文書を渡すため、部署ごとに見せる文書を変えるといった閲覧権限の管理にも向きません。
RAGの強みと弱点
RAGは文書量が増えても破綻しにくい方法です。文書を追加・削除すればすぐに回答に反映され、どの文書を根拠にしたかも示せます。検索の段階で権限を絞れば、利用者ごとに見せる文書を変えることもできます。
弱点は、回答の質が検索の質で決まる点です。文書の分け方、表や画像を含むPDFの読み取り、言い換えへの対応など、調整する箇所が多くあります。「全規程の中で例外があるものを一覧にして」のように、多くの文書を横断する質問は苦手です。構築の手間は、Amazon Bedrock Knowledge BasesやAzure AI Searchといったマネージドサービスでかなり減らせます。
ファインチューニングの強みと弱点
ファインチューニングが向くのは、社内の書式に沿った回答や、決まった分類作業を安定してこなさせたい場合です。長い指示を毎回書かずに済むので、入力を短くできます。小さなモデルを特定の作業向けに鍛えて、推論コストを下げる使い方もあります。
弱点は、出典を示せないこと、更新に再学習が必要なこと、効果を確かめる評価の設計が難しいことです。ファインチューニングできるモデルや提供条件はベンダーごとに異なり、変更も多いため、公式ドキュメントで確認してください。
条件別の選び方
文書量で選ぶ
コンテキストウィンドウに余裕をもって収まる量なら、直接入力から始めます。数百ページを超える規模や、今後も増え続ける文書群ならRAGを選びます。
更新頻度で選ぶ
週に何度も更新されるFAQや規程なら、直接入力かRAGを選びます。差し替えだけで済むからです。ファインチューニングは、内容がほとんど変わらない書式や手順を教え込む場合に限ります。
予算で選ぶ
初期費用を抑えたいなら直接入力です。ただし利用回数が多いと継続コストが逆転します。その場合はプロンプトキャッシュを使うか、RAGに移ることを検討します。ファインチューニングは、データ準備と評価に人手を割ける場合の選択肢です。
求める精度で選ぶ
人事規程や顧客対応のように、根拠を示せないと困る業務なら、出典を返せるRAGか直接入力を使います。そのうえで、回答に引用元を必ず添えるよう指示します。出力形式のぶれが問題になるときに限って、ファインチューニングを組み合わせます。
まず小さく試して評価用の質問集を作る
最初の一歩として、代表的な文書を直接入力で渡し、実際に寄せられる質問を20〜50問ほど試してください。正解と根拠の箇所を記録した評価用の質問集を作っておくと、ほかの方法に移ったときも同じ物差しで比べられます。文書が入りきらない、費用が見合わない、と分かった時点でRAGに移ります。RAGでも出力形式が安定しないときだけ、ファインチューニングを検討します。この順に進めると、手間のかかる方法に早すぎる段階で投資するのを避けられます。