ATDD für LLMs: Fehlerdialoge als Tests und Trainingsdaten

Acceptance Test Driven LLM Development (ATDD für LLMs) bezeichnet einen Ansatz, bei dem fehlgeschlagene Akzeptanztests aus echten Fehlerdialogen zugleich als Trainingsdaten für das Fine-Tuning eines Large Language Models dienen. Neue Business-Anforderungen werden als dialogbasierte Testfälle spezifiziert, das Modell neu trainiert und anschließend automatisiert gegen alle bisherigen Tests geprüft, um Regressionen zu erkennen.

Das Wichtigste in Kürze

• Acceptance Test Driven LLM Development überträgt das Prinzip fehlschlagender Akzeptanztests direkt auf das Fine-Tuning: Ein Test schlägt fehl, neue Trainingsdialoge beheben den Fehler, danach beweist die Testsuite, ob das Modell gelernt hat ohne Regressionen zu erzeugen.
• LLM-Ausgaben lassen sich nicht per String-Vergleich prüfen, weil semantisch identische Antworten nie denselben Wortlaut haben. Die Verifikation muss deshalb je nach Ausgabetyp zwischen striktem Strukturvergleich und semantischer Prüfung unterscheiden.
• Echte Produktivdialoge aus dem Pilotbetrieb sind die primäre Datenquelle: Anonymisierte Gespräche zeigen, welche Anfragen das Modell noch nicht autonom löst, und liefern direkt den Stoff für neue Trainings- und Testdaten.
• Template-basierte Dialoge ermöglichen kombinatorisches Testen, indem Template-Variablen durch viele verschiedene Werte ersetzt werden und so aus einem Testfall automatisch eine große Messreihe entsteht.

Was ATDD für LLMs bedeutet

Acceptance Test Driven LLM Development überträgt das Prinzip der akzeptanztestgetriebenen Entwicklung auf das Training und die Validierung von Sprachmodellen. Statt ein Modell nur einmal zu trainieren und zu hoffen, dass es passt, schreibt das Team zuerst Akzeptanztests, die das Modell anfangs nicht besteht, und entwickelt dann gezielt dagegen.

Der Begriff stammt von David Faragó, der bei Mediform an einem Telefonassistenten für Arztpraxen arbeitet. Sein Punkt: Die LLM-Entwicklung als Disziplin steckt noch in den Anfängen. Die Modelle selbst sind mächtig, aber die Prozesse und Werkzeuge drumherum hinken hinterher.

Der Reiz des Ansatzes liegt in der Verbindung zweier Welten. Aus dem Machine Learning kommen das Trainings-Set und das Test-Set. Aus der agilen Softwareentwicklung kommen die Akzeptanztests als Sicherheitsnetz. Wer fehlschlagende Testfälle aus echten Beispielen ableitet, hat hinterher eine messbare Aussage darüber, ob das Modell besser geworden ist.

Warum das Testen von Sprachmodellen so schwierig ist

Ein LLM zu verifizieren ist schwer, weil es nicht deterministisch ist und sich wie eine Blackbox verhält. Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen, und niemand sieht direkt, warum das Modell so antwortet, wie es antwortet.

Faragó zitiert ein treffendes Bild: LLMs seien Technologie, die von Aliens geschenkt wurde. Sie können hervorragend mit natürlicher Sprache umgehen und Schlüsse ziehen, lassen sich aber kaum mit klassischen Methoden kontrollieren.

Erschwerend kommt hinzu, dass natürlichsprachliche Anwendungen sich nicht über einfache Stringvergleiche prüfen lassen. Ob der Bot sagt “Habe ich richtig verstanden, Sie wollen einen Termin buchen?” oder “Sie wollen also einen Termin buchen?”, ist nicht derselbe String, aber semantisch identisch. Genau diese semantische Prüfung ist der schwierige Teil.

Die drei Stoßrichtungen für Qualität

Mediform begegnet diesen Herausforderungen mit einem soliden Prozess, einer schnellen Validierung und einer angepassten Verifikation.

