FAISS: die Bibliothek hinter der Suche vectorielle

#Eine Bibliothek, keine Datenbank

FAISS wird oft mit Vektordatenbanken verglichen, als wären sie Alternativen zueinander. Sie gehören jedoch unterschiedlichen Kategorien an. Eine Vektordatenbank ist ein Dienst mit einer API, Speicher, Filterfunktionen und Berechtigungen. FAISS ist eine Komponente, geschrieben in C++ mit vollständigen Wrappern für Python und NumPy: Sie übergeben ihr Vektoren, sie erstellt einen Index im Speicher und beantwortet die Frage „Welche Vektoren liegen diesem hier am nächsten?“. Mehrere Vektordatenbanken verwenden intern FAISS oder etwas Ähnliches. Das Projekt wird unter der MIT-Lizenz veröffentlicht, hatte Ende September 2026 mehr als 41.000 Sterne auf GitHub, und seine Autoren geben an, dass einige seiner Methoden auf Milliarden von Vektoren im Hauptspeicher eines einzigen Servers skalieren.

Die praktische Konsequenz: Wer FAISS wählt, akzeptiert damit, alles Weitere selbst zu übernehmen: den Index auf der Festplatte speichern, ihn wieder laden, ihn mit den eigenen Dokumenten konsistent halten, die Position eines Vektors dem Text zuordnen, aus dem er stammt, und entscheiden, was passiert, wenn zwei Prozesse gleichzeitig schreiben wollen. Nichts davon wird standardmäßig mitgeliefert; das ist eine bewusste Architekturentscheidung und kein Versäumnis des Projekts.

#Die relevanten Indizes

Der Rat, der am meisten Zeit spart: mit der exakten Suche beginnen. Approximative Indizes lösen ein Skalierungsproblem; sie einzusetzen, bevor dieses Problem auftritt, bedeutet, sich einzustellende Parameter und einen zu messenden Recall einzuhandeln — im Austausch gegen Millisekunden, die niemand bemerkt hat. Bei einem lokalen Korpus ist das Retrieval fast nie der langsame Schritt — die Generierung durch das Sprachmodell bestimmt den größten Teil der vom Endnutzer wahrgenommenen Antwortzeit.

#Das Wichtigste für den Einstieg mit Python

1. 01
   Bibliothek installieren

   pip install faiss-cpu installe le paquet officiel PyPI (version 1.15.1 fin septembre 2026). Pour la variante GPU, le projet documente une installation via conda : conda install -c pytorch -c nvidia -c conda-forge faiss-gpu=1.15.1.
2. 02
   Einen exakten Index erstellen

   index = faiss.IndexFlatL2(dimension) erstellt einen exakten Suchindex für Vektoren der Dimension Ihres Embedding-Modells.
3. 03
   Vektoren hinzufügen

   index.add(vecteurs), wobei vecteurs ein NumPy-Array der Form (n, dimension) mit 32-Bit-Gleitkommazahlen ist.
4. 04
   Abfragen

   distances, indices = index.search(requete, k) liefert die k nächsten Nachbarn und ihre Abstände; Sie müssen indices den ursprünglichen Textabschnitten zuordnen.
5. 05
   Sichern und erneut laden

   Mit faiss.write_index(index, chemin) und anschließend faiss.read_index(chemin) bleibt der Index zwischen zwei Ausführungen auf der Festplatte gespeichert, da FAISS dies nicht selbst erledigt.

#Einen Index nach der Größe des Korpus auswählen

Das offizielle Wiki des Projekts veröffentlicht präzise Richtwerte in Form von Zeichenketten, die an dessen Index-Factory (index_factory) übergeben werden. Unter einer Million Vektoren genügt IVF_K, wobei K je nach Anzahl der Vektoren N zwischen 4×√N und 16×√N gewählt wird und der Trainingsdatensatz 30×K bis 256×K Vektoren umfasst. Zwischen 1 und 10 Millionen wird die Kombination IVF65536_HNSW32 empfohlen, die HNSW nutzt, um die Zuweisung zu Clustern zu beschleunigen. Zwischen 10 und 100 Millionen: IVF262144_HNSW32; darüber hinaus bis zu einer Milliarde: IVF1048576_HNSW32 – ab dieser Größenordnung wird das Training deutlich langsamer und erfolgt in der Regel auf der GPU, während der Rest auf der CPU läuft.

Für ein lokales Dokumentenkorpus – einige Tausend bis einige Hunderttausend Textabschnitte – bestätigen diese Richtwerte vor allem, dass die Schwelle, ab der ein approximativer Index notwendig wird, noch weit entfernt ist: Ein exakter Index oder schlimmstenfalls ein einfacher IVF_K decken nahezu alle Fälle in der Praxis ab, und Konfigurationen mit mehreren Hunderttausend Trainingseinträgen bleiben für die übliche Arbeit mit Dokumenten außer Reichweite.

#Der Speicherbedarf in Zahlen

