AutoSynthData: Trainingsdaten für Enterprise-Agenten verwandelt Fehler in einen Lehrplan

ServiceNow CoreAI veröffentlichte AutoSynthData am 2. Oktober und berichtete über Fortschritte durch nahezu 4.000 synthetische Aufgaben in zwei Experimenten mit Enterprise-Agenten. AutoSynthData: Generating Training Data for Enterprise Agents beginnt bei Modellfehlern und wandelt diese Schwächen dann in ausführbare und überprüfbare Trainingsbeispiele um. Der Zielkonflikt ist offensichtlich: Synthetische Daten lassen sich schnell skalieren, doch generierte Aufgaben können auch falsches Verhalten vermitteln.

Damit ist AutoSynthData mehr als ein weiteres System, das ein Modell dazu auffordert, Prompts zu erfinden. Es versucht, einen geschlossenen Trainingskreislauf rund um den Zielagenten, seine Betriebsumgebung und ein leistungsfähigeres Lehrermodell aufzubauen. Jede akzeptierte Aufgabe umfasst einen anfänglichen Systemzustand, eine Nutzeranfrage, eine erfolgreiche Trajektorie und einen Verifizierer, der den Endzustand bewertet.

ServiceNow zufolge verbesserte der Ansatz ein Gemma-Zielmodell in zwei EnterpriseOps-Gym-Domänen. Diese Fortschritte stammen jedoch aus kontrollierten Experimenten innerhalb derselben Benchmark-Familie, die auch den Lehrplan prägte. Das Ergebnis setzt Teams unter Druck, die auf statische, von Menschen verfasste Datensätze setzen, während externe Übertragbarkeit und Zuverlässigkeit im Produktionseinsatz ungeklärt bleiben.

AutoSynthData: Generating Training Data for Enterprise Agents beginnt mit Fehlern

Die entscheidende Veränderung besteht darin, dass ServiceNow Agentenfehler als Anleitung dafür behandelt, welche Trainingsdaten als Nächstes erzeugt werden sollen.

Herkömmliche Pipelines für synthetische Daten beginnen oft mit Themen, Vorlagen oder Ausgangsbeispielen. Sie erweitern diese Eingaben zu größeren Sammlungen, filtern die Ergebnisse und nutzen die verbleibenden Beispiele für das Training. Dieser Prozess kann Umfang schaffen, ohne zu belegen, dass die neuen Daten tatsächliche Schwächen eines Modells adressieren.

AutoSynthData kehrt diese Reihenfolge um. Zunächst bewertet es ein Zielmodell innerhalb einer operativen Umgebung und untersucht, wo das Modell scheitert. Ein leistungsfähigeres Lehrermodell bearbeitet dieselben Diagnoseaufgaben und ermöglicht so einen Vergleich zwischen erfolglosem und erfolgreichem Verhalten.

Das System analysiert die beteiligte Fähigkeit, die benötigten Tools, die Workflow-Struktur und den Endzustand, der als Erfolg gilt. Außerdem identifiziert es Details, die sich ändern können, ohne die zugrunde liegende Fähigkeit zu beseitigen. Aus diesen Beobachtungen entstehen sogenannte bereinigte Spezifikationskarten für Fähigkeiten.

Diese Karten steuern die Generierung, ohne die ursprünglichen Evaluierungsprompts, Entitäten, Trajektorien oder Details der Verifizierung offenzulegen. Diese Trennung soll direkte Benchmark-Lecks reduzieren. Sie zwingt den Generator zudem dazu, neue Situationen zu erstellen, statt Testfragen lediglich umzuformulieren.

Das Aufgabenformat besteht aus drei verknüpften Teilen. Eine Systemspezifikation definiert Richtlinien, verfügbare Aktionen und den anfänglichen Umgebungszustand. Ein Nutzer-Prompt beschreibt das gewünschte Ergebnis, während ein Verifizierer entscheidet, ob der Agent einen akzeptablen Endzustand erreicht hat.

Diese Struktur ist wichtig, weil Unternehmensarbeit selten mit einer Textantwort endet. Ein IT-Service-Agent muss möglicherweise einen Vorfall prüfen, eine Berechtigung kontrollieren, einen Datensatz aktualisieren und einen Prüfpfad erhalten. Eine sprachlich überzeugende Antwort belegt nicht, dass eine dieser Aktionen korrekt ausgeführt wurde.

