AesCode Infographics Chart: Was die Evidenz überprüfbar macht – und was für Vergleiche noch fehlt

Stand der Evidenz: Dokumentation und Code sind verfügbar, aber keine vollständige Reproduktion

Die öffentliche AesCode-Dokumentation belegt mehr als nur, dass es eine Suite mit einem Kanal namens Chart gibt. Das offizielle Repository beschreibt das Evaluierungssystem, führt Prüfer auf und enthält Anleitungen zu ihrer Ausführung. Das Modellprofil ergänzt Ergebnisse, Generierungsbedingungen und eine allgemeine Beschreibung der Bewertung. Daher lassen sich das angekündigte Design untersuchen und Teile des Harness mit eigenen Daten ausführen.

Das bedeutet jedoch nicht, dass sich die veröffentlichten Zahlen von Grund auf reproduzieren lassen. Im Repository steht ausdrücklich, dass Code, nicht aber die Datensätze bereitgestellt werden. Zugleich wird eine Stichprobe als Kombination aus Prompt, überprüfbaren Anforderungen und Referenzbild beschrieben. Dass das Format oder ein Beispiel verfügbar ist, belegt allerdings nicht, dass alle 300 ausgewerteten Fälle veröffentlicht wurden. Die zentrale Lücke besteht zwischen verfügbaren Evaluierungswerkzeugen und sämtlichen Eingaben, die zur Wiederholung des ursprünglichen Experiments nötig wären.

Die hier herangezogene Evidenz stammt aus zwei primären Projektquellen: dem Microsoft-Repository und dem Profil von AesCode-8B. Beide beschreiben die Arbeit als AesCode und verlinken den als arXiv-Preprint bezeichneten Artikel. Anhand der eingesehenen Informationen lässt sich der wissenschaftliche Begutachtungsstatus dieses Artikels nicht unabhängig prüfen. Deshalb wird er weder als begutachtete Arbeit noch als unabhängig repliziert dargestellt. Die Ergebnisse sind als vom Projekt berichtete Werte zu verstehen, nicht als externe Validierung.

Wie Chart in die Suite eingebettet ist

In der Ergebnistabelle werden Text, Bound und Chart als programmatische Prüfungen aufgeführt, die zu Rule zusammengefasst werden. Content, Layout und Style bilden Visual; Overall ist der Mittelwert aus Rule und Visual. Diese Struktur ist wichtig, weil der Chart-Wert weder das Gesamtergebnis der visuellen Evaluierung noch ein eigenständiges Maß für ästhetische Qualität darstellt. Er ist eine Dimension überprüfbarer Korrektheit im Zusammenhang mit Diagrammen.

Das Repository beschreibt Diagrammanforderungen anhand erwarteter Daten, etwa benannter Reihen mit Werten oder numerischer Listen, sowie des Diagrammtyps. In der Systembeschreibung prüft der tablechart-Kanal Daten von Tabellen und Diagrammen. Das Profil von AesCode-8B führt Chart als programmatische Komponente von Rule auf. Diese Dokumentation stützt den allgemeinen Zusammenhang, reicht aber nicht aus, um alle Einzelheiten der Bewertungsfunktion oder die Aggregation spezieller Fälle festzustellen.

Bei der Terminologie ist Sorgfalt nötig: Im ursprünglichen Entwurf werden Bound, Content, Layout und Overall als verwandte Komponenten genannt, doch die Dokumentation führt außerdem Text, Chart, Rule und Style auf. Das sind unterschiedliche Kategorien, keine Synonyme. Bound und Chart haben jeweils eigene Werte; Rule fasst beide gemeinsam mit Text zusammen. Ebenso werden Content, Layout und Style zu Visual kombiniert, das anschließend in Overall eingeht. Wer den Chart-Wert eines Modells mit dem Overall-Wert eines anderen vergleicht, vermischt Aggregationsebenen.

Was die Zahlen zeigen – und was sie nicht belegen

