Was ist eine Vektordatenbank?

Eine Vektordatenbank beantwortet eine Frage, sehr schnell

Man gibt ihr eine Zahlenliste, und sie liefert die gespeicherten Listen zurück, die ihr am nächsten sind. Das ist die gesamte Schnittstelle.

Die Listen sind Embeddings. Ein Embedding-Modell verwandelt eine Passage, eine Produktbeschreibung oder ein Bild in einige hundert bis einige tausend Zahlen, so platziert, dass ähnliche Bedeutungen nahe beieinander landen, und was sind Embeddings in der KI erklärt, wie das funktioniert. Eine Vektordatenbank ist der Ort, an dem diese Listen leben, sobald man viele davon hat. Sie speichert jede mit einer ID und einigen Metadaten, baut einen Index darüber auf und beantwortet die Suche nach nächsten Nachbarn: "hier ist ein Anfragevektor, gib mir die zehn nächstgelegenen."

Der schwierige Teil ist das Wort schnell. Eine Anfrage mit einer Million gespeicherten Vektoren zu je 1.536 Zahlen zu vergleichen, sind 1,5 Milliarden Multiplikationen, und das bei jedem Tastenanschlag zu tun, skaliert nicht. Deshalb verwenden Vektordatenbanken approximative Nächste-Nachbarn-Indizes, wobei HNSW der gängigste ist, eine Graphstruktur aus einem Paper von Malkov und Yashunin von 2016, die nur ein paar hundert Kandidaten statt aller Millionen prüft und fast immer die richtige Antwort liefert. Dieses "fast" ist der Kompromiss: etwas weniger Trefferquote für eine tausendfache Geschwindigkeitssteigerung.

Die bestehende Datenbank findet Wörter, eine Vektordatenbank findet Bedeutung

Eine relationale Datenbank findet Zeilen, deren Werte übereinstimmen: WHERE customer_id = 4127. Ein Volltextindex findet Dokumente, die Wörter enthalten: refund AND policy. Eine Vektordatenbank findet Einträge, deren Bedeutung nahe ist: die Anfrage "wie bekomme ich mein Geld zurück" liefert die Passage mit dem Titel "Rückgaben und Erstattungen", obwohl beide kein Wort gemeinsam haben.

Die letzte Zeile zeigt, wie verschwommen die Kategorie ist. pgvector fügt Vektorspalten und einen HNSW-Index zu einem gewöhnlichen Postgres hinzu, und Elasticsearch trägt seit Version 7.0 im Jahr 2019 ein Vektorfeld und seit 8.0 im Jahr 2022 HNSW-Suche. Eine "Vektordatenbank" ist oft eine Fähigkeit innerhalb einer Datenbank, die man bereits betreibt, statt ein neues Produkt, und die eigenständigen Produkte konkurrieren bei Skalierung und Betriebsreife, nicht dabei, etwas zu können, was Postgres nicht kann.

Chat-mit-Dokumenten ist eine Vektorsuche mit einem Modell am Ende

Retrieval-Augmented Generation, das was ist RAG durchgeht, hat einen Suchschritt und einen Schreibschritt. Die Vektordatenbank ist der Suchschritt.

1. Jedes Dokument in Passagen von einigen hundert bis tausend Tokens aufteilen.
2. Jede Passage einbetten und die Vektoren zusammen mit dem Passagentext und seiner Quelle in der Vektordatenbank speichern.
3. Wenn eine Frage eintrifft, sie einbetten und die Datenbank nach den nächstgelegenen Passagen fragen.
4. Diese Passagen zusammen mit der Frage an das Sprachmodell übergeben und es die Antwort schreiben lassen.

Schritte 1 und 2 passieren einmal, wenn die Dokumente hinzugefügt werden. Schritte 3 und 4 passieren bei jeder Frage. Das Sprachmodell sieht nie die gesamte Sammlung, sondern nur die fünf oder zehn Passagen, die die Datenbank ausgewählt hat. Deshalb ist die Antwort nur so gut wie die Suche: Wenn der nächstgelegene Vektor die falsche Passage ist, beantwortet das Modell selbstsicher die falsche Frage, was was ist eine KI-Halluzination als einen Treffer der Suche einordnet, nicht als Erfindung.

