RAGとは？精度を上げる「正しい順番」と、社内の知識が多面的だという話

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

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

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

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

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

① まず「ひとつの文書検索」を強くする（別のデータベースを足すのは、その後です）。
② 社内の知識は表・文書・つながりの3種類に分かれているので、検索の戦略が多面的になる。
③ 問いに応じて選び、足りなければ取り直す。これがAgentic 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を片っ端からベクトル検索に放り込んだだけの、まさに冒頭の「悪くはないけど頭打ちになるやつ」でした。しかもしばらく、堂々と古い答えを返しているのに気づかず、けっこう使える気でいました。順番を知ったのは、だいぶあとです…。

以上です。