なぜ二段検索にリランカーが効くのか / bi-encoder の表現力と「非加法的な好み」を実験で確かめる

はじめに

こんにちは。データサイエンティストの浦山です。

情報検索や推薦システムでは、まず軽量なモデルで候補を絞り、その上位を別のモデルで並べ替える「二段階構成」が広く使われています。とりあえずリランカーを足せば精度が上がる、という肌感を持っている方も多いと思います。

ただ、これはいつでも成り立つわけではありません。リランカーがよく効く場面もあれば、ほとんど無意味、あるいは逆効果になる場面もあります。

本記事では、「リランカーはどんなときに効くのか」を、埋め込みモデル（bi-encoder）の表現力の限界 という観点から整理し、非加法性を意図的に作り込んだ合成データ を使った実験で確かめます。結論を先に言えば、効き目を分けるのは「関連性に交互作用があるかどうか」です。

精度評価結果

補足：題材は text→image（テキストで画像を検索）ですが、これから述べる話はモダリティに依存しません。テキスト同士の検索でも同じ理屈が成り立ちます。

---

課題：「とりあえずリランカー」は本当に効くのか

二段階検索（リトリーバー→リランカー）はもはや定石です。リトリーバーが大量の候補から数十〜数百件に絞り、リランカーがその候補を精密に並べ替える。クエリとアイテムを個別にベクトル化して内積で測るリトリーバーは高速ですが精度は粗く、そのぶんを後段のリランカーで補う、という分担です。

しかし実務では、「リランカーを足したのに、ほとんど効果がない」「むしろ少し悪くなった」という経験をすることがあります。リランカーは万能ではなく、効くかどうかには 条件 があります。

本記事のゴールは、その条件を一つ、はっきりと示すことです。鍵になるのは「関連性が、属性の 足し算 で書けるか、それとも交互作用を含むか」という違いです。

二段階検索の全体像

前提：二段階検索と二つのモデル

本論に入る前に、登場する道具を整理します。

Note: bi-encoder と cross-encoder

• bi-encoder（Two Tower 型）：クエリとアイテムを 別々に ベクトル化し、その内積（やコサイン類似度）で関連度を測ります。アイテム側のベクトルは事前計算でき、近似最近傍探索（ANN）で高速に検索できるため、リトリーバー（候補の絞り込み） に向きます。今回の実験では、クエリとアイテムに同じ重みの同じアーキテクチャの埋め込みモデルを利用します。
• cross-encoder：クエリとアイテムを 1 つの入力として一緒に モデルへ通し、関連スコアを 1 つ出力します。表現力は高い一方、クエリごとに候補を 1 件ずつ通す必要があり重いので、リランカー（少数候補の精密なスコアリング） に向きます。

Note: NDCG / MRR / Recall@k

検索の良し悪しを測る代表的な指標です。いずれも 0〜1 で、高いほど良い指標です。

• Recall@k：上位 k 件の中に、正解がどれだけ含まれるか（網羅性）。
• MRR（Mean Reciprocal Rank）：最初の正解が何位に出たか（その順位の逆数の平均）。上位に正解を出せるほど高くなります。
• NDCG@k（normalized DCG）：正解を上位に並べられたかを、順位の重みつきで評価したもの。1 に近いほど理想的な並び。

二段階構成の役割分担ですが、リランカーは並び替えを「目的」とするモデルですが、リランカーモデル自身がやっているのはスコアリングだけ です。(query, item) のペアごとに関連スコアを返し、そのスコアで上位 k 件を降順ソートします。Recall@k（正解をどれだけ拾えたか）は リトリーバー（候補集合）が決め、リランカーは候補集合内の順位しか動かせません。 つまりリランカーが動かせるのは並びの質（NDCG / MRR）であって、候補に入っていない正解は何をしても拾えません。

では、同じ候補を並べ替えるだけなのに、なぜ 別の種類のモデル を後段に置くと精度が上がるのでしょうか。

核心：ドット積に表現できないもの

答えは、それぞれのモデルが「関連性をどうスコアリングできるか」という 表現力 の違いにあります。この章では、その違いを「好み」という具体例で掘り下げます。

足し算で説明できない「好み」

