Qualität von und mit Prompt Engineering

Prompt Engineering für Testgenerierung bedeutet, einem Large Language Model durch gezielte Prompt-Muster schrittweise bessere Testfälle zu entlocken. Bewährte Techniken sind Few-Shot-Beispiele für Robustheit, eingebettete Bibliotheksspezifikationen für Korrektheit und das ReAct-Pattern für stabile Konversationssequenzen. Korrektheit bleibt dabei die zentrale ungelöste Schwäche.

Das Wichtigste in Kürze

• Prompt Engineering ersetzt kein menschliches Review: Selbst nach iterativer Verbesserung mit mehreren Prompt-Patterns blieben von elf generierten Testfällen zwei fehlerhaft, weil das Modell Korrektheit nicht zuverlässig garantiert.
• Few-Shot-Beispiele im Prompt erhöhen die Robustheit messbar: Sie verhindern, dass das Modell bei minimalen Prompt-Änderungen komplett andere oder absurde Ergebnisse liefert.
• Domänenspezifisches Wissen direkt im Prompt verankern verbessert die Korrektheit stärker als allgemeines Prompt-Tuning: Das Einfügen einer konkreten Bibliotheks-Spezifikation hat die Trefferquote der Testfälle deutlich gesteigert.
• Das ReAct-Pattern (Reasoning plus Action) ist das robusteste Prompt-Muster aus Davids Experimenten: Es hat Halluzinationen in den getesteten Szenarien vollständig verhindert und Prompts gegenüber Abwandlungen stabil gehalten.
• Tester sind für Prompt Engineering besser qualifiziert als viele andere Rollen, weil sie gewohnt sind, Korrektheit zu prüfen, Anforderungen zu spezifizieren und repräsentative Beispiele zu konstruieren.

Prompt Engineering ist die Disziplin, die Sprachmodelle für Qualitätsarbeit brauchbar macht

Prompt Engineering bezeichnet die gezielte Gestaltung von Anweisungen an ein Sprachmodell, damit es eine konkrete Aufgabe zuverlässig erfüllt. Es ist die Alternative zum Fine-Tuning, bei dem man ein Modell mit gesammelten und gelabelten Daten nachtrainiert. Beim Prompt Engineering bleibt das Modell unverändert, die Steuerung passiert allein über den Text der Anfrage.

David Faragó nutzt diesen Ansatz seit dem Erscheinen von GPT-3. Sein erster ernsthafter Versuch betraf die Bewertung von Commit-Nachrichten. Statt ein Modell aufwendig zu fine-tunen, formulierte er eine Spezifikation auf Basis bestehender Guidelines und ergänzte sie um Beispiele. Das Modell vergab daraufhin Noten für die Qualität von Commit-Nachrichten, mit erstaunlich guten Ergebnissen.

Für Tester ist das Thema näher dran, als es zunächst klingt. Viele Prompt-Patterns drehen sich um Qualität und nicht-funktionale Aspekte. Genau das ist das tägliche Brot im Testing.

Warum du dich auf die Korrektheit generierter Tests nicht verlassen kannst

Sprachmodelle liefern bei der Testgenerierung keine garantiert korrekten Ergebnisse. Das ist die zentrale Einschränkung, und sie wiegt schwer, sobald es um etwas Spezifisches statt um etwas Kreatives geht.

David beschreibt zwei Momente, die seine anfängliche Euphorie gedämpft haben. Beim Commit-Nachrichten-Experiment lieferte das Modell zunächst eine schlechte Note mit einer überzeugenden Begründung. Eine minimale Änderung, ein Komma zu einem Semikolon, kippte das Urteil komplett: Dieselbe schwache Commit-Nachricht bekam plötzlich eine Bestnote. Das Ergebnis war schlicht falsch.

Den zweiten Dämpfer brachte ChatGPT bei einem statistischen Problem. Die Antwort klang durchgehend plausibel, enthielt aber in der Mitte einen Fehler von etwa zehn Prozent. David wandte die vorgeschlagene Methode an und rannte ein bis zwei Tage in eine Sackgasse, weil er das Ergebnis nicht genug hinterfragt hatte.

Bei kreativen Aufgaben wie einem Gedicht ist eine inhaltliche Abweichung verkraftbar. Bei Testfällen nicht. Wenn ein generierter Test fehlschlägt, suchst du den Fehler im System under Test, dabei steckt er im Test selbst.

