AutoSynthData de la ServiceNow transformă eșecurile agenților în aur pentru instruire

Răspuns scurt: AutoSynthData de la ServiceNow CoreAI transformă eșecurile agenților și succesele profesorilor în sarcini SFT sintetice validate atunci când întreprinderile au nevoie de competență în mediu, nu doar de scoruri generale de referință. Acesta sanitizează lacunele în fișe cu specificații de capabilitate, multiplică munca verificabilă, apoi controlează calitatea înainte de reglajele fine. Conform autorului, creșterea performanței EnterpriseOps Gym este valabilă dacă forța profesorilor, calitatea verificatorului și fidelitatea mediului se aliniază.

Concluzii cheie:

Carduri de capabilitate: Igienizați defecțiunile în carduri, astfel încât generatorii să nu vadă niciodată ID-urile originale.

Auditabilitatea verificatorului: Preferă verificările SQL la starea finală care resping rezultatele greșite mutate.

Nivel de dificultate: Antrenează doar sarcinile pe care ținta le rezolvă rar și pe care profesorul le elimină de obicei.

Revizuire umană: Mențineți revizuirea umană a politicilor cu miză mare și a acțiunilor ireversibile înainte de recalificare.

Frontieră în mișcare: După SFT, reevaluați și mutați faza țintă către decalajele rămase.

Agenții de inteligență artificială pentru întreprinderi rareori eșuează din cauza lipsei de cunoștințe generale. Eșuează deoarece mediul este specific: politici de tichete, particularități ale schemei, contracte de instrumente, baze de date inițiale, articole de cunoștințe și fluxuri de lucru intersisteme care nu arată ca demonstrații din manuale. Un model care obține scoruri bune la testele de performanță deschise se poate bloca totuși atunci când următorul pas trebuie să respecte o fereastră de modificare, o relație CMDB sau un verificator care verifică starea finală în loc de un chat fluent.

ServiceNow CoreAI / ServiceNow-AI a publicat AutoSynthData pentru a aborda direct această lacună. Autorul numit Esakkivel Esakkiraja descrie o conductă care convertește eșecurile unui agent țintă - împreună cu succesele mai bune ale unui profesor - în sarcini de instruire sintetice validate, adaptate mediilor de întreprindere. Ideea nu este de a colecta mai multe jurnale de chat. Ci de a multiplica munca dificilă, verificabilă, care exercită aceeași capacitate în condiții noi, astfel încât reglajele fine supravegheate să poată închide lacunele specifice mediului.

Acest articol prezintă ideea centrală, abstractizarea sarcinilor, bucla de generare și control al calității, arhitectura partajată și rezultatele raportate de autori privind EnterpriseOps Gym în contexte hibride și ITSM. Se bazează pe ceea ce descrie cercetarea: o programă mobilă de sarcini sintetice, nu pe afirmația că o problemă a unei întreprinderi este rezolvată brusc.

De ce competența de mediu depășește capacitatea generală

Întreprinderile au nevoie de agenți care să lucreze în mediul lor - în sistemele, regulile și starea datelor lor. Capacitatea extinsă nu este același lucru cu competența în mediu. Un agent poate ști cum funcționează de obicei managementul serviciilor IT și totuși să nu înțeleagă politica locală care interzice anumite tranziții sau instrumentul care actualizează un tabel aferent numai după ce există o înregistrare prealabilă.

Eșecurile individuale sunt informative, dar insuficiente ca datele de antrenament. O traiectorie întreruptă arată o slăbiciune; nu oferă zecile de situații apropiate care ar învăța modelul să se recupereze în condiții de variație. Echipele au nevoie de multe sarcini noi care exersează aceeași capacitate în mod diferit, rămân finalizabile în cadrul mediului, par realiste pe măsură ce utilizatorul solicită și rămân verificabile în funcție de verificările rezultatelor.

Aceasta este presiunea de proiectare din spatele AutoSynthData. Eșecurile devin semnale pentru fișele de capabilitate. Fișele devin generatoare de noi sarcini. Un profesor mai puternic demonstrează traiectorii de succes. Filtrele și verificatorii decid ce intră în setul de reglaje fine supravegheate. După antrenament, evaluarea deplasează frontiera către lacunele rămase. Bucla este în formă de curriculum, mai degrabă decât o descărcare de date unică.

Încadrarea este importantă pentru practicieni. Dacă stocați doar solicitările eșuate, riscați să supraadaptați la acele entități și formulări exacte. Dacă generați doar solicitări sintetice neconstrânse, riscați sarcini imposibile, nerealiste sau neverificabile. AutoSynthData se situează între aceste extreme: curăță ceea ce a eșuat într-o specificație de capabilitate, apoi regenerează sarcini care păstrează nucleul dur, modificând în același timp forma suprafeței și dimensiunile controlabile.

Forma practică a sarcinii: sistem, prompt, verificator

O abstracție fezabilă pentru munca agentială este: sarcina este egală cu specificația sistemului, promptul utilizatorului și verificatorul. Fiecare element poartă constrângeri care mențin datele sintetice fundamentate și demne de încredere.

