ハイブリッド検索とRRF｜BM25＋ベクトルを750問で実測・SQL実装

この記事で実際に動かしたもの：RJC の技術記事247本を見出し単位の3,917節に分け、Sudachi と文字 bigram で分かち書きした BM25、TF-IDF＋SVD（LSA）の密ベクトル検索、RRF・重み付き RRF・線形結合を Python で自作し、自分で initdb した PostgreSQL 16 に同じ仕組みを SQL 関数として載せて、750問の Recall@10・MRR@10 と応答時間を測りました。

RAG（検索で集めた文書を LLM に渡して答えさせる仕組み）では、検索で正解の文書を上位に持ってこられなければ、LLM はその文書を読めません。ハイブリッド検索は、その検索部分の取りこぼしを減らすための定番の方法です。この記事は「2つの検索をどう組み合わせるか」に絞ります。評価指標の詳しい解説とチャンク分割の比較は、同じコーパスを使う別の記事（公開準備中）で扱います。

flowchart TD
    Q[質問] --> T[分かち書き]
    Q --> E[埋め込み]
    T --> B[BM25<br>上位100件]
    E --> V[ベクトル検索<br>上位100件]
    B --> F[融合<br>RRF や線形結合]
    V --> F
    F --> R[必要ならリランク]
    R --> L[上位を LLM に渡す]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（Intel Xeon 2.10GHz・2コア・メモリ8GB、ほかの作業と同時に動いている共有のマシン）で、Python 3.13.18・numpy 2.5.3（OpenBLAS、スレッド数1）・scipy 1.18.1・scikit-learn 1.9.1・SudachiPy 0.7.0・SudachiDict-core 20261015 を使いました。コーパスは RJC の技術記事247本の本文（HTML タグを外し、見出し単位で3,917節・5,561,447文字）です。学習済みの埋め込みモデルには接続できないため、ベクトル検索は TF-IDF＋SVD（LSA）で手元で作った密ベクトルを「埋め込みの代わり」に使いました。実際の埋め込みモデルでは、ベクトル側の数字も、融合したときの数字も変わります。PostgreSQL は、ホストの設定を変えないよう Ubuntu の PostgreSQL 16.15 の実行ファイル一式を作業場所に複製し、apt-get download した postgresql-16-pgvector 0.6.0 の .deb をそこへ展開して、作業場所に initdb したクラスタを 127.0.0.1 だけで起動しました。各製品の既定値は公式ドキュメント、RRF の式は Cormack らの原論文、BM25 の式は Apache Lucene の公式ドキュメントで確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年11月4日）。

ハイブリッド検索とは（BM25とベクトル検索を組み合わせる理由）

この節では、ハイブリッド検索が何を組み合わせ、なぜ RAG の検索精度の話で必ず出てくるのかが分かります。

ハイブリッド検索は、性質の違う2つ以上の検索を同じ質問で実行し、結果を1つの順位にまとめる方法です。RAG の文脈では、ほとんどの場合「BM25 などのキーワード検索」と「埋め込みを使ったベクトル検索」の組み合わせを指します。RRF は、その「まとめ方」の1つです。

組み合わせる理由は、2つの検索が取りこぼす質問が違うからです。手元の750問で、BM25 と LSA の上位10件が何件重なるかを数えると、平均6.1件でした。残りの約4件は片方にしか出てこない文書で、ここに相手が取りこぼした正解が入っていることがあります。上位50件ずつを合わせると、重複を除いて平均69.7件になりました。

一方で、2つを足せば必ず良くなるわけではありません。片方が明らかに弱いと、弱い方の順位が強い方の正解を押し下げます。この記事の後半は、その「下がる場面」と「下げない組み合わせ方」を実測で見ていきます。

BM25とベクトル検索の違い（型番・エラー文と言い換えで何が起きるか）

この節では、同じコーパスで BM25 とベクトル検索がそれぞれどんな質問で勝ち、どんな質問で負けるかが、実際の順位で分かります。

手元の BM25（Sudachi の A 単位）と LSA（512次元）で、正解の節が何位に来たかの実例です。「圏外」は上位100件に入らなかったことを表します。RRF は k=60・重みなしです。