Das AutoSynthData release beschreibt zwei Generierungsphasen. Die Zielphase erstellt und validiert Kernbeispiele, die sich um identifizierte Fähigkeitslücken drehen. Die Multiplikationsphase erzeugt neue Varianten aus akzeptierten Zielbeispielen.

Jede Variante erhält ihre eigene Anfrage, Entitäten, ihren anfänglichen Zustand, eine Referenztrajektorie und einen Verifizierer. Ein vervielfachtes Beispiel darf nicht zum Ausgangspunkt eines weiteren vervielfachten Beispiels werden. Diese Begrenzung soll verhindern, dass mehrere Generationen synthetischer Erweiterung vom validierten Kern abdriften.

Die Pipeline trennt die zentrale Steuerung der Generierung von der umgebungsspezifischen Ausführung. Ein Controller verwaltet Abdeckung, Qualitätsprüfungen und den Aufbau des Datensatzes. Ein Adapter führt Tools aus, verwaltet Zustände, spielt Referenzlösungen nach, bewertet Agenten und wendet deterministische Verifizierung an.

Diese Trennung eröffnet dem Ansatz einen Weg über eine einzelne Benchmark hinaus. Ein Unternehmen könnte theoretisch den gemeinsamen Controller beibehalten und zugleich einen Adapter für seine eigenen Systeme entwickeln. Jeder neue Adapter würde jedoch präzise Tools, realistische Zustandsübergänge und verlässliche Erfolgskriterien benötigen.

Die Nachricht ist daher nicht bloß, dass ServiceNow synthetische Aufgaben generiert hat. Das Unternehmen hat einen Prozess aufgebaut, der Aufgaben anhand der aktuellen Schwächen des Modells auswählt. Anschließend verschiebt er das Trainingsziel, wenn sich diese Schwächen verändern.

Dieser adaptive Kreislauf stellt die Entwicklung statischer Datensätze infrage. Eine feste Sammlung wird weniger wertvoll, sobald ein Modell den Großteil davon löst. AutoSynthData sucht stattdessen nahe der aktuellen Fähigkeitsgrenze des Modells, wo Beispiele weiterhin schwierig, aber noch erlernbar sind.

Die Idee verändert auch die Bedeutung eines Evaluierungsfehlers. Statt nur eine Kennzahl oder einen Fehlerbericht zu liefern, wird der Fehler zum Rohmaterial für das Post-Training. Dieselbe Umgebung kann Schwächen diagnostizieren, gezielte Übung erzeugen und das aktualisierte Modell testen.

Dieser Kreislauf ist die zentrale Behauptung hinter AutoSynthData: Generating Training Data for Enterprise Agents. ServiceNow hat noch nicht gezeigt, dass er in nicht verwandten Unternehmensumgebungen funktioniert. Dennoch hat das Unternehmen eine konkrete Alternative zur wahllosen Skalierung synthetischer Daten definiert.

Statische Agentendatensätze sehen sich nun einem beweglichen Ziel gegenüber

AutoSynthData setzt Teams unter Druck, die umfangreiche Trainingsdaten sammeln, ohne zu messen, ob jedes Beispiel eine fehlende Fähigkeit vermittelt.

Entwickler von Enterprise-Agenten stehen vor einem schwierigen Datenproblem. Produktionsdaten enthalten nützliche Workflow-Muster, können aber auch personenbezogene Informationen, vertrauliche Geschäftsdaten und inkonsistente Ergebnisse umfassen. Von Menschen verfasste Aufgaben umgehen einige Datenschutzprobleme, doch ausreichend vielfältige und überprüfbare Beispiele zu erstellen, ist teuer.

Synthetische Daten bieten Skalierung, doch Skalierung allein wählt nicht die richtige Lektion aus. Ein Modell, das Anfragen zum Zurücksetzen von Passwörtern bereits bewältigt, profitiert kaum von Tausenden ähnlicher Beispiele. Es benötigt Aufgaben, die ungelöste Probleme wie Richtlinienprüfungen, systemübergreifende Planung und sichere Ablehnungen offenlegen.

EnterpriseOps Gym stellt die kontrollierte Umgebung für die Experimente von ServiceNow bereit. Sein benchmark paper beschreibt zustandsbehaftete Aufgaben, bei denen ein Agent über Tools hinweg schlussfolgern und das zugrunde liegende System im korrekten Zustand hinterlassen muss. Das unterscheidet sich von Benchmarks, die nur eine abschließende Textantwort bewerten.

