ServiceNows AutoSynthData wandelt Agentenfehler in wertvolle Schulungsergebnisse um

Kurz gesagt: ServiceNow CoreAI AutoSynthData wandelt Agentenfehler und Lehrererfolge in validierte synthetische SFT-Aufgaben um, wenn Unternehmen Umgebungskompetenz und nicht nur allgemeine Benchmark-Werte benötigen. Es bereinigt Lücken in Fähigkeitsspezifikationskarten, vervielfacht die verifizierbare Arbeit und prüft die Qualität vor der Feinabstimmung. Die vom Autor berichteten EnterpriseOps Gym-Übungen bleiben bestehen, wenn die Lehrerstärke, die Verifizierungsqualität und die Umgebungstreue übereinstimmen.

Wichtigste Erkenntnisse:

Fähigkeitskarten: Fehler werden in Karten anonymisiert, sodass Generatoren niemals die ursprünglichen IDs sehen.

Prüfbarkeit des Verifizierers: Bevorzugen Sie SQL-Endzustandsprüfungen, die veränderte, falsche Ergebnisse ablehnen.

Schwierigkeitsgrad: Üben Sie nur Aufgaben, die der Zielschüler selten löst und die der Lehrer normalerweise bewältigt.

Menschliche Überprüfung: Bei wichtigen politischen Entscheidungen und irreversiblen Maßnahmen sollte vor einer Umschulung eine menschliche Überprüfung erfolgen.

Verschiebung der Zielfront: Nach der SFT die Zielphase neu bewerten und auf die verbleibenden Lücken ausrichten.

KI-Systeme in Unternehmen scheitern selten an mangelndem Allgemeinwissen. Vielmehr scheitern sie an den spezifischen Gegebenheiten der Umgebung: Ticketrichtlinien, Schema-Besonderheiten, Tool-Verträge, vordefinierte Datenbanken, Wissensartikel und systemübergreifende Workflows entsprechen nicht den Lehrbuchbeispielen. Selbst ein Modell, das in offenen Benchmarks gut abschneidet, kann ins Stocken geraten, wenn der nächste Schritt ein Änderungsfenster, eine CMDB-Beziehung oder einen Prüfer berücksichtigen muss, der den Endzustand statt eines flüssigen Chats überprüft.

ServiceNow CoreAI / ServiceNow-AI hat AutoSynthData veröffentlicht , um diese Lücke direkt zu schließen. Der Autor Esakkivel Esakkiraja beschreibt eine Pipeline, die die Fehler eines Zielagenten – zusammen mit den Erfolgen eines leistungsfähigeren Trainingsagenten – in validierte synthetische Trainingsaufgaben umwandelt, die auf Unternehmensumgebungen zugeschnitten sind. Es geht nicht darum, mehr Chatprotokolle zu sammeln, sondern darum, umfangreiche, verifizierbare Übungen durchzuführen, die dieselbe Fähigkeit unter neuen Bedingungen testen, sodass überwachtes Feintuning umgebungsspezifische Schwachstellen beheben kann.

Dieser Artikel erläutert die Kernidee, die Aufgabenabstraktion, den Generierungs- und Qualitätskontrollzyklus, die gemeinsame Architektur sowie die vom Autor vorgestellten Ergebnisse zum EnterpriseOps Gym in Hybrid- und ITSM-Umgebungen. Er orientiert sich an den Forschungsergebnissen: einem dynamischen Curriculum synthetischer Aufgaben, nicht an der Behauptung, dass sich damit jedes Unternehmensproblem plötzlich lösen lässt.

Warum Umweltkompetenz breiter Kompetenz überlegen ist

Unternehmen benötigen Agenten, die in ihrer Umgebung – ihren Systemen, Regeln und Datenzuständen – arbeiten können. Umfassende Fähigkeiten sind nicht gleichzusetzen mit Umgebungskompetenz. Ein Agent kann zwar die üblichen Abläufe im IT-Servicemanagement kennen, aber dennoch die lokale Richtlinie übersehen, die bestimmte Übergänge verbietet, oder das Tool, das eine zugehörige Tabelle erst aktualisiert, wenn ein erforderlicher Datensatz vorhanden ist.

Einzelne Fehler sind zwar aufschlussreich, aber als Trainingsdaten unzureichend. Ein einzelner Fehlschlag offenbart eine Schwäche; er liefert nicht die vielen ähnlichen Situationen, die das Modell lehren würden, sich an Variationen anzupassen. Teams benötigen daher viele neue Aufgaben, die dieselbe Fähigkeit auf unterschiedliche Weise testen, innerhalb der Umgebung lösbar bleiben, sich für die Nutzer realistisch anfühlen und deren Ergebnisse überprüfbar sind.

Das ist der Designdruck hinter AutoSynthData. Fehler werden zu Signalen für Fähigkeitskarten. Karten generieren neue Aufgaben. Ein besserer Lehrer demonstriert erfolgreiche Abläufe. Filter und Verifizierer entscheiden, was in den überwachten Feinabstimmungssatz aufgenommen wird. Nach dem Training verschiebt die Evaluierung die Grenze hin zu den verbleibenden Lücken. Der Kreislauf ist lehrplanorientiert und keine einmalige Datenübermittlung.

Die richtige Formulierung ist für Anwender entscheidend. Werden nur fehlerhafte Eingabeaufforderungen gespeichert, besteht die Gefahr, dass man sich zu sehr auf diese Entitäten und Formulierungen konzentriert. Werden hingegen nur unbeschränkte synthetische Aufgaben generiert, riskiert man unmögliche, unrealistische oder nicht überprüfbare Aufgaben. AutoSynthData bietet einen Mittelweg: Fehlerhafte Eingaben werden zu einer Fähigkeitsspezifikation verarbeitet, und anschließend werden Aufgaben neu generiert, die den Kern beibehalten, aber die Oberflächenform und die kontrollierbaren Dimensionen anpassen.

Die praktische Aufgabenstellung: System, Aufforderung, Prüfer

Eine praktikable Abstraktion für agentenbasierte Arbeit lautet: Aufgabe = Systemspezifikation, Benutzeraufforderung und Verifizierer. Jedes Element beinhaltet Einschränkungen, die die synthetischen Daten fundiert und vertrauenswürdig halten.

