12 Erweiterbarkeit, Research Notes und Ausblick
Dieses Kapitel zeigt, wie die data2type LLM Testsuite um neue Fähigkeiten, Standards, Modelle und Fragestellungen erweitert werden kann. Zugleich beschreibt es den fortlaufenden Artikelbereich, in dem aktuelle und zukünftige Erkenntnisse aus dem veröffentlichten Dashboard-Stand vertieft werden.
LLM Testsuite als langfristige Infrastruktur
Die Plattform ist nicht auf den aktuellen Testkatalog begrenzt. Neue Fähigkeiten können durch zusätzliche Testdefinitionen, Kategorien, Bewertungsregeln und Modellläufe aufgenommen werden.
Das macht die LLM Testsuite zu einer Infrastruktur für kontinuierliche Forschung und Qualitätssicherung.
Vorgehen für eine neue Fähigkeit
Ein Beispiel ist XPath 3.0 oder XPath 3.1. Eine belastbare Testserie sollte nicht nur fragen, ob ein Modell einen einfachen Pfad erzeugt. Sie könnte mehrere Kompetenzstufen unterscheiden:
| Stufe | Beispiel |
|---|---|
| Basis-Selektion | Elemente und Attribute auswählen |
| Namespaces | Präfixe und Default-Namespaces korrekt behandeln |
| Sequenzen | Sequenzsemantik und leere Sequenz anwenden |
| Funktionen | Standardfunktionen passend einsetzen |
| Prädikate | Positions- und Wertfilter korrekt kombinieren |
| Maps und Arrays | XPath-3.1-Datentypen nutzen |
| Höhere Funktionen | Funktionswerte und for-each-Funktionen verwenden |
| Fehlerdiagnose | fehlerhafte Ausdrücke erklären und korrigieren |
| Ergebnisprüfung | Ausdruck gegen definiertes XML ausführen |
Die Bewertung kann deterministisch erfolgen, wenn die Ausdrücke in einer XPath-Engine ausgeführt und ihre Ergebnisse mit Sollwerten verglichen werden. Ein LLM Judge wäre dann nur für Erklärung oder Stil erforderlich.
Weitere mögliche Testgebiete
- XQuery 3.1 und Update Facility,
- XSLT 3.0,
- Schematron und Schematron QuickFix (SQF),
- SPARQL-, SHACL- und RDF-Datenqualität,
- JSON Schema und JSONPath,
- komplexe RSS- und Atom-Varianten,
- NISO STS in unterschiedlichen Anwendungsprofilen,
- barrierefreie EPUB- und HTML-Strukturen,
- OCR-Nachbearbeitung und Layout-Verständnis,
- RAG-Chunking nach XML-Struktur, Token-Länge oder Semantik,
- Tool-Nutzung und Function Calling,
- selbstständige Validierung und Reparatur von Ausgaben.
Workflow für Research Notes
Research Notes werden zukünftig unter Methodikstudie: Schlussfolgerungen veröffentlicht. Eine Research Note sollte eine klar begrenzte Fragestellung verfolgen.
Empfohlene Struktur:
- Titel und Hypothese,
- methodischer Bezug auf diese Studie,
- Datenstand und Auswahlkriterien,
- Testfamilie und kontrollierte Variation,
- Modelle und Ausführungswege,
- Bewertungsregeln,
- statistische Auswertung,
- Ergebnisse,
- alternative Erklärungen,
- Grenzen,
- Daten- und Dashboard-Links,
- Fazit für die Praxis.
Beispiel für eine Research Note: CSV mit Komma oder Semikolon
Eine passende Research Note könnte untersuchen, ob das Trennzeichen die Extraktion aus derselben Tabelle verändert.
Dazu müssen beide Testfälle möglichst identisch sein:
- gleiche Zeilen und Spalten,
- gleiche Zielzelle,
- gleiche Instruktion,
- gleiche Prompt-Position,
- gleiche Modelle,
- gleiche Wiederholungszahl,
- gleiche Bewertungsregel.
Dann kann pro Modell ein gepaarter Vergleich erfolgen. Interessant sind nicht nur Mittelwerte, sondern auch Modelle, die nur bei einer Variante stabil sind.
Beispiel für eine Research Note: Direkte RTF-Verarbeitung
Die Frage „Kann ein Modell RTF?“ muss genauer operationalisiert werden. Mögliche Stufen sind:
- sichtbaren Text aus einfachem RTF erkennen,
- Tabellenstruktur rekonstruieren,
- Steuerwörter und Escaped Characters korrekt behandeln,
- irrelevante Formatierungsinformationen ignorieren,
- dieselbe Aufgabe im Vergleich zu Klartext oder WordML lösen.
Die praktische Schlussfolgerung kann lauten, dass direkte RTF-Eingabe für bestimmte Modelle ausreicht oder dass eine vorgelagerte Konvertierung zuverlässiger ist.
Beispiel für eine Research Note: RSS-Kompetenz
Auch RSS kann auf mehreren Ebenen getestet werden:
- Kenntnis der Grundstruktur,
- Erzeugung eines gültigen RSS-2.0-Feeds,
- Pflicht- und optionale Elemente,
- Datumsformate,
- mehrere Items,
- Namespaces und Erweiterungsmodule,
- Reparatur ungültiger Feeds,
- Extraktion aus bestehenden Feeds.
Damit wird aus einer allgemeinen Frage ein differenziertes Fähigkeitsprofil.
Jahresberichte
Neben einzelnen Research Notes kann ein jährlicher Bericht Entwicklungen zusammenfassen:
- neue Modellfamilien,
- Fähigkeiten mit deutlichen Fortschritten,
- weiterhin problematische Standards,
- Veränderungen bei Laufzeit und Stabilität,
- Unterschiede lokaler und externer Betriebsmodelle,
- neue Testgebiete und Bewertungsverfahren.
Ein Jahresbericht benötigt einen eingefrorenen Datenstand und sollte Veränderungen nur auf vergleichbaren Testmengen ausweisen.
Governance
Mit wachsendem Umfang werden redaktionelle Regeln wichtig:
| Bereich | Regel |
|---|---|
| Test-IDs | dauerhaft stabil, keine Wiederverwendung |
| Kategorien | kontrolliertes Vokabular mit Synonymregeln |
| Prompt-Änderungen | neue Version und neuer Hash |
| Bewertungsregeln | versioniert und getestet |
| Modellnamen | sichtbarer Name plus Metadaten |
| Datenstände | Build-Zeitpunkt und Manifest |
| Research Notes | reproduzierbare Auswahlabfrage |
| Archivierung | alte Fassungen erhalten |
Ausblick
Die LLM Testsuite kann zu einer fachlichen Referenz für strukturierte Daten, XML, Publishing und semantische Verarbeitung werden. Ihr Wert wächst nicht nur mit der Zahl der Runs, sondern mit der Qualität der Testfamilien, der Transparenz der Bewertung und der Sorgfalt der veröffentlichten Interpretation.
Eigener Artikelbereich auf der data2type Website
Für die LLM Testsuite wird unter der Seite Methodikstudie: Schlussfolgerungen ein eigener redaktioneller Bereich eingerichtet, in dem regelmäßig neue Artikel und Research Notes erscheinen. Dieser Bereich verbindet die langfristig stabile Methodikstudie mit dem fortlaufend aktualisierten LLM Testsuite Dashboard. Er ist damit die Stelle, an der aus großen Ergebnismengen konkrete, verständliche Erkenntnisse werden.
Die Artikel sollen nicht nur besonders gute oder überraschende Modelle präsentieren. Ebenso wichtig sind negative oder uneindeutige Befunde, methodische Lernprozesse und Fälle, in denen eine zunächst plausible Hypothese nicht bestätigt wird. Dadurch entsteht eine realistische Wissensbasis und keine reine Erfolgsschau.
Der Artikelbereich ist ausdrücklich offen für zwei Arten von Veröffentlichungen.
Die erste Gruppe analysiert den jeweils aktuellen Stand der LLM Testsuite.
Die zweite Gruppe begleitet zukünftige Erweiterungen, neue Modelle, neue Testkategorien und Wiederholungen bereits bekannter Versuche.
Ein späterer Beitrag kann beispielsweise prüfen, ob ein neu erschienenes Modell die bisherigen Unterschiede zwischen Komma und Semikolon bestätigt. Ein anderer Beitrag kann untersuchen, ob sich die XPath-3.1-Fähigkeit einer Modellfamilie über mehrere Versionen verbessert hat. Ältere Beiträge bleiben als historische Messpunkte wertvoll.
Mögliche Artikeltypen
Der Veröffentlichungsbereich kann u.a. unterschiedliche Formate enthalten:
| Artikeltyp | Inhalt |
|---|---|
| Ergebnisnotiz | Kurze Einordnung eines klaren, aktuellen Befunds |
| Vergleichsstudie | Mehrere Modelle, Formate oder Modellversionen zu einer Hypothese |
| Methoden-Update | Neue Bewertungsregel, neue Kennzahl oder geänderter Testaufbau |
| Testfallporträt | Detaillierte Erklärung einer Testfamilie und ihrer Aussagekraft |
| Performance-Bericht | Laufzeit, Stabilität, Timeouts und Ressourcen-Bedarf |
| Standard-Bericht | Fähigkeiten zu RSS, JATS, XPath, NISO STS oder anderen Standards |
| Jahresrückblick | Wichtigste Entwicklungen und Veränderungen über mehrere Builds |
Die Länge kann dem Gegenstand angepasst werden. Entscheidend sind Datenstand, klare Fragestellung und nachvollziehbare Auswahl.
Redaktioneller Workflow für einen Artikel
Ein Artikel sollte in mehreren Schritten entstehen:
- Ein Auffälliges Muster im LLM Testsuite Dashboard identifizieren.
- Prüfen, ob Abdeckung und Bewertungsregeln ausreichend sind.
- Hypothese und Vergleichsgruppe vor der Detail-Auswertung festlegen.
- Relevante Runs und Ausreißer kontrollieren.
- Kennzahlen berechnen und visualisieren.
- Beobachtung, mögliche Erklärung und praktische Bedeutung trennen.
- Methodenfassung, Dashboard-Build und Filter dokumentieren.
- Beitrag veröffentlichen und mit dem LLM Testsuite Dashboard verknüpfen.
Bei späteren Datenständen wird geprüft, ob der Beitrag weiterhin gilt. Ein Update kann als neue Fassung oder als eigenständige Folge-Analyse erscheinen.
Verknüpfung mit dem öffentlichen Dashboard
Jeder Ergebnisartikel sollte den Leser zur zugrunde liegenden Dashboard-Ansicht führen. Ideal sind stabile Links oder reproduzierbare Filterangaben. Umgekehrt kann das LLM Testsuite Dashboard auf Artikel verweisen, die einen Testfall oder eine Kategorie vertiefen.
Damit wird die Aussage im Artikel überprüfbar. Leser können andere Modelle hinzunehmen, alternative Filter setzen oder die Zahl der zugrunde liegenden Runs prüfen. Der Artikel gibt Orientierung, das Dashboard ermöglicht Eigenanalyse.
Öffentliche Nutzung ohne Veröffentlichung des Quellcodes
Die Veröffentlichung des LLM Testsuite Dashboards wird durch eine ausführliche Beschreibung des Ausführungs- und Bewertungsprozesses ergänzt. Die Öffentlichkeit kann nachvollziehen, wie Testfälle entstehen, wie Wiederholungen durchgeführt, technische Fehler erfasst, Antworten bewertet, Kennzahlen berechnet und Datenstände freigegeben werden.
Nicht bereitgestellt wird der Quellcode der internen Testsoftware. Ebenso bleiben konkrete Skripte, Automatisierungsbefehle, Zugangsdaten, Provider-Konfigurationen und Infrastrukturdetails intern. Nutzer können das geprüfte Ergebnisangebot frei erkunden, ohne Modelle selbst installieren oder die interne Implementierung ausführen zu müssen.
Diese Form der Öffnung verbindet methodische Transparenz, öffentliche Nutzbarkeit und kontrollierte Qualität. data2type bleibt für Testdefinition, Ausführung, Bewertung und Freigabe verantwortlich. Die Öffentlichkeit erhält zugleich einen direkten Zugang zu den Ergebnissen und eine nachvollziehbare Beschreibung ihres Entstehungswegs.
Beteiligung und Rückmeldungen
Das öffentliche LLM Testsuite Dashboard und fortlaufende Artikel erleichtern fachliche Rückmeldungen. Experten und Expertinnen können auf unklare Testdefinitionen, alternative korrekte Lösungen oder fehlende Standards hinweisen. Solche Hinweise werden redaktionell geprüft und können zu neuen Testfällen oder Regelversionen führen.
Die Governance muss dabei verhindern, dass einzelne Interessen die Vergleichbarkeit verzerren. Änderungen werden versioniert und begründet. Externe Vorschläge sind willkommen, werden aber nicht ungeprüft in veröffentlichte Scores übernommen.
Erweiterungs-Roadmap
Die Roadmap kann parallel mehrere Linien verfolgen:
- Ausbau allgemeiner semantischer Aufgaben,
- Vertiefung von XML-Sprachen und Standards,
- neue Repräsentationsvergleiche,
- längere Kontexte und komplexere Dokumente,
- stärkere Validierung mit Fachwerkzeugen,
- Zeitreihen über Modellversionen,
- zusätzliche Performance- und Kostenkennzahlen,
- bessere Verlinkung zwischen Dashboard, Methodikstudie und Artikeln.
Die Reihenfolge richtet sich nach fachlicher Relevanz, verfügbaren Ressourcen und der Trennschärfe möglicher Testfälle.