RAGとは｜検索・拡張・生成の3フェーズと仕組み、ファインチューニングとの違い

念のため、まず一行だけ。RAGとは、社内の文書やデータをAIに検索させ、その検索結果を根拠にAIに答えさせる仕組みのことです。「AIに社内の知識を持たせる」ときの、いまの定番のやり方だと思ってください。その上で――今日の本題は、その一歩先です。

先日、「RAGを入れたのに、思ったほど賢くならない」という相談を受けました。よく聞くと、社内のマニュアルやPDFを片っ端からベクトルデータベースに入れて、検索させている、という作りでした。悪くありません。むしろ、最初の一歩としては正しい。

ただ、そこから先で伸び悩む理由と、伸ばす順番は、わりとはっきりしています。

今日は、RAG構築の「あるべきかたち」を、専門用語をなるべく噛み砕きながら、淡々と書いてみます。誰かを責める話ではありません。RAGは、正しい順番で強くしていくものだ、という話です。

先に結論を、順番の形で言ってしまいます。

① まず「ひとつの文書検索」を強くする（別のデータベースを足すのは、その後です）。
② 社内の知識は表・文書・つながりの3種類に分かれているので、検索の戦略が多面的になる。
③ 問いに応じて選び、足りなければ取り直す。これがAgentic RAG。
④ 作って終わりにしない。評価で劣化を測りながら育て、社内で自走させる。

この順番が、けっこう大事です。順に書きます。

（この記事は「RAGをどう作るか」の設計の話です。）

RAG（検索拡張生成）とは

RAGとは Retrieval-Augmented Generation の略で、質問に関係する文書をまず検索し、その中身をAIに読ませてから答えさせる仕組みです。日本語では検索拡張生成と訳されます。

AIに知識を覚えさせるのではなく、その場で資料を渡すのが要点です。モデル自体には手を加えません。

RAGをひとことで例えると

持ち込み禁止の試験を、持ち込み可の試験に変えるのがRAGです。

暗記でしか答えられなかったAIに、「この資料を見ながら答えていい」と言って手元に置いてやる。知識を問う問題が、資料を読んで答える問題に変わります。賢くしたのではなく、問題の種類を変えた——ここがRAGの本質です。

なぜRAGが必要なのか｜従来の生成AIの限界

生成AIをそのまま業務で使うと、次の4つで詰まります。

• 社内の事情を知らない — 学習データに自社の規程も商品も入っていない
• 学習した時点で情報が止まる — それ以降の出来事を知らない
• 知らないことを、知らないと言わない — もっともらしい誤りを返す
• 根拠が示せない — 合っているかを確かめる手段が無い

4つ目が、業務で使えるかどうかの分かれ目です。出典が出ないなら、結局その資料を人が探し直すことになります。

RAGと従来のLLMは何が違うのか

	知識の在り処	更新のしかた
従来のLLM	モデルの内部（学習済みの重み）	学習し直すしかない
ファインチューニング	モデルの内部（追加学習した重み）	追加学習をやり直す
RAG	モデルの外（データベース）	データベースを差し替えるだけ

この1行の違いが、運用の手間をすべて決めます。規程が改訂されるたびに学習し直す構成は、現実には回りません。

RAGの仕組み｜検索・拡張・生成の3フェーズ

RAGという名前は、この3つの頭文字から来ています。

フェーズ	やること	効いてくるところ
検索（Retrieval）	質問に関係する文書を、データベースから取り出す	ここの精度が、そのまま答えの精度になる
拡張（Augmentation）	取り出した中身を、質問と一緒にAIへ渡す	渡す件数と量の設計
生成（Generation）	渡された資料を根拠に、AIが答えを書く	資料の外に出ないよう指示する

RAGの品質問題は、ほとんどが1つ目のフェーズの問題です。関係のない文書を渡せば、AIはその関係のない文書をもとに答えます。生成の指示をいくら直しても、そこは直りません。

RAGの動きを手順で追う

