Vector Database
Eine Datenbank, die Text als numerische Vektoren speichert, sodass du nach Bedeutung statt nach exakten Stichwörtern suchen kannst. Die Retrieval-Engine, auf der die meisten RAG-Systeme laufen.
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.
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.