LangChain: OpenWiki-Gedächtnis macht Agenten bei quellenübergreifenden Fragen etwa fünfmal genauer

Warum LangChain ein kompiliertes Wiki gebaut hat

Agenten, die über Richtlinien, Handbücher, Wikis, Tickets und Code hinweg arbeiten, müssen sich in Wissen zurechtfinden, das über Systeme und Teams verstreut ist. LangChain argumentiert, dass das Auffinden einer passenden Passage nur der Anfang sei: Agenten müssten außerdem entscheiden, welche Regeln gelten, was sich geändert hat und wie sich eine Quelle auf eine andere auswirkt. Ohne persistente Gedächtnisschicht bauen Agenten dieses Verständnis laut dem Unternehmen bei jeder Frage neu auf, was teuer und fehleranfällig sei.

Besonders groß ist das Problem bei Banken und Versicherungen, wo sich Richtlinien und Vorgaben häufig gegenseitig ändern oder ersetzen. Gängige RAG-Pipelines rufen meist per semantischer oder hybrider Suche einzelne Textabschnitte ab und überlassen es dem Agenten, deren Zusammenhang selbst zu klären.

OpenWiki ist ein quelloffenes CLI-Tool auf Basis von Deep Agents. Es verdichtet Quellmaterial zu verlinkten Seiten, die zentrale Konzepte und deren Beziehungen erklären, samt Quellenverweisen. LangChain zufolge entstand das Werkzeug zunächst, damit Coding-Agenten Architektur und Codeverhalten nicht bei jeder Aufgabe neu herausfinden müssen.

Jede Aussage in OpenWiki beruht auf einem Claim, einer Behauptung, die mit den stützenden Quellzeilen und deren Hash verknüpft ist. Ändern sich diese Zeilen, ändert sich der Hash, sodass OpenWiki betroffene Claims ohne Modellaufruf markieren kann. Nur diese Claims werden anschließend einem Modell zur Bestätigung, Überarbeitung oder Rücknahme vorgelegt.

Der Test: 111 Versicherungsdokumente

Zur Bewertung des Ansatzes baute LangChain eine synthetische Versicherungsbibliothek aus 111 langen Dokumenten. Das Unternehmen wählte Versicherungen, weil sich Policen und Nachträge häufig aufeinander beziehen, einander ändern und außer Kraft setzen. Das Team erstellte eine Liste von 972 Fakten, legte fest, wo jeder davon auftauchen und wie sich Dokumente aufeinander beziehen sollten, und ließ den umgebenden Text von einem LLM generieren. Anschließend mischte es veraltete Versionen, Widersprüche, indirekte Verweisketten, variierende Formulierungen und sehr lange Dokumente hinein.

Derselbe Retrieval-Agent wurde unter zwei Bedingungen getestet: Search, mit Stichwortsuche über die Originaldokumente, und Wiki, mit Zugriff auf ein von OpenWiki kompiliertes Wiki. Modell, Anweisungen, Dokumente und Fragen blieben konstant. Es gab 80 einfache Nachschlagefragen und 50 vernetzte Fragen, bei denen Abhängigkeiten über Dokumente hinweg verfolgt werden müssen, jeweils dreimal gestellt. LangChain bewertete Genauigkeit, Konsistenz (Überschneidung der zitierten Belege über mehrere Durchläufe) sowie Kosten und Latenz.

OpenWiki kompilierte die Bibliothek für 4,15 US-Dollar zu einem Wiki, das etwa ein Zehntel der ursprünglichen Größe hatte. Das spätere Hinzufügen von 17 Dokumenten kostete rund 0,09 US-Dollar pro Dokument. Die berichteten Ergebnisse schließen Kompilierungs- und Aktualisierungskosten nicht ein.

Wo das Wiki half und wo nicht

Bei einfachen Nachschlagefragen schnitten Suche und Wiki ähnlich ab: 0,84 gegenüber 0,83 Genauigkeit, 0,72 gegenüber 0,74 Überschneidung der Zitate und 0,020 gegenüber 0,021 US-Dollar pro richtiger Antwort. Die Latenz stieg mit dem Wiki von 9 auf 12 Sekunden.

Bei vernetzten Fragen stieg die Genauigkeit von 0,10 mit reiner Suche auf 0,52 mit dem Wiki. Die Kosten pro richtiger Antwort sanken von rund 0,55 auf 0,19 US-Dollar, weil der kompilierte Kontext dem Agenten erlaubte, Zusammenhänge mit weniger Tool-Aufrufen zu finden.

Die Konsistenz der Zitate blieb eine Schwachstelle. Die Überschneidung fiel von 0,74 bei einfachen Nachschlagefragen auf 0,25 bei vernetzten Fragen. LangChain weist darauf hin, dass diese Kennzahl nichts über die Korrektheit aussagt. Wechselnde Belege könnten jedoch eine Antwort verändern, vor allem bei widersprüchlichen Quellen, und Teams bräuchten Antworten, die sich reproduzieren und prüfen lassen.

Ein Evidenzgraph als Ergänzung

Um den Abruf reproduzierbarer zu machen, ergänzte LangChain einen schlanken Evidenzgraphen, der Wiki-Zitate in explizite, typisierte Kanten zwischen Claims, Wiki-Seiten, Absätzen und Themen überführt. Er entsteht in zwei Schritten. Ein deterministischer Prozess zerlegt jedes Dokument in Absätze mit eindeutigen Kennungen, sodass Claims auf exakte Passagen statt auf ganze Dokumente verweisen. Absätze, Claims und Seiten werden dann über typisierte Kanten verbunden: Claims zitieren Absätze, neuere Dokumente ersetzen ältere, und Abschnitte verweisen auf andere Dokumente.

Da Wiki-Claims bereits Textzitate enthalten, lassen sich Kanten wie refers_to und supersedes ohne weiteren Modellaufruf erzeugen. Laut LangChain dauerte der Aufbau des Graphen weniger als eine Sekunde und löste jeden expliziten Querverweis in der Testbibliothek auf. Aus dem Wiki abgeleitete Kanten hängen dem Unternehmen zufolge weiterhin von der Genauigkeit der modellgenerierten Zitate ab.

Zwei Werkzeuge ermöglichen dem Agenten die Navigation im Graphen: locate findet einen zur Frage passenden Startpunkt, expand folgt dessen Verbindungen zu stützenden Passagen. Im Vergleich zum Wiki allein verdoppelte der Graph die Zitatkonsistenz, verbesserte die Genauigkeit um 27 % und senkte die Kosten pro richtiger Antwort um 58 %, berichtet LangChain.

Was das für Teams bedeutet, die Agenten bauen

LangChains Fazit: Kompiliertes Gedächtnis sollte man sich für wiederkehrendes quellenübergreifendes Schlussfolgern aufheben. Bei einfachen Nachschlagefragen war der Agent ohne Gedächtnis ebenso genau und schneller. Wo Fragen von Beziehungen zwischen Dokumenten abhängen, erfasst das Wiki laut dem Unternehmen das Domänenwissen, und der Evidenzgraph sorgt für genaueren und besser wiederholbaren Abruf. Die Ergebnisse stammen aus einem von LangChain erstellten synthetischen Versicherungskorpus, sie beschreiben also den eigenen Benchmark und nicht reale Unternehmensbibliotheken.