Vector Database
Eine Datenbank, die Text als Vektoren speichert, damit du nach Bedeutung statt nach Stichwörtern suchst. Die Retrieval-Engine der meisten RAG-Systeme.
Eine Vektordatenbank speichert Embeddings: numerische Repräsentationen von Text (oder Bildern oder Audio), bei denen ähnliche Bedeutung auf nahe Punkte im Raum abgebildet wird. Statt exakte Stichwörter abzugleichen, bettest du die Nutzeranfrage auf dieselbe Weise ein und fragst die Datenbank nach den nächstgelegenen Vektoren. Das ist Ähnlichkeitssuche, und sie lässt ein System “wie kündige ich meinen Tarif” finden, wenn im Dokument eigentlich “Vorgang zur Abo-Beendigung” steht.
In einer RAG-Pipeline ist das die Retrieval-Schicht. Die Qualität deiner Antworten hängt stark davon ab: gute Embeddings und gute Suche liefern die richtigen Chunks ans Modell, schlechte liefern Müll, und das Modell fasst diesen Müll überzeugt zusammen. Deshalb entscheidet meist das Retrieval, nicht das Modell, über Erfolg oder Scheitern eines RAG-Projekts.
Hier der Teil, den Anbieter überspringen: Oft brauchst du gar keine dedizierte Vektordatenbank. Ist dein Korpus klein (Tausende, nicht Millionen Chunks), ist eine Vektor-Erweiterung auf dem ohnehin laufenden Postgres (pgvector) einfacher, billiger und ein System weniger zu betreiben. Ist deine Suche vorwiegend stichwortgetrieben, schlägt schlichte Volltextsuche die Vektorsuche unter Umständen klar. Greife zur spezialisierten Vektor-DB, wenn Skalierung, Latenz oder hybride Suche bei hohem Volumen es tatsächlich rechtfertigen, nicht weil sie im Architekturdiagramm steht.
Praxisbeispiel fürs Over-Engineering: Ein Team baut einen internen Doku-Assistenten über ein paar tausend Seiten und greift zu einer gemanagten Vektordatenbank, einer separaten Embedding-Pipeline und einem Reranking-Service, bevor es einen einzigen Nutzer hat. Es betreibt jetzt vier Systeme, um Fragen zu beantworten, die pgvector auf dem bestehenden Postgres erledigt hätte, und jedes davon ist eine neue Sache zum Überwachen, Absichern und Bezahlen. Die langweilige Variante geht in einer Woche live und skaliert gut, bis der Korpus wirklich groß wird. Greife zur spezialisierten Datenbank, wenn die Zahlen es erzwingen (Millionen Vektoren, harte Latenzbudgets, hybride Suche bei hohem Volumen), nicht weil das Architekturdiagramm seriöser aussieht.
Wir wählen bewusst die ausreichend langweilige Option unter Künstliche Intelligenz , denn jedes zusätzliche System ist eine weitere Sache, die man um 3 Uhr morgens am Leben halten muss.