Specificațiile sistemului acoperă constrângeri, politici și starea inițială - de exemplu, elementele inițiale ale bazei de date și articolele de cunoștințe. Trebuie să rămână compatibile cu instrumentele și starea disponibile. Constrângerile de dificultate arbitrare care ignoră contractele instrumentelor sau realismul elementelor inițiale tind să creeze sarcini fragile care predau lecții greșite.

Calitatea solicitărilor utilizatorului are trei perspective. Fezabilitatea se întreabă dacă există o traiectorie validă. Realismul se întreabă dacă un utilizator ar solicita în mod plauzibil acest lucru. Dificultatea se întreabă dacă sarcina expune o slăbiciune actuală a agentului, mai degrabă decât ceva ce ținta rezolvă deja în mod fiabil. O solicitare banală pentru țintă irosește bugetul de instruire; o solicitare imposibilă irosește încrederea în evaluare.

Calitatea verificatorului depinde de consecvență, soliditate și caracter complet. Traiectoriile prea laxe și slabe sunt acceptate. Soluțiile prea restrictive la o singură traiectorie și alternative valide eșuează. Configurațiile întreprinderilor preferă adesea verificările rezultatelor bazate pe SQL sau pe stări, deoarece acestea clasifică lumea după ce agentul acționează, nu calea exactă a token-ului parcursă de agent.

AutoSynthData se bazează pe această triadă, astfel încât munca generată să rămână ancorată. Generatoarele nu inventează teste libere. Ele produc sarcini care pot fi executate în adaptorul de mediu și evaluate de verificatori care țin cont de proprietățile stării finale necesare.

De la evaluarea diagnostică la carduri cu specificații de capabilitate

Canalul de lucru începe cu evaluarea diagnostică a agentului țintă și a unui profesor mai puternic din mediul înconjurător. Evaluările comparative dezvăluie unde eșuează ținta și unde are succes profesorul. Aceste cazuri comparative reprezintă materia primă pentru proiectarea curriculumului.

Urmează distilarea în fișe de specificații de capabilități igienizate. O fișă surprinde capacitatea testată, instrumentele relevante sau forma fluxului de lucru, unde ținta eșuează și profesorul reușește, proprietățile stării finale necesare și dimensiunile care pot varia atunci când sunt inventate sarcini noi. Este esențial faptul că generatorul nu primește solicitări originale, entități, traiectorii sau detalii despre verificator - doar fișele.

Această igienizare este o mișcare deliberată împotriva supraadaptării. Dacă generatorul ar vedea exact numerele tichetelor de eroare, ID-urile articolelor de cunoștințe sau urmele profesorilor, ar fi tentat să parafrazeze același episod. Fișele forțează abstractizarea: predați capacitatea sub variație controlabilă, nu în instanța memorată.

După ce există fișe, sistemul generează noi sarcini pe baza acestora. Profesorul demonstrează apoi traiectorii de succes pentru reglaje fine supravegheate. Aceste demonstrații nu sunt sfaturi simple; sunt succese bazate pe mediu care trec același tip de verificare de care este preocupată programa școlară.

Structura are două faze. Faza țintă se concentrează pe eșantioanele de bază verificate din jurul lacunelor - sarcinile cu cel mai mare semnal din apropierea locului unde agentul slab se rupe. Faza de multiplicare creează variante noi ale țintelor acceptate. Eșantioanele multiplicate nu pot genera runde de multiplicare suplimentare, ceea ce limitează deriva. Această regulă este mică, dar importantă: variația recursivă nelimitată se poate îndepărta de capacitatea menționată de card.

Controler partajat, adaptor de mediu și frontiera în mișcare

Din punct de vedere arhitectural, AutoSynthData utilizează un controler partajat plus un adaptor de mediu. Controlerul orchestrează diagnosticarea, cardarea, generarea, demonstrațiile profesorilor, porțile de calitate și revizuirea în loturi. Adaptorul conectează acești pași la un sandbox concret al întreprinderii - instrumente, stare, politici și verificatori - astfel încât aceeași buclă de control poate viza domenii diferite fără a rescrie logica curriculumului de la zero.

După reglajul fin supravegheat, procesul de învățare este reevaluat. Programa se îndreaptă apoi către lacunele rămase: o frontieră mobilă, mai degrabă decât un set de date static. Experimentele descrise în lucrare se concentrează pe reglajul fin supravegheat. Aceeași buclă ar putea susține învățarea prin consolidare ulterior; acea direcție este notată ca fiind planificată, nu declarată ca fiind finalizată.

Pentru echipele din mediul de afaceri, lecția arhitecturală este modulară. Controlerele nu ar trebui să codifice hardcode-ul unei scheme de tichet. Adaptoarele ar trebui să expună suficientă fidelitate a stărilor și instrumentelor pentru ca verificatorii să poată fi semnificativi. Programa de învățământ ar trebui să trateze rezultatele evaluării ca următoarea intrare, nu ca un tablou de bord unic.

EnterpriseOps Gym este mediul în care a fost ilustrată această abordare. Este un banc de agenți la scară largă, cu aproximativ 1.150 de sarcini selectate de experți în 8 domenii, aproximativ 512 instrumente, aproximativ 164 de tabele de baze de date, execuție containerizată, verificare a rezultatelor bazată pe SQL, operațiuni guvernate de politici, scenarii hibride între domenii, testare a nefezabilității și a refuzului și traiectorii stateful pe orizont lung. AutoSynthData nu este prezentat ca inventator al acelui banc de lucru; bancul de lucru este platforma de testare la stres pentru bucla de sinteză.

