埋め込みスタックはモデルを変更するためだけに100%のリインデックスを強制します。 そしてほとんどのチームはそれを避けられないものと見なしています。 高い検索品質のために大規模な埋め込みモデルを持つRAGパイプラインを構築し、それを本番環境に出荷したと想像してください。 6か月後、アプリケーションのトラフィックと組み込みモデルのコストは急増し、パイプラインのスケールは苦戦しています。この新しい需要に応えるために、コストとレイテンシを優先するモデルに切り替えたいのです。 しかし、既存の埋め込みは一つのベクトル空間に存在し、新しいモデルは別のベクトル空間に埋め込みを生成するため、互換性がありません。 モデルを切り替えるということは、インデックスの再構築を意味します: - 各文書を再埋め込みする必要があります - すべてのチャンクを再計算しなければならない - クエリが再び動作する前に数百万のベクトルを再生成する必要があります 多くのチームはこれを見て、切り替えるのではなくコストを吸収することを決めます。 時間が経つにつれて、これは暗黙のルールとして固まっていきます。 品質を最適化するかコストを最適化するかのどちらかで、早い段階で下した決断と共に生きていくのです。 しかし、これは埋め込みの根本的な制限ではありません。 それは設計上の選択です。 埋め込みモデルが同じベクトル空間を共有していたらどうなるでしょうか? その仕組みでは、大きなモデルで文書をインデックスし、軽量モデルでクエリを行使でき、何も再構築せずに済みます。 ...