ServiceNow macht aus Agenten-Fehlern Trainingsdaten

Jedes Team, das einen KI-Agenten in einem echten Unternehmenssystem eingesetzt hat, kennt denselben Schmerz. Das Modell ist breit einsatzfähig und trifft dann auf Ihre spezifischen Tools, Ihre spezifischen Richtlinien, Ihr spezifisches Durcheinander einer Zustandsmaschine – und es stolpert.

Der Forschungsbereich von ServiceNow, CoreAI, hat ein System veröffentlicht, das versucht, aus diesen Stolperern einen Vorteil zu machen. Es heißt AutoSynthData, und seine Prämisse ist, dass die Fehler eines Modells der wertvollste Rohstoff sind, den man für sein Training hat.

Der zentrale Schachzug

Die Pipeline beginnt damit, ein Zielmodell und ein stärkeres Teacher-Modell dieselben diagnostischen Aufgaben in einer realen Umgebung ausführen zu lassen. Wo das Zielmodell scheitert und das Teacher-Modell erfolgreich ist, gibt es eine Fähigkeitslücke. AutoSynthData destilliert diese Lücke in das, was das Team Capability-Specification-Karten nennt: bereinigte Beschreibungen der beteiligten Tools, Workflows, Endzustände und zulässigen Variationen, befreit von den ursprünglichen Evaluierungs-Prompts und Entitätsdetails.

Diese Karten dienen als Ausgangspunkt für die Generierung neuer Aufgaben. Entscheidend ist, dass der Generator nie die ursprünglichen Evaluierungstrajektorien sieht, sodass die resultierenden Daten die zugrunde liegende Kompetenz testen und nicht auswendig gelernte Sequenzen. Das Framework skaliert dies in zwei Phasen. Eine Zielphase erstellt Kernaufgaben parallel. Eine Multiplizierungsphase nimmt die verifizierten Aufgaben und erzeugt Varianten mit neuer Formulierung, neuen Entitätskonfigurationen und neuen Ausgangszuständen. Eine Regel verhindert, dass die Daten abdriften: Eine multiplizierte Stichprobe darf nie eine weitere Multiplikation als Ausgangspunkt dienen.

Drei Bedingungen für eine Aufgabe, die es wert ist, generiert zu werden

ServiceNow macht deutlich, dass eine plausibel wirkende Anfrage nicht ausreicht. Eine generierte Aufgabe muss drei Dinge gleichzeitig erfüllen.

Sie muss machbar sein, das heißt, es gibt mindestens einen ausführbaren Pfad durch die Umgebung, der die Anfrage abschließt und dabei die Regeln einhält. Sie muss realistisch sein, das heißt, sie spiegelt Arbeit wider, die ein echter Nutzer tatsächlich anfragen würde, und nicht eine technisch gültige Aktion, die niemand ausführen würde. Und sie muss schwierig sein, das heißt, sie zielt auf eine echte Schwäche ab. Eine triviale Aufgabe lehrt nichts, und eine unmögliche lehrt die falsche Lektion.

Jede Aufgabe wird mit einem Verifier ausgeliefert, und der Verifier muss seine eigene Messlatte erfüllen. Er muss mit dem Prompt und dem Systemzustand konsistent sein, belastbar genug, um Verstöße gegen Einschränkungen zurückzuweisen, und vollständig genug, um jede funktionierende Lösung zu akzeptieren, statt auf einem einzigen Referenzpfad zu bestehen.

Die Qualitäts-Gates sind das eigentliche Produkt

Der Teil daran, der Aufmerksamkeit verdient, ist nicht die Aufgabengenerierung. Es ist die Prüfung.

Jeder Kandidat durchläuft zwei Gates. Ein positives Gate führt die Referenzlösung innerhalb der Umgebung aus, um zu bestätigen, dass die beabsichtigte Antwort tatsächlich den Verifier erfüllt, wodurch Diskrepanzen zwischen dem Prompt, dem Ausgangszustand und den Erfolgskriterien erkannt werden. Ein negatives Gate verändert dann absichtlich den Endzustand, um zu bestätigen, dass falsche Ergebnisse tatsächlich zurückgewiesen werden. Dieses zweite Gate ist dasjenige, das unterspezifizierte Verifier erkennt – die Art, die eine fehlerhafte Agenten-Trajektorie bereitwillig belohnen würde.

Wenn ein Kandidat fehlschlägt, diagnostiziert ein Kritiker den Zusammenbruch, erkennt defekte Referenzen oder widersprüchliche Zustände und leitet eine begrenzte Reparatur ein, anstatt die Arbeit sofort zu verwerfen. Oberhalb der Stichprobenebene beobachtet eine Batch-Überprüfung die Gesamtheit: welche Aufgabencluster überrepräsentiert sind, welche Dimensionen fehlen, welche Generierungsmuster immer wieder ins Stocken geraten. Der Controller steuert dann den nächsten Batch auf die verbleibenden Lücken zu.