Das Ding kann viel, aber meine Hand dafür ins Feuer legen, dass es immer ein korrektes Ergebnis liefert, würde ich nicht. David Faragó

Wie sich ein Prompt Schritt für Schritt verbessern lässt

Ein guter Prompt entsteht iterativ, indem man bewährte Prompt-Patterns einzeln anwendet und das Ergebnis vergleicht. Ähnlich wie es Design-Patterns in der Softwareentwicklung gibt, existieren dokumentierte Prompt-Patterns, und es kommen wöchentlich neue dazu.

David hat etwa fünf bis zehn Patterns ausgewählt, die sich in seiner Praxis bewährt haben, und sie an einem einzelnen Beispiel zur Testgenerierung sukzessive ergänzt. Das Beispiel war bewusst klein gehalten, eine String-Verarbeitung mit Python und PyTest.

Bei jeder Iteration wurde ein Aspekt besser, ein anderer dafür schlechter. Testabdeckung und Strukturierung der Tests verbesserten sich merklich. Die Korrektheit blieb der wunde Punkt. Das Endergebnis war deutlich besser als der erste Versuch, aber nicht einwandfrei.

Zwei Hebel entscheiden über die Qualität: Robustheit und Korrektheit

Die größte Wirkung auf die Testqualität hatten zwei Stellschrauben. Robustheit beschreibt, ob das Modell bei leichter Änderung oder bloßer Wiederholung des Prompts ein vergleichbares Ergebnis liefert, statt etwas völlig anderes auszuwerfen.

Konkrete Beispiele im Prompt erhöhen die Robustheit. Dieser Ansatz heißt Few-Shot Learning. Er sorgt nicht für immer identische oder immer korrekte Tests, aber er unterbindet die absurden Fälle: dass das Modell den gesamten System-under-Test-Code in die Testdatei kopiert, unnötige Imports einbaut oder vor und nach dem Testcode lange Erklärtexte schreibt.

Der zweite Hebel ist die Korrektheit, und hier half eine simple Maßnahme. David arbeitete mit einer Abhängigkeit namens difflib. Das Modell kannte das Modul und beschrieb auf Nachfrage den zugrunde liegenden Algorithmus, blieb aber vage. Erst als er die difflib-Spezifikation, etwa vier bis fünf Absätze Text, direkt in den Prompt kopierte, wurde die Korrektheit der generierten Tests spürbar besser.

Die Faustregel daraus: Verlass dich nicht darauf, dass das Modell sein eigenes Wissen präzise abruft. Liefere die relevante Spezifikation mit, auch wenn das Modell den Inhalt theoretisch kennt.

Konversation schlägt Einzelprompt: das Modell als eigener Prüfer

Ein einzelner Prompt ist nicht das Ende. Mit Coverage-Kriterien im Prompt erzeugte David aus dem String-Beispiel elf Testfälle. Die Vorstufe ohne die zusätzliche Abdeckungsanforderung hatte fünf Tests geliefert, alle korrekt. Mit der Aufforderung, die Testabdeckung zu erhöhen, kamen elf teils schwierigere Tests heraus, von denen zwei wieder fehlerhaft waren.

Statt diesen einen Prompt weiter zu optimieren, ging David in eine Konversation über. Dafür gibt es ein eigenes Pattern: Man lässt das Modell selbst beurteilen, ob seine vorherige Ausgabe die gestellte Aufgabe erfüllt hat.

Das ist intuitiv nachvollziehbar. Ein generatives Sprachmodell produziert Wort für Wort. Ein fertiges Ergebnis im Nachhinein zu beurteilen ist eine leichtere Aufgabe als es fehlerfrei zu erzeugen. Beim Menschen ist es genauso: Zu bewerten, ob etwas gut oder schlecht ist, fällt leichter, als selbst etwas Gutes zu schaffen. In Davids Fall erkannte das Modell die zwei fehlerhaften Testfälle als solche.

Welche Ansätze gegen Halluzination wirklich helfen

Korrektheit verbessert sich am ehesten über durchdachte Prompt-Sequenzen, weniger über spezialisierte Modelle. David hat das Constitutional-AI-Modell Claude von Anthropic ausprobiert, einem Unternehmen ehemaliger OpenAI-Mitarbeiter. Auf die Frage, ob es halluziniere, antwortete das Modell, es sei ein Constitutional-AI-Modell und halluziniere nicht. Die generierten Testfälle hatten dann etwa die Qualität von Davids erstem, schwachem ChatGPT-Versuch. Beim Thema Korrektheit war das Ergebnis enttäuschend.