ServiceNow beschreibt EnterpriseOps Gym als Plattform für acht Geschäftsbereiche. Die zugehörige Umgebung umfasst 512 funktionale Tools und 164 miteinander verknüpfte Datenbanktabellen. Diese Ressourcen unterstützen Workflows in Bereichen wie IT-Service-Management, Kundenservice und Personalwesen.

Die umfassendere Benchmark enthält ServiceNow zufolge 1.150 Unternehmensaufgaben. Sie testen Planung, Richtlinienkonformität und Zustandsänderungen über vernetzte Systeme hinweg. Der released dataset verschafft externen Forschenden zudem Zugang zu den Benchmark-Materialien.

Diese Zahlen erklären, warum gezielte Generierung wichtig ist. Ein einzelner Workflow kann mehrere Tools, Datensätze, Richtlinien und Abhängigkeiten kombinieren. Kleine Änderungen des Anfangszustands können verändern, welche Abfolge gültig ist oder ob die angeforderte Aktion überhaupt erfolgen sollte.

ServiceNow berichtete zuvor, dass die Bereitstellung von Expertenplänen für Aufgaben die Leistung in schwierigen Unternehmensdomänen um 15 % bis 35 % erhöhte. Dieses Ergebnis deutet darauf hin, dass Planung weiterhin eine wesentliche Einschränkung darstellt, selbst wenn ein Agent einzelne Tools korrekt aufrufen kann. AutoSynthData versucht, solche Planungslücken in wiederholte Trainingsgelegenheiten umzuwandeln.

Der Druck trifft zunächst statische Evaluierungsteams. Ein fester Testsatz kann eine Schwäche identifizieren, erzeugt jedoch nicht automatisch einen Lehrplan, der sie behebt. Forschende müssen Fehler weiterhin in vielfältige Beispiele, gültige Lösungen und verlässliche Bewertungslogik überführen.

Der zweite Druck trifft Anbieter universeller Modelle. Starke Durchschnittswerte in Benchmarks können Fehler verschleiern, die durch lokale Richtlinien, Tabellenstrukturen oder Workflow-Regeln verursacht werden. Unternehmen benötigen Belege dafür, dass ein Modell in ihren konkreten Systemen arbeiten kann, nicht nur Fragen dazu beantwortet.

Der dritte Druck trifft Unternehmen, die Agentenplattformen entwickeln. Wenn sich adaptives Training als nützlich erweist, wird Evaluierungsinfrastruktur zu einem Teil der Modellentwicklung statt zu einer abschließenden Qualitätsschranke. Plattformen werden reproduzierbare Umgebungen, Aufgabengenerierung, Ausführungsprotokolle und zustandsbasierte Verifizierung benötigen.

Diese Anforderung begünstigt Organisationen mit operativen Simulatoren oder digitalen Zwillingen. Salesforce verfolgt mit CRMArena-Pro eine verwandte Richtung, die simulierte Unternehmensumgebungen nutzt, um Agenten bei Geschäftsworkflows zu bewerten. Die Überschneidung signalisiert eine breitere Bewegung hin zu ausführbaren, umgebungsbasierten Agententests.

Die Ansätze sind nicht identisch. Eine Benchmark kann Modelle vergleichen, ohne sie zu verändern, während AutoSynthData Benchmark-Fehler zur Erzeugung von Post-Training-Daten verwendet. Der eine Ansatz misst Fähigkeiten, der andere versucht, sie zu erweitern.

Dieser Unterschied ist für Unternehmenskäufer wichtig. Eine Rangliste identifiziert unter den angegebenen Bedingungen das stärkste Modell. Ein adaptiver Lehrplan fragt, ob sich ein günstigeres oder kleineres Zielmodell bei den eigenen wiederkehrenden Aufgaben der Organisation verbessern kann.

Die von ServiceNow berichteten Ergebnisse machen diese Möglichkeit greifbar, aber nicht abschließend geklärt. Das Zielmodell löste nach dem Training weiterhin nur eine Minderheit der IT-Service-Aufgaben. Besser als die Ausgangsbasis bedeutet nicht, dass es für unbeaufsichtigten Produktionszugriff bereit ist.

Auch die Qualität des Wissens bleibt eine praktische Einschränkung. Ein Agent kann einer Richtlinie nicht folgen, wenn diese fehlt, widersprüchlich oder nicht zugänglich ist. Teams, die eine durchsuchbare Wissensdatenbank aufbauen, benötigen weiterhin klares Quellmaterial, bevor generierte Trainingsaufgaben reale Arbeit abbilden können.