あるユーザーが画像の好みを持っているとします。話を単純にするため、画像の属性を「暖色か（warm）」「装飾過多か（ornate）」の 2 つだけで考えます。

このユーザーは、

• 暖色は 好き
• 装飾過多も 好き

だとしましょう。素直に考えれば「暖色 × 装飾過多」の画像はもっと好きなはずです。ところが実際の好みはこうでした。

暖色	装飾過多	このユーザーの評価
✕	✕	興味なし
◯	✕	好き
✕	◯	好き
◯	◯	苦手

「どちらか一方なら好きだが、両方そろうと急に苦手」。それぞれの属性の良し悪しが、もう一方の属性によってひっくり返っています（ちなみに「どちらか一方だけ」を良しとするこのパターンは、論理演算の XOR と同じ形です）。この、単独の効果の足し算では説明できない現象を 交互作用（interaction） と呼びます。

Note: 交互作用（interaction）とは？

複数の要因が組み合わさったときの効果が、単独の効果の 足し算では説明できない 現象を指します。「薬 A は安全、薬 B も安全、でも併用すると危険」というのも交互作用の一種です。

上の例でいえば、暖色の効果（＋）と装飾過多の効果（＋）を足しても「両方そろうと苦手（−）」は出てきません。一方の良し悪しが、もう一方の値によって変わる。これが交互作用です。

数式で見ると、加法的なモデル score = a・暖色 + b・装飾 には組み合わせを表す項がありません。交互作用を入れるには + c・(暖色 × 装飾) という 積の項 が要ります。この積の項を スコアリング時に作れるかどうか が、このあとリトリーバーとリランカーを分けます。

二つのモデルは「好み」をどうスコアリングするか

リトリーバー（bi-encoder）と リランカー（cross-encoder）は、関連スコアの 作り方 が根本的に違います。

bi-encoder は、クエリとアイテムを 別々に ベクトル化し、最後に内積を取ります。

ここで と はそれぞれ独立したエンコーダで、クエリとアイテムは 最後の内積でしか出会いません。クエリを固定すると、スコアはアイテムベクトルの各成分の 重み付き和、つまり次元ごとの足し算になります。

cross-encoder は、クエリとアイテムを 一緒に 読み込み、attention で相互作用させてからスコアを出します。

はペアを丸ごと受け取る関数なので、入力の 組み合わせ に依存した特徴を、しかもクエリに応じて計算できます。

bi-encoder と cross-encoder のスコアリングの違い

内積が作れないもの

ここが核心です。bi-encoder のスコアを成分で書くと、

これは「クエリ成分 × アイテム成分」を足し合わせた形で、アイテムの 2 つの特徴（暖色と装飾過多）をスコアリング時に掛け合わせる項がありません。

先ほどの好みを思い出すと、加法的なスコア a・暖色 + b・装飾 では、

• 暖色を好きにする（a > 0）
• 装飾過多を好きにする（b > 0）

までは設定できます。しかしそうすると、どうしても「暖色 × 装飾過多」が 最も高評価（a + b） になってしまい、「両方そろうと苦手」は表現できません。これを表すには + c・(暖色 × 装飾)（c < 0）という積の項が必須で、それは足し算だけでは作れないのです。

一方 cross-encoder は、この積の項に相当する特徴を attention でその場で作れます。だから非加法的な好みを表現できる。「並べ替えるか否か」ではなく「スコアリング時に交互作用を作れるか否か」 が、二つのモデルの本質的な差です。

厳密には

これは スコアリングの形 の話です。画像エンコーダ が十分に強ければ、「暖色かつ装飾過多」という特徴をあらかじめ 1 次元に畳み込んでおくこともでき、その意味で「内積では交互作用を絶対に表現できない」わけではありません。

ただし bi-encoder は、どんなクエリが来るか分からないまま すべての 交互作用を固定長ベクトルに先に詰め込んでおく必要があるのに対し、cross-encoder は必要な交互作用をクエリ条件付きで その場で 計算できます。つまり bi-encoder は構造的に不利、というのが正確な言い方で、それが実際にどれだけ効くかは後の実験で確かめます。

だから二段階構成に意味が出る

整理すると、