言い換えの質問では、BM25 は「描き直す」と本文の「リフレッシュレート」を結び付けられず52位でしたが、LSA は同じ記事で一緒に出てくる語の傾向から1位にしました。逆にエラー文や識別子では、BM25 が1位にしたものを LSA は数十位か圏外にしています。RRF の列を見ると、言い換えでは中間に、識別子では大きく下に引っ張られています。この「下に引っ張られる」幅が、片方の検索が弱いときの RRF の弱点です。

実験の作り方（RJCの技術記事3,917節と評価用の質問750件）

この節では、手元で測った評価セットの作り方と、数字を読むときの前提が分かります。

数字を読むときの注意が3つあります。1つ目は、4種類の比率で全体の数字が変わることです。この評価セットは見出しが半分、エラー文と識別子が4割あり、BM25 に有利な配分です。この記事では種類ごとの数字を必ず並べるので、本番の質問に近い種類の数字を重く見て読み替えられます。2つ目は、言い換えが50問しかなく、1問で MRR が最大0.02動くことです。3つ目は、ベクトル側が本物の埋め込みではなく LSA であることです。指標の意味と、件数によるぶれの見積もり方は、評価指標の記事（公開準備中）で詳しく扱います。

日本語のBM25を自作する（文字bigramとSudachiの比較）

この節では、日本語の BM25 で分かち書きをどうするかで精度がどれだけ変わるかと、BM25 の式とパラメータ k1・b の効き方が分かります。

BM25 は、語 t の珍しさ（IDF）と、文書の中の出現回数 tf を、文書の長さで補正して足し合わせるスコアです。Apache Lucene の BM25Similarity は、既定値を k1=1.2・b=0.75 とし、IDF を log(1 + (N − df + 0.5) / (df + 0.5)) で計算すると公式ドキュメントに書いています（N は文書数、df はその語を含む文書数）。1語ぶんの点は idf × tf × (k1+1) ÷ (tf + k1 × (1 − b + b × 文書長 ÷ 平均文書長)) です。手元でもこの形で書きました。

import numpy as np, scipy.sparse as sp
from collections import Counter

class BM25:
    def __init__(self, docs, k1=1.2, b=0.75):          # docs: 分かち書き済みの語のリスト
        self.vocab, rows, cols, vals, dfc = {}, [], [], [], Counter()
        dl = np.array([len(d) for d in docs], dtype=float)
        for i, d in enumerate(docs):
            c = Counter(d); dfc.update(c.keys())
            for w, tf in c.items():
                j = self.vocab.setdefault(w, len(self.vocab))
                rows.append(i); cols.append(j); vals.append(tf)
        N = len(docs)
        df = np.array([dfc[w] for w in self.vocab])
        idf = np.log(1 + (N - df + 0.5) / (df + 0.5))   # Lucene と同じ形（負にならない）
        tf = np.array(vals, dtype=float); r = np.array(rows)
        w = idf[cols] * tf * (k1 + 1) / (tf + k1 * (1 - b + b * dl[r] / dl.mean()))
        self.W = sp.csc_matrix((w, (rows, cols)), shape=(N, len(self.vocab)))

    def scores(self, q_tokens):                         # 質問の語の列を足すだけ
        js = [self.vocab[t] for t in set(q_tokens) if t in self.vocab]
        return np.asarray(self.W[:, js].sum(axis=1)).ravel() if js else np.zeros(self.W.shape[0])

あらかじめ「語ごと・文書ごとの点」を疎行列に入れておくと、検索は質問の語の列を足すだけになり、3,917節で1問0.1〜0.2msでした。

分かち書きの違い（文字bigram・Sudachi C単位・A単位）

同じ BM25 で、分かち書きだけを変えた結果です。セルは「Recall@10 / MRR@10」です。

文字 bigram は辞書が要らず手軽ですが、全体の MRR@10 が0.516で、Sudachi の0.636より明らかに低くなりました。「の日」「本語」のような意味の無い2文字が大量に一致し、IDF の差が付きにくいためです。分かち書きは Sudachi の normalized_form（正規化形）を使い、助詞・助動詞・記号・空白を落としました。A 単位（短い単位）と C 単位（固有表現をまとめた長い単位）の差は小さく、以降は A 単位を使います。分かち書きにかかった時間は、5,561,447文字で Sudachi が約40秒、bigram が4.2秒でした。