Der Prozess basiert auf CPMAI, dem Cognitive Project Management for AI von Cognilytica. Er verbindet moderne Softwareentwicklung mit modernem Machine Learning und integriert Agilität, was ältere Ansätze wie CRISP-DM nicht leisten.

Die Validierung läuft über kurze Iterationszyklen mit direkt eingebundenen Pilotkunden. Patienten nutzen den Bot, das Team analysiert die anonymisierten Dialoge und leitet ab, was in der nächsten Iteration angepasst werden muss.

Die Verifikation stützt sich auf ein Testwerkzeug, das aus dem Language Model Evaluation Harness von EleutherAI weiterentwickelt wurde. Dieses Harness steckt auch hinter dem bekannten LLM-Leaderboard bei Hugging Face. Mediform hat es kräftig aufgebohrt und auf die eigenen Business Requirements zugeschnitten.

Task-oriented Dialog liegt genau in der Mitte

Telefonassistenten für Arztpraxen sind ein Sonderfall beim Testen, weil sie zwischen zwei Extremen liegen. Faragó nennt diese Klasse von Anwendungen Task-oriented Dialog.

Am einen Ende stehen Aufgaben mit eindeutiger Antwort. Dort genügt ein Stringvergleich auf Identität. Am anderen Ende steht die freie Kreativität, etwa ein generiertes Gedicht, bei dem ein Mensch drüberliest und kleine Abweichungen egal sind.

Ein Telefonbot, der einen Termin bucht, sitzt dazwischen. Er muss eine konkrete Aufgabe lösen, formuliert die Antwort aber sprachlich frei. Deshalb braucht es eine Prüfung, die zwischen wörtlich gleich und semantisch gleich unterscheidet, statt nur Zeichenketten zu vergleichen.

Wie der Tool-Former-Ansatz die Prüfung steuert

Mediform nutzt einen agentenbasierten Tool-Former-Ansatz, bei dem das Modell zwei Arten von Ausgaben erzeugt. Die eine Art ist natürlichsprachlicher Text für den Patienten. Die andere Art sind Funktionsaufrufe.

Vorgefertigte Nachrichten werden über solche Funktionsaufrufe ausgelöst, damit das Modell nicht jedes Mal lange Textblöcke neu generieren muss. Daneben erzeugt das Modell Funktionsaufrufe für Datenbankabfragen und ähnliche Aktionen.

Das Verifikationswerkzeug prüft je nach Situation unterschiedlich streng. Bei freiem Text darf es kulanter sein, bei Funktionsaufrufen und Datenbankabfragen muss die Ausgabe exakt stimmen. Diese Unterscheidung entscheidet darüber, ob ein Test als Stringvergleich oder als semantische Prüfung läuft.

Der Dialog steht im Zentrum des gesamten Prozesses

Mediform hält ein einziges Dialogformat über den ganzen Prozess durch. Dieselbe Struktur dient als Trainingsdaten, als Testfälle und als Format, das auch das Testwerkzeug liest.

Der Ablauf folgt dem CPMAI-Zyklus. Nach dem Deployment sammelt der Pilotkunde anonymisierte, real stattgefundene Dialoge. Das Team analysiert sie im Business und Data Understanding, misst etwa, wie viele Dialoge vollständig autonom bis zum Ziel kamen, und identifiziert die suboptimalen Fälle.

Aus diesen fehlerhaften Dialogen entstehen neue Akzeptanztests. Weil sie aus echten Fehlern stammen, schlagen sie zunächst fehl: Das Modell kann sie noch nicht bewältigen. Parallel erzeugt das Team viele Trainingsdialoge im selben Format.

Anschließend wird das Modell neu trainiert und gegen die neuen wie die alten Tests geprüft. So lässt sich gleichzeitig messen, ob das Modell dazugelernt hat und ob es dabei Regressionen zeigt.

Die sechs Stufen von CPMAI im Überblick

CPMAI strukturiert die LLM-Entwicklung in sechs iterative Stufen, zwischen denen man vor und zurück springen kann. Mediform hat dabei die erste und zweite Stufe für den eigenen Anwendungsfall zusammengelegt.