• リトリーバー（bi-encoder） は加法的なスコアリングしかできない。関連性が非加法的だと、本来上位に来るべきアイテムを正しく上げられず、ランキングに限界が出る。
• リランカー（cross-encoder） は交互作用を表現できる。候補集合の中であれば、その限界を埋めて並べ替え直せる。

ここから一つの予測が立ちます。リランカーが効くのは、関連性に非加法的な構造があるときであって、関連性が素直に加法的なら、後段のリランカーはほとんど仕事がない はずです。

では、これは本当に成り立つのか。次章では、この「非加法性」を 意図的に・強さを変えながら 作り込んだ合成データを用意し、実験で確かめていきます。

検証の設計：合成データで非加法性を操作する

予測をきれいに確かめるには、非加法性の強さを自分で変えられるデータ が要ります。

ところが、自然言語や画像のような実データでは、これができません。交互作用は生のピクセルやトークンではなく 潜在的な意味 の側にあり、しかもその強さを測る物差しも、外から動かすツマミもないからです。そこで本記事では、非加法性を意図的に・強さを変えながら作り込める合成データ を用意します。

合成データの作り方

データ生成の流れはこうです。

1. 各ペルソナは、7 つの「好みの軸」に対する好みを持ちます（暖かみ / 年代感 / 装飾性 / 雰囲気 / 彩度 / 素材感 / 背景）。前章の「暖色」「装飾過多」も、このうちの 2 軸（暖かみ・装飾性）にあたります。
2. あるペルソナの好み分布から属性をサンプリングし、その属性を反映した画像を FLUX.2-klein-4B で生成します。このとき被写体（猫、机、など）は属性とは独立にランダムへ選ぶので、見た目は多様になる一方、味付けは一貫します。
3. 出来た画像を、その属性を最も好むペルソナ でラベル付けします。これが「正解の検索クエリ」になります。

3 番目が少しトリッキーです。ステップ 1 のサンプリングは各軸の好みに基づくもので、交互作用はここでは考慮していません。交互作用が効くのはステップ 3 のラベル付けのときだけです。だからこそ「あるペルソナが生成した属性の組み合わせを、実は別のペルソナの方が好む」というズレが生じます。つまりラベルは「誰がこの画像を最も好むか」を計算から決めており、人手のアノテーションは一切不要 です。

データ生成のフロー

生成された合成データの例（AI生成画像）

なぜクエリを「意味のないトークン」にするのか

各ペルソナのクエリは user_alpha、user_beta … という、それ自体には意味のないトークンにしています。

もしクエリが「暖かくてレトロな写真が好きな人」のような 意味を持つ文 だと、事前学習済みモデルは語彙のマッチングだけである程度解けてしまい、「非加法的な好みを 学習できたか」を測れません。意味のないトークンにすることで、ペルソナと好みの対応づけを fine-tune で 新しく覚える しかなくなり、学習の効果だけを切り出せます。

裏を返せば、これは現実とは違う簡略化でもあります（実際の検索クエリは意味を持ちます）。今回は「アーキテクチャが非加法的な関連性を学べるか」という変数を切り分けるための、意図的な単純化だと考えてください。

非加法性の「ツマミ」: gamma

各ペルソナの嗜好（appeal）は、おおまかに「各属性の好みの和（主効果）」＋「属性同士の交互作用」で決まり、後者の効き具合を gamma というパラメータで調整します。模式的に書くと、

• gamma = 0：交互作用が消え、純粋に加法的（＝主効果の和だけ）になります。関連性が加法的なら、加法的なスコアリングしかできないリトリーバーでも十分に表現できる はず です。
• gamma を上げる：「暖色 ∧ 装飾過多 は苦手」のような交互作用が効き始め、非加法的になります。
• gamma = 2.0（本実験の既定値）：交互作用が十分に強く、「最も好むペルソナ（argmax appeal）」が、単純な主効果の和から予測されるペルソナと食い違うことがあります。

この「ツマミ」があるおかげで、後段のリランカーの効き目を 「非加法性の強さ」に紐づけて読む ことができます。gamma を 0 にした条件と 2.0 にした条件を比べれば、リランカーの貢献が 非加法性のせいなのかどうか を切り分けられる、という建付けです。

