Token Pooling-Aware Training：検索品質を保ちながら多ベクトル索引を圧縮する
多ベクトル検索の表現力と、索引サイズのトレードオフ
単一ベクトル埋め込みが文書全体を1本のベクトルに圧縮するのに対し、多ベクトルモデルは文脈化されたトークンベクトル群を保持する。これにより、クエリの異なる語が文書の別々の箇所にある根拠と対応できる。MaxSimでは、各クエリベクトルについて最も類似する文書ベクトルとの内積を求め、その値をクエリ側で合計する。
[ \operatorname{MaxSim}(Q,D)=\sum_{q\in Q}\max_{d\in D}q^\top d ]
表現力の代償は、文書ごとに多数のベクトルを保存することだ。記事の例では、128次元の文書ベクトルを200個、残差量子化後の各座標4ビットで保存すると、1文書あたり12.8 KB、100万文書で12.8 GBの量子化残差が必要になる。文書あたり50ベクトルまで減らせば、同じ次元数・精度で3.2 GBとなる。
そこで使うのが、類似するトークンベクトルをまとめるtoken poolingである。ただし、推論時に単純に統合すると、検索に必要な区別まで失う可能性がある。記事の中心的な提案は、圧縮後の表現でも検索に必要な情報が残るよう、学習目的そのものにpoolingを組み込むことだ。
Ward階層クラスタリングと圧縮予算の設計
Sentence TransformersのHierarchicalTokenPoolingは、Ward階層クラスタリングでトークンベクトルを段階的に統合する。各ステップでは、クラスタ内のばらつき、すなわち各ベクトルとクラスタ平均との二乗距離の総和が最も小さく増加する2クラスタを結合する。この基準は、互いに近いベクトルをコンパクトなグループにまとめる方向に働く。各グループは平均ベクトルで表し、MaxSimに使う前に再正規化する。
圧縮率は用途に応じて指定できる。pool_factor=4は元の約4分の1のベクトル数を維持し、文書が長いほど保持数も増える。max_tokens=16は保護対象を含めて文書あたり最大16ベクトルとする固定上限である。一方、distance_thresholdは共通のWard距離しきい値を使うため、文書の埋め込み形状に応じて保持数が変わる。文書長に比例させたい場合と、内容の多様性に応じて容量を配分したい場合とで、制御方法を選び分けられる。
適応的poolingでは、代表的な文書群の埋め込みを使い、目標平均ベクトル数に合う距離しきい値を校正できる。ただし目標値は平均であり、個々の文書のベクトル数を固定するものではない。また、校正に使ったコーパスと別のコーパスでは、達成される平均数が変わる可能性がある。既定では先頭トークンを統合対象から保護し、poolingは文書埋め込みだけに適用される。クエリ埋め込みは圧縮しない。
圧縮後の検索を学習し、評価で予算との交換条件を測る
Pooling-aware trainingでは、同じエンコーダに対して、通常表現とpooling後の表現の両方で検索損失を計算する。記事の実験では、元の埋め込みによる損失と、約4分の1に圧縮した埋め込みによる損失を等しい重みで平均する。
[ \mathcal{L} =\tfrac{1}{2}\mathcal{L}{\mathrm{unpooled}} +\tfrac{1}{2}\mathcal{L}{\mathrm{pooled}} ]
通常の損失は非圧縮時の検索性能を学習させ、圧縮後の損失は、ベクトルを統合しても有用な一致が残るようトークン表現の配置を促す。Wardクラスタリングの割り当ては離散的であるため、クラスタ決定そのものを微分するのではなく、straight-through estimatorを使ってpooling後の勾配をメンバーのトークンベクトルへ伝える。
実装では、MultiVectorTokenPoolingLossが既存の多ベクトル検索損失をpoolerごとに適用する。例では、CachedMultiVectorMultipleNegativesRankingLossを基礎損失にし、非圧縮版とpool_factor=4版を重み0.5ずつで組み合わせる。各pooling variantはエンコーダのトークン埋め込みを再利用するため、poolerを追加してもそのvariantごとにエンコーダを再実行する必要はない。一方、クラスタリングと類似度計算の追加コストは発生する。勾配キャッシュにより、ミニバッチ64で処理しながら学習バッチサイズ256のin-batch negativesを利用した例も示されている。
評価では、同じ初期化・最適化設定で、MS MARCOの120,000 tripletsを1 epoch学習し、seed 42で比較している。違いは損失だけで、ハイパーパラメータ探索は行っていない。NanoBEIR@13の平均nDCG@10では、pool_factor=4で通常学習モデルが49.03、pooling-awareモデルが51.23となった。後者は非圧縮時の51.84に対して97.8%を維持し、文書ベクトル数を74.8%削減する。通常学習モデルの同条件での維持率は94.6%だった。非圧縮時の値も、通常学習の51.84に対してpooling-aware学習は52.39である。
改善は学習時と異なる圧縮設定にも及んだ。平均29.58ベクトルとなる適応的poolingでは、pooling-awareモデルは自身の非圧縮スコアの97.3%を維持し、通常学習モデルの93.3%を上回った。固定上限4ベクトルでは改善幅が5.78ポイントとなり、圧縮が強い領域ほど学習方法の差が大きくなる結果も報告されている。ただし、これらは特定の学習設定と評価群で得られた数値であり、別のコーパスや検索エンジンでも同等の品質になることを保証するものではない。
開発者・エンジニア視点での考察
-
評価はベクトル予算を揃えて行う。 非圧縮時のnDCGだけでは、本番索引に必要な容量を反映できない。
pool_factor、max_tokens、適応的しきい値ごとに、平均ベクトル数・索引サイズ・検索品質を同時に測り、同じ保存予算で通常学習とpooling-aware学習を比較するのが実務的である。 -
訓練時のpoolerと配備時の圧縮条件のずれを検証する。 記事では、学習時に使った比例poolingの効果が固定上限や適応的poolingにも転移した。一方、設定間の転移は実験結果であり、一般保証ではない。実運用の文書長分布を含む検証データで、候補となる上限・しきい値を評価し、校正用コーパスと索引対象コーパスの差も確認したい。
-
圧縮手段は独立に足すのではなく、組み合わせた最終構成で測る。 ベクトル数の削減にはtoken pooling、座標あたりの保存量には量子化、ベクトル次元にはMatryoshka truncationが使える。記事はこれらを併用できるとし、次元削減とpoolingをそれぞれ学習目的に組み込む構成にも触れている。最終的な容量と品質は、対象の索引・検索エンジン・コーパス上で一体として測定する必要がある。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