Controlul calității la nivel de probă care menține sarcinile sintetice fiabile

Generarea fără porți este modul în care datele despre agenții sintetici dau greș. AutoSynthData descrie controlul calității la nivel de eșantion cu mai multe verificări complementare.

Un filtru de dificultate al rezolvitorului direcționează setul către sarcini dificile pentru țintă și rezolvabile pentru profesor. Configurația descrisă favorizează sarcinile pe care ținta le rezolvă în cel mult una din trei încercări, în timp ce profesorul reușește în cel puțin două din trei. Această bandă este cea în care demonstrațiile supervizate pot preda ceva ce modelul slab nu deține deja.

Verificarea pozitivă necesită ca o traiectorie de referință să treacă de verificator. Verificarea negativă necesită ca rezultatele greșite mutate să eșueze. Împreună, acestea testează sub presiune atât partea de acceptare, cât și cea de respingere a verificatorului. Dacă sunt verificate doar rezultatele pozitive, un verificator permisiv poate admite erori. Dacă sunt verificate doar rezultatele negative, un verificator prea strict poate respinge o lucrare validă.

O buclă de critică și reparare, cu o limită de reîncercări, încearcă să remedieze sarcinile care eșuează la porți, în loc să elimine imediat fiecare situație la limită. Limitele de reîncercări contează: repararea la nesfârșit poate inventa constrângeri din ce în ce mai artificiale doar pentru a trece o listă de verificare.

Meta-revizuirea la nivel de lot analizează apoi setul pentru acoperire, diversitate, redundanță și ținte eșuate. Porțile de eșantionare mențin elementele individuale solide; revizuirea la nivel de lot împiedică gruparea curriculumului pe un singur mod de eșec restrâns sau clonarea duplicatelor aproape identice.

Aceste controale explică de ce fluxul de lucru poate petrece ore întregi producând mii de eșantioane fără a trata volumul ca substitut pentru potrivire. Viteza diferă în funcție de domeniu și de mărimea profesorului, dar povestea QC este consistentă: bandă de dificultate, verificare pozitivă și negativă, reparare cu limite, apoi meta-revizuire.

Eșecuri brute vs. carduri vs. seturi SFT validate

Ajută la compararea scopurilor fiecărui artefact. Jurnalele brute de defecțiuni sunt de diagnosticare. Fișele de capabilitate sunt contracte generative. Seturile de reglaje fine supervizate validate sunt cele cu care te antrenezi în practică.

În instantaneele Hybrid și ITSM de pe EnterpriseOps Gym, rulările raportate de autori au folosit Gemma-4-26B-A4B-it ca țintă. Hybrid a asociat această țintă cu Qwen3.8-27B ca profesor și a produs aproximativ 2.000 de eșantioane hibride în aproximativ 18 ore, cu cel mai bun punct de control la epoca 5. Rata medie de Pass@1 a crescut cu 7,2 puncte procentuale - aproximativ 35% relativ - succesul verificatorului trecând de la 63,01% la 68,55%, închizând cu aproximativ 59% decalajul Pass@1 față de modelul de referință.

ITSM a asociat aceeași țintă cu DeepSeek-V4.1-Flash ca profesor și a produs aproximativ 1.994 de eșantioane în aproximativ 66 de ore, un timp mai lung parțial datorită unui profesor mai mare și pentru că unele optimizări ale pipeline-ului nu erau încă implementate. Rata medie de trecere la 1 a crescut de la 18,77% la 27,18%.

Citiți aceste cifre ca rezultate ale cercetărilor companiei asupra acestei săli de sport pentru domeniile testate - nu ca o replicare independentă a unei terțe părți și nu ca o garanție universală a companiei. Câștigurile se manifestă acolo unde puterea profesorului, calitatea verificatorului și fidelitatea mediului se aliniază.

Ce ar trebui practicienii să copieze din buclă

Chiar dacă stiva ta nu este canalul de cercetare ServiceNow, tiparul se transferă. Începe cu evaluarea pereche a unei ținte de tip producție și a unui profesor mai puternic într-un sandbox fidel. Convertește eșecurile de contrast în fișe de capabilitate care elimină identificatorii și traiectoriile. Genera sarcini care variază dimensiunile permise, păstrând în același timp proprietățile stării finale necesare. Roagă profesorul să demonstreze succesele. Ține cont de benzi de dificultate, verificare pozitivă și negativă, reparații limitate și revizuire a diversității în loturi. Ajustează fin, reevaluează și deplasează frontiera.

Acordați o atenție deosebită designului verificatorului. Verificările rezultatelor SQL în stil EnterpriseOps Gym și operațiunile guvernate de politici ilustrează de ce rubricile de chat în sine sunt slabe pentru lucrul cu stări. Dacă verificatorul dvs. nu poate distinge rezultatele greșite mutate de rezultatele finale corecte, scalarea sintetică va amplifica zgomotul.

De asemenea, respectați spiritul regulilor multiple: variantele țintelor acceptate nu ar trebui să genereze la nesfârșit mai multe variante fără a reveni la nuclee verificate. Deriva este silențioasă. O programă de învățământ care inventează încet constrângeri mai exotice poate totuși să treacă de filtre superficiale, lăsând în același timp capacitatea originală subantrenată.