評価セットと、指標の読み方

評価セットは、コーパス 200 枚・クエリ 200 件（7 ペルソナ）です。各クエリの正解は「そのペルソナが argmax appeal となる画像すべて」で、ペルソナあたり 10〜59 枚、平均およそ 29 枚あります。

1 クエリに正解が平均 29 枚もある ため、たとえ完璧に並べても Recall@1 のような「上位 1 件」系の指標は構造的に低く出る、という点です（top-1 に正解を 1 枚置いても、残りの 28 枚は拾えない）。そこで本記事では、絶対値の大小ではなく、

• Acc@k：上位 k 件に正解が 1 枚でも含まれるか（ヒット率）
• NDCG / MRR：正解をどれだけ上位に持ち上げられたか（並びの質）

を中心に読みます。

使用モデルは、リトリーバーが Qwen3-VL-Embedding-2B、リランカーが Qwen3-VL-Reranker-2B、画像生成が FLUX.2-klein-4B（いずれも Apache-2.0）。リトリーバーは、Two-Tower Model と似ていますが、二つのタワーで重みを共有するイメージで学習させます。学習はそれぞれ 1 epoch です。なお、嗜好の中身や、属性からプロンプトを組み立てる仕組みといったデータ生成の細部は、次回の記事でじっくり扱います。本章では「非加法性を、強さを変えながら作り込める」という設計の勘所だけ押さえておきます。

結果1：埋め込み単体（base vs fine-tuned）

まずリトリーバー単体、つまり埋め込みモデルを fine-tune する前後で、検索の質がどう変わるかを見ます。

モデル	Acc@1	Acc@10	NDCG@10	MRR@10	MAP@100	Recall@10
Base（Qwen3-VL-Embedding-2B）	0.190	0.765	0.133	0.273	0.106	0.035
Fine-tuned	0.530	1.000	0.647	0.703	0.492	0.208

※ Acc@k = 上位 k 件に正解が含まれるクエリの割合

Base の Acc@1 は 0.19 で、7 ペルソナをランダムに当てる水準（≒ 0.143）とほぼ変わりません。 クエリが意味のないトークン（user_alpha）であるため、事前学習済みモデルにはペルソナの好みを知る手がかりがなく、「この課題は fine-tune なしには解けない」、という設計どおりの結果です。fine-tune 後は NDCG@10 が 0.133 → 0.647 へと大きく改善し、ペルソナと好みの対応づけを学習できたことがわかります。

それでも fine-tune 後の埋め込みは 天井には届いていません（NDCG@10 = 0.647）。これは重要で、前章の理論を思い出すと、関連性が非加法的なら加法的なスコアリングしかできない bi-encoder には限界があるはずでした。実際、別途用意した「素直に加法的なタスク」では埋め込み単体で NDCG@10 ≒ 0.985 とほぼ天井に達します。非加法的なタスクでだけ埋め込みが伸び切らず、後段のリランカーに伸びしろが残る あたりに着目して結果を見てみます。

fine-tune 前後の検索結果の例（AI生成画像）

結果2：二段で並べ替える（リトリーバー × リランカー）

リトリーバーの上位をリランカーで並べ替えます。リランカーは候補集合の中だけを動かすので Recall は変わりません。動くのは並びの質（NDCG / MRR）です。

リトリーバー {base, fine-tuned} ×リランカー{base, fine-tuned, なし} の 6 通りすべてを比較します。

リトリーバー	リランカー	NDCG@1	NDCG@5	NDCG@10	MRR	Recall@10
Base	なし	0.190	0.089	0.122	0.273	0.030
Base	Base	0.000	0.052	0.094	0.131	0.030
Base	Fine-tuned	0.000	0.108	0.106	0.167	0.030
Fine-tuned	なし	0.530	0.644	0.646	0.703	0.208
Fine-tuned	Base	0.760	0.639	0.654	0.820	0.208
Fine-tuned	Fine-tuned	0.790	0.696	0.680	0.860	0.208

ここで二段階構成が 効きます。fine-tune した埋め込みの上に fine-tune したリランカーを載せると、MRR は 0.703 → 0.860（+0.157）、NDCG@1 は 0.530 → 0.790（+0.26） へと上がります。前章の予測どおり、リランカーが交互作用を表現して、埋め込み単体では持ち上げきれなかった正解を上位へ動かしています。

