Dieselben verhaltensbasierten Leitlinien ließen die Aufgabenerfolgsquote von gpt-oss-120b um 16.1 Prozentpunkte steigen, bei GLM-5 bewegte sich dagegen nichts. In einer am 18. August veröffentlichten Versuchsreihe testete IBM Research acht Modelle und kam zu einem zentralen Schluss: Die richtige Dosis an Gedächtnis hängt davon ab, wie viel Spielraum das Modell selbst noch hat.
Die Experimente nutzten den AppWorld-Benchmark: 585 mehrstufige Aufgaben, davon 168 mit regulärem und 417 mit hohem Schwierigkeitsgrad, verteilt auf 9 simulierte Anwendungen wie Kalender, Nachrichten und Zahlungen.
Die Methode selbst ist nicht kompliziert: Der Agent durchläuft die Aufgaben zunächst einmal, aus erfolgreichen und gescheiterten Verläufen werden verhaltensbezogene Leitlinien destilliert und zu einer wiederverwendbaren Sammlung gebündelt; beim Inferenzieren werden diese Leitlinien dann wieder in den Kontext eingespeist. Es gibt zwei Arten der Einspeisung: entweder wird bei jedem Schritt der gesamte Regelsatz eingefügt, oder ein schlanker fester Kern bleibt bestehen und eine aufgabenrelevante Teilmenge wird per Retrieval nachgeladen. Derselbe Regelsatz, zwei Zufuhrarten, im direkten Vergleich.
Drei Modellstufen, drei unterschiedliche Optimallösungen
Bei den acht Modellen zeigt sich eine klare Aufteilung.
Die Stufe mit reichlich Spielraum – DeepSeek-V3.2 (671B MoE), Claude Opus 4.6 und GPT-5.5 – schneidet am besten ab, wenn der komplette Regelsatz eingespeist wird. Bei DeepSeek-V3.2 stieg die Aufgabenerfolgsquote um 9.5 Punkte, die Szenarienerfolgsquote um 16.1 Punkte; bei Claude Opus 4.6 waren es 4.1 und 7.1; bei GPT-5.5 2.9 und 7.2.
Die Stufe mit knapper Kapazität umfasst nur gpt-oss-120b (117B MoE). Der vollständige Regelsatz überflutet das Modell regelrecht; nach dem Wechsel zu selektivem Retrieval steigen beide Kennzahlen um jeweils 16.1 Punkte – der größte Zuwachs unter allen acht Modellen.
GLM-5 (745B MoE) fällt in die gesättigte Stufe: Es liegt bei dieser Aufgabenmenge bereits nah an seiner Obergrenze, weshalb sich mit oder ohne Gedächtnis bei beiden Kennzahlen nichts ändert – 0.0 Prozentpunkte.
Zwei Kennzahlen, getrennt betrachtet
TGC (Task Goal Completion) misst den Anteil der Einzelaufgaben, die der Agent vollständig und korrekt löst. SGC (Scenario Goal Completion) ist strenger: Ein Szenario bündelt mehrere Varianten derselben Aufgabe – andere Daten, andere Formulierung, andere Randbedingungen – und gilt nur als bestanden, wenn jede Variante besteht.
Der Wert dieser Trennung steckt in den Zahlen selbst: Bei DeepSeek-V3.2 stieg der TGC nur um 9.5 Punkte, der SGC dagegen um 16.1 Punkte. Dasselbe Muster zeigt sich bei Claude Opus 4.6 (4.1 gegenüber 7.1) und GPT-5.5 (2.9 gegenüber 7.2). Der Nutzen des Gedächtnisses zeigt sich stärker darin, "dieselbe Aufgabenart auch bei anderer Formulierung richtig zu lösen", als darin, "mehr neue Aufgaben zu lösen". Für Teams, die Produktivsysteme bauen, ist Ersteres eine deutlich seltenere Art von Gewinn als Letzteres.
Der Preis steht in Token
Die Kostenspalte ist der praktischste Teil der Studie. Bei vollständiger Einspeisung stieg der Token-Verbrauch pro Aufgabe bei DeepSeek-V3.2 von 148,000 auf 263,000 – ein Plus von 78%. gpt-oss-120b, ebenfalls mit vollständiger Einspeisung, stieg von 110,000 auf 166,000 – ein Plus von 51%. Nach dem Wechsel zu selektivem Retrieval lag der Verbrauch von gpt-oss-120b nur noch bei 116,000, ein Plus von lediglich 5% – dafür aber 16.1 Prozentpunkte mehr Leistung.
Stellt man beide Werte nebeneinander, ergibt sich eine grobe Kosteneffizienzrechnung: gpt-oss-120b tauscht 5% zusätzliche Token gegen 16.1 Punkte, DeepSeek-V3.2 tauscht 78% zusätzliche Token gegen 9.5 Punkte (nach TGC). Pro 1% zusätzlichem Token-Einsatz entspricht das beim ersten Modell rund 3.2 Prozentpunkten, beim zweiten nur rund 0.12 – ein Unterschied um mehr als das Zwanzigfache. Bei nach Token abgerechneten Produktivsystemen reicht diese Lücke aus, um "dem starken Modell einfach das gesamte Gedächtnis zu geben" zu einer Rechnung zu machen, die sich nicht mehr trägt.
Gelernt wird außerhalb des Modells
Die Autoren fügen einen Satz hinzu, der die Grenze dieses Ansatzes markiert:
Learning happens around the model, not inside it.
Gelernt wird rund um das Modell, nicht in seinem Inneren.
Die Leitlinien verändern die Kontextumgebung des Agenten, während die Modellgewichte unangetastet bleiben. Der Vorteil: Sie lassen sich jederzeit hinzufügen oder entfernen, sind prüfbar und beim Modellwechsel einfach austauschbar. Genau dort liegt aber auch die Grenze – jeder Gewinn ist durch Kontextfenster und Inferenzkosten begrenzt und kippt ab einem bestimmten Punkt ins Gegenteil, wie es bei gpt-oss-120b geschah, als der vollständige Regelsatz es überflutete.
Die Arbeit stammt von IBM Research, gezeichnet von zehn Autorinnen und Autoren, darunter Vatche Isahagian, Evelyn Duesterwald und Vinod Muthusamy; Code und Methode sind unter dem Namen ALTK-Evolve veröffentlicht.
Für Teams, die Agenten gerade mit Gedächtnis ausstatten, ist die aus diesen Daten ableitbare Vorgehensreihenfolge nützlicher als das Fazit selbst: zuerst den Basis-Spielraum des Modells bei der Zielaufgabe messen; bei knappem Spielraum selektives Retrieval einsetzen; bei reichlich Spielraum lässt sich vollständige Einspeisung erwägen; und bei einem Modell, das bereits nahe an seiner Obergrenze liegt, die Token sparen und das Budget anderswo einsetzen.
Quellen: Technikblog von IBM Research und Hugging Face, CocoLoop; die Zusammensetzung der 585 AppWorld-Aufgaben, die TGC/SGC-Prozentpunktveränderungen der acht Modelle sowie die Token-Kosten je Konfiguration wurden anhand der veröffentlichten Versuchsdaten überprüft.