• 事前準備 — 社内文書を検索できる形にして、データベースを作っておく
• 1. 質問が入る — 利用者の問いを、意味を表す数値の並びに変換する
• 2. 取り出す — 意味の近い文書のかたまりを、データベースから取り出す
• 3. 渡す — 取り出した中身を、質問と一緒にAIへ渡す
• 4. 答える — AIが、渡された資料を根拠に文章を作る
• 5. 出す — 回答と、根拠になった文書を利用者へ返す

5で出典を一緒に返すかどうかを、最初に決めてください。後から足そうとすると、どの文書を使ったのかを記録していない作りになっています。

外部データの作成と、その更新

RAGで最も手がかかるのは、実は検索される側のデータです。

更新が止まった瞬間から、RAGは劣化します。古い版が入っていると、それを根拠に自信をもって間違えます。誰が、どの頻度で、どの文書を入れ直すのかを、人の役割として決めてください。

RAGの構成要素

要素	役割	選ぶときに見るところ
データソース	答えの根拠になる社内文書	更新される場所か。権限が付いているか
埋め込みモデル	文章を数値の並びに変換する	日本語の性能。専門用語の扱い
ベクトルデータベース	その数値を貯めて、近いものを探す	件数、更新のしやすさ、権限で絞れるか
検索の仕組み	質問に合う文書を取り出す	意味検索だけか、キーワード検索と併用できるか
LLM	渡された資料をもとに答えを書く	長い資料を読めるか。費用

4行目を「意味検索だけ」で組むと、型番や固有名詞で外します。意味が近いことと、その語が入っていることは別です。

セマンティック検索（ベクトル検索）との違い

よく混同されますが、セマンティック検索はRAGの部品です。

	何をするか	返すもの
セマンティック検索	意味の近い文書を探す	文書の一覧
RAG	その文書をAIに読ませて答えさせる	答えの文章

「探すところまで」か「答えるところまで」かが違います。検索結果の一覧で足りる用途に、RAGを載せる必要はありません。

キーワード検索・RAG・ファインチューニングの比較

	得意なこと	苦手なこと
キーワード検索	型番・固有名詞・完全一致	言い換え、曖昧な問い
RAG	頻繁に更新される知識。根拠を示すこと	口調や形式を固定すること
ファインチューニング	出力の形式・口調。分類の精度	知識の更新（そのつど学習し直しになる）

「社内の知識を持たせたい」なら、まずRAGです。ファインチューニングの判断はファインチューニングとは？その前に分類ではないかを疑うに整理しています。

RAGとファインチューニングの使い分け

排他ではありません。両方使う構成が普通です。知識はRAGで外から渡し、答え方の型はファインチューニングで固める。

迷ったらRAGから始めてください。効果が出なかったときに、やめる費用が小さいためです。

RAGのメリット1｜学習し直さずに済む

モデルに手を加えないので、追加学習のための計算資源も、専門の人材も要りません。

効いてくるのは初期費用より、更新のたびの費用です。規程が変わるたびに学習し直す構成と比べると、差は毎月出ます。

RAGのメリット2｜最新の情報に追従できる

データベースを更新すれば、その日から回答に反映されます。

RAGのメリット3｜根拠を示せる

どの文書をもとに答えたかを、回答と一緒に出せます。

これが業務で使えるかどうかの分かれ目です。出典の無い回答は、確認のために結局その資料を探すことになります。

RAGのメリット4｜挙動を制御できる

渡す資料の範囲を絞れば、答えられる範囲もそこに収まります。

「答えさせない」を設計できるのが、モデル任せの構成との大きな違いです。

RAGのメリット5｜属人化が解ける

「あの人しか知らない」が、文書として引ける状態になります。部署や権限に応じて、渡す資料を変えることもできます。

活用例1｜社内ナレッジ検索・社内ルールの問い合わせ

規程、手順書、過去の提案書を横断して引きます。「経費の締め日はいつか」のような質問に、根拠つきで答えます。