AutoSynthData verlagert den Engpass daher, statt ihn zu beseitigen. Teams benötigen weniger manuell verfasste Varianten, aber eine vertrauenswürdige Umgebung und präzise Verifizierung. Dieser Tausch wird entscheidend, wenn ein Agent Kunden-, Mitarbeiter- oder Infrastrukturdaten verändern kann.

Der Mechanismus hängt von ausführbaren Aufgaben und strikten Verifizierern ab

AutoSynthData funktioniert nur, wenn generierte Anfragen, Referenzlösungen und Verifizierer darin übereinstimmen, was Erfolg bedeutet.

Die Pipeline beginnt damit, Aufgaben zu identifizieren, die das Zielmodell von einem leistungsfähigeren Lehrermodell unterscheiden. In der berichteten Konfiguration bevorzugt ServiceNow Kandidaten, die das Zielmodell in drei Versuchen höchstens einmal löst. Der stärkere Solver muss sie in drei Versuchen mindestens zweimal abschließen.

Dieser Filter zielt auf einen sinnvollen Schwierigkeitsbereich ab. Aufgaben, an denen beide Modelle scheitern, bieten keine verlässliche Demonstration. Aufgaben, die beide konsistent lösen, verbrauchen Trainingskapazität, ohne auf eine eindeutige Schwäche abzuzielen.

Sobald ein Kandidat in die Pipeline gelangt, führt AutoSynthData seine Referenztrajektorie aus. Eine Trajektorie ist die Abfolge von Tool-Aufrufen und Aktionen, mit der der angeforderte Zustand erreicht wird. Der Verifizierer prüft anschließend das Ergebnis anhand der Erfolgskriterien der Aufgabe.

Diese positive Prüfung fragt, ob die beabsichtigte Lösung tatsächlich funktioniert. Sie kann einen ungültigen Anfangszustand, ein nicht verfügbares Tool, eine fehlerhafte Aktionsfolge oder einen Widerspruch zwischen Anfrage und Verifizierer aufdecken. Ein plausibel wirkendes Beispiel scheitert, wenn es der Ausführung nicht standhält.

Die Pipeline führt außerdem eine Negativverifikation durch. Sie verändert erwartete Ergebnisse und bestätigt, dass fehlerhafte Zustände nicht bestehen. Dieser Schritt ist wichtig, weil ein schwacher Verifizierer einen Agenten belohnen kann, der erforderliche Aktionen überspringt oder eine wichtige Einschränkung verletzt.

Betrachten wir eine Anfrage, einen IT-Vorfall erst zu schließen, nachdem die Lösung mit dem betroffenen Mitarbeiter bestätigt wurde. Ein Verifizierer, der nur den Status des Vorfalls prüft, würde eine unsichere Abkürzung akzeptieren. Ein stärkerer Verifizierer würde zusätzlich den Bestätigungsnachweis und alle vorgeschriebenen Notizen verlangen.

Dasselbe Problem tritt auf, wenn mehrere Lösungen gültig sind. Ein Verifizierer sollte akzeptable Ergebnisse erkennen, ohne eine exakt vorgegebene Referenzabfolge zu verlangen. ServiceNow beschreibt dies als Vollständigkeit, neben der Übereinstimmung mit der Anfrage und der zuverlässigen Zurückweisung fehlerhaften Verhaltens.

Diese Anforderungen schaffen ein schwieriges Gleichgewicht. Ein zu großzügiger Verifizierer belohnt unvollständige Arbeit. Ein zu enger Verifizierer bestraft legitime Strategien und trainiert das Modell darauf, eine willkürliche Abfolge nachzuahmen.

Fehlgeschlagene Kandidaten gelangen in eine begrenzte Schleife aus Kritik und Reparatur. Ein Kritiker untersucht die Aufgabenkonstruktion, den Ausgangszustand, die Lösung und die Verifizierungslogik. Das System wendet gezielte Korrekturen an, führt die relevanten Prüfungen erneut aus und akzeptiert oder verwirft den überarbeiteten Kandidaten.

Die Reparatur eines vorhandenen Kandidaten kann nützliche Arbeit bewahren. Sie verhindert außerdem, dass die Generierung neu gestartet werden muss, sobald eine Komponente einen behebbaren Fehler enthält. Das Wiederholungslimit verhindert, dass das System unbegrenzt Ressourcen für eine aufgabenschwache Aufgabenfamilie aufwendet.