Die Systemspezifikation umfasst Einschränkungen, Richtlinien und den Ausgangszustand – beispielsweise Datenbank-Seeds und Wissensartikel. Sie muss mit verfügbaren Werkzeugen und Zuständen kompatibel bleiben. Willkürliche Schwierigkeitseinschränkungen, die Werkzeugverträge oder die Realitätsnähe der Seeds ignorieren, führen häufig zu fehleranfälligen Aufgaben, die die falschen Lehren vermitteln.

Die Qualität von Nutzeraufforderungen wird anhand dreier Kriterien beurteilt. Machbarkeit: Gibt es einen plausiblen Lösungsweg? Realismus: Würde ein Nutzer diese Aufforderung plausibel anfordern? Schwierigkeit: Deckt die Aufgabe eine aktuelle Schwäche des Anwenders auf oder löst sie etwas, das der Anwender bereits zuverlässig bewältigt? Eine für den Anwender triviale Aufforderung verschwendet Trainingsbudget; eine unlösbare Aufforderung untergräbt das Vertrauen in die Bewertung.

Die Qualität der Verifizierung hängt von Konsistenz, Korrektheit und Vollständigkeit ab. Zu lasche und schwache Verifizierungspfade werden akzeptiert. Zu restriktive Verifizierung, die sich auf einen einzigen Verifizierungspfad beschränkt, führt zum Scheitern. In Unternehmensumgebungen werden häufig SQL-basierte oder zustandsbasierte Ergebnisprüfungen bevorzugt, da diese die Situation nach der Aktion des Agenten bewerten und nicht den exakten Tokenpfad, den der Agent zurückgelegt hat.

AutoSynthData stützt sich auf dieses Dreigestirn, um sicherzustellen, dass die generierten Aufgaben fundiert bleiben. Generatoren erstellen keine frei schwebenden Aufgaben. Sie erzeugen Aufgaben, die im Umgebungsadapter ausgeführt und von Verifizierern bewertet werden können, die auf die erforderlichen Eigenschaften des Endzustands achten.

Von der Diagnosebewertung bis zu den Leistungsspezifikationskarten

Der Prozess beginnt mit der Diagnose des Zielagenten und eines stärkeren Lehrers innerhalb der Umgebung. Parallele Testläufe zeigen, wo der Zielagent versagt und wo der Lehrer erfolgreich ist. Diese Vergleichsfälle bilden das Rohmaterial für die Lehrplanentwicklung.

Im nächsten Schritt werden die Daten in bereinigte Fähigkeitsspezifikationskarten. Eine Karte erfasst die zu testende Fähigkeit, relevante Werkzeuge oder den Workflow, die Schwachstellen des Zielsystems und die Erfolgsfaktoren des Testsystems, die erforderlichen Eigenschaften des Endzustands sowie Dimensionen, die sich bei der Entwicklung neuer Aufgaben ändern können. Entscheidend ist, dass der Generator keine ursprünglichen Eingabeaufforderungen, Entitäten, Abläufe oder Prüfdetails erhält – nur die Karten.

Diese Bereinigung ist eine bewusste Maßnahme gegen Überanpassung. Würde der Generator die exakten Fehlernummern, Wissensartikel-IDs oder Lehrerspuren sehen, wäre er versucht, dieselbe Episode zu paraphrasieren. Karten erzwingen Abstraktion: Vermitteln Sie die Fähigkeit unter kontrollierbarer Variation, nicht die auswendig gelernte Instanz.

Nachdem die Aufgabenkarten erstellt wurden, generiert das System daraus neue Aufgaben. Die Lehrkraft demonstriert anschließend erfolgreiche Lösungswege zur angeleiteten Feinabstimmung. Diese Demonstrationen sind keine bloßen Ratschläge, sondern praxisnahe Erfolge, die denselben Überprüfungskriterien entsprechen, die auch im Lehrplan Anwendung finden.

Die Skalierung erfolgt in zwei Phasen. Die Zielphase konzentriert sich auf geprüfte Kernbeispiele in Bereichen mit Lücken – die Aufgaben mit dem stärksten Signal in der Nähe der Stellen, an denen der schwache Agent versagt. Die Multiplikationsphase erzeugt neue Varianten akzeptierter Ziele. Multiplizierte Beispiele können keine weiteren Multiplikationsrunden auslösen, was die Abweichung begrenzt. Diese Regel ist klein, aber wichtig: Unbegrenzte rekursive Variationen können von der im Code angegebenen Fähigkeit abweichen.

Gemeinsamer Controller, Umgebungsadapter und die sich bewegende Grenze

Architektonisch verwendet AutoSynthData einen gemeinsamen Controller und einen Umgebungsadapter. Der Controller steuert Diagnose, Kartenerstellung, Generierung, Lehrerdemos, Qualitätsprüfungen und Stapelverarbeitung. Der Adapter verbindet diese Schritte mit einer konkreten Unternehmensumgebung – Tools, Status, Richtlinien und Verifizierer –, sodass derselbe Regelkreis verschiedene Anwendungsbereiche abdecken kann, ohne die Lehrplanlogik von Grund auf neu schreiben zu müssen.

Nach der überwachten Feinabstimmung wird die Pipeline erneut evaluiert. Der Lehrplan zielt dann auf die verbleibenden Lücken ab: eine dynamische Grenze anstelle eines statischen Datensatzes. Die in der Arbeit beschriebenen Experimente konzentrieren sich auf die überwachte Feinabstimmung. Derselbe Kreislauf könnte später auch Reinforcement Learning unterstützen; diese Richtung ist als geplant vermerkt, aber noch nicht als abgeschlossen.

Für Enterprise-Teams ist die Architekturlehre modular aufgebaut. Controller sollten kein festes Ticket-Schema vorgeben. Adapter sollten ausreichend Statusinformationen und Tool-Genauigkeit bereitstellen, damit Verifizierer aussagekräftige Ergebnisse liefern. Der Lehrplan sollte Evaluierungsergebnisse als nächsten Input behandeln, nicht als einmalige Bewertung.

EnterpriseOps Gym ist die Umgebung, in der dieser Ansatz veranschaulicht wurde. Es handelt sich um eine umfangreiche Agenten-Testumgebung für Unternehmen mit rund 1.150 von Experten kuratierten Aufgaben in acht Domänen, etwa 512 Tools, ca. 164 Datenbanktabellen, containerisierter Ausführung, SQL-basierter Ergebnisverifizierung, richtliniengesteuerten Operationen, hybriden domänenübergreifenden Szenarien, Tests auf Unmöglichkeit und Ablehnung sowie langfristigen zustandsbehafteten Trajektorien. AutoSynthData erhebt nicht den Anspruch, diese Testumgebung erfunden zu haben; sie dient vielmehr als Stresstest für den Syntheseprozess.

