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

新しい埋め込みモデルが話題になるたびに「うちのRAGインデックスも作り直すべきか」という判断を先送りしていないでしょうか。2026-08-26公開の初出時、この記事はrebasisが公表していた計測値——素の差し替えは12.5%、アダプタ橋渡しでも71%、62件中12件だけが橋渡し推奨——を、読者がそのまま自分の判断の目安に使える数字として紹介しました。2026-09-05に一次情報を取り直したところ、その数値の一部は作者自身の手で撤回されていました。この記事はその結果を反映して書き直しています。

誰におすすめ

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

何をすべきか

結論は「rebasisを使うかどうか」ではありません。ベンダが公表した保持率を、自分のインデックスの判断閾値として借りないことです。9日間で起きたことがそれを裏づけています。

1つ目。62件中12件で橋渡しが推奨されたという件数について、READMEは現在「12件のうち4件は数値が再現しないランで、手元に残る行では4件のいずれも損益分岐を越えていない。公開値は12で、生き残った行が支えるのは8である」と自ら注記しています。さらに、その推奨がどれだけ当たったかを示していた一致件数は「代数的な恒等式だった」として撤回され、残ったのは順位相関（Spearman ρ = 0.60）だけです。

2つ目。同じ3種類のアダプタを同じ問題に適用した査読付きの先行研究（Drift-Adapter、EMNLP 2025）は、フル再エンベッドの検索再現率の95〜99%を回復したと報告しています。ところがrebasis側は、その論文自身のコーパス・モデル対・フィット予算で同じプロトコルを走らせても0.24〜0.50しか出ず、公開値を再現できなかったと自ら公表しました。同じプロトコル・同じコーパスで0.97と0.50が同時に正しいことはありえず、どちらが正しいかはこの2文書からは決まりません。

3つ目。インデックス側を書き換えるmigrateは、0.1.0より前のすべての実行で、どのクエリでも答えられないインデックスを書き出していました。fitが作るのはクエリ側の写像なのに、migrateが書き換えるのは文書ベクトルで、必要なのは逆向きだったためです。書き込みは成功し、件数も本文も保たれ、読み戻しの検査も通っていました。0.1.0は双方向で誤ったアダプタを拒否するようになりましたが、通っていた検査の側が「意味が残っているか」を見ていなかったという点は、外から見えた数値の信頼性とは別の問題です。

だから、乗り換えの可否は他人の平均値ではなく、自分のコーパスと実際のクエリログの上で出た数字で決めるしかありません。rebasisのprobeはそのための道具として今も有効で、実際にクエリログが無いと損益分岐そのものを計算できず「暫定」と表示する設計になっています。

なお、埋め込みモデルを切り替える際に全ベクトルの再エンベッドが必要になること自体は、rebasis固有の主張ではありません。Qdrantの公式ドキュメントは「モデルを切り替えるにはコレクション内の全ベクトルの再エンベッドが必要で、時間がかかりうる」と明記したうえで、新コレクションへのデュアルライト（blue-green）と、同一コレクションに新モデルをnamed vectorとして追加する2経路を案内しています。前提そのものはベンダ側でも確認できます。

注意点

rebasisは2026-08-27にPyPIへ0.1.0が公開されました（Apache-2.0、Python 3.12以上、これが唯一のリリース）。GitHubのスターは16、フォークは0で、README・計測・その撤回のすべてが同一の作者によるもので、独立した第三者による再現はまだありません。

作者自身が「1.0より前はPython API・.rbsアダプタ形式・判定しきい値のいずれも変わりうる」「バックアップはrebasisに任せず別に取ってほしい」と明記している段階のツールです。移行を途中で止めた半移行状態のインデックスは新旧モデルのベクトルが混在し、どのクエリも全体に対しては正しくありません。

それでも、自分に不利な訂正を自分で公開し、査読付きの先行研究に対する再現失敗まで公表しているという振る舞いは、数値そのものとは別に評価できる材料です。数値を借りるのではなく、測る道具として見るなら妥当な選択肢です。