from sudachipy import Dictionary, SplitMode
tok = Dictionary(dict="core").tokenizer()
DROP = ("助詞", "助動詞", "補助記号", "空白")

def sudachi_tokens(text, mode=SplitMode.A):
    out = []
    for m in tok.tokenize(text, mode):                  # 1回に渡せるのは 49,149 バイトまで
        if m.part_of_speech()[0] not in DROP:
            out.append(m.normalized_form())
    return out

print(sudachi_tokens("Webサーバのログを確認する"))
# ['ウェブ', 'サーバー', 'ログ', '確認', '為る']

正規化形は表記の揺れをそろえます。手元では「サーバ」「ｻｰﾊﾞｰ」がどちらも「サーバー」に、「Web」が「ウェブ」になりました。「関西国際空港」は C 単位では1語、A 単位では「関西／国際／空港」の3語です。一方で、英単語の example が「エグザンプル」、select が「セレクト」になるなど、英語がカタカナに変わる語もあります。索引と質問の両方を同じ関数で処理していれば一致しますが、片方だけ別の処理をすると0件になります（よくあるエラーの節）。

k1 と b を変えた結果

Sudachi A 単位で k1 と b を変えた全体の Recall@10 / MRR@10 です。

k1 はほとんど効かず、b（文書の長さでどれだけ割り引くか）を0.3に下げると MRR@10 が0.02上がりました。この評価セットは長い節に正解が多いためと考えられます。ただし差は分かち書きの違い（0.12）よりずっと小さく、BM25 を直すならパラメータより分かち書きが先です。以降は既定値（k1=1.2・b=0.75）で比べます。

ベクトル検索の代わりにLSAで密ベクトルを作る（次元と精度）

この節では、手元で使った密ベクトルの作り方と、その強さが次元でどう変わるかが分かります。

学習済みの埋め込みモデルが使えないため、TF-IDF の行列を SVD で低い次元に縮める LSA（潜在意味解析）で密ベクトルを作りました。LSA は「同じ文書に一緒に出やすい語」を近いベクトルにするので、語が一致しなくても近い話題の文書を拾えます。ただし語の意味を外から学んでいるわけではないため、本物の埋め込みモデルより弱いベクトル検索として読んでください。

import numpy as np
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.decomposition import TruncatedSVD

tv = TfidfVectorizer(analyzer=lambda x: x, sublinear_tf=True, min_df=2)   # 分かち書き済みを渡す
X = tv.fit_transform(docs_tokens)
svd = TruncatedSVD(512, random_state=0)
D = svd.fit_transform(X)
D /= np.linalg.norm(D, axis=1, keepdims=True)          # 正規化して内積＝コサイン類似度

def dense_scores(q_tokens):
    v = svd.transform(tv.transform([q_tokens]))[0]
    return D @ (v / np.linalg.norm(v))

次元を増やすほど強くなりますが、512次元でも全体の MRR@10 は0.433で、BM25（0.636）より低いままです。言い換えの質問に限っても、MRR@10 は LSA 0.345、BM25 0.334 とほぼ同じでした。つまり手元の組み合わせは「BM25 が強く、ベクトル側が弱い」状態です。本物の埋め込みモデルでは、多くの場合言い換えでベクトル側がはっきり強くなり、2つの強さが近づきます。この違いが融合の結果を大きく左右するので、次の節以降では次元を変えて「ベクトル側の強さ」を動かした結果も並べます。以降の基本の比較は512次元です。

RRF（Reciprocal Rank Fusion）とは（式・k=60の意味・kを変えた実測）

この節では、RRF の式と k の意味、k を1〜1000に変えたときの実測が分かります。

RRF は、各検索の結果リストでの順位 r だけを使い、文書ごとに 1/(k + r) を足し合わせた値で並べ直す方法です。Cormack・Clarke・Büttcher の論文「Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods」（SIGIR 2009）で示されました。原論文は k=60 を予備実験で決めて固定し、最適に近いが厳密な値は重要ではなかった、と書いています。k は、上位の文書を重く見つつ、下位の文書の影響が急に消えないようにする定数です。