Qualitätskontrolle auf Probenebene, die die Vertrauenswürdigkeit synthetischer Aufgaben gewährleistet

Die Generierung ohne Kontrollmechanismen ist der Grund, warum synthetische Agentendaten fehlerhaft sind. AutoSynthData beschreibt die Qualitätskontrolle auf Probenebene mit mehreren sich ergänzenden Prüfungen.

Ein Schwierigkeitsfilter lenkt die Aufgabenauswahl auf Aufgaben, die für die Zielperson schwierig, für die Lehrperson aber lösbar sind. Die beschriebene Konfiguration bevorzugt Aufgaben, die die Zielperson in maximal einem von drei Versuchen löst, während die Lehrperson mindestens zwei von drei Versuchen erfolgreich bewältigt. In diesem Bereich können angeleitete Demonstrationen dem leistungsschwächeren Modell etwas beibringen, das es noch nicht beherrscht.

Die positive Verifikation erfordert, dass eine Referenztrajektorie den Verifizierer besteht. Die negative Verifikation erfordert, dass veränderte, fehlerhafte Ergebnisse fehlschlagen. Zusammen testen sie die Akzeptanz- und Ablehnungsseite des Prüfers. Werden nur positive Ergebnisse geprüft, kann ein permissiver Verifizierer fehlerhafte Ergebnisse zulassen. Werden nur negative Ergebnisse geprüft, kann ein übermäßig strenger Verifizierer gültige Ergebnisse ablehnen.

Eine Fehlerkorrekturschleife mit Wiederholungslimit versucht, Aufgaben, die an bestimmten Kontrollpunkten scheitern, zu beheben, anstatt jeden Beinahe-Fehler sofort zu verwerfen. Wiederholungslimits sind wichtig: Endlose Reparaturen können immer künstlichere Einschränkungen erfinden, nur um eine Checkliste zu bestehen.

Die Meta-Prüfung auf Batch-Ebene untersucht anschließend das gesamte Set auf Abdeckung, Diversität, Redundanz und nicht erfüllte Ziele. Stichprobenprüfungen gewährleisten die Korrektheit einzelner Elemente; die Batch-Prüfung verhindert, dass sich der Lehrplan auf einen eng begrenzten Fehlermodus konzentriert oder nahezu identische Inhalte erzeugt.

Diese Kontrollmechanismen erklären, warum die Pipeline stundenlang Tausende von Stichproben erzeugen kann, ohne das Volumen als Ersatz für die Anpassung zu verwenden. Die Geschwindigkeit variiert je nach Domäne und Modellgröße, aber der Qualitätskontrollprozess ist konsistent: Schwierigkeitsgrad, positive und negative Verifizierung, Korrektur mit Grenzwerten und anschließende Meta-Überprüfung.

Rohfehler vs. Karten vs. validierte SFT-Sets

Es ist hilfreich, den Nutzen der einzelnen Artefakte zu vergleichen. Rohdaten von Fehlern dienen der Diagnose. Fähigkeitskarten sind generative Verträge. Validierte, überwachte Feinabstimmungssets sind die Grundlage für das praktische Training.

In Hybrid- und ITSM-Snapshots auf EnterpriseOps Gym verwendeten die vom Autor gemeldeten Läufe Gemma-4-26B-A4B-it als Zielsystem. Hybrid kombinierte dieses Zielsystem mit Qwen3.8-27B als Lehrersystem und erzeugte in etwa 18 Stunden rund 2.000 Hybrid-Samples, wobei der beste Checkpoint bei Epoche 5 lag. Die mittlere Pass@1-Rate stieg um 7,2 Prozentpunkte – etwa 35 Prozent relativ –, und die Erfolgsquote der Verifizierer verbesserte sich von 63,01 Prozent auf 68,55 Prozent. Dadurch verringerte sich die Pass@1-Lücke zum Referenzmodell um etwa 59 Prozent.

ITSM kombinierte dasselbe Zielsystem mit DeepSeek-V4.1-Flash als Trainingssystem und erzeugte in etwa 66 Stunden rund 1.994 Samples. Die längere Dauer war teilweise auf ein größeres Trainingssystem und auf noch nicht implementierte Pipeline-Optimierungen zurückzuführen. Die mittlere Erfolgsquote (Pass@1) stieg von 18,77 % auf 27,18 %.

Diese Zahlen sind als Ergebnisse firmeninterner Untersuchungen zu diesem Fitnessstudio in den getesteten Bereichen zu verstehen – nicht als unabhängige Bestätigung durch Dritte und nicht als allgemeingültige Unternehmensgarantie. Erfolge erzielen sich dort, wo die Kompetenz der Trainer, die Qualität der Prüfer und die Umgebungsbedingungen optimal aufeinander abgestimmt sind.

Was Praktiker aus der Schleife übernehmen sollten

Auch wenn Ihre Umgebung nicht der ServiceNow-Forschungspipeline entspricht, lässt sich das Muster übertragen. Beginnen Sie mit der paarweisen Evaluierung eines produktionsnahen Zielsystems und eines leistungsfähigeren Lehrsystems in einer realitätsnahen Sandbox. Wandeln Sie Fehler im Vergleich in Fähigkeitskarten um, die Kennungen und Trajektorien entfernen. Generieren Sie Aufgaben mit variierenden zulässigen Dimensionen, wobei die erforderlichen Eigenschaften des Endzustands erhalten bleiben. Lassen Sie das Lehrsystem Erfolge demonstrieren. Setzen Sie Schwierigkeitsgrade, positive und negative Verifizierung, begrenzte Reparaturmöglichkeiten und eine Überprüfung der Batch-Diversität ein. Optimieren Sie, evaluieren Sie erneut und erweitern Sie die Grenzen.

Achten Sie besonders auf die Gestaltung des Verifizierers. SQL-Ergebnisprüfungen im EnterpriseOps Gym-Stil und richtliniengesteuerte Operationen verdeutlichen, warum Chat-Rubriken allein für zustandsbehaftete Operationen unzureichend sind. Kann Ihr Verifizierer fehlerhafte Ergebnisse nicht von korrekten Endergebnissen unterscheiden, verstärkt die synthetische Skalierung das Rauschen.