Die sechste Stufe ist die eigentliche Neuerung gegenüber CRISP-DM. Erst das Deployment schließt den Kreis, weil es neue, businessorientierte Daten für die nächste Iteration liefert.

Fine-Tuning entscheidet, wann Prompt Engineering nicht mehr reicht

Fine-Tuning kommt ins Spiel, wenn man mit dem Anpassen der Prompts allein nicht weiterkommt. Beim Prompt Engineering ändert man nur die Eingabe. Beim Fine-Tuning justiert man die Gewichte eines Basismodells hin zur konkreten Aufgabe.

Mediform fährt dafür zwei Varianten. Die eine ist ein feingetuntes GPT, die andere ein feingetuntes Open-Source-Modell wie Mistral. Prompt Engineering bleibt in beiden Fällen Teil der Lösung.

Eine Besonderheit liegt in den Trainingsdaten selbst. Die Dialoge kommen aus Speech-to-Text, enthalten also gelegentlich Transkriptionsfehler. Das Test-Framework muss damit umgehen, dass die Eingaben nicht aus sauber getipptem Text bestehen.

Wie stark Fine-Tuning ein Modell prägt, zeigt ein Sprachbeispiel. Ein auf deutschen Dialogen feingetuntes Mistral-Modell versteht Französisch hervorragend, antwortet aber gelegentlich auf Deutsch, weil es zum Deutschen tendiert. Für einen französischen Pilotkunden braucht es deshalb französische Trainings- und Testdialoge.

Template-basierte Tests öffnen die Tür zu Metamorphic Testing

Weil Akzeptanztests und Trainingsdaten template-basiert geschrieben sind, lässt sich Metamorphic Testing einfach umsetzen. Man nimmt einen relevanten Dialog und ersetzt die Template-Variablen durch viele weitere Werte.

So entsteht Combinatorial Testing zu einem einzelnen Aspekt. Statt eines einzigen Falls führt das Team viele Messungen zur selben Frage durch und sieht, ob das Modell über Variationen hinweg stabil bleibt.

Daneben gibt es Stress-Tests vor dem Deployment. Dabei automatisiert das Team auch die Patientenseite mit einem eigenen Sprachmodell und lässt das frisch feingetunte Modell gegen dieses Patienten-Modell laufen. Die entstehenden Dialoge werden anschließend ausgewertet.

Das eigentliche Sicherheitsnetz bleiben aber die Akzeptanztests. Unit-Tests laufen weiterhin für den Code rund um das Modell, doch das Verhalten des LLM selbst sichern vor allem die dialogbasierten Akzeptanztests ab.

Man nimmt Präzedenzfälle oder Beispiele, spezifiziert damit die neuen Requirements und hat dann eine Messmöglichkeit oder gar ein Sicherheitsnetz, um hinterher wirklich messbar zu haben, ob man es verbessert hat.

David Faragó

Warum Iterationen sich nicht an starre Sprints binden lassen

Die Iterationszyklen folgen bei Mediform keinem festen Takt, auch wenn das Team in zweiwöchigen Sprints arbeitet. Ein CPMAI-Durchlauf deckt sich nicht zwingend mit einem Sprint.

Manchmal passen mehrere Iterationen in zwei Wochen, manchmal zieht sich ein einzelner Zyklus länger. Im Idealfall liegen Sprint und Zyklus übereinander, in der Praxis kommt regelmäßig etwas dazwischen.

Treiber ist die Nachfrage. Wenn ein neuer Pilotkunde eine zusätzliche Sprache braucht, schiebt das Team eine schnelle Zwischeniteration ein und startet erst einmal mit dem vorhandenen Modell, bevor es gezielt neue Trainings- und Testdaten erzeugt. Diese Flexibilität ist Teil des Ansatzes, kein Bruch mit ihm.

Häufig gestellte Fragen

Warum reicht ein einfacher Stringvergleich nicht aus, um die Antworten eines Sprachassistenten zu prüfen?