一方で、表の上 3 行が示すように、壊れた リトリーバー（base 埋め込み）の上ではリランカーは役に立ちません。 候補集合そのものに正解が十分入っていなければ、いくら精密にスコアリングし直しても拾えるものがないからです。リランカーは「まともな候補集合」を前提にしてはじめて働きます。

考察：リランカーが効く/効かない条件

ここまでの結果を、最初の予測に照らして整理します。

効き目は非加法性から来ている。 「リランカーが勝ったのは、ただモデルが大きい（パラメータや計算量が多い）からでは？」という疑問は当然です。これに答えるのが gamma です。非加法性を消した条件（gamma = 0、＝素直に加法的なタスク）では、同じリランカーを載せても MRR はほとんど動きません（ΔMRR ≒ −0.005、むしろ僅かに悪化）。今回の実験においては 非加法性がある場合にはリランカーの恩恵が得られました。ただし、一般的にリランカーの伸びしろが非加法性のみに依存するとは言い切れません。モデルの表現力やタスクの複雑さ等、その他の要因も考慮する必要はあります。

ただし、コストは無視できない。 リランカー（cross-encoder）は、クエリごとに候補を 1 件ずつ通してスコアリングする必要があり、計算量は候補数 k に比例します。一方 リトリーバー（bi-encoder）はアイテムのベクトルを事前計算でき、ANN で高速に検索できます。つまり、たとえ精度が上がっても、二段目には相応のレイテンシ・計算コストがかかります。「非加法的な構造があり、かつスコアリングコストを払えるとき」 がリランカーの出しどころ、というのが実務的な結論です。

合成データの結果を一般化しすぎない。 本実験は「意図的に作り込んだ非加法性」の上での話です。あなたのタスクの関連性が同じくらい非加法的とは限りません。ここで示したのは「+0.157 の MRR 改善が常に得られる」ことではなく、「リランカーが効く 条件」と、その条件を見極める考え方 です。

では自分のタスクが非加法的かどうか、どう見極めればよいか。自然言語や画像のように属性が直接観測できないデータでは、検定で交互作用を調べることは難しく、「加法的なモデル（例：bi-encoder や線形モデル）と、交互作用を表せるモデル（例：cross-encoder や勾配ブースティング）の性能差を比べる」 のが現実的です。差が大きいほど、非加法的な構造が効いている可能性が高いと推定するというのが、本記事で見てきた内容です。

おわりに

「リランカーを足せば精度が上がる」は、半分正しく半分間違いです。今回の実験の設定では、関連性に交互作用（非加法的な構造）があるときには、リランカーの恩恵が得られます。これは、bi-encoder の内積ではスコアリング時に作れない「特徴同士の掛け合わせ」を、cross-encoder が表現できるからと考えられます。逆に関連性が素直に加法的なら、リランカーはほとんど仕事をしませんでした。本記事では、非加法性を強さを変えながら作り込んだ合成データで、この条件を実験的に確かめました。

次回は、今回さらっと流した 「どうやって 非加法的で・学習可能な ベンチマークを設計したのか」 という好みのモデル化、属性からのプロンプト合成、嗜好によるラベル付けを掘り下げます。

最後までお読みいただきありがとうございました！

出典

アクセス日時：2026/06/22

Qwen/Qwen3-VL-Embedding-2B huggingface.co

Qwen/Qwen3-VL-Reranker-2B huggingface.co

black-forest-labs/FLUX.2-klein-4B huggingface.co

浦山 昌生 Masao Urayama

データ･AIソリューション本部 AIプロダクト統括部 AIプロダクトソリューション部 シニアデータアナリスト

AI ベンダーでデータサイエンティスト兼PL（プロジェクトリーダー）として機械学習モデルの開発やデータ分析の受託業務に従事。それまでは、ネットワークエンジニア、情報セキュリティエンジニアとして顧客の課題解決に対応。2021年10月にパーソルキャリアに入社し、推薦モデルの開発、情報検索システムの開発等、先進的なデータの活用を実践。

※2026年6月現在の情報です。