活用例2｜カスタマーサポート

製品マニュアルとFAQを根拠に、顧客からの問い合わせへ一次回答します。

最初の1つ目は、ここから始めるのが安全です。質問の型が決まっており、正解も決まっているので、評価しやすいためです。

活用例3｜社内ヘルプデスク

情シスや総務への定型的な質問を一次受けし、解決できないものだけ人へ渡します。

効果は「解決率」で測ってください。応答件数で測ると、答えられていない応答も数に入ります。

RAGの限界とデメリット

• 検索で外すと、答えも外す — 渡されなかった情報には答えられない
• 誤りが完全には消えない — 渡した資料の解釈を誤ることはある
• 元の文書が間違っていれば、間違ったまま答える
• 集計や計算は苦手 — 「合計で何件」は検索では答えが出ない
• データ整備の手間が続く — 作って終わりにできない

3つ目は仕組みの限界ではなく、資料の問題です。RAGを入れると、社内文書の古さと矛盾が一気に表に出ます。

落とし穴｜チャンク（分割単位）のサイズ

長い文書は、検索の単位に切り分けます。この単位をチャンクと呼びます。

症状で見分けられます。「途中から答えが始まる」なら小さすぎ、「聞いていないことまで答える」なら大きすぎです。見出し単位で切り、見出しの文言をチャンクに含めるのが定石です。

落とし穴｜類似検索だけでは届かない質問がある

「一番新しいのはどれ」「合計で何件」のような質問は、意味が近い文書を探しても答えが出ません。

意味検索とキーワード検索を併用し、数字や日付は検索ではなく属性で絞るのが基本の手です。

精度を上げる打ち手と、その順番

• チャンクの作り直し — 見出しや表の構造に合わせて切り直す
• ハイブリッド検索 — 意味検索とキーワード検索の結果を混ぜる
• リランキング — 取り出した候補を、別のモデルで並べ替える
• クエリの書き換え — 曖昧な質問を、検索に向く形に直してから探す
• HyDE — 仮の答えを先に作り、その文で検索する

この順番が大事です。チャンクの切り直しが最も効いて、最も安く済みます。手の込んだ手法を足す前に、切り方を疑ってください。

出力の精度をどう測るか

• 検索の評価 — 正解の文書が、取り出した中に入っていたか
• 生成の評価 — 渡した資料の範囲で答えているか（作っていないか）

この2つを分けて測るのが要点です。まとめて「答えが変」と扱うと、直す場所が分かりません。質問と正解のセットを資産として貯めてください。設定を変えたときに、良くなったか悪くなったかが即座に分かります。

利用部門との認識がずれる

作る側は精度の話をし、使う側は「探すのが面倒」の話をしています。

想定質問を、利用部門に書いてもらってください。開発側が考えた質問は、たいてい答えやすい質問になっています。

導入の進め方1｜想定質問と要件を決める

誰の、どんな問いに答えるのかを先に決めます。「社内のことなら何でも」を目標にすると、評価ができません。

実務では、想定質問を30件書き出すところから始めます。この30件に答えられるかが、そのまま合否の基準になります。

導入の進め方2｜データを選び、整える

• 古い版と現行版が混在していないか
• 同じ内容の文書が複数ないか
• スキャンした画像のPDFになっていないか
• 誰が見てよい文書かの区別が付いているか

4つ目を後回しにすると、あとから権限を付け直すことになります。人事評価や給与の文書が混ざったまま全社公開する事故は、ここで防ぎます。

導入の進め方3｜分割し、ベクトル化して格納する

文書をチャンクに切り、埋め込みモデルで数値に変換し、索引を付けてデータベースへ入れます。

このとき、文書の属性（部署・作成日・機密区分）も一緒に入れてください。後で「営業部の、今年の資料だけ」と絞れるかどうかが、ここで決まります。

導入の進め方4｜検索とLLMをつなぐ

