Von der richtigen Antwort zur erledigten Aufgabe: Wie sich die KI-Evaluation entwickelt hat

Die historische Frage: Was bedeutet es, eine KI-Fähigkeit zu evaluieren?

Eine Fähigkeit künstlicher Intelligenz zu evaluieren bedeutet, eine weit gefasste Frage – etwa, ob ein System Anweisungen versteht oder bei der Problemlösung helfen kann – in einen Test mit Aufgaben, Bedingungen und einer Regel zur Bewertung der Ergebnisse zu übersetzen. Die erzielte Punktzahl misst nicht die Fähigkeit an sich. Sie fasst die Leistung unter den konkret festgelegten Bedingungen zusammen.

Eine richtige Antwort auf eine Frage, eine Lösung, die Softwaretests besteht, und eine Aktion, die eine Anwendung in den gewünschten Zustand versetzt, sind unterschiedliche Arten von Evidenz. Sie lassen sich nicht als austauschbare Einheiten behandeln. Jede macht bestimmte Erfolge und Fehler sichtbar und lässt andere außer Acht. Die Geschichte der Evaluation lässt sich daher zum Teil als Wandel der jeweils bewerteten Einheit lesen: zunächst Antworten auf klar abgegrenzte Beispiele, dann vielfältigere Aufgabensammlungen und bei einigen neueren Benchmarks schließlich Folgen ausgeführter Aktionen in Umgebungen.

Diese Abfolge dient als Interpretationsrahmen, nicht als lückenlose Chronologie oder als unvermeidliche Treppe zu einem besseren Maß. Die ausgewählten Arbeiten stehen für unterschiedliche Ansätze. Ein Benchmark mit Antwortaufgaben kann für eine eng umrissene Frage geeignet sein. Ein interaktiver Benchmark kann direktere Evidenz zur Ausführung liefern, bringt aber zugleich Abhängigkeiten von Umgebung und Protokoll mit sich.

Die erste Phase: klar abgegrenzte Aufgaben und bewertbare Antworten

Bei einer Evaluation auf Grundlage von Datensätzen enthält jedes Beispiel eine Eingabe und legt fest, welche Ausgabe als richtig gilt oder welches Kriterium anzuwenden ist. Beim Sprachverständnis kann die Eingabe aus einem Satz oder einem Satzpaar bestehen; die Ausgabe kann ein Label, eine Bewertung oder eine Antwort sein. Das aggregierte Ergebnis ermöglicht den Vergleich von Systemen, die dieselbe Aufgabe unter einem gemeinsamen Protokoll bearbeitet haben.

Dieses Design bietet praktische Vorteile. Beispiele lassen sich wiederholen, Ergebnisse konsistent berechnen und Methoden vergleichen, ohne dass die Systeme eine vollständige Anwendung bedienen müssen. Geht es um die Frage, ob ein Modell eine bestimmte semantische Beziehung erkennt, kann eine klar definierte Klassifikationsaufgabe nützliche Evidenz liefern.

Die bewertete Einheit bleibt jedoch eng gefasst. Ein richtiges Label zeigt nicht, dass das System eine Reihe von Schritten planen, Werkzeuge einsetzen, auf eine unerwartete Änderung reagieren oder eine Aufgabe in einer Benutzeroberfläche erledigen kann. Auch erklärt eine aggregierte Punktzahl für sich genommen nicht, wo sich Fehler häufen. Datenabdeckung, Fragestellung und gewählte Metrik begrenzen, welche Schlussfolgerungen sich ziehen lassen.

Eine vorsichtige Schlussfolgerung ist daher an Bedingungen geknüpft: Das System hat bei diesen Aufgaben, mit diesen Daten und nach dieser Bewertungsregel ein bestimmtes Ergebnis erzielt. Für weiterreichende Aussagen über allgemeine Kompetenz, Robustheit oder Nutzen in einer realen Situation sind zusätzliche Tests erforderlich.

Das Testfeld erweitern: GLUE und BIG-bench