Beachten Sie auch den Grundgedanken der Multiplikationsregel: Varianten akzeptierter Ziele sollten nicht endlos weitere Varianten erzeugen, ohne zu den geprüften Kernen zurückzukehren. Drift ist unbemerkt. Ein Lehrplan, der nach und nach immer komplexere Einschränkungen einführt, kann oberflächliche Filter passieren, während die ursprüngliche Fähigkeit unzureichend trainiert bleibt.

Schließlich sollte man hybride, domänenübergreifende Arbeit als besonders anspruchsvolle Belastungssituation betrachten. Anwender im Arbeitsalltag beschränken sich nicht auf ein einziges Tool. Hybride Aufgaben, langfristige Projekte und Machbarkeits- oder Ablehnungstests sind die Bereiche, in denen sich die Kompetenz im Umgang mit der jeweiligen Umgebung zeigt – oder kläglich scheitert.

Vorbehalte, Grenzen und eine sorgfältige Interpretation der Gewinne

Die vom Autor auf EnterpriseOps Gym berichteten Ergebnisse sind informative Hinweise, keine generelle Garantie. Die veröffentlichten Vorteile für Hybrid- und ITSM-Lösungen gelten für die beschriebenen Domänen und Modellkombinationen unter den beschriebenen Bedingungen. Andere Domänen, weniger leistungsfähige Schulungsumgebungen, weniger zuverlässige Prüfumgebungen oder eine geringere Umgebungsgenauigkeit können den Nutzen verringern oder aufheben.

Qualität beruht auf drei Säulen, die in keiner Marketingfloskel fehlen dürfen. Die Kompetenz der Lehrkraft setzt die Obergrenze für Demonstrationen. Die Qualität der Prüfer bestimmt die Vertrauenswürdigkeit von Kennzeichnungen und Filtern. Die Umgebungstreue entscheidet darüber, ob erlernte Verhaltensweisen auch im Produktivbetrieb mit Produktionssystemen, Regeln und Datenzuständen erhalten bleiben.

Die Experimente von AutoSynthData legen den Schwerpunkt auf überwachtes Feintuning. Reinforcement Learning wird als mögliche spätere Anwendung desselben Algorithmus erwähnt, ist aber in der vorliegenden Arbeit geplant, nicht aber umgesetzt. Leser sollten eine sofort einsatzbereite Daten-Engine nicht mit der Behauptung verwechseln, dass bereits ein komplettes RL-Training abgeschlossen sei.

Leser sollten die Synthese-Pipeline nicht mit der Testumgebung selbst verwechseln. EnterpriseOps Gym stellt die kuratierten Aufgaben, Tools, Tabellen, Containerisierung und Verifizierungsinfrastruktur bereit. AutoSynthData nutzt diese Umgebung, um Fehler in wertvolle Trainingsdaten umzuwandeln. Beide Komponenten verdienen Anerkennung: Die Testumgebung trainiert Agenten; die Pipeline generiert aus erkannten Lücken zahlreiche lernfähige Aufgaben.

Auch Rechen- und Kalenderzeit sind im Sandbox-Umfeld nicht kostenlos. Die hybride Synthese wurde innerhalb weniger Stunden für etwa zweitausend Samples abgeschlossen; ITSM benötigte aufgrund der komplexeren Lehrerstruktur und der früheren Pipeline-Struktur mehr Zeit. Teams sollten Zeit für Lehrer-Inferenz, Wiederholungsversuche zur Kritik oder Korrektur sowie für eine erneute Bewertung nach jedem Curriculum-Schritt einplanen.

Lehrplanüberlegungen für Agententeams in Unternehmen

Der Kerngedanke von AutoSynthData ist eher curricular als rein generativ. Fehler werden analysiert. Karten abstrahieren. Die Generierung vervielfacht sich. Die Qualitätskontrolle validiert. SFT aktualisiert das Ziel. Die erneute Evaluierung verschiebt die Grenzen. Diese Abfolge betrachtet die Agentenverbesserung als eine Reihe von umgebungsbezogenen Lektionen anstatt als einmaliges Offline-Speichern von Traces.

Curriculumsorientiertes Denken verändert die Ressourcenverteilung der Führungskräfte. Anstatt lediglich mehr Testergebnisse oder menschliche Anmerkungen zu fordern, sollte man sich fragen, welche Fähigkeiten unter Variationen weiterhin versagen, ob diese Fähigkeiten eindeutige Endzustandseigenschaften aufweisen und ob eine erfahrene Lehrkraft sie zuverlässig demonstrieren kann. Gelingt dies der Lehrkraft nicht oft genug, lehrt synthetisches SFT unzuverlässiges Verhalten. Sind die Endzustandseigenschaften unklar, werden Prüfer gültige Strategien infrage stellen.

Es verändert auch die Art und Weise, wie Sie über Erfolg sprechen. Die teilweise Schließung einer Lücke im Pass@1-Ergebnis im Vergleich zu einem Referenzmodell im Hybrid-Umfeld oder die Steigerung des ITSM-Pass@1-Werts von knapp 15 auf knapp 25 in den vom Autor gemeldeten Läufen ist ein Fortschritt hinsichtlich der gemessenen Kompetenz in der Umgebung. Es ist kein Beweis dafür, dass jeder Workflow, jede Richtlinie oder jeder Ablehnungsfall gelöst ist. Behalten Sie die dynamische Sprache bei: Verbleibende Lücken bilden die nächste Zielphase und werden nicht nachträglich vernachlässigt.

Bei der Programmgestaltung sollte diese Schleife mit einer menschlichen Überprüfung kombiniert werden, wenn hohe Einsätze anfallen – etwa bei Sicherheitsrichtlinien, irreversiblen Maßnahmen oder regulierten Daten. Gleichzeitig sollten automatisierte Kontrollinstanzen bei klar definierten Zustandsprüfungen das Datenvolumen übernehmen. Synthetische Daten eignen sich am besten, wenn die Umgebung SQL-ähnliche Klarheit mit Ja oder Nein liefern kann. Schwierigkeiten bereiten sie, wenn der Erfolg von subjektiven Einschätzungen abhängt.

Anmerkungen zum Design hinsichtlich Schwierigkeit, Realismus und Ablehnung

Die Schwierigkeitsanpassung verdient eine erneute Betrachtung. Indem man Aufgaben bevorzugt, die der/die Teilnehmer/in höchstens in einem Drittel der Fälle lösen kann, vermeidet man, dass das Training zu trivialem Wissen wird. Die Anforderung, dass der/die Lehrer/in mindestens zwei Drittel der Fälle erfolgreich sein muss, verhindert, dass Demonstrationen zu reinen Glücksspielen werden. Dieser Bereich stellt einen praktikablen Kompromiss zwischen Herausforderung und Lernbarkeit dar.

