AutoSynthData este un pipeline construit de echipa ServiceNow CoreAI care pornește de la eșecurile unui model țintă și de la reușitele unui profesor mai puternic, apoi generează și validează sarcini noi de antrenament. În experimentul publicat, pe domeniul Hybrid din EnterpriseOps Gym, checkpoint-ul SFT a crescut Pass@1 mediu cu 7,2 puncte procentuale, o îmbunătățire relativă de 35%, și a urcat succesul verifier de la 63,01% la 68,55%. Sursa: Hugging Face, blog ServiceNow AI.

Ideea centrală nu e spectaculoasă, dar e corectă: un model poate fi bun la nivel general și slab în mediul tău concret. Aici începe problema reală.

Problema pe care o rezolvă și de ce contează

Un agent enterprise nu trăiește într-un vid. Operează într-un mediu cu stări observabile, unelte și API-uri pe care le poate apela, tranziții de stare pe care le produce. Un model care pare capabil pe benchmark-uri poate rata un workflow anume, poate folosi greșit o combinație de unelte sau poate încălca o constrângere de politică internă. Exact acolo e valoarea.

Problema nu e identificarea eșecului, ci transformarea lui în date de antrenament. Un singur eșec spune ceva, dar antrenarea cere multe sarcini noi care exercită aceeași capacitate în situații diferite. Și, mai important, acele sarcini trebuie să fie posibile în mediu, să semene cu ce ar cere un utilizator real și să aibă o metodă fiabilă de verificare a succesului. Fără aceste trei condiții, generezi volum, nu semnal de învățare.

Asta e diferența dintre un pipeline serios și un generator de prompturi care umple un fișier. În practică, majoritatea eforturilor de date sintetice mor exact aici: produc text plauzibil, dar nu produc sarcini verificabile.

Ce face un task util: fezabilitate, realism, dificultate

AutoSynthData abstractizează sarcina ca triplet: specificație de sistem, prompt de utilizator, verifier. Specificația descrie constrângerile: instrucțiuni, politici de mediu, inițializare specifică (o bază de date populată, un set de articole de cunoaștere). Ea trebuie să fie compatibilă cu uneltele și acțiunile suportate, iar constrângerile nu trebuie inventate doar ca să fabrici dificultate artificială.

Promptul de utilizator trebuie să îndeplinească trei proprietăți. Prima, fezabilitatea: să existe cel puțin o traiectorie validă în mediul curent. A doua, realismul: promptul să semene cu ce ar cere un utilizator în acel mediu. Spațiul comportamentelor executabile e mult mai larg decât spațiul workflow-urilor realiste, iar asta e o capcană pe care mulți o ignoră. A treia, dificultatea: sarcina să expună o slăbiciune a modelului curent. Sarcinile deja rezolvate constant oferă semnal minim. Zona utilă e cea a sarcinilor fezabile și realiste, dar încă nerezolvate consistent.

Verifierul are și el trei proprietăți. Consistență cu promptul, specificația și starea inițială. Corectitudine, adică respinge traiectoriile care nu satisfac sarcina sau încalcă constrângeri. Și completitudine: acceptă soluții valide, nu doar o traiectorie de referință. Un verifier lax recompensează comportament greșit. Unul prea restrictiv penalizează soluții corecte. Ambele strică antrenamentul, doar în direcții diferite.

Reține ceva: verificarea e miezul tehnic al problemei, nu generarea. Generarea e ieftină. Verificarea e grea.

Cum funcționează pipeline-ul, pe scurt

Pipeline-ul evaluează modelul țintă pe sarcini de diagnostic, identifică tipare în ce nu reușește, iar un profesor mai puternic caracterizează ce e rezolvabil și cum arată comportamentul corect. Rezultatele se distilează în așa-numite carduri de specificație a capacității, curățate. Generatorul nu primește prompturile originale, entitățile, traiectoriile sau detaliile verifierului. Primește cardurile și creează sarcini noi, cu prompturi, stări și căi de soluție diferite.

Construcția are două faze. Faza Target creează setul de bază: muncitori generați în paralel, fiecare candidat trece prin validare, execuție, evaluare de solver și reparare înainte de acceptare. Faza Multiply extinde setul cu variante noi ale eșantioanelor acceptate, fiecare variantă cu propriul prompt, stare de mediu, configurație de entități, traiectorie de referință și verifier. Un eșantion multiplicat nu poate genera la rândul lui alt eșantion multiplicat. Asta ancorează expansiunea în setul verificat și limitează derivarea generațiilor.

La nivel de eșantion, fiecare candidat trece prin evaluare de solver pentru măsurarea dificultății, verificare pozitivă (traiectoria de referință rezolvă sarcina?), verificare negativă (rezultatele incorecte eșuează?) și un proces de reparare cu număr limitat de reîncercări. Candidatul respins ajunge la un critic care caută stare inconsistentă, workflow imposibil, construcție greșită, traiectorie de referință defectă sau logică slabă de verificare.

La nivel de lot, un meta-review examinează ce e acceptat, ce e respins și cum s-a comportat generarea: ce familii de sarcini sunt suprareprezentate, ce dimensiuni de capacitate lipsesc, ce tipare apar repetat în critici. Controllerul urmărește acoperirea în setul acceptat, reduce generarea în zonele suprareprezentate și direcționează efortul spre goluri.

Aici merită o observație de operator. Cifrele din articol descriu un experiment specific, pe un mediu specific, cu modele specificate. Nu sunt o promisiune pentru datele tale. Sunt un semnal că abordarea poate funcționa când verificarea e făcută serios.

Ce arată experimentele EnterpriseOps Gym