def rrf(lists, k=60, weights=None):
    """lists: 文書IDの順位リストを複数。weights: リストごとの重み（省略時は全部1）"""
    score = {}
    for li, ranked in enumerate(lists):
        w = 1.0 if weights is None else weights[li]
        for r, doc in enumerate(ranked, start=1):        # 順位は1から数える
            score[doc] = score.get(doc, 0.0) + w / (k + r)
    return sorted(score, key=lambda d: (-score[d], d))  # 同点は ID で決める

前の節の「ダイアログを開いているのに後ろの画面がスクロールしてしまう」で、実際の RRF の点を見ます。正解は BM25 で6位、LSA で1位でした。

両方で上位にいる文書が強くなり、片方で1位でも、もう片方で6位なら3位に落ち着きます。RRF の点は元のスコアを捨てているので、BM25 の点がどれだけ大差でも、ベクトルの類似度がどれだけ高くても、「何位だったか」しか効きません。BM25 の点（上限なし）とコサイン類似度（−1〜1）のように単位が違うスコアでも、そのまま合わせられるのが RRF の利点です。

RRF の k を変えた実測

BM25 と LSA の上位100件ずつを RRF でまとめ、k だけを変えた結果です。

k を小さくすると1位と2位の点の差が大きくなり、「片方だけが1位にした文書」が残りやすくなります。手元では k=1 が最も良く、k≧60 はほぼ同じ値になりました。上位100件の中では、k が60を超えると 1/(k+r) の差が順位にほとんど関係しなくなり、「両方のリストに入っているか」だけでほぼ決まるためです。ただし k=1 でも MRR@10 は BM25 単独（0.636）に届きません。この組み合わせで効くのは k ではなく重みでした。

RRFが順位を下げる場面（片方の検索が弱いときの実測）

この節では、RRF が BM25 単独より悪くなる仕組みと、それが「2つの検索の強さの差」で決まることが分かります。

「core.longpaths とは」の正解は BM25 で1位、LSA では上位100件の圏外でした。RRF の点は 1/61＝0.01639 だけです。一方、BM25 で2位・LSA で2位の文書は 1/62＋1/62＝0.03226 になります。正解より上に57件が並び、その多くは両方のリストにそこそこの順位で入った文書でした。片方のリストだけに入った文書の点は最大でも 1/61 なので、両方に入った文書にはまず勝てません。k=60 では、片方のリストで1位でも、両方のリストで40位なら負けます（1/61＝0.0164 に対して 2/100＝0.0200）。

BM25 と比べて、RRF（k=60）で正解の順位が上がった質問・下がった質問の数です。

2つの検索の強さの差で結果が変わる

ベクトル側の次元を変えて強さを動かし、同じ BM25 と RRF でまとめた結果です。BM25 単独は全体で 0.892 / 0.636 です。

ベクトル側が強くなるほど、RRF の結果は BM25 単独に近づきます。逆向きの例として、BM25 を弱い文字 bigram 版（0.777 / 0.516）に替えて LSA 512次元（0.784 / 0.433）と RRF でまとめると、0.850 / 0.548 になり、どちらの単独よりも上がりました。2つの強さが近いときは RRF が効き、差が大きいときは強い方の足を引っ張る、というのが手元の結果です。原論文の「RRF は個々の最良のシステムを上回ることが多い」という報告も、性能の近い複数のシステムを融合した実験です。

重み付きRRFと線形結合（min-max・z-score）の比較

この節では、RRF に重みを付けた場合と、スコアを正規化して足す線形結合の精度を同じ表で比べ、重みの決め方が分かります。

線形結合は、各検索のスコアを同じ範囲にそろえてから、重み a（ベクトル側）と 1−a（BM25 側）を掛けて足す方法です。そろえ方は、候補の中の最小を0・最大を1にする min-max と、平均0・標準偏差1にする z-score が代表です。片方のリストにしか無い文書は、もう片方の点を0として足しました。

