Warum Generative AI Testing die übliche Assertion aushebelt
Prüfen Sie die Antwort gegen eine feste Zeichenkette, schlägt der Test beim zweiten Durchlauf fehl – aus Gründen, die nichts mit Ihrem Produkt zu tun haben. Lockern Sie die Prüfung auf einen Teilstring, läuft sie auch bei Ausgaben durch, die subtil falsch sind. Beides hilft nicht weiter, und das Hin und Her zwischen diesen Varianten führt Teams zu dem Schluss, dass sich generative Funktionen nicht testen lassen.
Was Sie stattdessen prüfen sollten
| Eigenschaften | Gültiges JSON, alle Pflichtfelder vorhanden, Länge eingehalten, Verweis auf eine Quelle, die es tatsächlich gibt. Prüfbar und über Durchläufe hinweg stabil. |
| Ablehnungen | Das Modell lehnt ab, was es ablehnen soll, und tut das konsistent. Oft die wertvollste Prüfung der gesamten Suite. |
| Grounding | Jede Aussage lässt sich auf etwas im bereitgestellten Kontext zurückführen. Deckt Erfundenes auf, ohne über den Stil zu urteilen. |
Raten, nicht Ergebnisse
Ein einzelner Durchlauf sagt nichts aus. Schicken Sie dieselbe Eingabe viele Male durch und erfassen Sie, wie oft die Eigenschaft erfüllt ist. Ihre Maßeinheit ist eine Rate, und Ihr Signal ist die Veränderung dieser Rate, nicht ein einzelner Fehlschlag.
Damit ändert sich auch, was eine Regression bedeutet. Die Frage lautet nie „Ist es perfekt?", sondern „Hat diese Änderung es gegenüber der vergangenen Woche verschlechtert?".
Die Eigenschaften auswählen, die Sie prüfen
Das Schwierige daran ist nicht die Mechanik, sondern die Entscheidung, was Sie prüfen, wenn Sie die Antwort selbst nicht prüfen können. Ein guter Einstieg ist die Frage, was die Ausgabe unbrauchbar machen würde, statt der Frage, was sie gut machen würde.
Unbrauchbar ist konkret: fehlerhaft formatierte Ausgaben, die der Aufrufer nicht parsen kann, ein Verweis auf etwas, das es nicht gibt, eine Ablehnung, die eine Antwort hätte sein müssen, eine Antwort, die eine Ablehnung hätte sein müssen, Inhalte, die ein nachgelagertes Limit überschreiten. Jeder dieser Punkte ist binär und prüfbar, und jeder entspricht einem realen Vorfall statt einer Meinung über Qualität.
Gut dagegen ist ein Urteil, das je nach Reviewer anders ausfällt und sich nicht lohnt, als Gate festzuschreiben. Erfassen Sie es gern, mit manueller Durchsicht einer Stichprobe, aber halten Sie es aus der Pipeline heraus, wo es Diskussionen statt Entscheidungen erzeugt.
Der Teil, der sich normal testen lässt
Der größte Teil eines Produkts mit einer generativen Funktion ist ganz gewöhnliche deterministische Software: Authentifizierung, Speicherung, Rate Limiting, die Oberfläche rund um die Funktion. All das sollten Sie konventionell testen. Wer das gesamte Produkt als nicht-deterministisch behandelt, nur weil ein Teil davon es ist, verschenkt viel günstige Abdeckung.
Ziehen Sie die Grenze explizit. Innerhalb davon: Eigenschaften und Raten. Außerhalb davon: normale Assertions gegen die laufende Anwendung.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie nichts installieren möchten, erledigt das Dashboard dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.
Zwei Wege, und die Wahl hängt im Kern davon ab, wer die Pipeline verantwortet. Die Anbindung der GitHub App über das Dashboard erfordert keinerlei Änderung an Ihrem Repository, denn sie reagiert auf das Deployment, das Ihr Build ohnehin erzeugt. Ein Schritt mit GitHub Actions legt die Prüfung ins Repository, wo sie wie der restliche Build im Review landet.
Was TestSprite rund um die Funktion abdeckt
Den deterministischen Großteil des Produkts, der bei den meisten Teams mit Abstand der größere Anteil ist. Authentifizierung, Speicherung, Rate Limiting, die Oberfläche rund um die Funktion und jeder Ablauf, den ein Nutzer tatsächlich durchläuft, sind gewöhnliche Software und lassen sich konventionell testen. Auto-Authentication hält Sessions über einen Durchlauf hinweg aktiv, Dynamic Variables übergeben Werte zwischen Aufrufen, Dependency Chains leiten die Ausführungsreihenfolge ab, und Auto-Cleanup entfernt genau das, was der Durchlauf erzeugt hat.
Die Abdeckung wird aus Ihrem Produkt generiert und in natürlicher Sprache verfeinert, und sie läuft bei jeder Änderung gegen die deployte Anwendung – damit wird genau das exakt geprüft, was sich exakt prüfen lässt.
Die generative Funktion selbst braucht Eigenschaften und Raten, also ein eigenes Harness mit einem eigenen Begriff von Bestehen. Diese Grenze explizit zu ziehen verhindert, dass ein Team entweder statistische Methoden auf deterministischen Code anwendet oder Assertions ganz aufgibt, weil exakte Vergleiche ständig fehlgeschlagen sind.
Können wir die Ausgabe von einer KI bewerten lassen?
Verbreitet und praktikabel, mit einer Einschränkung: Der Bewerter hat eigene Fehlermodi und braucht eine eigene Kalibrierung. Gleichen Sie ihn an einer Stichprobe mit dem menschlichen Urteil ab, bevor Sie ihm vertrauen.
Wie viele Durchläufe ergeben eine aussagekräftige Rate?
So viele, dass sich der Wert nicht mehr bewegt, wenn Sie weitere hinzunehmen. Beginnen Sie eher im Bereich von Dutzenden als von Hunderten und achten Sie darauf, wann er stabil wird.
Sollten generative Tests einen Merge blockieren?
Ein starker Einbruch einer Ablehnungsrate: ja. Kleine Qualitätsschwankungen: nein, sonst wird die Pipeline zu Rauschen.
Und die Kosten?
Wiederholte Durchläufe kosten Geld. Prüfen Sie bei jeder Änderung eine Stichprobe statt des kompletten Satzes, und lassen Sie den kompletten Satz nach Zeitplan laufen.
Ist Prompt-Testing dasselbe?
Verwandt. Prompt-Änderungen sind die häufigste Ursache für veränderte Raten – ein gutes Argument dafür, Prompts als versionierte Artefakte zu behandeln.
Eigenschaften und Raten, nicht Gleichheit.
Generative AI Testing ersetzt exakte Assertions durch Eigenschaften, Ablehnungen und Grounding, gemessen als Raten über viele Durchläufe hinweg. Testen Sie den deterministischen Großteil des Produkts normal und ziehen Sie die Grenze explizit.