AutoSynthData überprüft anschließend die Qualität über den gesamten Batch hinweg. Einzelne gültige Beispiele können dennoch einen repetitiven Datensatz bilden. Ein Generator könnte vertraute Workflows überproduzieren und schwierige Kombinationen aus Richtlinien, Tools oder Systemzuständen ignorieren.

Der Controller verfolgt akzeptierte und verworfene Samples, wiederkehrende Muster, Fähigkeitsabdeckung und wiederholte Kritikbefunde. Er reduziert die Generierung in überrepräsentierten Bereichen und lenkt Aufwand auf Lücken um. Dadurch entsteht Feedback oberhalb der Ebene einzelner Aufgaben.

Die Phasen „Target“ und „Multiply“ unterstützen diese Strategie. Target-Samples etablieren validierte Aufgabenfamilien rund um bestimmte Fähigkeitslücken. Multiply-Samples variieren Formulierungen, Entitäten, Tool-Kombinationen und Umgebungszustände, ohne frühere Varianten rekursiv zu erweitern.

Dieses Design reduziert ein häufiges Risiko synthetischer Daten. Rekursive Generierung kann kleine Fehler vergrößern, da jedes neue Sample Annahmen aus einem anderen generierten Sample übernimmt. Die Verankerung aller Varianten in geprüften Target-Beispielen begrenzt diese Kette.

Der Ansatz verschafft Unternehmen zudem einen besser vertretbaren Prüfpfad. Jedes Trainingsbeispiel kann seinem Ausgangszustand, der vorgesehenen Aktionsfolge, dem Verifizierer und dem Validierungsergebnis zugeordnet werden. Das ist nützlicher als ein Ordner mit Prompts ohne ausführbaren Kontext.

Deterministische Prüfungen können jedoch nicht jede bedeutsame Qualitätsdimension abbilden. Ein finaler Datenbankzustand kann korrekt aussehen, selbst wenn ein Agent unterwegs sensible Informationen offengelegt hat. Eine andere Ausführung kann unnötige Änderungen erzeugen, bevor sie den erwarteten Zustand wiederherstellt.

Ausführungsprotokolle und richtlinienbewusste Prüfungen bleiben notwendig. ServiceNows eigenes Tooling zur Agentenbewertung betont Datensätze, Ausführungsprotokolle und mehrere Qualitätsdimensionen. AutoSynthData erweitert diese Philosophie auf die Produktion von Trainingsdaten.

Der Mechanismus hängt außerdem vom Teacher ab. Ein stärkeres Modell kann erfolgreiches Verhalten demonstrieren, doch seine Aktionen spiegeln weiterhin die verfügbaren Tools und codierten Richtlinien wider. Ein Teacher, der eine riskante Abkürzung wählt, kann dieses Verhalten in das überwachte Fine-Tuning weitertragen.

Dadurch entsteht eine Governance-Frage. Unternehmen müssen wissen, wer gültiges Verhalten definiert, welche Richtlinien die Umgebung umsetzt und wie Änderungen an Verifizierern überprüft werden. Andernfalls kann automatisierte Generierung einen unbemerkten Spezifikationsfehler skalieren.

AutoSynthData: Generating Training Data for Enterprise Agents ist am stärksten als Argument für ausführbare Daten. Der Generator erhält Aufmerksamkeit, doch die Umgebung und der Verifizierer tragen einen großen Teil der Glaubwürdigkeit des Systems. Ohne sie bleiben synthetische Aufgaben überzeugende Geschichten statt nachgewiesener Trainingsbeispiele.

Die berichteten Zugewinne sind bedeutsam, aber weiterhin begrenzt

ServiceNow berichtet von deutlichen Benchmark-Verbesserungen, doch die Experimente belegen weder Produktionszuverlässigkeit noch breite Übertragbarkeit.

Das erste Experiment verwendete Gemma-4-26B-A4B-it als Zielmodell in der Hybrid-Domäne von EnterpriseOps Gym. Qwen3.8-27B fungierte als Teacher. AutoSynthData generierte in rund 18 Stunden 2.000 synthetische Trainingsbeispiele.

ServiceNow führte bei Gemma überwachtes Fine-Tuning durch, das ein Modell darauf trainiert, erfolgreiche Beispiele nachzuahmen. Der beste berichtete Checkpoint stammte aus der fünften Epoche. Eine Epoche entspricht einem vollständigen Durchlauf durch den Trainingsdatensatz.

