FAISS：検索に使用されるライブラリ vectorielle

#ライブラリであり、データベースではない

FAISSは、ベクトルデータベースと互いの代替となるかのように比較されることがよくあります。しかし、両者は異なる種類のものです。ベクトルデータベースは、API、ストレージ、フィルタリング、権限管理を備えたサービスです。FAISSはコンポーネントです。C++で書かれ、PythonとNumPy向けの完全なラッパーを備えており、ベクトルを渡すとメモリ上にインデックスを構築し、「このベクトルに最も近いのはどれか」という問いに答えます。複数のベクトルデータベースが、内部でFAISSまたは類似のものを使用しています。このプロジェクトはMITライセンスで公開されており、2026年9月末時点でGitHubのスター数は41,000を超えていました。開発者らによると、一部の手法は、単一サーバーのメインメモリ上で数十億のベクトルを扱う規模にまで対応できます。

実用上、FAISSを選ぶということは、それ以外の処理をすべて自分で担うことを受け入れるということです。インデックスをディスクに保存して再読み込みし、ドキュメントとの整合性を保ち、ベクトルの位置とその元のテキストを対応付け、2つのプロセスが同時に書き込もうとした場合の処理を決める必要があります。これらはどれも標準では提供されません。これは意図的なアーキテクチャ上の選択であり、プロジェクト側の実装漏れではありません。

#重要となるインデックス

最も時間の節約につながるアドバイスは、まず厳密検索から始めることです。近似インデックスは規模の問題を解決するためのものです。その問題に直面する前に採用すると、誰も気づかない数ミリ秒の短縮と引き換えに、パラメータの調整や再現率の測定という負担を抱えることになります。ローカルのコーパス程度の規模では、検索が遅い工程になることはほとんどありません。エンドユーザーが感じる応答時間の大部分を占めるのは、言語モデルによる生成です。

#Pythonで始めるために最低限必要なこと

1. 01
   ライブラリのインストール

   pip install faiss-cpuで、公式PyPIパッケージをインストールします（2026年9月末時点のバージョンは1.15.1です）。GPU版については、プロジェクトがconda経由のインストールを案内しています：conda install -c pytorch -c nvidia -c conda-forge faiss-gpu=1.15.1。
2. 02
   厳密検索用のインデックスを構築する

   index = faiss.IndexFlatL2(dimension)は、お使いの埋め込みモデルと同じ次元数のベクトルを対象に、厳密検索用のインデックスを作成します。
3. 03
   ベクトルを追加する

   index.add(vecteurs) の vecteurs は、形状が (n, dimension) で、要素が 32 ビット浮動小数点数の NumPy 配列です。
4. 04
   問い合わせる

   distances, indices = index.search(requete, k) は、最も近いk個の近傍とそれぞれの距離を返します。indicesを元のテキストの断片に対応付ける処理は、ご自身で行う必要があります。
5. 05
   保存して再読み込みする

   faiss.write_index(index, chemin)で保存し、その後faiss.read_index(chemin)で読み込むことで、インデックスをディスク上に保持し、次の実行時にも利用できます。FAISS自体はこれを自動では行いません。

#コーパスのサイズに応じてインデックスを選択する

プロジェクトの公式Wikiには、インデックスファクトリ（index_factory）に渡す文字列として表現された正確な目安が公開されています。100万ベクトル未満の場合、IVF_K が十分であり、K はベクトル数 N に応じて 4×√N から 16×√N の間で選択し、学習セットは 30×K から 256×K ベクトルを使用します。100万から1000万の場合、推奨される組み合わせは IVF65536_HNSW32 で、HNSW を使用してクラスタへの割り当てを高速化します。1000万から1億の場合、IVF262144_HNSW32 を使用し、1億を超えて10億まででは IVF1048576_HNSW32 を使用します。この段階では、学習が明らかに遅くなり、通常は残りの処理が CPU で実行されている間に GPU で行われます。

ローカルの文書コーパス、つまり数千から数十万のテキスト断片を扱う場合、これらの目安からまず確認できるのは、近似インデックスが必要になる規模にはまだ遠く及ばないということです。厳密インデックス、あるいは必要になっても単純な IVF_K で、実際のケースのほぼすべてに対応できます。また、数十万件の学習用エントリを必要とする構成は、一般的な文書利用では依然として手の届かないものです。

#数字で見るメモリ