În cele din urmă, tratați munca hibridă inter-domenii ca pe un caz de stres de primă clasă. Utilizatorii de zi cu zi nu rămân într-un singur siloz de instrumente. Sarcinile hibride, traiectoriile pe orizont lung și testarea refuzului sau a nefezabilității sunt domeniile în care competența mediului apare - sau eșuează zgomotos.

Avertismente, limite și o analiză atentă a câștigurilor

Rezultatele raportate de autori pe EnterpriseOps Gym sunt semnale informative, nu o garanție generală. Câștigurile publicate pentru hibrid și ITSM se aplică acelor domenii și asocieri de modele în configurația descrisă. Alte domenii, profesori mai slabi, verificatori mai zgomotoși sau fidelitate mai mică a mediului pot reduce sau elimina beneficiul.

Calitatea depinde de trei piloni pe care nicio glosă de marketing nu îi poate omite. Forța profesorului stabilește plafonul demonstrațiilor. Calitatea verificatorului stabilește credibilitatea etichetelor și filtrelor. Fidelitatea mediului stabilește dacă comportamentele învățate supraviețuiesc contactului cu sistemele de producție, regulile și starea datelor.

Experimentele AutoSynthData pun accent pe reglajul fin supravegheat. În lucrarea raportată, învățarea prin consolidare este menționată ca o posibilă utilizare ulterioară a aceleiași bucle, planificată mai degrabă decât livrată. Cititorii nu ar trebui să confunde un motor de date pregătit pentru curriculum cu o afirmație de instruire RL finalizată.

Cititorii nu ar trebui să confunde fluxul de sinteză cu platformele de lucru în sine. EnterpriseOps Gym oferă sarcinile, instrumentele, tabelele, containerizarea și structura de verificare selectate. AutoSynthData folosește acest tip de mediu pentru a transforma eșecurile în resurse utile pentru antrenament. Acordați credit ambelor aspecte cu exactitate: agenții de stres din sala de sport; fluxul de sinteză multiplică sarcinile care pot fi învățate din lacunele diagnosticate.

De asemenea, nu există programări gratuite pentru timpul de calcul și calendaristic în cadrul sandbox-ului. Sinteza hibridă s-a finalizat în aproximativ ore pentru aproximativ două mii de eșantioane; ITSM a durat mai mult cu un profesor mai complex și o formă mai timpurie a pipeline-ului. Echipele ar trebui să prevadă un buget pentru inferențele profesorului, reîncercările de critică sau reparare și reevaluarea după fiecare etapă a curriculumului.

Gândire curriculară pentru echipele de agenți din cadrul întreprinderilor

Cea mai profundă idee din AutoSynthData este curriculară, mai degrabă decât pur generativă. Eșecurile diagnostichează. Fișele abstractizează. Generarea multiplică. Controlul calității validează. SFT actualizează ținta. Reevaluarea mută frontiera. Această secvență tratează îmbunătățirea agenților ca o serie de lecții bazate pe mediu, în loc de o singură descărcare offline de urme.

Gândirea curriculară schimbă modul în care liderii alocă efortul. În loc să ceri doar mai multe tichete sau mai multe adnotări umane, întreabă-te ce capacități încă eșuează în variație, dacă aceste capacități au proprietăți curate ale stării finale și dacă un profesor mai puternic le poate demonstra în mod fiabil. Dacă profesorul nu poate reuși suficient de des, SFT-ul sintetic va învăța un comportament nesigur. Dacă proprietățile stării finale sunt imprecise, verificatorii se vor certa cu strategiile valide.

De asemenea, schimbă modul în care vorbești despre succes. Închiderea unei părți a decalajului Pass@1 față de un model de referință pe Hybrid sau ridicarea ITSM Pass@1 de la peste 100% la peste 20% în rundele raportate de autori reprezintă un progres în ceea ce privește competența de mediu măsurată. Nu este o dovadă că fiecare flux de lucru, fiecare politică sau fiecare caz de refuz este rezolvat. Păstrează limbajul frontierei mobile: decalajele rămase devin următoarea fază țintă, nu o diapozitivă ulterioară.

Pentru proiectarea programului, asociați această buclă cu revizuirea umană acolo unde mizele sunt mari - politici de siguranță, acțiuni ireversibile, date reglementate - permițând în același timp porților automate să suporte volumul de informații prin verificări de stare bine specificate. Datele sintetice funcționează cel mai bine atunci când mediul poate spune da sau nu cu o claritate similară SQL. Se confruntă cu dificultăți atunci când succesul este o preferință subiectivă.

Note de design privind dificultatea, realismul și refuzul

Direcționarea în funcție de dificultate merită o a doua analiză. Favorizarea sarcinilor pe care ținta le rezolvă în cel mult o treime din cazuri împiedică antrenamentul să se bazeze pe detalii. Solicitarea ca profesorul să reușească cel puțin două treimi din cazuri împiedică demonstrațiile să arunce monede. Această limită reprezintă un compromis practic între provocare și ușurință în învățare.

