1 Ausgangslage, Motivation und Zielsetzung

Dieses Kapitel erläutert, warum die data2type LLM Testsuite entwickelt wurde, welche praktischen und methodischen Fragestellungen ihr zugrunde liegen und welche Ziele mit ihr verfolgt werden. Themen führen von der Ausgangslage über die empirische Prüfung von Fähigkeiten bis zu Forschungsfragen, Anwendungsentscheidungen und der langfristigen Perspektive.

Ausgangslage

Sprachmodelle (Large Language Models) werden heute für Aufgaben eingesetzt, die weit über freie Textproduktion hinausgehen. Sie sollen Informationen aus Dokumenten extrahieren, Tabellen interpretieren, Metadaten erzeugen, XML-Strukturen aufbauen, technische Standards anwenden, Klassifikationen vornehmen und Ergebnisse in streng vorgegebenen Formaten liefern.

Für solche Anwendungen reicht eine allgemeine Aussage wie „das Modell ist leistungsfähig“ nicht aus. Ein Modell kann in einer Wissensfrage überzeugen und zugleich an einer einfachen Formatvorgabe scheitern. Es kann XML syntaktisch erzeugen, aber einen Fachstandard falsch anwenden. Es kann eine Tabelle in HTML korrekt lesen, dieselbe Information in RTF jedoch nicht zuverlässig erfassen. Es kann eine Aufgabe einmal lösen, aber bei identischer Wiederholung stark schwanken.

Die data2type LLM Testsuite wurde geschaffen, um diese Unterschiede sichtbar zu machen!

Fähigkeiten müssen empirisch geprüft werden

Aus Anwendersicht ist die vollständige Zusammensetzung der Vortrainingsdaten eines Sprachmodells in der Regel nicht prüfbar. Es lässt sich daher nicht sicher aus Modellgröße, Anbieterbeschreibung oder allgemeinem Benchmarkwert ableiten, ob ein Modell beispielsweise RSS, NISO STS, MARC21, CALS, FHIR oder eine bestimmte XPath-Version zuverlässig beherrscht.

Die data2type LLM Testsuite ersetzt diese Unsicherheit nicht durch Vermutungen, sondern durch wiederholbare Aufgaben. Ein Standard gilt nicht schon deshalb als bekannt, weil das Modell seinen Namen erklären kann. Entscheidend ist, ob es eine konkrete Aufgabe korrekt löst, eine gültige Struktur erzeugt, relevante Informationen findet und die geforderte Ausgabeform einhält.

Damit verschiebt sich die Fragestellung von vermutetem Trainingswissen zu beobachtbarem Verhalten.

Motivation aus RAG-Projekten

Ein wesentlicher Ausgangspunkt war die Arbeit mit Retrieval-Augmented Generation, kurz RAG. In einem RAG-System wird die Antwortqualität nicht allein vom Sprachmodell bestimmt. Ebenso wichtig sind Auswahl, Zuschnitt und Codierung der bereitgestellten Informationsblöcke.

Chunks können denselben fachlichen Inhalt in sehr unterschiedlichen Formen enthalten. Eine Tabelle kann als CSV, HTML, Markdown, Excel, WordML oder CALS vorliegen. Ein XML-Dokument kann eingerückt oder vollständig in einer Zeile serialisiert sein. Eine CSV-Datei kann Komma oder Semikolon als Trennzeichen verwenden. Diese Unterschiede verändern den Informationsgehalt nicht zwingend, können aber beeinflussen, wie zuverlässig ein Modell Zeilen, Spalten, Überschriften, Hierarchien und Beziehungen erkennt.

Die praktische Frage lautet deshalb nicht nur, ob ein Chunk inhaltlich richtig ist. Es ist auch zu prüfen, ob seine Repräsentation für das verwendete Modell geeignet ist.

Von Dateiformaten zu Fähigkeitsprofilen

Die Untersuchung verschiedener Formate ist ein wichtiger Teil der LLM Testsuite, aber nicht ihr alleiniger Zweck. Die Plattform ist als allgemeine Fähigkeits-Testsuite angelegt.

Sie kann beispielsweise untersuchen:

• ob ein Modell einen RSS- oder Atom-Feed korrekt erzeugt,
• ob es einen Standard wie JATS, DITA, DocBook, BITS oder NISO STS kennt und praktisch anwenden kann,
• ob es semantische Informationen wie Personen, Orte, Literaturangaben oder Identifikatoren extrahiert,
• ob es Regeln kombiniert und daraus einen Zielwert ableitet,
• ob es eine Klassifikation korrekt vornimmt,
• ob es XPath 3.0 oder XPath 3.1 versteht und passende Ausdrücke erzeugt,
• ob es dieselbe Aufgabe in XML, JSON, YAML, Markdown oder Plain Text gleich zuverlässig löst,
• ob die Ergebnisse über mehrere Läufe stabil bleiben.

Das langfristige Ziel ist ein wachsendes Profil konkreter Fähigkeiten über viele Modelle und Modellversionen hinweg.

Zielsetzung

Die LLM Testsuite verfolgt fünf zentrale Ziele.

1) Empirische Fähigkeitsprüfung

Konkrete Aufgaben sollen zeigen, was ein Modell tatsächlich leisten kann. Das Ergebnis ist kein pauschales Gütesiegel, sondern ein nach Domänen und Aufgabentypen gegliedertes Profil.

2) Vergleichbarkeit

Modelle sollen auf derselben Testdefinition, mit nachvollziehbaren Prompts und dokumentierten Bewertungsregeln verglichen werden. Wo identische technische Bedingungen nicht möglich sind, werden Unterschiede in Ausführungsweg und Umgebung ausdrücklich ausgewiesen.

3) Reproduzierbarkeit

Mehrere Durchläufe machen sichtbar, ob eine Fähigkeit stabil abrufbar ist. Ein gelegentlicher Treffer ist für automatisierte Produktionsprozesse anders zu bewerten als ein konsistentes Ergebnis.

4) Erweiterbarkeit

Neue Standards, Sprachen, Aufgabenklassen und Modellfamilien sollen ohne grundlegenden Umbau ergänzt werden können. So kann die LLM Testsuite künftig unter anderem XPath 3.1, XQuery, Schematron, SPARQL, XSLT, Tool-Nutzung oder neue Dokumentenstandards aufnehmen.

5) Praxisbezug

Die Ergebnisse sollen Entscheidungen unterstützen. Dazu gehören Modellwahl, RAG-Aufbereitung, Konvertierungsstrategien, Validierungsbedarf, lokale oder cloud-basierte Ausführung und die Gestaltung automatisierter Content-Pipelines.

Forschungsfragen

Diese Studie leitet daraus folgende übergeordnete Forschungsfragen ab:

1. Welche fachlichen und semantischen Fähigkeiten zeigen aktuelle Sprachmodelle in klar definierten Aufgaben?
2. Wie zuverlässig wenden Modelle technische Standards und formale Sprachen an?
3. Welchen Einfluss hat die Repräsentation identischer oder vergleichbarer Informationen?
4. Wie stark schwanken Ergebnisse bei wiederholter Ausführung?
5. Welche technischen Fehler treten auf und wie sind sie von fachlichen Fehlern zu trennen?
6. Welche Bewertungsmethode ist für einen Testfall angemessen?
7. Welche Kombination aus Large Language Model, Datenrepräsentation und Validierung eignet sich für einen konkreten Produktionsprozess?

Kein universelles Modell-Ranking

Die LLM Testsuite kann Rangfolgen für einen definierten Datenstand erzeugen. Diese Rangfolgen sind jedoch kein Selbstzweck. Ein Gesamt-Score verdichtet unterschiedliche Fähigkeiten, Testabdeckungen und Fehlerarten. Er darf nicht so interpretiert werden, als sei ein Modell in jeder denkbaren Anwendung überlegen.

Für die praktische Auswahl sind deshalb mindestens Testkategorie, Anzahl bewerteter Läufe, technische Stabilität, Reproduzierbarkeit, Laufzeit, Ausführungsweg und die konkrete Aufgabenklasse zu berücksichtigen.

Die zentrale Aussage lautet: Nicht das Sprachmodell allein bestimmt die Qualität einer KI-Anwendung, sondern das Zusammenspiel aus Modell, Aufgabe, Datenrepräsentation, Ausführungsumgebung und Bewertung.

