Ein Agenten-Benchmark hat zwei Aufgaben: den Agenten ausführen und anschließend ehrlich berichten, was geschehen ist. Wir konzentrieren uns auf die erste und behandeln die zweite wie nebensächliche Infrastruktur. Sobald das Ergebnis über einen Modelleinsatz mitentscheidet, ist das ein Fehler.

Ich habe die am 25. Oktober veröffentlichten Versionshinweise zu Inspect AI 0.3.284 und eine Arbeit zur Zuverlässigkeit von Agenten-Rankings gelesen. Inspect korrigiert Fehler in der Beweiskette: Unerwartete Fehler von Hintergrundagenten lassen eine Testprobe nun scheitern; wiederhergestellte Proben behalten Eingabe, Ziel, Bewertungen, Ausgabe und Nachrichtentext; protokollierte Modelleingaben und -ausgaben ändern sich nicht mehr rückwirkend, wenn ein Agent eine Nachricht bearbeitet. Auch ein durch native Kontextkomprimierung doppelt eingefügter Prompt wurde korrigiert. Das sind Korrekturen am Evaluator, keine Verbesserung des Modells. [1]

Ein gescheiterter Unteragent ist kein Erfolg

Stellen wir uns vor, ein Agent delegiert eine Aufgabe, formuliert danach eine überzeugende Antwort, aber sein Hintergrundarbeiter ist unerwartet ausgefallen. Wird die Probe wegen der eleganten Antwort als Erfolg gezählt, belohnt der Benchmark eine unvollständige Ausführung. Die in Inspect dokumentierte Fehlerweitergabe betrifft genau diese Buchführung. Sie garantiert nicht, dass jede Aufgabe einen unabhängigen Test des tatsächlich erreichten Zustands besitzt. [1]

Eine Antwort kann eine gelesene Quelle behaupten, obwohl sie nicht abgerufen wurde; sie kann eine erledigte Änderung beschreiben, die nie wirksam wurde. Das sind illustrative Beispiele, keine von Inspect gemeldeten Vorfälle. Wer nur die Erzählung bewertet, kann einen glänzend formulierten Fehlschlag höher bewerten als einen holprig beschriebenen Erfolg.

Wiederholungen machen es schwieriger. Der erste Versuch kann scheitern und ein späterer gelingen. Erstversuchserfolg, Erfolg nach Wiederholung, Gesamtkosten und Stabilität über unabhängige Läufe sind unterschiedliche Größen. Gehen bei der Wiederherstellung Ziel oder frühere Bewertungen verloren, verschwindet möglicherweise auch die Evidenz für den Fehlschlag. Die korrigierten Felder und Nachrichtentexte sind deshalb für Vergleiche wichtig. Ich habe die konkreten Fehler allerdings nicht selbst reproduziert. [1]

Mehr Aufgaben reparieren keinen falschen Schluss

Die Forschungsarbeit untersucht 22 Agenten-Benchmarks und trennt zwei Aussagen: Das Ranking einer festgelegten Kombination aus Modell und Scaffold ist nicht dasselbe wie ein vom Scaffold unabhängiges Ranking der Modelle. Für die einzeln analysierten Evaluationen nennt das Abstract eine geschätzte Ranking-Zuverlässigkeit von 0,935–0,994 für feste Kombinationen und 0,148–0,841 für die zugrunde liegenden Modelle. Diese Schätzungen beruhen auf einer bayesschen Varianzzerlegung und gelten nicht automatisch für jeden Benchmark. [2]

Unter den untersuchten Bedingungen würden sogar unendlich viele ähnlich konstruierte Aufgaben die Zuverlässigkeit des Modell-Rankings um höchstens 0,097 steigern, wenn die begrenzte Scaffold-Abdeckung dominiert. Das Zusammenführen verschiedener Benchmarks könnte laut Studie die aufgabenübergreifende Zuverlässigkeit beim gleichen Aufgabenbudget von 0,44 auf 0,75 erhöhen. Das sind statistische Projektionen der Autoren, keine garantierten Gewinne durch ein neues Werkzeug. [2]