Pe domeniul Hybrid, modelul țintă a fost Gemma-4-26B-A4B-it, profesorul Qwen3.8-27B, iar pipeline-ul a generat 2.000 de eșantioane sintetice în circa 18 ore. Checkpoint-ul cel mai bun a fost epoca 5. Rezultatul: Pass@1 mediu plus 7,2 puncte procentuale, 35% relativ, succes verifier de la 63,01% la 68,55%, acoperind 59% din diferența inițială de Pass@1 față de modelul de referință. Sarcinile de antrenament au fost generate din specificații de capacitate, fără acces la sarcinile originale de evaluare.

Pe ITSM, cu același model țintă și DeepSeek-V4.1-Flash ca profesor, s-au generat 1.994 de eșantioane în 66 de ore. Generarea a durat mai mult decât în rularea Hybrid ulterioară, potrivit sursei, din motive legate de mediul respectiv.

Un detaliu de reținut: rezultatele sunt raportate pe EnterpriseOps Gym, mediul folosit în experiment. Nu sunt rezultate generale pe agenți enterprise din orice domeniu. Cine citează cifrele fără această precizare le folosește greșit.

Ce înseamnă pentru tine, ca antreprenor sau marketer român

Dacă ai un magazin online, un CRM aglomerat și un asistent AI care răspunde la întrebări despre comenzi, ai deja un mediu cu stări, unelte și politici. Nu ai nevoie de EnterpriseOps Gym ca să recunoști problema. Ai nevoie de un set de sarcini de test pe care asistentul tău le ratează constant și de o metodă clară de a decide dacă răspunsul e bun sau nu.

Traducerea practică a metodologiei, în termeni pe care îi poți aplica fără infrastructură de cercetare:

Primul pas, definește mediul. Ce poate vedea asistentul, ce poate modifica, ce unelte poate apela, ce politici interne trebuie respectate. Fără asta, nu ai cum să validezi nimic.

Al doilea pas, strânge eșecuri reale. Nu scenarii inventate în ședință, ci cereri care au produs rezultate greșite. Fiecare eșec e un punct de plecare.

Al treilea pas, scrie un verifier înainte de a genera variații. Concret: cum arată o soluție acceptabilă, cum arată una inacceptabilă, ce nu are voie agentul să facă. Verificatorul se scrie înaintea setului de teste, nu după.

Al patrulea pas, generează variații pe dimensiuni diferite: entități, stări inițiale, formulare, compoziție de pași. Aici AI-ul chiar ajută, pentru că producerea de variante e muncă repetitivă.

Al cincilea pas, validează pozitiv și negativ. Rulează soluția de referință și confirmă că trece. Apoi mută părți din rezultatul așteptat și confirmă că verificatorul respinge. Dacă verificatorul acceptă rezultate mutate, ai un verificator slab și antrenezi agentul să fie încrezător și greșit.

Al șaselea pas, măsoară acoperirea. Dacă 80% din testele tale sunt despre anulări de comenzi, restul capacităților rămân neacoperite. Echilibrul contează mai mult decât volumul.

Pentru un marketer care lucrează cu date de performanță, logica se aplică identic. Dacă vrei un agent care să citească rapoarte și să propună bugete, trebuie să definești ce e o propunere validă, ce e una dăunătoare, cum verifici. Un agent care nu are verifier clar nu învață nimic util, indiferent cât de bun e modelul de bază.

Ai și un context mai larg în care încadrezi asta. Dacă lucrezi la SEO și vrei să fii citat de AI Search, ai deja un checklist de 43 de pași pentru Google și AI Search. Aceeași disciplină de structurare se aplică și când construiești reguli pentru agenți. Iar dacă te interesează diferența dintre un agent care reacționează la prompt și unul care rulează pe evenimente, ai analiza despre ambient agents pe Amazon Bedrock AgentCore, unde discuția despre execuție și constrângeri e direct relevantă.

FAQ

Ce este AutoSynthData, pe scurt? Un pipeline ServiceNow CoreAI care transformă slăbiciunile unui model țintă în date de antrenament: generează sarcini fezabile, realiste și dificile, fiecare cu specificație de sistem, prompt și verifier, apoi le validează în mediu înainte de a le accepta pentru post-antrenare.

Cifrele din experiment sunt valabile pentru orice agent enterprise? Nu. Rezultatele raportate sunt pe EnterpriseOps Gym, pe domeniile Hybrid și ITSM, cu modelele menționate explicit. Sunt dovezi de metodă într-un mediu controlat, nu garanții de transfer pe mediul tău. Tratează-le ca pe un argument de abordare, nu ca pe un benchmark universal.

Care e partea grea, generarea sau verificarea? Verificarea. Generarea de cereri plauzibile e la îndemână cu un model bun. Verificarea corectă, care acceptă soluții valide alternative și respinge rezultatele greșite, e partea care decide dacă datele sintetice sunt utile sau o povară.

Concluzia ALLSoft Agency

Metodologia din spatele AutoSynthData e un argument în favoarea unei idei pe care o susținem de mult: calitatea verificării decide calitatea învățării. AI-ul ajută la generare de variante, la analiză și la planning. Un model poate descrie ce lipsește și poate produce rapid scenarii noi. Dar decizia despre ce merită antrenat, ce constrângeri sunt reale și ce înseamnă un rezultat acceptabil rămâne la operator. Media buyer-ul știe ce înseamnă un lead bun pentru clientul lui, nu modelul. Iar execuția, adică transformarea acestor reguli într-un sistem care chiar rulează, rămâne muncă de om.

Dacă vrei să aplici logica asta pe datele și agenții tăi, începe de la o singură întrebare: cum verifici rezultatul înainte să-l lauzi? ALLSoft Agency te ajută să treci de la ipoteză la sistem măsurabil.