2026.08.02 AI

リトリーバルとは？RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】

リトリーバル（Retrieval）は、質問文を受け取って関連する文書を探し出し、生成モデルに渡す文脈を組み立てるまでの検索工程を指します。RAGの回答品質を分けるのは生成モデルの大きさよりも、この工程が正解を含む文書を上位に持ってこられるかどうかです。この記事では、スパース検索と密ベクトル検索の仕組みの差、実装で決めるパラメータ、精度の測り方、検索側と生成側のどちらに手を入れるべきかの切り分けまでを実装目線で整理しました。判断の根拠は、BM25の既定値やRRFの合成式、pgvectorの索引方式といった公式ドキュメントで確認できる値です。

まとめ：リトリーバルの構成要素と精度が伸びないときの切り分け順

リトリーバルは単一の技術ではなく、文書の前処理・索引作成・候補取得・再スコアリング・文脈組み立ての5工程をまとめた呼び名です。手を入れる順番には優先度があります。まず前処理（チャンク分割と埋め込み）、次に取得方式（スパース検索・密ベクトル検索・両者の合成）、最後に再スコアリング。この順を逆にすると、リランカーを載せても順位が動かないという結果になりがちです。並べ替えは、候補の中に正解が入っていて初めて効きます。

精度が出ないときの切り分けは2手で足ります。取得件数を100件まで広げて正解文書が候補に入るかを見る。入らなければ前処理と取得方式の問題であり、入るのに回答が外れるなら並べ替えかプロンプト側の問題です。文書が数千件規模で語彙が業務用語に偏っているなら、BM25だけで実用水準に届くこともあります。評価セットを作らないまま構成だけ厚くする進め方は費用に見合いません。

リトリーバルの定義と検索拡張生成における検索工程全体の位置づけ

まず、この語がどこからどこまでを指すのかを固定します。範囲が曖昧なままだと、次章以降のパラメータの話が誰の担当かも決まりません。

リトリーバルが担う4工程：クエリ受理から文脈の組み立てまでの範囲

リトリーバルの入力はユーザーの質問文、出力は生成モデルのプロンプトに差し込む文脈テキストです。その間には4つの処理が入ります。クエリの受理と加工、索引への問い合わせ、候補の並べ替え、文脈への組み立て。このうち索引作成と文書のチャンク分割は事前処理として別に走りますが、検索精度の上限を決めるのはこの事前処理の側です。

  1. クエリ加工：質問文の正規化、検索用クエリへの書き換え、絞り込み条件の抽出
  2. 候補取得：索引に問い合わせて上位50〜100件を取り出す
  3. 再スコアリング：候補をクエリとのペアで採点し直し、上位3〜5件へ絞る
  4. 文脈組み立て：本文・出典・メタデータをプロンプトの形式に整える

取得件数を増やしても改善しないなら1と索引側、増やすと正解が入るなら3の設計が薄い、という読み方をします。

レトリーバーとジェネレーターの分業と品質評価が分かれる境界線

RAGは、文書を探すレトリーバーと、その文書をもとに回答文を書くジェネレーターに分かれます。レトリーバーの成績はRecall@kやNDCG@10といった検索の指標で測り、ジェネレーターの成績は根拠との整合や網羅性で測ります。指標が別物なので、片方の改善がもう片方の数値を動かすとは限りません。

この境界を意識せず「RAGの精度が低い」と一括りにすると、対策が空回りします。生成モデルを大きなものへ差し替えても、渡した文脈に正解がなければ回答は変わりません。どちらの数値を上げに行くのかを先に決めてください。

検索エンジンの検索とリトリーバルの違い：読み手がLLMである前提

従来の検索は、結果を人間が読んでクリックする前提で設計されてきました。10件のリンクを並べ、ユーザーが取捨選択する。リトリーバルの読み手は生成モデルで、上位3〜5件がそのままプロンプトに入ります。人間なら無視できる無関係な1件が、誤った根拠になり得る。この違いは設計に3つの影響を与えます。適合率の重みが上がること、文書全体ではなく数百トークン単位の断片を返すこと、出典を機械可読な形で一緒に返すこと。検索結果のスニペット生成を流用すると、文の途中で切れた断片が根拠として渡ります。

