BlogUmsetzung

Was stehen muss, bevor ein KI-Pilot in Produktion geht

Ein Pilot zeigt, dass ein System die Arbeit erledigen kann, solange seine Entwickler zusehen. Die Produktion braucht das, womit andere es betreiben können, wenn niemand zusieht: einen Regressionstestsatz, der bei jeder Änderung läuft, versionierte Prompts und Modelle mit Rückfallweg, Monitoring von Qualität und Kosten neben der Verfügbarkeit, eine benannte verantwortliche Person mit Supportweg und einen stufenweisen Start. Prüfen Sie das in einem Readiness Review vor der Umstellung, nicht nach dem ersten Vorfall.

Von Aktualisiert am

Was sich ändert, wenn das Pilotteam nicht mehr zusieht

  • Fehler bemerken. Im Piloten lesen die Entwickler die meisten Ergebnisse. In der Produktion müssen Monitoring und eine stichprobenartige Prüfung finden, was schiefgeht.
  • Das System ändern. Aus einem im Notebook bearbeiteten Prompt wird ein versioniertes Release, das eine Pipeline durchläuft und zurückgerollt werden kann.
  • Testen. Anthropics Leitfaden zu Evaluierungen unterscheidet Capability-Evals, die mit niedriger Bestehensquote beginnen und zeigen, was zu verbessern ist, von Regressions-Evals, die fast vollständig bestanden werden sollten und schützen, was bereits funktioniert. Die Produktion braucht die zweite Art.
  • Support. Aus einer Nachricht an den Entwickler wird ein Supportweg, ein Runbook und jemand, der während der Prozesszeiten erreichbar ist.
  • Volumen. Aus einigen hundert Testfällen wird das volle Volumen mit Spitzen, Ratenlimits der Anbieter und gelegentlichen Ausfällen.

Ein Readiness Review nach SRE-Vorbild

Die SRE-Teams von Google führen ein Production Readiness Review durch, bevor sie die Verantwortung für einen Dienst übernehmen, mit einer Checkliste, die auf diesen Dienst zugeschnitten ist. Gefragt wird zum Beispiel, ob alle für Nutzer sichtbaren Fehler mit Alarmierung überwacht werden und ob Fehler im zentralen Logging ankommen. Für einen KI-Prozessdienst kommen Punkte hinzu, die klassische Dienste nicht haben.

  1. 1

    Regressionssuite

    Zurückgehaltene Fälle plus jeder im Piloten gefundene Fehler, ausgeführt bei jeder Änderung an Prompt, Modell, Werkzeug oder Retrieval-Einstellung. Eine Regression blockiert das Release.

  2. 2

    Versionen und Rollback

    Prompts, Modellkennungen und Werkzeugdefinitionen werden gemeinsam versioniert, und die vorherige Version lässt sich wieder ausrollen. Das AWS Generative AI Lens empfiehlt versionierte Prompt-Vorlagen genau aus diesem Grund.

  3. 3

    Monitoring

    Fehler, Latenz und Kosten pro Fall, dazu Qualitätssignale: die Fehlerquote der Stichprobe, die Eskalationsquote und regelmäßige Läufe gegen den Referenzdatensatz, um Drift zu erkennen.

  4. 4

    Zielwerte mit Konsequenzen

    Wenige Zielwerte für Qualität, Bearbeitungszeit und Kosten, mit einer vereinbarten Reaktion, wenn einer verfehlt wird. Das SRE-Buch rät, Zielwerte wenige und einfach zu halten.

  5. 5

    Sicheres Scheitern

    Wenn der Modellanbieter nicht antwortet oder ausfällt, gehen Fälle in die manuelle Queue und gehen weder verloren noch bleiben sie halb bearbeitet.

  6. 6

    Verantwortung und Support

    Eine benannte verantwortliche Person, ein Supportweg für die Zeiten, in denen der Prozess läuft, und ein Runbook für die bisher beobachteten Fehler.

Ein hypothetisches Go-live-Gate

Stellen Sie sich einen Piloten zur Vorsortierung von Schadenmeldungen vor, der seine Abnahmekriterien erfüllt hat. Beim Readiness Review besteht die Regressionssuite, ein Rollback wurde in Staging geprobt, die Fehlerquote der Stichprobe erscheint auf einem Dashboard, und eine Teamleitung aus der Schadenabteilung hat die Verantwortung übernommen. Ein Punkt fehlt: Niemand hat getestet, was passiert, wenn der Modellanbieter nicht erreichbar ist. Der Go-live wartet, bis ein simulierter Ausfall zeigt, dass Fälle in der manuellen Queue landen. Ein einziger offener Punkt reicht, um den Go-live zu verschieben, denn er betrifft einen Fehlerpfad, dessen Funktionieren noch niemand gesehen hat.