def linear(cands, alpha, norm="minmax"):
    """cands: [(BM25のID列, スコア列), (ベクトルのID列, スコア列)]、alpha: ベクトル側の重み"""
    out = {}
    for i, (ids, s) in enumerate(cands):
        s = np.asarray(s, dtype=float)
        if norm == "minmax":
            z = (s - s.min()) / ((s.max() - s.min()) or 1)
        else:                                            # z-score
            z = (s - s.mean()) / (s.std() or 1)
        w = (1 - alpha) if i == 0 else alpha
        for d, v in zip(ids, z):
            out[d] = out.get(d, 0.0) + w * v
    return sorted(out, key=lambda d: (-out[d], d))

読み取れることは4つです。

• 上位10件の再現率（R@10）では、線形結合 a=0.3 が BM25 単独を上回りました（0.892→0.907）。言い換えは0.700→0.760、見出しは0.855→0.880 です。MRR@10 は少し下がる（0.636→0.619）ので、「正解が上位10件に入るか」を重く見る RAG では線形結合が有力です。
• 重み付き RRF でも、ベクトル側を0.3にすると R@10 は BM25 単独とほぼ同じ（0.890）まで戻りました。重みを2.0にしてベクトル側を重く見ると、すべての種類で悪くなります。
• z-score と min-max の差は小さく、a の選び方の方がずっと効きます。
• 正規化なしの和は BM25 単独とほぼ同じでした。BM25 の点は数〜数十、コサイン類似度は1以下なので、足してもほぼ BM25 の順位のままになります。スコアをそのまま足すと、片方を捨てているのと同じです。

重みは評価セットを分けて決める

同じ評価セットで重みを選んでその評価セットで成績を報告すると、数字がよく見えすぎます。質問を種類ごとに半分に分け、片方（調整用）で最も MRR@10 が高い設定を選び、もう片方（確認用）で測りました。

MRR@10 を基準に選ぶと、ベクトル側の重みは最小の0.1が選ばれ、確認用でも BM25 単独とほぼ同じになりました。手元のベクトル側が弱い以上、これは妥当な結果です。何を基準に選ぶか（R@10 か MRR@10 か）で、選ばれる重みが変わる点にも注意が要ります。

質問の形で重みを振り分ける

識別子やエラー文を含む質問だけ BM25 を重く見る方法も試しました。正規表現（英数字の間に . _ - : / を含む、英字＋数字、Error・failed などを含む）で判定し、当てはまればベクトル側の重みを0.1、そうでなければ0.5にした RRF です。判定は、識別子150問中149問・エラー文150問中131問を拾い、見出し400問中38問・言い換え50問中2問を誤って拾いました。結果は全体で 0.903 / 0.597 で、重みなしの RRF（0.856 / 0.533）より良く、識別子の MRR@10 は0.565から0.727に戻りました。判定を誤ると逆効果になるので、本番の質問ログで判定の当たり外れを数えてから入れる方法です。

上位10件の外まで見る（Recall@50・100とリランクの前段）

この節では、ハイブリッド検索が「上位を並べ替える」のではなく「候補を広く集める」役割で効くことが、Recall@k の実測で分かります。

上位100件で見ると、BM25 単独は0.964、LSA 単独は0.971ですが、RRF と線形結合はどちらも0.988でした。正解の取りこぼしは、BM25 単独の3.6％から1.2％へ3分の1になっています。上位1件の精度では BM25 単独に負けている RRF でも、候補を集める段階としては両方の単独より優れています。

このため、ハイブリッド検索の後ろにリランカー（質問と文書の組を1つずつ採点し直すモデル。クロスエンコーダーなど）を置く構成がよく使われます。融合で上位50〜100件の候補を広く集め、リランカーで上位10件を決め直す形です。手元ではリランカーのモデルを動かせないため、その精度は測っていません。リランカーを置くなら、融合の方式は Recall@50〜100 で選び、置かないなら Recall@10・MRR@10 で選ぶ、と分けて考えると判断がぶれません。

融合の処理そのものは軽く、Python で上位100件ずつの RRF は1問0.05msでした。かかるのは2つの検索を2回走らせる分の時間と、リランカーを置く場合はその時間です。

PostgreSQLで1つのSQLにする（BM25・pgvector・RRF）

この節では、PostgreSQL の中だけでハイブリッド検索を完結させる SQL と、手元で測った精度・応答時間・落とし穴が分かります。