In der veröffentlichten Tabelle erreicht AesCode-8B bei Chart 87,79 und AesCode-32B 90,37. Dem Modellprofil zufolge wurden die Ergebnisse anhand von 300 Infografik-Beispielen berechnet, mit drei Generierungen je Prompt und ohne Auswahl zwischen den Generierungen. Damit lässt sich das berichtete Ergebnis samt dem beschriebenen übergreifenden Verfahren wiedergeben. Allein daraus lässt sich jedoch nicht ableiten, wie stark sich die Werte bei einer anderen Fallauswahl, einer anderen Implementierung oder einer unabhängigen Wiederholung verändern würden.

Dieselbe Quelle nennt Generierungsparameter für die berichteten Werte: Temperatur 0,8, top-p 0,95, bis zu 12.000 Ausgabetokens und ein Kontext von 24.576 Tokens. Diese Angaben grenzen die gemeldete Konfiguration sinnvoll ein. Sie dürfen nicht mit einer vollständigen Spezifikation sämtlicher Versuchsbedingungen aller verglichenen Systeme verwechselt werden: Modelle, verfügbare Werkzeuge, Versionen und Umgebungen können sich unterscheiden. Um einen Leistungsunterschied dem Modell selbst zuzuschreiben, müssten vergleichbare Bedingungen für jeden Fall dokumentiert sein.

Auch der Umfang des Kanals setzt der Interpretation Grenzen. Chart bewertet einen Aspekt der Suite, der an Diagrammdaten geknüpft ist. Der Wert belegt nicht automatisch, dass die Visualisierungen ästhetisch gelungen sind, dass Ergebnisse außerhalb der vorgegebenen Anforderungen sachlich richtig sind oder dass ein Modell bei allen visuellen Generierungsaufgaben überlegen ist. Die Dokumentation erläutert die Zusammensetzung von Rule und Visual, doch die vorliegende Evidenz enthält weder ein externes Audit der Fallmenge noch eine Schätzung statistischer Unsicherheit für die einzelnen Werte.

Lücken, die ein methodisches Audit einschränken

Die erste Einschränkung betrifft die Verfügbarkeit der Daten. Das Repository erklärt, dass es Code, aber keine Datensätze veröffentlicht, und beschreibt ein Stichprobenformat mit Prompt, überprüfbaren Anforderungen und Referenzbild. Ohne die vollständige Chart-Fallmenge lässt sich nicht prüfen, welche Diagrammtypen vorkommen, wie die Schwierigkeitsgrade verteilt sind, ob Duplikate enthalten sind oder ob bestimmte Diagrammfamilien stärker gewichtet werden. Ein Beispiel im Repository hilft, das Format zu verstehen, muss aber nicht die vollständige Evaluierung repräsentieren.

Die zweite Einschränkung ist eine vollständige operative Spezifikation. Der Evaluierungscode ist verfügbar und die Dokumentation erläutert Kanäle und Abhängigkeiten. Ein Audit der Ergebnisse muss jedoch Versionen, Parameter, den Umgang mit Fehlern, Aggregationsregeln und das Verhalten festlegen, wenn eine Anforderung nicht überprüft werden kann. Das Repository weist selbst darauf hin, dass ein Kanal für Layout bei fehlendem PaddleOCR den Wert null zurückgibt, statt sich der Bewertung zu enthalten. Diese Warnung betrifft Layout und belegt keinen Fehler in Chart. Sie zeigt aber, warum Abhängigkeiten und Fehlerpfade bei der Reproduktion jedes Punktwerts dokumentiert werden sollten.

Die dritte Einschränkung betrifft die Vergleichbarkeit der Modelle. Für AesCode-8B nennt die Dokumentation Generierungsparameter; ein fairer Vergleich setzt jedoch voraus, dass die relevanten Bedingungen für alle Systeme bekannt und angeglichen sind: Modellversionen, Vorlagen, Eingaben, Werkzeuge, Ausgabelimits sowie die Regeln für Wiederholungsversuche oder die Auswahl von Ergebnissen. Die verfügbare Evidenz reicht nicht aus, um zu bestätigen, dass jedes Modell in der Tabelle in all diesen Punkten exakt gleich behandelt wurde. Die Tabelle ist daher als Projektbericht nützlich, beseitigt aber nicht die Notwendigkeit, die Vergleichbarkeit vor folgenreichen Entscheidungen zu prüfen.