Realismus bleibt ein weniger strenges Kriterium, ist aber dennoch unerlässlich. Unternehmensanwender fordern Lösungen, die ihren Rollen und Systemen entsprechen. Generatoren, die ausschließlich auf Schwierigkeitsgraden basieren, können komplexe, vielschichtige Aufgaben erzeugen, die kein Anwender anfordern würde. Fähigkeitskarten mit variablen Dimensionen sind hilfreich, doch Menschen oder eine Meta-Prüfung müssen weiterhin unrealistische Aufgaben erkennen.

Ablehnungs- und Unmöglichkeitstests, die im Gesamtkonzept von EnterpriseOps Gym enthalten sind, erinnern Teams daran, dass Kompetenz auch das Nein-Sagen umfasst. Eine Pipeline, die nur für abschließbare Aufgaben optimiert ist, kann das Ablehnen vernachlässigen. Beim Erweitern von AutoSynthData-ähnlichen Schleifen sollten Karten hinzugefügt werden, deren korrekte Endbedingung eine sichere Ablehnung gemäß den Richtlinien ist, nicht nur eine erfolgreiche Änderung des Datenbankzustands.

Langfristige zustandsbehaftete Trajektorien erfordern eine weitere Designüberlegung. Die Demonstrationen der Lehrkräfte müssen über viele Tool-Aufrufe hinweg konsistent bleiben. Verifizierer, die nur die letzte Tabellenzeile prüfen, übersehen möglicherweise zwischenzeitliche Richtlinienverstöße. Vollständigkeit im Verifiziererdesign bedeutet, die Eigenschaften abzudecken, die den Erfolg dieser Funktionalität tatsächlich definieren – einschließlich der Einschränkungen, die während des gesamten Prozesses und nicht nur am Ende gelten müssen.

Abschlusszusammenfassung

AutoSynthData, eine Pipeline aus ServiceNow CoreAI/ServiceNow-AI, die in der öffentlichen Dokumentation von Esakkivel Esakkiraja beschrieben wird, wandelt Zielagentenfehler und Lehrer-Agenten-Erfolge in validierte synthetische Trainingsaufgaben für Unternehmensumgebungen um. Sie abstrahiert Fehler in bereinigte Fähigkeitsspezifikationskarten, generiert neue Aufgaben, ohne die ursprünglichen Anweisungen oder Trajektorien preiszugeben, sammelt Lehrer-Demonstrationen und führt vor dem überwachten Feinabstimmen eine Qualitätskontrolle auf Stichproben- und Batch-Ebene durch.

Das praktische mentale Modell besteht aus einer Aufgabe als Systemspezifikation, einer Benutzeraufforderung und einem Verifizierer – wobei Machbarkeit, Realismus und Schwierigkeit im Gleichgewicht stehen und die Verifizierer weder zu nachlässig noch auf einen einzigen Weg festgelegt sind. Die Phasen „Zielsetzung“ und „Multiplikation“, eine Regel, die die Verwendung weiterer Startwerte für multiplizierte Stichproben unterbindet, ein gemeinsamer Controller plus Umgebungsadapter und die erneute Bewertung nach der SFT schaffen eine dynamische Grenze zur Schließung verbleibender Lücken.

Auf EnterpriseOps Gym zeigen die vom Autor berichteten Hybrid-Ergebnisse mit Gemma-4-26B-A4B-it und Qwen3.8-27B in etwa 18 Stunden rund zweitausend Beispiele und signifikante Verbesserungen bei Pass@1 und Verifier-Erfolg, wodurch ein Großteil der Lücke zu einem Referenzmodell geschlossen wird. ITSM mit DeepSeek-V4.1-Flash als Lehrermodell zeigt einen Anstieg von Pass@1 von 18,77 Prozent auf 27,18 Prozent bei etwa 1.994 Beispielen über einen längeren Zeitraum. Diese Zahlen sind als Forschungsergebnisse in spezifischen Bereichen zu betrachten, die von der Genauigkeit des Lehrermodells, des Verifiers und der Umgebung abhängen – und Reinforcement Learning sollte als geplante Erweiterung des Prozesses und nicht als endgültige Aussage betrachtet werden.

Merken Sie sich einen Satz: Unternehmensagenten verbessern sich, wenn Fehler zu abstrahierten, vervielfachten und verifizierten Lektionen innerhalb der Systeme werden, mit denen sie täglich arbeiten müssen – und nicht, wenn Teams einfach immer wieder dasselbe fehlerhafte Ticket bearbeiten.

Praktisches Beispiel: Erweiterung schwieriger ITSM-Fälle aus einem eingefrorenen Fehlerset im Gym-Stil

Szenario

Ein britisches Enterprise-Plattform-Team – beispielsweise eine mittelgroße Betriebsgruppe im Finanzdienstleistungssektor, die ITSM im ServiceNow-Stil mit Änderungsfenstern, CMDB-Beziehungen und richtliniengesteuerten Übergängen betreibt – hat einen produktionsnahen Agenten, der immer wieder auf die gleiche Art von Arbeit stößt: Tabellenübergreifende Aktualisierungen, die eine Genehmigungsvoraussetzung erfüllen müssen, Wissensartikel-Lookups, die mit lokalen Änderungssperren in Konflikt stehen, und hybride Anfragen, die ITSM mit angrenzenden Betriebstools verbinden.

Sie frieren eine private EnterpriseOps-Gym-ähnliche Suite ein (containerisierte Sandbox, SQL-Ergebnisprüfungen, initialisierte Tabellen, Richtlinienregeln), um die Ergebnisse wöchentlich vergleichbar zu machen. Diagnoseläufe zeigen, dass der Zielagent dort versagt, wo ein leistungsstärkerer Trainer erfolgreich ist. Die Führungsebene wünscht sich mehr Trainingssignale, ohne dieselben Ticketnummern und Entitäts-IDs erneut abzuspielen. AutoSynthData (oder eine äquivalente Synthese-aus-Fehlern-Schleife, falls die Forschungspipeline in ihrem Stack eingeschränkt ist) ist die Lösung: Kontrastfehler werden in bereinigte Fähigkeitsspezifikationskarten umgewandelt, neue Aufgaben generiert, Trainerdemos gesammelt und – ganz entscheidend – die synthetischen Traces vor jedem erneuten Training manuell überprüft.