Warum überhaupt jemand synthetische Daten braucht

Es lohnt sich, einen Schritt zurückzutreten und zu fragen, warum das wichtig ist. Die idealen Trainingsdaten für einen Unternehmensagenten sind ein Protokoll echter Menschen, die echte Arbeit im echten System erledigen, korrekt gekennzeichnet. Diese Daten sind knapp, sensibel und teuer zu sammeln, und ein Großteil davon kann aus Datenschutz- oder Compliance-Gründen das Unternehmen nicht verlassen.

Synthetische Generierung ist das Ventil, aber sie bringt einen bekannten Fehlermodus mit sich. Wenn Sie Aufgaben aus einem Modell generieren, erben Sie die blinden Flecken dieses Modells, und die resultierenden Daten können reichlich erscheinen, während sie sehr wenig lehren. Der gesamte Beitrag von AutoSynthData ist die Maschinerie rund um die Generierung, die die Daten ehrlich hält: Gates, die schlechte Aufgaben zurückweisen, Diversitätsprüfungen, die Wiederholung verhindern, und ein Curriculum, das weiterhin auf das abzielt, was der Agent noch nicht beherrscht. Generierung ohne Verifikation ist Rauschen. Dies ist ein Versuch, daraus Signal zu machen.

Was die Zahlen sagen – und was nicht

In Tests auf EnterpriseOps Gym, einer Open-Source-Umgebung für Unternehmensagenten-Aufgaben, verbesserte ein Gemma-basiertes Modell, das auf 2.000 AutoSynthData-Stichproben feinabgestimmt wurde, seine Pass@1-Metrik in einer hybriden Domäne um 35 Prozent gegenüber der Baseline. In der ITSM-Domäne hob synthetisches überwachtes Feintuning den mittleren Pass@1 von 18,77 Prozent auf 27,18 Prozent.

Das sind echte Zugewinne auf einem bestimmten Benchmark, was nicht dasselbe ist wie ein allgemeines Ergebnis. Die zentrale Abhängigkeit der Pipeline ist ehrlich und verdient eine klare Benennung: Sie braucht ein deutlich stärkeres Teacher-Modell, das korrektes Verhalten demonstriert, und eine akkurate Simulationsumgebung zum Testen. In einem Unternehmen ohne hochpräzise Sandbox und zuverlässige deterministische Verifier ist der Aufbau der Ausführungsebene selbst ein ernsthaftes Engineering-Projekt. AutoSynthData ersetzt diese Arbeit nicht. Es verändert, wofür die Arbeit dient.

Der Haken beim Teacher-Modell

Es gibt eine Abhängigkeit in diesem Design, die einen eigenen Satz verdient. Die gesamte Pipeline beruht auf der Lücke zwischen einem schwachen und einem starken Modell. In den Experimenten war das Teacher-Modell deutlich größer als das Zielmodell. Das funktioniert, wenn man ein Frontier-System hat, von dem man borgen kann. Es funktioniert weniger gut, wenn man selbst die Frontier ist oder wenn die Aufgabe so spezialisiert ist, dass kein stärkeres Modell existiert, das sie demonstrieren könnte. In diesem Fall hat die Pipeline nichts, woraus sie lernen kann, und die Fähigkeitslücke, von der sie abhängt, ist einfach eine Wand. Forschung zur Generierung von Trainingsdaten stößt irgendwann immer darauf: Die Methode skaliert, solange jemand, irgendwo, das Problem bereits gelöst hat.

Warum dies die Gestalt von Enterprise-KI ist

Das Interessante an dieser Veröffentlichung ist, was sie darüber verrät, wo Enterprise-KI tatsächlich steht. Der Engpass ist nicht mehr, ein leistungsfähiges Modell zu bekommen. Der Engpass ist, ein leistungsfähiges Modell dazu zu bringen, innerhalb einer bestimmten Organisation mit ihren bestimmten Tools und Regeln korrekt zu funktionieren, wo die Fehler subtil und der Zustandsraum groß ist.

Jahrelang war die Antwort manuelle Annotation, die langsam, teuer und schwer zu skalieren ist. AutoSynthData ist ein Argument dafür, dass die Fehler selbst das Signal enthalten, wenn man sie extrahieren, verifizieren und diversifizieren kann, ohne das Evaluierungsset zu leaken. Die Pipeline ist für die Forschung auf Hugging Face verfügbar, und das Team sagt, dass Reinforcement Learning mit derselben Methodik als Nächstes folgt.

Wenn es breit funktioniert, bedeutet das, dass sich die knappe Fähigkeit in der Enterprise-KI verschiebt. Es geht nicht mehr um die Beschaffung von Daten, sondern um den Aufbau von Umgebungen, die gut genug sind, um darin vertrauenswürdige Daten zu generieren. Das ist ein schwierigeres Problem – und ein dauerhafteres, weil die Umgebung eines Unternehmens das ist, was kein Wettbewerber kopieren kann.