AutoSynthData: generowanie danych treningowych dla agentów korporacyjnych zamienia porażki w program nauczania
ServiceNow CoreAI zaprezentował AutoSynthData 2 października, informując o poprawie wyników w dwóch eksperymentach z agentami korporacyjnymi dzięki niemal 4 000 syntetycznych zadań. AutoSynthData: Generating Training Data for Enterprise Agents zaczyna od błędów modelu, a następnie przekształca te słabości w wykonywalne i weryfikowalne przykłady treningowe. Napięcie jest wyraźne: dane syntetyczne można szybko skalować, lecz generowane zadania mogą również uczyć niewłaściwych zachowań.
To czyni AutoSynthData czymś więcej niż kolejnym systemem proszącym model o wymyślanie promptów. Próbuje on zbudować zamkniętą pętlę treningową wokół docelowego agenta, jego środowiska operacyjnego i silniejszego modelu nauczyciela. Każde zaakceptowane zadanie obejmuje początkowy stan systemu, żądanie użytkownika, udaną trajektorię oraz weryfikator oceniający stan końcowy.
ServiceNow twierdzi, że podejście poprawiło wyniki docelowego modelu Gemma w dwóch domenach EnterpriseOps Gym. Zyski te pochodzą jednak z kontrolowanych eksperymentów w obrębie tej samej rodziny benchmarków, która ukształtowała program nauczania. Wynik ten wywiera presję na zespoły polegające na statycznych, tworzonych przez ludzi zbiorach danych, pozostawiając jednocześnie nierozstrzygnięte kwestie transferu zewnętrznego i niezawodności produkcyjnej.
AutoSynthData: generowanie danych treningowych dla agentów korporacyjnych zaczyna się od błędu
Istotna zmiana polega na tym, że ServiceNow traktuje błędy agentów jako wskazówki, jakie dane treningowe należy wygenerować w następnej kolejności.
Tradycyjne procesy tworzenia danych syntetycznych często zaczynają się od tematów, szablonów lub przykładów startowych. Rozszerzają te dane wejściowe do większych kolekcji, filtrują wyniki i wykorzystują zachowane próbki do treningu. Taki proces może zwiększać wolumen bez dowodu, że nowe dane odpowiadają na rzeczywiste słabości modelu.
AutoSynthData odwraca tę kolejność. Najpierw ocenia docelowy model w środowisku operacyjnym i analizuje miejsca, w których model zawodzi. Silniejszy model nauczyciela podejmuje te same zadania diagnostyczne, zapewniając porównanie nieudanego i skutecznego zachowania.
System analizuje zaangażowaną zdolność, wymagane narzędzia, strukturę przepływu pracy oraz stan końcowy oznaczający sukces. Identyfikuje też szczegóły, które można zmienić bez usuwania podstawowej zdolności. Te obserwacje stają się tym, co ServiceNow nazywa oczyszczonymi kartami specyfikacji zdolności.
Karty te kierują generowaniem bez ujawniania oryginalnych promptów ewaluacyjnych, encji, trajektorii ani szczegółów weryfikatora. Separacja ma ograniczać bezpośrednie przecieki z benchmarku. Zmusza też generator do tworzenia nowych sytuacji zamiast zwykłego parafrazowania pytań testowych.
Format zadania składa się z trzech połączonych części. Specyfikacja systemu definiuje polityki, dostępne działania i początkowy stan środowiska. Prompt użytkownika określa oczekiwany rezultat, a weryfikator rozstrzyga, czy agent osiągnął akceptowalny stan końcowy.
Ta struktura ma znaczenie, ponieważ praca w przedsiębiorstwie rzadko kończy się tekstową odpowiedzią. Agent obsługi IT może potrzebować sprawdzić incydent, zweryfikować uprawnienie, zaktualizować rekord i zachować ślad audytowy. Płynna odpowiedź nie dowodzi, że którekolwiek z tych działań wykonano poprawnie.
W informacji o wydaniu AutoSynthData opisano dwa etapy generowania. Etap docelowy tworzy i waliduje podstawowe przykłady zbudowane wokół zidentyfikowanych luk w zdolnościach. Etap mnożenia tworzy nowe warianty na podstawie zaakceptowanych próbek docelowych.
Każdy wariant otrzymuje własne żądanie, encje, stan początkowy, trajektorię referencyjną i weryfikator. Zmnożona próbka nie może stać się ziarnem dla kolejnej zmnożonej próbki. Ograniczenie to ma zapobiegać oddalaniu się wielu generacji syntetycznej ekspansji od zwalidowanego rdzenia.
Proces rozdziela centralne sterowanie generowaniem od wykonania zależnego od środowiska. Kontroler zarządza pokryciem, kontrolami jakości i budową zbioru danych. Adapter uruchamia narzędzia, zarządza stanem, odtwarza rozwiązania referencyjne, ocenia agentów i stosuje deterministyczną weryfikację.
Taki podział daje temu podejściu drogę poza jeden benchmark. Firma mogłaby teoretycznie zachować wspólny kontroler, jednocześnie pisząc adapter dla własnych systemów. Każdy nowy adapter wymagałby jednak dokładnych narzędzi, realistycznych przejść stanów i niezawodnych kryteriów sukcesu.
Wiadomość nie polega zatem po prostu na tym, że ServiceNow wygenerował syntetyczne zadania. Firma skonstruowała proces, który wybiera zadania zgodnie z aktualnymi słabościami modelu. Następnie przesuwa cel treningowy wraz ze zmianą tych słabości.
Ta adaptacyjna pętla podważa statyczne tworzenie zbiorów danych. Ustalona kolekcja staje się mniej wartościowa, gdy model rozwiązuje większość jej zadań. AutoSynthData zamiast tego szuka w pobliżu aktualnej granicy możliwości modelu, gdzie przykłady pozostają trudne, ale nadal możliwe do nauczenia.
Idea ta zmienia również znaczenie błędu ewaluacji. Zamiast być jedynie wynikiem lub raportem o błędzie, porażka staje się surowcem do dalszego treningu. To samo środowisko może diagnozować słabości, generować ukierunkowane ćwiczenia i testować zaktualizowany model.
Ta pętla jest centralnym twierdzeniem stojącym za AutoSynthData: Generating Training Data for Enterprise Agents. ServiceNow nie wykazał jeszcze, że działa ona w niezwiązanych ze sobą środowiskach korporacyjnych. Mimo to firma zdefiniowała konkretną alternatywę dla bezkrytycznego skalowania danych syntetycznych.
Statyczne zbiory danych dla agentów mierzą się teraz z ruchomym celem
AutoSynthData wywiera presję na zespoły, które zbierają szerokie dane treningowe bez mierzenia, czy każda próbka uczy brakującej zdolności.
Twórcy agentów korporacyjnych mają trudny problem z danymi. Rekordy produkcyjne zawierają użyteczne wzorce przepływów pracy, ale mogą również obejmować dane osobowe, poufne dane biznesowe i niespójne wyniki. Zadania pisane przez ludzi pozwalają uniknąć części problemów z prywatnością, jednak stworzenie wystarczającej liczby różnorodnych i weryfikowalnych przykładów jest kosztowne.
Dane syntetyczne oferują skalę, lecz sama skala nie wybiera właściwej lekcji. Model, który już obsługuje prośby o reset hasła, niewiele zyskuje dzięki tysiącom podobnych przykładów. Potrzebuje zadań ujawniających nierozwiązane problemy, takie jak kontrole polityk, planowanie wielosystemowe i bezpieczna odmowa.
EnterpriseOps Gym zapewnia kontrolowane środowisko użyte w eksperymentach ServiceNow. Jego artykuł o benchmarku opisuje zadania ze stanem, w których agent musi rozumować między narzędziami i pozostawić bazowy system we właściwym stanie. Różni się to od benchmarków oceniających wyłącznie końcową odpowiedź tekstową.
ServiceNow opisuje EnterpriseOps Gym jako obejmujący osiem domen biznesowych. Powiązane środowisko zawiera 512 funkcjonalnych narzędzi i 164 połączone ze sobą tabele baz danych. Zasoby te wspierają przepływy pracy w obszarach obejmujących zarządzanie usługami IT, obsługę klienta i zasoby ludzkie.
Według ServiceNow szerszy benchmark obejmuje 1 150 zadań korporacyjnych. Testują one planowanie, zgodność z politykami i zmiany stanów w połączonych systemach. Udostępniony zbiór danych daje również zewnętrznym badaczom dostęp do materiałów benchmarku.
Liczby te wyjaśniają, dlaczego ukierunkowane generowanie ma znaczenie. Pojedynczy przepływ pracy może łączyć kilka narzędzi, rekordów, polityk i zależności. Niewielkie zmiany stanu początkowego mogą zmienić, która sekwencja jest prawidłowa, albo czy żądane działanie powinno w ogóle nastąpić.
ServiceNow wcześniej informował, że udostępnienie eksperckich planów zadań podniosło wyniki o 15% do 35% w trudnych domenach korporacyjnych. Ustalenie to sugeruje, że planowanie pozostaje istotnym ograniczeniem, nawet gdy agent potrafi poprawnie wywoływać pojedyncze narzędzia. AutoSynthData próbuje przekształcić takie luki planistyczne w powtarzalne możliwości treningowe.
Presja w pierwszej kolejności spada na zespoły pracujące nad statyczną ewaluacją. Ustalony zestaw testowy może wskazać słabość, ale nie tworzy automatycznie programu nauczania, który ją eliminuje. Badacze nadal muszą przełożyć błędy na różnorodne przykłady, prawidłowe rozwiązania i niezawodną logikę oceniania.
Druga presja spada na dostawców modeli ogólnego przeznaczenia. Silne średnie wyniki benchmarkowe mogą ukrywać błędy powodowane przez lokalne polityki, struktury tabel lub reguły przepływów pracy. Przedsiębiorstwa potrzebują dowodów, że model potrafi działać w ich konkretnych systemach, a nie jedynie odpowiadać na pytania na ich temat.
Trzecia presja spada na firmy budujące platformy agentowe. Jeśli adaptacyjny trening okaże się użyteczny, infrastruktura ewaluacyjna stanie się częścią rozwoju modeli, a nie końcową bramką jakości. Platformy będą potrzebować odtwarzalnych środowisk, generowania zadań, dzienników wykonania i weryfikacji opartej na stanie.
Wymóg ten sprzyja organizacjom dysponującym symulatorami operacyjnymi lub cyfrowymi bliźniakami. Salesforce realizuje powiązany kierunek poprzez CRMArena-Pro, które wykorzystuje symulowane środowiska korporacyjne do oceny agentów w przepływach pracy biznesowej. To podobieństwo sygnalizuje szerszy zwrot ku wykonywalnemu, zakorzenionemu w środowisku testowaniu agentów.
Podejścia te nie są identyczne. Benchmark może porównywać modele bez ich modyfikowania, podczas gdy AutoSynthData wykorzystuje błędy benchmarku do generowania danych po treningu. Jedno mierzy zdolność, a drugie próbuje ją przesunąć.
To rozróżnienie ma znaczenie dla nabywców korporacyjnych. Ranking wskazuje najsilniejszy model w określonych warunkach. Adaptacyjny program nauczania pyta, czy tańszy lub mniejszy model docelowy może poprawić się w zakresie własnych, powtarzalnych zadań organizacji.
Zgłoszone przez ServiceNow wyniki czynią tę możliwość konkretną, ale nie rozstrzygniętą. Model docelowy nadal wykonywał po treningu tylko mniejszość zadań z zakresu usług IT. Lepszy wynik od wartości bazowej nie oznacza gotowości do niesuperwizowanego dostępu produkcyjnego.
Jakość wiedzy pozostaje również praktycznym ograniczeniem. Agent nie może przestrzegać polityki, która jest niepełna, sprzeczna lub niedostępna. Zespoły budujące przeszukiwalną bazę wiedzy nadal potrzebują jasnych materiałów źródłowych, zanim generowane zadania treningowe będą mogły odzwierciedlać rzeczywistą pracę.
AutoSynthData przesuwa więc wąskie gardło, zamiast je eliminować. Zespoły potrzebują mniej ręcznie tworzonych wariantów, ale potrzebują godnego zaufania środowiska i precyzyjnej weryfikacji. Ta wymiana staje się decydująca, gdy agent może zmieniać rekordy klientów, pracowników lub infrastruktury.
Mechanizm zależy od wykonywalnych zadań i rygorystycznych weryfikatorów
AutoSynthData działa tylko wtedy, gdy wygenerowane żądania, rozwiązania referencyjne i weryfikatory są zgodne co do tego, co oznacza sukces.
Proces rozpoczyna się od identyfikacji zadań, które odróżniają model docelowy od silniejszego nauczyciela. W opisanej konfiguracji ServiceNow preferuje kandydatów, których model docelowy rozwiązuje nie więcej niż raz w trzech próbach. Silniejszy rozwiązujący musi ukończyć je co najmniej dwa razy w trzech próbach.
Filtr ten ma wyznaczać użyteczny przedział trudności. Zadania, które pokonują oba modele, nie oferują wiarygodnej demonstracji. Zadania, które oba rozwiązują konsekwentnie, zużywają zasoby treningowe bez ukierunkowania na wyraźną słabość.
Gdy kandydat trafia do procesu, AutoSynthData wykonuje jego trajektorię referencyjną. Trajektoria to sekwencja wywołań narzędzi i działań użytych do osiągnięcia żądanego stanu. Weryfikator następnie sprawdza wynik względem warunków sukcesu zadania.
Ta pozytywna kontrola pyta, czy zamierzone rozwiązanie rzeczywiście działa. Może ujawnić nieprawidłowy stan początkowy, niedostępne narzędzie, uszkodzoną sekwencję działań lub niespójność między żądaniem a weryfikatorem. Wiarygodnie wyglądający przykład zawodzi, jeśli nie przetrwa wykonania.
Potok wykonuje również weryfikację negatywną. Modyfikuje oczekiwane wyniki i potwierdza, że nieprawidłowe stany nie przechodzą kontroli. Ten krok ma znaczenie, ponieważ słaby weryfikator może nagradzać agenta, który pomija wymagane działania lub narusza ważne ograniczenie.
Rozważmy żądanie zamknięcia incydentu IT dopiero po potwierdzeniu rozwiązania problemu z poszkodowanym pracownikiem. Weryfikator sprawdzający wyłącznie status incydentu zaakceptowałby niebezpieczny skrót. Silniejszy weryfikator wymagałby także zapisu potwierdzenia oraz wszelkich wymaganych notatek.
Ten sam problem pojawia się, gdy poprawnych jest kilka rozwiązań. Weryfikator powinien rozpoznawać akceptowalne wyniki, nie wymagając jednej dokładnej sekwencji referencyjnej. ServiceNow ujmuje to jako kompletność, obok zgodności z żądaniem i skutecznego odrzucania nieprawidłowego zachowania.
Wymagania te tworzą trudną równowagę. Zbyt pobłażliwy weryfikator nagradza niekompletną pracę. Zbyt wąski weryfikator karze uzasadnione strategie i uczy model naśladowania arbitralnej sekwencji.
Nieudane kandydatury trafiają do ograniczonej pętli krytyki i naprawy. Krytyk analizuje konstrukcję zadania, stan początkowy, rozwiązanie i logikę weryfikacji. System stosuje ukierunkowane poprawki, ponownie uruchamia odpowiednie bramki i akceptuje albo odrzuca zmienioną kandydaturę.
Naprawienie istniejącej kandydatury może zachować wartościową pracę. Pozwala też uniknąć ponownego rozpoczynania generowania za każdym razem, gdy jeden komponent zawiera możliwą do usunięcia wadę. Limit ponowień zapobiega zużywaniu przez system nieograniczonych zasobów na rodzinę zadań o niskiej efektywności.
AutoSynthData następnie ocenia jakość całej partii. Przykłady poprawne indywidualnie mogą nadal tworzyć powtarzalny zbiór danych. Generator może nadmiernie produkować znane przepływy pracy, ignorując trudne kombinacje zasad, narzędzi lub stanów systemu.
Kontroler śledzi zaakceptowane i odrzucone próbki, powtarzające się wzorce, pokrycie możliwości oraz nawracające ustalenia krytyki. Ogranicza generowanie w nadreprezentowanych obszarach i przekierowuje wysiłek na luki. Tworzy to sprzężenie zwrotne ponad poziomem pojedynczego zadania.
Etapy target i multiply wspierają tę strategię. Próbki target ustanawiają zweryfikowane rodziny zadań wokół konkretnych luk w możliwościach. Próbki multiply zmieniają sformułowania, encje, kombinacje narzędzi i stany środowiska bez rekurencyjnego rozszerzania wcześniejszych wariantów.
Taka konstrukcja ogranicza jedno z powszechnych ryzyk danych syntetycznych. Generowanie rekurencyjne może powiększać drobne błędy, ponieważ każda nowa próbka dziedziczy założenia po innej wygenerowanej próbce. Zakotwiczenie wszystkich wariantów w sprawdzonych przykładach target ogranicza ten łańcuch.
To podejście daje przedsiębiorstwom również łatwiejszy do obrony ślad audytowy. Każdy przykład szkoleniowy można powiązać z jego stanem początkowym, zamierzoną sekwencją działań, weryfikatorem i wynikiem walidacji. Jest to bardziej użyteczne niż folder zawierający prompty bez wykonywalnego kontekstu.
Jednak deterministyczne kontrole nie potrafią zakodować każdego istotnego wymiaru jakości. Końcowy stan bazy danych może wyglądać poprawnie, nawet jeśli agent po drodze ujawnił wrażliwe informacje. Inna trajektoria może wprowadzić niepotrzebne zmiany przed przywróceniem oczekiwanego stanu.
Nadal potrzebne są dzienniki wykonania i kontrole uwzględniające zasady. Własne narzędzia ServiceNow do oceny agentów podkreślają znaczenie zbiorów danych, zapisów wykonania i wielu wymiarów jakości. AutoSynthData rozszerza tę filozofię na produkcję danych szkoleniowych.
Mechanizm zależy również od nauczyciela. Silniejszy model może demonstrować skuteczne zachowanie, lecz jego działania nadal odzwierciedlają dostępne narzędzia i zakodowane zasady. Nauczyciel wybierający ryzykowny skrót może przenieść takie zachowanie do dostrajania nadzorowanego.
Rodzą się tu pytania dotyczące zarządzania. Przedsiębiorstwa muszą wiedzieć, kto definiuje poprawne zachowanie, które zasady wdraża środowisko i jak są przeglądane zmiany weryfikatora. W przeciwnym razie automatyczne generowanie może skalować niezauważony błąd specyfikacji.
AutoSynthData: Generating Training Data for Enterprise Agents jest najsilniejsze jako argument za wykonywalnymi danymi. Generator przyciąga uwagę, lecz to środowisko i weryfikator budują znaczną część wiarygodności systemu. Bez nich syntetyczne zadania pozostają przekonującymi opowieściami, a nie potwierdzonymi przykładami szkoleniowymi.
Raportowane wzrosty są istotne, lecz nadal ograniczone
ServiceNow raportuje wyraźną poprawę wyników benchmarków, ale eksperymenty nie dowodzą niezawodności produkcyjnej ani szerokiej zdolności transferu.
W pierwszym eksperymencie jako model docelowy w domenie Hybrid EnterpriseOps Gym wykorzystano Gemma-4-26B-A4B-it. Rolę nauczyciela pełnił Qwen3.8-27B. AutoSynthData wygenerował 2 000 syntetycznych przykładów szkoleniowych w około 18 godzin.
ServiceNow dostroił Gemma za pomocą dostrajania nadzorowanego, które uczy model naśladowania udanych przykładów. Najlepszy raportowany punkt kontrolny pochodził z piątej epoki. Epoka oznacza jedno pełne przejście przez zbiór danych szkoleniowych.
Według firmy średni Pass@1 poprawił się o 7,2 punktu procentowego. ServiceNow określa tę zmianę jako 35% względnej poprawy. Skuteczność weryfikatora również wzrosła z 63,01% do 68,55%.
Firma twierdzi, że powstały punkt kontrolny zamknął 59% pierwotnej luki Pass@1 między Gemma a modelem referencyjnym. Wyniki te wskazują, że ukierunkowane przykłady syntetyczne wpłynęły na więcej niż jeden pomiar. Nie ujawniają jednak, jak model zachowywał się poza testowanym środowiskiem.
Drugi eksperyment koncentrował się na zarządzaniu usługami IT. Ponownie wykorzystano Gemma-4-26B-A4B-it jako model docelowy, podczas gdy DeepSeek-V4.1-Flash pełnił rolę nauczyciela. Potok wytworzył 1 994 zaakceptowane próbki w ciągu 66 godzin.
Średni Pass@1 wzrósł z 18,77% do 27,18% w ocenie ITSM. To wzrost o 8,41 punktu procentowego. Oznacza to również, że wytrenowany model nadal zawodzi przy większości pierwszych prób zgodnie z metodą punktacji benchmarku.
Ta pozostała luka jest istotnym kontekstem. Eksperyment potwierdza tezę, że ukierunkowane syntetyczne dostrajanie może poprawić model. Nie potwierdza tezy, że wynikowy agent jest gotowy do samodzielnego działania w systemach biznesowych.
ServiceNow twierdzi, że generator Hybrid nigdy nie otrzymał oryginalnych promptów ewaluacyjnych, encji, trajektorii ani szczegółów weryfikatora. Otrzymał specyfikacje możliwości wyprowadzone z zachowania podczas ewaluacji. To rozdzielenie ogranicza jedną oczywistą formę zanieczyszczenia zbioru testowego.
Program nauczania nadal wynikał jednak z porażek zaobserwowanych w EnterpriseOps Gym. Szkolenie i ewaluacja dzieliły zatem środowisko, strukturę narzędzi i ogólny rozkład zadań. Poprawa w tym środowisku nie dowodzi transferu do niepowiązanego oprogramowania ani prywatnych konfiguracji przedsiębiorstw.
Raportowane wartości pochodzą również od zespołu, który zaprojektował system. Niezależna replikacja wzmocniłaby wynik. Badacze potrzebowaliby wystarczającej ilości kodu, ustawień generowania, zaakceptowanych próbek i szczegółów ewaluacji, aby odtworzyć potok.
Artificial Analysis prowadzi obecnie niezależny ranking oparty na EnterpriseOps Gym. Jego ewaluacja także podkreśla znaczenie stanowych, wieloetapowych zadań oraz końcowych warunków bazy danych. Ten zewnętrzny mechanizm tworzy jedno możliwe miejsce do bardziej niezależnego testowania wytrenowanych punktów kontrolnych.
Ewaluacja między środowiskami byłaby jeszcze bardziej miarodajna. Model wytrenowany na jednej konfiguracji ITSM można byłoby testować wobec zmienionych zasad, przemianowanych narzędzi, zmodyfikowanych schematów i nieznanych rozkładów rekordów. Wyniki przy takich zmianach pokazałyby, czy model nauczył się danej możliwości, czy zapamiętał wzorzec środowiska.
Bezpieczeństwo również wymaga odrębnego pomiaru. ServiceNow opisał wcześniej 30 niewykonalnych zadań benchmarkowych obejmujących niedostępne zasoby, brakujące uprawnienia lub naruszenia zasad. Jego najsilniejszy testowany model podobno rozpoznał jako niewykonalne tylko około połowy z nich.
AutoSynthData mógłby celować w takie porażki, lecz obecna wersja nie przedstawia odrębnego wyniku bezpiecznego powstrzymywania się od działania. Poprawa realizacji zadań może tworzyć nowe zagrożenia, jeśli model staje się także bardziej skłonny do działania wtedy, gdy poprawną reakcją jest odmowa.
Relacja nauczyciel–model docelowy zasługuje na analizę. Eksperyment Hybrid wykorzystywał parę modeli o stosunkowo zbliżonych rozmiarach, podczas gdy w przebiegu ITSM zastosowano znacznie większego nauczyciela. Czas generowania znacząco się różnił, częściowo dlatego, że ServiceNow podaje, iż wcześniejszy przebieg ITSM poprzedzał optymalizacje przepustowości.
Różnice te utrudniają bezpośrednie porównania. Obie domeny obejmowały różnych nauczycieli, różne czasy przetwarzania i prawdopodobnie odmienne rozkłady możliwości. Dowody pokazują powtarzalność w dwóch ustawieniach, a nie kontrolowane badanie każdego komponentu systemu.
Brak badania ablacyjnego również ogranicza interpretację. Wyniki publiczne nie wyodrębniają, jaka część poprawy wynikała z kierowania się porażkami, demonstracji nauczyciela, filtrowania przez weryfikator, zwielokrotniania zadań czy równoważenia na poziomie partii. Każdy komponent brzmi wiarygodnie, ale ich odrębny wkład pozostaje niejasny.
Koszt i wykorzystanie zasobów to kolejna otwarta kwestia, nawet bez podawania wartości komercyjnych. Generowanie tysięcy zadań wymaga powtarzanych wywołań modeli, wykonywania w środowisku, prób rozwiązywania, krytyki, napraw i weryfikacji. Zaakceptowany zbiór danych przedstawia jedynie wynik, a nie całkowity nakład podjętej pracy.
Przedsiębiorstwa muszą porównać ten nakład z alternatywami. Przykłady tworzone przez ludzi mogą powstawać wolniej, ale być łatwiejsze do przeglądu. Zmiany w wyszukiwaniu i orkiestracji mogą naprawić niektóre problemy bez aktualizowania wag modelu.
Przepływ pracy może też zawodzić dlatego, że jego wiedza jest niekompletna, a nie dlatego, że modelowi brakuje zdolności rozumowania. Lepsze łączenie wiedzy może bardziej bezpośrednio rozwiązać niektóre luki. Szkolenie nie powinno stawać się domyślną odpowiedzią na każde nieudane uruchomienie agenta.
Ostrożna interpretacja nadal jest zachęcająca. AutoSynthData przyniósł mierzalne poprawy dzięki zadaniom dobranym wokół zaobserwowanych słabości. Silniejsze twierdzenie — że adaptacyjne syntetyczne programy nauczania uogólniają się na bezpieczniejszych agentów produkcyjnych — pozostaje nieudowodnione.
Trzy sygnały zdecydują, czy AutoSynthData ma znaczenie poza benchmarkiem
Kolejne dowody powinny wykazać odtwarzalność, transfer i bezpieczniejsze zachowanie, a nie jedynie kolejny wyższy wynik w pierwotnym środowisku.
Pierwszym sygnałem jest niezależnie odtwarzalne wydanie. ServiceNow opublikował materiały EnterpriseOps Gym, lecz badacze potrzebują implementacji AutoSynthData oraz pełnej receptury eksperymentalnej. Pakiet ten powinien obejmować konstrukcję kart możliwości, ustawienia generowania, testy weryfikatora, kryteria odrzucania i ewaluację punktów kontrolnych.
Niezależne zespoły powinny móc odtworzyć porównywalne zbiory danych na podstawie tych samych zdiagnozowanych porażek. Podobne poprawy w wielu uruchomieniach zmniejszyłyby obawy o korzystne próbkowanie. Publikacja statystyk odrzuconych zadań ujawniłaby również, jak dużo filtrowania wymagał końcowy zbiór danych.
Najsilniejsza wersja tego sygnału obejmowałaby ablacje. Badacze mogliby usuwać weryfikację negatywną, równoważenie partii, zwielokrotnianie lub kierowanie się porażkami — po jednym komponencie naraz. Wynikowe różnice wydajności wskazałyby, które mechanizmy zapewniają poprawę.
Jeśli niezależna replikacja powiedzie się, wzmocni główne twierdzenie techniczne ServiceNow. Jeśli wzrosty będą znacząco różnić się między uruchomieniami, wynik zasugeruje, że potok pozostaje wrażliwy na generatory, nauczycieli lub wybory selekcyjne.
Drugim sygnałem jest transfer między środowiskami. Wytrenowany model powinien zmierzyć się z przepływami pracy, które zachowują podstawową możliwość, jednocześnie zmieniając narzędzia, encje, zasady i schematy. Taki test odróżni ogólne uczenie się od znajomości struktury EnterpriseOps Gym.
Przydatny eksperyment mógłby polegać na szkoleniu w jednym środowisku ITSM i ewaluacji w innym bez dodatkowego dostrajania. Inny mógłby przejść od przepływu pracy w jednej domenie do zadania międzydomenowego wymagającego danych klientów, pracowników i zasobów.
Przedsiębiorstwa powinny również zwracać uwagę na adaptery wykraczające poza systemy zorientowane na ServiceNow. Architektura kontrolera i adapterów AutoSynthData sugeruje przenośność, lecz projekt oprogramowania nie gwarantuje praktycznej kompatybilności. Każde nowe środowisko wymaga wykonywalnych działań i niezawodnej weryfikacji.
Pomyślne wyniki na różnych platformach sprawiłyby, że metoda byłaby istotna dla znacznie szerszego rynku agentów. Słaby transfer ograniczyłby jej rolę do wydajnego procesu dostosowywania dla ściśle określonych środowisk.
Trzecim sygnałem będzie to, czy realizacja zadań poprawia się bez osłabiania odmowy działania i zgodności z zasadami. Agent przedsiębiorstwa musi wiedzieć, kiedy nie powinien działać. Wyższe wyniki Pass@1 nie wystarczą, jeśli szkolenie zachęca do pewnego wykonywania działań przy braku uprawnień lub sprzecznych instrukcjach.
Przyszłe oceny powinny raportować wykrywanie niewykonalnych zadań, nieautoryzowane zmiany stanu, naruszenia zasad i niepotrzebne wywołania narzędzi. Powinny też analizować działania pośrednie, a nie tylko końcowe stany bazy danych. Przywrócony stan końcowy może ukryć niebezpieczną sekwencję.
W przypadku procesów o dużym wpływie kontrola człowieka pozostaje ważna. Recenzenci powinni badać próbki dotyczące akt pracowników, kontroli dostępu, uprawnień klientów, incydentów bezpieczeństwa i nieodwracalnych zmian. Automatyczne weryfikatory mogą wspierać ten proces, lecz nie powinny definiować zasad bez odpowiedzialnego nadzoru.
Najbliższe od jednego do trzech miesięcy powinny zatem przynieść trzy konkretne rodzaje dowodów: działający kod potoku, testy między środowiskami oraz wyniki dotyczące konkretnie bezpieczeństwa. Każdy z nich odniósłby się do innej niepewności obecnej w aktualnej publikacji.
AutoSynthData: Generating Training Data for Enterprise Agents przedstawia wiarygodny mechanizm przekształcania niepowodzeń ewaluacji w ukierunkowaną praktykę. Zgłoszone przez autorów korzyści pokazują, że pomysł zasługuje na uwagę, zwłaszcza ze strony zespołów dysponujących środowiskami do wykonywania procesów.
Szersza decyzja należy teraz do twórców korporacyjnych rozwiązań AI. Powinni zapytać, czy własne błędy ich agentów da się wyrazić jako odtwarzalne stany, prawidłowe trajektorie i testowalne wyniki. Jeśli nie, generowanie większej liczby zadań jedynie zwiększy skalę niejednoznaczności.
Jeśli te fundamenty istnieją, adaptacyjny program nauczania może uczynić ewaluację znacznie bardziej użyteczną. Może pokazać, co zawiodło, wygenerować ukierunkowane szkolenie i zmierzyć, czy ta sama słabość nadal występuje. Kolejny dowód musi wykazać, że ta pętla działa również poza środowiskiem, które ją stworzyło.
