Agentische KI in Produktion: Drei Muster mit Azure Functions und Databricks

Alle bauen KI-Agenten. Die meisten dieser Agenten laufen in Notebooks, erfordern manuelle Trigger und scheitern lautlos, wenn etwas schiefgeht. Das ist für Demos in Ordnung. Es ist nicht in Ordnung, wenn Ihre ML-Pipeline um 3 Uhr morgens Modelle neu trainieren, evaluieren, ob die neue Version besser ist, und autonom entscheiden muss, ob promoted oder zurückgerollt wird.

Dieser Beitrag beschreibt drei agentische KI-Muster, die wir in der Produktion betreiben, alle enthalten in unserer Open-Source-Enterprise-Databricks-Plattform. Sie laufen auf Azure Functions mit Durable Functions für Orchestrierung, Service Bus für ereignisgesteuerte Aktivierung und Databricks für Compute.

Warum Azure Functions für KI-Agenten?

Die Wahl der Laufzeitumgebung ist wichtig:

VNet-Integration — Unsere Agenten interagieren mit Databricks und ADLS Gen2 über Private Endpoints. Azure Functions Premium (EP1) unterstützt VNet-Integration, sodass Agenten innerhalb desselben sicheren Perimeters wie die Daten und Compute-Ressourcen operieren.

Durable Functions — Das Orchestrator-Muster braucht zuverlässige, gecheckte Ausführung. Wenn der Function Host mitten im Workflow neu startet, spielt Durable Functions vom letzten Checkpoint ab.

Service-Bus-Trigger — Der Monitoring Responder braucht ereignisgesteuerte Aktivierung. Service Bus bietet Exactly-once-Delivery mit Dead-Letter-Queues.

Managed Identity — Functions authentifiziert sich bei allen Azure-Diensten über eine benutzerzugewiesene Managed Identity. Keine Geheimnisse, keine Token, keine Rotationspläne.

Muster 1: Durable Orchestrator

Der häufigste Fehlermodus in ML-Pipelines ist die Lücke zwischen „der Trainingsjob ist fertig" und „das Modell ist sicher in Produktion". Der Durable Orchestrator schließt diese Lücke mit einer Fünf-Schritte-Kette:

Der Workflow

validate_data → trigger_databricks_job → poll_job_status → evaluate_metrics → decide_action

Schritt 1 — validate_data: Prüft, ob der Eingabedatensatz minimale Qualitätsschwellen erfüllt (Zeilenanzahl, Null-Prozentsatz, Schema-Konformität). Bei Validierungsfehler stoppt der Orchestrator und sendet einen Alert.

Schritt 2 — trigger_databricks_job: Übermittelt einen Trainingslauf an einen Databricks-Job-Cluster über die Jobs API. Die Cluster-Konfiguration ist im Terraform-Modul definiert.

Schritt 3 — poll_job_status: Pollt den Databricks-Job-Status mit exponentiellem Backoff. Durable Functions verwaltet das Timer-Management — der Orchestrator schläft zwischen den Polls ohne Compute zu verbrauchen.

Schritt 4 — evaluate_metrics: Liest die Trainingsmetriken aus MLflow (RMSE, MAE, R2, MAPE). Vergleicht mit den Metriken des aktuellen Produktionsmodells. Hier trifft der Agent seine Entscheidung.

Schritt 5 — decide_action: Wenn das neue Modell bei allen verfolgten Metriken besser ist, Promotion durch Aktualisierung des MLflow-Modell-Alias von challenger auf champion. Bei Regression wird die Promotion abgelehnt. Bei gemischten Metriken wird menschliche Überprüfung angefordert.

Warum das besser ist als Cron-Jobs

Eine Cron-basierte Pipeline promotet entweder blind oder erfordert manuelle Metrikprüfung. Der Orchestrator evaluiert Metriken programmatisch und verarbeitet Teilausfälle elegant.

Muster 2: Multi-Agent (Planner-Executor-Critic)

Manche Workflows lassen sich nicht in eine feste Sequenz zerlegen. Modellverbesserung kann iteratives Feature-Engineering, Hyperparameter-Tuning oder Datenaugmentation erfordern.

Die Schleife

Planner → Executor → Critic → (Wiederholung oder Akzeptanz)

Planner-Agent analysiert den aktuellen Zustand und erstellt einen Plan.