Was für ein künftiges Audit erforderlich wäre

Eine reproduzierbare Evaluierung würde mindestens die genaue verwendete Codeversion, eine eindeutige Beschreibung der Chart-Metrik, die Spezifikationen ihrer Eingaben und eine Erklärung der Aggregation von einzelnen Diagrammen zum berichteten Wert erfordern. Darüber hinaus sollten Abhängigkeiten und Ausführungsumgebung sowie Kriterien für Renderfehler, nicht erkannte Diagramme, fehlende Daten und nicht anwendbare Fälle dokumentiert werden. Das Repository stellt Code und Einrichtungsschritte bereit; die Liste der erforderlichen Eingaben bleibt jedoch unvollständig, solange der ausgewertete Datensatz nicht verfügbar ist oder kein transparentes Zugangsverfahren besteht.

Eine Veröffentlichung der Fälle würde es ermöglichen, die Abdeckung zu prüfen und reproduzierbare Aufteilungen festzulegen. Falls sensible Inhalte betroffen wären, könnten Kennungen, Spezifikationen und Generierungsskripte veröffentlicht oder ein kontrollierter Zugang mit klaren Regeln eingerichtet werden. Entscheidend ist, dass autorisierte Dritte nachvollziehen können, was bewertet wurde, und dass sich die Fallmenge zwischen Versionen nicht unbemerkt ändert. Ein Versionsprotokoll und Prüfsummen der Dateien würden Änderungen leichter erkennbar machen.

Ein Audit sollte außerdem Replikation und Erweiterung getrennt behandeln. Eine Replikation würde dieselbe Evaluierung mit derselben Fallmenge und Konfiguration ausführen und die Ergebnisse vergleichen. Eine Erweiterung würde andere Anwendungsbereiche, Diagrammtypen oder Modelle testen. Das kann nützlich sein, überprüft aber für sich genommen nicht die ursprünglichen Werte. Schließlich sollten Ergebnisse je Fall und Maße für die Variabilität zwischen Generierungen berichtet werden, nicht nur aggregierte Mittelwerte. So ließe sich unterscheiden, ob ein Vorteil konsistent ist oder sich auf wenige Beispiele konzentriert.

Fazit: Vergleiche sind möglich, aber nur mit begrenzter Aussagekraft

Derzeit lässt sich sagen, dass AesCode einen dokumentierten Chart-Kanal als Teil einer umfassenderen Evaluierung umfasst, Werte für konkrete Modelle veröffentlicht und Code zur Ausführung der Evaluierung bereitstellt. Ebenso ist dokumentiert, dass das Projekt 300 Beispiele und drei Generierungen je Prompt nennt und Chart in Rule eingeht. Diese Angaben ermöglichen eine fundierte Einordnung der berichteten Struktur und eine Untersuchung der Software.

Mit der verfügbaren Evidenz lässt sich nicht behaupten, dass jedes Team die veröffentlichte Tabelle exakt reproduzieren kann: Das Repository hält fest, dass die Daten nicht verteilt werden. Ebenso wenig sind eine unabhängige Replikation oder ein vollständig kontrollierter Vergleich aller Modelle belegt. Eine methodisch angemessene Haltung besteht darin, die Werte als vom Projekt berichtete Ergebnisse zu behandeln, die Fragen und Experimente anregen können, aber vor einer endgültigen Auswahlentscheidung extern überprüft werden sollten.

Für Forschende und Evaluierungsteams hängt die praktische Entscheidung vom Einsatzzweck ab. Als explorative Orientierung können die Ergebnisse dabei helfen, berichtete Unterschiede zwischen Systemen zu erkennen. Für eine abschließende Rangfolge, eine Kaufentscheidung oder eine allgemeine Leistungsbehauptung sollten Daten, Versionen, operative Spezifikationen und Einzelergebnisse verlangt werden. Ohne diese Elemente kann die Evidenz den Benchmark beschreiben, aber ein Audit seiner Vergleichbarkeit nicht abschließen.

Weiter entdecken

Korrekturen und Transparenz

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