CI/CD für KI-Projekte ist nicht dasselbe wie CI/CD für traditionelle Software. Das habe ich auf die harte Tour gelernt, als mein perfekt konfiguriertes GitHub Actions-Pipeline ein KI-Modell-Update bereitstellte, das im Test einwandfrei funktionierte und in der Produktion Müll produzierte.
Das Problem: Mein Testset validierte die Logik des Codes, aber nicht das Verhalten des Modells. Der Code war korrekt. Die Ausgaben des Modells hatten sich aufgrund einer Änderung des Prompts verschoben, die alle Code-Tests bestand, aber das Verhalten des Agenten in einer Weise grundlegend veränderte, die meine Tests nicht erfassen konnten.
Traditionelles CI/CD setzt deterministische Ausgaben voraus: Gegebenenfalls Eingabe X, erwarten Sie Ausgabe Y. KI-Systeme haben probabilistische Ausgaben: Gegebenenfalls Eingabe X, erwarten Sie eine Ausgabe, die meistens ungefähr Y ist, abhängig von der aktuellen Stimmung des Modells.
Wie eine CI/CD-Pipeline für KI aussieht
Meine Pipeline hat fünf Phasen, im Vergleich zu den typischen drei (Build, Test, Deployment):
Phase 1: Build. Standard. Abhängigkeiten installieren, bei Bedarf kompilieren, die Anwendung paketieren. Hier ist nichts KI-spezifisch.
Phase 2: Code-Tests. Standard Unit- und Integrationstests. Macht der Code, was er soll? Sind die Funktionen korrekt? Reagieren die APIs? Dies fängt Fehler in der Anwendungslogik auf, testet aber nicht das Verhalten der KI.
Phase 3: Verhaltenstests. Dies ist die KI-spezifische Phase. Senden Sie Test-Prompts an den Agenten und bewerten Sie die Antworten. Nicht nach genauen Übereinstimmungen — sondern nach Verhaltenskriterien: „Erwähnt die Antwort die Schlüsselfakten? Ist der Ton angemessen? Hält sie sich an ihre Grenzen? Halluziniert sie?“
Ich habe 15 Verhaltenstestfälle, die die kritischsten Verhaltensweisen des Agenten abdecken. Jeder Test sendet einen Prompt und bewertet die Antwort anhand einer Checkliste. Ein Mensch hat die anfänglichen erwarteten Verhaltensweisen festgelegt; die CI-Pipeline überprüft, ob der Agent diese weiterhin erfüllt.
Phase 4: Canary Deployment. Bereitstellung in einer Staging-Umgebung und Routing eines kleinen Prozentsatzes des echten Traffics dorthin. 30 Minuten lang überwachen. Wenn die Fehlerquote normal ist und die Verhaltensqualität hält, fortfahren. Ansonsten automatisch zurückrollen.
Phase 5: Volles Deployment. In die Produktion ausrollen. 2 Stunden mit erweiterten Alarmierungsmaßnahmen überwachen.
Die Herausforderung der Verhaltenstests
Verhaltenstests sind der schwierigste Teil von AI CI/CD, weil die Antworten von AI variieren. Der gleiche Prompt kann bei jedem Mal unterschiedliche Antworten produzieren. Wie schreibt man einen Test für etwas Nicht-deterministisches?
Mein Ansatz: Testen von Einschränkungen statt spezifischer Ausgaben.
Anstatt: „Die Antwort muss genau ‘Das Wetter in London beträgt 18°C.’ sein.“
Testen auf: „Die Antwort muss London erwähnen. Die Antwort muss eine Temperatur enthalten. Die Antwort darf nicht behaupten, das aktuelle Wetter zu kennen (der Agent hat keinen Zugang zu Wetterdaten in diesem Test).“
Dieses testbasierte Einschränkungsansatz ist solider als das Testen auf genaue Übereinstimmungen. Es fängt Verhaltensregressionen (der Agent erwähnt London nicht mehr) auf, ohne bei harmlosen Variationen (äußere Formulierungen ändern sich zwischen den Durchläufen) zu brechen.
Prompt-Änderungen sind Deployments
Dies ist der größte Denkansatz für AI CI/CD: Eine Prompt-Änderung ist ein Deployment, kein Text-Edit.
Die Änderung Ihres System-Prompts kann jede Antwort, die der Agent produziert, verändern. Es ist gleichbedeutend damit, jede Funktion in Ihrem Code gleichzeitig zu refaktorisieren. Dennoch bearbeiten die meisten Menschen Prompts beiläufig, ohne Tests, Versionierung oder Rollback-Pläne.
Meine Regel: Prompt-Änderungen durchlaufen dasselbe CI/CD-Pipeline wie Code-Änderungen. Ändern Sie den Prompt in einem Branch, führen Sie Verhaltenstests durch, überprüfen Sie den Unterschied, mergen Sie in das Haupt-Branch, und deployen Sie durch die Pipeline. Wenn die Verhaltenstests fehlschlagen, wird die Prompt-Änderung abgelehnt.
Überwachung nach dem Deployment
KI-Deployments benötigen eine andere Überwachung als traditionelle Deployments:
Antwortqualitätsbewertung. Ein leichtgewichtiger Bewertungsmechanismus, der jede Antwort auf einer Skala von 1 bis 5 hinsichtlich Relevanz, Genauigkeit und Hilfsbereitschaft bewertet. Die Bewertung ist ungefähre (sie wird auch von der KI bewertet, was meta ist), fängt jedoch dramatische Qualitätsrückgänge auf.
Halluzinationsrate. Verfolgen Sie, wie oft der Agent Aussagen macht, die nicht auf seinen verfügbaren Daten basieren. Ein Anstieg der Halluzinationsrate nach einem Deployment bedeutet, dass der Prompt oder die Modelländerung eine Falschaussage eingeführt hat.
Nutzer-Feedback. Daumen hoch/runter für Agentenantworten. Das zuverlässigste Qualitätszeichen, aber mit dem niedrigsten Volumen. Nützlich für die Trendanalyse über Tage, nicht um Probleme in Minuten zu erfassen.
Kosten pro Interaktion. Ein Deployment, das den Agenten gesprächiger macht (längere Antworten, mehr Werkzeugaufrufe), wird die Kosten erhöhen. Verfolgen Sie dies, um unbeabsichtigte Kostensteigerungen zu erkennen.
Der ROI von AI CI/CD
Die Einrichtung dieser Pipeline hat mich etwa eine Woche gekostet. Die Wartung benötigt etwa 2 Stunden pro Monat (Aktualisierung der Verhaltenstests, Überprüfung der Canary-Deployments).
Seit der Implementierung habe ich: 3 Prompt-Änderungen erkannt, die die Qualität verschlechtert hätten, 2 Abhängigkeitsaktualisierungen, die Werkzeugintegrationen zerstört hätten, und 1 Änderung des Modellanbieters, die das Antwortverhalten verändert hat. Jede dieser Änderungen wäre ohne die Pipeline ein Produktionsvorfall gewesen.
Die Pipeline macht Deployments nicht langsamer — die automatisierten Phasen dauern etwa 5 Minuten. Sie macht Deployments sicherer. Und sichere Deployments sind die Art, die Sie tatsächlich regelmäßig durchführen, was bedeutet, dass Ihr Agent aktuell bleibt, anstatt eine Monate alte Version zu verwenden, weil Sie Angst haben, zu aktualisieren.
🕒 Published: