Zum Inhalt springen

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.

Textstück"Die Rechnung war fehlerhaft"
Vektor: 1024 Zahlen[0.12, -0.04, 0.88, ...]
Inhaltlich ähnlich"Reklamation zur Rechnung"
Vektor liegt nah[0.10, -0.03, 0.85, ...]
Stichwortsuche: nur exakt"Rechnung" findet nur "Rechnung"
Vektor-Suche: nach Bedeutungfindet auch "Beschwerde", "Problem"
Suche nach Bedeutung statt nach 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.

Anwendung 1: RAG für Antwortenaktuelle Mail + ähnliche frühere Mails
Aktuelle EmailVektor wird gebildet
Kontext fürs LLMVorgeschichte mitliefern
Anwendung 2: Suche per Beispielfragein Bedien-Oberfläche
Treffer sortiert nach Ähnlichkeit

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.

MariaDBTabellen + JOINs
ArangoDBKnoten + Kanten
QdrantVektoren + Ähnlichkeit
Quelle der Wahrheitstrukturierte Daten
SpiegelungGraph-Anfragen
BedeutungsraumRAG-Suche
Drei Wartungs-Themen, drei StärkenAufteilung lohnt sich, wenn alle drei genutzt werden

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.

9 GraphSyncin den Graph
10 Chunkin Vektoren - hier
11 RagKontext aufbauen
12 DraftAntwort entwerfen
Teil 1: Chunkingin MariaDB
Teil 2: Embeddingin Qdrant
Status: indexedbeides erfolgreich
Status: partially_indexedChunks da, Vektoren fehlen
Wiederholung füllt Lücke ohne erneutes Chunkinggetrennte Phasen helfen bei Recovery