RAGの精度向上とは、ベクトル検索だけに頼らず、全文検索（BM25）やナレッジグラフ、リランキングを組み合わせてハルシネーションを抑え、回答品質を本番運用レベルへ引き上げる一連の手法である。 PoCでは十分に答えられていたのに、本番のデータ量や質問の多様性に直面した途端に精度が崩れる——RAG開発でほぼ必ず通る壁だ。本記事は、RAGの初期構築を終えた開発者・AI担当者に向けて、「評価指標の設計 → 検索の改善 → 生成の制御」という改善の順序に沿って、何を・どの順番で手を入れれば精度が伸びるのかを実装レベルで解説する。やみくもに部品を足すのではなく、効果を数値で確認しながら積み上げる進め方を示す。

PoC段階で高精度だったRAGが本番で崩れる主因は、モデルの賢さではなく「検索（Retrieval）が必要な文書を拾えていない」ことにある。 ここではまず、精度が伸び悩む構造的な理由を、ベクトル検索の限界とハルシネーションの発生源という2つの観点から整理する。

ベクトル検索は文の意味的な近さを捉えるのが得意な一方、特定のキーワードと完全一致させる用途では取りこぼしが起きやすい。典型的なのは、型番・商品コード・人名・法令番号・社内固有の略語といった「意味よりも文字列そのものが重要」な情報だ。たとえば「型番 ABC-1200 の仕様」という質問に対し、埋め込みベクトルは「ABC-1100」や「類似製品の仕様」を意味的に近いと判断してしまい、肝心の正確な型番を含むチャンクが上位に来ないことがある。

もう一つの落とし穴は、質問と文書で語彙が食い違うケースだ。利用者が「退職金」と書いても社内規程では「退職給付」と表現されている場合、意味は同じでも表記が違うだけで、埋め込みモデルの学習データ次第ではスコアが伸びない。こうした語彙の不一致（lexical gap）は、後述するBM25のような全文検索を併用することで大きく改善できる。意味検索とキーワード検索は、どちらかが優れているのではなく、取りこぼす情報の種類が異なるため補完関係にある——これが実務的な捉え方だ。

RAGにおけるハルシネーション（事実に基づかない生成）は、生成モデルの「嘘つき度合い」よりも、その手前の工程に原因があることが多い。現場で切り分けると、おおむね次の3つに集約される。

第一に、検索が失敗しているケース。回答の根拠となる文書がそもそも検索結果に含まれていなければ、モデルは事前学習の知識で埋め合わせようとし、もっともらしい誤りを生む。第二に、検索はできているが文脈が不十分なケース。チャンクが小さすぎて前後の文脈が切れていたり、表の一部だけが渡されたりすると、モデルは欠けた情報を推測で補う。第三に、プロンプトの制御不足。「検索結果に書かれていない場合は『分かりません』と答える」といったグラウンディングの指示が弱いと、根拠がなくても回答を作ってしまう。

重要なのは、この3つで打ち手がまったく異なる点だ。検索失敗ならハイブリッド検索やリランキング、文脈不足ならチャンク設計、制御不足ならプロンプトと出力制約——と切り分けてから手を入れないと、的外れな改善に時間を浪費する。「ハルシネーションが多い」をひとくくりにせず、原因を分類することが改善の出発点になる。

精度改善の第一歩は、検索改善でも生成改善でもなく「測れるようにすること」だ。 何を直したらどれだけ良くなったのかを数値で追えなければ、改善は勘に頼ることになる。ここでは、本番運用を見据えた評価指標の設計と、自動評価・定性評価の組み合わせ方を解説する。

RAGの評価では、生成と検索を分けて測るのが定石だ。代表的な指標は次の3つで、それぞれ別の問題を検知する。

Faithfulness は、回答に含まれる主張が検索された文脈で裏付けられる割合を示す。これが低ければ、モデルが根拠なく語っているサインだ。Answer Relevancy は、質問に対して回答がどれだけ的を射ているかを測る。文脈は正しくても、回答が冗長・曖昧だと下がる。Context Recall は、正解に必要な情報を検索段階でどれだけ拾えたかを示し、検索（Retrieval）側の品質を直接反映する。

この3指標を分けて見ることで、「生成が悪いのか、検索が悪いのか」を切り分けられる。Faithfulnessは高いのにContext Recallが低ければ、改善の焦点は生成ではなく検索側にあると判断できる。指標を一つの総合点に丸めず、原因別に読むことが肝心だ。

