IBM-Framework reduziert Konsistenzlücke um 16 Punkte auf AppWorld

IBM-Framework reduziert Konsistenzlücke um 16 Punkte auf AppWorld

Ein auf arXiv veröffentlichtes Paper von IBM Software Innovation Lab und IBM Research stellt einen Self-Evolving-Agent-Ansatz vor, der die sogenannte Consistency Gap bei LLM-Agenten messbar reduziert. Das Paper trägt den Titel „Closing the Consistency Gap: Self-Evolving Agents That Learn to Stay on Course“. Die Differenz zwischen dem durchschnittlichen Erfolg pro Versuch (Mean@k) und der Wahrscheinlichkeit, alle k Versuche zu bestehen (Pass^k), sinkt auf dem AppWorld-Benchmark von 24,4 auf 12,0 Punkte. Konkret steigt Pass^5 von 53,0 auf 69,0 Prozent, während Mean@5 von 77,4 auf 81,0 Prozent zulegt. Die Autoren bezeichnen die Lücke als Voraussetzung für vertrauenswürdigen Agenteneinsatz. Das Framework besteht aus einem Consistency Analyzer und einem Guideline Generator, die instabile Entscheidungsschritte identifizieren und in wiederverwendbare Richtlinien überführen. Diese werden bei künftigen Ausführungen injiziert. Die Ergebnisse beziehen sich auf ReAct/GPT-4.1. Der Code ist als Open-Source-Toolkit ALTK-Evolve verfügbar.

Mean@k vs. Pass^k: Warum Durchschnittserfolg trügt

Mean@k misst den durchschnittlichen Erfolg pro Versuch, Pass^k die Wahrscheinlichkeit, alle k Versuche zu bestehen. Bei Erfolgsraten unter 100 Prozent fällt Pass^k schnell ab. Ein Agent, der eine Aufgabe in 61 Prozent der Fälle löst, schafft dieselbe Aufgabe in acht aufeinanderfolgenden Versuchen mit weniger als 25 Prozent Wahrscheinlichkeit. Konkretes Beispiel aus dem Paper: ReAct/GPT-4.1 auf AppWorld erreicht Mean@5 77 Prozent und Pass^5 53 Prozent – eine Lücke von 24 Punkten. Das bedeutet: Ein Agent kann im Durchschnitt drei von vier Aufgaben lösen, aber nur etwas mehr als die Hälfte der Aufgaben in allen fünf Läufen. Ursache sind flache Wahrscheinlichkeitsverteilungen an Entscheidungspunkten, bei denen das Modell zwischen fast gleichwertigen Optionen schwankt. Kleine Störungen wie Batch-Verarbeitung oder Fließkomma-Variationen können das Ergebnis kippen. Über viele verkettete Entscheidungen summieren sich diese Mikro-Abweichungen zu makroskopischer Inkonsistenz. Pass^k ist ein ehrlicherer Proxy für nutzerseitige Zuverlässigkeit als der Durchschnittserfolg.

Selbstheilende Agenten: Vom instabilen Schritt zur Guideline

Das Framework diagnostiziert zuerst, dann interveniert es. Ein Consistency Analyzer spielt aufgezeichnete Trajektorien durch kontrolliertes Resampling erneut ab und bewertet jeden Entscheidungsschritt auf Instabilität. Dafür sind keine Ground-Truth-Daten und kein erneutes Ausführen der Aufgabe nötig. Der Analyzer markiert Schritte, die bei Wiederholung kippen könnten. Ein Guideline Generator überführt die Diagnose in gezielte Richtlinien, die als episodisches Gedächtnis gespeichert und bei künftigen Ausführungen ähnlicher Aufgaben injiziert werden. Diese Richtlinien liefern deterministische Anweisungen für zuvor volatile Entscheidungen, ohne die Gesamtfähigkeit zu bestrafen. Auf AppWorld mit ReAct/GPT-4.1 erhöht das Framework den Anteil der Aufgaben, die in allen fünf Läufen gelingen, um 16 Punkte bei gleicher Aufgabe und um 13 Punkte bei ähnlicher Aufgabe. Konkret steigt Pass^5 von 53,0 auf 69,0 Prozent, Mean@5 von 77,4 auf 81,0 Prozent. Die Richtlinien generalisieren auch auf ein schwächeres Modell (gpt-oss-120b), was darauf hindeutet, dass sie wiederverwendbare Fehlermuster erfassen statt einzelne Trajektorien auswendig zu lernen.

Zuverlässigkeit als neues Schlachtfeld: Metriken, Horizonte und ein zweiter Gap