Auf Gym Pass@1 wird nichts von selbst versendet. Synthetische Daten werden als Kandidatenlehrplan behandelt, nicht als freie Wahrheit.

Was der Assistent benötigt

• Zugriff auf den eingefrorenen Gym-Umgebungsadapter: Tools, Seed-Zustand, Richtlinien und SQL- (oder gleichwertige zustandsbasierte) Verifizierer.
• Gegenübergestellte Auswertungsprotokolle: Zielversagen im Vergleich zu den Erfolgen der Lehrkräfte bei denselben Aufgaben.
• Ein Kartenschema, das Fähigkeiten, Werkzeug-/Workflow-Struktur, Misserfolgs-/Erfolgskontrast, erforderliche Endzustandseigenschaften und zulässige Variationsdimensionen erfasst - ohne ursprüngliche Eingabeaufforderungen, Entitäten, Trajektorien oder interne Verifizierungsmechanismen.
• PII- und Richtlinienbereinigungsregeln (Ticket-IDs, Benutzernamen, CI-Namen, regulierte Felder), bevor irgendetwas die Sandbox verlässt oder eine Generator-Eingabeaufforderung aufruft.
• Eine Warteschlange für die menschliche Überprüfung von Stichproben synthetischer Aufgaben und Lehrerspuren (Machbarkeit, Realismus, Korrektheit des Prüfers, Ablehnungs-/Unmachbarkeitsfälle).
• Klare Abbruchbedingungen: Zuerst Ziel-, dann Multiplikationsphasen; multiplizierte Proben dienen nicht als Ausgangspunkt für weitere Multiplikationsrunden.

Beispielanleitung

Die Plattform führt zum Curriculum-Operator (oder zu einem Orchestrierungsassistenten, der nur Karten entwirft und Packs überprüft – er schult oder befördert keine Modelle):

Führen Sie den Diagnose-Pass@1 für die eingefrorenen ITSM- und Hybrid-Slices gegen unser aktuelles Zielsystem und den designierten Lehrer durch. Erstellen Sie für jeden Vergleich, bei dem das Zielsystem scheitert und der Lehrer mindestens zwei von drei Versuchen erfolgreich ist, eine bereinigte Fähigkeitsspezifikationskarte: Benennen Sie die Fähigkeit, listen Sie relevante Tools auf, geben Sie die erforderlichen Eigenschaften des Endzustands an und listen Sie steuerbare Dimensionen auf (Prioritätsband, zugehörige CI-Klasse, Änderungsfenster-Flag, Wissenskonflikttyp). Entfernen Sie Ticketnummern, Benutzerkennungen, CI-Namen und Rohdatenverläufe. Generieren Sie aus diesen Karten einen Batch neuer Aufgaben für die Zielphase. Lassen Sie den Lehrer Erfolge demonstrieren. Wenden Sie Schwierigkeitsband (Zielsystem ≤1/3, Lehrersystem ≥2/3), positive und negative Verifizierung sowie begrenzte Kritik/Reparatur an. Erstellen Sie ein Prüfpaket mit 5 % stratifizierten Stichproben plus jeder Ablehnungs-/Unmöglichkeitskarte. Starten Sie SFT erst, wenn zwei Prüfer das Paket freigegeben und die PII-Bereinigungsprüfungen erfolgreich waren. Nach SFT an einem Kandidaten-Checkpoint führen Sie eine erneute Bewertung an der eingefrorenen Suite und an einem Holdout-Exact-Match-Set durch. Wir haben dies nie für die Generation verwendet. Berichtsabdeckung nach Fehlerklasse und Regressionsrate im Vergleich zum vorherigen Produktions-Checkpoint. Nicht allein auf Basis des Gym-Scores bewerben.“

Wie man es testet

1. Baseline-Sperre: Protokollieren Sie die Erfolgsraten von Pass@1 und der Verifizierung für die eingefrorene Testsuite nach Fehlerklasse (Voraussetzungsreihenfolge, Ablehnung im Änderungsfenster, hybrider Cross-Tool-Fehler, Wissenskonflikt). Die Testsuite und die Startwerte bleiben während des Zyklus unveränderlich.
2. Kartenprüfung: Stichprobenartige Überprüfung, ob die Generatoren niemals Original-Prompts, Entitäten oder Lehrerspuren erhalten – sondern ausschließlich Karten.
3. Beispielhafte Qualitätskontrolle: Bestätigen, dass positive Abläufe die Prüfer passieren und fehlerhafte Ergebnisse fehlschlagen. Aufgaben ablehnen, die für das Ziel trivial sind oder für den Lehrer einem Münzwurf gleichen.
4. Menschliche Begutachtung: Die Gutachter bewerten jedes Beispiel hinsichtlich Machbarkeit, Realismus und politischer Sicherheit als beibehalten/reparieren/verwerfen. Die Übereinstimmung der Gutachter bei einer gemeinsamen Teilmenge wird erfasst.
5. Holdout-Exaktübereinstimmung: Nach dem Kandidaten-SFT wird ein Holdout mit realen (oder zuvor eingefrorenen) Aufgaben bewertet, die nie als Eingaben für das Carding oder die Generierung dienten. Nahezu paraphrasierte Trainingsaufgaben werden separat bewertet, um oberflächliches Auswendiglernen zu erkennen.
6. Regressionsgate: Jede Fehlerklasse, die sich gegenüber dem vorherigen Produktions-Checkpoint verschlechtert, blockiert die Freigabe, bis sie erklärt oder behoben ist.

Ergebnis

Hier dürfen keine Backprozentsätze erfunden werden. Verwenden Sie einen Messplan und kennzeichnen Sie veröffentlichte Forschungsergebnisse als ARTIKELBEHAUPTUNG, wenn Sie sie zitieren.

Messplan (was dieses Team berichten sollte):

• Fehlerklassenabdeckung: Anteil der diagnostizierten Lückenklassen, die nach der Qualitätskontrolle ≥N akzeptierte Aufgaben in der Zielphase erzeugt haben (N im Voraus definieren, z. B. 20 akzeptierte Aufgaben pro Klasse).
• Holdout-Exact-Match: Pass@1 / Verifizierungserfolg beim unveränderten Holdout vor vs. nach dem Kandidaten-SFT (gleiche Seeds, gleicher Verifizierer).
• Regressionsrate: Anzahl der Fehlerklassen, bei denen Pass@1 im Vergleich zum vorherigen Produktionsprüfpunkt abbricht; Blockierung, falls eine sicherheitskritische Klasse einen Regressionseffekt erleidet.
• Überprüfungsertrag: Beibehaltung/Reparatur/Drop-Raten beim menschlichen Überprüfungspaket; falls die Drop-Rate sprunghaft ansteigt, Multiplikation pausieren und Karten oder Verifizierer reparieren.
• Scrub-Fehler: Anzahl der Samples, die vor der Freigabe der Überprüfung die PII-/Richtlinienprüfung nicht bestehen (Ziel: keine Escape-Sequenzen im SFT-Set).