Mehr überzeugt hat ihn das React-Pattern. React steht für Reasoning und Action und hat nichts mit dem Frontend-Framework zu tun. Der Reasoning-Teil ähnelt Chain of Thought, bei dem man das Modell anweist, Schritt für Schritt zu denken, bevor es ein Ergebnis ausgibt. Der Action-Teil bringt dem Modell bei, externe Aufrufe zu machen oder Informationen von außen einzuholen.

Bei einem Chatbot-Experiment für MediForm erlebte David mit einem sauber geschriebenen React-Pattern eine sehr hohe Robustheit. Er konnte einen einzelnen Aspekt im Prompt korrigieren, alles andere blieb stabil. In der Handvoll Experimente, die er gemacht hat, trat keine Halluzination auf.

Das React-Pattern findet sich auch in verbreiteten Werkzeugen wieder. Auto-GPT geht in Richtung GPT-Agent und kombiniert eine ganze Sequenz von Prompts mit Plugins und externen API-Aufrufen. Die Bibliothek LangChain, mit der sich solche Agenten programmieren lassen, nutzt unter der Haube ein React-ähnliches Pattern.

Tester sind als Prompt Engineers im Vorteil

Wer testet, bringt genau die Denkweise mit, die Prompt Engineering verlangt. Korrektheit ist die zentrale Schwäche der Modelle, und Qualität ist die Kernkompetenz im Testing.

Viele Prompt-Patterns zielen auf Qualität und nicht-funktionale Aspekte. Gute Few-Shot-Beispiele für einen Prompt auszuwählen oder eine saubere Anforderungsspezifikation zu formulieren, liegt Testern. Der prüfende, skeptische Blick auf ein Ergebnis ist im Prompt Engineering ein Vorteil, kein Hindernis.

So fängst du im Kleinen an

Der Einstieg lohnt sich schon mit kleinen, täglichen Aufgaben. Der Return on Invest ist hoch, der Aufwand gering.

David nutzt ChatGPT nebenher für überschaubare Probleme: eine Bibliothek wieder ins Gedächtnis holen, die er länger nicht verwendet hat, oder einen langen, unbekannten Stacktrace deuten lassen. Häufig nennt das Modell die Fehlerursache direkt. Wo man früher zu Stack Overflow oder Google gewechselt ist, kann heute ein Wechsel zum Sprachmodell stehen.

Der Dialog ist der eigentliche Vorteil gegenüber einer Suchanfrage. Wenn ein Thema mehr Interaktion verlangt und du Teilaspekte in Folgefragen klären willst, ist das Modell nützlicher als eine einzelne Google-Suche. Auf diesem Weg sammelt sich Erfahrung an, die später beim systematischen Prompt Engineering trägt.

Wohin sich das Feld bewegt: offene Modelle und effizienteres Fine-Tuning

Die Weiterentwicklung läuft stark über offene Modelle und neue Fine-Tuning-Techniken. Meta hat Llama als Open Source veröffentlicht, wenn auch nicht für kommerzielle Nutzung. Anders als beim reinen Prompt Engineering hat man hier das Modell selbst zur Verfügung und kann es fine-tunen, um Eigenschaften wie Korrektheit zu verbessern.

Modellgrößen reichen von etwa drei oder sechs Milliarden Parametern bis zu 13, 30 oder 60 Milliarden. Größere Modelle zu fine-tunen ist hardwareseitig schwierig. Dagegen entstehen wöchentlich neue Optimierungen: Quantisierung, das Fine-Tuning nur bestimmter Parameter oder das Merken von Gewichtsunterschieden statt der Gewichte selbst.

Ein geleaktes Google-Dokument mit dem Titel “We have no moat” argumentiert, dass weder Google noch OpenAI einen dauerhaften Vorsprung haben, weil Open-Source-Entwicklung und offen publizierte Forschung den Abstand rasch aufholen. David hält das Dokument für einseitig, sieht darin aber einen wahren Kern.

Wie viel noch nötig ist, um ein so robustes und korrektes System zu bauen, dass man es guten Gewissens in einem sicherheitskritischen Bereich einsetzen kann, lässt sich in dieser disruptiven Phase kaum prognostizieren. Manches mit großem Wow-Effekt erweist sich in der Praxis als untauglich, während unscheinbarere Ansätze richtig nützlich werden.