Wann man eine braucht und wann die ganze Datei besser ist

Die Entscheidung geht um Größe. Ein Modell kann jeweils nur sein Kontextfenster berücksichtigen, und jedes Token darin wird bei jeder Runde bezahlt. Eine Vektordatenbank existiert, um nur den relevanten Ausschnitt vor das Modell zu legen. Für ein einzelnes Dokument, das passt, ist Retrieval ein Schritt, den man überspringen kann; für eine Sammlung, die nicht passt, ist es die einzige Option.

Man vergleiche die beiden Designs an einem 300.000-Token-Bericht, mehreren hundert Seiten, mit zehn gestellten Fragen und fünf abgerufenen 1.000-Token-Passagen pro Frage. Die ganze Datei jedes Mal zu senden, sind 3 Millionen Eingabe-Tokens. Fünf Passagen zu je 1.000 Tokens pro Frage abzurufen, sind 50.000. Bei den Listenpreisen im AI Modell-Preisindex, abgerufen von OpenRouter am 2026-08-20, beträgt die Spanne 60x bei jedem Modell. Prompt-Caching, wo der Anbieter es bietet, berechnet ein erneutes Lesen derselben Datei zu einem Zehntel bis der Hälfte des Listenpreises, was die Spanne auf etwa 6x bis 30x verringert. Retrieval gewinnt weiterhin, nur weniger deutlich.

Das Design mit der ganzen Datei bringt für dieses Geld etwas, wenn die Datei ins Budget passt: Ein 60-seitiger Vertrag, etwa 40.000 Tokens, erlaubt dem Modell, Fragen zu beantworten, die das gesamte Dokument auf einmal brauchen, etwa "widerspricht hier etwas Klausel 14", was Retrieval nicht kann, weil es Klausel 14 und den Widerspruch nie im selben Durchgang sieht. Die Regel, die sich daraus ergibt: Ein Dokument oder eine Handvoll geht vollständig hinein; eine Bibliothek geht durch eine Vektordatenbank. Zwischen den beiden teilt man den Upload nach Thema auf, damit das Modell den Abschnitt bekommt, den es braucht.

Whizi sendet den Text selbst, bis zu einer 40.000-Token-Runde

Whizi betreibt für den Chat keine Vektordatenbank. Wenn man eine Datei anhängt, extrahiert der Dokument-Upload-Pfad den Text und sendet ihn dem Modell als Prompt-Text, bis zu einem festen Budget von 40.000 Tokens pro Runde; ein längerer Upload wird gekürzt, mit einem Hinweis und einem Vermerk in der Nachricht. Projektdateien funktionieren genauso: Die Projekte-Funktion pinnt bis zu 10 Dateien und baut ihren Text bei jeder Nachricht neu in den Prompt ein, begrenzt auf 32.000 Zeichen pro Datei und 120.000 für den gesamten Projektblock.

Die Grenzen sind der Rand des Designs. Eine gepinnte Datei über 32.000 Zeichen wird gekürzt, ein Anhang über das 40.000-Token-Rundenbudget wird abgeschnitten, und ein Projekt ist ein Ordner, keine durchsuchbare Bibliothek. Der Kompromiss ist bewusst: Für einen Vertrag oder ein Paper, das ins Rundenbudget passt, ist es besser, den Text vorliegen zu haben, als ihn zu durchsuchen, und der Test, der zählt, das Modell zu bitten, die verwendete Passage zu zitieren, funktioniert, weil die Passage vorhanden ist. Für tausend Dokumente ist eine Vektordatenbank das richtige Werkzeug und eine Chat-App das falsche.

Zwei Gewohnheiten ergeben sich aus dem Mechanismus. Man nennt die Datei einmal in der Frage, sobald mehrere angehängt sind, denn sonst wählt das Modell stillschweigend aus. Und bei jeder Antwort, nach der man handeln wird, fragt man nach dem Zitat. Ein Retrieval-System kann die falsche Passage liefern; ein System mit der ganzen Datei kann aus dem Gedächtnis statt aus der Datei antworten. Das Zitat fängt beides ab.