GLUE, 2018 vorgestellt, bündelt mehrere Aufgaben zum Verständnis natürlicher Sprache in einem Multitask-Benchmark und einer Analyseplattform. Der Schwerpunkt verschiebt sich damit von einem einzelnen Test auf eine Gruppe verwandter Probleme: Es lässt sich beobachten, ob ein System bei unterschiedlichen Aufgaben Ergebnisse erzielt, und ein Teil dieser Leistung kann zusammengefasst werden. Die Aufgabenvielfalt erschwert es, die Evaluation auf eine einzige Fähigkeit zu reduzieren. Sie beseitigt jedoch weder die Einschränkungen der einzelnen Aufgaben noch macht sie das aggregierte Ergebnis zu einem universellen Maß.

BIG-bench erweiterte die Vielfalt der zusammengeführten Tests noch stärker. Statt sich auf eine vergleichsweise eng umrissene Familie sprachlicher Probleme zu konzentrieren, umfasst der Benchmark eine breite Sammlung von Aufgaben, die von verschiedenen Mitwirkenden beigesteuert wurden und unterschiedliche Ziele und Bewertungsformen haben. Die Arbeit untersucht, wie Sprachmodelle in dieser Sammlung abschneiden und wie sich Ergebnisse mit unterschiedlicher Modellgröße verändern.

Die wichtige Veränderung besteht nicht einfach darin, mehr Beispiele hinzuzufügen. Eine heterogene Sammlung kann unterschiedliche Fähigkeiten und Verhaltensweisen prüfen und zeigen, dass ein System, das bei einer Aufgabe gut abschneidet, nicht zwangsläufig auch bei einer anderen erfolgreich ist. Zugleich erschwert diese Vielfalt den Vergleich: Aufgaben können unterschiedliche Formate, Metriken und Schwierigkeitsgrade haben. Eine aggregierte Zahl erleichtert den Überblick, kann aber wichtige Unterschiede zwischen den Bestandteilen verdecken.

In beiden Fällen bleibt die Evaluation hauptsächlich ein Test von Antworten auf vorab definierte Aufgaben. Viele Aufgaben zu haben bedeutet nicht, einen Agenten bei der Arbeit in einer offenen Umgebung zu beobachten. Die größere Breite verbessert die Abdeckung innerhalb der Sammlung. Sie garantiert weder, dass diese Sammlung alle möglichen Anwendungen repräsentiert, noch dass sie längere Ausführungsprozesse misst.

Die bewertete Einheit ändern: ein Problem in einem Repository lösen

SWE-bench verschiebt die bewertete Einheit hin zu einer Aufgabe aus der Softwareentwicklung: Probleme in realen GitHub-Repositories zu lösen. Statt ausschließlich eine textuelle Antwort auf eine Frage zu bewerten, muss das System mit dem Kontext eines Projekts arbeiten und Codeänderungen erstellen, die auf das beschriebene Problem eingehen.

Der Patch kann anhand der Projekttests geprüft werden, darunter Tests zum beschriebenen Fehler und Tests, die weiterhin erfolgreich sein sollten. So entsteht Evidenz für etwas Konkreteres als eine überzeugend formulierte Erklärung: ob die vorgeschlagene Änderung nach den im Benchmark verfügbaren Prüfungen funktioniert. Der Evaluator kann feststellen, ob das Ergebnis diese Tests besteht. Das bedeutet nicht, dass damit die einzig richtige Lösung bestätigt, das Design in jeder Hinsicht für gelungen befunden oder die Sicherheit für jede Bereitstellung gewährleistet wäre.

Das evaluierte System besteht dabei nicht unbedingt nur aus dem isoliert betrachteten Modell. Je nach Konfiguration kann das Ergebnis davon abhängen, wie das Repository bereitgestellt wird, welche Werkzeuge zum Prüfen oder Bearbeiten von Dateien zur Verfügung stehen, wie viele Versuche erlaubt sind und nach welchem Verfahren die Tests ausgeführt werden. Um Punktzahlen zu vergleichen, ist es wichtig zu wissen, welche Komponenten einbezogen sind und ob das Protokoll unverändert blieb.

Auch diese Evaluation basiert auf einer festgelegten Sammlung von Problemen und Ausführungsbedingungen. Ein Problem zu lösen belegt daher den Erfolg in diesem konkreten Fall und gemäß den dazugehörigen Prüfungen – nicht die Fähigkeit, jedes beliebige Softwareproblem zu beheben. Ein Repository-Test bringt die Aufgabe näher an eine konkrete berufliche Tätigkeit heran, deckt aber nicht automatisch Produktanforderungen, Zusammenarbeit, langfristige Wartung oder die Folgen einer Änderung im Produktivbetrieb ab.