スパース検索と密ベクトル検索の仕組みと得意な問い合わせの違い

候補取得の方式は大きく2系統です。どちらが優れているかではなく、どの問い合わせで外すかが選定の判断材料になります。

BM25の仕組みとk1・bの既定値が効く問い合わせのパターン

BM25は、クエリの単語が文書内に何回出るか（TF）と、その単語がコーパス全体でどれだけ珍しいか（IDF）から関連度を計算する方式です。Elasticsearchでは既定の similarity が BM25 に設定されており、公式ドキュメントの既定値は k1 が1.2、b が0.75です。k1 は同じ単語が繰り返し出たときにスコアが頭打ちになる速さを決め、b は文書長による正規化の強さを決めます。

この方式が強いのは、型番・エラーコード・社内の固有名詞・法令名など、表記が一致する語で引く問い合わせです。「ORA-01555」のような文字列は、意味の近さで探すより完全一致で引いたほうが確実に当たります。長短のチャンクが混在する索引では b を下げて長さ補正を弱める調整も効きますが、まず既定値のまま評価セットで測ってから触ってください。

密ベクトル検索の索引方式：HNSWとIVFFlatの選び分け基準

密ベクトル検索は、文章を埋め込みモデルで数百〜数千次元のベクトルに変換し、コサイン類似度などの距離でクエリに近い文書を取り出す方式です。multilingual-e5-large は1024次元、text-embedding-3-small は1536次元を返します。表記が違っても意味が近ければ引ける一方、型番の1文字違いは区別しません。モデルごとの性格差は埋め込みモデルの選び方の側で整理しています。

索引方式は2つに絞って考えれば足ります。PostgreSQLの拡張である pgvector は 0.8.6（2026年7月29日リリース）時点で HNSW と IVFFlat の両方を備えます。HNSW はグラフ構造で検索が速く再現率も高い代わりに、構築時間とメモリを食う。IVFFlat は構築が軽く、代わりに lists と probes の設定で再現率が上下します。文書が10万件を超えて更新頻度が低いなら HNSW、頻繁に作り直すなら IVFFlat という分け方が実務では扱いやすい選択です。

ハイブリッド検索とRRFの合成：rank_constant=60の意味

2方式は排他ではありません。BM25の結果と密ベクトル検索の結果を両方取り、順位を合成するのがハイブリッド検索です。合成に使われる RRF（Reciprocal Rank Fusion）は、各検索結果での順位の逆数を足し合わせます。Elasticsearch の公式ドキュメントに載る式は score = Σ 1 ÷ (k + rank) で、rank_constant の既定値は60です。

定数が60だと、1位の寄与は約0.0164、10位で約0.0143、50位で約0.0091です。上位と下位の差が緩やかに効くため、片方の検索だけが強く推す文書が突出しません。定数を小さくすると上位偏重になり、大きくした場合の順位差はより緩やかです。スコアの絶対値ではなく順位だけを使うので、BM25のスコアと類似度を正規化して足す方式にありがちなスケール調整が不要になります。合成の実装はBM25とベクトル検索を統合するハイブリッド検索の実装で扱っています。

リトリーバル実装の処理順と各工程で決めるべきパラメータの一覧

方式が決まったら、次は工程ごとに数値を決める作業です。決める順番を守らないと、後工程の調整が前工程の欠陥を覆い隠します。

チャンク分割と埋め込みモデルが検索精度の上限を先に決める理由

索引に入っていない情報は、どの検索方式でも取り出せません。長い規程を1文書のまま格納すれば、該当する一節がスコアに埋もれます。細かく切りすぎれば、主語や前提が別チャンクに残って断片だけでは意味を成しません。目安は300〜800トークンと前後10〜20%のオーバーラップですが、見出し単位で区切れる規程やマニュアルなら、トークン数より見出し境界を優先したほうが当たります。分割手法の比較はチャンク分割の手法とサイズの決め方にまとめました。