上記の指標を毎回手作業で採点するのは現実的ではない。そこで使われるのが、RAGASに代表される自動評価フレームワークだ。これらは、質問・検索された文脈・生成された回答（必要に応じて正解）を入力すると、LLMを採点者（LLM-as-a-judge）として用いて各指標のスコアを算出する。

運用の出発点として有効なのは、本番で想定される質問を50〜100問ほど集めた**評価用データセット（ゴールデンセット）**を作ることだ。代表的な質問、エッジケース、過去にうまく答えられなかった質問を意図的に混ぜておく。検索方式やチャンクサイズを変えるたびにこのデータセットでスコアを取れば、変更が改善なのか改悪なのかを定量的に判断できる。

ただし、LLMによる自動採点は万能ではない。採点用モデルや採点プロンプト次第でスコアがぶれるため、常に同じ条件で比較することが前提になる。絶対値そのものより、施策前後の相対変化を追う使い方が安全だ。スコアが不自然に高い・低い項目は、必ずいくつか目視で実際の回答を確認し、自動評価を過信しないようにする。

自動評価のスコアが上がっても、ユーザー体験が良くなったとは限らない。数値では捉えにくい「回答の分かりやすさ」「トーン」「過不足のなさ」は、人による定性評価で補う必要がある。

実務で機能しやすいのは、週次などの頻度で実際の利用ログから数十件をサンプリングし、担当者が良し悪しをレビューする運用だ。その際、単に○×を付けるのではなく、悪かった回答について「検索が悪いのか・生成が悪いのか・質問自体が曖昧なのか」を分類しておくと、次に着手すべき改善対象が自然に浮かび上がる。

もう一つ有効なのが、ユーザーからのフィードバック（👍／👎ボタンや自由記述）を蓄積し、👎が付いた質問を優先的に評価データセットへ取り込むサイクルだ。定量指標で全体傾向を監視し、定性評価で個別の失敗を掘り下げる——この二段構えにすると、スコアだけを追って現場の実感と乖離する事態を避けられる。評価は一度作って終わりではなく、失敗例を吸収して育てていく資産だと考えたい。

ハイブリッド検索とは、キーワード検索（BM25）とベクトル検索を併用し、両者のスコアを統合して検索結果を決める方式だ。 多くのRAGで、検索精度を底上げする最も費用対効果の高い一手になる。ここでは統合の仕組みと、チャンク設計・多言語対応という実装上のポイントを扱う。

BM25（キーワードの一致度に基づく古典的な全文検索）とベクトル検索は、スコアの尺度がまったく異なる。BM25のスコアは理論上の上限がなく、ベクトル検索のコサイン類似度は0〜1付近に収まる。この2つを単純に足し合わせると、片方のスケールに引っ張られて意味をなさない。

そこで広く使われるのが RRF（Reciprocal Rank Fusion／逆順位融合） だ。RRFはスコアの絶対値を捨て、各検索方式での「順位」だけを使う。具体的には、各文書について 1 / (k + 順位) を検索方式ごとに計算し、それらを合計して最終順位を決める（kは上位の影響を緩和する定数で、60前後がよく使われる）。

RRFはパラメータが少なく、ベクトル検索・BM25のどちらが強いデータでも破綻しにくいため、最初の統合方式として扱いやすい。まずRRFで土台を作り、評価データセットで物足りなければ重み付けやリランキングを足す——この順序が堅実だ。

検索の上限はチャンク（文書を分割した単位）の設計で決まる。チャンクが大きすぎると無関係な情報が混ざってノイズになり、小さすぎると文脈が切れて意味が通らなくなる。万能の数値はないが、出発点としては1チャンク300〜800トークン程度から始め、評価データセットで調整するのが現実的だ。

隣接チャンク間に重複（オーバーラップ）を持たせると、文や段落の境界で情報が分断される問題を緩和できる。10〜20%程度の重複が目安になる。ただし重複を増やすほどインデックスは肥大化し、同じ内容が複数ヒットして検索結果が冗長になるため、やみくもに増やすのは避ける。

