Grounding von LLMs mit Knowledge-Graphen
Fest geerdet
Veröffentlicht in Ausgabe 06/2024 - SCHWERPUNKT
Bei den ersten Prototypen von GenAI-Anwendungen steht das Grounding von LLMs auf der Prioritätenliste nicht unbedingt an oberster Stelle. Soll die GenAI im Unternehmen jedoch in die Produktion gehen, gewinnt die Frage nach der richtigen Datenbank schnell an Dringlichkeit. Das liegt an einem grundsätzlichen, inhärenten Problem von LLMs.
Damit die Modelle natürliche Sprache verarbeiten und generieren können, werden sie anhand eines umfangreichen Informationskorpus trainiert. Das Training ist in der Regel auf einen klar abgesteckten Zeitrahmen beschränkt. So gibt es immer Informationen, die dem LLM nicht zur Verfügung stehen – entweder weil sie nicht Teil der Trainingsdaten waren oder weil sie es noch nicht gab.
Grounding-Ansätze: RAG und Vektorsuche
Grounding – auch bekannt als Retrieval Augmented Generation (RAG) – versucht dieses Problem zu lösen. Es ergänzt LLMs mit zusätzlichen Daten und verbessert die Fähigkeit von GenAI, relevante, aktuelle und domänenspezifische Antworten zu generieren. Der RAG-Prozess nimmt die natürlichsprachliche Frage eines Nutzers an das LLM auf, erweitert sie um externe Informationen (zum Beispiel aus Unternehmensdatenbanken) und gibt beide als Gesamtpaket an das LLM zurück, das dann die finale Antwort aus der Frage und den Kontextinformationen erzeugt.
Bei den ersten Prototypen von GenAI-Anwendungen steht das Grounding von LLMs auf der Prioritätenliste nicht unbedingt an oberster Stelle. Soll die GenAI im Unternehmen jedoch in die Produktion gehen, gewinnt die Frage nach der richtigen Datenbank schnell an Dringlichkeit. Das liegt an einem grundsätzlichen, inhärenten Problem von LLMs.
Damit die Modelle natürliche Sprache verarbeiten und generieren können, werden sie anhand eines umfangreichen Informationskorpus trainiert. Das Training ist in der Regel auf einen klar abgesteckten Zeitrahmen beschränkt. So gibt es immer Informationen, die dem LLM nicht zur Verfügung stehen – entweder weil sie nicht Teil der Trainingsdaten waren oder weil sie es noch nicht gab.
Grounding-Ansätze: RAG und Vektorsuche
Grounding – auch bekannt als Retrieval Augmented Generation (RAG) – versucht dieses Problem zu lösen. Es ergänzt LLMs mit zusätzlichen Daten und verbessert die Fähigkeit von GenAI, relevante, aktuelle und domänenspezifische Antworten zu generieren. Der RAG-Prozess nimmt die natürlichsprachliche Frage eines Nutzers an das LLM auf, erweitert sie um externe Informationen (zum Beispiel aus Unternehmensdatenbanken) und gibt beide als Gesamtpaket an das LLM zurück, das dann die finale Antwort aus der Frage und den Kontextinformationen erzeugt.
Grounding stellt dabei nicht nur die Aktualität sicher, sondern hilft auch KI-Halluzinationen zu reduzieren, den Zugriff auf sensible Daten abzusichern und Security- und Compliance-Richtlinien zu erfüllen. Ein zeitraubendes und kostspieliges Re-Training (oder Fine-Tuning) der LLMs ist nicht nötig.
Als Standardtools zur Implementierung von RAG gelten Vektordatenbanken. Unstrukturierter Text – etwa PDFs oder Webseitentext – wird in Abschnitte zerlegt und diese in eine numerische Repräsentation (Vektor-Embeddings) umgewandelt, die die Essenz der Texte repräsentiert. Gespeichert in Vektordatenbanken ermöglichen die Vektoren eine effektive Ähnlichkeitssuche nach für die Frage relevanten Textabschnitten und helfen dem LLM, die Antwort zu präzisieren.
Grenzen von RAG mit Vektorsuche
Vektordatenbanken erlebten im letzten Jahr einen regelrechten Hype. Dafür gab es zwei Gründe: Sie sind schnell einzurichten und sie sind effektiv für GenAI-Experimente. In Folge integrierten die meisten Anbieter die Vektorsuche als eigene Features in ihre Datenbanken, darunter Oracle, MongoDB, Couchbase und Neo4j. Allerdings unterliegen auch Vektordatenbanken Grenzen:
- Die Vektorsuche liefert nur Informationen, die die Konzepte der ursprünglichen Frage repräsentieren.
- Vektor-RAG gestützte LLM-Anwendungen sind unfähig, Konzepte über den gesamten Datenbestand hinweg ganzheitlich zu verstehen.
- Sie sind nicht in der Lage, einen breiteren Kontext mit einzubeziehen, der für eine vollständige Antwort wesentlich ist.
Natürlich lassen sich RAG-Ansätze weiterentwickeln und verbessern. Allerdings steigt damit die Komplexität von Abfragen und der Ausführung, was wiederum eine leistungsfähige, flexible Datenbank voraussetzt, die mit dieser Komplexität umgehen kann.
Graphdatenbanken und Knowledge-Graphen
Genau hier kommen Graphdatenbanken und Knowledge-Graphen ins Spiel. Sie stellen eine effektive Datenbankumgebung dar, um die Qualität und Vollständigkeit der Grounding-Daten und damit auch der LLM Antworten zu verbessern. Das Datenmodell des Graphen stellt Entitäten, beispielsweise Objekte oder Personen, als Knoten und die Beziehungen zwischen ihnen als Kanten dar. Damit lassen sich Daten so speichern, wie sie in der realen Welt existieren. Beispiele sind alle Assets eines IT-Netzwerks oder sämtliche Produktionsschritte eines komplexen Endprodukts und die beteiligten Personen und Organisationen.
Ein weiterer Vorteil von Graphdatenbanken ist die Fähigkeit, sowohl strukturierte als auch unstrukturierte Informationen in einer strukturierten Repräsentation zu speichern. Dies ermöglicht Multi-Hop-Reasoning und schnelle Antworten auf komplexe Abfragen. Gleichzeitig sinkt der Aufwand beim Abfragen und Wiederauffinden von Informationen (Information Retrieval), was die Gesamtleistung weiter verbessert. Aufgrund dieser Eigenschaften und Flexibilität eignet sich ein Knowledge-Graph auch sehr gut für RAG-Anwendungen: Er verarbeitet verschiedene Datentypen, berücksichtigt dabei die Beziehungen zwischen Entitäten und bleibt dank des Knoten-Kanten-Modells nachvollziehbar und transparent.
Praxisbeispiel: LLM-Chatbot für App-Nutzer
Das folgende Beispiel zeigt, wie sich Knowledge-Graphen für das Grounding beziehungsweise als RAG-Ansatz nutzen lassen. Ziel des im Team entwickelten LLM-Chatbots war es, Anwender der Graphdatenbank Neo4j bei technischen Fragen zu unterstützen und Antworten in natürlicher Sprache zu geben. Dabei sollten die Nutzer auch auf das ursprüngliche Quellmaterial und damit auf zusätzliche Informationen schnell und ohne aufwändiges Suchen zurückgreifen und damit die Antworten validieren können.
In der dazu verwendeten Graphdatenbank sind rund 1500 Seiten an öffentlich zugänglicher Neo4j-Dokumentation miteinander verknüpft. Ergänzt wurden diese mit Neo4j-Code-Repositories und Transkripten aus Webinaren. Insgesamt enthält der Knowledge-Graph über 15.000 Textbausteine, die über jeweilige Beziehungen mit ihrer ursprünglichen Quelle, etwa ein Webinar, verbunden sind.
Ein so aufgebauter GenAI-Chatbot ist grundsätzlich für jede Art von Informationsabfrage vorstellbar. Statt Dokumentationen und technische Daten einer Anwendung lassen sich zum Beispiel Richtlinien und Policies zur Sicherheit in IT-Netzwerken in einem Graphen hinterlegen. IT-Administratoren und Sicherheitsexperten können dann auf wichtige Informationen zugreifen, ohne seitenlange Dokumente durchforsten zu müssen.
In Kombination mit der Visualisierung des IT-Netzwerks als Graphen könnte eine RAG-Anwendung einem Administrator es sogar ermöglichen, gleich direkt mit dem Netzwerk über Konfigurationen und Richtlinien "zu chatten". Andere Beispiele sind Forschungsdokumente und Patente oder Gesetze, Entscheidungen und Urteile.
Graph Data Science und Graphalgorithmen
Für die Analyse in Graphdatenbanken kommen Graphalgorithmen zum Einsatz. Da der Knowledge-Graph des Neo4j-Chatbots die Informationen nicht nur als vollständiger Text, sondern auch in Form von Text-Embeddings speichert, nutzte das Team in einem ersten Schritt den K-Nächste-Nachbarn-Algorithmus (KNN).
Dieser Algorithmus identifiziert für jeden Knoten eine bestimmte Anzahl (k) ähnlicher Entitäten. Für den Neo4j-Chatbot wurden so für jeden Text die zehn ähnlichsten Texte identifiziert und entsprechende "Ähnlichkeitsbeziehungen" erstellt, einschließlich eines quantitativen Wertes für die Distanz.
Die Analyse half im Folgenden bei zwei wichtigen Aufgaben. Zunächst ist das das Aufdecken von Informationsclustern: Dank der im Knowledge-Graph neu hinzugefügten Ähnlichkeitsbeziehungen ließen sich Textbausteine gruppieren. Dazu kam ein weiterer Graphalgorithmus (Community Detection) zum Einsatz, der eng miteinander verbundene Knoten im Graphen erkennt und als Cluster zusammenfasst.
Außerdem geht es um das Verteilen von Informationen. Deshalb wurden im nächsten Schritt die Cluster dazu genutzt, die Qualität und Effizienz der Grounding-Daten zu verbessern. Gerade im Umfeld technischer Dokumentationen kommt es häufig vor, dass sich Textbausteine in Dokumenten wiederholen beziehungsweise dieselben Informationen mehrfach vorkommen. In einem Knowledge-Graphen lassen sich solche Duplikate nicht nur identifizieren, sondern auch übersichtlich zu einem einzelnen Knoten zusammenfassen. Die Verweise zu den ursprünglichen Quellen bleiben dabei erhalten. Dieser Ansatz lässt sich natürlich auch auf andere Duplikate übertragen, egal ob es sich um Programmiercode, mehrfach vergebene Lizenzen oder doppelte IT-Assets in der Unternehmens-IT handelt.
Protokollierung von Konversationen
Knowledge-Graphen ermöglichen es, Daten flexibel hinzuzufügen. Um die einzelnen Anfragen der Nutzer an den Neo4j-Chatbot zu protokollieren, ergänzte das Team zusätzliche Daten über Benutzersitzungen und Konversationen. Da die Sequenz aus Prompts/Fragen und Antworten von Natur aus einem Graphen ähnelt, gestaltet sich das Modellieren einfach. Bild 2 bildet von links nach rechts die einzelnen Elemente einer LLM-Konversation ab, die den RAG-Ansatz nutzt:
- Anwender melden sich im Neo4j Chatbot an und öffnen eine Sitzung.
- Im Rahmen dieser Sitzung starten sie eine Konservation mit dem LLM.
- Die Konversation beginnt mit einer ersten Frage ("FIRST").
- Um die Frage zu beantworten, sind Grounding-Daten aus dem Know-ledge-Graphen außerhalb der Trainingsdaten des LLMs nötig (Data-Knoten). Über die HAS_CONTEXT-Beziehungen werden diese Data-Knoten zur Antwort verlinkt und sie wieder ans LLM zurückgegeben.
- Jeder Knoten ist zudem über eine HAS_SOURCE-Beziehung mit der originären Quelle (etwa Dokumentations-URL) verbunden.
- Jede Frage (Question-Knoten) ist über eine NEXT-Beziehung mit der jeweiligen Antwort verbunden. NEXT-Beziehungen gehören bei der Modellierung von sequenziellen Elementen in Graphen zum Standard. Für die Beantwortung einer Frage können ein oder mehrere Frageknoten nötig sein, je nach Konfiguration des LLM.
- Der Response-Knoten stellt schließlich die vollständige LLM-Antwort dar und enthält gegebenenfalls weitere Details (beispielsweise Benutzerbewertung, Abrufzeit).
Das Datenmodell in Bild 2 ist nur ein Beispiel. In Graphdatenbanken lassen sich jedem Knoten und jeder Kante Eigenschaften hinzufügen. Theoretisch ließe sich daher auch der LLM-Dialog mit weiteren Details anreichern und zum Beispiel die jeweiligen Knoten mit einer eindeutigen Nutzer- oder Session-ID versehen. Zudem lässt sich der LLM-Dialog unbegrenzt fortsetzen. Und schließlich können als Grounding-Data mehrere externe Quellen gleichzeitig herangezogen werden.
Visualisierung von Gesprächsketten
Graphdatenbanken eignen sich sehr gut, um komplexe Beziehungen und Sequenzen lückenlos abzubilden und transparent zu dokumentieren. Die oben beschriebene Protokollierung von LLM-Dialogen zeigte dem Chatbot-Team zum Beispiel sehr klar, welche Informationen am wichtigsten oder nützlichsten für die Beantwortung der Anwenderfragen sind. Im Umkehrschluss ließen sich Informationen identifizieren, die zu ungenauen Ergebnissen beitrugen und die in Zukunft für ähnliche Fragen ausgeklammert werden.
Die Visualisierung einer Dialogkette in Bild 3 veranschaulicht das deutlich. Jede LLM-Frage-Antwort Sequenz ist hier mit mehreren Grounding-Daten verbunden. Die Nummer der jeweiligen Knoten repräsentiert ein vorher definiertes Dokumenten-Cluster. Im Graphen ist sehr schnell erkennbar, dass fast alle Informationen, die der Neo4j-Chatbot zur Beantwortung der Frage verwendet, aus demselben Cluster stammen (13065).
Fazit
Je stärker sich GenAI-Projekte der Produktionsreife nähern, desto deutlicher zeichnen sich die Grenzen von puren LLM-Ansätzen ab. Um die Sprachmodelle mit aktuellen, spezifischen und relevanten Daten zu ergänzen und in einem größeren Informationskontext zu verankern, ist ein Grounding nötig. Retrieval Augmented Generation nutzt dazu in der Regel Vektordatenbanken. Mit steigender Komplexität der GenAI-Anwendung sind jedoch neue Datenbankwerkzeuge gefragt.
Graphdatenbanken können sowohl die Komplexität der Daten als auch die Datenbeziehungen berücksichtigen. Know-ledge-Graphen insbesondere bieten einen dichten Wissenskontext mit umfassenden und vollständigen Informationen. Dabei bleibt die Abfrage der Daten transparent und erklärbar. Angesichts der wachsenden Regulierungen und Richtlinien rund um die Nutzung von GenAI gilt diese Erklärbarkeit und Rückverfolgbarkeit zunehmend als Erfolgskriterium. Das gilt für Enterprise-Anwendungen, vor allem aber für GenAI-Werkzeuge, die in kritischen Infrastrukturen zum Einsatz kommen und wo die fehlende "Erdung" schwerwiegende Folgen haben kann.
(ln)
Daniel Bukowski ist Sales Engineer bei Neo4j.