Auch deine Prompts brauchen Integrationstests

Ein Prompt sieht zunächst wie Konfiguration aus. Text ändern, ein paar Beispiele ausprobieren, ausrollen.

Das ist bequem. Und es funktioniert, solange der Prompt praktisch das gesamte Feature ist. Sobald Retrieval, Parsing und Anwendungscode dazukommen, reicht das nicht mehr.

Prompts entwickeln sich weiter. Das Produktteam findet neue Anwendungsfälle. Edge Cases sammeln sich an. Modelle ändern sich. Retrieval ändert sich. Das Eingabeformat ändert sich. Output-Schemas ändern sich.

Ab diesem Punkt reicht es nicht mehr, Beispiele manuell durchzugehen.

Der Prompt ist nur ein Schritt in der Pipeline

Ein Produktions-Prompt steht selten für sich allein.

Normalerweise gibt es Code, der den Input vorbereitet, Kontext abruft, ihn formatiert, den Prompt rendert, das Modell aufruft, die Antwort parst, strukturierte Ausgaben validiert und sie möglicherweise noch einmal transformiert.

Ein Playground kann dir zeigen, ob sich der Prompt bei einem bestimmten Input korrekt verhält. Er kann dir aber nicht sagen, ob die Anwendung ihm überhaupt den richtigen Input übergeben hat.

Besonders deutlich wird das bei RAG. Das Retrieval kann die richtigen Fakten liefern, aber im falschen Feld, in der falschen Reihenfolge oder in einer leicht anderen Datenstruktur. Der Prompt ist korrekt. Das System, das ihn füttert, ist es nicht.

Integrationstests decken genau diese Grenze ab.

Die Testsuite ist das Gedächtnis des Teams

Zehn Beispiele manuell zu testen ist am Anfang einfach.

Ein paar Monate später sind aus zehn fünfzig geworden. Ein Product Manager hat einen Edge Case gefunden. Etwas ist in Produktion fehlgeschlagen. Das Modell hat sich unerwartet verhalten.

Niemand erinnert sich an alle Fälle. Menschen verlassen das Team. Die Fehler bleiben.

Jeder relevante Fehler sollte zu einem Testfall werden. Mit der Zeit wird die Suite zur Dokumentation dessen, womit das System umgehen können muss.

Das gilt besonders dann, wenn Prompts außerhalb des Repositories in Tools wie Langfuse liegen. Einen Prompt zu ändern wird sehr einfach. Etwas kaputtzumachen, das vorher funktioniert hat, leider auch.

Modellwechsel sind potenzielle Regressionen

Selbst Modelle desselben Anbieters können auf denselben Prompt unterschiedlich reagieren.

Behandle einen Modellwechsel deshalb ähnlich wie das Upgrade einer wichtigen Dependency.

Führe dieselben Testfälle gegen das neue Modell aus, bevor du wechselst. Die Frage ist nicht, ob das neue Modell allgemein besser ist. Die Frage ist, ob es weiterhin das Verhalten liefert, auf das diese Anwendung angewiesen ist.

Teste nicht den exakten Wortlaut

LLM-Integrationstests sollten keine exakten Formulierungen prüfen.

Bei strukturierten Outputs solltest du das testen, was die Anwendung tatsächlich verwendet: Pflichtfelder, erlaubte Werte, Wertebereiche, Klassifizierungen, Beziehungen zwischen Feldern und Geschäftsregeln.

Bei freierem Output können semantische oder modellbasierte Evaluierungen helfen, solange die Tests eine gewisse Varianz tolerieren.

Du testest Verhalten, nicht Formulierungen.

Teste die Pipeline, nicht den Prompt

Prompt-Level-Tests sind nützlich, während du den Prompt entwickelst.

Sobald das Feature Teil eines echten Produkts ist, lautet die Frage nicht mehr:

"Funktioniert dieser Prompt?"

Sondern:

"Funktioniert das System weiterhin mit diesem Prompt, diesem Modell, diesem Retrieval-Ergebnis und diesem Anwendungscode zusammen?"

Genau dafür sind Integrationstests da.

Wenn niemand mehr den Prompt anfassen möchte, weil alle Angst haben, dadurch an anderer Stelle etwas kaputtzumachen, ist die Teststrategie bereits ins Hintertreffen geraten.

Brauchst du Unterstützung?

Wenn ein LLM-Feature zu fragil geworden ist, um es sicher weiterzuentwickeln, kann ich helfen. Meistens ist die Lösung nicht ein größerer Playground, sondern eine Testsuite auf Pipeline-Ebene, die den nächsten Prompt-Edit, Modellwechsel oder Retrieval-Change erkennt, bevor es die Produktion tut.

Hinweis: Dieser Artikel wurde mithilfe von KI aus dem englischen Original ins Deutsche übersetzt.