Executor-Agent führt den Plan gegen Databricks aus.

Critic-Agent evaluiert das Ergebnis und gibt eines von drei Urteilen:

• Accept — Ergebnis erfüllt Kriterien. Mit Promotion fortfahren.
• Reject — Ergebnis erfüllt nach maximalen Versuchen nicht die Kriterien. Alert für menschliche Überprüfung.
• Retry — Ergebnis zeigt Verbesserung, erfüllt aber nicht die Kriterien. Feedback an den Planner für eine weitere Iteration.

Die Schleife läuft bis zu drei Iterationen. Jede Iteration enthält das Critic-Feedback, sodass der Planner seine Strategie anpassen kann.

Wann dieses Muster verwenden

Verwenden Sie die Planner-Executor-Critic-Schleife, wenn:

• Der Problemraum mehrere gültige Ansätze hat und der beste nicht vorab bekannt ist
• Iterative Verfeinerung basierend auf Zwischenergebnissen benötigt wird
• Einfache sequentielle Orchestrierung suboptimale Ergebnisse liefert

Verwenden Sie es nicht, wenn eine feste Sequenz ausreicht. Das Orchestrator-Muster ist einfacher und schneller zu debuggen.

Muster 3: Monitoring Responder

Produktive ML-Systeme degradieren. Datendrift, Schemaänderungen, Upstream-Pipeline-Ausfälle und Modell-Veraltung sind keine Ausnahmen — sie sind die normalen Betriebsbedingungen jedes langlebigen ML-Systems.

Funktionsweise

1. Alert-Quellen — Log Analytics erkennt Anomalien: Spike in der Modellfehlerrate, Datendrift über PSI-Schwelle, Pipeline-Ausfall
2. Service-Bus-Routing — Alerts werden als Nachrichten an Service-Bus-Queues veröffentlicht
3. Klassifizierung — Der Responder klassifiziert den Schweregrad (kritisch, Warnung, informativ)
4. Auto-Mitigation — Basierend auf Schweregrad und Alert-Typ:
   • Kritische Modelldegradation → Rollback auf vorherige Produktionsversion
   • Datendrift erkannt → Retraining-Job über den Orchestrator auslösen
   • Pipeline-Ausfall → Incident-Eintrag erstellen und On-Call-Team benachrichtigen
   • Budget-Alert → Ereignis protokollieren und nicht-essentielles Compute pausieren

Die Schlüsselerkenntnis

Der Monitoring Responder ersetzt nicht menschliches Urteilsvermögen — er übernimmt die ersten fünf Minuten. Ein Modell-Rollback um 3 Uhr morgens ist besser als zu warten, bis jemand um 9 Uhr das Dashboard prüft.

Wie die drei Muster zusammenwirken

In der Praxis bilden die drei Muster einen selbstverwaltenden ML-Lifecycle:

1. Neue Daten kommen im Bronze-Container an → Event Grid löst den Durable Orchestrator aus
2. Der Orchestrator trainiert, evaluiert und promotet (oder lehnt ab) das neue Modell
3. Wenn das Modell die Kriterien nach Basisevaluierung nicht erfüllt, iteriert die Multi-Agent-Schleife
4. In der Produktion überwacht der Monitoring Responder Drift und Degradation

Der gesamte Zyklus kann für Routinefälle ohne menschliches Eingreifen laufen.

Die Agenten ausführen

Alle drei Muster sind im databricks-enterprise-ai-platform-Repository enthalten. Das modules/compute_integration-Terraform-Modul provisioniert die Azure-Functions-Runtime, Service-Bus-Queues und Event-Grid-Subscriptions.

Weiterführende Ressourcen

• Wir haben unseren Enterprise-Databricks-KI-Plattform-Blueprint als Open Source veröffentlicht — Der vollständige Plattformkontext für diese Agent-Muster.
• Enterprise RAG-Pipelines: Architektur, Fallstricke und Best Practices — Ein weiteres KI-Architekturmuster für Enterprise-LLM-Deployments.
• LLMs im Unternehmen: Sicherheit, Kosten und Governance — Governance für die LLM-Schicht, mit der diese Agenten interagieren.

Möchten Sie autonome ML-Agenten in Ihrer Infrastruktur deployen? Kontaktieren Sie uns — wir helfen Teams beim Aufbau selbstverwaltender KI-Plattformen.