質問を受けて検索し、取り出した内容をAIへ渡す部分を作ります。

渡す件数と文字数の上限を、最初に決めてください。多く渡せば良くなるわけではありません。関係の薄い文書が混ざると、精度は下がります。

導入の進め方5｜小さく試して評価する（PoC）

いきなり全社の文書を入れず、1部署・1業務から始めます。

PoCの合格条件を、始める前に決めてください。「便利そう」で終わるPoCの多くは、合格の定義が無いまま始まっています。

導入の進め方6｜公開して、運用に乗せる

更新の仕組み、権限、監視、問い合わせ窓口を決めて公開します。

手作業での再投入は、必ず止まります。元の保管場所の更新を検知して自動で入れ直す仕組みを、最初から組んでください。

セキュリティとアクセス権限

見てよい人だけが見られる状態を、検索の段階で担保します。

生成の段階で隠すのでは間に合いません。検索で取り出せてしまった時点で、その内容はAIに渡っています。

情報漏えいのリスクと対策

• 外部のLLMへ送る内容が、学習に使われない契約になっているか
• 個人情報や機密文書を、そもそも入れない区分にしているか
• 誰がいつ何を聞いたかのログを残しているか

3つ目は、事故が起きたときの調査に必要です。入れる前に決めておかないと、後から遡れません。

運用とメンテナンスのコツ

• 更新を自動で検知して入れ直す
• 答えられなかった質問を記録して、資料の穴として扱う
• 使われ方を見て、想定質問の一覧を育てる
• 定期的に評価を回し、劣化に気づけるようにする

2つ目が、いちばん安く効く改善です。答えられなかった質問は、そのまま「書かれていない資料」の一覧になります。

社内に浸透させる

作っても使われないRAGは珍しくありません。

「AIに聞く」を新しい習慣として足すのではなく、いま使っている場所（チャットや検索窓）の中に置くのが確実です。

体制と、外部に頼むかどうか

	向いているとき	注意点
自社開発	継続して育てる前提がある。社内に技術者がいる	立ち上げに時間がかかる。評価の仕組みまで自作する
外部委託	早く立ち上げたい。まず効果を確かめたい	運用と更新を誰が持つかを契約に書く

委託先を選ぶときは、構築の実績より「評価の方法を持っているか」を見てください。作れる会社は多く、良くなったかを測れる会社は多くありません。構築の手順と費用はRAG構築｜7つの手順とチャンク分割・検索精度の上げ方に整理しています。

どのくらいのデータ量があれば始められるか

下限はありません。数十件の文書でも動きます。重要なのは件数ではなく、想定する質問に答えられる材料が入っているかです。

逆に、数万件あっても答えられないことがあります。文書はあるが、聞かれることが書かれていない、という状態です。想定質問30件から逆に材料を集めるほうが、確実に立ち上がります。

ここまでが、RAGとは何かと、その仕組みの教科書どおりの整理です。検索して、渡して、答えさせる。データを整え、切り方を直し、評価して、更新し続ける。この順番どおりに組めば、RAGは動きます。

この記事の後半で扱うのは、動いたその先です。文書を片端から入れて検索させる作りは、最初の一歩としては正しい。そこから伸び悩む理由と、強くしていく順番を見ていきます。

① 社内の知識は、1種類ではない

まず、社内にある知識を、素直に並べてみます。

→ 表のデータ（構造化データ）。顧客マスタ、売上、在庫、契約。表の形をしていて、数値の集計や、正確な絞り込みが求められるもの。

→ 文書（非構造化データ）。マニュアル、議事録、日報、提案書。文章の形をしていて、「だいたいこういうことが書いてある文書」を探したいもの。

→ つながり（関係性情報）。この部署はどの部署の下にあるか、この機能はどのライブラリに依存しているか。点と点の「つながり」そのものが知識になっているもの。

この3つは、問いのかたちが違います。