Laut dem Unternehmen verbesserte sich der mittlere Pass@1-Wert um 7,2 Prozentpunkte. ServiceNow beschreibt diese Veränderung als relative Verbesserung von 35 %. Auch der Erfolg des Verifizierers stieg von 63,01 % auf 68,55 %.

Nach Angaben des Unternehmens schloss der resultierende Checkpoint 59 % der ursprünglichen Pass@1-Lücke zwischen Gemma und seinem Referenzmodell. Diese Ergebnisse deuten darauf hin, dass gezielte synthetische Beispiele mehr als eine Messgröße beeinflussten. Sie zeigen nicht, wie sich das Modell außerhalb der getesteten Umgebung verhielt.

Das zweite Experiment konzentrierte sich auf IT-Service-Management. Es verwendete erneut Gemma-4-26B-A4B-it als Zielmodell, während DeepSeek-V4.1-Flash als Teacher fungierte. Die Pipeline erzeugte über 66 Stunden 1.994 akzeptierte Samples.

Der mittlere Pass@1-Wert stieg bei der ITSM-Evaluierung von 18,77 % auf 27,18 %. Das entspricht einem Zuwachs von 8,41 Prozentpunkten. Zugleich scheitert das trainierte Modell nach der Bewertungsmethode des Benchmarks bei den meisten ersten Versuchen.

Diese verbleibende Lücke ist wesentlicher Kontext. Das Experiment stützt die Behauptung, dass gezieltes synthetisches Fine-Tuning ein Modell verbessern kann. Es stützt nicht die Behauptung, dass der resultierende Agent bereit ist, eigenständig in Geschäftssystemen zu arbeiten.

ServiceNow zufolge erhielt der Hybrid-Generator niemals die ursprünglichen Evaluierungs-Prompts, Entitäten, Trajektorien oder Verifiziererdetails. Er erhielt Fähigkeitsspezifikationen, die aus dem Evaluierungsverhalten abgeleitet wurden. Diese Trennung reduziert eine offensichtliche Form der Kontamination des Testsatzes.

Der Lehrplan entstand jedoch weiterhin aus Fehlern, die innerhalb von EnterpriseOps Gym beobachtet wurden. Training und Evaluierung teilten daher eine Umgebung, eine Tool-Struktur und eine allgemeine Aufgabenverteilung. Verbesserungen innerhalb dieser Umgebung belegen keine Übertragbarkeit auf nicht verwandte Software oder private Unternehmenskonfigurationen.

Die berichteten Zahlen stammen außerdem von dem Team, das das System entwickelt hat. Eine unabhängige Replikation würde das Ergebnis stärken. Forschende bräuchten ausreichend Code, Generierungseinstellungen, akzeptierte Samples und Evaluierungsdetails, um die Pipeline reproduzieren zu können.

Artificial Analysis betreibt inzwischen eine unabhängige Rangliste, die auf EnterpriseOps Gym basiert. Auch deren Evaluierung betont zustandsbehaftete, mehrstufige Arbeit und finale Datenbankzustände. Dieses externe Testsystem bietet eine mögliche Möglichkeit, trainierte Checkpoints unabhängiger zu testen.

Eine umgebungsübergreifende Evaluierung wäre noch aussagekräftiger. Ein Modell, das auf einer ITSM-Konfiguration trainiert wurde, könnte gegen geänderte Richtlinien, umbenannte Tools, veränderte Schemata und unbekannte Datensatzverteilungen getestet werden. Die Leistung unter solchen Veränderungen würde zeigen, ob das Modell eine Fähigkeit gelernt oder ein Umgebungsmuster auswendig gelernt hat.

Auch Sicherheit benötigt eine separate Messung. ServiceNow beschrieb zuvor 30 nicht umsetzbare Benchmark-Aufgaben mit nicht verfügbaren Ressourcen, fehlenden Berechtigungen oder Richtlinienverstößen. Sein stärkstes getestetes Modell erkannte Berichten zufolge nur etwa die Hälfte davon als nicht umsetzbar.

AutoSynthData könnte auf solche Fehler abzielen, doch die aktuelle Veröffentlichung präsentiert kein spezielles Ergebnis zum sicheren Unterlassen von Handlungen. Eine verbesserte Aufgabenbewältigung kann neue Risiken schaffen, wenn das Modell zugleich eher bereit wird zu handeln, obwohl eine Verweigerung korrekt wäre.