より効果的なのは、文字数で機械的に切るのではなく、見出し・段落・箇条書きといった文書構造に沿って分割することだ。表は途中で割らず1チャンクにまとめる、見出しをチャンク先頭に付与して文脈を保つ、といった工夫で、同じトークン数でも検索のヒット品質が上がる。チャンク設計は一度決めて終わりではなく、失敗した回答を見ながら見直し続ける対象だと考えておきたい。

日本語・英語に比べ、ラオス語やタイ語のような低リソース言語では、RAGの精度が落ちやすい落とし穴がいくつかある。第一にトークナイズと単語分割だ。タイ語やラオス語は単語間にスペースを置かない言語のため、分割を誤ると検索の単位が崩れ、BM25のキーワード一致が機能しにくくなる。言語に対応した分割処理を前段に入れるかどうかで結果が大きく変わる。

第二に埋め込みモデルの言語カバレッジ。多言語対応をうたう埋め込みモデルでも、学習データに占める東南アジア言語の比率は小さいことが多く、意味検索の精度が主要言語ほど出ないことがある。導入前に、対象言語の実データで検索品質を必ず検証すべきだ。

第三に混在表記。現場の文書では、専門用語が英語のまま書かれていたり、複数言語が1文に混ざったりする。この場合こそ、キーワード一致に強いBM25とのハイブリッド検索が効く。低リソース言語ほど、意味検索単独ではなくハイブリッド構成の恩恵が大きい——主要言語向けの常識をそのまま持ち込まないことが重要だ。

グラフRAGとは、文書をベクトル化するだけでなく、エンティティ（人・組織・製品など）とその関係をナレッジグラフとして保持し、関係をたどって回答を組み立てる手法だ。 複数文書をまたぐ質問に強い一方、導入コストも高い。どんな場合に投資へ見合うのかを整理する。

通常のRAGは、質問に近いチャンクを個別に拾ってくる。このため「複数の文書をまたいで関係を統合しないと答えられない質問」に弱い。たとえば「製品Aの不具合に関わった部署と、その部署が過去に対応した類似案件は」といった問いは、製品・不具合・部署・案件という複数エンティティの関係をたどる必要があり、単純な類似度検索では断片的な情報しか集まらない。

グラフRAGは、文書からエンティティと関係を抽出してナレッジグラフを構築し、検索時にそのグラフをたどることで、散在する情報を関係性ごと束ねて取り出せる。結果として、「全体像を要約せよ」「AとBの関連を説明せよ」といった横断的・俯瞰的な質問への回答品質が上がりやすい。

逆に、単一文書内で完結する事実確認型の質問（「この規程の有効期限は」など）では、グラフ化の恩恵は小さい。グラフRAGは「関係をたどる必要があるか」が有効性の分かれ目になる、と覚えておくとよい。

グラフRAGの難点はコストだ。文書からエンティティと関係を正確に抽出する工程（多くはLLMで実行）が追加で必要になり、文書量に比例して抽出コストと構築時間がかかる。グラフのスキーマ設計や、文書更新時のグラフ再構築フローも運用負荷になる。

そのため、最初からグラフRAGに飛びつくのは得策でないことが多い。費用対効果の観点では、まずハイブリッド検索とリランキングで土台を固め、それでも「関係をたどる質問」で精度が頭打ちになった段階で、対象を絞ってグラフRAGを検討するのが現実的な順序だ。

判断材料としては、(1)横断的・関係性の質問が利用全体に占める割合、(2)文書の更新頻度（高頻度だと再構築コストが重い）、(3)エンティティ抽出の精度を担保できるか、の3点を見るとよい。これらが揃わないうちに全面導入すると、構築・保守コストに精度改善が見合わない事態になりやすい。具体的な費用は文書量・モデル単価・運用体制に大きく依存するため、小規模なサブセットでPoCを行い、効果と工数を測ってから判断することを推奨する。

RAGの精度が伸びない現場には、共通する「手を抜きがちな工程」がある。 ここでは特に頻出する2つの失敗——リランキングの省略とインデックスの陳腐化——を取り上げ、原因と回避策をセットで示す。

ハイブリッド検索まで実装したのに精度が頭打ちになる——その多くは、リランキング（再順位付け）を省いていることが原因だ。BM25やベクトル検索は高速に「候補」を集めるのが役割で、上位に本当に関連する文書が来るとは限らない。

