Vektorspeicher
Warum dieser Schritt
Warum Vektoren neben Tabelle und Graph
Der Wissensgraph liefert strukturiertes Wissen. Für Fragen, die in Worten statt in Entitäten gestellt werden, braucht es einen zweiten Zugang: die Vektoren.
Bisher sind die Daten der Email zweimal abgelegt worden: in MariaDB als strukturierte Zeilen und in ArangoDB als Knoten und Kanten. Eine Frage wie "Welche Mails sprechen inhaltlich von etwas Ähnlichem wie diese hier" lässt sich aber weder per JOIN noch per Pfad-Suche zuverlässig beantworten. Genau dafür gibt es die dritte Datenbank: Qdrant für Vektoren. Vier Bausteine im Überblick.
Was Vektoren bedeuten
Ein Vektor ist eine Liste von Zahlen, in diesem System konkret 1024 Fließkommazahlen pro Textstück. Die Idee dahinter: ähnliche Texte werden in ähnliche Zahlenlisten übersetzt. Zwei Mails über Rechnungs-Probleme bekommen Vektoren, die rechnerisch nah beieinander liegen, auch wenn die genauen Worte verschieden sind.
Wer in einer Tabelle nach dem Wort "Reklamation" sucht, findet nur Mails, die genau dieses Wort enthalten. Wer per Vektor sucht, findet auch Mails über "Beschwerde", "Probleme" oder "Unzufriedenheit", weil diese Wörter inhaltlich nahe beieinander liegen. Die Suche basiert auf Bedeutung, nicht auf Buchstaben.
Wozu Vektoren in dieser Pipeline
Die Vektoren sind die technische Grundlage für Retrieval Augmented Generation, kurz RAG. Wenn das System eine Antwort auf eine eingehende Email vorbereitet, sucht es zuerst nach inhaltlich verwandten früheren Mails. Diese Suche läuft über Vektoren, nicht über Stichworte.
Das Ergebnis: das Sprachmodell bekommt nicht nur die aktuelle Email zu sehen, sondern auch die thematisch passende Vorgeschichte. Wer schreibt heute nach drei Monaten zum zweiten Mal wegen derselben Sache, bekommt eine Antwort, die Bezug auf die erste Mail nimmt, ohne dass jemand sich die Verbindung gemerkt hätte.
Der zweite Anwendungsfall ist die Suche in der Bedien-Oberfläche. Wer alle Mails zu einem Thema finden möchte, kann eine Beispielfrage eintippen und bekommt die passenden Mails sortiert nach Ähnlichkeit, nicht nach Datum.
Drei Datenbanken, drei Aufgaben
Mit Qdrant ist die Drei-Datenbanken-Architektur komplett. Jede der drei hat ihre spezifische Stärke und ihre Aufgabe.
- MariaDB: strukturierte Daten in Tabellen mit JOINs. Quelle der Wahrheit für alles, was Felder und feste Beziehungen hat: Mails, Klassifikationen, Threads, Entitäten, Beziehungen.
- ArangoDB: Graph-Datenbank für Pfad-Suchen über Knoten und Kanten. Spiegelt einen Teil der MariaDB-Daten in einer anderen Form.
- Qdrant: Vektor-Datenbank für Ähnlichkeitssuche im Bedeutungsraum. Speichert Vektoren und liefert die rechnerisch nächsten zu einer gegebenen Anfrage.
Drei Datenbanken bedeuten auch drei Wartungs-Themen, drei Backup-Strategien, drei Quellen für Fehler. Die Aufteilung lohnt sich, wenn die Stärken der drei wirklich genutzt werden. Im email2rag-System ist das der Fall: relationale Auswertungen, Graph-Traversierungen und Vektor-Suchen sind alle drei Teil des Alltags.
an fester Position in der Pipeline in der Pipeline
Der ChunkStep ist Pipeline-an fester Position in der Pipeline, nach GraphSync und vor Wissens-Schritt/Entwurfs-Schritt. An dieser Stelle sind alle inhaltlichen Daten der Email schon vorbereitet: Klassifikation, Entitäten, Beziehungen, Graph-Eintrag. Was fehlt, sind die Vektoren, damit später bei einer Antwort-Generierung passende frühere Mails gefunden werden können.
Im Schritt selbst passieren zwei Dinge nacheinander: erst wird der Body-Text in Stücke zerlegt (Chunking) und in MariaDB abgelegt, dann werden die Stücke einzeln in Vektoren übersetzt und in Qdrant geschrieben (Embedding). Kurz gesagt: ein Embedding übersetzt Text in eine Zahlenfolge, in der rechnerisch gemessen werden kann, wie ähnlich sich zwei Texte sind. Beide Teile werden in den nächsten Unterkapiteln ausführlich gezeigt.
Eine Besonderheit: scheitert das Embedding (Qdrant nicht erreichbar, Embedding-Modell nicht erreichbar), markiert der Schritt die Email als partially_indexed statt indexed. Die Chunks selbst sind dann zwar in MariaDB, aber nicht im Vektorraum. Eine spätere Wiederholung kann die Lücke füllen, ohne den Chunk-Vorgang zu wiederholen.