PostgreSQL の標準の全文検索（tsvector と ts_rank・ts_rank_cd）は BM25 ではありません。公式ドキュメントは、ランキング関数が「global information（コーパス全体の情報）を使わない」と書いています。つまり IDF が無く、珍しい語に重みが付きません。日本語の分かち書きの機能もありません。そこで、Python で Sudachi の分かち書きをして、BM25 は「語ごとに文書IDと出現回数の配列を持つ転置インデックス」の表から SQL で計算し、ベクトル側は pgvector の HNSW インデックスで引きました。

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE term (term text PRIMARY KEY, df int, idf float8, secs int[], tfs int[]);
CREATE TABLE sec  (id int PRIMARY KEY, art text, head text, dl int, tsv tsvector, emb vector(512));
CREATE TABLE bm25_meta AS SELECT count(*)::int AS n, avg(dl)::float8 AS avgdl FROM sec;
CREATE INDEX sec_emb_hnsw ON sec USING hnsw (emb vector_cosine_ops);

CREATE OR REPLACE FUNCTION hybrid_search(q_tokens text[], q_emb vector, rrf_k int DEFAULT 60)
RETURNS TABLE (id int, rrf numeric, bm25_rank bigint, vec_rank bigint)
LANGUAGE sql STABLE AS $f$
WITH q AS (
  SELECT DISTINCT unnest(q_tokens) AS t
),
bm25 AS (                       -- BM25（k1=1.2, b=0.75）を転置インデックスの配列から計算
  SELECT p.sec,
         sum(tm.idf * p.tf * (1.2 + 1)
             / (p.tf + 1.2 * (1 - 0.75 + 0.75 * s.dl / m.avgdl))) AS score
  FROM q
  JOIN term tm ON tm.term = q.t
  CROSS JOIN LATERAL unnest(tm.secs, tm.tfs) AS p(sec, tf)
  JOIN sec s ON s.id = p.sec
  CROSS JOIN bm25_meta m
  GROUP BY p.sec
  ORDER BY score DESC
  LIMIT 100
),
bm25_r AS (
  SELECT sec, row_number() OVER (ORDER BY score DESC) AS r FROM bm25
),
vec AS (                        -- HNSW で近い順に100件
  SELECT id AS sec, emb <=> q_emb AS dist
  FROM sec
  ORDER BY emb <=> q_emb
  LIMIT 100
),
vec_r AS (
  SELECT sec, row_number() OVER (ORDER BY dist) AS r FROM vec
)
SELECT coalesce(b.sec, v.sec) AS id,
       coalesce(1.0 / (rrf_k + b.r), 0) + coalesce(1.0 / (rrf_k + v.r), 0) AS rrf,
       b.r AS bm25_rank,
       v.r AS vec_rank
FROM bm25_r b
FULL OUTER JOIN vec_r v ON b.sec = v.sec
ORDER BY rrf DESC, id
LIMIT 10;
$f$;

-- 呼び出し側：分かち書きした語の配列と、質問のベクトルを渡す
SET hnsw.ef_search = 100;
SELECT * FROM hybrid_search(ARRAY['ダイアローグ','開く','後ろ','画面','スクロール'], '[0.0123, ...]'::vector);

ベクトル側だけを重くしたいときは、最後の SELECT の 1.0 を重みに変えます。750問をこの関数で引いた結果です（psql で1問ずつ実行し、\timing の値を集計）。

インデックス無しの厳密な計算では、指標は Python 版（R@10 0.856・MRR@10 0.533）と同じになりました。上位10件が完全一致しない107問は、RRF の点が同点の文書の並び順の違いです（上位11件に同点を含む質問は196問ありました）。同点の並べ方を ORDER BY rrf DESC, id のように決めておかないと、実行のたびに順位が変わることがあります。

hnsw.ef_search が LIMIT より小さいと件数が減る

pgvector の公式ドキュメントは「結果は動的候補リストの大きさ（hnsw.ef_search、既定40）で制限される」と書いています。手元でも、ef_search が既定の40のまま LIMIT 100 で引くと、40件しか返りませんでした。

   setting    | count
--------------+-------
 ef_search=40 |    40
(1 row)

SET
   ?column?    | count