Interaktion und Zustand einbeziehen: Aufgaben in Computerumgebungen

OSWorld evaluiert multimodale Agenten anhand offener Aufgaben in realitätsnahen, simulierten Computerumgebungen. Statt lediglich eine Antwort zu einer Anwendung zu formulieren, muss ein Agent möglicherweise die Benutzeroberfläche beobachten und über Eingabemittel wie Tastatur oder Maus handeln, um einen gewünschten Zustand herzustellen. Im Mittelpunkt stehen Aufgaben, die in der Umgebung ausgeführt werden, nicht nur die sprachliche Qualität einer Beschreibung.

Durch diese Änderung lassen sich Dimensionen beobachten, die ein Antworttest nicht unmittelbar erfasst: ob Aktionen ausgeführt werden, ob eine Aktionsfolge das vorgesehene Ergebnis erreicht und ob der Endzustand eine Bewertungskondition erfüllt. Auch der Zusammenhang zwischen Wahrnehmung, Entscheidung und Handlung wird deutlicher. Ein System kann korrekt beschreiben, was zu tun wäre, und trotzdem außerstande sein, es umzusetzen. In einer interaktiven Umgebung kann dieser Unterschied Teil des Ergebnisses sein.

Die Ausführung liefert ein Signal, das näher an der operativen Aufgabe liegt. Trotzdem muss weiterhin festgelegt werden, was als Erfolg gilt. Umgebung, Anwendungen, Ausgangszustand, Anweisungen, Werkzeuge und Verifikator gehören zu den Testbedingungen. Vergleicht die Evaluation Zustände anhand automatisierter Regeln, können diese Regeln bestimmte Aspekte des Ergebnisses prüfen. Sie bewerten damit nicht zwangsläufig jedes Detail der Qualität, Sicherheit oder Zweckmäßigkeit des eingeschlagenen Vorgehens.

Außerdem muss man Agent und Umgebung auseinanderhalten. Eine Punktzahl, die mit bestimmten Werkzeugen und Steuerelementen erzielt wurde, beschreibt nicht automatisch, was das Modell ohne diese Hilfsmittel, mit einer anderen Benutzeroberfläche oder unter nicht berücksichtigten Bedingungen leisten würde. Das Ergebnis bezieht sich auf das evaluierte System und Protokoll, nicht auf eine isolierte Fähigkeit sämtlicher beteiligter Komponenten.

Was sich mit einer ausführbaren Umgebung ändert – und was bleibt

Der Wechsel von bewerteten Antworten zu ausführbaren Aufgaben erweitert die beobachtbare Evidenz. Er kann zeigen, ob das System eine Änderung in einem Repository oder einer Anwendung bewirkt, statt lediglich eine plausibel klingende Lösung zu formulieren. Für Aussagen über Handlungsfähigkeit ist das ein relevanter Unterschied. Ein Benchmark wird dadurch jedoch nicht automatisch zu einem vollständigen Maß für Nutzen, Autonomie oder Zuverlässigkeit.

Vier Elemente sollten getrennt betrachtet werden. Die Aufgabe legt fest, was verlangt wird. Die Umgebung bestimmt, wo und unter welchen Bedingungen es stattfindet. Der Verifikator legt fest, welche Ergebnisse er als zufriedenstellend bewertet. Und das evaluierte System umfasst die Komponenten, die die Aufgabe erhalten und Aktionen ausführen. Eine Änderung an einem dieser Elemente kann die Schwierigkeit oder Bedeutung der Punktzahl verändern. Werden Ergebnisse aus unterschiedlichen Protokollen verglichen, ohne diese Veränderungen zu berücksichtigen, schreibt man dem Modell womöglich etwas zu, das teilweise auf andere Bedingungen zurückgeht.

Die Gültigkeit des Verifikators verdient besondere Aufmerksamkeit. Ein automatisierter Test kann reproduzierbar und nützlich sein, prüft aber nur das, was er tatsächlich abdeckt. Eine unvollständige Testsuite könnte einen nicht erfassten Fehler übersehen. Eine Prüfung des Endzustands könnte einen ineffizienten Weg dorthin unberücksichtigt lassen, wenn Effizienz nicht Teil des Kriteriums ist. Das sind allgemeine Möglichkeiten, die für jeden Benchmark untersucht werden müssen – keine Mängel, die man ohne Belege einer bestimmten Evaluation zuschreiben sollte.

