AutoSynthData premieňa zlyhania podnikových AI agentov na overené tréningové úlohy
ServiceNow CoreAI predstavil postup, ktorý z konkrétnych zlyhaní agenta vytvára nové tréningové úlohy, kontroluje ich vykonateľnosť a priebežne upravuje učebný plán modelu.
Za text zodpovedá Redakcia AI Feed. Zodpovedný editor: Marek Považský. Ako používame AI.
- Typ zdroja
- Oficiálny zdroj
- Zdroj / autorita
- ServiceNow CoreAI
Ako vznikol tento text
Redakcia spracovala verejné podklady do slovenského kontextu. Za výber, pravidlá kvality a prípadné opravy zodpovedá Marek Považský.
Text je zaradený v sekcii AI výskum a opiera sa o 3 zdroje. Konkrétne odkazy sú uvedené pod článkom; podrobnosti o AI postupe vysvetľuje metodika redakcie.
Podnikový AI agent môže uspieť vo všeobecných testoch a napriek tomu zlyhávať pri práci s konkrétnym ticketovacím systémom, databázou alebo internými pravidlami. ServiceNow CoreAI preto predstavil AutoSynthData, postup na tvorbu syntetických tréningových úloh odvodených od pozorovaných slabín cieľového modelu. Namiesto generovania veľkého množstva všeobecných inštrukcií vyhodnocuje, ktoré pracovné postupy agent nezvláda, porovnáva jeho výsledky so silnejším učiteľským modelom a vytvára nové, odlišné úlohy zamerané na rovnakú schopnosť. Každá úloha musí byť vykonateľná v príslušnom prostredí a obsahovať kontrolu výsledného stavu.
Novinka reaguje na praktický problém podnikových agentov: ich výkon neurčuje iba kvalita jazykového modelu, ale aj schopnosť správne kombinovať nástroje, rešpektovať oprávnenia a doviesť viacstupňový proces do požadovaného stavu. Jedno zlyhanie však samo osebe neposkytuje dostatok materiálu na ďalší tréning. AutoSynthData sa ho snaží premeniť na širšiu rodinu realistických príkladov bez kopírovania pôvodnej hodnotiacej úlohy. Autori postup demonštrujú v prostredí EnterpriseOps Gym, ktoré zahŕňa stavové podnikové scenáre z oblastí IT, ľudských zdrojov, CRM, kalendárov, e-mailu a tímovej spolupráce.
Od diagnózy k novému učivu
Základom pipeline je diagnostické vyhodnotenie cieľového modelu a silnejšieho učiteľa. Systém sleduje, akú schopnosť úloha preveruje, ktoré nástroje treba použiť, kde slabší model zlyhal, ako postupoval učiteľ a aké vlastnosti musí mať správny konečný stav. Tieto zistenia zapisuje do takzvaných kariet špecifikácie schopnosti. Generátor pritom podľa autorov nedostáva pôvodné zadania, entity, trajektórie ani podrobnosti verifikátorov. Má vytvárať nové situácie s inými formuláciami, počiatočnými stavmi a cestami k riešeniu, nie memorovať testovaciu množinu.
Takto pripravená úloha pozostáva zo systémovej špecifikácie, požiadavky používateľa a verifikátora. Systémová časť určuje dostupné nástroje, pravidlá a počiatočný stav prostredia. Používateľské zadanie musí byť uskutočniteľné, realistické a dostatočne náročné pre aktuálny model. Verifikátor následne nehodnotí iba text odpovede, ale kontroluje, či agent vykonal požadované zmeny v stave systému. Mal by odmietnuť chybné výsledky, no zároveň uznať rôzne platné postupy, namiesto presadzovania jedinej referenčnej trajektórie.
AutoSynthData najskôr vytvára jadro nových vzoriek vo fáze označenej ako Target. Kandidáti prechádzajú validáciou, spustením v prostredí, hodnotením riešiteľom a prípadnou opravou. Vo fáze Multiply potom z prijatých vzoriek vznikajú varianty s novými entitami, nástrojmi, formuláciami, stavmi a úrovňami náročnosti. Variant však nemôže slúžiť ako základ ďalšieho variantu. Toto obmedzenie má tlmiť postupný odklon od pôvodnej, už overenej schopnosti, ktorý je pri reťazovom generovaní syntetických dát častým rizikom.
Overovanie je dôležitejšie než samotné generovanie
Najpodstatnejšou časťou návrhu nie je jazykový generátor, ale séria kontrol. Referenčná trajektória sa reálne vykoná a jej výsledok sa porovná s verifikátorom. Pozitívna skúška zisťuje, či zamýšľané riešenie skutočne splní úlohu. Negatívna skúška mení očakávaný výsledok a preveruje, či ho verifikátor správne odmietne. Ak kandidát neprejde, kritik má určiť, či je problém v nekonzistentnom stave, nemožnom pracovnom postupe, chybnej trajektórii alebo príliš slabom kontrolnom pravidle. Opravy majú obmedzený počet opakovaní a po každej sa kontroly spúšťajú znova.
Pri experimentoch autori uprednostňovali úlohy, ktoré cieľový model vyriešil najviac v jednom z troch pokusov, zatiaľ čo silnejší riešiteľ uspel aspoň v dvoch z troch. Ide o praktický filter: príliš ľahké príklady neprinášajú veľa nového tréningového signálu a úlohy, ktoré nezvládne ani učiteľ, môžu byť chybné alebo nevykonateľné. Pipeline navyše hodnotí celé dávky dát. Sleduje opakovanie rovnakých rodín úloh, chýbajúce dimenzie schopností a pomer medzi úsilím generátora a počtom prijatých vzoriek. Platná jednotlivá úloha totiž ešte nezaručuje rozmanitý a užitočný dataset.
Tento prístup je zaujímavý aj z bezpečnostného hľadiska. Agentické dáta neobsahujú iba otázku a odpoveď, ale tiež nástroje, oprávnenia, stav databázy a očakávané vedľajšie účinky. Slabý verifikátor môže odmeniť agenta, ktorý síce vytvorí presvedčivú odpoveď, ale nevykoná požadovanú operáciu alebo poruší obmedzenie. Príliš úzky verifikátor môže naopak penalizovať správne alternatívne riešenie. AutoSynthData tento problém neodstraňuje automaticky, no robí kvalitu verifikátora explicitnou súčasťou dátovej pipeline a testuje ho aj na zámerne nesprávnych stavoch.
Výsledky ukazujú prínos, nie univerzálny recept
V hybridnej časti EnterpriseOps Gym zvýšil syntetický supervised fine-tuning priemerné Pass@1 o 7,2 percentuálneho bodu, čo autori vyjadrujú ako 35-percentné relatívne zlepšenie. Úspešnosť podľa verifikátorov vzrástla zo 63,01 na 68,55 percenta a experiment uzavrel 59 percent pôvodného rozdielu medzi cieľovým modelom Gemma a referenčným modelom. V samostatnej doméne ITSM pipeline vytvorila 1 994 tréningových vzoriek za 66 hodín a priemerné Pass@1 sa zvýšilo z 18,77 na 27,18 percenta.
Čísla treba čítať v hraniciach experimentu. Pochádzajú od tvorcov metódy, z kontrolovaného prostredia EnterpriseOps Gym a zatiaľ nepredstavujú nezávislú replikáciu v reálnej podnikovej prevádzke. Benchmark síce používa stavové aplikácie, viac nástrojov a deterministické kontroly, no produkčné systémy prinášajú meniace sa API, neúplné údaje, komplikovanejšie oprávnenia a následky, ktoré nemožno vždy bezpečne opakovať. Zverejnené výsledky preto dokazujú zlepšenie v skúmaných doménach, nie všeobecnú schopnosť automaticky opraviť ľubovoľného agenta.
Čo to znamená pre podnikové tímy
Pre firmy je dôležitý najmä posun od všeobecného dolaďovania k uzavretému cyklu okolo vlastného prostredia. Logy neúspešných behov môžu ukázať, ktoré kombinácie nástrojov, pravidiel a stavov spôsobujú problémy. Po sanitizácii sa z nich dajú odvodiť nové tréningové scenáre, tie spustiť v izolovanom prostredí a prijať iba vtedy, keď je možné jednoznačne overiť výsledok. Po ďalšom vyhodnotení sa učebný plán zameria na slabiny, ktoré zostali. Takýto cyklus môže byť hodnotnejší než neustále pridávanie všeobecných dát bez väzby na konkrétnu prácu agenta.
Nasadenie však bude vyžadovať viac než silný model. Tímy potrebujú reprodukovateľné testovacie prostredia, bezpečné počiatočné stavy, presné verifikátory, evidenciu verzií nástrojov a oddelenie tréningových príkladov od produkčných tajomstiev. Osobitne treba kontrolovať, či generované úlohy nepreberajú citlivé entity alebo škodlivé vzory z prevádzkových záznamov. Náklady na učiteľský model, opakované spúšťanie a opravy môžu byť významné; údaj o 66 hodinách pri ITSM zároveň ukazuje, že nejde o bezplatnú výrobu dát.
Otvorenou otázkou zostáva, ako dobre sa zlepšenie prenesie medzi verziami podnikových aplikácií, rôznymi modelmi a procesmi, pri ktorých sa úspech nedá vyjadriť databázovým stavom. Nie je tiež jasné, akú časť výsledku priniesol výber úloh, kvalita učiteľa, samotný supervised fine-tuning alebo konkrétne verifikátory. AutoSynthData napriek tomu pomenúva presvedčivý smer: pri agentoch nestačí generovať viac dát. Treba generovať dáta o správnych slabinách, vykonať ich v realistickom prostredí a overiť, že učia správanie, ktoré organizácia skutočne potrebuje.
Zdroje