RAG und Knowledge Graphs: Wie komplexes Unternehmenswissen für GenAI besser nutzbar wird

Von Max Kühn 

Durch Retrieval Augmented Generation (RAG) sind Large Language Modelle (LLM) dazu in der Lage, auf Informationen aus neuen, ihnen vorher unbekannten Dokumenten zurückzugreifen und so tiefgehendes Faktenwissen in ihre Antworten einfließen zu lassen. Die Praxis zeigt jedoch, dass RAG-Anwendungen an ihre Grenzen stoßen, wenn Fragen auf implizites Wissen abzielen, das sich erst aus der Summe mehrerer Dokumente ergibt.  

Knowledge Graphs können helfen, diese Grenzen zu erweitern, indem sie die Informationen aus verschiedenen Dokumenten verknüpfen und anreichern. Im dritten Beitrag unserer Reihe „AI Deep Dive“ erläutern wir daher Möglichkeiten, wie Knowledge Graphs zu diesem Zweck in RAG-Anwendungen integriert werden können. 

Unter der Motorhaube: Wie RAG Nutzeranfragen für die KI anreichert 

In den Beiträgen zu maßgeschneiderter generativer KI in Unternehmen und dem Nutzbarmachen von Unternehmenswissen mit GenAI und Retrieval Augmented Generation haben wir beschrieben, wie RAG genutzt werden kann, um Anwendungen der generativen KI ohne aufwändiges Training mit neuen, unternehmensinternen Wissensschätzen anzureichern.  

Der dort beschriebene und generell sehr weit verbreitete Ansatz von RAG funktioniert grob folgendermaßen: Ein Nutzer stellt über eine Anwendung eine Frage an ein LLM. Bevor diese Frage zum LLM gelangt, wird sie „embedded“, d. h. in eine numerische Repräsentation ihrer semantischen Bedeutung umgewandelt. Diese Repräsentation kann gegen äquivalente Embeddings der unternehmensinternen Dokumente mit Hilfe von Suchalgorithmen abgeglichen werden, welche in sogenannten Chunks vorbereitet in einer Vektordatenbank bereitliegen.  

Nach der Suche liegen ein oder mehrere Text-Chunks vor, die der Frage in ihrer Bedeutung ähnlich sind und schlussendlich zusammen mit dieser an ein LLM geschickt werden, sodass es über ausreichend Kontext zur Beantwortung der Frage verfügt. Dank RAG können Informationen, die explizit in den Quelldokumenten enthalten sind, für LLMs sehr gut zugänglich gemacht werden.  

Man stelle sich z. B. ein Szenario vor, in dem ein Maschinenbauer seine Einsätze zur Fehlerbehebung beim Kunden in Form von Fehlerberichten dokumentiert. Diese enthalten unter anderem Informationen über den Kunden, die Maschine, die defekten Bauteile sowie eine narrative Beschreibung des Problems und der Lösung.  

Werden diese nun in einer Vektordatenbank abgelegt, können effizient hilfreiche Kontextinformationen zu Fragen wie „Es liegt folgender Fehler vor: (…). Ist ein ähnlicher Fehler bereits in der Vergangenheit aufgetreten? Wenn ja, wie kann er behoben werden?“ gefunden werden.  

Zielen Fragen jedoch auf Informationen ab, die zwar implizit vorhanden sind, aber explizit nicht erwähnt werden, kommen solche Systeme an ihre Grenzen. Zum Beispiel wird die Frage „Welche Bauteile sind besonders häufig von Fehlern betroffen?“ zwar in der Summe der Dokumente beantwortet, nicht aber in einem einzelnen oder wenigen Textabschnitten.  Zur Schließung dieser Lücke sind Knowledge Graphs eine Option, die in Kombination mit “konventionellem” RAG eingesetzt werden können.

Bedeutung und Funktionsweise von Knowledge Graphs 

Für die Zwecke dieses Artikels können Knowledge Graphs im Wesentlichen als eine Art Datenstruktur betrachtet werden, die ein Geflecht von Entitäten in Form von Knoten (also Objekten, Personen, Organisationen etc.) und deren Relationen untereinander in Form von Kanten abbildet (vgl. Abbildung 1)  

Graphendatenbanken halten diese Informationen vor und machen sie über spezielle Abfragesprachen und entsprechende Visualisierungen zugänglich.  

