RAGの検索を二つのモデルで分担する、Cohere Embed 5の仕組み｜2026年11月3日版
社内文書を探してからAIに回答させるRAGでは、資料を登録するときと、利用者が質問するときに、それぞれ検索用の数値データを作ります。Cohereの「Embed 5」は、この二つの処理を別のモデルに分担させられる点が特徴です。
文書の登録には品質重視のPro、質問の処理には速度重視のFastを使い、同じ検索インデックスを利用できます。 大量の資料を登録する処理と、利用者を待たせないための処理を、別々に設計できるわけです。
2026年11月3日（日本時間）時点の公式情報をもとに、9月30日に発表されたEmbed 5の仕組みと、導入時に確認したい点を整理します。
- ProとFastは、検索に使う「埋め込み空間」を共有する。
- 文書側をProで登録したまま、質問側にFastを使える。
- 導入判断では、日本語資料での検索品質と、回答までの待ち時間を測る必要がある。
Embed 5で変わる、文書登録と質問処理の関係
CohereはEmbed 5を、品質を優先するProと、低遅延・大量処理を重視するFastの二つで提供しています。発表時点ではCohere API、Model Vault、Microsoft Foundry、Amazon SageMakerでの一般提供を案内しました。公式発表
埋め込みモデルは、文章などの内容を「ベクトル」と呼ぶ数値の並びに変換します。検索では、質問のベクトルと文書のベクトルを比較し、意味が近い資料を候補にします。
ここで重要なのは、同じ桁数のベクトルなら、別モデル同士でも比較できるとは限らないことです。数値が表す意味の対応が必要になります。
Embed 5は、ProとFastでその対応を共有しています。Cohereの公式ドキュメントも、Proで文書を登録し、Fastで質問を処理する構成を推奨しています。モデル仕様
なぜ処理を分けると役に立つのか
文書の登録は、利用者が検索する前にまとめて実行できます。一方、質問を検索用ベクトルに変える処理は、原則として検索のたびに発生します。
この違いを使うと、次のように役割を分けられます。
- 資料の追加・更新時に、Proで文書ベクトルを作る。
- 利用者から質問が来たら、Fastで質問ベクトルを作る。
- 登録済みの文書から関連資料を探し、生成AIへ渡す。
共有空間の利点は、質問側でProとFastを比較するときに、文書全体のベクトルを作り直さずに済むことです。ただし、これはEmbed 5の両モデル間での話です。旧世代や他社のモデルで作ったインデックスを、そのまま流用できるという意味ではありません。
高速化できるのは、RAGのどの部分か
Fastを採用しても、回答システム全体が同じ割合で速くなるわけではありません。
RAGには、質問のベクトル化以外にも処理があります。
- ベクトルデータベースから候補を取得する。
- 必要なら候補を並べ替える。
- 閲覧権限を確認し、回答に使う資料を絞る。
- 生成AIが資料を読み、回答を出す。
質問のベクトル化が待ち時間の大きな部分を占めるなら、Fastへの切り替えは有効な改善候補です。生成AIの回答処理やデータベース検索に時間がかかっているなら、そこも測らなければなりません。
また、埋め込みモデルは資料を探すための部品です。見つかった資料の正しさや、生成AIがその内容を忠実に回答することまで保証するものではありません。
日本語の社内検索では、正解資料を拾えるかを測る
日本の開発者や企業利用者にとって、最初の確認点は、日本語の質問で必要な資料が検索上位に入るかどうかです。
公式ドキュメントの対応言語には日本語が含まれます。ただし、対応言語に載っていることと、自社の略語、製品名、独自帳票を正しく検索できることは別です。
導入評価では、たとえば次のような質問と正解資料の組を用意すると、差を判断しやすくなります。
- 社内の略称を使って、正式名称で書かれた規程を探す質問。
- 日本語の質問から、英語の技術資料を探す質問。
- よく似た旧版・新版のマニュアルから、必要な版を探す質問。
そのうえで、Proで作った同じ文書インデックスに対し、質問側をProにした場合とFastにした場合を比較します。
見るべき指標は、少なくとも二つです。正解資料が上位に入る割合と、質問を受けてから検索結果が返るまでの時間。 平均時間だけでなく、遅いケースで利用者を何秒待たせるかも確認したいところです。
検索品質と閲覧権限は別に管理する
関連性が高い資料でも、質問者が閲覧できるとは限りません。人事資料や契約書を扱う場合、回答用の資料を生成AIへ渡す前に、利用者の権限を反映する必要があります。
Embed 5への変更を評価するときも、検索精度の改善と、既存のアクセス制御が保たれていることを分けて確認するのが実務上の要点です。
継続ウォッチ：同じインデックスで何を比較するか
Embed 5の注目点は、文書登録と質問処理に別モデルを選べることです。実運用で価値が出るかは、次の比較で見えてきます。
- 品質差：Fastに切り替えたとき、取りこぼす質問はどれか。
- 時間差：質問のベクトル化と、回答全体の待ち時間がそれぞれどれだけ変わるか。
- 更新負荷：文書の追加頻度に対し、Proでの登録処理が間に合うか。
最初の検証は、同じ文書、同じ質問、同じ検索条件で質問側のモデルだけを変えることです。そこで品質と待ち時間の差を測れば、Fastを標準にするか、品質が必要な検索にProを残すかを具体的に判断できます。