Die IBM-Arbeit ordnet sich in eine breitere Debatte um Agentenzuverlässigkeit ein. Eine Princeton-Studie, als Preprint im August dieses Jahres erschienen, schlägt zwölf Metriken entlang der Dimensionen Konsistenz, Robustheit, Vorhersagbarkeit und Sicherheit vor und findet bei 14 Modellen trotz Fähigkeitsgewinnen nur kleine Verbesserungen der Zuverlässigkeit. Daten von METR und Intuitionlabs zeigen, dass sich der 50-Prozent-Zuverlässigkeitshorizont für Langzeit-Agenten seit 2019 etwa alle sieben Monate verdoppelt, der 80-Prozent-Horizont aber deutlich kürzer bleibt. Das bedeutet: Gelegentlicher Erfolg bei langen Aufgaben bedeutet nicht verlässlichen Erfolg.

LangChain bietet mit seinen Checklisten und Observability-Primitiven wie Runs, Traces und Threads eine praktische Infrastruktur, um Agentenverhalten systematisch zu erfassen und zu bewerten. Diese Werkzeuge sind relevant, weil sie Teams ermöglichen, Fehlerquellen zu identifizieren und Evaluierungsdatensätze aus realen Traces zu erstellen – eine Voraussetzung, um Zuverlässigkeitsmetriken wie die Consistency Gap überhaupt messbar zu machen. Der IBM-Ansatz könnte von einer Integration in solche Plattformen profitieren, da die Diagnose instabiler Schritte auf aufgezeichneten Trajektorien basiert, die mit Observability-Tools gesammelt werden können.

Eine Studie über 33k von fünf Coding-Agenten verfasste Pull Requests auf GitHub zeigt, dass Dokumentations-, CI- und Build-Updates die höchste Merge-Erfolgsquote haben, während Performance- und Bugfix-Aufgaben am schlechtesten abschneiden. Nicht gemergte PRs umfassen oft größere Codeänderungen, berühren mehr Dateien und bestehen häufig die CI/CD-Validierung nicht.

ghx, ein deterministisches GitHub-Interface für KI-Agenten, adressiert einen anderen Zuverlässigkeits-Gap: Interface-Reibung. Diese entsteht, wenn Agenten bei jeder Sitzung erneut lernen müssen, wie sie mit GitHub interagieren – sie probieren CLI-Syntax aus, inspizieren Schemas, wiederholen fehlerhafte Payloads und normalisieren inkonsistente Antworten, bevor sie überhaupt mit der eigentlichen Aufgabe beginnen. Diese Reibung unterscheidet sich von der Consistency Gap: Während die Consistency Gap die Varianz der Ergebnisse bei identischer Aufgabe beschreibt, beeinträchtigt Interface-Reibung die Effizienz und Kontextnutzung, indem sie das Kontextfenster mit operationalem Rauschen füllt und so die Erfolgswahrscheinlichkeit senken kann, ohne dass die Aufgabe selbst variiert. ghx stellt typisierte Operationen und strukturierte Ergebnisse bereit, damit Agenten über Aufgaben nachdenken statt über die Schnittstelle.

Zwei Lücken, ein Begriff: Wo IBMs Ansatz nicht greift

Der Begriff „Gap“ ist doppelt belegt. IBM definiert Consistency Gap als Differenz zwischen Mean@k und Pass^k. plainenglish.io beschreibt mit „Gap“ dagegen Interface-Reibung: Agenten müssen bei jeder Sitzung neu lernen, mit GitHub zu sprechen, was das Kontextfenster mit operationalem Rauschen füllt. ghx soll diesen zweiten Gap schließen. Beide Probleme sind real, aber verschieden: Interface-Reibung ist ein eigenständiger Zuverlässigkeits-Gap, weil sie die Zuverlässigkeit auf einer anderen Ebene beeinträchtigt – sie verschwendet Kontextbudget und führt zu suboptimalen Entscheidungen, selbst wenn der Agent grundsätzlich konsistent wäre. Ein Agent, der die Schnittstelle beherrscht, kann trotzdem unter Consistency Gap leiden, und umgekehrt. IBMs Framework adressiert nur den ersten Gap. Es reduziert die Konsistenzlücke, nicht die Schnittstellenreibung. Offen bleibt, wie sich Konsistenzmetriken in bestehende Evaluierungsplattformen integrieren lassen. Die Princeton-Studie und LangChain bieten bereits Metriken und Observability, aber eine einheitliche Integration von Pass^k und Consistency Gap in Standard-Benchmarks fehlt bislang.