Wissensgraph

Warum dieser Schritt

Warum ein Wissensgraph neben der Datenbank

Bisher wurden Entitäten und Beziehungen in der relationalen Datenbank MariaDB abgelegt. Das funktioniert für einzelne Mails gut, hat aber Grenzen, sobald Fragen wie "Welche Personen sind über drei Ecken mit Karl verbunden" beantwortet werden sollen. Genau für solche Fragen gibt es den Wissensgraphen in ArangoDB. Dieses Unterkapitel zeigt, was ein Wissensgraph überhaupt ist, warum er als zweite Datenbank parallel zur ersten gepflegt wird, was vom Pipeline-Schritt dort hineingeschrieben wird und wo der Schritt in der Pipeline steht.

Was ein Wissensgraph ist

Ein Graph besteht aus zwei Sorten von Dingen: Knoten und Kanten. Knoten sind die Datenpunkte, hier die Entitäten. Kanten sind die Verbindungen zwischen ihnen, hier die Beziehungen. Eine Beziehung "Anna Schmidt arbeitet bei Müller GmbH" wird zur Kante zwischen dem Knoten "Anna Schmidt" und dem Knoten "Müller GmbH", beschriftet mit "arbeitet_bei".

Was den Graphen besonders macht, ist die Möglichkeit, beliebige Pfade zwischen Knoten zu verfolgen. Frage: "Wer arbeitet bei einer Firma, die ihren Sitz in derselben Stadt hat wie Karl?" Im Graphen ist das eine Pfad-Suche von Karl zu seiner Stadt, dann zu allen Firmen in dieser Stadt, dann zu allen Personen, die bei einer dieser Firmen arbeiten. In einer relationalen Datenbank wäre dieselbe Frage eine Kette aus drei JOINs, die mit jedem zusätzlichen Schritt langsamer wird.

Warum ArangoDB neben MariaDB

MariaDB ist eine relationale Datenbank, in ihrem Element bei klar strukturierten Tabellen mit festen Spalten und vorhersehbaren JOINs. ArangoDB ist eine Multi-Modell-Datenbank, die unter anderem Graphen nativ kann: jeder Knoten ist ein Dokument, jede Kante ein Dokument mit zwei besonderen Feldern _from und _to, die auf andere Dokumente zeigen.

Aus diesem Unterschied ergibt sich eine klare Aufgabenteilung. MariaDB bleibt die Quelle der Wahrheit für alle relationalen Daten: Mails, Klassifikationen, Threads, Entitäten, Beziehungen. ArangoDB bekommt eine Kopie der Knoten und Kanten in einer Form, die sich für Graph-Anfragen eignet. Wer die Graph-Datenbank löschen würde, könnte sie aus den MariaDB-Tabellen jederzeit neu aufbauen.

Mehrere spezialisierte Datenbanken sind also im Spiel: MariaDB für strukturierte Daten, ArangoDB für den Graphen, und Qdrant für die Vektoren (das nächste Kapitel). Jede macht das, wofür sie gebaut ist, und sie ergänzen sich gegenseitig.

Was in den Graphen reinkommt

Der GraphSyncStep schreibt nicht alle Daten der Email in den Graphen, sondern genau zwei Sorten: die Entitäten dieser Email als Knoten in die Sammlung entities, und die Beziehungen dieser Email als Kanten in die Sammlung relations. Andere Daten wie Mail-Inhalt, Klassifikation oder Status bleiben ausschließlich in MariaDB.

Pro Email passieren also potenziell zwei Schreibvorgänge in ArangoDB: einer für die Knoten, einer für die Kanten. Beide laufen gegeneinander unabhängig, beide werden übersprungen, wenn das jeweilige Eingangs-Array leer ist. Eine Email ohne Entitäten erzeugt keinen Graph-Schreibvorgang, eine Email mit Entitäten aber ohne Beziehungen erzeugt nur Knoten-Updates, keine Kanten-Updates.

an fester Position in der Pipeline in der Pipeline

Der GraphSyncStep ist Pipeline-an fester Position in der Pipeline. Vor ihm: Parse, Attachment, Contact, Thread, Rule, Classify, Ner, Relations. Nach ihm: Chunk, Rag, Draft. Diese Position ist die natürliche Folge: er braucht die Entitäten aus dem NerStep und die Beziehungen aus dem RelationsStep, und er liest beide direkt aus MariaDB nach (nicht aus dem Zusammenhang aus vorherigen Schritten).

Die Wahl, beide Datensorten frisch aus MariaDB zu holen statt aus dem Kontext zu nehmen, hat einen Vorteil: der GraphSync sieht garantiert die persistierten Daten, also genau das, was auch dauerhaft in MariaDB steht. Wenn der RelationsStep aus irgendeinem Grund eine Beziehung nicht persistiert hat (zum Beispiel wegen fehlender Entitäts-Endpunkte), taucht sie auch nicht im Graphen auf. MariaDB bleibt die Quelle der Wahrheit, ArangoDB ist die Spiegelung.

Damit ist klar, wofür der Wissensgraph existiert und wo der Schritt in der Pipeline steht. Im nächsten Unterkapitel sehen wir konkret, wie die Entitäten aus MariaDB gelesen und in den Graph geschrieben werden.