Context Graphs oder einfach bessere Knowledge Graphs? Ein Realitätscheck

Zusammenfassung

Was sind „Context Graphs"? Der jüngste Hype um „Context Graphs" beschreibt den Anspruch, den informellen, außerhalb der Systeme entstehenden Kontext des Geschäftsbetriebs zu erfassen – etwa Entscheidungen, die per Slack oder E-Mail getroffen werden – und ihn einer KI verfügbar zu machen.

Ein altes Problem mit neuem Namen: Dies ist kein neues technologisches Neuland. Es ist eine klassische organisatorische Herausforderung aus unvollständiger Prozessdisziplin und fragmentierter Datenerfassung. Der Hype klebt neue Buzzwords (Graphen, LLMs) auf ein Problem, das gut geführte Unternehmen längst lösen.

Die eigentliche KI-Aufgabe: Einer KI beizubringen, vergangene Entscheidungen auf Basis von Kontext zu reproduzieren, ist im Kern ein Problem des Graph-Pattern-Matchings, kein rein sprachliches. Ein LLM kann dies orchestrieren, ist dabei aber auf strukturiertes, abfragbares Wissen angewiesen.

Die nachhaltige Lösung: Statt einem neuen Marketingbegriff hinterherzulaufen, sollten Unternehmen sich auf das konzentrieren, was funktioniert: den Aufbau eines robusten Enterprise Knowledge Graph, der in einer formalen, bewusst gestalteten Ontologie verankert ist. Das ist der richtige und skalierbare Weg, um den reichhaltigen Kontext bereitzustellen, den KI auf Enterprise-Niveau benötigt.

Einleitung

Die Welt der Enterprise AI ist anfällig für Hype-Zyklen, und der jüngste Begriff, der die LinkedIn-Feeds überschwemmt, ist der „Context Graph". Er kam in einer plötzlichen Welle auf, befeuert durch Ankündigungen von Wagniskapitalgebern, und das Ökosystem reagierte vorhersehbar: zuerst mit zaghafter Begeisterung, dann mit wachsender Skepsis. Inzwischen ist die Gegenbewegung in vollem Gange, und viele Fachleute argumentieren, „Context Graphs" seien nichts Neues – jeder gut entworfene Knowledge Graph sei bereits einer.

Was ist also die Realität? Handelt es sich um ein neues Paradigma für KI oder um ein cleveres Rebranding etablierter Prinzipien? Dieser Artikel schneidet durch das Rauschen und bietet eine klare, faktenbasierte Sicht darauf, was „Context Graphs" zu sein behaupten, auf welches Problem sie tatsächlich verweisen und warum ein disziplinierter, ontologiegetriebener Ansatz der einzig tragfähige Weg bleibt.

Die zentrale Unterscheidung: das Problem, das sie zu lösen behaupten

Befürworter von Context Graphs benennen zutreffend einen realen Schmerzpunkt: Ein erheblicher Teil der Geschäftstätigkeit findet außerhalb formaler IT-Systeme statt. Ein Vertriebsleiter genehmigt in einer Slack-Nachricht einen Sonderrabatt von 30 % und überschreitet damit das im CRM fest hinterlegte Limit von 20 %. Eine kritische Entscheidung fällt im Flurgespräch und wird nie protokolliert.

Diese begleitenden Informationen – das Wer, Warum und Wie hinter einem Ereignis – sind der „Kontext". Das Argument lautet: Damit eine KI wirklich aufmerksam und autonom werden kann, muss sie Zugriff auf dieses Universum informeller, unstrukturierter und bisher nicht erfasster Informationen haben. Die Vision ist, all diese Daten in einen Graphen zu gießen und eine KI die ungeschriebenen Regeln des Geschäfts lernen zu lassen.

Unser Realitätscheck: Definitionen und ein Modell

Das Problem ist real, doch die Diagnose und die vorgeschlagene Lösung führen in die Irre. Dies ist keine Technologielücke; es ist eine Disziplinlücke.

1. Das eigentliche Problem: Prozess- und Datendisziplin

In stark regulierten Branchen wie der Automobilindustrie oder dem Finanzwesen wird dieser „Kontext" akribisch erfasst – weil es sein muss. Jeder Statusübergang in einem Bauteil-Freigabeprozess etwa wird mit den zugehörigen Daten, Akteuren und der Begründung dokumentiert. Dass informelle Entscheidungen in anderen Sektoren nicht erfasst werden, ist kein Zeichen dafür, dass wir einen neuen Graphentyp brauchen; es ist ein Zeichen dessen, was man als „Prozess-Indisziplin" bezeichnen kann. Das Problem ist das Versäumnis, Daten zu erfassen, nicht eine Grenze von Knowledge Graphs.

2. Das eigentliche Muster: Event Sourcing und State Logging