Die Beziehung zwischen Teacher und Zielmodell verdient eine genaue Prüfung. Das Hybrid-Experiment nutzte eine relativ ähnliche Modellgröße, während der ITSM-Lauf einen deutlich größeren Teacher einsetzte. Die Generierungsdauer unterschied sich erheblich, teilweise weil ServiceNow angibt, dass der frühere ITSM-Lauf vor Durchsatzoptimierungen stattfand.

Diese Unterschiede erschweren direkte Vergleiche. Die beiden Domänen umfassten unterschiedliche Teacher, Verarbeitungszeiten und wahrscheinlich unterschiedliche Fähigkeitsverteilungen. Die Evidenz zeigt Wiederholbarkeit in zwei Konfigurationen, keine kontrollierte Studie jeder Systemkomponente.

Das Fehlen einer Ablationsstudie begrenzt ebenfalls die Interpretation. Öffentliche Ergebnisse isolieren nicht, wie viel der Verbesserung aus Fehlerfokussierung, Teacher-Demonstrationen, Verifiziererfilterung, Aufgabenvervielfachung oder Batch-übergreifender Ausbalancierung stammt. Jede Komponente klingt plausibel, doch ihre jeweiligen Beiträge bleiben unklar.

Kosten und Ressourcenverbrauch sind ein weiteres offenes Thema, auch ohne kommerzielle Zahlen anzuführen. Die Generierung Tausender Aufgaben erfordert wiederholte Modellaufrufe, Umgebungsausführung, Solver-Versuche, Kritik, Reparatur und Verifizierung. Der akzeptierte Datensatz repräsentiert nur das Ergebnis, nicht die gesamte versuchte Arbeitslast.

Unternehmen müssen diese Arbeitslast mit Alternativen vergleichen. Von Menschen erstellte Beispiele sind möglicherweise langsamer, aber leichter zu prüfen. Änderungen an Retrieval und Orchestrierung könnten einige Fehler beheben, ohne Modellgewichte zu aktualisieren.

Ein Workflow kann auch scheitern, weil sein Wissen unvollständig ist, und nicht, weil dem Modell Schlussfolgerungsfähigkeit fehlt. Besseres Knowledge Blending kann manche Lücken direkter schließen. Training sollte nicht zur Standardreaktion auf jeden erfolglosen Agentenlauf werden.

Die vorsichtige Lesart bleibt dennoch ermutigend. AutoSynthData erzielte messbare Verbesserungen mit Aufgaben, die anhand beobachteter Schwächen ausgewählt wurden. Die stärkere Behauptung, dass adaptive synthetische Lehrpläne zu sichereren Produktionsagenten generalisieren, bleibt unbewiesen.

Drei Signale werden entscheiden, ob AutoSynthData über den Benchmark hinaus Bedeutung erlangt

Die nächsten Belege sollten Reproduzierbarkeit, Übertragbarkeit und sichereres Verhalten zeigen – nicht nur einen weiteren höheren Wert innerhalb der ursprünglichen Umgebung.

Das erste Signal ist eine unabhängig reproduzierbare Veröffentlichung. ServiceNow hat Materialien zu EnterpriseOps Gym veröffentlicht, doch Forschende benötigen die AutoSynthData-Implementierung und das vollständige experimentelle Rezept. Dieses Paket sollte die Erstellung von Fähigkeitskarten, Generierungseinstellungen, Verifizierertests, Ablehnungskriterien und die Checkpoint-Evaluierung enthalten.

Unabhängige Teams sollten in der Lage sein, aus denselben diagnostischen Fehlern vergleichbare Datensätze neu zu erzeugen. Ähnliche Verbesserungen über mehrere Durchläufe hinweg würden Bedenken über vorteilhafte Stichproben reduzieren. Die Veröffentlichung von Statistiken zu verworfenen Aufgaben würde außerdem zeigen, wie viel Filterung der endgültige Datensatz erforderte.

Die stärkste Version dieses Signals würde Ablationen enthalten. Forschende könnten Negativverifikation, Batch-Ausbalancierung, Vervielfachung oder Fehlerfokussierung jeweils einzeln entfernen. Die daraus resultierenden Leistungsunterschiede würden erkennen lassen, welche Mechanismen die Verbesserung erzeugen.