Anwendung finden Knowledge Graphs klassischerweise in z. B. Suchmaschinen oder im Natural Language Processing. Bei RAG-Lösungen können sie helfen, Informationen aus Dokumenten zu verknüpfen und so übergreifende Konzepte abzubilden, die dann an das LLM zur Beantwortung komplexer Nutzerfragen weitergegeben werden. Je nach Ausgangssituation können Knowledge Graphs auf verschiedene Arten in RAG-Lösungen integriert werden. Zwei aus unserer Sicht besonders interessante und zugängliche Varianten wollen wir im Folgenden exemplarisch vorstellen. 

Abbildung 1: Beispiel Knowledge-Graph 

Wie Knowledge Graphs RAG-Anwendungen verbessern können 

Variante 1: Graph als angereicherte Vektordatenbank 

Bei dieser Variante werden Textchunks inkl. Embeddings als Knoten in einem Graphen gespeichert, deren Reihenfolge entsprechend dem Originaldokument über Beziehungen abgebildet und dann ggf. mit weiteren Entitäten in Relation gesetzt.  

Abbildung 2 skizziert einen Ausschnitt aus einem Graphen, wie er für das Maschinenbauer-Beispiel aussehen könnte. Hier hängen die Textchunks (Chunk) über NEXT-Beziehungen zusammen und sind jeweils einem Fehlerbericht (Report) über die BELONGS_TO-Beziehung zugeordnet.  

Einige Graphendatenbanken bieten Funktionen einer Vektordatenbank und ermöglichen so die Vektorsuche nach passenden Chunks zu einer Nutzerfrage. Der Graph hat dann den Vorteil, neben den passenden Chunks auch schnell und einfach zusammenhängende Informationen liefern zu können, wie vorherige und nachfolgende Chunks oder die Metadaten des konkreten Fehlerberichts.  

Einen wirklichen Vorteil bringt das, wenn weitere, einfach zu extrahierende Entitäten aus den Dokumenten als solche im Graphen abgebildet werden. Bei den Fehlerberichten sind das z. B. die betroffenen Bauteile, in der Abbildung dargestellt über die Component-Knoten und die REFERS_TO-Beziehung.  

Über passende Abfragen können aus dem Graphen dann beispielsweise Informationen gewonnen werden, wie häufig ein Bauteil in allen Fehlerberichten vorkommt. Die Beantwortung von eingangs erwähnter Frage „Welche Bauteile sind besonders häufig von Fehlern betroffen?“ rückt so in den Rahmen des Möglichen. Darüber hinaus ist es denkbar, dass weitere Informationen aus anderen (strukturierten) Datensätzen in den Graphen eingebracht werden, z. B. aus einer Bauteildatenbank, die auch Informationen über Hersteller vorhält. Dadurch kann – in der Theorie – der Wissensschatz eines LLMs systematisch erweitert werden.  

In der Praxis allerdings kann das, wie generell das Erstellen eines Graphen auf diese Weise, mit großem manuellem Aufwand verbunden sein. Ob sich das lohnt, ist je nach Anwendungsfall abzuwägen, auch gegen Alternativen, wie beispielsweise die direkte Einbindung von relationalen Datenbanken in die RAG-Anwendung. 

Abbildung 2: Textstruktur und ergänzende Informationen abgebildet als Graph 

Variante 2: Generierter Graph als zusätzlicher Baustein 

Es besteht die Möglichkeit, die Vorteile eines Graphen für RAG zu nutzen, ohne dass dieser händisch erstellt und gepflegt werden muss. In diesem Fall wird der Graph von einem LLM automatisch aus den Quelldokumenten generiert, wobei nicht der Text selbst Gegenstand des Graphen ist, sondern die darin enthaltenen, automatisch erkannten Entitäten und Relationen.  

Abbildung 3 zeigt beispielhaft, wie ein Ausschnitt eines Graphen für einen Fehlerbericht aussehen könnte. Automatisch erkannt wurden hier Entitäten wie Maschinen (Machine), Modellreihen (Model) und Kunden bzw. Firmen (Company) sowie deren Beziehungen untereinander (OF_TYPE, LOCATED_AT, SUBSIDIARY_OF).  