「先月の東京エリアの売上合計は？」——これは表への問いです。答えは1つに定まり、間違ってはいけません。これは“似た文を探す”仕事ではなく、“台帳を正確に足し算する”仕事です。電卓の担当で、意味検索の担当ではありません。

「配送遅延のときの返金ポリシーは？」——これは文書への問いです。近い意味の記述を探してきて、要約します。

「この機能を止めたら、どこに影響が出る？」——これはつながりへの問いです。関係を1歩ずつたどっていく必要があります。

いわゆる普通のRAGが使うベクトル検索（文章を「意味の座標」に変換して、近いものを探す方法）は、真ん中の問いが得意です。ただ、意味は掴めても、型番や人名のような“語句の厳密な一致”は取りこぼしやすいという癖があります。「XR-200という型番の不具合」を探したいのに、意味の近い別の型番の文書を持ってきてしまう、というやつです。

つまり、社内文書を全部ベクトル検索に任せる作りは、意味で探す問いには強い一方で、正確な集計（表）にも、厳密な語句一致にも、関係をたどる問いにも、そのままでは十分に届きません。これは腕の問題ではなく、道具の得意分野の問題です。

② その前に――まず「ひとつの文書検索」を強くする

ここが、いちばん飛ばされがちで、いちばん効くところです。

「精度が出ない」と、すぐ別のデータベースを足したくなります。でも、その前にやるべきことがあります。同じ文書検索を、二段構えで強くすることです。

一段目：ハイブリッド検索。 先ほどの「型番を取りこぼす」問題は、意味検索にキーワード検索（語句がそのまま一致するものを拾う、昔ながらの検索。BM25という定番の方法があります）を組み合わせると、大きく改善します。意味の近さで「似た話を思い出す」検索と、語句の一致で「目次から拾う」検索の、二刀流です。片方だけだと、意味検索は固有名詞を取りこぼし、キーワード検索は言い回しの違いを取りこぼす。両方を回して結果を混ぜる（RRFという合流のさせ方がよく使われます）と、取りこぼしが減ります。

二段目：リランキング。 一段目で、関連しそうな候補をやや多めに、たとえば数十件かき集めます。そのあと、候補を1件ずつ丁寧に読み直して、本当に関連の高い順に並べ替える専用のモデル（cross-encoderと呼ばれる、リランカー）を通します。ざっと集める司書と、精読して並べ替える司書を分けるイメージです。最初から精読で全文書を評価するのは重すぎるので、「ざっくり集める→精読で並べ替える」の二段にする。これがいまの定番の形です。

ハイブリッド検索＋リランキングとは、意味検索だけに頼らず、キーワード一致と意味の近さを併用して候補を集め、それを精読モデルで並べ替える二段構えの文書検索のことです。 地味ですが、「RAGの精度を上げたい」という話の、最初にして最大のレバーは、たいていここにあります。別のデータベースを足すのは、ここをやり切ってからで十分です。

（あわせて、文書をどう区切って入れるか＝チャンク設計や、部署・日付などで絞り込むメタデータの付け方も、精度を左右します。派手ではありませんが、実装の手間の多くは実はここに乗ります。）

③ だから、検索の「戦略」は多面的になる

文書検索を強くしても、①で見たとおり、表への問いとつながりへの問いは、まだ残っています。ここで初めて、道具を増やします。ただし、増やすのは「箱」ではなく「戦略」です。

• 表のデータには、SQL。 顧客や売上のような構造化データは、リレーショナルデータベース（RDB。SQLで正確な集計・絞り込み・結合ができるデータベース）で扱うのが正解です。ここで使うのがtext-to-SQL――人の質問を、AIがSQLという集計の言葉に翻訳して、台帳を正確に計算させるやり方です。「先月の東京の売上」は、文章を意味検索するのではなく、SQLで足し算させる。電卓の仕事は、電卓にやらせるということです。
• 文書には、②で強くした意味検索（ハイブリッド＋リランキング）。
• つながりには、グラフ。 組織構造や技術の依存関係のような「たどる」問いには、点と点の関係を保持するグラフデータベースが向きます。ただし、これは多段の関係推論が本当に必要なときに足すもので、常に要るわけではありません。

