Fragen Sie eine gewöhnliche Datenbank, ob der Kunde „seinen Hund mitbringen darf", findet sie nichts, es sei denn, jemand hat genau diese Worte zuvor irgendwo niedergeschrieben. Fragen Sie einen KI-Chatbot dasselbe, antwortet er korrekt, selbst wenn die Website des Unternehmens nur eine „Haustierrichtlinie" erwähnt. Der Unterschied liegt nicht im Modell, das die Antwort erzeugt. Er liegt in der Schicht, die die richtige Information findet, bevor das Modell überhaupt ins Spiel kommt: einer Vektordatenbank.
Das ist kein Detail. Es ist das Fundament, auf dem jede KI-Lösung ruht, die präzise auf Basis der eigenen Daten eines Unternehmens antworten soll.
Was eine Vektordatenbank eigentlich ist
Eine Vektordatenbank speichert Text nicht so, wie es eine gewöhnliche Datenbank tut. Sie speichert die Bedeutung des Textes, übersetzt in ein langes Zahlen-Array, einen Vektor. Das geschieht mithilfe eines Embedding-Modells, das ein Textstück liest und es an einer bestimmten Stelle in einem mehrdimensionalen Raum platziert, wo Texte mit ähnlicher Bedeutung nah beieinander landen, unabhängig davon, welche Wörter tatsächlich verwendet wurden.
„Darf ich meinen Hund mitbringen?" und „Wie lautet eure Haustierrichtlinie?" haben kein einziges Wort gemeinsam. Aber sie bedeuten im Wesentlichen dasselbe, und deshalb landen sie in diesem Raum nah beieinander. Genau diese Eigenschaft macht semantische Suche möglich: Man sucht nach Bedeutung, nicht nach Buchstaben.
Wenn ein Nutzer eine Frage stellt, wird die Frage selbst auf dieselbe Weise in einen Vektor umgewandelt. Die Datenbank findet dann die Vektoren in ihrer Sammlung, die am nächsten liegen — in der Praxis als Nearest-Neighbor-Suche bezeichnet — und gibt den Inhalt zurück, den diese Vektoren repräsentieren. Das sind die paar Millisekunden, von denen die gesamte Erfahrung abhängt.
Warum eine gewöhnliche Datenbank das nicht kann
Eine relationale Datenbank ist hervorragend darin, etwas nachzuschlagen, wenn man den genauen Namen, die ID oder das Schlagwort bereits im Voraus kennt. Sie ist für exakte Treffer und strukturierte Felder gebaut.
Das Problem ist, dass echte Menschen nicht mit den Worten fragen, die tatsächlich in der Dokumentation stehen. Ein Kunde schreibt „kann ich mein Geld zurückbekommen", nicht „Rückgaberichtlinie, Absatz 3". Ein Mitarbeiter sucht „wie lösche ich einen Benutzer", nicht den exakten Seitentitel im internen Wiki. Schlagwortsuche erfordert, dass der Fragende bereits die Sprache der Antwort kennt. Semantische Suche erfordert nur, dass der Fragende seine eigene Absicht kennt.
Deshalb kann man keinen KI-Assistenten bauen, der die Inhalte eines Unternehmens wirklich versteht, allein auf Basis einer gewöhnlichen Datenbank. Man kann Volltextsuche und Fuzzy-Matching hinzufügen, aber man flickt damit immer noch an einem System herum, das grundsätzlich nach Buchstaben sucht, nicht nach Bedeutung.
So wird es in der Praxis eingesetzt: RAG
Der häufigste Weg, wie eine Vektordatenbank in einer KI-Lösung genutzt wird, ist als Teil eines RAG-Setups, Retrieval-Augmented Generation. Die Idee ist einfach: Statt ein Sprachmodell zu bitten, im Voraus alles über ein Unternehmen zu „wissen", gibt man ihm genau dann den richtigen Kontext, wenn es ihn braucht.
Kurz gesagt passieren vier Dinge: Die Inhalte des Unternehmens werden in kleinere Teile zerlegt und in Vektoren umgewandelt (Ingest und Embedding), eine Frage wird mit diesen Vektoren abgeglichen, um die relevantesten Teile zu finden (Retrieval), die besten Ergebnisse werden nach Relevanz sortiert (Rerank), und schließlich werden sie zusammen mit der eigentlichen Frage an ein Sprachmodell gesendet, damit das Modell eine Antwort auf Basis der tatsächlichen Inhalte des Unternehmens formulieren kann, statt zu raten.
Die Vektordatenbank ist die Schicht, die den Retrieval-Teil ermöglicht. Ohne sie gibt es nichts, womit das Modell arbeiten könnte, und man landet wieder bei einem Modell, das aus allgemeinem Wissen antwortet, nicht aus Ihren Daten.
Visuell dargestellt sieht der Ablauf so aus:
flowchart TD
A[Virksomhedens indhold] -->|Ingest og embedding| D[(Vektordatabase)]
E[Brugerens spørgsmål] -->|Embedding| F[Spørgsmåls-vektor]
F -->|Finder nærmeste match| D
D --> G[Mest relevante stykker]
G --> H[Rerank efter relevans]
H --> I[Sprogmodel]
E --> I
I --> J[Svar til brugeren]Der Teil, der tatsächlich Zeit kostet
Was auf dem Papier einfach aussieht, wird in der Produktion schnell komplex. Wie viele Vektoren kann das System verarbeiten, bevor die Suche langsam wird? Wie hält man Daten verschiedener Kunden oder Projekte voneinander isoliert? Was passiert mit den Kosten, wenn die Datenmenge von tausend auf zehn Millionen Inhaltsstücke wächst? Und wie aktualisiert man den Index laufend, ohne dass die Suche währenddessen ausfällt?
Keine dieser Fragen ist für jemanden interessant, der einfach nur eine schnelle und korrekte Antwort will. Aber genau darauf verwenden die meisten Teams die meiste Zeit, wenn sie ihr erstes KI-Produkt bauen: nicht auf das Produkt selbst, sondern auf die Infrastruktur darunter.
Wo es eingesetzt wird
In der Praxis tauchen Vektordatenbanken immer dann auf, wenn eine KI-Lösung etwas Spezifisches wissen muss, das das Modell während des Trainings nicht gelernt hat: ein KI-Chatbot, der auf Basis der eigenen Website oder Dokumentation eines Unternehmens antworten soll. Eine interne Suchmaschine, die den richtigen Fall unter Tausenden früherer Vorgänge findet. Ein Support-Tool, das die richtige Antwort in einem Produkthandbuch in Sekundenschnelle findet. Allen gemeinsam ist, dass die Antwort irgendwo in den eigenen Inhalten des Unternehmens existiert — es geht nur darum, die richtige Stelle schnell zu finden.
Wir haben kürzlich ein konkretes Beispiel dafür bei einem unserer Kunden gesehen, wo damit die gesamte Unternehmenswebsite automatisch und ohne manuelle Einrichtung in einen durchsuchbaren KI-Chat verwandelt wird.
Es muss nicht Ihr Problem sein, das zu lösen
Diese Infrastruktur selbst zu bauen und zu betreiben bedeutet in der Regel drei Entscheidungen gleichzeitig: welche Vektordatenbank, wie sie betrieben wird, und wie sie skaliert werden soll, wenn Daten oder Traffic wachsen. Genau für diese Schicht haben wir bei Liviate eine Managed-Lösung gebaut: eine gehostete Vektordatenbank, produktionsbereit ab dem ersten Tag, in mehreren Stufen je nach Bedarf, von einer kostenlosen Option für den Einstieg bis hin zu dedizierter Infrastruktur für alle, die mehr Isolation oder Kapazität benötigen.
Möchten Sie wissen, ob das für Sie relevant ist? Schreiben Sie uns, und lassen Sie uns besprechen, wo Sie starten könnten.