Es beginnt harmlos: Ein Klassifikations-Agent hat seit Monaten eine Genauigkeit von 92 %. Dann fällt sie auf 89 % — kaum merkbar innerhalb des täglichen Rauschens. Nach sechs Wochen liegt sie bei 81 %. Die ersten Kunden beschweren sich. Was passiert ist? Drift — und er war die ganze Zeit da.
Drei Arten von Drift — und warum jede anders erkannt werden muss
Model-Drift: Wenn sich das Fundament verschiebt
LLM-Provider aktualisieren ihre Modelle regelmäßig — manchmal angekündigt, oft still. Ein GPT-4-Update kann das Verhalten von Prompts verändern, die monatelang stabil liefen. Wir haben Fälle gesehen, in denen ein Provider-Update die Sortierlogik eines Dokumentenklassifikators um 15 Prozentpunkte verschlechtert hat — ohne dass sich ein einziges Wort im Prompt geändert hat.
Erkennung: Canary-Prompts — ein Satz definierter Testeingaben mit bekannten erwarteten Ausgaben, die bei jedem Deployment oder Provider-Update automatisch durchlaufen werden. Sinkt die Trefferquote, schlägt die Pipeline Alarm.
Daten-Drift: Wenn sich die Eingabe verändert
Ihre Agenten wurden auf einer bestimmten Verteilung von Eingabedaten trainiert — bestimmten Dokumenttypen, Sprachmustern, Anfragekategorien. Wenn sich die Zusammensetzung der Eingaben ändert (neue Produktlinie, neues Kundensegment, neue Dokumentvorlagen), driftet die Leistung — obwohl das Modell und der Prompt unverändert sind.
Erkennung: Statistische Überwachung der Eingangsverteilung. Wenn der Anteil einer Kategorie plötzlich um mehr als zwei Standardabweichungen vom gleitenden Mittelwert abweicht, liegt eine Verteilungsverschiebung vor.
Behavior-Drift: Wenn sich der Kontext veraltet
Prompts altern. Ein Wissens-Assistent, der im Januar mit aktuellen Richtlinien gefüttert wurde, verliert im Juli an Relevanz — weil sich die Richtlinien geändert haben, ohne dass der RAG-Index aktualisiert wurde. Auch Tool-Responses können sich ändern: Eine API liefert zusätzliche Felder, ein CRM hat neue Pflichtfelder. Der Agent reagiert unerwartet — nicht weil er kaputt ist, sondern weil seine Umwelt ihn überholt hat.
Erkennung: Regelmäßige Eval-Sets — ein repräsentativer Satz von Frage-Antwort-Paaren, der monatlich gegen den Agenten läuft und die Übereinstimmung mit den erwarteten Antworten prüft.
Monitoring-Patterns für den Agent-Betrieb
Drift-Erkennung ist kein einmaliges Setup, sondern ein kontinuierlicher Prozess. Drei etablierte Patterns haben sich im Agent-Betrieb bewährt:
- Canary-Prompts: 10–20 Testeingaben mit erwarteten Outputs. Läuft bei jedem Deployment und wöchentlich im Cron. Schwellwert: < 85 % Trefferquote = Alert.
- Eval-Sets: 50–100 domänenspezifische Frage-Antwort-Paare. Läuft monatlich. Schwellwert: Rückgang > 5 Prozentpunkte gegenüber Vorwoche = Untersuchung.
- Statistical Process Control (SPC): Überwachung der Fehlerquote über Zeit mit Kontrollgrenzen. Ein Punkt außerhalb der 3σ-Grenze = definiter Drift-Alarm.
Was Drift-Erkennung praktisch bedeutet
Drift ist unvermeidlich — jede Software, die mit der realen Welt interagiert, driftet. Die Frage ist nicht, ob Drift auftritt, sondern wie schnell Sie ihn erkennen und wie systematisch Sie reagieren. Unternehmen mit aktivem Drift-Monitoring erkennen Leistungsabfälle im Durchschnitt zwei Wochen früher als Unternehmen ohne — und die Kosten der Korrektur sind um den Faktor drei bis fünf geringer.
Die Korrektur selbst ist meist einfach: Prompt-Update, Index-Refresh, Retraining. Was fehlt, ist in der Regel nicht das Werkzeug, sondern die Beobachtung.
Drift ist die natürliche Krankheit aller Agent-Systeme. Wer nicht misst, merkt es erst, wenn die Kunden es tun — und dann ist es bereits ein Vorfall, keine Optimierung.