Cohere Embed 5：ProとFastの埋め込み空間共有、クエリモデルの個別選択

出力次元と入力タイプで決まるベクトルの互換条件

発表には条件が付いている。文書ベクトルとクエリベクトルの出力次元が同じでなければならない。

ベクトルを短く切るMatryoshka切り詰めや、値を低い精度で保存するint8量子化を適用しても互換性は保たれるとCohereは説明する。これはベクトル表現の互換性の説明であり、検索結果が同じという意味ではない。

埋め込みのドキュメントは、検索対象のテキストにinput_type="search_document"を、検索クエリにinput_type="search_query"を指定するよう案内している。ベクトルの長さはoutput_dimensionパラメーターで選ぶ。

モデルを比べるときにこれらの設定を記録しなければ、差がモデルから来たのか設定から来たのかを見分けられない。

注意点：Embed 4のインデックスと自社評価の数値

共有空間についての互換性の説明は、二つのEmbed 5モデルの間のものだ。以前のEmbed 4のインデックスをそのまま使える根拠ではない。

Cohereは40の開発用データセットで交差組み合わせを試し、FastクエリとProクエリの平均損失はそれぞれ1.6%と2.7%だったとしている。

これらはCohere自身の数値だ。互換性だけでは、特定の文書群での検索品質を証明するには足りない。

条件を固定したクエリ側の比較

次の段階は条件を統制したクエリ側の比較だ。Proでインデックス化した文書、出力次元、ベクトル形式、検索設定、代表的なクエリを固定し、FastとProの検索の関連性とエンドツーエンドのレイテンシを比べる。

アプリケーションにとって重要な言語や分野の難しいクエリも含める。

Fastが要件を満たすなら、ドキュメントに明記された共有空間のおかげで、文書ベクトルを作り直さずにクエリの経路だけを切り替えられる。これは評価計画であり、この記事のために実際に行ったテストではない。

同じ空間を共有するという保証はインデックスの再構築を省くだけで、自前のクエリでの検索品質は別に測るべき値だ。