Ich sehe hier zwei unabhängige Fehlerquellen. Das Protokoll kann falsch darstellen, was ein Lauf getan hat. Und selbst ein perfektes Protokoll kann nur einen engeren Vergleich tragen als die Schlagzeile behauptet. Besseres Logging hilft beim ersten Problem; unterschiedliche Scaffolds und Aufgaben beim zweiten.

Ein offenes Problem bleibt

Die Veröffentlichung ist kein Beweis für makellose Protokolle. Ein weiterhin offenes Inspect-Ticket beschreibt, dass eine erneute Bewertung mit Streaming und Überschreiben bei Fehler oder Unterbrechung das vollständige Eingabeprotokoll durch eine partielle Momentaufnahme ersetzen kann. Als Umgehung nennt das Ticket den Verzicht auf Streaming oder eine neue Ausgabedatei. Ich habe das nicht selbst getestet. Die Lehre ist trotzdem klar: Originalbelege vor einer Transformation bewahren. [3]

Auch die korrigierte nachträgliche Änderung protokollierter Modelleingaben verdient Aufmerksamkeit. Wenn sich ein Input-Protokoll nach der Antwort verändert, lässt sich nicht mehr sicher rekonstruieren, was wirklich evaluiert wurde. Eine Rangliste braucht unveränderliche Beobachtungen und nicht nur ordentlich formatierte Punktzahlen. Dass dieser Fehler behoben wurde, sagt noch nichts darüber aus, ob die Bewertungsregel richtig ist. [1]

So würde ich eine Rangliste prüfen

Zuerst die Behauptung festlegen: Geht es um eine konkrete Modell-Scaffold-Kombination auf bestimmten Aufgaben oder um das Modell über verschiedene Scaffolds hinweg? Veröffentlicht werden sollten Scaffold, Werkzeugrechte, Prompts, Kontextbehandlung, Wiederholungsregeln, Evaluator- und Aufgabenversion. Ein einzelner Modellname in der Tabelle trägt diese Informationen nicht.

Dann Fehler sichtbar machen: Unerwartete Fehler von Unteragenten müssen die Probe scheitern lassen oder gesondert ausgewiesen werden. Anfangseingaben, Ziel, Werkzeugspur, Modellnachrichten, Bewertungsregeln und Beleg für den Endzustand gehören zusammen. Vor erneuter Bewertung sollte eine unveränderte Kopie des Originals erhalten bleiben. Bei wiederhergestellten Läufen muss erkennbar sein, welcher Versuch die Wertung erzeugte.

Schließlich würde ich die Beweiskette absichtlich belasten: einen Unteragentenfehler auslösen, eine Nachricht nach dem Protokollieren verändern und eine Wiederherstellung unterbrechen. Danach würde ich den Bericht mit der beobachteten Ausführung vergleichen. Das ist ein vorgeschlagenes Prüfverfahren, kein von mir durchgeführter Test. Wer Aussagen über das Modell statt nur über eine konkrete Agentenkonfiguration machen will, muss zusätzlich verschiedene Scaffolds prüfen.

Ich habe weder Inspect noch ein Modell für diesen Beitrag benchmarked. Mein Fazit ist enger: Versioniert den Evaluator mit dem Modell, hebt Rohdaten auf und formuliert Rankings nur so weit, wie das Versuchslayout sie trägt. Der Benchmark ist Teil der Messapparatur. Wenn er Fehler, Wiederherstellung und Eingaben nicht zuverlässig festhält, erzeugen mehr Aufgaben nur sauber formatierte Verwirrung.

Quellen

[1] https://github.com/UKGovernmentBEIS/inspect_ai/releases/tag/0.3.284 [2] https://arxiv.org/abs/2610.00651 [3] https://github.com/UKGovernmentBEIS/inspect_ai/issues/5914