Cohere Embed 5、インデックス作成とクエリを分離しRAGの遅延を削減

Cohereは水曜日にEmbed 5を発表し、データインデックス作成とクエリ実行を分離するデュアルモデルアーキテクチャを導入しました。このアップデートにより、エンジニアリングチームは、ベクトルインデックスの構築には高忠実度のEmbed 5 Proを使用し、ライブクエリの処理には低コストかつ高スループットのEmbed 5 Fastを使用することが可能になります。しかも、個別のデータ構造を維持管理する必要はありません。

何が起きたか

今回のリリースの中核的な革新は、2つのモデル間で共有される埋め込みスペースです。従来、より効率的なクエリモデルへの切り替えには、コーパス全体の再インデックスや並行インデックスの維持が必要になることが多く、ストレージコストと運用複雑性が倍増していました。Embed 5では、開発者はProモデルを使用してドキュメントを取り込み、インデックス作成段階での高い検索品質を確保できます。システムがユーザーのクエリに応答する際は、同じベクトル次元と互換性基準内で動作するFastモデルに切り替えます。

Cohereの社内テストによると、このハイブリッドアプローチによる検索品質の低下は最小限にとどまっています。テキスト、画像、融合ドキュメント、解析済みドキュメントを含む40のデータセットにおいて、ProインデックスとFastクエリの組み合わせは、Pro対Pro使用時のベースライン100に対して98.4という相対スコアを達成しました。一方、インデックス作成とクエリの両方でFastモデルを使用すると、スコアはさらに96.6まで低下しました。同社は、混合Pro-Fast構成を使用した場合、個々のデータセットでパフォーマンスの大幅な低下は見られなかったと指摘しています。

このアーキテクチャの変更は、Retrieval-Augmented Generation（RAG）およびエージェントワークフローにおける一般的なボトルネックに対処します。これらのシステムでは、データの取り込みは頻繁に行われませんが、検索クエリは繰り返し発生し、低遅延である必要があります。Fastモデルによって重いクエリトラフィックを最適化することで、チームは初期インデックス作成段階で確立された精度を犠牲にすることなく、応答時間とインフラストラクチャコストを大幅に削減できます。

仕組み

Embed 5 ProとFastの両方は、同一の次元で互換性のあるベクトルを生成するため、同じインデックス内で共存できます。この互換性は、Matryoshka切り詰めやint8量子化などの高度な圧縮技術にも適用されます。開発者は256から2,048までの6つのベクトル次元から選択でき、ストレージ要件と精度要件に応じてfloat32、int8、バイナリ形式を選択できます。

大規模展開においては、ストレージへの影響が顕著です。標準的な2,048次元のfloat32ベクトルは8 KBを占めるため、1億チャンクのコーパスには約819 GBが必要になります。1,024次元のint8ベクトルに切り替えると、フットプリントは約102 GBに減少します。さらなる効率化のため、256次元のバイナリベクトルを使用すると、同じデータセットを約3.2 GBまで縮小できます。Cohereは、メモリ節約とほぼ完全な精度の検索品質のバランスが取れているため、ほとんどのユースケースで1,024次元のint8形式を推奨しています。速度が重要な初期検索段階ではバイナリ表現が推奨され、その後に高精度のリランキングが行われます。

これらのモデルは、100以上の言語に対応したマルチモーダル入力（テキスト、画像、テキストと画像の融合など）もサポートしています。128Kトークンのコンテキストウィンドウを備えており、大きなドキュメントや複雑な視覚データを直接処理できます。この機能により、ページ画像や複合入力を単一のベクトルに埋め込むことが可能になり、現代のAIアプリケーションにおける多様なドキュメントタイプの処理が簡素化されます。

主要な詳細

• Embed 5 Proは100万トークンあたり0.12ドル、Embed 5 Fastは100万トークンあたり0.08ドルです。
• Cohereのテストでは、FastモデルはProモデルと比較して平均2.4倍のドキュメントスループットを提供します。
• 40のデータセットにおいて、ProインデックスとFastクエリの組み合わせは、Pro対Proベースライン100に対して98.4の相対スコアを記録しました。
• 両モデルとも、256から2,048までの6つのベクトル次元をサポートし、float32、int8、バイナリ形式のオプションがあります。
• モデルは、128Kトークンのコンテキストウィンドウを持つ100以上の言語で、テキスト、画像、融合入力を処理します。
• Embed 5は、CohereのAPI、Model Vault、Microsoft Foundry、Amazon SageMakerを通じて利用可能であり、vLLMを介したプライベートVPCおよびオンプレミス展開をサポートします。

なぜ重要なのか

RAGシステムを構築するソフトウェアエンジニアにとって、インデックス作成の品質とクエリ遅延を分離できることは、大きな運用上の利点です。本番環境の多くは読み取り負荷が高いため、クエリのコストと速度が総所有コストを支配します。高ボリュームのクエリパスに安価で高速なモデルを使用することで、チームは複数のインデックスの管理やデータの再処理に伴うオーバーヘッドなしに、APIコストを削減し、ユーザー体験を向上させることができます。

ただし、ベンチマーク結果には重要な注意点があります。Cohereは、固定ラベルではなくクエリ固有の関連性基準を使用する指標であるRCP-nDCG@10を用いてEmbed 5を評価しました。この手法は従来のベンチマークで見逃された関連結果を特定できる場合がありますが、フルコーパスからの第一段階検索ではなく、固定候補セットに対するリランキングを測定しています。第一段階検索は標準的なnDCGとRecallを用いて別途評価されているため、報告されたスコアはすべての評価タイプ間で直接比較できるものではありません。

本番チームは、これらの発見事項を自社のデータで検証する必要があります。エージェントワークフローにおける検索エラーは複数ステップにわたって累積し、重大な下流の問題を引き起こす可能性があります。したがって、平均スコアの低下は小さいものの、特定のドメインやクエリパターンでは異なる挙動を示す可能性があります。エンジニアは、完全に移行する前に、自社のコーパスとクエリ分布に対してPro対Fast設定をベンチマークすべきです。

実施可能なこと

• インデックス用にEmbed 5 Pro、クエリ用にFastを使用し、現在のRAGパイプラインをベンチマークして、遅延とコスト削減を測定してください。
• 異なるベクトル次元と量子化形式が、ストレージコストと検索精度に与える影響を評価してください。
• アプリケーションが多様なドキュメントタイプを扱う場合は、ページ画像や融合テキスト-画像入力の埋め込みを通じてマルチモーダル機能をテストしてください。
• オンプレミスやプライベートVPC設定などのvLLMなど、選択した展開オプションをサポートしているかを確認するために、インフラストラクチャを見直してください。
• エージェントワークフローに複数の連続した検索ステップが含まれる場合特に、本番環境での検索品質を注意深く監視してください。
• ストレージ制約が厳しい場合は、初期検索段階でバイナリベクトルを使用し、その後リランキングを行うことを検討してください。