Wie verwaltet man den Kontext von Agenten? RAG, LLM Wiki und GraphRAG

Ich erinnere mich noch genau daran, wie ich als Kind, mit etwa 10 oder 11 Jahren, in Ponta Delgada lebte und völlig begeistert nach Hause kam, um die Dokumentationen auf History Channel und Discovery zu sehen. Jeden Tag, ohne Ausnahme, prägte sich mein Kopf Tausende von Einzelheiten ein: „Oh, die alten Griechen hatten in manchen Tempeln Automaten, die gegen Münzen Weihwasser ausgaben!“ Über viele Jahre entstand eine Gewohnheit, die ich bis heute habe. In diesen letzten (fast) 36 Jahren muss ich Zehntausende Dokumentationen und Videos über Wissenschaft, Geschichte, Philosophie und andere Themen gesehen haben. Und die (offensichtliche) Wahrheit ist, dass 99,9 Prozent dessen, was ich gehört, gesehen und gelesen habe, nirgendwo in meinem Kopf geblieben sind.

Einige Fakten sind geblieben, weil sie so kurios waren wie die griechischen Automaten, oder weil ich sie aufgeschrieben und irgendwann erneut gelesen habe, oder weil ich sie so stark verinnerlicht habe, dass sie inzwischen zu meinem Allgemeinwissen gehören, oder weil sie mit anderen prägenden Erinnerungen verbunden sind, oder weil die Erinnerung noch frisch ist.

Daraus lässt sich eine interessante Analogie ziehen, auch wenn es keine Gleichsetzung ist. Auch Foundation Models (AI-Modelle, die mit großen Mengen vielfältiger Daten trainiert werden und sich an unterschiedliche Aufgaben anpassen lassen) haben nicht zu jedem Zeitpunkt alles verfügbar. Man muss aber das im Training gelernte Wissen vom aktiven Kontext unterscheiden, also den Informationen, die sie für einen bestimmten Modellaufruf erhalten.

Während des Trainings werden sie mit mehr Daten konfrontiert, als ein Mensch in seinem ganzen Leben aufnehmen könnte. Ein Teil dieser Inhalte geht in das Gemisch aus Grundwissen des Modells ein. Genau wie Menschen können Modelle dabei auch Fake News und falsche Vorstellungen aufnehmen.

Im normalen Alltagseinsatz verbinden Modelle dieses Grundwissen mit verschiedenen Kontextquellen. Wenn ich möchte, dass ein AI-Agent das Filtern und Priorisieren meines E-Mail-Postfachs automatisiert, verwendet er sein mitgebrachtes Grundwissen, das Prozesswissen (Anweisungen), das ich ihm gegeben habe, und die Daten der E-Mails selbst (Wissen zur konkreten Aufgabe). Doch hier stoßen wir auf eine der größten Grenzen dieser Technologie: Modelle haben ein begrenztes Kontextfenster. Einige Spitzenmodelle bieten Fenster in der Größenordnung von 1 Million Tokens. Ein Token entspricht im Durchschnitt und als Näherung für englische Texte etwa vier Zeichen. Eine Million Tokens entspricht damit ungefähr dem Eineinhalbfachen des Textes aller drei Bände von Der Herr der Ringe im englischen Original.

Ich definiere einen Agenten hier als ein Programm, das ein Foundation Model (FM) nutzt, um Entscheidungen zu treffen und Werkzeuge zu verwenden. Jedes Mal, wenn es Informationen erhalten und eine Entscheidung treffen muss, ruft es das Modell auf. Informationen, die nicht in diesem Aufruf enthalten sind, stehen nicht als Kontext zur Verfügung, selbst wenn sie in einem früheren Aufruf vorkamen. Die Branche hat sich weiterentwickelt, um diese Einschränkung zu umgehen. Die Praktiken, mit denen man dem Agenten den benötigten Kontext zum benötigten Zeitpunkt gibt, nenne ich hier Techniken des Kontextmanagements. Eine der Grundideen ist die progressive disclosure of information, also die schrittweise Bereitstellung von Kontext im Zeitverlauf, zusammen mit Werkzeugen, mit denen der Agent die benötigten Informationen selbst abrufen kann.

Da das gesamte Gebiet noch vergleichsweise jung ist, gibt es keine One-size-fits-all-Lösung. In der Branche sind mehrere Heuristiken verbreitet; eine der am häufigsten genutzten ist Retrieval-Augmented Generation (RAG). Dabei werden Dokumente normalerweise nach unterschiedlichen Kriterien in Abschnitte aufgeteilt, etwa nach fester Größe, semantischem Kontext oder Dokumenthierarchie. Häufig werden diese Abschnitte in numerische Darstellungen umgewandelt, die wir Embeddings nennen.¹ Bei Bedarf durchsucht der Agent diese Informationen, erhält die für seine Aufgabe als relevant eingestuften Abschnitte und nutzt sie, um die Antwort zu erzeugen. Typischerweise kann er eine lexikalische Suche durchführen (nach bestimmten Begriffen), eine semantische Suche (nach Abschnitten, deren Bedeutung zur Aufgabe passt) oder eine hybride Suche (beides). Das eignet sich hervorragend, wenn man bestimmte Informationen in sehr umfangreichen Dokumenten finden muss, etwa im klassischen Beispiel, relevante Informationen aus einem 500-seitigen Vertrag herauszuziehen. Doch selbst bei einer gut formulierten Suche erhält der Agent möglicherweise nicht alle für die Aufgabe erforderlichen Abschnitte und hat dann nur unvollständigen Kontext. Trotzdem wird sowohl in der Industrie als auch in der Forschung weiterhin viel über diese Technik gesprochen, und sie kam in praktisch allen Implementierungen zum Einsatz, die ich gesehen habe.

