Ähnlich statt gleich
Eine klassische Datenbank beantwortet Fragen nach exakter Übereinstimmung: Gib mir alle Meetings mit dem Kunden „Gruber“ aus dem März. Entweder ein Eintrag passt, oder er passt nicht.
Eine Vektordatenbank beantwortet eine andere Art von Frage: Welche Einträge sind dieser Anfrage am ähnlichsten? Dafür werden Texte vorher in Embeddings umgewandelt. Die Anfrage wird ebenfalls zum Vektor, und die Datenbank sucht die Vektoren, die ihm am nächsten liegen – die sogenannten nächsten Nachbarn. Das Ergebnis ist keine Ja-Nein-Liste, sondern eine Rangfolge nach Ähnlichkeit.
Klassische Datenbank und Vektordatenbank im Vergleich
Beide haben ihren Platz und werden oft gemeinsam eingesetzt:
| Klassische Datenbank | Vektordatenbank | |
|---|---|---|
| Speichert | Felder wie Name, Datum, Betrag | Zahlenvektoren plus Verweis auf das Original |
| Sucht nach | exakter Übereinstimmung, Bereichen, Filtern | Bedeutungsähnlichkeit |
| Ergebnis | Treffer oder kein Treffer | Rangliste der ähnlichsten Einträge |
| Typische Frage | „Alle Rechnungen über 1.000 € im Mai“ | „Stellen, an denen es um Preisbedenken ging“ |
Wie die Suche schnell bleibt
Bei ein paar tausend Einträgen könnte man jede Anfrage einfach mit allen Vektoren vergleichen. Bei Millionen wird das zu langsam. Vektordatenbanken nutzen deshalb spezielle Indizes für die ungefähre Nächste-Nachbarn-Suche (englisch Approximate Nearest Neighbor, ANN). Ein verbreitetes Verfahren heißt HNSW: Es baut ein Netz aus Verbindungen zwischen ähnlichen Vektoren auf, durch das sich die Suche in wenigen Sprüngen zum Ziel hangelt.
Der Kompromiss: Die Suche ist um ein Vielfaches schneller, findet aber nicht in jedem Fall garantiert den allerbesten Treffer, sondern einen sehr guten. Für die meisten Anwendungen ist das kein Problem, und die Genauigkeit lässt sich über Einstellungen gegen Geschwindigkeit abwägen.
Was neben dem Vektor gespeichert wird
Ein Vektor allein ist wenig wert – man muss auch wissen, wofür er steht. Deshalb speichert eine Vektordatenbank zu jedem Eintrag den Originaltext oder einen Verweis darauf und dazu Metadaten: Datum, Quelle, Kunde, Projekt, Sprache und vor allem Zugriffsrechte.
Diese Metadaten sind entscheidend für gute Ergebnisse. Eine Anfrage kann dann lauten: „Finde die ähnlichsten Stellen, aber nur aus Meetings mit Kunde Gruber seit Jänner, und nur aus Meetings, die diese Person sehen darf.“ Ohne solche Filter liefert die Ähnlichkeitssuche womöglich Treffer aus dem falschen Projekt – oder aus Daten, die die fragende Person gar nicht sehen dürfte.
Eigenes System oder Erweiterung
Es gibt spezialisierte Vektordatenbanken, aber auch Erweiterungen für bestehende Systeme. Für die verbreitete Datenbank PostgreSQL etwa gibt es die Erweiterung pgvector, und viele Suchmaschinen haben inzwischen eine Vektorsuche eingebaut. Für kleinere Projekte ist eine Erweiterung oft einfacher, weil Daten, Rechte und Backups an einem Ort bleiben.
Und manchmal braucht es gar keine: Bei kleinen Datenmengen oder wenn Nutzer:innen ohnehin nach exakten Begriffen suchen, ist Volltextsuche einfacher und oft besser. Viele Systeme kombinieren beides zur hybriden Suche.
Das Support-Team der Softwarefirma Leitner speichert alle gelösten Tickets als Embeddings in einer Vektordatenbank, mit Produkt und Version als Metadaten.
Ein neues Ticket lautet: „Nach dem Update komme ich nicht mehr ins Programm.“ Die Datenbank liefert als ähnlichste Fälle „Anmeldung scheitert seit Version 3.2“ und „Login-Fehler nach Aktualisierung“ – obwohl kaum ein Wort übereinstimmt. Der Filter auf das richtige Produkt sorgt dafür, dass keine Fälle aus einer anderen Software auftauchen.
Dieser Eintrag dient der allgemeinen Information und ersetzt keine individuelle Beratung.