ARTIKELBESTÄTIGUNG (vom Autor auf EnterpriseOps Gym berichtet – nicht das Ergebnis dieses Teams): Hybridläufe mit Gemma-4-26B-A4B-it als Zielsystem und Qwen3.8-27B als Testsystem erzeugten in etwa 18 Stunden ca. 2.000 Samples. Der mittlere Wert für „Pass@1“ stieg um ca. 7,2 Prozentpunkte, und die Erfolgsquote der Verifizierung verbesserte sich von 63,01 % auf 68,55 %. ITSM mit DeepSeek-V4.1-Flash als Testsystem steigerte den mittleren Wert für „Pass@1“ in einem längeren Lauf (~66 Stunden) bei ca. 1.994 Samples von 18,77 % auf 27,18 %. Diese Ergebnisse sind als Forschungsergebnisse für spezifische Domänen und Systemkombinationen zu verstehen und stellen keine allgemeingültige Garantie für eine Produktionsumgebung in Großbritannien dar.

Beispielhafter Programmablauf (Annahmen, nicht gemessene Gewinne): Wenn das Team für einen ITSM-Zyklus etwa 2.000 QC-geprüfte Stichproben akzeptiert, die Einschätzung der Lehrkräfte sowie eine Überprüfung mit einer geschichteten Stichprobe von 5 % einplant und nur dann befördert, wenn die Testpersonen in sicherheitskritischen Klassen keine Rückschritte machen, dann ist das „Ergebnis“, das sie guten Gewissens behaupten können, die Prozessreife – geprüfter Lehrplan, bereinigte Spuren und vergleichbare Deltas in eingefrorenen Klassen – und nicht eine versprochene prozentuale Steigerung.

Was kann schiefgehen?

• Synthetisches Material als freie Wahrheit behandeln: Durch das Überspringen einer menschlichen Überprüfung oder einer negativen Verifizierung können permissive Prüfer massenhaft Müll zulassen.
• Entitätsleck: Die Eingabe von ursprünglichen Ticket-IDs oder Lehrer-Traces in den Generator birgt die Gefahr des Paraphrasierens-Overfittings; Karten dienen dazu, dies zu verhindern.
• Unbegrenzte Multiplikation: Wenn multiplizierte Stichproben weitere Runden auslösen, entfernt sich dies von der ursprünglich vorgesehenen Funktionalität.
• Gym-Score-Versand: Werbung, weil die Nachfrage nach Pass@1 in der eingefrorenen Suite stieg, während der Traffic in der Warte- oder Produktionsschattenzone zurückging.
• Schwache Lehrergrenze: Wenn der Lehrer die Erfolgsschwelle von ≥2/3 nicht erreichen kann, lehrt SFT unzuverlässige Demos.
• Unscharfe Prüfverfahren: Chatbasierte Bewertungsraster anstelle von zustandsorientierten Prüfungen werten flüssige, aber fehlerhafte Abschlussprüfungen als Erfolg.
• Untertrainingsverweigerung: Die Optimierung nur für abschließbare Mutationen macht das Änderungsfenster und die Richtlinienrückgänge brüchig.
• PII-Escape: Synthetische Eingabeaufforderungen, die nach einer oberflächlichen Bereinigung echte CI- oder Benutzernamen wieder einführen.

Praktische Erkenntnisse

Nutzen Sie AutoSynthData-ähnliche Schleifen – oder ein gleichwertiges Synth-from-Failures-Muster, falls die ServiceNow CoreAI-Pipeline in Ihrem Mandanten nicht verfügbar ist –, um aus diagnostizierten Lücken verifizierbare ITSM-Fälle zu generieren. Bereinigen Sie die Daten in Fähigkeitskarten, prüfen Sie den Schwierigkeitsgrad und führen Sie positive/negative Verifizierungen durch, entfernen Sie personenbezogene Daten und lassen Sie die Stichproben vor dem SFT manuell überprüfen. Messen Sie die Abdeckung der Fehlerklassen, die Übereinstimmung mit den Holdout-Daten und die Regressionsrate. Zitieren Sie die Zahlen aus dem Artikel-Claim-Gym nur als externen Forschungskontext. Synth-Daten dienen als Grundlage für Schulungsmaterialien, sind aber keine Garantie: Prüfen Sie Stichproben, halten Sie die Suite für einen fairen Vergleich eingefroren und verlassen Sie sich niemals allein auf den Gym-Score.

Häufig gestellte Fragen

Was ist AutoSynthData und welches Problem löst es?

AutoSynthData ist eine von Esakkivel Esakkiraja beschriebene ServiceNow CoreAI/ServiceNow-AI-Pipeline, die die Fehler eines Zielagenten mit den Erfolgen eines leistungsfähigeren Trainingsagenten in validierten synthetischen Trainingsaufgaben für Unternehmensumgebungen kombiniert. Der Fokus liegt dabei auf der Umgebungskompetenz – lokalen Richtlinien, Schemata, Tools und Zuständen – anstatt auf allgemeinem Wissen. Ziel ist es, durch sorgfältige und überprüfbare Arbeit umgebungsspezifische Lücken zu schließen, anstatt immer wieder dieselben Fehler zu beheben.

Warum unterscheidet sich Umweltkompetenz von umfassender Modellfähigkeit?

Enterprise-Agenten stoßen oft auf Schwierigkeiten, weil die Umgebung selbst spezifisch ist: Ticketrichtlinien, Schema-Besonderheiten, Tool-Verträge, vordefinierte Datenbanken und systemübergreifende Workflows. Ein Modell, das in offenen Benchmarks gut abschneidet, kann dennoch bei einem Änderungsfenster, einer CMDB-Beziehung oder einem Prüfer, der den Endzustand untersucht, zum Stillstand kommen. Umfassende Funktionalität ist nicht gleichzusetzen mit dem Wissen, wie sich Ihre Systeme, Regeln und Datenzustände bei richtliniengesteuerten Übergängen verhalten.

Welche praktische Aufgabenform verwendet AutoSynthData?

