ZenML Pro führt Bots für automatisierte ML- und KI-Engineering-Aufgaben ein

Von fehlgeschlagenen Läufen zu prüfbaren Fehlerbehebungen

Bots sind für Aufgaben gedacht, die häufig auf einen fehlgeschlagenen Pipeline-Lauf oder einen leistungsschwachen KI-Workflow folgen. Ein Team kann einen Bot auffordern, einen fehlgeschlagenen Trainingslauf mit dem letzten erfolgreichen Lauf zu vergleichen, Pipeline-Metadaten, Artefakte, Konfiguration und Repository-Code zu prüfen und anschließend einen Entwurfs-Pull-Request mit einem vorgeschlagenen Fix zu öffnen. Mit einem autorisierten erneuten Lauf kann der Bot die Untersuchung über einen neuen Lauf fortsetzen, der die Änderung testet.

ZenML zufolge umfasst die Ausgabe sowohl die Codeänderung als auch die dahinterstehenden Ausführungsnachweise. Die Ergebnisse werden als Artefakte wie Code-Diffs, Pull-Requests, Berichte, Diagramme, Vergleiche sowie Links zu relevanten Läufen und Modellversionen aufgezeichnet. Bei Workflows zur Dokumentenverarbeitung kann ein Bot außerdem erklären, warum zwei Läufe unterschiedliche Ergebnisse geliefert haben, und dazu eine gezielte Codeänderung vorschlagen.

Agentenverhalten mit Kitaru testen

Der Bots-Workflow umfasst über Kitaru auch die Verbesserung von KI-Agenten. Bots können aufgezeichnete Agentensitzungen prüfen, wiederholte Tool-Aufrufe oder unnötige Modellanfragen untersuchen, eine vorgeschlagene Änderung testen und sie mit einer Baseline vergleichen. Teams können ein Experiment anfordern, das Qualitäts-, Kosten- und Latenzkompromisse anhand eines vereinbarten Evaluators ausweist.

Dieser Ansatz kann dabei helfen zu beurteilen, ob ein günstigeres Modell für eine bestimmte Arbeitslast geeignet ist. Ein Team kann Sitzungen auswählen und Qualitätskriterien festlegen und anschließend den Vergleich prüfen, bevor es über die Einführung einer Modell- oder Prompt-Änderung entscheidet.

ZenML beschreibt einen Benchmark mit einem Agenten zur Prüfung von Versicherungsansprüchen über acht Stapel mit jeweils 100 echten kalifornischen Gesundheitsbeschwerden. Die Testfälle wurden aus öffentlichen Berufungsentscheidungen erstellt. Über alle 800 Beschwerden hinweg erzielte der von einem KI-Engineer verbesserte Agent bei der Balanced Accuracy 3.3 Prozentpunkte mehr als der von Codex verbesserte Agent. Nachdem der Agent auf ein günstigeres Open Model umgestellt worden war, nutzte der KI-Engineer die aufgezeichneten Sitzungsenden, um Beschwerden zu finden, die ungelöst blieben, weil dem Agenten Tokens oder Modellanfragen ausgingen. Anschließend erhöhte er die Limits und testete die Änderung.

Das Unternehmen weist darauf hin, dass für den Vergleich unterschiedliche Setups verwendet wurden. Der KI-Engineer nutzte Kitaru und eine spezifische Anweisung, Sitzungsenden zu zählen, während Codex eine allgemeine Aufforderung zur Verbesserung erhielt. ZenML zufolge zeigte ein früherer Lauf ohne diese Anweisung keinen klaren Unterschied. Das Unternehmen bezeichnet das Ergebnis als einen einzelnen Benchmark und nicht als allgemeines Ranking von Coding-Agenten.

Regelmäßige Untersuchungen und kontrollierter Zugriff

Automatisierungen ermöglichen es Teams, einen konfigurierten Bot mit einem festen Prompt nach Zeitplan auszuführen. Eine tägliche Aufgabe könnte die fehlgeschlagenen Pipeline-Läufe des Vortags prüfen, wiederkehrende Fehler untersuchen, betroffene Läufe verknüpfen und Entwurfs-Pull-Requests öffnen, wenn eine Code-Korrektur eindeutig ist. Eine wöchentliche Aufgabe könnte KI-Workflows und Agentensitzungen auf vermeidbare Arbeit prüfen, vorgeschlagene Verbesserungen priorisieren und ein klar abgegrenztes Experiment identifizieren.

Teams legen fest, welchen Umfang und welche Aktionen jede wiederkehrende Aufgabe haben darf. ZenML stellt dies als praktischen FinOps-Workflow dar, um Verschwendung zu finden, eine Änderung vorzuschlagen sowie Kosten und Qualität vor der Einführung zu vergleichen. Jede geplante Ausführung verfügt über einen eigenen Chat und aufgezeichnete Ausgaben. In Slack oder GitHub gestartete Arbeiten kehren in den zugehörigen Thread zurück. Bei erforderlicher Aufmerksamkeit können Bots Slack-Benachrichtigungen senden.

Jeder Bot verwendet ein eigenes ZenML-Pro-Servicekonto. Rollen bestimmen, auf welche ZenML- und Kitaru-Arbeitsbereiche und Ressourcen er zugreifen kann. Separate Berechtigungen regeln, wer den Bot verwenden und verwalten darf. Bots laufen in isolierten Sandboxes, die mit Repositories, Einrichtungskommandos, Teamanweisungen und Fähigkeiten konfiguriert werden. Konnektoren unterstützen unter anderem GitHub, Notion, Context7, Firecrawl und Tavily. Auch benutzerdefinierte MCP-Server werden unterstützt.

Was Bots für Teams von ZenML Pro bedeuten

ZenML positioniert Bots als wiederholbaren Weg, Untersuchungen, vorgeschlagene Fehlerbehebungen und Evaluierungsergebnisse zur Prüfung durch Engineers vorzubereiten. Dieselbe Konfiguration kann von mehreren Engineers, für geplante Aufgaben und für Anfragen aus dem ZenML-Pro-Dashboard, aus Slack, GitHub, dem SDK oder der API wiederverwendet werden.

Das Unternehmen empfiehlt, mit einer wiederkehrenden Aufgabe zu beginnen, etwa der Untersuchung fehlgeschlagener ML-Pipelines, der Prüfung von Rückschritten in KI-Workflows oder der Suche nach einer Agentenverbesserung, die in Kitaru getestet werden kann. Teams können die relevanten Repositories, Fähigkeiten und Berechtigungen konfigurieren, die ersten Ergebnisse prüfen und die Aufgabe planen, sobald ihr Umfang feststeht. Entscheidungen darüber, was ausgeliefert wird, bleiben bei den Engineers. Vorbereitung und Beweissammlung übernimmt dagegen ein ständig verfügbarer Bot.