Die Idee, ein Ereignis und den Zustand der Welt in diesem Moment zu erfassen, ist ein gut verstandenes Muster der Datenarchitektur. Denken Sie an Ihr Bankkonto: Ihr aktueller Kontostand ist der gegenwärtige Zustand, aber er ist das Ergebnis eines vollständigen, unveränderlichen Protokolls aller vergangenen Transaktionen (der Ereignisse). Jede Transaktion wird mit ihrem eigenen Kontext erfasst: Betrag, Empfänger, Zeitstempel und vielleicht ein Grundcode für ein Scheitern (z. B. „unzureichende Deckung").

Dafür brauchen Sie keinen „Context Graph". Sie brauchen die Verbindlichkeit, die Ereignisse zu erfassen, auf die es ankommt. Ob Sie dieses Ereignisprotokoll in einer relationalen Datenbank, einem Document Store oder einem Knowledge Graph speichern, ist ein Implementierungsdetail.

Beispiel-Durchlauf: die Rabattfreigabe

Kehren wir zum Beispiel des Vertriebsrabatts zurück.

• Das nicht erfasste Ereignis: Ein Manager genehmigt per Slack einen Rabatt von 30 %. Dieser Kontext geht den Systemen des Unternehmens verloren.
• Der „Context-Graph"-Pitch: Eine KI würde die Slack-Konversation aufnehmen und im Graphen Knoten erzeugen, die die Entscheidung repräsentieren und sie mit dem Kunden, dem Deal und dem Manager verknüpfen.
• Die disziplinierte Realität: Ein robuster Geschäftsprozess würde nicht zulassen, dass diese Entscheidung in Slack entsteht und vergeht. Er hätte einen formalen Workflow für Ausnahmen innerhalb eines System of Record. Die Anfrage für einen Rabatt von 30 % wäre ein Datenpunkt, die Freigabe ein weiterer, und beide wären formal mit dem Deal-Objekt verknüpft.

Das Ziel ist nicht, einen sekundären Graphen anzulegen, der informelle Chats spiegelt; es ist, sicherzustellen, dass wichtige Geschäftsereignisse von vornherein formal erfasst werden – innerhalb des primären Enterprise Knowledge Graph.

Warum das wichtig ist: von Buzzwords zu praktischen Konsequenzen

Dem Buzzword „Context Graph" hinterherzujagen, lenkt von der eigentlichen Arbeit ab.

Erstens lautet die zentrale Anforderung, dass eine KI aus vergangenen Entscheidungen lernt. Diese Aufgabe wird nicht allein durch Sprachinterpretation gelöst, sondern durch klassisches Pattern-Matching: zu erkennen, wann eine neue Situation mit den Eigenschaften A, B und C einer zuvor genehmigten Entscheidung X entspricht. Ein LLM-basierter Agent orchestriert diesen Prozess, indem er die richtige Abfrage formuliert (z. B. „Finde frühere Beispiele ähnlicher Rabattfreigaben"), doch die Kernlogik beruht auf der Abfrage einer strukturierten Wissensrepräsentation. Das ist Schema-RAG in Aktion: Reasoning über die formale Struktur des Graphen, nicht bloßes Raten aus Text.

Zweitens ist ein formaler Enterprise Knowledge Graph bereits das richtige Werkzeug. Es braucht keinen neuen Namen. Eine gut entworfene Ontologie kann und sollte Klassen für Decision, Event und Approval enthalten. Diese lassen sich mit den Geschäftsobjekten verknüpfen, die sie betreffen (Customer, Contract), und mit Eigenschaften anreichern, die den Zustand der Welt in diesem Moment erfassen. Entscheidend ist, dass dieses Modell bewusst und formal ist – nicht emergent und chaotisch.

Abwägungen und Grenzen

Der Reiz des „Context-Graph"-Konzepts liegt in seiner scheinbaren Einfachheit: einfach alle Kommunikationswerkzeuge verbinden und die KI das Sortieren übernehmen lassen. Das ist genau derselbe Bottom-up-, emergente Ansatz, der die heutigen unordentlichen Datenlandschaften hervorgebracht hat. Er verspricht Agilität, liefert aber einen verrauschten, unzuverlässigen und nicht governbaren Daten-Wollknäuel.

Der disziplinierte Top-down-Ansatz des formalen Ontologie-Designs ist schwieriger. Er erfordert silo-übergreifenden Konsens und intellektuelle Strenge. Doch er bringt eine stabile, skalierbare und vertrauenswürdige semantische Schicht (Semantic Layer) hervor: ein Asset, das dauerhaften Wert stiftet, weil es Bedeutung explizit und berechenbar macht.

Fazit: Wenn Sie sich nur eines merken

„Context Graph" ist eine Lösung auf der Suche nach einem Problem, das bereits einen Namen hat: Daten- und Prozessdisziplin.

Lassen Sie sich vom Hype nicht ablenken. Der Weg zu leistungsfähiger, kontextbewusster KI führt nicht über das Anlegen eines separaten, informellen „Context Graph". Er erfordert, Ihren einzigen, maßgeblichen Enterprise Knowledge Graph anzureichern, indem Sie die Ereignisse und Entscheidungen, die Ihr Geschäft antreiben, formal modellieren und erfassen.

Im Zeitalter der KI ist Klarheit die neue Agilität. Diese Klarheit entsteht aus der bewussten Struktur einer formalen Ontologie – nicht daraus, dem Stapel noch mehr unstrukturierte Daten hinzuzufügen.