リランカーの深度を高くすると、候補のスコアリング数にほぼ比例してプライベート検索のレイテンシが増加しますが、バッチ処理、シーケンス長、モデルアーキテクチャ、ハードウェアによって、その曲線は非線形になります。
第1段階のリトリーバーは、クロスエンコーダーやローカルLLMが並べ替える前に、20、100、または500個の候補チャンクを返すことがあります。リランキングを深くすると、初期順位が低い関連パッセージにも残る機会が増えますが、候補が1つ増えるたびにトークン化と推論の処理が発生します。関連文書の再現率が頭打ちになった後は、深度を追加しても主に計算リソースを消費し、インタラクティブなクエリの処理時間の遅い側を長引かせるだけです。
深度とは第2段階に入る候補数
リランカーの深度は、最終的なtop-kとは異なります。パイプラインが100個の候補をスコアリングして5個を返す場合、レイテンシを左右するのは100回のクエリと文書の比較であり、言語モデルが見るのは数個だけです。候補テキストの長さによって、比較ごとに処理するトークン数が決まります。
Elasticのリランキング深度実験では、リランキングの深度を変えた際の検索品質を測定し、モデルごとの指針を示しています。結果から、適切な深度は1つの固定値ではなく、第1段階のリトリーバーとリランカーに依存することがわかります。この影響は、想定するホームサーバーのワークロードでも測定可能な状態にしておく必要があります。
第1段階が弱い場合は、回答を候補に含めるためにより深い深度が必要になることがあります。一方、強力なハイブリッドリトリーバーなら、早い段階で良い候補を提示できます。そのため、リランカーの深度では、そもそも取得されなかった候補を補うことはできません。この違いは、複数のパイプライン段階が同じストレージとメモリの予算を共有する場合に重要です。
推論コストは候補数と候補のトークン数に応じて増加する
クロスエンコーダーはクエリと各候補を同時に処理するため、バッチ処理の影響を除けば、深度を2倍にするとスコアリングするペアもおよそ2倍になります。大きなバッチではアクセラレーターの使用効率を高められますが、必要なメモリも増え、バッチが完了するまで最初の結果の返却が遅れる場合があります。
ペアワイズリランキングに関する研究では、リランキング対象の集合を制限し、小型のモデルを選び、精度を下げ、出力処理を制御することで、大幅なレイテンシ削減が得られると報告されています。これは、深度が複数ある配信設定のうちの1つにすぎないことを示しています。この境界は、想定する値を決めつけず、代表的な家庭内データで検証する必要があります。
CPUでのリランキングでは、ほぼ線形の曲線になることがあります。一方、GPUでは、効率の良いプラトーの後に、メモリ不足やキュー待ちによる急激な悪化が発生する場合があります。候補の長さにばらつきがあると、長いチャンクがバッチ処理の大部分を占めるため、テールレイテンシも増加します。この影響は、想定するホームサーバーのワークロードでも測定可能な状態にしておく必要があります。
品質向上はコストより先に頭打ちになる
深度を増やすことで効果が得られるのは、現在のカットオフより下に関連する証拠が存在し、リランカーがそれを特定できる間だけです。第1段階の再現率が飽和した後は、候補を増やしてもノイズとコストが増えるだけで、曖昧なクエリではランキングの安定性が低下することさえあります。
管理されたエンドツーエンド評価では、効果、生成品質、コスト、レイテンシを用いて、リトリーバーとリランカーの構成を比較しています。これは、ランキングスコアだけを個別に最適化するのではなく、エンドツーエンドのフロンティアから深度を選ぶことを支持します。この違いは、複数のパイプライン段階が同じストレージとメモリの予算を共有する場合に重要です。
失敗につながるのは、ウォーム状態で均一なクエリを処理した平均レイテンシだけを基準に深度を決めることです。モデルのコールドスタート、長いチャンク、同時利用者、NASからの読み出しによって、平均的な関連性がわずかに向上していても、p95やp99は中央値を大きく上回ることがあります。
リランカーの候補深度に関するFAQ
100個の候補をリランキングすると、50個の場合の2倍遅くなりますか?
スコアリング処理はおよそ2倍になる可能性がありますが、実際の処理時間は、バッチの使用効率、トークン長、メモリ制限、キュー待ちによって短くも長くもなります。完全に線形な比率を仮定せず、導入するモデルを測定してください。
最終的なtop-kを大きくするには、リランカーの深度も増やす必要がありますか?
通常、候補プールは最終結果の件数より大きくする必要がありますが、必要な倍率は第1段階の再現率と結果の多様性によって異なります。返すパッセージを増やしたからといって、質の低い候補を数百件スコアリングする理由が自動的に生じるわけではありません。この境界は、想定する値を決めつけず、代表的な家庭内データで検証する必要があります。
リランカーのスコアをキャッシュするとレイテンシを削減できますか?
キャッシュは、同じクエリと候補の組み合わせや、正規化後も安定したクエリに有効です。しかし、プライベート検索では独自の表現や変化する文書が含まれることが多くあります。古い順位を使わないように、キャッシュの無効化は文書のバージョンとモデルの変更に従う必要があります。この影響は、想定するホームサーバーのワークロードでも測定可能な状態にしておく必要があります。
品質が頭打ちになる最小の深度を見つける
正確な用語、言い換え、曖昧な名称、難しいネガティブ例を含むラベル付きクエリセットを作成します。10、25、50、100、200などのリランカー深度を順に試し、第1段階の再現率、最終的なnDCGまたはMRR、引用の網羅率、CPUまたはGPU時間、メモリ、p50、p95、p99のレイテンシを測定します。
リランカーの判断要因にある決定要因と曲線を比較します。深度だけを変更する変数にするため、第1段階の候補生成、チャンク長、リランカーモデル、最終top-k、同時実行数、キャッシュ状態を一定に保ちます。この違いは、複数のパイプライン段階が同じストレージとメモリの予算を共有する場合に重要です。
品質が頭打ちになった状態と統計的に区別できず、かつテールレイテンシがインタラクティブ処理の目標を満たす最小の深度を選択します。追加の再現率に測定可能な価値がある場合に限り、バックグラウンド調査をより深いプロファイルへ振り分けます。この境界は、想定する値を決めつけず、代表的な家庭内データで検証する必要があります。
テック&AIハブ
もっと読む

ローカルLLMはプロセスの再起動後に生成を再開できますか?
LLM生成の再開についてのメカニズム優先の説明、共有リソースにおけるトレードオフ、クエリ・ファンアウトに関する3つのFAQ、そして実践的な検証プロトコル。

ホームサーバーは同じ内蔵GPUで埋め込み生成と動画トランスコードを実行できますか?
共有 iGPU の埋め込みとトランスコーディングについて、仕組みを第一に説明し、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、実践的な検証方法を紹介します。

アクセストークンの有効期間はセキュリティと家庭内の手間にどのような影響を与えるか?
アクセストークンの有効期間について、仕組みを重視した説明、共有リソースのトレードオフ、クエリファンアウトに関する3つのよくある質問、そして実践的な検証手順。