埋め込みモデルは、多言語対応かどうかと次元数で先に絞り込みます。次元が大きいほど索引のサイズとメモリが増え、10万チャンクを1536次元で持てば単純計算で約600MBです。決め直すと再計算が全件に及ぶため、着手前に評価セットで2〜3モデルを比べておく手順が結局は安く付きます。

クエリ側の前処理：書き換え・分解・メタデータ条件の付与の実装

ユーザーの質問文は、そのまま検索クエリにするには情報が足りません。「去年の分はどうなってる？」は、直前の会話を踏まえて「2025年度の経費精算規程の上限額」のような自立した文へ書き換えて初めて索引に当たります。書き換えはLLMに1回投げる実装が一般的で、応答時間に数百ミリ秒が乗ります。

複合質問の分解も同じ理屈です。「AとBの違いと、それぞれの申請期限」は1本のクエリで両方の文書を上位に持ってこられないため、2〜3本に分けて検索し結果を統合します。質問文から部署・年度・文書種別を抜き出してメタデータの絞り込みに渡せば、候補の母数が減って後段の負荷も下がる。ただし条件抽出を誤ると正解が母数から消えるので、抽出できなかった場合は絞り込まずに全体を検索するフォールバックを必ず入れてください。

二段構成の設計：候補件数の決め方とリランクの担当範囲の線引き

一段目で広く取り、二段目で絞る。この分業がリトリーバル実装の標準形です。一段目の取得件数は50〜100件が扱いやすく、二段目のリランカーで3〜5件へ落とします。件数を決める材料はリランカーのスループットと許容応答時間の2つで、1件あたり数ミリ秒の推論なら100件で数百ミリ秒に達します。

リランカーの種類と選び方はリランクモデルの種類と選び方で扱っています。実装面で押さえるのは、二段目が担うのは並べ替えだけで、一段目の取りこぼしは回復できないという一点です。評価も一段目は Recall@100、二段目は NDCG@10 と分けて記録すると、どちらの変更が効いたかを後から追えます。

リトリーバル精度の測り方と検索側・生成側の不具合の切り分け手順

数値がなければ改善の判断ができません。評価セットの作り方と、症状から原因へ辿る順序を決めておきます。

Recall@kとMRR・NDCG@10の使い分けと評価データの作り方

指標は目的で使い分けます。Recall@k は上位k件に正解文書が含まれる割合で、一段目の取得漏れを見る数値です。MRR は正解が最初に現れた順位の逆数の平均で、1件だけ当てればよい用途に向きます。NDCG@10 は複数の正解に重み付けした順位品質を測り、二段目の並べ替えを評価する数値として使われます。

評価データは、想定される質問50〜100問と正解チャンクIDの対応表で足ります。問題は正解の付与で、ここは業務を知る担当者の作業です。過去の問い合わせ履歴から質問を抜き出し、回答時に参照した文書を紐付ける進め方が現実的でしょう。100問の対応表があれば、索引設定を変えたときの影響を数分で測れます。この投資を省くと、以降の調整はすべて体感頼りになります。

回答が外れたときに検索側と生成側を切り分ける2段階の確認手順

回答が誤っていたとき、最初に見るのは生成結果ではなく検索結果です。手順は2段階。第一に、その質問で取得された候補50〜100件の中に正解チャンクが含まれているかを確認します。含まれていなければ検索側の問題で、対策はチャンク分割・埋め込みモデル・取得方式の見直しに限られます。

第二に、候補に含まれているのに回答が外れる場合、正解チャンクが上位何位だったかを見ます。50位付近に沈んでいれば並べ替えの問題で、リランカーの導入や条件絞り込みが効く。上位3件に入っているのに回答が誤っているなら、原因はプロンプトか生成モデル側です。

密ベクトル検索まで積む条件と全文検索のままでよい条件の判断基準

構成を厚くすれば当たるわけではありません。ここでは条件を切って、どこで止めるべきかを言い切ります。

