Ihr Test am Montag war erfolgreich. Gleiche Eingabe, gleicher Code, temperature=0. Am Dienstag schlug er fehl, und Sie hatten nichts geändert. Die Assertion prüfte auf eine exakte Zeichenkette, und das Modell gab die gleiche Antwort nur etwas anders formuliert zurück. Der Test ist rot, der Agent ist in Ordnung, und jetzt debuggen Sie Ihre Testsuite anstatt Ihr Produkt.
Das ist der Preis dafür, alles zu testen, was ein Sprachmodell aufruft. Die Ausgabe bewegt sich, selbst wenn Sie es ihr verboten haben. Stellen Sie die Temperatur auf Null, und Sie werden immer noch keine byte-identischen Antworten über mehrere Durchläufe hinweg erhalten. Die meisten Entwickler lernen dies auf die harte Tour, einmal, und schreiben dann ihre Teststrategie neu. Dieser Leitfaden zeigt Ihnen, wie Sie Assertions schreiben, die Bestand haben, auch wenn sich der zugrunde liegende Text ständig ändert. Es ist der tiefgehende Einblick in den Fehlermodus drei aus unserem Leitfaden zu warum KI-Agenten in der Produktion scheitern.
Warum temperature=0 nicht Deterministik bedeutet
Die Temperatur steuert, wie das Modell das nächste Token samplet. Bei Null nimmt es jedes Mal das wahrscheinlichste Token, was sich so anfühlt, als sollte es reproduzierbar sein. Das ist es aber nicht, und die Gründe liegen unterhalb des Modells.
Gleitkomma-Arithmetik ist auf einer GPU nicht assoziativ. Addieren Sie dieselben Zahlen in einer anderen Reihenfolge, und Sie erhalten ein leicht unterschiedliches Ergebnis in der letzten Dezimalstelle. Dieser winzige Unterschied kann beeinflussen, welches Token am höchsten rangiert, und ein einziges anderes Token ändert alles danach. Die Reihenfolge dieser Additionen hängt davon ab, wie der Anbieter Ihre Anfrage mit anderem Traffic bündelt, welche Hardware sie ausführt und welche Kernel-Version an diesem Tag eingesetzt wird. Sie haben keine Kontrolle darüber.
Anbieter ändern auch Dinge auf ihrer Seite. Sie tauschen GPUs aus, aktualisieren Inferenzbibliotheken, re-quantisieren Gewichte und leiten Ihren Anruf in eine andere Region. Eine lange vLLM-Diskussion erläutert, warum ein fester Seed und temperature=0 immer noch nicht ausreichen, um Bit-weise Reproduzierbarkeit zu gewährleisten. Die Kurzfassung: Determinismus ist eine Eigenschaft des gesamten Serving-Stacks, nicht ein Flag, das Sie in Ihrer Anfrage setzen.
Hören Sie also auf, identische Ausgaben als Basis zu betrachten. Das Modell gibt Ihnen eine Antwort, die dasselbe bedeutet, egal wie sie in diesem Durchlauf formuliert ist. Ihre Tests müssen das akzeptieren.
Assertions mit exakten Zeichenketten machen Ihre Suite unzuverlässig
Hier ist die Falle. Sie schreiben assert response == "Your order total is $42.00.", weil das das erste Mal zurückkam. Es ist erfolgreich. Dann gibt das Modell „Ihre Gesamtsumme beträgt $42.00“ zurück, und der Test schlägt bei einer korrekten Antwort fehl.
Ein Test, der bei einer korrekten Antwort fehlschlägt, ist schlimmer als gar kein Test. Das Team lernt, dass diese Suite ständig Fehlalarme gibt. Die Leute führen ihn erneut aus, bis er grün wird, hören dann auf, die Fehler zu lesen, und übersehen dann die echte Regression, die im Rauschen begraben ist. Unzuverlässige Tests verschwenden nicht nur Zeit, sie untergraben auch das Vertrauen in die gesamte Suite, und wir haben bereits darüber geschrieben, was unzuverlässige Tests verursacht und warum sie sich verbreiten. Nicht-deterministische Ausgaben sind eine der schnellsten Möglichkeiten, sie zu erzeugen.
Der Instinkt ist, die Ausgabe noch stärker zu fixieren: die exakte Zeichenkette zu erfassen, sie als Schnappschuss zu speichern, sie zu vergleichen. Das verschlimmert die Unzuverlässigkeit, weil Sie Ihren Test an das Einzige gekoppelt haben, was sich garantiert ändert. Sie brauchen die entgegengesetzte Bewegung.
Auf Struktur und Bedeutung prüfen, nicht auf exakten Text
Die Ausgabe variiert, aber der darunterliegende Vertrag sollte nicht variieren. Ein Support-Agent könnte eine Rückerstattungsbestätigung auf hundert Arten formulieren, doch jede gültige Antwort enthält dieselben Fakten: einen Rückerstattungsbetrag, eine Bestell-ID, einen Status. Testen Sie die Fakten, nicht die Formulierung.
Das ist die ganze Veränderung. Hören Sie auf zu fragen „Hat das Modell genau das gesagt?“ und fangen Sie an zu fragen „Hat die Antwort die richtige Form, die richtigen Felder und Werte im richtigen Bereich?“. Diese Eigenschaften überstehen Umformulierungen. Eine echte Regression, ein fehlendes Feld, eine Zahl außerhalb der Grenzen, eine falsch formatierte Payload, löst immer noch die Assertion aus. Hier sind die Strategien, die dies in die Praxis umsetzen.
Die Antwort anhand eines JSON-Schemas validieren
Wenn Ihr Agent strukturierte Daten zurückgibt, definieren Sie ein JSON-Schema dafür und validieren Sie jede Antwort anhand dieses Schemas. Das Schema prüft Typen, erforderliche Felder, zulässige Enums und Formate, ohne sich um spezifische Werte zu kümmern. Ein status-Feld muss eines von refunded, pending oder denied sein. Eine order_id muss Ihrem ID-Muster entsprechen. Ein amount muss eine Zahl sein, keine Zeichenkette.
Dies ist die stärkste einzelne Assertion, die Sie gegen eine nicht-deterministische Antwort schreiben können, da sie die Fehler abfängt, die wehtun: Das Modell hat ein Feld weggelassen, das Objekt falsch verschachtelt oder Prosa zurückgegeben, wo Sie JSON erwartet haben. Laden Sie Ihr Antwortschema in Apidog und validieren Sie die Live-Antworten des Agenten dagegen. Eine Nichtübereinstimmung benennt genau das Feld, das den Fehler verursacht hat, nicht einen 400-Zeichen-String-Diff.
Prüfen, ob der Tool-Aufruf die richtige Form und das richtige Ziel hat
Wenn Ihr Agent beschließt, ein Tool aufzurufen, testen Sie den Aufruf, nicht den Satz, der dazu führte. Prüfen Sie drei Dinge: Es hat das richtige Tool ausgewählt, es hat das richtige Ziel angesteuert und die Payload entspricht dem Schema des Tools. Ein Buchungsagent, der POST /reservations aufruft, sollte guests als Integer und ein gültiges date senden, unabhängig davon, welche natürlichsprachliche Argumentation diesen Aufruf erzeugt hat.
Dies ist dieselbe Disziplin wie die Validierung eines Antwortkörpers, angewendet auf die ausgehende Anfrage. Prüfen Sie, ob die erforderlichen Parameter vorhanden sind, die Typen korrekt sind und keine erfundenen Felder eingeschmuggelt wurden. Die End-to-End-Methode zum Testen der API-Aufrufe eines Agenten behandelt das Erfassen dieser Tool-Schemas und deren Prüfung. Eine Tool-Call-Payload hat einen Vertrag, auch wenn die Formulierung darum herum nicht fest ist.
Numerische Bereiche statt genauer Werte verwenden
Für jede Zahl, die das Modell erzeugt oder durchleitet, prüfen Sie einen Bereich, nicht einen genauen Wert. Ein Einkaufswagen-Agent berechnet eine Gesamtsumme. Sie kennen die genaue Zahl nicht über jeden Durchlauf, jeden Warenkorb und jede Steuerregel hinweg, aber Sie wissen, dass sie nicht negativ sein und den Warenkorbwert plus maximale Versand- und Steuerkosten nicht überschreiten darf. Prüfen Sie also Folgendes: Die Antwort enthält eine total zwischen 0 und dieser Obergrenze.
Diese einzelne Begrenzung fängt die Fehler ab, die wichtig sind – eine negative Gesamtsumme, eine zehnmal zu große Gesamtsumme, eine Gesamtsumme von Null bei einem vollen Warenkorb –, während sie Variationen ignoriert, die Sie nicht interessieren. Bereiche funktionieren für Konfidenzwerte, Artikelanzahlen, Token-Verbrauch, Latenzbudgets und jede abgeleitete Zahl. Wählen Sie die breiteste Begrenzung, die immer noch bei einem echten Fehler fehlschlägt.
Prüfen, ob erforderliche Schlüssel existieren und verbotene Felder fehlen
Zwei einfache Assertions haben viel Gewicht. Erstens sind die Schlüssel, auf die Sie sich verlassen, vorhanden und nicht null. Zweitens fehlen die Schlüssel, die niemals erscheinen dürfen. Ein Agent, der ein Support-Ticket bearbeitet, sollte eine resolution zurückgeben und niemals ein Feld wie internal_notes oder raw_prompt an den Kunden weitergeben.
Prüfungen auf Vorhandensein und Abwesenheit sind per Design immun gegen Umformulierungen, da sie das Skelett der Antwort testen, nicht ihren Inhalt. Sie sind auch Ihr günstigster Schutz gegen eine ganze Klasse von Datenschutzlecks, bei denen das Modell hilfreicher Weise ein Feld enthält, das es privat hätte halten sollen.
Semantische und Schwellenwertprüfungen für Freitext verwenden
Manchmal ist die Payload Prosa, und Sie müssen sie trotzdem testen. Eine exakte Übereinstimmung funktioniert nicht, also prüfen Sie stattdessen Eigenschaften. Enthält die Antwort die Bestellnummer, die Sie übergeben haben? Bleibt sie unter einer Längenbegrenzung? Vermeidet sie eine Sperrliste von Phrasen, die Sie niemals an einen Benutzer senden möchten?
Wenn Sie die Bedeutung wirklich testen müssen, vergleichen Sie die Einbettungsähnlichkeit mit einer Referenzantwort und prüfen Sie, ob der Score einen Schwellenwert überschreitet, anstatt zu verlangen, dass die Zeichenketten übereinstimmen. Behandeln Sie diese semantischen Prüfungen als grobes, nicht präzises Tor. Sie fangen eine Antwort ab, die vom Thema abgewichen ist. Sie fangen keinen subtilen sachlichen Fehler ab, also kombinieren Sie sie mit den oben genannten strukturellen Assertions.
Bereichs-Snapshots, nicht exakte Snapshots
Snapshot-Tests haben immer noch ihren Platz, solange Sie die stabilen Teile als Schnappschuss festhalten. Frieren Sie die Form der Antwort, den Satz der Schlüssel, die Typen, die Enum-Werte ein und lassen Sie die frei fließenden Felder innerhalb von Grenzen variieren. In der Praxis erfasst Ihr Schnappschuss „diese Antwort hat die Schlüssel a, b, c, wobei b in diesem Bereich und c aus diesem Satz liegt“ und nicht einen eingefrorenen Blob exakten Textes. Wenn der Schnappschuss bricht, bricht er an einer strukturellen Änderung, die überprüft werden muss, nicht an einem Synonym.
Zustand und Gedächtnis erschweren dies
Alles oben Genannte geht von einer Anfrage herein, einer Antwort heraus aus. Agenten arbeiten nicht so. Sie führen Erinnerungen über mehrere Runden hinweg mit sich, und dieser Zustand vervielfacht die Quellen der Variation.
Die Antwort eines zustandsbehafteten Agenten hängt davon ab, was er abgerufen, was er zuvor gespeichert und in welcher Reihenfolge frühere Runden liefen. Zwei Durchläufe derselben Konversation können auseinanderlaufen, weil ein Abrufschritt Dokumente anders bewertet hat oder weil eine in Runde zwei geschriebene Zusammenfassung die Argumentation in Runde fünf beeinflusst hat. Jetzt variiert Ihre Ausgabe aus zwei sich verstärkenden Gründen: der modellinternen Nicht-Determiniertheit und einem anderen Startzustand. Unser Erklärer zu wie das Gedächtnis von KI-Agenten funktioniert erklärt, wo dieser Zustand lebt und wie er aufgebaut wird.
Zwei Gewohnheiten halten dies testbar. Erstens: Kontrollieren Sie den Zustand, den Sie können. Initialisieren Sie den Speicher des Agenten vor jedem Test auf einen bekannten Ausgangspunkt, so dass Sie nur eine Sache und nicht zwei variieren. Zweitens: Prüfen Sie auf Invarianten, die unabhängig vom Pfad gelten. Ein laufendes Guthaben sollte niemals negativ werden. Eine Konversation, die einen Flug gebucht hat, sollte mit genau einer Reservierung enden, egal wie viele Runden sie gedauert hat. Pfadunabhängige Assertions sind diejenigen, die einen zustandsbehafteten, nicht-deterministischen Agenten überleben.
Abhängigkeiten mocken, damit der Test wiederholbar ist
Sie können nichts davon gegen Live-APIs von Drittanbietern proben. Sie limitieren Sie, sie ändern ihre Daten und sie fügen eine zweite Quelle der Zufälligkeit zusätzlich zum Modell hinzu. Um einen wiederholbaren Test zu erhalten, fixieren Sie alles, was nicht das Verhalten ist, das Sie testen.
Mocken Sie die APIs, die der Agent aufruft, und programmieren Sie feste Antworten. Jetzt gibt die Zahlungs-API immer dieselbe Quittung zurück, die Such-API immer dieselben drei Ergebnisse, und das Einzige, was sich noch bewegt, ist die eigene Denkweise des Agenten, die Sie beobachten möchten. Eine gemockte Abhängigkeit ermöglicht es Ihnen auch, die Randfälle zu erzwingen, die eine gesunde API nicht auf Anfrage produzieren würde, und dann zu prüfen, ob der Agent sie handhabt. Richten Sie Apidog auf die Abhängigkeiten des Agenten aus, um diese Mocks mit stabilen, kontrollierbaren Bodies einzurichten, und kombinieren Sie sie mit den oben genannten Schema-Assertions. Dies gehört zur breiteren Praxis des Agentic AI Testing, wo Mocking und Assertion zusammenarbeiten.
Wo Apidog passt (und wo nicht)
Seien Sie genau bei der Aufgabenbeschreibung des Tools. Apidog ist eine Plattform für API-Design, -Tests und -Mocking. Es ist kein Agent-Framework, kein Modell-Host, keine Agent-Laufzeitumgebung und keine Evaluations- oder Observability-Plattform. Es baut Ihren Agenten nicht, führt ihn nicht aus, orchestriert seine Schritte nicht und bewertet seine Argumentation nicht.
Was es besitzt, ist die API-Schicht, mit der Ihr Agent kommuniziert, und hier leben diese Tests. Zwei ehrliche Passungen. Sie schreiben Assertions zu den API-Antworten des Agenten (Schema-Validierung, Antwortform, numerische Bereiche, erforderliche und verbotene Schlüssel, Tool-Call-Payload-Form), die nicht-deterministische Ausgaben überleben. Und Sie mocken die Abhängigkeiten des Agenten, damit ein Test zweimal auf die gleiche Weise läuft. Das ist die Nahtstelle, die Apidog füllt: der Vertrag über Anfragen und Antworten, nicht das Modell, das sie produziert.
Testen Sie den Vertrag, nicht die Formulierung
Nicht-Determinismus ist kein Fehler, den man wegkonfigurieren kann. Er ist eine Eigenschaft des Betriebs eines Sprachmodells, und temperature=0 schaltet ihn nicht ab. Die Teams, die zuverlässige Agenten ausliefern, haben aufgehört, dagegen anzukämpfen. Sie testen die Dinge, die konstant bleiben, das Schema, die Form, die Bereiche, die erforderlichen Felder, und sie lassen die Formulierung sich bewegen. Tun Sie das, und Ihre Suite wird auf die gute Weise leise: Sie bleibt grün, während der Text driftet, und wird nur dann rot, wenn wirklich etwas kaputt ist.
Nehmen Sie diese Woche eine unzuverlässige Assertion in Ihrer Suite und schreiben Sie sie als Schema- und Bereichsprüfung um. Laden Sie Apidog herunter, um die Antworten Ihres Agenten gegen einen Vertrag zu validieren und die Abhängigkeiten zu mocken, die Tests wiederholbar machen.