Wenn eine unabhängige Replikation gelingt, würde sie ServiceNows zentrale technische Behauptung stärken. Wenn die Zugewinne zwischen Durchläufen stark schwanken, würde das Ergebnis darauf hindeuten, dass die Pipeline weiterhin empfindlich gegenüber Generatoren, Teachern oder Auswahlentscheidungen ist.

Das zweite Signal ist die Übertragbarkeit über Umgebungen hinweg. Ein trainiertes Modell sollte mit Workflows konfrontiert werden, die die zugrunde liegende Fähigkeit bewahren, während sie Tools, Entitäten, Richtlinien und Schemata verändern. Dieser Test würde allgemeines Lernen von Vertrautheit mit der Struktur von EnterpriseOps Gym unterscheiden.

Ein nützliches Experiment könnte auf einer ITSM-Umgebung trainieren und ohne zusätzliches Fine-Tuning auf einer anderen evaluieren. Ein weiteres könnte von einem Workflow in einer einzelnen Domäne zu einer domänenübergreifenden Aufgabe wechseln, die Kunden-, Mitarbeiter- und Asset-Daten erfordert.

Unternehmen sollten auch auf Adapter jenseits von ServiceNow-orientierten Systemen achten. Die Controller-Adapter-Architektur von AutoSynthData deutet auf Portabilität hin, doch Softwaredesign garantiert keine praktische Kompatibilität. Jede neue Umgebung benötigt ausführbare Aktionen und verlässliche Verifikation.

Erfolgreiche plattformübergreifende Ergebnisse würden die Methode für einen deutlich größeren Agentenmarkt relevant machen. Schwache Übertragbarkeit würde ihre Rolle auf eine effiziente Anpassungspipeline für eng spezifizierte Umgebungen beschränken.

Das dritte Signal ist, ob sich die Aufgabenerfüllung verbessert, ohne Ablehnungen und die Einhaltung von Richtlinien zu schwächen. Ein Unternehmensagent muss wissen, wann er nicht handeln darf. Höhere Pass@1-Werte reichen nicht aus, wenn das Training eine selbstsichere Ausführung bei fehlenden Berechtigungen oder widersprüchlichen Anweisungen fördert.

Künftige Evaluierungen sollten die Erkennung nicht durchführbarer Aufgaben, unautorisierte Zustandsänderungen, Richtlinienverstöße und unnötige Tool-Aufrufe ausweisen. Sie sollten zudem Zwischenaktionen prüfen, nicht nur die finalen Datenbankzustände. Ein wiederhergestellter Endzustand kann eine unsichere Abfolge verdecken.

Für Workflows mit hoher Auswirkung bleibt menschliche Überprüfung wichtig. Prüfer sollten Stichproben zu Mitarbeiterdaten, Zugriffskontrollen, Kundenberechtigungen, Sicherheitsvorfällen und unumkehrbaren Änderungen untersuchen. Automatisierte Verifizierer können diesen Prozess unterstützen, sollten jedoch ohne verantwortliche Aufsicht keine Richtlinien festlegen.

Die kommenden ein bis drei Monate sollten daher drei konkrete Formen von Evidenz liefern: ausführbaren Pipeline-Code, umgebungsübergreifende Tests und sicherheitsspezifische Ergebnisse. Jede davon würde eine andere Unsicherheit der aktuellen Veröffentlichung adressieren.

AutoSynthData: Generating Training Data for Enterprise Agents stellt einen glaubwürdigen Mechanismus vor, um Evaluierungsfehler in gezielte Übung zu überführen. Die berichteten Fortschritte zeigen, dass die Idee Aufmerksamkeit verdient, insbesondere für Teams mit ausführbaren Workflow-Umgebungen.

Die größere Entscheidung liegt nun bei den Entwicklern von Unternehmens-KI. Sie sollten fragen, ob die Fehler ihrer eigenen Agenten als reproduzierbare Zustände, gültige Trajektorien und testbare Ergebnisse ausgedrückt werden können. Andernfalls würde das Generieren weiterer Aufgaben lediglich Mehrdeutigkeit skalieren.

Wenn diese Grundlagen vorhanden sind, kann ein adaptives Curriculum Evaluierungen deutlich nützlicher machen. Es kann zeigen, was fehlgeschlagen ist, fokussiertes Training erzeugen und messen, ob dieselbe Schwäche bestehen bleibt. Der nächste Beweis muss zeigen, dass diese Schleife außerhalb der Umgebung, die sie hervorgebracht hat, Bestand hat.