Ein Vektor mit 1.024 Dimensionen, dessen Werte als 32-Bit-Gleitkommazahlen gespeichert sind, belegt etwa 4 KB. Eine Million Vektoren benötigt somit ungefähr 4 GB, noch ohne die Indexstruktur selbst. Speziell für einen HNSW-Index gibt das offizielle Wiki die Formel (d×4 + M×2×4) Bytes pro Vektor an, wobei d die Dimension und M die Anzahl der Verbindungen pro Vektor ist (zwischen 4 und 64: mehr Verbindungen bedeuten mehr Genauigkeit und einen höheren Speicherbedarf). Diese Rechnung bestimmt die meisten Architekturen: Deshalb gibt es Kompression, und deshalb hat ein Rechner, auf dem auch ein Sprachmodell läuft, weniger Spielraum, als man vermutet.

Bei der Kompression kodiert die Produktquantisierung (PQ) jeden Vektor mit M Bytes, typischerweise höchstens 64 — darüber hinaus ist eine skalare Quantisierung (SQ) in der Regel ebenso genau und schneller. Wenn die Qualität der Kompression wirklich zählt, empfiehlt der offizielle Leitfaden, vor der Quantisierung eine OPQ-Transformation hinzuzufügen: Sie reduziert zunächst die Dimension des Vektors durch eine lineare Transformation, die ihn leichter komprimierbar macht, und wendet anschließend die Produktquantisierung auf das Ergebnis an. Das ist ein zusätzlicher Rechenschritt bei der Indexierung, verringert aber bei gleicher Codegröße den Genauigkeitsverlust gegenüber einer direkten Produktquantisierung. RaBitQ, die Option für maximale Kompression, kommt auf etwa (d/8 + 8) Bytes pro Vektor, indem es nur ein Bit pro Dimension beibehält. Dafür ist ein zusätzlicher Schritt mit einer zufälligen Rotation nötig, um eine angemessene Genauigkeit zu erhalten; Varianten mit mehreren Bits pro Dimension erlauben es, gegen etwas mehr Speicherbedarf ein wenig Genauigkeit zurückzugewinnen.

#Die fehlende Funktion, die alles entscheidet

Fragen aus der Praxis enthalten Bedingungen: nur die Dokumente dieses Kunden, nur nach diesem Datum, nur das, was diese Person lesen darf. FAISS kennt keine Metadaten. Der übliche Behelf – mehr Ergebnisse als nötig abrufen und anschließend in Python filtern – ist aus einem ganz bestimmten Grund fehlerhaft: Wenn die fünfzig besten Ergebnisse alle zu einer anderen Abteilung gehören, bleibt nach dem Filtern nichts übrig. Ihr Assistent erklärt dann, keine Informationen gefunden zu haben, statt zu sagen, dass er keine Informationen gefunden hat, die Sie einsehen dürfen.

Insbesondere darf die Filterung nach Zugriffsrechten nicht erst nach dem Abruf implementiert werden. Das ist das stärkste praktische Argument für ein System, das bereits während der Suche filtert: eine Vektordatenbank oder Vektoren in PostgreSQL, wo die Filterung über eine WHERE-Klausel erfolgt.

• pgvector: Filtern während der Suche in SQL
• Qdrant: der dedizierte Dienst
• Milvus: die Vektordatenbank für große Datenmengen
• Die vollständige RAG-Kette
• Das lokale RAG-Kit QuelLLM
• Quelle: offizielles FAISS-Repository auf GitHub
• Quelle: offizieller Leitfaden zur Auswahl eines Index
• Quelle: Schnellstartbeispiel FAISS in Python

#Wann FAISS die richtige Wahl ist

Eine Anwendung mit einem einzigen Prozess

Die beim Start einen Index lädt und ihn abfragt: ein Desktop-Tool, eine Batchverarbeitung, ein Notebook.

Ein unveränderliches Korpus

Wird nach einem festen Zeitplan neu aufgebaut statt kontinuierlich aktualisiert.

Keine Benutzerfilterung

Oder eine so grobe Filterung, dass ein Index pro Kategorie noch sinnvoll ist.

Wenn die Latenz entscheidend ist

Wenn Sie gerade die Latenz eines Netzwerk-Roundtrips zu einer Datenbank vermeiden möchten, etwa bei einem eingebetteten Tool ohne garantierte Verbindung.

Abgesehen von diesen Fällen ist der Dienst, dessen Installation man vermeiden möchte, auf Dauer meist günstiger als der Code für Persistenz, Filterung und die Verwaltung gleichzeitiger Zugriffe, den man mit wachsendem Projekt schließlich selbst neu implementiert.

Ein letzter hilfreicher Hinweis, bevor Sie sich entscheiden: Mehrere Vektordatenbanken, denen Sie andernorts begegnen werden, ersetzen FAISS nicht auf magische Weise. Sie kapseln es oder orientieren sich an denselben Indexfamilien (IVF, HNSW, Produktquantisierung), die hinter einer Netzwerk-API, einem verwalteten Persistenzsystem und einer Filter-Engine zum Einsatz kommen. FAISS zu verstehen bedeutet daher, einen großen Teil der internen Funktionsweise von Vektordatenbanken selbst zu verstehen — ein hilfreicher Umweg, selbst wenn das endgültige Projekt Qdrant oder Milvus verwendet, statt FAISS direkt einzusetzen. Denn dieselben Kompromisse zwischen Speicherbedarf und Genauigkeit finden sich dort unter anderen Parameternamen wieder.

#FAQ