埋め込みモデルを乗り換える前に「やらない」を数値で判断するrebasis

新しい埋め込みモデルが話題になるたびに「うちのRAGインデックスも作り直すべきか」という判断を先送りしていないでしょうか。2026年8月23日に公開されたrebasisは、その判断を着手前に自分のコーパスとクエリログで数値化するためのCLIです。

誰におすすめ

Chroma、Qdrant、sqlite-vec、LanceDBなどで数万〜数百万チャンク規模のRAGインデックスを本番運用していて、より新しい埋め込みモデルに乗り換えたいものの、再エンベッドの費用と停止時間を理由に判断を先送りしている個人開発者・少人数チームのエンジニア向けです。

何をすべきか

rebasisの開発者自身が62件の実移行に人手評価を付けて計測したところ、埋め込みモデルを素のまま差し替えるだけでは、フル再インデックスした場合の性能の12.5%しか保てなかったとされています。学習済みのアダプタ(orthogonal Procrustesによる変換)で橋渡しした場合でも71%止まりで、この62件のうち、rebasis自身の判定ロジックが「橋渡しする価値がある」と推奨したのはわずか12件、残り50件では橋渡しが見送られています。

つまりこのツールの主な使いどころは、移行を実行することではなく、「今回は見送る」という判断を裏付ける数値を得ることにあります。据え置き・アダプタ橋渡し・全件再構築のどれを選ぶにせよ、その判断は一般的なベンチマークではなく自分のコーパスと実際のクエリログの数値で下すべきです。

なお、埋め込みモデルを切り替える際に全ベクトルの再エンベッドが必要になること自体は、rebasis固有の話ではありません。Qdrantの公式ドキュメントも、モデルを切り替える場合は新しいコレクションを用意してデュアルライトで段階的に再エンベッドする、という同様の前提に立った移行手順を案内しています。

注意点

これらの数値はすべてrebasis開発者自身による自己計測です(v0.1、公開からまだ数日、GitHubスター1桁台)。11コーパス・398,010文書・10,346件の人手作成質問という規模の大きい計測ではあるものの、独立した第三者による再現はまだありません。また開発者自身が「1.0より前はPython API・アダプタ形式・判定しきい値のいずれも変わりうる」「バックアップはrebasisに任せず別に取ってほしい」と明記している段階のツールである点も踏まえて判断してください。