RAGの検索層を実装していると、ある時点で「faissって、こんなに設定が多かったっけ」と感じる瞬間が来ます。
IndexFactoryの文字列を書き、nprobを調整し、大規模インデックスでは学習フェーズを走らせる。C++依存のビルドが環境によって通らない、という経験をした人も少なくないはずです。
turbovecは、そういった設定コストとは別の方向を向いたツールです。Rustバックエンド＋Pythonバインディングの検索専用インメモリインデックス。faissの代替ではなく、「検索層だけをシンプルに速くしたい」という場面での差し替え候補です。
faissの設定コストと、turbovecという選択肢
faissは多彩なインデックス戦略（IVF・PQ・HNSW）を持ち、億単位のベクトルを扱う場面でも実績があります。その「全部入り」な設計は、しかし、導入コストと裏表です。
IVF+PQを使おうとすると、まずコーパスからサンプルを引いてコードブックを学習させる必要があります。コーパスが増えるたびに再学習が必要になることもあり、動的に文書が追加されるRAGとは噛み合わない場面があります。
C++依存のビルドも、Dockerイメージの構成やCI環境によっては思わぬ時間を取られます。
turbovecはこの逆を狙っています。pip install turbovec で入り、数行でインデックスを構築してクエリを投げられます。
faissとturbovecの役割の違いを整理すると、こうなります。
- faiss：多様なインデックス戦略・大規模スケール・高度なチューニングを提供する「全部入り」ライブラリ
- turbovec：シンプルなAPIで検索だけを担う「検索専用」インデックス。永続化・メタデータ管理は対象外
- 導入コスト：faissはIndexFactory・学習フェーズ・C++依存、turbovecはpip一発
- 使い分けの基準：規模・チューニング要否・動的コーパスかどうか
ひとつ先に書いておくと、turbovecはGitHubスター数1.7K程度の若いプロジェクトです。faissやchromadbと比べるとコミュニティは小さく、本番採用する場合は自分でベンチマークを取ることを前提にすべきです。
TurboQuantが速さとメモリ効率を両立する仕組み
turbovecの核心は、Google Researchが発表したTurboQuantという量子化アルゴリズムです。仕組みを数式なしで整理します。
OpenAIのtext-embedding-3-smallが出力する1536次元のベクトルは、float32（1次元あたり4バイト）で表現すると1ベクトルあたり6,144バイトです。
これを2〜4ビット整数に近似することで、384バイトまで圧縮されます。16倍のメモリ削減で、10Mベクトルで換算すると31GBが4GBになります。
「精度を犠牲にして圧縮しているだけでは？」という疑問は自然です。ここでTurboQuantの工夫が効いてきます。
まず各ベクトルを正規化し、ランダム回転を適用します。この回転によって各座標の値の分布が均一に近い形に整い、量子化の際の情報損失を最小化できます。そのうえでLloyd-Maxスカラー量子化を使って各座標を低ビット整数にマッピングします。
faiss PQとの決定的な違いは「訓練不要」という点です。
faiss PQはコーパスからk-meansクラスタリングでコードブックを学習しますが、TurboQuantのコードブックはデータに依存しません。新しいベクトルをいつでも追加でき、コーパスの分布が変わっても再学習は不要です。
文書が日々追加される社内RAGでは、この特性は実用上かなり効きます。
検索速度については、SIMD命令（ARM向けNEON、x86向けAVX2）を使った手書きカーネルで高速化しています。ただし現時点のベンチマーク結果は環境によって差があります。
- ARM環境：FAISSの速度に対して2〜25%以内の差に収まる
- x86環境：現時点では1.4〜3.7倍遅い（最適化継続中）
M1/M2 MacやARM系Linuxサーバーでは十分競争力がありますが、x86サーバーで速度要求が厳しい場面では慎重な評価が必要です。
recallについては次元数とビット数の組み合わせで変わります。d=3072の2ビット量子化ではTurboQuantがFAISSを上回り（0.912 vs 0.903）、d=1536の2ビットではFAISSがやや優位（0.882 vs 0.870）という検証結果があります。
ただし、k=4〜8以上では両者ともrecallが1.0に収束します。RAGの実用的な検索では、この差はほぼ無視できます。
Pythonから数行で使う：社内文書RAGへの最小組み込み例
turbovecの実装は、faissと比べると拍子抜けするほどシンプルです。埋め込みの生成は別途（OpenAI APIでもローカルモデルでも）行い、turbovecは検索だけを担います。
まずインストールから。
pip install turbovec
インデックス構築からクエリ実行までの最小構成です。
import numpy as np
from turbovec import Index
# インデックスを初期化（次元数を指定）
dim = 1536 # text-embedding-3-small の場合
index = Index(dim)
# ベクトルを追加（埋め込み生成は別途実施済みとする）
# embeddings: shape (N, dim) の numpy array
doc_ids = ["doc_001", "doc_002", "doc_003"] # 例
for i, embedding in enumerate(embeddings):
index.add(embedding, doc_ids[i])
# クエリ実行
query_vector = get_embedding("社内の有給申請手続きについて教えてください")
results = index.search(query_vector, k=5)
# results は (スコア, ID) のリスト
for score, doc_id in results:
print(f"{doc_id}: {score:.4f}")
APIシグネチャはREADMEで最新版を確認してください。上記はturbovecのコンセプトを示す構成例です。
search-time filteringについては、SIMDカーネル内部でフィルタリングを実行するため、対象外ベクトルを後から除外するのと違い、recallロスなしに絞り込みが効きます。具体的なPython APIのシグネチャはGitHubのturbovecリポジトリで確認してください。
ここで注意点を添えておきます。
turbovecは永続化に対応していません。プロセスを再起動するたびにインデックスをゼロから再構築する必要があります。
文書数が数万件程度なら再構築コストは許容範囲ですが、数十万件を超えてくると起動時間が問題になります。
chromadbとの役割分担はここで整理できます。chromadbはベクトルDBで、永続化・メタデータ管理・コレクション管理が主役です。turbovecは純粋な検索インデックスで、「保存されたベクトルをどう速く探すか」だけを担います。
競合ではなく、用途が異なります。永続化が必要ならchromadbを選び、インメモリで検索速度を最大化したい場面でturbovecを選ぶ、という使い分けです。
turbovecが「刺さる」場面と、刺さらない場面
社内文書RAG（数万〜数十万件規模） が最も相性のいい用途です。
この規模ならインメモリで十分収まり、起動時の再構築コストも許容範囲です。シンプルなAPIのおかげで検索層の実装が薄くなり、RAGパイプライン全体の見通しがよくなります。
プロトタイプ・PoC でも力を発揮します。IndexFactory文字列を調べたり学習フェーズを走らせたりする手間なく、埋め込みを入れてすぐ検索を試せます。「まず動くものを見せる」フェーズでの摩擦が少ない。
エアギャップ環境・プライバシー重視の構成にも向いています。外部サービスへの通信が不要で、ローカルで完結します。医療・法務・金融など、データを外に出せない業種での社内RAGで、このローカル完結という特性が効きます。
一方、向かない場面も明確にあります。
- 億単位のベクトル：インメモリ前提の設計なので、スケールに限界があります
- 永続化が必須：再起動のたびに再構築が必要なため、本番運用では設計上の工夫が必要です
- 複雑なメタデータフィルタリング：chromadbやqdrantのようなリッチなフィルタ機能はありません
- x86環境での速度要求が厳しい場合：現時点でFAISSより1.4〜3.7倍遅いケースがあります
プロジェクトの成熟度も見ておく必要があります。
GitHubスター数1.7Kは、faissやchromadbと比べると小さなコミュニティです。APIの安定性・長期メンテナンスの継続性・エッジケースでの挙動など、成熟したライブラリが当たり前に持っている安心感は、まだ自分で検証する必要があります。
本番採用するなら、自分のデータセットでrecallとスループットを計測してから判断するのが筋です。
「faissを捨てる」話ではありません。大規模・高チューニング・永続化が必要な場面ではfaissやchromadbが正解です。turbovecが提示するのは「検索層だけをシンプルに速くしたい場面での選択肢」であり、RAGの検索層は差し替えが効く部分なので、小さく試して判断できます。
株式会社ホコサキは、山口県宇部を拠点にRAG構築・AI活用支援・業務システム開発を手がけています。「社内文書の検索精度を上げたい」「RAGのプロトタイプを早く動かしたい」といった相談があれば、お問い合わせページからお気軽にどうぞ。