Realismul rămâne un criteriu mai puțin strict, dar totuși esențial. Utilizatorii din mediul enterprise cer lucruri care se potrivesc rolurilor și sistemelor lor. Generatoarele ghidate doar de duritate pot inventa puzzle-uri elaborate cu constrângeri multiple pe care niciun operator nu le-ar solicita. Fișele de capabilități care listează dimensiuni variabile ajută, însă oamenii sau meta-revizuitorii trebuie să surprindă în continuare solicitările suprarealiste.

Testarea refuzului și a nefezabilității, prezentă în designul mai larg al EnterpriseOps Gym, reamintește echipelor că a spune nu este o competență. O conductă optimizată doar pentru sarcini finalizabile poate sub-antrena refuzul. Atunci când extindeți bucle în stil AutoSynthData, includeți carduri în care proprietatea finală corectă este o refuzare sigură conform politicii, nu doar o mutație reușită a stării bazei de date.

Traiectoriile cu stări pe orizont lung ridică o altă notă de design. Demonstrațiile pentru profesori trebuie să rămână coerente pe parcursul mai multor apeluri de instrumente. Verificatorii care verifică doar ultimul rând din tabel pot rata întreruperi de politici intermediare. Completitudinea în proiectarea verificatorilor înseamnă acoperirea proprietăților care definesc cu adevărat succesul pentru acea capacitate - inclusiv constrângerile care trebuie să rămână adevărate pe tot parcursul, nu doar la final.

Rezumatul final

AutoSynthData, de la ServiceNow CoreAI / ServiceNow-AI și scrisă în articolul public de Esakkivel Esakkiraja, este o pipeline care transformă eșecurile agenților țintă plus succesele profesorilor în sarcini de antrenament sintetice validate pentru medii enterprise. Aceasta abstractizează eșecurile în fișe de specificații de capabilități igienizate, generează sarcini noi fără a divulga prompturi sau traiectorii originale, colectează demonstrații ale profesorilor și impune controlul calității la nivel de eșantion și lot înainte de reglajul fin supravegheat.

Modelul mental practic este o sarcină ca specificație de sistem, prompt pentru utilizator și verificator - cu fezabilitate, realism și dificultate ținute în tensiune și cu verificatori care nu sunt nici prea laxi, nici fixați pe o singură cale. Fazele „Țintă apoi înmulțire”, o regulă fără alte semințe pentru eșantioanele multiplicate, controler partajat plus adaptor de mediu și reevaluarea post-SFT creează o frontieră mobilă peste lacunele rămase.

Pe EnterpriseOps Gym, rezultatele hibride raportate de autori cu Gemma-4-26B-A4B-it și Qwen3.8-27B arată aproximativ două mii de eșantioane în aproximativ optsprezece ore și creșteri semnificative ale Pass@1 și ale succesului verificatorului, eliminând o mare parte din decalajul față de un model de referință. ITSM cu DeepSeek-V4.1-Flash ca profesor arată o creștere a Pass@1 de la 18,77% la 27,18% pe aproximativ 1.994 de eșantioane pe o perioadă mai lungă. Tratați aceste cifre ca semnale cercetate pe domenii specifice, în funcție de profesor, verificator și fidelitatea mediului - și păstrați învățarea prin consolidare ca o extensie planificată a buclei, nu o afirmație finalizată.

Dacă vă amintiți o propoziție: agenții din cadrul întreprinderii se îmbunătățesc atunci când eșecurile devin abstractizate, multiplicate, lecții verificate în interiorul sistemelor pe care trebuie să le opereze zi de zi - nu atunci când echipele pur și simplu repetă același tichet defect.

Exemplu practic: Extinderea cazurilor ITSM dificile dintr-un set de eșecuri înghețate, în stilul unei săli de sport

Scenariu

O echipă de platformă pentru întreprinderi din Marea Britanie - gândiți-vă la un grup de operațiuni de servicii financiare de dimensiuni medii care rulează ITSM în stil ServiceNow cu ferestre de modificare, relații CMDB și tranziții controlate de politici - are un agent de tip producție care se împiedică în mod repetat de aceeași clasă de lucru: actualizări încrucișate între tabele care trebuie să respecte o condiție prealabilă de aprobare, căutări în articole de cunoștințe care intră în conflict cu blocările locale de modificări și solicitări hibride care transmit ITSM în instrumente operaționale adiacente.

Ei îngheață o suită privată în stil EnterpriseOps Gym (sandbox containerizat, verificări ale rezultatelor SQL, tabele inițializate, reguli de politică), astfel încât scorurile sunt comparabile de la o săptămână la alta. Ruletele de diagnosticare arată că agentul țintă eșuează acolo unde un profesor mai puternic are succes. Conducerea dorește mai mult semnal de instruire fără a reda aceleași numere de tichete și ID-uri de entități. AutoSynthData (sau o buclă echivalentă de sinteză din eșecuri dacă pipeline-ul de cercetare este închis în stiva lor) este candidatul: transformă eșecurile de contrast în carduri de specificații de capabilități igienizate, generează noi sarcini, colectează demonstrații pentru profesori, apoi - în mod esențial - revizuiește urmele sintetice de către oameni înainte de orice re-instruire.

Nimic nu este inclus în Gym Pass@1. Datele Synth sunt tratate ca curriculum candidat, nu ca adevăr gratuit.