Weil semantisch identische Antworten fast nie denselben Wortlaut haben. “Habe ich richtig verstanden, Sie wollen einen Termin buchen?” und “Sie wollen also einen Termin buchen?” sind zwei verschiedene Zeichenketten mit gleicher Bedeutung. Hinzu kommt, dass ein LLM nicht deterministisch arbeitet: Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen. Die Verifikation muss deshalb semantisch prüfen statt wörtlich.

Was bringt es, Akzeptanztests zu schreiben, bevor ein Modell feingetunt wird?

Sie machen den Fortschritt messbar. Tests, die aus echten Fehlerdialogen abgeleitet sind, schlagen zunächst fehl, weil das Modell diese Fälle noch nicht bewältigt. Nach dem erneuten Training zeigt die Suite zweierlei: ob das Modell die neuen Fälle gelernt hat und ob es dabei alte, bereits funktionierende Fälle kaputt gemacht hat.

Müssen alle Ausgaben eines LLM-basierten Assistenten gleich streng geprüft werden?

Nein. Bei frei formuliertem Text für den Nutzer darf die Prüfung kulanter sein, bei Funktionsaufrufen und Datenbankabfragen muss die Ausgabe exakt stimmen. Beim agentenbasierten Tool-Former-Ansatz erzeugt das Modell beide Arten von Ausgaben. Diese Unterscheidung entscheidet, ob ein Test als strikter Strukturvergleich oder als semantische Prüfung läuft.

Woher bekommt man aussagekräftige Testfälle für ein dialogbasiertes System?

Aus dem Pilotbetrieb. Der Pilotkunde sammelt anonymisierte, real stattgefundene Dialoge, das Team analysiert sie und misst etwa, wie viele Gespräche vollständig autonom bis zum Ziel kamen. Die suboptimalen Fälle werden zu neuen Akzeptanztests, parallel entstehen viele Trainingsdialoge im selben Format. Ein einziges Dialogformat dient so als Trainingsdaten und als Testfall.

Was unterscheidet CPMAI von älteren Vorgehensmodellen wie CRISP-DM?

CPMAI integriert Agilität und ergänzt eine sechste Stufe: das Deployment. Erst die Auslieferung schließt den Kreis, weil sie neue, businessorientierte Daten für die nächste Iteration liefert. Die sechs Stufen sind iterativ, man kann zwischen ihnen vor und zurück springen. Business und Data Understanding lassen sich zusammenlegen, wenn ohnehin dieselben Dialoge analysiert werden.

Wann lohnt sich Fine-Tuning gegenüber weiterem Prompt Engineering?

Wenn das Anpassen der Prompts allein nicht mehr weiterführt. Prompt Engineering ändert nur die Eingabe, Fine-Tuning justiert die Gewichte eines Basismodells hin zur konkreten Aufgabe. Beides schließt sich nicht aus, Prompt Engineering bleibt Teil der Lösung. Wie stark Fine-Tuning prägt, zeigt ein auf deutschen Dialogen trainiertes Modell, das auf Französisch angesprochen gelegentlich auf Deutsch antwortet.

Wie prüft man, ob ein Sprachmodell über Variationen derselben Anfrage hinweg stabil bleibt?

Über template-basierte Testdialoge. Man nimmt einen relevanten Dialog und ersetzt die Template-Variablen durch viele weitere Werte. Aus einem einzelnen Testfall wird so eine Messreihe zum selben Aspekt, also Combinatorial Testing im Sinne des Metamorphic Testing. Ergänzend laufen Stress-Tests, bei denen ein eigenes Sprachmodell die Nutzerseite übernimmt und die entstehenden Dialoge ausgewertet werden.

Lassen sich Trainings- und Testzyklen für ein LLM an feste Sprints binden?

Nur bedingt. Ein vollständiger Durchlauf deckt sich nicht zwingend mit einem zweiwöchigen Sprint: Mal passen mehrere Iterationen hinein, mal zieht sich ein einzelner Zyklus länger. Treiber ist die Nachfrage. Braucht ein neuer Pilotkunde eine zusätzliche Sprache, wird eine schnelle Zwischeniteration eingeschoben, die zunächst mit dem vorhandenen Modell startet.