---------------+-------
 ef_search=100 |   100
(1 row)

RRF の候補が40件に減るので、上の表のとおり R@10 が0.850から0.832に下がります。エラーにならず件数が減るだけなので気付きにくい落とし穴です。pgvector 0.8.0 以降には、足りないときに探し続ける反復スキャン（hnsw.iterative_scan）があると公式ドキュメントにありますが、手元の 0.6.0 には無いため試していません。

標準の全文検索（ts_rank_cd）と比べた結果

同じ分かち書きを to_tsvector('simple', …) に入れ、ts_rank_cd で並べた結果です。

plainto_tsquery は公式ドキュメントのとおり語を &（AND）でつなぐため、語の多い質問ほど0件になりやすく、750問中162問で何も返りませんでした。OR でつなぐと0件は無くなりますが、IDF が無いので「する」「方法」のようなよく出る語の一致にも同じだけ点が付き、BM25 よりはるかに低くなります。PostgreSQL で RAG のキーワード側を作るなら、ts_rank 系をそのまま BM25 の代わりにしないのが手元の結論です。BM25 を提供する拡張もありますが、この記事では試していません。日本語の全文検索の拡張（pg_trgm・pg_bigm）の比較は、関連記事「PostgreSQL日本語全文検索｜pg_trgmとpg_bigmの速度比較と選び方」で扱っています。pgvector の導入とインデックスの基本は関連記事「pgvectorの使い方｜PostgreSQLでベクトル検索をコピペで構築」で扱っています。

表の大きさは、term が8,656kB、sec が37MB（tsvector と512次元のベクトルを含む）、GIN インデックスが3,856kB、HNSW インデックスが10MB でした。

製品ごとのハイブリッド検索とRRFの既定値

この節では、主な検索エンジン・ベクトルデータベースで RRF の k や重みがどう決まっているかが、公式ドキュメントで確かめた範囲で分かります（2026年11月4日時点）。

同じ「RRF」でも、Qdrant は k=2・順位を0から数える、Elasticsearch は rank_window_size が既定10、Weaviate はそもそも既定が RRF ではない、など前提が違います。製品を移すと、同じ設定名のまま結果が変わります。手元の表で k=1 と k=60 の差が全体の MRR@10 で0.03あったように、k の違いは数字に出ます。移行や版上げのたびに評価セットで測り直すのが安全です。

よくあるエラー・つまずき（原文つき）

この節では、手元でハイブリッド検索を組んだときに実際に出たエラー・警告と、気付きにくい結果の崩れが、原因と直し方つきで分かります。

ハイブリッド検索の判断表（RAGの検索精度を上げる順番）

この節では、ハイブリッド検索を入れるか、どの融合方式にするかを、手元の結果と公式ドキュメントをもとに判断できます。

入れる前に確かめておきたいことです。

RAG 全体の作り方（チャンク・プロンプト・評価）は関連記事「RAGの作り方｜Pythonで動かす最小構成と精度の上げ方」で扱っています。

よくある質問

この節では、ハイブリッド検索と RRF についてよく聞かれる疑問への答えが分かります。

Q. ハイブリッド検索と RRF は同じものですか。

違います。ハイブリッド検索は複数の検索を組み合わせる構成の名前で、RRF はその結果をまとめる方法の1つです。線形結合や、Qdrant の DBSF のような別のまとめ方もあります。

Q. RRF の k=60 はどこから来た値ですか。

Cormack らの SIGIR 2009 の論文で、予備実験で決めて固定した値です。論文は、最適に近いが厳密な値は重要ではなかったと書いています。Elasticsearch・Milvus・MongoDB の既定も60ですが、Qdrant の既定は2です。

Q. BM25 とベクトル検索の重みはどう決めますか。

評価セットを調整用と確認用に分け、調整用でベクトル側の重みを0.1刻みで変えて選び、確認用で測ります。手元のようにベクトル側が弱いと、小さい重み（0.1〜0.3）が選ばれます。本物の埋め込みモデルなら、もっと大きな重みが選ばれることが多いはずです。

Q. ハイブリッド検索を入れると必ず精度が上がりますか。