De ce are nevoie asistentul

• Acces la adaptorul de mediu înghețat, în stil Gym: instrumente, stare inițială, politici și verificatori SQL (sau echivalenți bazați pe stare).
• Jurnale de evaluare pereche: eșecurile la ținte comparate cu succesele profesorilor la aceleași sarcini.
• O schemă de card care surprinde capacitatea, forma instrumentelor/fluxului de lucru, contrastul eșec/reușit, proprietățile stării finale necesare și dimensiunile de variație permise - fără solicitări originale, entități, traiectorii sau componente interne ale verificatorului.
• Regulile de verificare a informațiilor personale și a politicilor (ID-uri de tichete, nume de utilizatori, nume de CI, câmpuri reglementate) înainte ca orice element să părăsească mediul de testare sau să intre într-un prompt al generatorului.
• O coadă de verificare umană pentru sarcini sintetice eșantionate și urme ale profesorului (fezabilitate, realism, soliditatea verificatorului, cazuri de refuz/nefezabilitate).
• Ștergeți condițiile de oprire: Țintește, apoi multiplică fazele; probele multiplicate nu generează runde suplimentare de multiplicare.

Exemplu de instrucțiuni

Contactul platformei către operatorul de curriculum (sau către un asistent de orchestrare care doar elaborează fișe și pachete de revizuire - nu recalifică și nu promovează modele):

„Rulați diagnosticarea Pass@1 pe secțiunile ITSM și Hybrid înghețate împotriva țintei noastre actuale și a profesorului desemnat. Pentru fiecare contrast în care ținta eșuează și profesorul reușește cel puțin două din trei încercări, elaborați o fișă de specificații de capacitate igienizată: denumiți capacitatea, enumerați instrumentele relevante, specificați proprietățile stării finale necesare și enumerați dimensiunile controlabile (banda de prioritate, clasa CI aferentă, indicatorul ferestrei de modificare, tipul de conflict de cunoștințe). Eliminați numerele tichetelor, identificatorii de utilizatori, numele CI și traiectoriile brute. Generați un lot de sarcini noi pentru faza țintă doar din aceste fișe. Rugați profesorul să demonstreze succesele. Aplicați banda de dificultate (țintă ≤1/3, profesor ≥2/3), verificarea pozitivă și negativă și critica/repararea limitată. Produceți un pachet de revizuire cu eșantioane stratificate de 5% plus fiecare fișă de refuz/nefezabilitate. Nu începeți SFT până când doi recenzori nu semnează pachetul și verificările PII nu trec. După SFT pe un punct de control candidat, reevaluați suita înghețată și pe un set de potrivire exactă rezervat pe care nu l-am folosit niciodată pentru generare. Raportați acoperirea după clasa de eșec și rata de regresie față de producția anterioară.” punct de control. Nu promovați doar pe baza scorului la sală.”

Cum să îl testezi

1. Blocare de bază: Înregistrați ratele de succes Pass@1 și ale verificatorului pentru suita înghețată în funcție de clasa de eșec (ordonare precondiții, refuz la fereastră de modificare, hibrid cross-tool, conflict de cunoștințe). Mențineți suita și seed-urile imuabile pe parcursul ciclului.
2. Audit carduri: Verificați aleatoriu dacă generatoarele nu primesc niciodată solicitări originale, entități sau urme ale profesorilor - doar carduri.
3. Exemplu de control al calității: Confirmați că traiectoriile pozitive trec de verificatori, iar rezultatele greșite cu mutații eșuează. Respingeți sarcinile care sunt banale pentru țintă sau aruncați moneda cu banul pentru profesor.
4. Revizuire umană: Evaluatorii marchează fiecare eșantion ca fiind păstrat / reparat / eliminat în funcție de fezabilitate, realism și siguranța politicilor. Urmăresc acordul inter-evaluatori asupra unui subset comun.
5. Potrivire exactă a sarcinilor reținute: După SFT-ul candidat, se evaluează o parte din sarcinile reținute (sau anterior înghețate) care nu au fost niciodată introduse în cardare sau generare. Se evaluează separat aproape parafrazele sarcinilor de antrenament pentru a detecta memorarea superficială.
6. Poartă de regresie: Orice clasă de eșec care se agravează față de punctul de control al producției anterioare blochează promovarea până la explicarea sau remedierea acesteia.

Rezultat

Nu inventați aici procente de eliminare a informațiilor. Folosiți un plan de măsurare și etichetați cifrele de cercetare publicate drept AFIRMAȚII ARTICOLULUI atunci când le citați.

Plan de măsurare (ce ar trebui să raporteze această echipă):

• Acoperire a claselor de defecțiuni: ponderea claselor de decalaje diagnosticate care au produs ≥N sarcini acceptate în faza țintă după controlul calității (definiți N de la început, de exemplu, 20 de sarcini acceptate per clasă).
• Potrivire exactă a reținerii: Pass@1 / succesul verificatorului pe reținerea neatinsă înainte vs. după SFT-ul candidat (aceleași valori inițiale, același verificator).
• Rată de regresie: numărul de clase de eșec în care Pass@1 se încadrează în punct de control al producției anterioare; blochează dacă vreo clasă critică pentru siguranță regresează.
• Randamentul recenziilor: mențineți / reparați / ratele de abandon pe pachetul de recenzii umane; dacă rata de abandon crește brusc, întrerupeți. Înmulțiți și reparați cărțile sau verificatorii.
• Erori de verificare a datelor: numărul de eșantioane care nu au trecut verificările PII/politicii înainte de aprobarea revizuirii (țintă: zero eșecuri în setul SFT).

