Acceptance Test Driven LLM Development 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 Acceptance Test Driven LLM Development 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 Process 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 LLM 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.
| Stufe | Inhalt bei Mediform |
|---|---|
| Business Understanding | Mit Data Understanding vereint, weil dieselben Dialoge analysiert werden |
| Data Understanding | Analyse der gesammelten Dialoge, Ableitung neuer Business Requirements |
| Data Preparation | Akzeptanztests schreiben, Trainings-Set erstellen |
| Model Development | Fine-Tuning des Sprachmodells |
| Evaluation | Testwerkzeug ausführen, businessorientierte Metriken berechnen |
| Deployment | Demo, Pilotkunde oder Produktion, um neue Daten zu sammeln |
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 in französischem Dialekt 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.
