Graph RAG in der Praxis: Wenn RAG bei vernetztem Fachwissen unvollständig antwortet
Ein KI-Assistent, der Fragen aus den eigenen Dokumenten beantwortet, gehört inzwischen zu den naheliegendsten Anwendungen im Unternehmen. Das Verfahren dahinter heisst Retrieval-Augmented Generation, kurz RAG, und für einen grossen Teil der Fälle ist es die richtige Wahl.
Es gibt jedoch eine Ausgangslage, in der dieser Standardansatz zuverlässig danebenliegt. Diese tritt genau dort auf, wo Wissen aus Regeln, Ausnahmen und Zuständigkeiten besteht, also in Versicherungen, im Gesundheitswesen, in der Finanzbranche und überall dort, wo eine Auskunft Folgen hat.
Dieser Beitrag zeigt an einem konkreten Fall aus dem Schweizer Gesundheitswesen, wo diese Grenze verläuft, wie ein Knowledge Graph sie verschiebt und was der Ansatz an Aufwand kostet. Der erste Teil richtet sich an alle, die über solche Projekte entscheiden. Der zweite beschreibt die technische Umsetzung im Detail.
Ausgangspunkt war die Aussage eines Unternehmens im ersten Gespräch: Ein intern getesteter Assistent liefere unbrauchbare Ergebnisse. Es wurde ein RAG-Chatbot mit Copilot Studio und einer mit AI-Studio von Google erstellt und die Resultate waren unbefriedigend. Bei Copilot Studio war die Antwort schlichtweg falsch und bei Googles AI-Studio dauerte die Antwort über 3 Minuten. Eine Herausforderung, sich das genauer anzuschauen.
Wie RAG funktioniert
Ein Chatbot mit einem Standard-LLM antwortet zunächst nur aus seinem Trainingswissen. Über die internen Unterlagen eines Unternehmens weiss er nichts, und was er nicht weiss, ergänzt es im Zweifel plausibel klingend - so entstehen Halluzinationen. RAG löst das, indem es dem Modell zu jeder Frage die passenden Stellen aus einer eigenen Wissensquelle mitgibt.
Dafür werden die Dokumente vorab in kleinere Abschnitte (Chunks) zerlegt. Jeder Abschnitt wird in ein sogenanntes Embedding überführt, eine Zahlenrepräsentation seiner inhaltlichen Bedeutung. Abschnitte mit ähnlichem Sinn liegen in diesem Bedeutungsraum nahe beieinander, auch wenn sie andere Wörter verwenden. Diese Repräsentationen liegen in einer Vektordatenbank.
Stellt jemand eine Frage, wird auch sie in ein Embedding überführt. Das System sucht die Abschnitte, die der Frage am nächsten liegen, und übergibt sie zusammen mit der Frage an das Sprachmodell, das daraus die Antwort formuliert.
Der Mehwert ist beträchtlich. Die Antwort stützt sich auf geprüfte, aktuelle und unternehmenseigene Inhalte statt auf allgemeines Trainingswissen, und die Quellen lassen sich benennen. Das funktioniert zuverlässig, solange eine Bedingung erfüllt ist: Die Frage muss mit Embedding beantwortet werden können, die im Vektorraum semantisch in der Nähe voneinander sind.
Die Ausgangslage
Das Unternehmen betreibt mehrere Softwaresysteme für unterschiedliche Anwendergruppen. Die Dokumentation umfasst je nach Sprache zwischen 300 und 650 Seiten, liegt in drei Sprachen vor, und ein relevanter Teil der Information steckt in Screenshots statt im Fliesstext.
Drei Eigenschaften dieses Wissensbestands sind entscheidend.
- Er ist verteilt. Inhalte liegen in einem Redaktionssystem, in SharePoint und in Confluence, ohne durchgängige Verlinkung zwischen zusammengehörenden Regeln.
- Er ist rollenabhängig. Dieselbe Frage hat je nach Funktion der fragenden Person eine andere korrekte Antwort, weil Berechtigungen und Zuständigkeiten variieren.
- Er ist relational. Eine einzelne Aussage ist selten für sich genommen vollständig. Regeln haben Ausnahmen, Ausnahmen haben Bedingungen, und diese stehen häufig in einem anderen Dokument als die Regel selbst.
Der Service Desk beantwortet vor diesem Hintergrund täglich wiederkehrende Fragen von Hand. Ein Assistent, der die Standardfälle abdeckt, ist die naheliegende Entlastung. Genau dieser Ansatz war getestet worden und gescheitert.
Warum die Suche unvollständig antwortet
Die semantische Suche findet die Abschnitte mit der grössten inhaltlichen Nähe zur Frage. Nähe bedeutet jedoch Ähnlichkeit, nicht Vollständigkeit. Bei relationalem Fachwissen fällt beides auseinander.
Ein Beispiel aus dem Betrieb. Auf die Frage, ob eine Ergotherapeutin Hilfsmittel für ihre Patienten abgeben und verrechnen darf, findet die Suche das Dokument zu Rollen und Berechtigungen. Dort steht, dass Therapeutinnen keine Rezepte ausstellen dürfen. Das System leitet daraus eine ablehnende Antwort ab.
Diese Antwort ist unvollständig und damit im Ergebnis falsch. In einem anderen Dokument ist nämlich die Bedingung geregelt, unter der die Leistung zulässig ist: Bei vorliegender ärztlicher Verordnung und aktiver Delegation darf die Therapeutin die Leistung erbringen und verrechnen. Ein konventioneller RAG-Chatbot macht hier also aus einem "Ja aber nur wenn es eine ärztliche Verordnung gibt" ein "Nein".
Der Fehler ist vorhersehbar, wenn man versteht, wie RAG funktioniert. Die Suche bewertet Abschnitte nach ihrer Nähe zur Frage, nicht nach ihrer inhaltlichen Zusammengehörigkeit. Dass zu einer gefundenen Regel eine Ausnahme in einem separaten Dokument gehört, ist für das Verfahren nicht erkennbar. Beide erscheinen als unabhängige Fragmente, und die Ausnahme, die der Frage sprachlich weniger ähnelt, fällt aus dem Ergebnis heraus.
Kritisch ist vor allem die Form des Fehlers. Die Antwort ist sprachlich einwandfrei, in sich schlüssig und wirkt vollständig. Sie ist lediglich in der Sache unvollständig. Wo aus einer Auskunft eine Handlung mit rechtlichen oder finanziellen Folgen entsteht, ist das einer falschen Antwort gleichzusetzen. Und weil die Antwort überzeugend klingt, bemerkt sie zunächst niemand.
Für den Betrieb hat das eine unmittelbare Konsequenz. Wer einmal eine Antwort erhalten hat, die sich als unzutreffend erwies, fragt beim nächsten Mal wieder beim Service Desk nach. Der Assistent entlastet dann nicht, sondern erzeugt zusätzliche Arbeit.
Der Ansatz: Graph RAG
Dem Standardverfahren liegt eine Annahme zugrunde: dass Wissen eine Menge durchsuchbarer Textabschnitte ist. Für relationales Fachwissen trifft das nicht zu. Es ist ein Netz aus Regeln, Rollen, Ausnahmen und Bedingungen, die sich gegenseitig bedingen.
Hier setzen graphgestützte Verfahren an, die unter dem Begriff Graph RAG zusammengefasst werden. Die gemeinsame Idee: Neben textbasiertem Wissen, gibt es einen Knowledge Graph, der nicht die Inhalte selbst enthält, sondern die Beziehungen zwischen den fachlichen Objekten. Welche Rolle ist zu welcher Aktion berechtigt, welche Regel schränkt eine Aktion ein, welche Ausnahme hebt eine Regel unter welcher Bedingung auf, welcher Systemzustand blockiert welchen Ablauf.
Damit bleibt das System nicht bei der gefundenen Grundregel stehen. Es folgt den Verbindungen und bezieht die zugehörigen Ausnahmen und Bedingungen ein. Im genannten Beispiel ist der Knoten, der die Rolle der Therapeutin mit der fraglichen Aktion verbindet, mit der Bedingung der aktiven Delegation und mit der ärztlichen Verordnung verknüpft. Die Antwort lautet daher nicht schlicht ablehnend, sondern nennt die Bedingungen, unter denen die Leistung zulässig ist.
Welche Variante von Graph RAG
Graph RAG ist kein einheitliches Verfahren, sondern eine Familie von Ansätzen, die sich erheblich unterscheiden.
Am einen Ende stehen vollständig graphbasierte Verfahren, bei denen der Graph selbst die primäre Wissensquelle bildet, inklusive automatisch erzeugter Zusammenfassungen ganzer Themencluster. Sie eignen sich für breite, explorative Fragen über sehr grosse Bestände, sind im Aufbau aber aufwendig und in der Nachvollziehbarkeit schwächer.
Am anderen Ende stehen hybride Verfahren, bei denen der Graph die Suche steuert und die Texte die Erläuterung liefern. Der Graph hält die geprüfte Struktur, die Vektorsuche den Fliesstext samt Quelle.
Für den beschriebenen Fall haben wir den hybriden Ansatz gewählt, und zwar aus drei Gründen. Die Fragen sind präzise und regelbezogen, nicht explorativ. Jede Aussage muss auf eine konkrete Quelle zurückführbar sein, was in einem regulierten Umfeld nicht verhandelbar ist. Und der Graph bleibt auf die fachlich relevanten Beziehungen begrenzt, statt den gesamten Bestand abzubilden, was Aufbau und Pflege beherrschbar hält.
Diese Entscheidung ist der eigentliche Kern solcher Projekte. Nicht das aufwendigste Verfahren zu wählen, sondern dasjenige, das zur Struktur des Wissens und zu den Anforderungen an Nachvollziehbarkeit passt.
Aufbau des Prototyps
Der folgende Teil beschreibt die technische Umsetzung. Für die Machbarkeitsprüfung entstand ein Prototyp mit zwei Datenspeichern. Ein Graph in Neo4j bildet die Regeln und ihre Beziehungen ab und ist Ausgangspunkt jeder Anfrage. Ein Vektorspeicher in Weaviate hält die Fliesstexte und liefert die Erläuterungen zu den im Graphen gefundenen Objekten.
Aufbau der Wissensbasis
Bei der Ingestion werden die Inhalte aus Redaktionssystem, SharePoint und Confluence eingelesen. Da ein Teil der Anleitungen in Screenshots steckt, reicht reine Textextraktion nicht aus. Die Seiten werden multimodal verarbeitet, wobei die Layout-Struktur erhalten bleibt, damit Handlungsschritte, Tabellen und Warnhinweise als getrennte Einheiten erkennbar bleiben.
Das Chunking orientiert sich nicht an festen Zeichenlängen, sondern an der inhaltlichen Gliederung, also an Kapiteln, Handlungsschritten und Regelblöcken. Ein Abschnitt, der innerhalb einer Bedingung endet, führt andernfalls zu systematisch unvollständigen Antworten.
Die Modellierung des Graphen bildet das Fachwissen in einem Schema aus elf Klassen ab, darunter Rolle, Aktion, Regel, Ausnahme, Systemzustand, Modul, Fehlercode und Versicherungsart. Die Beziehungen zwischen diesen Objekten sind der eigentliche Mehrwert des Ansatzes. Ihre Extraktion ist zugleich der aufwendigste Schritt und derjenige, der über die Qualität des Gesamtsystems entscheidet. Automatisch erzeugte Beziehungen erfordern fachliche Prüfung, da ein fehlerhaft verknüpfter Graph zu ebenso überzeugend formulierten wie falschen Antworten führt.
Verarbeitung einer Anfrage
Die Beantwortung erfolgt in vier aufeinanderfolgenden Schritten. Ausgangspunkt ist der Graph, nicht die Textsuche.
Im ersten Schritt gleicht ein Sprachmodell die Frage mit dem Graphen ab. Es erhält das Schema und die vorhandenen Einträge und bestimmt, welche fachlichen Objekte die Frage betrifft, also welche Rollen, Aktionen, Regeln und Ausnahmen gemeint sind. Zu jedem Treffer gibt es an, wie sicher die Zuordnung ist. Das System legt damit offen, was es verstanden hat, bevor es sucht.
Im zweiten Schritt liefert der Graph zu diesen Treffern die unmittelbare Nachbarschaft, also die verbundenen Knoten und Kanten. Hier gelangen die Ausnahmen und Bedingungen in den Kontext, die zur gefundenen Regel gehören, bei reiner Textsuche jedoch unberücksichtigt blieben.
Im dritten Schritt wird für jeden im Graphen getroffenen Begriff eine eigene Abfrage an den Vektorspeicher gestellt. Diese Abfragen leiten sich aus dem Graph-Abgleich ab, nicht aus der Frage allein. Sie holen zu jedem Objekt den erläuternden Fliesstext samt Herkunftsangabe.
Im vierten Schritt wird die Antwort synthetisiert. Ein Modellaufruf erhält die ursprüngliche Frage, die Beziehungen aus dem Graphen und die zugehörigen Textabschnitte mit ihren Quellen. Die Vorgaben sind eng gefasst: Aussagen zu Regeln, Systemzuständen und Störungen müssen durch den Graphen belegt sein, textliche Aussagen werden mit der Quelldatei zitiert, und die zugrunde liegenden Beziehungen werden ausformuliert statt nur im Ergebnis wiedergegeben. Die Antwort enthält damit nicht nur das Resultat, sondern auch dessen Begründung.
Umgang mit Unsicherheit
Ist die Datenlage zu einer Frage unzureichend, soll das System keine Antwort auf gut Glück geben. Es weist die Unsicherheit aus und übergibt an den Service Desk. Ein Assistent, der einen klar abgegrenzten Teil der Fragen zuverlässig beantwortet und die übrigen kontrolliert weiterreicht, ist einem System vorzuziehen, das eine höhere Trefferquote durch überzeugend formulierte Fehlauskünfte erkauft.
Nachvollziehbarkeit und Betrieb
Für den produktiven Einsatz gehört die messbare Bewertung der Antwortqualität dazu. Ein fester Katalog realer Service-Desk-Fragen mit fachlich geprüften Antworten dient als Prüfmassstab, gegen den jede Änderung nach Korrektheit, Vollständigkeit und Relevanz bewertet wird. Ohne einen solchen Massstab bleibt eine schleichende Verschlechterung unbemerkt.
Jede Anfrage wird protokolliert, einschliesslich der herangezogenen Quellen und der erzeugten Antwort. In einem regulierten Umfeld ist diese Nachvollziehbarkeit nicht optional. Der Betrieb ist auf Schweizer Infrastruktur ausgelegt, eine Verwendung der Daten für das Training von Modellen findet nicht statt.
Aufwand und Abgrenzung
Ein graphgestützter Ansatz ist kein kostenloser Zugewinn. Der Graph muss modelliert, fachlich geprüft und bei jeder inhaltlichen Änderung nachgeführt werden. Das erfordert mehr Infrastruktur, mehr Aufwand in der Aufbereitung und deutlich mehr fachliches wie technisches Wissen als eine reine Vektorsuche.
Für einen überschaubaren, in sich geschlossenen Wissensbestand steht dieser Aufwand in keinem sinnvollen Verhältnis zum Nutzen. Wer eine begrenzte Zahl klar abgegrenzter Standardfragen beantworten möchte, ist mit dem Standardansatz schneller und günstiger bedient.
Der Mehraufwand rechtfertigt sich, wenn mindestens eine der folgenden Bedingungen zutrifft:
- Eine korrekte Antwort erfordert regelmässig die Kombination mehrerer Dokumente bei einer grossen Anzahl von Dokumenten.
- Das Wissen enthält Regeln mit Ausnahmen, Bedingungen und Rollenabhängigkeiten in unterschiedlichen Dokumenten.
- Eine fehlerhafte Antwort hat rechtliche oder finanzielle Konsequenzen.
Trifft keine dieser Bedingungen zu, ist der graphgestützte Ansatz die falsche Wahl.
Fazit
Ob ein Standardansatz ausreicht, entscheidet sich nicht am Anwendungsfall, sondern an der Struktur der zugrunde liegenden Daten. Die Aufgabe, Fragen zu einer Dokumentation zu beantworten, ist in ihrer Formulierung stets dieselbe. In der Umsetzung reicht sie von trivial bis anspruchsvoll, abhängig davon, ob eine Antwort in einem einzelnen Dokument steht oder sich erst aus dem Zusammenspiel mehrerer ergibt.
Daraus folgt ein einfaches Vorgehen: Am Anfang steht die Analyse der Datenstruktur, nicht die Auswahl eines Werkzeugs. Erst wenn klar ist, wie das Wissen organisiert ist, lässt sich beurteilen, ob ein Standardverfahren genügt oder ein graphgestützter Ansatz erforderlich ist.
Der beschriebene Fall ist anonymisiert. Die Umsetzung erfolgte als Prototyp im Rahmen einer Machbarkeitsprüfung. Für eine Einschätzung Ihres eigenen Anwendungsfalls stehen wir Ihnen gerne zur Verfügung.
