Agenten scheitern früh und merken es zuletzt

Ein Programm, das eine Aufgabe selbständig in einer Kommandozeile erledigt, produziert dabei eine Spur: Befehl, Ausgabe, nächster Befehl, ein gescheiterter Lauf im Median siebenundzwanzig Schritte lang. Am Ende steht bestanden oder nicht bestanden. Das meiste, was an solchen Systemen gemessen wird, steht in dieser letzten Zeile.

Die Spur davor erzählt etwas anderes.

Aus 3.843 aufgezeichneten Läufen – sieben Spitzenmodelle, drei verschiedene Agenten-Gerüste, eine Aufgabensammlung für Kommandozeilenarbeit – blieben nach einer Angleichung des Vergleichsgitters 1.794 übrig, verteilt auf 89 Aufgaben, für die das volle Gitter aus 21 Modell-Gerüst-Kombinationen vorliegt – abzüglich fünfundsiebzig Läufe, die auch dort nicht zustande kamen.

Die Fehlschläge darunter wurden Schritt für Schritt eingeordnet, nach festem Schema und Codebuch: ein Modell schreibt den Entwurf samt Belegstellen, zwei Menschen prüfen jede Trajektorie und entscheiden jedes Etikett. Deren Übereinstimmung ist hoch, und Schema, Codebuch und annotierter Datensatz sind veröffentlicht.

Was dabei herauskommt, ordnet den Fehler nicht als Ereignis, sondern als Verlauf: Wo setzt er ein, wie entwickelt er sich, an welcher Stelle ist er nicht mehr einzuholen.

Der erste Befund: Knapp drei Fünftel der Fehlschläge gehen auf epistemische Fehler zurück – die Information, die den Fehler verhindert hätte, lag bereits vor und wurde übersehen, vergessen oder falsch gedeutet. Der häufigste Einzelauslöser darin, knapp ein Drittel aller entscheidenden Fehler, ist die ungeprüfte Annahme: Der Agent glaubt, eine Datei liege dort, wo sie nicht liegt. Er nimmt an, ein Schritt sei geglückt, den er nie geprüft hat. Von da an arbeitet er sauber weiter, nur eben in einer Welt, die es nicht gibt. Ein weiteres knappes Drittel ist schlichtes Nichtkönnen, und nur jeder zehnte Fehlschlag geht auf die Umgebung.

Der zweite Befund verschärft den ersten: Diese Fehler entstehen typischerweise in den ersten paar Schritten. Der entscheidende Fehler liegt im Median bei Schritt sieben – nicht dort, wo es kompliziert wird, sondern gleich am Anfang, wenn noch alles einfach aussieht. Das Zeitfenster danach ist knapp, aber nicht geschlossen: Im Median bleibt ein einziger Schritt, in gut vier von zehn Fällen allerdings drei oder mehr. Die Autoren lesen es als messbare Gelegenheit zum Eingreifen.

Der dritte Befund verschiebt, wo der Unterschied liegt. Gescheiterte Läufe bekommen fast genauso oft ein sichtbares Fehlersignal wie geglückte, 72 gegen 74 Prozent – was sie unterscheidet, ist, was damit geschieht: Solange eine Rettung überhaupt noch möglich ist, reagieren 92 Prozent der erfolgreichen Läufe mit Signal auf mindestens eines, aber nur 37 Prozent der gescheiterten. Das Signal kommt allerdings zu spät, und zwar der Regel nach: Verloren ist der Lauf im Median um Schritt zwölf, sichtbar wird der Schaden erst um Schritt sechzehn. Diese Zahl gilt nur für die Läufe, die überhaupt ein Signal bekommen – bei den übrigen wird nie eines sichtbar. So oder so bleibt der Fehler oft verborgen, bis nichts mehr zu retten ist.

Für die gängige Praxis ist das unbequem, und die Autoren ziehen daraus den Schluss: Zuverlässigkeit verlangt früheres Prüfen und Eingreifen, statt sich allein auf die Bewertung des Endergebnisses zu verlassen. Eine Bewertung, die nur das Ende ansieht, kann den Anfang des Scheiterns systematisch verfehlen – sie beschreibt einen Zustand, dessen Ursache zwanzig Schritte zurückliegt: entscheidender Fehler bei Schritt sieben, Ende des Laufs bei Schritt siebenundzwanzig.

Der bemerkenswerteste Satz der Arbeit ist deshalb kein Ergebnis, sondern eine Umdeutung: Scheitern ist keine Eigenschaft des Endes, sondern eine Geschichte mit einem Anfang.

Was dagegen spricht¶

Der entscheidende Fehler wird rückblickend bestimmt, über den ganzen Lauf hinweg – und ist nicht notwendigerweise der erste, der auftritt. Das ist methodisch sauber, macht die Erzählung vom klaren Anfang aber weicher, als sie klingt: Erkennbar ist er erst, wenn man das Ende schon kennt. Genauso ist „nicht mehr einzuholen" eine Beobachtung, keine Aussage über Unmöglichkeit – die Autoren schreiben es selbst.

Das Zurückschneiden auf 89 Aufgaben kostet gut die Hälfte der 3.843 aufgezeichneten Läufe, und die abgebrochenen fielen schon davor heraus. Für die Abbrüche nennen die Autoren Infrastrukturgründe, die sich nicht annotieren lassen; das Zurückschneiden begründen sie anders: Sie behalten nur Aufgaben mit vollständigem Raster, damit die Vergleiche zwischen den Systemen fair bleiben. Die Schwierigkeitsverteilung des Restsatzes weisen sie aus. Bleibt: gemessen wurde auf einer einzigen Aufgabensammlung für Terminalarbeit, in drei Gerüsten und einem Zeitfenster, und die Vergleiche zwischen Systemen sind beobachtend, nicht ursächlich.

Am schwersten wiegt die eigene Gegenprobe. Um zu prüfen, ob sich das Scheitern überhaupt in Echtzeit erkennen ließe, bauen die Autoren einen Wächter, der laufende Spuren mitliest. Er erkennt einen bereits verlorenen Lauf zuverlässig – nur eben zu spät: Sein Vorlauf ist im Median null, und weniger als jeder zehnte Fehlschlag wird vor dem Punkt der Unrettbarkeit gemeldet. Sagt man ihm zusätzlich, was die Aufgabe verlangt, steigt seine Trefferquote von 18 auf 29 Prozent. Das Fenster ist also da; es automatisch zu nutzen scheitert bislang am Wächter und daran, dass ihm die Anforderung fehlt, gegen die er urteilen müsste.

Warum das hier steht¶

Weil es die Frage verschiebt, statt sie zu beantworten. Die verbreitete Messgröße ist die Erfolgsquote – sie liegt in diesen Läufen zwischen 19 und 45 Prozent –, und sie sieht systematisch am falschen Ort nach. Dazu kommt eine Zahl, die jeder wiedererkennen wird, der solchen Läufen zusieht: Gut ein Viertel der gescheiterten Läufe meldet am Ende Erfolg. Das Beunruhigende ist nicht der Lauf, der abbricht. Es ist der, der bis zum Schluss überzeugend aussieht.

Gegenprüfung

Von drei Modellfamilien gegen den Volltext der Quelle gelesen; Befunde und Korrekturen stehen im Protokoll.claude · gemini · grokPrüfprotokoll zu dieser Notiz →