Entscheidungen, die durch die Testsuite unterstützt werden

Die LLM Testsuite ist nicht nur ein Forschungsinstrument. Sie soll konkrete Entscheidungen in Projekten vorbereiten. In einer Content-Pipeline kann beispielsweise zu klären sein, ob ein lokales Modell ausreicht, ob eine Cloud-Variante benötigt wird oder ob die Aufgabe besser vollständig deterministisch gelöst werden sollte. Ebenso kann sich die Frage stellen, ob ein Dokument vor der Übergabe an ein Modell in ein anderes Format konvertiert werden muss.

Typische Entscheidungen betreffen:

• die Auswahl eines Modells für eine fachlich eng begrenzte Aufgabe,
• die Wahl zwischen lokaler und externer Ausführung,
• die Notwendigkeit einer Vorverarbeitung von XML, RTF, Tabellen oder Office-Formaten,
• die Auswahl eines geeigneten Chunk-Formats für ein RAG-System,
• die Entscheidung, welche Ausgaben durch XSD, Schematron, JSON Schema, Parser oder eigene Regeln validiert werden müssen,
• die Festlegung, ob ein einzelner Modell-Lauf genügt oder ob mehrere Versuche mit Konsensbildung erforderlich sind,
• die Abschätzung von Laufzeit, Fehlerrisiko und betrieblichem Aufwand.

Ein hoher Gesamt-Score beantwortet diese Fragen nicht automatisch. Für eine produktive Entscheidung muss die relevante Teilmenge der Tests betrachtet werden. Ein Modell kann beispielsweise bei semantischer Extraktion gut abschneiden, aber beim Erzeugen standardkonformer XML-Dokumente unzuverlässig sein. Umgekehrt kann ein kleineres Modell in einer klaren XPath-Aufgabe besonders geeignet sein, obwohl es in allgemeinen Reasoning-Tests schwächer abschneidet.

Beobachtung, Hypothese und Erklärung

Die Testsuite misst beobachtbares Verhalten. Sie kann zeigen, dass zwei Repräsentationen bei einer definierten Modellmenge unterschiedliche Erfolgsquoten erzeugen. Sie kann jedoch nicht allein beweisen, warum dieser Unterschied entsteht. Mögliche Ursachen sind Trainingsdaten, Tokenisierung, Promptlänge, Formatkonventionen, Kontextfenster, Modellausrichtung oder zufällige Schwankungen.

Für die Veröffentlichung wird deshalb zwischen drei Ebenen unterschieden:

1. Beobachtung: Welche Antworten und Kennzahlen wurden im dokumentierten Datenstand gemessen?
2. Hypothese: Welche plausible Erklärung ergibt sich aus dem Muster?
3. Schlussfolgerung: Welche praktische Konsequenz ist unter den genannten Einschränkungen sinnvoll?

Research Notes sollen diese Trennung ausdrücklich sichtbar machen. Eine auffällige Korrelation wird nicht als allgemeines Gesetz formuliert. Sie bildet den Ausgangspunkt für weitere kontrollierte Tests.

Langfristige Perspektive

Die Bedeutung einer Fähigkeit verändert sich mit der technischen Entwicklung. XPath 3.1, XSLT 3.0 oder ein bestimmtes XML-Vokabular können heute nur von wenigen Modellen zuverlässig angewendet werden und später zum verbreiteten Funktionsumfang gehören. Gleichzeitig können Updates bestehender Modelle zu Verbesserungen, aber auch zu Rückschritten führen.

Die data2type LLM Testsuite ist deshalb als Langzeitbeobachtung angelegt. Neue Modell-Generationen werden nicht nur gegen neue Aufgaben geprüft. Soweit technisch und rechtlich möglich, werden auch bestehende Testfälle wiederholt. Dadurch entsteht eine Zeitreihe darüber, wie sich fachliche Kompetenz, Robustheit, Laufzeit und technische Stabilität entwickeln.

Diese Langzeitperspektive erhöht den Wert der veröffentlichten Ergebnisse. Ein einzelner LLM Testsuite Dashboard-Stand zeigt den aktuellen Zustand. Mehrere versionierte Stände ermöglichen dagegen Aussagen über Entwicklung, Stabilität und Veränderung.