この「問いの性質ごとに、適した検索戦略を使い分ける」設計を、ここでは「多面的RAG」と呼びます。多面的RAGとは、すべてをひとつの検索に押し込むのではなく、表はSQL、文書は意味検索、つながりはグラフ、と問いの性質に合わせて検索の戦略を使い分けるRAGのことです。

ひとつ、実務で誤解されやすい点を補足します。これは「物理的なデータベースを3つ立てて統合する」という意味ではありません。 たとえばPostgreSQLにpgvectorという拡張を足せば、SQLの集計とベクトル検索は同じ1つのデータベースの中でできます。大事なのは箱の数ではなく、問いに応じて検索の戦略を選べることです。「3種類」なのは、知識の性質と問いのかたちであって、データベースの台数ではありません。

なお、「グラフ」と聞いて思い浮かべる最近の技術に GraphRAG がありますが、これは少し別物なので切り分けておきます。ここでの「グラフ」は、あらかじめ分かっている関係（組織図・依存関係）を保持してたどる話。一方のGraphRAGは、大量の文書からAIが自動で“登場人物の相関図”を組み立て、「今期の全社的なテーマは何か」といった、文書全体を見渡さないと答えられない問いに使う手法です。「関係を格納してたどる」のと、「文書から関係を描き起こして俯瞰する」のは、目的が違います。混同しないでおくと、設計を誤りません。

④ 問いに応じて選び、必要なら何度も取りにいく――Agentic RAG

戦略が複数あるなら、次は「どの問いに、どの検索を向けるか」という交通整理が要ります。ここを人間が固定のルールで書き切ろうとすると、すぐ苦しくなります。現実の問いは、きれいに分かれてくれないからです。

「この顧客に、去年提案した内容と近いものを、もう一度出したい」——これは、顧客の特定（SQL）と、過去提案の意味検索（文書）と、案件のつながり（グラフ）が、1つの問いに混ざっています。

そこで、交通整理そのものをエージェントに任せます。ここで大事なのは、Agentic RAGは「振り分け」だけではない、ということです。中身は、だいたい4つの動きでできています。

→ ①問いを理解して、分解する（「顧客を特定して」「その顧客の過去提案を探して」「近い案件をたどって」と小さな問いに割る）。

→ ②それぞれに、どの検索を使うか選ぶ（これがルーティング）。

→ ③足りなければ、もう一度取りにいく（一度で足りない多段の調べもの。multi-hop）。

→ ④答えを自分で点検してから返す（取ってきた根拠で本当に答えられているかを確かめる。self-reflection）。

Agentic RAGとは、問いを分解し、必要な検索を選び、足りなければ取り直し、答えを自己点検してから返すRAGのことです。 ルーティングはその一部であって、全部ではありません。人間が資料を調べるとき、一回検索して終わりにはせず、足りなければ調べ直し、答えを見直しますよね。あれをそのまま仕組みにしたもの、と思ってください。

（よく「エージェントが確率的に最適な知識を合成する」と説明されますが、正確には“確率で良くなる”のではなく、この分解・選択・再取得・点検という手続きで精度を上げています。ここは誤解されやすいところです。）

なお、何でもエージェントの判断に任せればいいわけではありません。SQLの集計のように答えが1つに定まる処理は、確実な関数処理の側に残す。どこまでをAIの判断に任せ、どこを確実な処理に残すかという線引きは、LLMに任せる領域と、関数処理に残す領域の境界として別の記事に書いたのと、同じ設計問題です。

⑤ 作って終わりにしない――更新し、評価し、自走させる

もう1つ、あるべきかたちとして書いておきたいことがあります。

RAGは、作って納品したら完成、というものではありません。作ってからが本番です。 検証で手応えがあったのに本番に辿り着かないRAGの多くは、精度ではなく、この「作ってから」の設計を後回しにしたところで止まっています（PoCが本番に辿り着かない構造については、別の記事に書きました）。