密ベクトル検索を入れない判断が妥当になる文書量と語彙の具体的な条件

次の条件がすべて当てはまるなら、BM25による全文検索だけで止める判断が妥当です。文書が数千件以下で、利用者が使う語彙が文書内の表記とほぼ一致し、検索対象が型番・規程番号・エラーコードのような一意な識別子を含む。この状況で密ベクトル検索を足しても、埋め込みの生成費用と索引の運用が増える割に Recall@50 はほとんど動きません。

逆に効くのは、質問と文書で言い回しが揃わない場面です。「経費で落ちますか」という質問に対し、規程側の表記が「損金算入の可否」であれば単語一致では引けません。社内の問い合わせ文を集め、その語が文書内にそのまま出現するかを数えてみてください。半数以上が一致するなら、まずBM25側の調整に伸びしろが残っています。

ハイブリッド検索とリランクまで積み上げる判断ラインと費用目安

ハイブリッド構成へ進む判断ラインは明確です。BM25単体と密ベクトル検索単体の両方で評価セットを回し、片方が外す質問をもう片方が拾えているなら合成する価値があります。両者の失敗が同じ質問に集中している場合、原因はチャンク側です。

リランクまで積むのは、Recall@50 が0.9を超えているのに NDCG@10 が伸びない場合に限ります。候補には入っているが順番が悪い、という症状です。GPU推論が要るぶん応答時間と運用費は増えます。1リクエスト200ミリ秒以内といった制約があり、GPUを常時確保できない構成では、候補を20件程度まで絞れない限り見送る判断が合理的です。

失敗パターン：チャンク設計を放置したままリランカーを足す構成

現場で最も多い失敗は、精度が出ない原因をチャンク分割に置いたまま、後段の部品を増やす進め方です。1文書を丸ごと1チャンクにした索引にリランカーを足しても、モデルが受け取るのは長すぎる文書であり、入力長の上限で末尾が切り捨てられます。切り捨てられた部分に正解が書いてあれば、順位は動きません。

もう1つは、評価セットを作らずに設定変更を重ねる進め方です。取得件数を20から50へ、埋め込みモデルをAからBへ、と触るたびに数人が体感で良し悪しを述べる状態では、変更の可否を判断できません。前処理・取得方式・並べ替えの順に手を入れ、各段階の前に数値を取る。この2点だけで無駄な作り込みの大半は避けられます。

開発を外部へ委託する場合の切り分け：索引設計と評価基盤の分担

社内にベクトル検索の運用経験がない状態で全工程を内製すると、索引方式の選定と評価基盤の整備で立ち止まりがちです。外部へ委託する場合も、評価セットの正解付与だけは業務側が持つ必要があります。ここは業務知識がないと付けられず、外注できない部分だからです。索引設計・検索方式の実装・パイプラインの運用は委託し、評価データと合否判断を自社に残す分担が噛み合います。一創ではRAG構築支援で、索引設計から評価の仕組みづくりまでを含めて対応しています。委託先を選ぶ際は、Recall@k と NDCG のどちらをどの工程の指標に置くかを説明できるかを確認してください。構成図にベクトルデータベース名が並ぶだけの提案は、評価の設計が抜けている可能性があります。

日本語の社内文書でリトリーバルを組むときの実装上の注意点と対策

日本語は単語の区切りが明示されないため、英語向けの設定をそのまま持ち込むと取りこぼします。索引側で先に手当てしておく項目を挙げます。

日本語のトークナイズ：kuromojiとN-gramの使い分け

BM25は単語単位で転置索引を作るため、まず文を単語に切る処理が必要です。Elasticsearch では analysis-kuromoji プラグインの形態素解析器が標準的な選択で、辞書に基づいて「経費精算規程」を意味のある単位へ分割します。弱点は未知語で、社内の製品名や略語が辞書にないと不自然な位置で切れるため、ユーザー辞書への登録が前提になります。