上がりません。手元では、重みなしの RRF で MRR@10 が BM25 単独の0.636から0.533に下がりました。上がりやすいのは、2つの検索の強さが近いときと、Recall@50〜100（リランカーに渡す候補の再現率）を見るときです。

Q. ベクトル検索だけで、型番やエラーコードを拾えないのはなぜですか。

埋め込みは意味の近さを表すため、1文字違いの型番や、語として珍しいだけの識別子は区別しにくくなります。手元の LSA でも、識別子の MRR@10 は0.385で BM25 の0.810の半分以下でした。

Q. PostgreSQL の ts_rank を BM25 の代わりに使えますか。

公式ドキュメントのとおり、ts_rank・ts_rank_cd はコーパス全体の情報（IDF）を使いません。手元では OR 検索で MRR@10 0.289、BM25 は0.636 でした。BM25 が要るなら、この記事のように SQL で計算するか、BM25 を提供する拡張を検討します。

Q. 埋め込み（エンベディング）の仕組みから知りたいときは。

ベクトルとコサイン類似度の計算は関連記事「エンベディングとは？ベクトル検索とコサイン類似度を計算例で解説」で扱っています。

Q. RAG の回答全体の良し悪しはどう測りますか。

この記事は検索部分だけを測りました。回答の忠実さなどを含めた評価の枠組みは関連記事「RagasでRAGを評価する｜指標の意味とPythonコード」で扱っています。

まとめ

この節では、記事全体の要点が分かります。

1. ハイブリッド検索は BM25 とベクトル検索の結果をまとめる構成で、RRF はまとめ方の1つ。BM25 は型番・エラー文に、ベクトル検索は言い換えに強く、上位10件の重なりは平均6.1件だった。
2. 日本語の BM25 は分かち書きで決まる。Sudachi の A 単位で MRR@10 0.636、文字 bigram で0.516。k1・b の調整より差が大きい。
3. RRF は片方が弱いと強い方の足を引っ張る。BM25 で1位の正解が58位まで落ちる例があり、重みなしの RRF で MRR@10 は0.533に下がった。2つの強さが近いときは両方を上回った。
4. 効くのは k より重み。ベクトル側を0.3にした RRF や、正規化つきの線形結合（a=0.3で R@10 0.907）が手元では良く、重みは調整用と確認用に分けて決める。
5. 候補集めとしては融合が強い。Recall@100 は単独0.964・0.971に対して融合0.988。PostgreSQL では BM25・pgvector・RRF を1つの関数にでき、hnsw.ef_search を LIMIT 以上にする。

参考・出典

この節では、この記事で根拠にした論文・公式ドキュメントが分かります（確認日 2026年11月4日）。

• G. V. Cormack, C. L. A. Clarke, S. Büttcher「Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods」SIGIR 2009：https://cormack.uwaterloo.ca/cormacksigir09-rrf.pdf
• Apache Lucene「BM25Similarity」：https://lucene.apache.org/core/9_12_0/core/org/apache/lucene/search/similarities/BM25Similarity.html
• PostgreSQL 16 文書「Controlling Text Search」（ts_rank・ts_rank_cd・plainto_tsquery）：https://www.postgresql.org/docs/16/textsearch-controls.html
• pgvector README（hnsw.ef_search・iterative scan・Hybrid Search）：https://github.com/pgvector/pgvector
• Sudachi（sudachi.rs）README（分割単位 A・B・C、正規化形、辞書の種類）：https://github.com/WorksApplications/sudachi.rs
• Elasticsearch「RRF retriever」：https://www.elastic.co/docs/reference/elasticsearch/rest-apis/retrievers/rrf-retriever
• Microsoft Learn「ハイブリッド検索のスコアリング (RRF) - Azure AI Search」：https://learn.microsoft.com/ja-jp/azure/search/hybrid-search-ranking
• Qdrant「Hybrid and Multi-Stage Queries」：https://qdrant.tech/documentation/concepts/hybrid-queries/
• Weaviate「Hybrid search」：https://docs.weaviate.io/weaviate/search/hybrid
• Milvus「RRF Ranker」：https://milvus.io/docs/rrf-ranker.md
• MongoDB「$rankFusion (aggregation stage)」：https://www.mongodb.com/docs/manual/reference/operator/aggregation/rankfusion/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。