Eine praktikable Struktur besteht aus Systemspezifikation, Benutzereingabe und Verifizierer. Die Systemspezifikation enthält Einschränkungen, Richtlinien und den Anfangszustand, beispielsweise Datenbank-Seeds und Wissensartikel. Benutzereingaben werden hinsichtlich Machbarkeit, Realismus und Schwierigkeit bewertet. Verifizierer nutzen idealerweise SQL-basierte oder zustandsbasierte Ergebnisprüfungen, um die Welt nach der Handlung des Agenten zu bewerten und nicht nur den exakten Token-Pfad.

Wie verhindern bereinigte Fähigkeitsspezifikationskarten Überanpassung?

Die Diagnose vergleicht Fälle, in denen das Ziel scheitert und der Lehrer erfolgreich ist, und fasst diese Fälle in bereinigte Fähigkeitsspezifikationskarten zusammen. Eine Karte erfasst die Fähigkeit, die Werkzeuge oder den Workflow, den Unterschied zwischen Erfolg und Misserfolg, die erforderlichen Eigenschaften des Endzustands und variable Dimensionen. Der Generator sieht niemals die ursprünglichen Anweisungen, Entitäten, Abläufe oder Prüfdetails – nur die Karten. So werden neue Aufgaben direkt auf die Kerninhalte angewendet, ohne dass bereits bekannte Episoden paraphrasiert werden müssen.

Was sind die Ziel- und Multiplikationsphasen in der Pipeline?

Die Zielphase konzentriert sich auf geprüfte Kernbeispiele in Bereichen mit Lücken – die Aufgaben mit dem höchsten Signalwert in der Nähe der Schwachstellen des Systems. In der Multiplikationsphase werden neue Varianten der akzeptierten Ziele entwickelt. Multiplizierte Beispiele können nicht für weitere Multiplikationsrunden verwendet werden, wodurch ein Abweichen von der angestrebten Fähigkeit verhindert wird. Nach der überwachten Feinabstimmung verschiebt die erneute Bewertung den Fokus des Curriculums auf die verbleibenden Lücken als dynamische Herausforderung anstatt als statischen Speicher.

Wie gewährleistet die Qualitätskontrolle auf Probenebene die Zuverlässigkeit synthetischer Aufgaben?

Ein Schwierigkeitsfilter für den Löser bevorzugt Aufgaben, die das Ziel in maximal einem von drei Versuchen löst, während der Lehrer mindestens zwei von drei Versuchen erfolgreich absolviert. Die positive Verifizierung benötigt eine Referenztrajektorie, um erfolgreich zu sein; die negative Verifizierung benötigt mutierte, falsche Ergebnisse, um fehlzuschlagen. Eine Kritik- und Reparaturschleife mit einem Wiederholungslimit versucht, Beinahe-Fehler zu beheben, und eine Meta-Überprüfung auf Batch-Ebene prüft Abdeckung, Diversität, Redundanz und fehlgeschlagene Ziele im gesamten Set.

Welche Architektur verwendet AutoSynthData in verschiedenen Unternehmensbereichen?

Es kombiniert einen gemeinsamen Controller mit einem Umgebungsadapter. Der Controller führt Diagnose, Kartenerstellung, Generierung, Lehrerdemos, Qualitätsprüfungen und Stapelverarbeitung durch. Der Adapter integriert diese Schritte in eine konkrete Sandbox – Werkzeuge, Status, Richtlinien und Verifizierer –, sodass derselbe Regelkreis auf verschiedene Domänen verweisen kann, ohne die Lehrplanlogik von Grund auf neu schreiben zu müssen.

Was ist EnterpriseOps Gym in diesem Forschungskontext?

EnterpriseOps Gym ist die umfangreiche Agenten-Testumgebung für Unternehmen, die als Stresstest dient. Sie umfasst rund 1.150 von Experten zusammengestellte Aufgaben in acht Domänen, etwa 512 Tools, ca. 164 Datenbanktabellen, containerisierte Ausführung, SQL-basierte Ergebnisverifizierung, richtliniengesteuerte Operationen, hybride Szenarien und langfristige zustandsbehaftete Entwicklungspfade. AutoSynthData erhebt nicht den Anspruch, diese Testumgebung erfunden zu haben; sie veranschaulicht vielmehr den Syntheseprozess in der Praxis.

Welche vom Autor gemeldeten Ergebnisse ergeben sich für Hybrid- und ITSM-Umgebungen?

Auf EnterpriseOps Gym wurden in Hybrid-Tests mit Gemma-4-26B-A4B-it als Zielsystem und Qwen3.8-27B als Testsystem in etwa 18 Stunden rund 2.000 Testbeispiele generiert. Die durchschnittliche Erfolgsquote (Pass@1) stieg um etwa 7,2 Prozentpunkte, und die Erfolgsquote der Verifizierung verbesserte sich von 63,01 % auf 68,55 %. ITSM mit DeepSeek-V4.1-Flash als Testsystem steigerte die durchschnittliche Erfolgsquote (Pass@1) in einem längeren Testlauf mit rund 1.994 Testbeispielen von 18,77 % auf 27,18 %. Diese Ergebnisse sind als Forschungsergebnisse für spezifische Systempaarungen zu verstehen und stellen keine allgemeingültige Produktionsgarantie dar.

Welche Fehler sollten Teams bei der Verwendung von Synth-from-Failures-Schleifen vermeiden?

Synthetische Daten dürfen nicht als unumstößliche Wahrheit betrachtet werden. Menschliche Überprüfung und negative Verifizierung sind unbedingt zu vermeiden. Es ist untersagt, Original-Ticket-IDs oder Lehrerdaten in den Generator einzugeben, vervielfältigte Stichproben in weitere Runden einfließen zu lassen oder Gym Pass@1 eigenständig zu bewerben, während der Datenverkehr in der Gruppe oder im Schattenbereich zunimmt. Achten Sie außerdem auf leistungsschwache Lehrer unterhalb der Erfolgsgrenze, unklare Chat-Bewertungskriterien anstelle von staatlichen Prüfungen, Fälle von Verweigerung aufgrund unzureichender Schulung und das unbefugte Öffnen personenbezogener Daten nach einer oberflächlichen Bereinigung.

Referenzen

1. Hugging Face — AutoSynthData — huggingface.co
2. EnterpriseOps Gym — enterpriseops-gym.github.io
3. arXiv — arxiv.org
4. GitHub — EnterpriseOps-Gym — github.com