もう一方の N-gram（2文字単位のbi-gram）は辞書を持たずに機械的に切るため未知語に強く、部分一致も拾えます。代わりに索引が膨らみ、無関係な文書もヒットしがちです。実務では両方のフィールドを作り、形態素解析側を主、N-gram側を補助として重みを付ける構成が扱いやすい。表記ゆれ（全角半角、送り仮名、カタカナ長音）は ICU normalizer で索引時とクエリ時に同じ正規化をかけて吸収します。

権限フィルタを検索の段階で効かせるメタデータ設計と索引分割の方針

社内文書は誰でも見てよいものばかりではありません。人事評価や役員資料が一般社員の回答に混ざれば、それだけで運用が止まります。原則は、取得後に除外するのではなく検索クエリの段階で権限条件を絞り込みに含めること。後から除外する実装では、上位50件がすべて権限外だった場合に候補が0件になります。

メタデータには閲覧可能な部署コードやロールを配列で持たせ、検索時にユーザーの所属と突き合わせます。テナントが完全に分かれるなら索引そのものを分ける設計のほうが安全です。権限判定を生成モデル側のプロンプトに委ねる実装は、指示が無視された時点で情報が漏れるため採用しません。

文書の更新頻度と再索引のコスト：差分更新で運用を回す設計方針

索引は作って終わりではありません。規程が改訂されれば、該当文書のチャンクを再分割して埋め込みを取り直す処理が要ります。全件を作り直す設計では10万チャンクの再生成に数時間と相応の費用がかかるため、文書ごとにハッシュ値を保持して変更分だけ再処理する差分更新にします。削除された文書のチャンクを索引から確実に消す仕組みも同時に必要です。古い版が残れば、生成モデルは古い規程を根拠に回答します。埋め込みモデルの差し替えだけは全件再計算が避けられません。sentence-transformers は PyPI で 5.6.1 が公開されており（2026年8月時点）、入れ替え自体はコード数行で済みますが、索引の作り直しは数時間単位の作業です。

よくある質問

リトリーバルの実装や用語について、検索されることの多い疑問をまとめました。

リトリーバルとレトリーバーは同じ意味ですか？

指すものが違います。リトリーバル（Retrieval）は「検索して取り出す処理」そのもの、レトリーバー（Retriever）はその処理を担う部品の呼称です。LangChain や LlamaIndex では Retriever がクラス名として現れ、get_relevant_documents のようなメソッドで候補文書を返します。日本語では「検索器」と訳される場合もあります。

リトリーバルだけを改善すれば回答精度は上がりますか？

上がる場合と上がらない場合があります。取得した候補に正解が含まれていないなら、検索側の改善が回答精度に直結します。上位3件に正解が入っているのに回答が外れているなら、原因はプロンプトか生成モデル側にあり、検索をいくら改善しても数値は動きません。候補に正解が入っているかを最初に確認してください。

ベクトルデータベースは必ず必要ですか？

必須ではありません。文書が数千件規模なら pgvector や Elasticsearch のベクトルフィールドで足り、専用のデータベースを別途立てずに済みます。既存のデータベース運用に相乗りできるぶん、バックアップや監視の仕組みも流用できます。数千万件規模でベクトル検索の負荷が支配的になった段階で専用製品への移行を検討する、という順序が無理のない進め方です。

取得件数（top-k）はいくつに設定すればよいですか？

二段構成なら一段目50〜100件、二段目3〜5件が出発点です。一段目の件数は Recall@k を実測して決め、50件で0.95に達しているなら増やす必要はありません。二段目の件数は生成モデルへ渡すトークン量と直結し、1チャンク500トークンで5件なら2,500トークンが文脈として乗ります。

リトリーバルの精度はどのくらいを目標にすべきですか？

用途で変わりますが、社内文書のQ&A用途では Recall@50 で0.9以上を一次目標に置く設計が扱いやすい水準です。ここに届かない状態でリランカーやプロンプトを調整しても、上限は低いまま。0.9を超えた後は NDCG@10 へ指標を切り替え、並べ替えの品質を上げる段階に進みます。評価セットが50問程度だと数値が振れるため、判断は100問規模で行うほうが安定します。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る