Es ist aber nicht die einzige Möglichkeit. Andrej Karpathy, einer der meistzitierten Namen in der Welt der generativen AI, schlug die LLM Wiki vor.² Dieser Ansatz nutzt Markdown-Dateien (.md), also einfache Textdateien mit einer bestimmten Formatierungssyntax, um einen Index und miteinander verknüpfte Wissensseiten zu pflegen, deren Inhalte aus den Quellen zusammengeführt werden. Der Agent kann die relevanten Seiten bei Bedarf vollständig lesen. Das entspricht dem Vorgehen, wenn ich die Bedienungsanleitung eines neuen Gegenstands aufschlage und anhand des Inhaltsverzeichnisses nur die für mich relevanten Abschnitte lese. Für mehrere Anwendungsfälle ist das mein bevorzugter Ansatz, weil er konsistent und leicht zu pflegen oder manuell anzupassen ist. Bei komplexen Anwendungsfällen kann der Pflegeaufwand allerdings höher sein, als beispielsweise die Embeddings einer neuen Dokumentversion zu erzeugen und den Index zu aktualisieren. Wir können Pipelines zur Informationsverdichtung bauen (damit meine ich, die Textmenge zu reduzieren und dabei die Informationsdichte zu erhalten), um eine LLM Wiki zu pflegen. Genau das schlägt Karpathy vor. Meiner Erfahrung nach sind die Modelle bei dieser Verdichtung jedoch noch ziemlich fehleranfällig: Ihnen entgehen häufig Nuancen der ursprünglichen Informationen und der Gesamtzweck des Dokuments. Der Kuratierungsaufwand wird schnell beträchtlich.

Zum Schluss möchte ich kurz auf GraphRAG, also Graph Retrieval-Augmented Generation, eingehen, denn der Text ist schon lang und ich will niemanden entmutigen, der bis hierher gelesen hat. Vielleicht fangen wir damit an, was ein Graph ist: eine mathematische oder informatische Struktur aus einer Menge von Knoten, die durch Kanten beziehungsweise Verbindungen miteinander verknüpft sind... erst einmal Luft holen. Einfach gesagt ist das eine Möglichkeit, Informationen und Beziehungen zwischen Daten darzustellen, wie unten zu sehen. Ein gutes Beispiel ist ein soziales Netzwerk, in dem die Namen verschiedener Menschen miteinander verbunden sein können, wobei die Verbindungen eine Richtung haben: Joaquina folgt Manuel, der Ramiro folgt, der wiederum Joaquina folgt. Das bedeutet nicht, dass Manuel Joaquina folgt oder Joaquina Ramiro. Die Menschen sind Knoten; die Verbindungen sind die Follows. Informationen können eine Richtung haben, und die Beziehungen sind explizit.

Ein Pfeil von A nach B bedeutet „A folgt B“. Die umgekehrte Beziehung ist nicht impliziert.

GraphRAG verwendet einen Wissensgraphen mit Entitäten (Konzepten, Gegenständen, Menschen) und ihren Beziehungen, um ein abfragbares Netz zu bilden. Das erleichtert es einem Agenten, bei der Suche nach Informationen für eine Aufgabe einem Recherchepfad durch diese Beziehungen zu folgen. Die gefundenen Informationen werden anschließend als Kontext an das Modell übergeben, damit es die Antwort erzeugen kann. Das kann besonders nützlich sein, wenn man Informationen aus mehreren Dokumenten miteinander verknüpfen muss. Wie bei den anderen Ansätzen gilt auch hier: Informationen und Beziehungen müssen kuratiert werden, insbesondere wenn der Agent sie autonom erzeugt. Sind Beziehungen etwa falsch, unvollständig oder veraltet, kann der Agent wichtige Informationen auslassen oder seine Antwort auf Verbindungen stützen, die keinen Sinn mehr ergeben. Ich habe diesen Ansatz schon angewendet und bin bei einem so komplexen Netz gelandet, dass weder ich noch der Agent (Shoutout an Sr. Alfredo) verstanden, was darin steckte.

Diese drei Ansätze schließen sich nicht gegenseitig aus, und ein relativ komplexes Unternehmensprojekt mit einer ausgereiften Herangehensweise könnte je nach Fall letztlich alle drei nutzen. Eine Wiki lässt sich mit RAG durchsuchen, und GraphRAG selbst unterstützt die Generierung mit abgerufenen Informationen. Hier ist eine Zusammenfassung meines gedanklichen Modells dafür, wann ich welchen Ansatz nutze:

Doch das Thema Kontextmanagement endet hier nicht. Dies ist erst der erste Artikel einer Reihe, in der ich mich damit beschäftigen werde. Künftig sprechen wir über Caching, Compaction, Context Pruning und die Isolation von Kontext durch Subagenten. Bis bald.