参照するデータは、日々変わります。新しいマニュアルが増え、古い規程が廃止される。この更新が止まった瞬間から、RAGは静かに劣化します。間違ったことを言い出すのではなく、少しずつ、自信を持って「古い正解」を返すようになる、という一番気づきにくい形で。

だから、劣化を数字で捕まえる仕組みをセットで持ちます。RAGの評価には、いくつかの観点があります。取ってきた根拠に忠実に答えているか（忠実性）／質問にちゃんと答えているか（関連性）／取ってきた根拠は的外れでないか（文脈の精度）。こうした指標を測るツール（RAGASなどが知られています）で、「先週より賢くなったか・鈍っていないか」を目で見えるようにする。感覚で運用しないことです。

加えて、知識源に該当情報がないとき、それらしい嘘を作らず、「見つかりませんでした」と正直に返して、必要なら別の手段に戻る――そういう「戻り先」を最初から用意しておくのも、あるべき設計の一部です。ゼロ件を、平然と埋めさせない。

そして最後に、いずれ社内で自走できる状態に引き渡すところまでを、最初から視野に入れておくのがいいと思います。外の専門チームが作り続けなければ動かないRAGは、便利ではあっても、自分たちの資産にはなりきりません。この「作って終わりにしない」感覚は、人の判断の癖を書き下してAIに引き継がせる話とも地続きです。関心があればこちらの記事も読んでみてください。

あるべき姿を、ひとつの絵にすると

ここまでを、順番の形でまとめます。

→ まず、何を賢くしたいのかを決める。RAGは手段なので、どの業務のどの判断を助けるかが先です。汎用のチャットに社内文書を繋いで「何でも聞いてください」と置くより、特定の業務に最適化した、自分たちの仕組みに寄せるほうが、精度も、使われているかどうかも、はっきり測れるようになります。

→ 次に、ひとつの文書検索を強くする。ハイブリッド検索＋リランキング。ここが最初で最大のレバー。

→ その上で、検索の戦略を多面的にする。表はSQL（text-to-SQL）、文書は意味検索、つながりはグラフ。ただし箱は1つに寄せてよい。

→ そして、問いに応じて選び、足りなければ取り直す（Agentic RAG）。

→ 最後に、評価で測りながら育て、社内で自走させる。

派手さはありません。でも、RAGを本気で成果につなげようとすると、だいたいこの順番に落ち着きます。逆に言えば、いきなり別のデータベースを足そうとしているなら、その手前に、まだ効く一手（ハイブリッド＋リランキング）が残っている、ということでもあります。

RAGは、社内の知識という「もともと多面的なもの」を扱う技術です。だから、道具の側も多面的になるのだと思います。

よくある質問（と僕の答え）

Q. RAGの精度を上げたいとき、まず何をすればいいですか？

別のデータベースを足す前に、ひとつの文書検索を強くするのが先です。具体的には、キーワード一致と意味検索を組み合わせるハイブリッド検索と、拾った候補を精読して並べ替えるリランキング（cross-encoder）。これだけで、型番や人名のような固有名詞の取りこぼしが減り、上位の関連度が上がります。ここを飛ばして別DBを足しても、たいてい期待ほど効きません。

Q. RAGは結局、いくつのデータベースが必要なのですか？

物理的なデータベースは1つでも構いません。たとえばPostgreSQLにpgvectorを足せば、SQLの集計とベクトル検索は同じ場所でできます。大事なのは「箱の数」ではなく、問いの性質に合わせて検索の戦略を使い分けることです。関係をたどるグラフは、多段の関係推論が本当に要るときにだけ足すのがいいと思います。

Q. Agentic RAGとは何ですか？

