- ColBERTは、質問と文章を別々に符号化し、単語ごとの近さを後段で計算する検索モデルを提案した。
- 英語の文章検索データで、検索順位の質、質問への応答時間、索引の容量を比較した。
- 速さの数字は索引の作り方と機材に左右され、精度だけで導入方法を決められない。
何を確かめた研究か
BERTに質問と候補文章を一組ずつ入力すると、細かい単語の対応を見ながら順位を付けられる。その一方、候補が多い検索では同じ文章を質問のたびに繰り返し処理するため、計算が重い。ColBERTの原論文は、検索の質を保ちつつ、この繰り返しを減らせるかを問うた。
ColBERTの「Late Interaction」は遅い段階での相互作用を意味する。質問と文章を別々にBERTへ通し、それぞれの語をベクトルとして保存する。両者の対応を計算するのは最後の軽い段階だ。文章側の計算を索引作成時に済ませられることが、応答速度の鍵になる。
どう検証したか
質問の各語について、文章中で最も近い語との一致度を取り、それらを合計して文章の点数を作る。論文はこの計算をMaxSimと呼ぶ。文章を一つのベクトルだけで表す方法より細かな対応を残しながら、質問と文章を結合してBERTで再計算する方法より、質問時の負担を減らす設計だ。
著者らは、まず既存の検索器が選んだ候補を並べ替える方法と、索引から直接候補を探す方法の両方を調べた。評価はMS MARCOとTREC CARという英語の文章検索データで行う。MS MARCOでは上位10件の順位を測るMRR@10、取りこぼしを示すRecall、応答時間などを分けて示す。TREC CARでは評価指標が異なり、二つのデータの点数を直接並べることはできない。
何が分かったか
MS MARCOの再ランキング実験では、ColBERTはBERTを用いる既存の順位付け手法に近い精度を保ち、質問時の計算を大きく減らした。論文要約は、比較対象のBERT系手法より約100倍速く、質問当たりの演算量を約1万分の1にしたと述べる。これは測定条件付きの比較であり、現在のハードウェアでの一般的な速度倍率ではない。
全文検索に近い設定でも、約880万件のMS MARCO文章から直接候補を探して評価した。索引を小さくすると容量と精度の交換が生じる。論文の表4では、保存形式とベクトル次元を変えた場合の索引容量とMRR@10を併記している。「速い検索」は索引作成や保存の費用が消えることを意味しない。
限界は何か
この論文は大量の英語の学習例を持つ二つの検索データを中心に検証した。日本語の文書や、専門用語の多い小規模な社内資料で同じ順位になるとは示していない。正解文章の判定が少ないMS MARCOでは、評価指標そのものにも取りこぼしがありうる。
また、文章を語ごとのベクトルで持つため、単一ベクトルの索引より容量を使い得る。文書が更新されれば索引の更新も必要だ。応答時間だけを見て、保存費用、更新頻度、運用時の遅延を見落としてはならない。
仕事との接点
検索システムを比較するなら、利用者が実際に入力する質問と文書で、正しい候補が何位に出るか、質問時の遅延、索引容量、更新にかかる時間を同時に記録する。これはTRAIL編集部の提案であり、原論文が日本企業の文書検索を評価した結果ではない。