Übergabe an das Team, das den Betrieb übernimmt

Im Modell von Google schulen die Prüfenden das übernehmende Team mit Designübersichten, Vertiefungen in Anfrageabläufe und praktischen Übungen und übertragen die Verantwortung dann schrittweise, während die Entwickler eine Zeit lang als Rückhalt verfügbar bleiben. Bei einem KI-System sind die Übungen konkret: gemeinsam Fehlerprotokolle lesen, die Regressionssuite auf eine geplante Prompt-Änderung anwenden, ein Rollback durchführen und einen Sprung der Kosten pro Fall erklären. Definieren Sie das Ende der Rückhaltphase über ein Ereignis, etwa ein Rollback, das das Betriebsteam allein bewältigt, statt über ein Datum.

Stufenweise einschalten

Das AWS Lens beschreibt das Deployment als kontrollierten Rollout, der auf echte Daten und Nutzung skaliert. Für einen Prozess heißt das meist eine Schattenphase, in der das System läuft und Menschen die Arbeit weiter erledigen, eine assistierte Phase, in der das System vorschlägt und Menschen entscheiden, und danach jeweils ein Falltyp oder eine Region. Jede Stufe braucht vorab festgehaltene Ausstiegskriterien und einen Auslöser für das Zurückrollen. Ob Coding-Agenten Softwareänderungen vom Issue bis zum Merge übernehmen sollten, ist eine andere Frage, die unser Artikel zur autonomen Software Factory behandelt.

Fragen

Wie lange sollte das Pilotteam nach dem Go-live beteiligt bleiben?

Bis das Betriebsteam die wichtigen Ereignisse ohne Hilfe bewältigt hat, etwa ein Rollback, einen Anbieterausfall und ein Release über die Regressionssuite. Vereinbaren Sie diese Ereignisse vorab, damit das Ende der Übergabe erkennbar ist.

Braucht ein KI-Prozess eine Rufbereitschaft rund um die Uhr?

Das hängt davon ab, wann der Prozess läuft und wie er scheitert. Schickt ein Fehler Fälle sicher in eine manuelle Queue, kann Support während der Arbeitszeiten des Prozesses genügen. Das entscheidet die verantwortliche Person, nachdem das Fehlerverhalten getestet ist.

Gilt die Checkliste, wenn der Pilot ein Produkt eines Anbieters genutzt hat?

Ja. Einige Punkte werden zu Fragen an den Anbieter, etwa wie Modellwechsel angekündigt werden und ob sich eine frühere Version wiederherstellen lässt. Ihre eigene Regressionssuite bleibt der Weg, die Antworten zu überprüfen.

Was geht als Erstes kaputt, wenn ein Agent live geht?

Meist die Teile rund um das Modell, die der Pilot nie beansprucht hat. Vier zeigen sich früh. Werkzeuge und Systeme fallen auf eine Weise aus, die der Pilot nicht gesehen hat, etwa durch Zeitüberschreitungen, geänderte Felder oder abgelaufene Zugangsdaten, und der Agent braucht einen festgelegten Weg, anzuhalten oder den Fall an einen Menschen zu übergeben. Wiederholungsversuche führen dieselbe Geschäftsaktion doppelt aus, etwa eine zweite Buchung oder eine zweite E-Mail, solange nicht jede Aktion idempotent ist, also bei Wiederholung keine weitere Wirkung hat. Die Kosten pro Fall steigen schleichend, weil Wiederholungen, längere Kontexte und neue Fallarten zusätzliche Modellaufrufe bringen. Und die Qualität sinkt unbemerkt, wenn sich die Mischung der eingehenden Fälle ändert oder ein Anbieter ein Modell aktualisiert. Das fangen nur Stichprobenprüfungen und die Regressionstests ab. Unsere Leitfäden zu Werkzeugfehlern von Agenten, zu idempotenten Agentenaktionen und zur Überwachung eines laufenden Agenten behandeln jeden dieser Punkte.

Mit einem Engineer sprechen

Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.

Die Buchung läuft über Google Kalender.

Mickey Graf

Wenn Sie ein Gespräch buchen, sprechen Sie mit Mickey Graf

Er hat Cloudsail gegründet und bringt seit 2017 Machine Learning in Produktion, unter anderem als AI Engineer bei trivago und SAP. Das Gespräch führen Sie auf Deutsch, Englisch oder Polnisch.

Mit 4,9 von 5 auf Clutch bewertet

Lieber erst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen. Mickey liest jede Nachricht selbst und antwortet per E-Mail mit Terminvorschlägen.

Die Schaltfläche bereitet in Ihrem eigenen E-Mail-Programm eine E-Mail vor, die Sie selbst senden. Datenschutzerklärung (Entwurf)