問いを理解して分解し、どの検索を使うかを選び、必要なら何度も取り直し、答えを自分で点検してから返すRAGのことです。ひとつの固定した検索を一回だけ回すのではなく、人間の調べもののように、足りなければ調べ直す。ルーティング（振り分け）はその一部で、多段検索や自己点検まで含めた振る舞い全体を指します。

もし、いま社内のRAGが「文書をベクトル検索に入れただけ」で止まっていて、次の一手を考えているところなら、まずはハイブリッド検索とリランキングを入れて、評価で測ってみるところから景色が変わります。戦略の設計から、多面的なRAGの実装、社内で自走させるところまで、一緒に考える相手が必要でしたら、社内データを対象にしたRAG構築の支援の内容を眺めてみるか、お問い合わせからご相談ください。

今日は、精度を上げる順番の話でした。別のDBを足すのは、ひとつの検索をやり切ってから。RAGが多面的になるのは、社内の知識が最初から多面的だから。それ以上でも以下でもありません。

白状すると、僕が最初に作ったRAGは、社内のPDFを片っ端からベクトル検索に放り込んだだけの、まさに冒頭の「悪くはないけど頭打ちになるやつ」でした。しかもしばらく、堂々と古い答えを返しているのに気づかず、けっこう使える気でいました。順番を知ったのは、だいぶあとです…。

以上です。

RAGのよくある質問

RAGとは何ですか？

Retrieval-Augmented Generation の略で、質問に関係する文書をまず検索し、その中身をAIに読ませてから答えさせる仕組みです。日本語では検索拡張生成と訳します。AIに知識を覚えさせるのではなく、その場で資料を渡すのが要点で、モデル自体には手を加えません。持ち込み禁止の試験を、持ち込み可の試験に変えるのがRAGだと考えると分かりやすくなります。

RAGの仕組みを教えてください。

名前のとおり3フェーズです。検索（Retrieval）で質問に関係する文書をデータベースから取り出し、拡張（Augmentation）でその中身を質問と一緒にAIへ渡し、生成（Generation）で渡された資料を根拠に答えを書かせます。RAGの品質問題は、ほとんどが1つ目の検索フェーズの問題です。関係のない文書を渡せば、AIはその関係のない文書をもとに答えます。生成の指示をいくら直しても、そこは直りません。

RAGと従来のLLM・ファインチューニングは何が違いますか？

知識の在り処が違います。従来のLLMとファインチューニングは知識がモデルの内部（学習済みの重み）にあり、更新するには学習し直すしかありません。RAGは知識がモデルの外（データベース）にあるため、データベースを差し替えるだけで更新できます。規程が改訂されるたびに学習し直す構成は現実には回らないので、社内の知識を持たせたいならまずRAGです。

RAGの構成要素は何ですか？

データソース（答えの根拠になる社内文書）、埋め込みモデル（文章を数値の並びに変換する）、ベクトルデータベース（数値を貯めて近いものを探す）、検索の仕組み、LLM（渡された資料をもとに答えを書く）の5つです。検索を意味検索だけで組むと、型番や固有名詞で外します。意味が近いことと、その語が入っていることは別だからです。

RAGのチャンクはどう切ればよいですか？

見出し単位で切って、見出しの文言をチャンクに含めるのが定石です。文字数で機械的に切ると、文の途中で分かれて意味が壊れます。症状で見分けられます。回答が途中から始まるならチャンクが小さすぎ、聞いていないことまで答えるなら大きすぎです。手の込んだ最適化を足す前に、切り方を疑ってください。最も効いて、最も安く済みます。

RAGの精度が頭打ちになったら、何をすればよいですか？

打ち手は、ハイブリッド検索（意味検索とキーワード検索を混ぜる）、リランキング（候補を別のモデルで並べ替える）、クエリの書き換え、HyDE（仮の答えを作ってその文で検索する）、チャンクの作り直しです。ただし順番があります。まずチャンクの切り直し、次にハイブリッド検索とリランキング。評価は検索（正解の文書が取り出せたか）と生成（渡した資料の範囲で答えているか）に分けて測ってください。