Auch die Reproduzierbarkeit hängt von operativen Details ab: Softwareversionen, Ausgangszustand, Werkzeugzugriff, Zeitbudget oder Anzahl der Versuche. Eine Beschreibung dieser Grenzen erleichtert die Einordnung des Ergebnisses. Fehlen solche Angaben, kann der Vergleich weniger aussagekräftig sein. Dann ist es besser, die Unsicherheit zu benennen, statt Lücken mit Annahmen zu füllen.

Eine historische Punktzahl richtig lesen

Eine historische Punktzahl braucht Kontext. Zuerst sollte man feststellen, welche Version des Benchmarks und welches Protokoll verwendet wurden. Dieselbe Bezeichnung kann sich auf unterschiedliche Aufgabensammlungen, Metriken oder Konfigurationen beziehen. Bevor zwei Werte verglichen werden, ist zu prüfen, ob sie hinreichend vergleichbare Tests beschreiben.

Als Nächstes ist die bewertete Einheit zu bestimmen. Wurde eine einzelne Antwort, eine Sammlung von Antworten, ein getesteter Patch oder eine Aufgabe in einer Benutzeroberfläche bewertet? Davon hängt ab, welche Art von Evidenz das Ergebnis liefert. Der Anteil richtiger Antworten und die Quote erledigter Aufgaben sind keine gleichwertigen Skalen, auch wenn beide als Prozentwerte ausgedrückt werden.

Danach empfiehlt es sich, das aggregierte Ergebnis von seiner Aufschlüsselung zu trennen. Bei einem Multitask-Datensatz können Ergebnisse je Aufgabe Stärken und Schwächen offenlegen, die im Durchschnitt verschwinden. Bei interaktiven Evaluationen ist wichtig, welche Ausführungsbedingungen konstant gehalten wurden und welche Zustände der Verifikator als zufriedenstellend bewertete. Sofern detaillierte Ergebnisse vorliegen, helfen sie zu vermeiden, dass eine zusammenfassende Zahl zu einer weitergehenden Aussage wird, als die Evidenz zulässt.

Schließlich belegt eine Verbesserung zwischen Evaluationen nicht für sich genommen, um wie viel eine allgemeine Fähigkeit zugenommen hat. Ändern sich gleichzeitig das Modell, die Aufgabensammlung, die Werkzeuge oder die Bewertungsregeln, lässt sich die gesamte Veränderung ohne zusätzliche Analyse nicht einer einzelnen Ursache zuschreiben. Ein Vergleich ist belastbarer, wenn die Bedingungen gleich bleiben oder Unterschiede präzise beschrieben werden.

Fazit: Die Evidenz passend zur Aussage auswählen

GLUE und BIG-bench zeigen zwei Möglichkeiten, Evaluationen mit Schwerpunkt auf Antworten zu erweitern: verwandte Aufgaben zusammenzuführen oder eine vielfältigere Sammlung abzudecken. SWE-bench und OSWorld veranschaulichen Ansätze, bei denen ausführbare Ergebnisse in Repositories und Computerumgebungen in den Mittelpunkt rücken. Sie sind keine austauschbaren Stufen einer Rangliste. Sie beantworten unterschiedliche Fragen und liefern unterschiedliche Arten von Evidenz.

Geht es um Antworten auf sprachliche Aufgaben, kann ein passender Datensatz ein nützlicher Test sein. Soll untersucht werden, wie sich die Leistung über mehrere Aufgaben verteilt, kommt es auf eine Multitask-Evaluation und ihre aufgeschlüsselten Ergebnisse an. Bezieht sich die Aussage darauf, ein Projekt zu ändern oder Aktionen in einer Anwendung auszuführen, kann eine ausführbare Evaluation direktere Evidenz zu solchen operativen Ergebnissen liefern.

Die abschließende Regel ist einfach: Eine Punktzahl ist auf der Ebene des Tests zu interpretieren, aus dem sie hervorgegangen ist. Eine nutzungsnähere Evaluation kann mehr über Aktionen und Zustände zeigen, misst aber nicht für sich allein sämtliche Aspekte eines nützlichen, sicheren oder zuverlässigen Systems. Für solche Schlussfolgerungen braucht es transparente Protokolle und ergänzende Evidenz, die zur jeweiligen Aussage passt.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.