AFIRMAȚIA ARTICOLULUI (raportat de autor pe EnterpriseOps Gym - nu este rezultatul măsurat de această echipă): Rularea hibridă cu Gemma-4-26B-A4B-it ca țintă și Qwen3.8-27B ca profesor a produs aproximativ 2.000 de eșantioane în aproximativ 18 ore, cu o creștere medie a succesului la 1 de aproximativ 7,2 puncte procentuale și o creștere a succesului verificatorului de la 63,01% la 68,55%. ITSM cu DeepSeek-V4.1-Flash ca profesor a mutat media succesului la 1 de la 18,77% la 27,18% pe aproximativ 1.994 de eșantioane pe o perioadă mai lungă (~66 de ore). Tratați-le ca semnale cercetate pe domenii și perechi specifice, nu ca o garanție universală pentru un stack de producție în Marea Britanie.

Forma ilustrativă a programului (presupuneri, nu câștiguri măsurate): Dacă echipa acceptă ~2.000 de eșantioane verificate prin QC pentru un ciclu ITSM, ia în considerare inferența profesorului plus revizuirea la o eșantionare stratificată de 5% și promovează doar atunci când excluderea nu regresează clasele critice pentru siguranță, „rezultatul” pe care îl pot revendica cu o poziție serioasă este maturitatea procesului - curriculum auditat, urme șterse și delte comparabile de suită înghețată - nu o creștere procentuală promisă.

Ce poate merge prost

• Tratarea sintetizatorului ca adevăr liber: Omiterea revizuirii umane sau a verificării negative permite verificatorilor permisivi să admită gunoi la scară largă.
• Scurgere de entități: Introducerea ID-urilor originale ale biletelor sau a urmelor profesorilor în generator invită la supraadaptarea parafrazelor; există carduri pentru a preveni acest lucru.
• Înmulțire nelimitată: Permiterea ca eșantioanele multiplicate să genereze runde suplimentare se îndepărtează de capacitatea numită.
• Livrare scoruri sală de sport: Promovare deoarece numărul de acces la ...
• Plafon slab pentru profesori: Dacă profesorul nu poate depăși banda de succes ≥2/3, SFT predă demonstrații nesigure.
• Verificatori incerti: Rubricile de chat, în loc de verificări bazate pe stare, notează rezultatele finale greșite la nivel fluent ca fiind reușite.
• Refuzul antrenării insuficiente: Optimizarea doar pentru mutațiile finalizabile lasă fereastra de schimbare și declinul politicilor fragile.
• Ieșire PII: Solicitări sintetice care reintroduc CI sau nume de utilizator reale după o curățare superficială.

Concluzie practică

Folosește bucle în stil AutoSynthData - sau un model echivalent synth-from-failures dacă pipeline-ul ServiceNow CoreAI nu este disponibil în țara ta - pentru a multiplica cazuri ITSM concrete și verificabile din lacunele diagnosticate. Sanitizează în carduri de capabilitate, gate cu dificultate și verificare pozitivă/negativă, curăță PII și mostrele revizuite de oameni înainte de SFT. Măsoară acoperirea clasei de eșecuri, reține potrivirea exactă și rata de regresie. Citează cifrele ARTICOLULUI REVENDICĂRII Gym doar ca context extern de cercetare. Datele Synth sunt combustibil pentru curriculum, nu o garanție: auditează mostrele, păstrează suita înghețată pentru o comparație corectă și nu expediază niciodată scorul Gym de la sine.

FAQ

Ce este AutoSynthData și ce problemă vizează?

AutoSynthData este o conductă ServiceNow CoreAI / ServiceNow-AI, descrisă de Esakkivel Esakkiraja, care combină eșecurile unui agent țintă cu succesele unui profesor mai puternic în sarcini de antrenament sintetic validate pentru setări de întreprindere. Se concentrează pe competența de mediu - politici locale, scheme, instrumente și stare - mai degrabă decât pe cunoștințe generale largi. Ideea este de a multiplica munca dificilă, verificabilă, astfel încât reglajele fine supravegheate să poată corecta lacunele specifice mediului în loc să repete același tichet defect.

De ce este competența de mediu diferită de capacitatea modelului general?

Agenții din cadrul companiei se împiedică adesea deoarece mediul în sine este particular: politici de tichete, particularități ale schemei, contracte de instrumente, baze de date inițiale și fluxuri de lucru între sisteme. Un model care pare puternic pe teste comparative deschise se poate bloca totuși într-o fereastră de modificare, o relație CMDB sau un verificator care inspectează starea finală. Capacitatea extinsă nu este același lucru cu cunoașterea modului în care se comportă sistemele, regulile și starea datelor în cadrul tranzițiilor guvernate de politici.

Care este forma practică a sarcinii pe care o folosește AutoSynthData?