32ビット浮動小数点数の1,024次元ベクトルは、約4 KBを占有します。したがって、100万個のベクトルでは、インデックス構造自体を含まずとも、約4 GBになります。HNSWインデックスについては、公式Wikiにベクトルあたり(d×4 + M×2×4)バイトという式が示されています。ここでdは次元数、Mはベクトルあたりのリンク数（4から64の間：リンク数が多いほど精度は高くなりますが、メモリ使用量も増加します）です。この計算が多くのアーキテクチャを決定づけており、圧縮が存在する理由であり、言語モデルもホストするマシンが想像以上に余裕が少ない理由でもあります。

圧縮の観点では、積量子化（PQ）は各ベクトルをMバイトで符号化します。通常は最大64バイトまでで、それを超えるとスカラー量子化（SQ）の方が一般的に同等の精度を持ち、より高速です。圧縮品質が本当に重要になる場合、公式ガイドでは量子化の前にOPQ変換を追加することを推奨しています。OPQはまず線形変換によってベクトルの次元を下げ、圧縮しやすくしてから、その結果に積量子化を適用します。インデックス作成時に計算するステップが一つ増えますが、コードサイズが同じ場合、直接積量子化を行うよりも精度の劣化を軽減できます。最大限の圧縮オプションであるRaBitQは、各次元につき1ビットのみを保持することで、ベクトルあたり約(d/8 + 8)バイトまで削減できます。ただし、適切な精度を維持するためにランダム回転のステップが必要です。各次元につき複数ビットを使用することで、わずかなストレージ増加の代わりにある程度の精度を取り戻せるバリアントも存在します。

#未搭載の機能がすべてを左右する

実際の条件は、このクライアントのドキュメントのみ、この日付以降のみ、この人物が読む権限を持つもののみに限定されます。FAISSはメタデータの概念を持ちません。一般的な回避策——必要な結果よりも多くの結果を取得してその後Pythonでフィルタリングする——は正確に誤りです。もし五十件のトップ結果がすべて別のサービスに属している場合、フィルタリングによって何も残らず、アシスタントは情報が見つからなかったと報告しますが、実際にはあなたが見られる情報が一つも存在しないという状況を伝えているにすぎません。

特に、アクセス権に基づくフィルタリングは、検索結果を取得した後の段階で実装してはいけません。これが、検索中にフィルタリングを行うシステムを選ぶ最も強い実務上の理由です。選択肢はベクトルデータベース、またはPostgreSQL内にベクトルを保存し、WHERE句でフィルタリングする方法です。

• pgvector : SQLで検索中にフィルタリングする
• Qdrant：専用サービス
• Milvus：大容量向けのベクトルデータベース
• RAGパイプラインの全体像
• QuelLLMのローカルRAGキット
• 出典：GitHub上のFAISS公式リポジトリ
• 出典：インデックス選定ガイド（公式）
• 出典：Python での FAISS クイックスタート

#FAISS が適している場合

単一プロセスアプリケーション

起動時にインデックスを読み込み、それに対して検索を行うものです。例えば、デスクトップツール、バッチ処理、ノートブックなどです。

固定されたコーパス

継続的に更新するのではなく、決まったスケジュールに従って再構築します。

ユーザーごとのフィルタリングなし

または、フィルタリングの区分が十分に大まかで、カテゴリごとにインデックスを用意しても無理がない場合です。

低遅延が重要な場合

データベースとのネットワーク往復にかかるコストこそをなくしたい場合。たとえば、接続が保証されない組み込みツールなどです。

これらの場合を除けば、導入を避けているサービスを使うほうが、プロジェクトの成長に伴って結局自分で書き直すことになる永続化、フィルタリング、並行処理のコードよりも、長期的には一般にコストが低くなります。

判断する前に、最後にもう一つ押さえておきたい点があります。他で目にする複数のベクトルデータベースは、FAISS を魔法のように置き換えるものではありません。FAISS を包み込む形で利用するか、同じ系統のインデックス（IVF、HNSW、積量子化）を参考にし、その上にネットワーク API、管理された永続化の仕組み、フィルタリングエンジンを備えています。つまり、FAISS を理解することは、ベクトルデータベース自体の内部動作のかなりの部分を理解することにつながります。最終的なプロジェクトで FAISS を直接使わず、Qdrant や Milvus を使う場合でも、この寄り道は役立ちます。同じメモリと精度のトレードオフが、別のパラメータ名で現れるからです。

#FAQ