Bei dieser Variante ist der Graph eine Ergänzung zu einer „konventionellen“ Vektordatenbank und ersetzt diese nicht. Das geht damit einher, dass bei der fertigen RAG-Anwendung nicht die Vektorsuche anhand der Textembeddings als Einstiegspunkt für die Suche von Informationen innerhalb des Graphen genutzt werden kann, sondern dass die relevanten Informationen aus diesem separat gewonnen werden müssen.  

Der Prozess für eine RAG-Anwendung kann bei Nutzung dieser Variante dann grob so aussehen: Ein Nutzer stellt eine Frage aus der anschließend die enthaltenen Entitäten durch ein dazu angewiesenes LLM extrahiert werden. Anhand der extrahierten Entitäten wird dann eine Abfrage in der Abfragesprache der Graphendatenbank generiert, welche die relevanten Knoten, deren direkte Nachbarn und deren Beziehungen als Ergebnis zurückgibt. Dieses Ergebnis wird zum Schluss zusammen mit den Chunks aus der Vektordatenbank in einem Prompt verpackt und in Kombination als Kontext zur Frage an ein LLM geliefert. Dieses kann die Nutzerfrage schlussendlich mit einem Wissensschatz beantworten, der dann im Optimalfall weit über ein oder wenige Chunks hinausgeht.  

Diese Variante ist mit vergleichsweise wenig manuellem Aufwand umzusetzen, da die Hauptarbeit der Graphenerstellung automatisiert wird. Das bietet in der Theorie viele Vorteile, z. B. kann der Graph kontinuierlich erweitert werden oder es werden nützliche Verbindungen entdeckt, die im Vorhinein nicht bekannt waren.  

In der Praxis müssen viele Herausforderungen gemeistert werden, damit die Vorteile zum Tragen kommen. So muss ein LLM den Graphen sinnvoll und zielgerichtet erstellen und gleichzeitigt Halluzinationen vermeiden. Auch müssen syntaktisch korrekte und inhaltlich sinnvolle und ggf. verkettete Abfragen für die Graphendatenbanken generiert werden. Des Weiteren ist das richtige Prompten der Ergebnisse im Kontext der Nutzerfrage elementar.  

Das alles sind Aspekte, die eine LLM-bedingte Unschärfe mit sich bringen, die es zu handhaben gilt. Darüber hinaus entstehen aufgrund des mehrfachen Einbindens von LLMs zusätzliche Kosten bei jeder Nutzerfrage. Insgesamt gilt dementsprechend auch hier: Für einen konkreten Anwendungsfall sind die Herausforderungen gegenüber den Potenzialen abzuwägen. 

Abbildung 3: Automatisch erkannte Entitäten und Beziehungen in einem Graphen 

Fazit: RAG-Anwendungen können von Knowledge Graphs auf vielfältige Weise profitieren 

Zusammenfassend lässt sich sagen, dass RAG-Anwendungen auf unterschiedliche Weisen von Knowledge Graphs profitieren können. Gemeinsam haben sie, dass sie potenziell mehr und vor allem übergreifende Fragestellungen beantworten können. Das Ergebnis kann bei geeigneter Ausgangslage sehr beeindruckend und gewinnbringend sein.  

Es ist jedoch auch zu berücksichtigen, dass sich LLMs im Allgemeinen, RAG und ihre kombinierte Verwendung mit Knowledge Graphs schnell weiterentwickeln. Es lohnt sich daher, die Entwicklungen, die zum Teil auch unter dem Begriff „GraphRAG“ geführt werden, zu beobachten. Die beschriebenen Varianten sind also keineswegs in Stein gemeißelt und es kann generell in der Zukunft andere Möglichkeiten geben, ähnliche Vorteile zu erzielen, beispielsweise wenn das Finetuning von LLMs einfacher und wirtschaftlicher wird. 

Deshalb ist es wichtig, jeden Anwendungsfall individuell zu betrachten und alle zum jeweiligen Zeitpunkt vorhandenen Möglichkeiten einzubeziehen. 

Gerne finden wir gemeinsam mit Ihnen heraus, welche Möglichkeiten für Ihren Anwendungsfall bestehen, konzipieren eine Lösung und setzen diese um. Dabei profitieren Sie von unseren Projekterfahrungen in den Bereichen LLM und RAG sowie von unseren vielfältigen Erfahrungen aus den Bereichen Data Science, Data Engineering und Cloud-Entwicklung. Wir freuen uns auf Ihre Anfrage.