同じAPIキーとクレジットで索引化、検索、再順位付け、回答生成をつなぐ実装例を公開しました。Proで文書を索引化し、Fastで質問を検索する組み合わせを紹介しています。 索引を作る費用と質問ごとの呼び出しを分けて見積もります。再順位付けを追加する効果は、実際の質問と文書で検証し、関連資料がない場合の扱いも決めます。 検索から生成まで同じAPIの入口へ Cohereは11月4日、Embed 5とRerank 5をOpenRouterで利用できると発表しました。既存のAPIキーとクレジットを使い、検索のために別の請求や接続の仕組みを増やさずに始める構成です。記事は、社内文書を参照して回答を作るRAGの実装例を紹介しています。文書を数値表現にするEmbedで候補を探し、Rerankで質問と候補を読み直して順序を整えます。その後に生成モデルへ資料を渡します。今回の新情報は利用経路の追加と実装の公開であり、Embed 5やRerank 5そのものを初めて発表する記事ではありません。検索と生成の役割を分けて説明しています。 Proの索引をFastの質問処理と組み合わせる Embed 5のProとFastは同じ埋め込み空間を共有します。同じ次元数を使えば、文書側をProで索引化し、質問側をFastで処理できます。記事は、索引作成と質問ごとの応答で異なるモデルを使う例を示しています。再順位付けは候補の生のテキストを読むため、既存のキーワード検索や別の埋め込み検索にも追加できます。Rerank 5はテキストを対象とし、画像やPDFを検索する場合も、再順位付けには抽出した文字や説明を使います。影響を受けるのは、社内検索、問い合わせ対応、文書探索を実装する開発者と見られます。複数の処理を一つのAPIで呼べても、入力の形式や各段階の役割まで同じになるわけではありません。接続経路ごとの仕様も確認点です。 検索の精度向上を遅延と呼び出し費用と比較 参照例では、索引を作る処理と、質問のたびに行う処理を分けています。質問ごとに埋め込み、再順位付け、会話モデルの呼び出しが発生します。候補をすべて生成モデルへ渡す代わりに、関連性の低い資料を落とす構成です。基準を満たす資料がない場合は、生成自体を省きます。導入側では、再順位付けによる改善と追加の遅延を比較することが論点になると見られます。原文は、実際の質問へ正解を付け、再順位付けの有無を比べて基準値を調整するよう案内しています。サンプルの点数を、そのまま自社の採用基準へ移すことはできません。資料の分割方法と候補数を変えた場合も、結果と費用を合わせて確認する必要があります。生成に渡す資料の量も測定対象になります。 小さな実装例から運用用の保存先へ移す 記事は簡単な例としてNumPyで文書のベクトルを保持しています。実運用では用途に合ったベクトルデータベースへ置き換えるよう説明しています。次の判断点は、自社の文書量と更新頻度で、索引の維持と回答の確認を継続できるかです。APIの入口が統一されても、文書の閲覧権限や出典の管理は設計事項として残ると見られます。検索できた資料を正しく引用することと、その資料を利用者へ見せてよいかは、併せて確認する必要があると考えられます。