In Schritt 5 hatte MySQL mein erstes großes Problem gelöst: Informationen konnten endlich dauerhaft gespeichert werden. Doch ziemlich schnell tauchte das nächste Problem auf – und es war im Grunde eine weitaus schwierigere Frage.
Menschen stellen dieselbe Frage nicht immer mit denselben Wörtern. Wenn ich einen Begriff als Suchbegriff in meiner Datenbank ablege, heißt das noch lange nicht, dass ein Benutzer später genau diesen Begriff verwendet. Damit wurde aus der technischen Frage „Wie speichere ich Wissen?“ plötzlich die eigentliche Frage: „Wie finde ich das richtige Wissen wieder?“
Bevor ich diesen Gedanken weiter vertiefe, ein kurzer Hinweis für alle, die bereits mit semantischer Suche oder Vektoren arbeiten: Wenn du direkt zu meinem nächsten großen Denkfehler springen möchtest, dann findest du weiter unten im Text einen Ausblick auf Schritt 7. Dort erzähle ich, warum ich danach versuchte zu verstehen, wie eine Chat-KI eigentlich arbeitet.
Warum eine normale Suche an ihre Grenzen kommt
Nehmen wir ein einfaches Beispiel aus meinem eigenen Projekt. In der Datenbank steht:
„Eine Grafikkarte mit mehr VRAM kann größere lokale Modelle aufnehmen.“
Ein Benutzer fragt aber: „Warum kann ich auf meiner 8-GB-Karte manche Modelle nicht laden?“
Die Wörter sind komplett verschieden, der Zusammenhang ist aber eindeutig. Eine klassische Datenbanksuche nach exakt gleichen Begriffen übersieht so etwas schnell. Das liegt nicht daran, dass relationale Datenbanken grundsätzlich keine flexiblen Suchen können – sie sind dafür nicht gebaut. Für Bedeutung und Ähnlichkeit braucht es einen anderen Ansatz.
Der Begriff Embedding
Irgendwann stieß ich auf den Begriff Embedding. Zunächst hörte er sich nach komplizierter Mathematik an, aber das Prinzip ist im Kern erstaunlich einfach: Ein Text wird in eine Reihe von Zahlen übersetzt. Diese Zahlenreihe soll nicht den Wortlaut speichern, sondern grob die Eigenschaften beziehungsweise die Bedeutung des Textes abbilden. Texte mit ähnlicher Bedeutung liegen im Zahlenraum dann näher beieinander.
Wer jetzt an Formeln denkt: Nein, darum geht es nicht. Wichtig ist nur das Grundprinzip, dass Wörter und Sätze über Zahlen vergleichbar werden – und zwar über ihre Bedeutung, nicht über ihre Schreibweise.
Was ist ein Vektor?
Diese Zahlenreihe nennt man Vektor. Für mein System war die Mathematik dahinter zunächst zweitrangig. Entscheidend war, dass ich Texte nicht mehr nur darüber vergleichen konnte, ob dieselben Wörter vorkommen, sondern ob sie ähnlich klingen und ähnlich gemeint sind. Dadurch wurde ein Stück weit das erreicht, was ich mir gewünscht hatte.
Die erste Begeisterung
Ich war überrascht, wie gut das funktionierte. Plötzlich konnte mein System zu einer Frage Inhalte finden, bei denen kein einziges Wort identisch war. Das fühlte sich an, als hätte das Wissenssystem endlich ein Gedächtnis bekommen. Die anfängliche Euphorie hielt allerdings nicht lange an.
Dann kam die nächste Ernüchterung
Je mehr Inhalte ich auf Basis dieser Vektoren speichern wollte, desto deutlicher wurden die Kosten des Ansatzes:
- Ich brauchte mehr Speicherplatz, weil zu jedem Text zusätzlich der Vektor gespeichert werden musste.
- Die Erzeugung der Embeddings kostete Rechenzeit.
- Die Datenbankstruktur wurde komplexer.
- Und ich musste Regeln festlegen, welche Inhalte ich überhaupt als Vektor ablegen wollte.
Natürlich sind Vektordatenbanken nicht grundsätzlich ineffizient – das möchte ich hier betonen. Aber ich hatte anfangs unterschätzt, wie viel organisatorische Arbeit ein wachsender Wissensbestand mit sich bringt. Mehr gespeicherte Vektoren bedeuten nicht automatisch bessere Antworten.
Eine Vektordatenbank ist kein magisches Gedächtnis
Der wichtigste Punkt für mich war jedoch ein anderer: Eine Vektorsuche kann ähnliche Inhalte finden – aber sie weiß nicht, ob diese Information richtig, aktuell, vollständig oder vertrauenswürdig ist. Sie weiß auch nicht, ob sie für die konkrete Frage wirklich geeignet ist.
Man stelle sich vor, ich speichere eine veraltete Systemvoraussetzung oder einen Tippfehler. Die Vektorsuche findet diese Information trotzdem wunderbar – mehr noch, sie liefert sie als scheinbar passende Antwort. Eine gute Suche macht schlechte Daten nicht zu gutem Wissen. Das wurde mir in diesem Schritt schmerzhaft bewusst.
Die Datenbank musste sauberer werden
An diesem Punkt wurde mir klar: Ich kann nicht einfach immer mehr Text in die Datenbank werfen. Ich musste anfangen zu unterscheiden:
- Woher kommt eine Information?
- Worum geht es inhaltlich?
- Wie wurde sie gespeichert und in welcher Form?
- Gehört sie zu einem bestehenden Thema oder ist sie neu?
- Ist sie doppelt oder widerspricht sie sogar einem früheren Eintrag?
- Kann ich später noch nachvollziehen, warum sie dort liegt?
Aus der einfachen Sammlung von Texten wurde damit allmählich ein strukturierteres Wissenssystem.
Von MySQL zu einem anderen Datenbankaufbau
Mit der Zeit passte mein ursprünglicher Datenbankaufbau mit MySQL immer weniger zu dem, was ich inzwischen vorhatte. Ich begann deshalb, die Struktur weiterzuentwickeln und später auf PostgreSQL beziehungsweise einen besser geeigneten strukturierten Datenbankansatz umzusteigen. Das war keine grundsätzliche Abwertung von MySQL – es war die natürliche Folge eines Projekts, das aus der einfachen Speicherlösung herausgewachsen war.
Mehr Daten waren nicht automatisch besser
Am Anfang hatte ich angenommen, dass mehr Informationen automatisch ein besseres System ergeben. Doch je weiter ich kam, desto deutlicher wurde: Je größer der Wissensbestand ist, desto wichtiger werden Qualität, Struktur, Herkunft und Auswahl. Wenn mein System später aus zehntausenden Einträgen sucht, hilft es wenig, wenn niemand mehr weiß, warum ein bestimmter Eintrag entstanden ist.
Der nächste Gedanke
Spätestens hier stellte ich mir eine größere Frage: Wie macht eine moderne Chat-KI das eigentlich? Warum kann sie auf so viele unterschiedliche Formulierungen reagieren, ohne dass vorher jede einzelne Frage als Datenbankeintrag hinterlegt wurde?
Ich begann, mich intensiver damit zu beschäftigen, wie solche Systeme grundsätzlich arbeiten. Und natürlich kam irgendwann der Gedanke: Kann ich davon etwas selbst nachbauen?
Schritt 6 ist geschafft, wenn …
Wer diesen Schritt für sich durchgeht, hat keine fertige Installation vor sich, sondern eine Reihe von Erkenntnissen. Ich habe am Ende verstanden:
- Speichern und Wiederfinden sind zwei verschiedene Probleme.
- Dieselbe Bedeutung kann mit völlig unterschiedlichen Wörtern ausgedrückt werden.
- Embeddings können Texte nach Ähnlichkeit vergleichbar machen.
- Eine Vektorsuche ist ein Werkzeug, aber kein Verständnis.
- Schlechte Daten bleiben auch durch eine gute Suche schlecht.
- Mit wachsendem Wissen werden Struktur und Herkunft immer wichtiger.
- Mein System brauchte also mehr als nur eine immer größere Datenbank.
Das war für mich der Moment, an dem aus einer einfachen Datenbanksammlung langsam der Traum von einem eigenen Wissenssystem wurde. Im nächsten Schritt geht es genau dort weiter: Ich versuchte zu verstehen, wie eine Chat-KI eigentlich arbeitet – und warum Embeddings allein noch keine Intelligenz erzeugen. Vielleicht geht es dir ähnlich, wenn du den gleichen Weg gehst.