Überwachen Sie die LLM-Produktionsdrift, ohne alles zu erfassen

Was die Forschung und Dokumentation abdeckt

ProxyDrift, ein Preprint vom August 2026, untersucht, wie man Live-Verkehr mit Testsätzen anhand strukturierter Zusammenfassungen von Interaktionen vergleicht. Diese Zusammenfassungen ermöglichen einen direkten Zugriff auf die Rohinteraktionen. Die Dokumentation von LangSmith beschreibt die Bewertung von Live-Läufen und das Hinzufügen von Beispielen zu Offline-Testsätzen. Das sind unterschiedliche Ansätze. Beides beweist nicht, dass eine Überwachungseinrichtung die Privatsphäre schützt oder alle Arten von Benutzeranfragen abdeckt.

Beweis: Datenschutzerhaltende Datendrift-Erkennung und -Wiederherstellung für große LLM-Anwendungen über Proxy-Darstellungen [1]LangSmith-Bewertung [2]

Beobachten Sie drei Arten von Veränderungen

Eingabedrift bedeutet, dass sich die Anforderungen geändert haben. Benutzer können andere Aufgaben stellen, neue Sprachen verwenden oder längere Dokumente senden. Ergebnisdrift bedeutet, dass sich die Ergebnisse geändert haben, beispielsweise mehr Fehler oder langsamere Antworten. Messdrift bedeutet, dass sich der Bewertungsprozess geändert hat. Ein neuer Richter, ein neuer Bewertungsleitfaden oder eine neue Stichprobenregel kann die Zahlen verschieben. Notieren Sie diese Änderungen separat.

Eine höhere Fehlerrate kann bedeuten, dass die eingehenden Aufgaben schwieriger sind. Das bedeutet nicht immer, dass das Modell schwächer ist. Ein unveränderter Durchschnitt kann auch ein Problem verbergen, wenn einfachere Anforderungen schwierigere Anforderungen ausgleichen. Vergleichen Sie Gruppen, die für Ihr Produkt wichtig sind, z. B. Sprache oder Aufgabentyp. Zeigen Sie die Anzahl der Beispiele hinter jeder Partitur an.

Führen Sie eine gezielte Überwachungsaufzeichnung

Rubrex empfiehlt, mit der Entscheidung zu beginnen, die jede Warnung unterstützen soll. Um eine Tool-Zeitüberschreitung zu untersuchen, benötigen Sie möglicherweise den Tool-Namen, die Uhrzeit, den Fehlertyp und die Softwareversion. Möglicherweise benötigen Sie nicht die vollständige Benutzernachricht. Um zu überprüfen, ob eine Antwort wahr ist, benötigen Sie möglicherweise das Quelldokument. Vereinbaren Sie, wer auf diese Daten zugreifen kann und wann sie gelöscht werden müssen.

Beschriftungen und zahlenbasierte Darstellungen, wie z. B. Einbettungen, können weiterhin vertrauliche Informationen enthalten. Prüfen Sie, ob sie private Details preisgeben oder einen Bezug zu einer Person herstellen können. Halten Sie Live-Benutzerdaten von öffentlichen Beispielen fern. Verwenden Sie fiktive Beispiele oder entfernen Sie sensible Details, wenn Sie einen Fehler erklären. Die Weitergabe transformierter Daten ist nicht automatisch sicher.

Beispiel: Gescannte Dokumente verursachen neue Fehler

Angenommen, ein Einkaufsassistent empfängt gescannte Dokumente, nachdem eine neue Integration gestartet wurde. Das Modell hat sich nicht geändert, aber das System hat jetzt Schwierigkeiten, den Text zu extrahieren. Der alte Testsatz verwendet sauberen digitalen Text. Es besteht immer noch Erfolg, auch wenn echte Benutzer mehr Fehler sehen.

Bestätigen Sie zunächst anhand von Beispielen, die Sie überprüfen dürfen, wo die Extraktion fehlschlägt. Fügen Sie gescannte Dokumente mit geprüftem Referenztext einer separaten Testgruppe hinzu. Testen Sie dann den Extraktionsschritt sowie die endgültige Antwort. Eine sofortige Änderung kann fehlenden Quelltext möglicherweise nicht beheben. Prüfen Sie, ob die neuen Tests das eigentliche Problem erfassen, bevor Sie sie als Warnsignal verwenden.

Geben Sie jeder Warnung einen nächsten Schritt

Benennen Sie für jede Warnung einen Besitzer. Erklären Sie, warum der Schwellenwert wichtig ist und was der Eigentümer zuerst überprüfen sollte. Überprüfen Sie Fehlalarme sowie Vorfälle, die der Alarm übersehen hat. Wenn ein echter Fehler zu einem Testfall wird, notieren Sie, woher er kam, was passieren sollte und welche Version des Testsatzes ihn enthält. Beachten Sie Änderungen im Datenverkehr und in den Bewertungsregeln, wenn Sie alte und neue Ergebnisse vergleichen.

• Notieren Sie die Anwendungs-, Testsatz-, Richter- und Stichprobenversionen.
• Vergleichen Sie die Qualität innerhalb jeder Aufgabengruppe sowie insgesamt.
• Sehen Sie sich eine breite Stichprobe sowie Fälle an, die Warnungen auslösen.
• Überprüfen Sie die Zugriffs- und Löschregeln für Rohdaten und abgeleitete Labels.

Machen Sie das Dashboard während eines Vorfalls nützlich

Die Überwachung zeigt, wie sich ausgewählte Signale im Laufe der Zeit verändern. Observability hilft Ihnen, ein Signal auf eine Anfrage, Systemeinstellung oder Abhängigkeit zurückzuführen. Die Auswertung prüft, ob das Ergebnis den Bedürfnissen des Nutzers entspricht. Rubrex empfiehlt, diese Datensätze mit einer Lauf-ID zu verknüpfen. Bewahren Sie nur die Daten auf, die für die Untersuchung gemäß den vereinbarten Datenregeln des Produkts erforderlich sind.

Versuchen Sie, einer Warnung von Anfang bis Ende zu folgen. Kann das Team die betroffenen Fälle und die Softwareversion finden? Kann jemand den Fehler in einen Test umwandeln, den ein anderer Ingenieur wiederholen kann? Zeigen Sie neben jedem Trend Stichprobenzahlen, fehlende Ergebnisse, schwerwiegende Fehler und Score-Definitionen an. Führen Sie nach einem Fix den Test erneut aus und prüfen Sie, ob sich das Ergebnis verbessert hat. Ein Dashboard ist nützlich, wenn es jemandem hilft, zu entscheiden, was als nächstes zu tun ist.

Häufige Fragen