O formă funcțională este o sarcină egală cu specificația sistemului, promptul utilizatorului și verificatorul. Specificația sistemului conține constrângeri, politici și stare inițială, cum ar fi valorile inițiale ale bazei de date și articolele de cunoștințe. Prompturile utilizatorului sunt evaluate în funcție de fezabilitate, realism și dificultate. În mod ideal, verificatorii se bazează pe verificări ale rezultatelor bazate pe SQL sau pe stări, astfel încât să evalueze lumea după ce agentul acționează, nu doar calea exactă urmată de token.

Cum previn supraadaptarea cardurilor cu specificații de capabilitate igienizate?

Rulele de diagnosticare compară cazurile în care obiectivul eșuează și profesorul are succes, apoi distilează aceste cazuri în fișe de specificații de capabilități igienizate. O fișă înregistrează forma capacității, instrumentelor sau fluxului de lucru, contrastul eșec/succes, proprietățile stării finale necesare și dimensiunile care pot varia. Generatorul nu vede niciodată solicitări, entități, traiectorii sau detalii ale verificatorului originale - doar fișele - astfel încât sarcinile noi apasă pe nucleul nucleului fără a parafraza un episod memorat.

Care sunt fazele Target și Multiply din fluxul de lucru?

Faza țintă se concentrează pe eșantioanele de bază verificate din jurul lacunelor - sarcinile cu cel mai mare semnal din apropierea locului unde agentul slab se rupe. Faza de multiplicare generează variante noi ale țintelor acceptate. Eșantioanele multiplicate nu pot genera runde suplimentare de multiplicare, ceea ce menține sub control deviația de la capacitatea numită. După reglarea fină supravegheată, reevaluarea deplasează programa către lacunele rămase ca o frontieră mobilă, mai degrabă decât o groapă statică.

Cum menține controlul calității la nivel de probă fiabilitatea sarcinilor sintetice?

Un filtru de dificultate pentru rezolvitor favorizează sarcinile pe care ținta le rezolvă în cel mult una din trei încercări, în timp ce profesorul reușește în cel puțin două din trei. Verificarea pozitivă necesită o traiectorie de referință pentru a trece; verificarea negativă necesită rezultate greșite mutate pentru a eșua. O buclă de critică și reparare cu o limită de reîncercări încearcă să remedieze situațiile la limită, iar meta-revizuirea la nivel de lot verifică acoperirea, diversitatea, redundanța și țintele eșuate din set.

Ce arhitectură folosește AutoSynthData în domeniile întreprinderilor?

Acesta conectează un controler partajat cu un adaptor de mediu. Controlerul execută diagnosticarea, cardarea, generarea, demonstrațiile pentru profesori, porțile de calitate și revizuirea în loturi. Adaptorul conectează acești pași într-un sandbox concret - instrumente, stare, politici și verificatori - astfel încât aceeași buclă de control poate indica domenii diferite fără a rescrie logica curriculară de la zero.

Ce este EnterpriseOps Gym în acest context de cercetare?

EnterpriseOps Gym este un banc de lucru pentru agenți la scară largă, folosit ca platformă de testare a stresului, cu aproximativ 1.150 de sarcini selectate de experți în 8 domenii, aproximativ 512 instrumente, aproximativ 164 de tabele de baze de date, execuție containerizată, verificare a rezultatelor bazată pe SQL, operațiuni guvernate de politici, scenarii hibride și traiectorii cu stări pe orizont lung. AutoSynthData nu este prezentată ca inventatoare a acelui platformă de lucru; platformă de lucru prezintă bucla de sinteză în acțiune.

Ce rezultate raportate de autori apar pentru setările hibride și ITSM?

Pe EnterpriseOps Gym, rulările Hybrid cu Gemma-4-26B-A4B-it ca țintă și Qwen3.8-27B ca instructor au produs aproximativ 2.000 de eșantioane în aproximativ 18 ore, cu o medie a Pass@1 în creștere cu aproximativ 7,2 puncte procentuale și o creștere a succesului verificatorului de la 63,01% la 68,55%. ITSM cu DeepSeek-V4.1-Flash ca instructor a mutat media Pass@1 de la 18,77% la 27,18% pe aproximativ 1.994 de eșantioane pe o perioadă mai lungă de timp. Tratați-le ca semnale cercetate pe perechi specifice, nu ca o garanție universală a producției.

Ce greșeli ar trebui să evite echipele atunci când utilizează bucle synth-from-failures?

Nu tratați datele sintetice drept adevăr liber și nu săriți peste revizuirea umană și verificarea negativă. Evitați să introduceți în generator ID-urile originale ale biletelor sau urmărirea profesorilor, să permiteți eșantioane multiplicate să genereze runde suplimentare sau să promovați Gym Pass@1 de la sine în timp ce traficul de blocare sau din umbră se înrăutățește. De asemenea, urmăriți profesorii slabi sub banda de succes, rubricile de chat vagi în loc de verificări de stare, cazurile de refuz al antrenamentului insuficient și evadarea informațiilor personale după o scurtă verificare superficială.

Referințe

1. Față îmbrățișătoare — AutoSynthData — huggingface.co
2. Sală de sport EnterpriseOps — enterpriseops-gym.github.io
3. arXiv — arxiv.org
4. GitHub — EnterpriseOps-Gym — github.com