リランキングは、検索で集めた上位20〜50件程度の候補を、より精密なモデル（質問と文書をペアで評価するクロスエンコーダなど）で採点し直し、本当に関連する数件を上位へ押し上げる工程だ。初段の検索が「広く速く」なら、リランキングは「狭く正確に」を担う。この二段構えにすると、最終的に生成へ渡る文脈の質が大きく上がる。

ありがちなのは、検索結果の上位5件をそのまま生成に渡してしまう構成だ。候補20件にすれば正解が含まれていたのに、リランキングなしで上位5件に絞ったために取りこぼす。回避策はシンプルで、検索は多めに候補を取り（recall重視）、リランキングで精度を担保（precision重視）してから生成に渡すこと。計算コストは増えるが精度への寄与が大きい工程なので、省略は最後の手段にすべきだ。

精度の問題は検索アルゴリズムだけでなく、データの鮮度にも起因する。元文書が更新されたのにインデックスが追従していなければ、RAGは自信満々に「古い情報」を返す。価格・仕様・規程・在庫のように更新が前提の情報を扱う場合、これは実害の大きい失敗だ。

回避策は、文書の性質に応じた更新パイプラインの設計にある。更新頻度の高いデータは、変更を検知して該当チャンクだけを差分で再インデックスする仕組みを用意する。全件を毎回作り直すのはコストが高く、更新が滞る原因になりやすい。

あわせて、回答に出典（元文書名・更新日）を併記する運用を入れておくと、ユーザー側が情報の新しさを判断でき、古い情報を鵜呑みにするリスクを減らせる。「いつ時点の情報か」を答えに含められない構成は、本番運用では危うい。インデックスの鮮度は、検索アルゴリズムと同じくらい運用の信頼性を左右する要素だと位置づけておきたい。

RAGの精度改善に取り組む開発者・AI担当者から、特に相談の多い2つの疑問について判断の指針を示す。

結論から言えば、多くの場合はRAGの改善を先に試すべきだ。 ファインチューニング（モデル自体を追加学習させる手法）は、文体やフォーマットの固定、専門用語の扱いといった「振る舞い」の調整には有効だが、「最新の事実を正しく答える」課題の解決には向かない。事実の鮮度や根拠の提示はRAG側の役割だからだ。

まず評価指標を整え、ハイブリッド検索・リランキング・チャンク設計で検索品質を上げる。それでも回答のトーンや形式に課題が残る場合に、ファインチューニングを検討する——この順序が、コストと効果のバランスが良い。両者は競合ではなく、解決する問題が異なる補完的な手段だと捉えるのが正確だ。

生成モデルによって回答の傾向に差はあるが、RAGの精度を左右する最大の要因は、モデル選びよりも検索の質であることが多い。どれだけ高性能なモデルでも、根拠となる文書が検索結果に含まれていなければ正しく答えられない。

そのうえでモデル間の違いを挙げるなら、指示への忠実さ（「検索結果にない場合は答えない」をどれだけ守るか）、長い文脈の扱い、出力の安定性などに個性が出る。実務では、自分の評価データセットで複数モデルを同条件で比較し、Faithfulnessや回答関連性のスコアで選ぶのが確実だ。モデルは固定して検索を磨く方が、精度への投資対効果は高い。なお、生成モデルは更新が速いため、選定時点での最新版を改めて検証することを勧める。

RAGの精度向上は、思いつきで部品を足す作業ではなく、順序のある改善プロセスだ。本記事の要点を改めて整理する。

• まず測る：Faithfulness・Answer Relevancy・Context Recallを軸に評価データセットを作り、検索と生成のどちらが弱いかを切り分ける。
• 次に検索を直す：ハイブリッド検索（BM25＋ベクトル、RRFで統合）とリランキングで、生成に渡す文脈の質を底上げする。チャンク設計とインデックスの鮮度も検索品質の一部だ。
• 必要に応じて構造化する：関係をたどる質問が多ければグラフRAGを検討するが、コストに見合うかを小規模PoCで確かめてから判断する。
• 最後に生成を制御する：グラウンディングの指示と出典提示で、根拠のない回答を抑える。

この「評価 → 検索改善 → 生成制御」の順序を守れば、勘に頼らず、施策ごとの効果を数値で確認しながら精度を積み上げられる。当社では、RAGの本番化支援において、この順序での改善が遠回りに見えて最も確実だと考えている。RAGの精度に課題を感じている場合は、まず評価基盤の整備から着手することをおすすめする。