ServiceNows AutoSynthData förvandlar agentmisslyckanden till utbildningsguld

ServiceNows AutoSynthData förvandlar agentmisslyckanden till utbildningsguld

Kort svar: ServiceNow CoreAI:s AutoSynthData omvandlar agentmisslyckanden plus lärares framgångar till validerade syntetiska SFT-uppgifter när företag behöver miljökompetens, inte bara breda benchmarkpoäng. Den sanerar luckor till kapacitetsspecifikationskort, multiplicerar verifierbart arbete och kontrollerar sedan kvaliteten innan finjustering. Författarrapporterade EnterpriseOps Gym-lyft håller om lärarstyrka, verifierarkvalitet och miljötrohet överensstämmer.

Viktiga slutsatser:

Kapabilitetskort: Sanera fel på korten så att generatorer aldrig ser ursprungliga ID:n.

Verifierargranskningsbarhet: Föredra SQL-slutgiltiga tillståndskontroller som avvisar muterade felaktiga resultat.

Svårighetsgrad: Träna endast uppgifter som målet sällan löser och som läraren vanligtvis klarar.

Mänsklig granskning: Håll mänsklig granskning av policyer med hög insats och oåterkalleliga åtgärder före omskoling.

Flyttande gräns: Efter SFT, omvärdera och flytta målfasen mot återstående luckor.

Företags-AI-agenter misslyckas sällan för att de saknar allmän kunskap. De misslyckas eftersom miljön är specifik: ärendepolicyer, schemamässiga egenheter, verktygskontrakt, seeddatabaser, kunskapsartiklar och systemövergripande arbetsflöden som inte ser ut som läroboksdemonstrationer. En modell som får bra resultat på öppna benchmarks kan fortfarande stanna upp när nästa steg måste respektera ett ändringsfönster, en CMDB-relation eller en verifierare som kontrollerar slutgiltigt tillstånd snarare än flytande chatt.

ServiceNow CoreAI / ServiceNow-AI publicerade AutoSynthData för att direkt åtgärda den luckan. Den namngivna författaren Esakkivel Esakkiraja beskriver en pipeline som omvandlar en målagents misslyckanden – tillsammans med en starkare lärares framgångar – till validerade syntetiska träningsuppgifter anpassade till företagsmiljöer. Poängen är inte att samla in fler chattloggar. Det är att mångfaldiga hårt, verifierbart arbete som utövar samma kapacitet under nya förhållanden så att övervakad finjustering kan täcka miljöspecifika luckor.

Den här artikeln går igenom kärnidén, uppgiftsabstraktionen, genererings- och kvalitetskontrollslingan, den delade arkitekturen och författarrapporterade resultat om EnterpriseOps Gym i hybrid- och ITSM-miljöer. Den håller sig till vad forskningen beskriver: en rörlig läroplan av syntetiska uppgifter, inte ett påstående att ett företag plötsligt är löst.

Varför miljökompetens överträffar bred kapacitet

Företag behöver agenter som arbetar i deras miljö – deras system, regler och datatillstånd. Bred kapacitet är inte samma sak som miljökompetens. En agent kan veta hur IT-tjänsthantering vanligtvis fungerar och ändå missa den lokala policyn som förbjuder vissa övergångar, eller verktyget som uppdaterar en relaterad tabell först efter att en nödvändig post finns.

Enskilda misslyckanden är informativa men lika tunna som träningsdata. En trasig bana visar på en svaghet; den tillhandahåller inte de dussintals närliggande situationer som skulle lära modellen att återhämta sig under variation. Team behöver många nya uppgifter som utövar samma kapacitet på olika sätt, förblir slutförbara i miljön, känns realistiska när användaren ber om det och förblir verifierbara mot resultatkontroller.

Det är designtrycket bakom AutoSynthData. Misslyckanden blir signaler för kompetenskort. Kort blir generatorer för nya uppgifter. En starkare lärare visar framgångsrika utvecklingsförlopp. Filter och verifierare avgör vad som ska in i den övervakade finjusteringsmängden. Efter träning flyttar utvärderingen gränsen mot återstående luckor. Loopen är läroplanformad snarare än en engångsdatadump.

Inramning är viktig för utövare. Om du bara lagrar misslyckade prompter riskerar du att överanpassa till exakt de entiteterna och formuleringarna. Om du bara genererar obegränsade syntetiska frågor riskerar du uppgifter som är omöjliga, orealistiska eller overifierbara. AutoSynthData befinner sig mellan dessa ytterligheter: sanera det som misslyckades till en funktionsspecifikation, och generera sedan uppgifter som behåller den hårda kärnan samtidigt som ytform och kontrollerbara dimensioner ändras.

Den praktiska uppgiftsformen: system, prompt, verifierare

En fungerande abstraktion för agentarbete är: uppgift är lika med systemspecifikation, användarprompt och verifierare. Varje del har begränsningar som håller syntetisk data grundad och tillförlitlig.

Systemspecifikationen täcker begränsningar, policyer och initialt tillstånd – till exempel databasfrön och kunskapsartiklar. Den måste vara kompatibel med tillgängliga verktyg och tillstånd. Godtyckliga svårighetsbegränsningar som ignorerar verktygskontrakt eller frörealism tenderar att skapa bräckliga uppgifter som lär ut fel läxa.

Användaruppmaningens kvalitet har tre linser. Genomförbarhet frågar om en giltig utvecklingsbana existerar. Realism frågar om en användare rimligen skulle begära detta. Svårighetsgrad frågar om uppgiften avslöjar en befintlig svaghet hos agenten snarare än något som målet redan löser på ett tillförlitligt sätt. En uppmaning som är trivial för målet slösar bort utbildningsbudgeten; en uppmaning som är omöjlig slösar bort utvärderingsförtroende.

Verifierarens kvalitet är beroende av konsekvens, sundhet och fullständighet. För slappa och svaga banor lyckas. För begränsade till en enda banor misslyckas och giltiga alternativa lösningar misslyckas. Företagsmiljöer föredrar ofta SQL-baserade eller tillståndsbaserade resultatkontroller eftersom de betygsätter världen efter att agenten agerat, inte den exakta token-vägen agenten tog.

AutoSynthData lutar sig mot denna triad så att genererat arbete förblir jordat. Generatorer uppfinner inte fritt flytande quiz. De producerar uppgifter som kan köras i miljöadaptern och bedömas av verifierare som bryr sig om nödvändiga egenskaper i slutgiltigt tillstånd.

Från diagnostisk utvärdering till kapacitetsspecifikationskort

Processen börjar med en diagnostisk utvärdering av målgruppen och en starkare lärare i miljön. Sida-vid-sida-analyser avslöjar var målet misslyckas och var läraren lyckas. Dessa jämförande fall är råmaterialet för läroplandesign.

Därefter följer destillation till sanerade kapacitetsspecifikationskort. Ett kort fångar den kapacitet som testas, relevanta verktyg eller arbetsflödesform, där målet misslyckas och läraren lyckas, nödvändiga slutgiltiga tillståndsegenskaper och dimensioner som kan variera när nya uppgifter uppfinns. Avgörande är att generatorn inte tar emot ursprungliga prompter, entiteter, banor eller verifierardetaljer - bara korten.

Den saneringen är ett avsiktligt drag mot överanpassning. Om generatorn såg exakta felnummer, kunskapsartikel-ID:n eller lärarspår, skulle den vara frestad att parafrasera samma avsnitt. Kort tvingar fram abstraktion: lär ut förmågan under kontrollerbar variation, inte den memorerade instansen.

När korten finns genererar systemet nya uppgifter från dem. Läraren demonstrerar sedan lyckade banor för övervakad finjustering. Dessa demonstrationer är inte fria råd; de är miljöbaserade framgångar som klarar samma typ av verifiering som läroplanen bryr sig om.

Tvåfasstrukturskala. Målfasen fokuserar på kärngranskade prover runt mellanrum – uppgifterna med högst signal nära där den svaga agenten bryts. Multiplikationsfasen skapar nya varianter av accepterade mål. Multiplicerade prover kan inte utlösa ytterligare multiplikationsrundor, vilket begränsar avdrift. Den regeln är liten men viktig: obegränsad rekursiv variation kan avvika från den förmåga som kortet namngav.

Delad styrenhet, miljöadapter och den rörliga gränsen

Arkitekturmässigt använder AutoSynthData en delad styrenhet plus en miljöadapter. Styrenheten orkestrerar diagnos, kartläggning, generering, lärardemonstrationer, kvalitetsgrindar och batchgranskning. Adaptern kopplar dessa steg till en konkret företagssandlåda - verktyg, tillstånd, policyer och verifierare - så att samma kontrollslinga kan rikta sig mot olika domäner utan att skriva om läroplanens logik från grunden.

Efter övervakad finjustering utvärderas processen på nytt. Läroplanen rör sig sedan mot återstående luckor: en rörlig gräns snarare än en statisk datamängd. Experiment som beskrivs i arbetet fokuserar på övervakad finjustering. Samma loop skulle kunna stödja förstärkningsinlärning senare; den riktningen noteras som planerad, inte påstås vara slutförd.

För företagsteam är den arkitektoniska lärdomen modulär. Kontrollanter bör inte hårdkoda ett enda ärendeschema. Adaptrar bör exponera tillräckligt med tillstånds- och verktygskvalitet för att verifierare kan vara meningsfulla. Läroplanen bör behandla utvärderingsresultat som nästa indata, inte som en engångspoängtavla.

EnterpriseOps Gym är den miljö där denna metod illustrerades. Det är en storskalig Enterprise Agent-bänk med cirka 1 150 expertkurerade uppgifter över 8 domäner, ungefär 512 verktyg, cirka 164 databastabeller, containeriserad exekvering, SQL-baserad resultatverifiering, policystyrda operationer, hybrida domänövergripande scenarier, infeasibility- och refusaltestning samt långsiktiga tillståndsbaserade banor. AutoSynthData presenteras inte som att den uppfann det gymmet; gymmet är stresstestbädden för syntesloopen.

Kvalitetskontroll på provnivå som gör syntetiska uppgifter tillförlitliga

Generering utan grindar är så syntetiska agentdata går fel. AutoSynthData beskriver kvalitetskontroll på provnivå med flera kompletterande kontroller.

Ett filter för svårighetsgraden av lösaren styr gruppen mot uppgifter som är svåra för målet och lösbara för läraren. Den beskrivna konfigurationen gynnar uppgifter som målet löser i högst ett av tre försök, medan läraren lyckas i minst två av tre. Det är i det bandet som handledda demonstrationer kan lära ut något som den svaga modellen inte redan behärskar.

Positiv verifiering kräver att en referensbana passerar verifieraren. Negativ verifiering kräver att muterade felaktiga resultat misslyckas. Tillsammans trycktestar de både acceptans- och avvisningssidan av kontrollören. Om endast positiva kontrolleras kan en tillåtande verifierare erkänna skräp. Om endast negativa kontrolleras kan en alltför strikt verifierare avvisa giltigt arbete.

En kritik- och reparationsloop, med en gräns för återförsök, försöker åtgärda uppgifter som misslyckas med grindar snarare än att omedelbart ignorera alla nära-missar. Gränser för återförsök spelar roll: oändliga reparationer kan skapa alltmer artificiella begränsningar bara för att klara en checklista.

Metagranskning på batchnivå tittar sedan över hela uppsättningen för täckning, mångfald, redundans och misslyckade mål. Sample gates håller enskilda objekt sunda; batchgranskning förhindrar att läroplanen klustras på ett smalt misslyckandeläge eller klonar nästan dubbletter.

Dessa kontroller förklarar varför pipelinen kan lägga timmar på att producera tusentals prover utan att behandla volym som ett substitut för anpassning. Hastigheten varierar beroende på domän och lärarstorlek, men QC-historien är konsekvent: svårighetsgrad, positiv och negativ verifiering, reparation med gränser, sedan meta-granskning.

Råa fel jämfört med kort jämfört med validerade SFT-uppsättningar

Det hjälper att jämföra vad varje artefakt är bra för. Råa felloggar är diagnostiska. Kompetenskort är generativa kontrakt. Validerade övervakade finjusteringsuppsättningar är det man tränar på i praktiken.

Artefakt Vad den innehåller Styrka Risk vid isolering
Råa felloggar Uppmaningar, tillstånd, brutna banor, kontraster med lärares framgång Identifierar verkliga brister i den levande miljön För få exempel; lätt att överanpassa enheter och formuleringar
Funktionsspecifikationskort Förmåga, verktyg eller arbetsflöde, kontrast mellan misslyckande och lyckat resultat, behov i slutgiltigt tillstånd, variabla dimensioner Sanerad abstraktion för generatorer utan läckande original Kort utan QC kan fortfarande ge omöjliga eller triviala uppgifter
AutoSynthData-validerad SFT-uppsättning Nya uppgifter plus lärardemonstrationer som klarat svårighetsgraden, verifieringen och granskningskraven Skala med realism, genomförbarhet och resultatkontroller Beror fortfarande på lärarens styrka, verifierarens kvalitet och miljöns trohet

I Hybrid- och ITSM-snapshots på EnterpriseOps Gym använde författarrapporterade körningar Gemma-4-26B-A4B-it som mål. Hybrid parade ihop det målet med Qwen3.8-27B som lärare och producerade cirka 2 000 hybridprover på ungefär 18 timmar, med den bästa kontrollpunkten vid epok 5. Medelvärdet för Pass@1 ökade med 7,2 procentenheter – cirka 35 procent relativt – med verifierarframgången som gick från 63,01 procent till 68,55 procent, vilket minskade cirka 59 procent av Pass@1-gapet till referensmodellen.

ITSM parade ihop samma mål med DeepSeek-V4.1-Flash som lärare och producerade cirka 1 994 samplingar på ungefär 66 timmar, längre tid delvis på grund av en större lärare och eftersom vissa pipeline-optimeringar ännu inte var på plats. Medelvärdet för Pass@1 ökade från 18,77 procent till 27,18 procent.

Domän Mål Lärare Prover och körtid Författarrapporterat resultat
Hybrid Gemma-4-26B-A4B-it Qwen3.8-27B ~2 000 prover på ~18 timmar; bästa kontrollpunkt epok 5 Medelvärde för Pass@1 +7,2 pp (~35 % relativt); verifierarens framgång 63,01 % till 68,55 %; ~59 % av Pass@1-gapet till referensvärdet avslutat
ITSM Gemma-4-26B-A4B-it DeepSeek-V4.1-Flash ~1 994 prover på ~66 timmar Medelvärde för godkänt vid första antalet 18,77 % till 27,18 %

Läs dessa siffror som företagsforskningsresultat på detta gym för de testade domänerna – inte som en oberoende tredjepartsreplikering och inte som en universell företagsgaranti. Vinster sker där lärarstyrka, verifierarkvalitet och miljötrohet överensstämmer.

Vad utövare bör kopiera från loopen

Även om din stack inte är ServiceNows forskningspipeline, överförs mönstret. Börja med parvis utvärdering av ett produktionsliknande mål och en starkare lärare i en trogen sandlåda. Konvertera kontrastfel till kapacitetskort som tar bort identifierare och banor. Generera uppgifter som varierar tillåtna dimensioner samtidigt som de bevarar nödvändiga slutliga tillståndsegenskaper. Låt läraren demonstrera framgångar. Grind med svårighetsband, positiv och negativ verifiering, begränsad reparation och granskning av batchdiversitet. Finjustera, omvärdera och flytta gränserna.

Var särskilt uppmärksam på verifierarens design. EnterpriseOps Gym-liknande SQL-resultatkontroller och policystyrda operationer illustrerar varför chattrubriker i sig själva är svaga för tillståndsbaserat arbete. Om din verifierare inte kan skilja på muterade felaktiga resultat från korrekta slutresultat, kommer syntetisk skalning att förstärka bruset.

Respektera också andan i multiplikationsregeln: varianter av accepterade mål bör inte oändligt skapa fler varianter utan att återgå till granskade kärnor. Driften är tyst. En läroplan som långsamt uppfinner mer exotiska begränsningar kan fortfarande passera ytliga filter samtidigt som den ursprungliga förmågan lämnas undertränad.

Slutligen, behandla hybridarbete över flera domäner som ett förstklassigt stressfall. Vardagliga användare håller sig inte inom en enda verktygssilo. Hybriduppgifter, långsiktiga banor och vägran eller ogenomförbarhetstester är där miljökompetens visar sig – eller misslyckas tydligt.

Förbehåll, begränsningar och en noggrann läsning av vinsterna

Resultat som rapporterats av författaren på EnterpriseOps Gym är informativa signaler, inte en generell garanti. De publicerade Hybrid- och ITSM-vinsterna gäller för dessa domäner och modellparningar under den beskrivna konfigurationen. Andra domäner, svagare lärare, mer bullriga verifierare eller en ytligare miljöåtergivning kan minska eller radera fördelen.

Kvalitet beror på tre pelare som ingen marknadsföringstext kan hoppa över. Lärarens styrka sätter taket för demonstrationer. Verifierarens kvalitet anger tillförlitligheten hos etiketter och filter. Miljötrohet avgör om inlärda beteenden överlever kontakt med produktionssystem, regler och datatillstånd.

AutoSynthDatas experiment betonar övervakad finjustering. Förstärkningsinlärning noteras som en möjlig senare användning av samma loop, planerad snarare än levererad i det rapporterade arbetet. Läsare bör inte blanda ihop en läroplanklar datamotor med ett färdigt RL-träningspåstående.

Läsarna bör inte heller förväxla syntespipelinen med själva bänken. EnterpriseOps Gym tillhandahåller de kurerade uppgifterna, verktygen, tabellerna, containeriseringen och verifieringsstrukturen. AutoSynthData använder den typen av miljö för att förvandla misslyckanden till utbildningsguld. Ge båda delarna korrekt kredit: gymmet stressar agenter; pipelinen multiplicerar lärbara uppgifter från diagnostiserade luckor.

Det finns inte heller någon gratis lunch på beräkning och kalendertid inuti sandlådan. Hybridsyntes slutfördes i storleksordningen timmar för cirka två tusen prover; ITSM tog längre tid med en tyngre lärare och tidigare pipeline-form. Team bör budgetera för lärarinferens, omförsök för kritik eller reparation, och omvärdering efter varje steg i läroplanen.

Läroplanstänkande för företagsagentteam

Den djupaste idén i AutoSynthData är snarare läroplanmässig än rent generativ. Misslyckanden diagnostiserar. Kort abstraherar. Generering multiplicerar. QC validerar. SFT uppdaterar målet. Omvärdering flyttar gränserna. Den sekvensen behandlar agentförbättring som en serie miljöbaserade lektioner istället för en enda offline-dump av spår.

Läroplanseringstänkande förändrar hur ledare fördelar arbete. Istället för att bara be om fler biljetter eller fler mänskliga anteckningar, fråga vilka förmågor som fortfarande misslyckas vid variation, om dessa förmågor har rena slutgiltiga egenskaper och om en starkare lärare kan demonstrera dem tillförlitligt. Om läraren inte kan lyckas tillräckligt ofta kommer syntetisk SFT att lära ut opålitligt beteende. Om slutgiltiga egenskaper är suddiga kommer verifierare att strida mot giltiga strategier.

Det förändrar också hur man pratar om framgång. Att minska en del av ett Pass@1-gap mot en referensmodell på Hybrid, eller att lyfta ITSM Pass@1 från de höga tonåren till de höga tjugotalen i författarrapporterade körningar, är framsteg inom uppmätt miljökompetens. Det är inte ett bevis på att varje arbetsflöde, varje policy eller varje avslagsfall är löst. Håll det rörliga frontspråket i rörelse: återstående luckor blir nästa Target-fas, inte en eftertanke.

För programdesign, para ihop denna loop med mänsklig granskning där insatserna är höga – säkerhetspolicyer, oåterkalleliga åtgärder, reglerad data – samtidigt som automatiserade grindar låter bära volym på välspecificerade tillståndskontroller. Syntetiska data fungerar bäst när miljön kan säga ja eller nej med SQL-liknande tydlighet. Det har svårt när framgång är subjektiv smak.

Designanteckningar om svårighetsgrad, realism och vägran

Svårighetsinriktning förtjänar en andra granskning. Att favorisera uppgifter som målet löser högst en tredjedel av tiden håller träningen borta från trivia. Att kräva att läraren ska lyckas minst två tredjedelar av tiden håller demonstrationer borta från slantsnurr. Det bandet är en praktisk kompromiss mellan utmaning och inlärningsbarhet.

Realism är fortfarande ett mjukare kriterium men fortfarande viktigt. Företagsanvändare ber om saker som passar deras roller och system. Generatorer som styrs enbart av hårdhet kan uppfinna komplicerade pussel med flera begränsningar som ingen operatör skulle begära. Förmågekort som listar variabla dimensioner hjälper, men människor eller meta-granskning behöver fortfarande fånga surrealistiska uppmaningar.

Avslags- och omöjlighetstestning, som finns i EnterpriseOps Gyms bredare design, påminner team om att kompetens inkluderar att säga nej. En pipeline som endast är optimerad för slutförbara uppgifter kan underträna avslag. När du utökar AutoSynthData-liknande loopar, inkludera kort där den korrekta slutliga egenskapen är en säker avböjning enligt policyn, inte bara en lyckad mutation av databasens tillstånd.

Långsiktiga tillståndsbaserade banor ger ytterligare en designanmärkning. Lärardemonstrationer måste vara sammanhängande över många verktygsanrop. Verifierare som bara kontrollerar den sista tabellraden kan missa mellanliggande policyavbrott. Fullständighet i verifierardesignen innebär att täcka de egenskaper som verkligen definierar framgång för den funktionen – inklusive begränsningar som måste förbli sanna hela tiden, inte bara i slutet.

Avslutande sammanfattning

AutoSynthData, från ServiceNow CoreAI / ServiceNow-AI och skriven i den offentliga artikeln av Esakkivel Esakkiraja, är en pipeline som omvandlar misslyckanden hos målagenter plus framgångar hos lärare till validerade syntetiska utbildningsuppgifter för företagsmiljöer. Den abstraherar misslyckanden till sanerade kapacitetsspecifikationskort, genererar nya uppgifter utan att läcka ursprungliga prompter eller banor, samlar in lärardemonstrationer och tillämpar kvalitetskontroll på provnivå och batchnivå innan övervakad finjustering.

Den praktiska mentala modellen är en uppgift som systemspecifikation, användarprompt och verifierare – med genomförbarhet, realism och svårighetsgrad i spänning, och med verifierare som varken är för slappa eller låsta till en enda väg. Målsättningen är att multiplicera faser, en regel om att inte utvinna ytterligare prover, delad styrenhet plus miljöadapter och omvärdering efter SFT skapar en rörlig gräns över återstående luckor.

På EnterpriseOps Gym visar författarrapporterade hybridresultat med Gemma-4-26B-A4B-it och Qwen3.8-27B ungefär två tusen sampel på cirka arton timmar och betydande ökningar av Pass@1 och verifierar-framgång, vilket minskar en stor del av gapet till en referensmodell. ITSM med DeepSeek-V4.1-Flash som lärare visar att Pass@1 ökar från 18,77 procent till 27,18 procent på cirka 1 994 sampel över en längre period. Behandla dessa siffror som undersökta signaler på specifika domäner, beroende på lärarens, verifierarens och miljöns trohet – och behåll förstärkningsinlärningen som en planerad förlängning av loopen, inte ett färdigt påstående.

Om du minns en mening: företagsagenter förbättras när misslyckanden blir abstraherade, mångfaldiga, verifierade lärdomar inuti de system de måste driva dagligen – inte när team bara spelar om samma trasiga ärende.

Praktiskt exempel: Utöka hårda ITSM-fall från en fryst felmängd i gymstil

Scenario

Ett brittiskt företagsplattformsteam – tänk dig en medelstor driftsgrupp för finansiella tjänster som kör ServiceNow-liknande ITSM med ändringsfönster, CMDB-relationer och policystyrda övergångar – har en produktionsliknande agent som hela tiden snubblar över samma arbetsklass: uppdateringar mellan tabeller som måste respektera ett godkännandekrav, sökningar i kunskapsartiklar som står i konflikt med lokala ändringsfrysningar och hybridförfrågningar som korsar ITSM till angränsande driftsverktyg.

De fryser en privat EnterpriseOps Gym-liknande svit (containeriserad sandlåda, SQL-resultatkontroller, seedade tabeller, policyregler) så att poängen är jämförbara vecka för vecka. Diagnostiska körningar visar att målagenten misslyckas där en starkare lärare lyckas. Ledningen vill ha fler utbildningssignaler utan att samma ärendenummer och entitets-ID:n spelas upp igen. AutoSynthData (eller en motsvarande synth-from-failures-loop om forskningspipelinen är gated i deras stack) är kandidaten: omvandla kontrastfel till sanerade kapacitetsspecifikationskort, generera nya uppgifter, samla in lärardemonstrationer och sedan – avgörande – granska syntetiska spår av människor innan någon omskolning.

Ingenting skickas med Gym Pass@1 i sig självt. Synth-data behandlas som kandidaternas läroplan, inte som fri sanning.

Vad assistenten behöver

  • Åtkomst till den frysta miljöadaptern i Gym-stil: verktyg, seed-tillstånd, policyer och SQL-verifierare (eller motsvarande tillståndsbaserade).
  • Parade utvärderingsloggar: misslyckanden med mål jämförda med lärares framgångar med samma uppgifter.
  • Ett kortschema som fångar upp kapacitet, verktygs-/arbetsflödesform, kontrast mellan misslyckande/lyckade, nödvändiga egenskaper för slutgiltigt tillstånd och tillåtna variationsdimensioner - utan ursprungliga prompter, entiteter, banor eller verifierarens interna funktioner.
  • Regler för personligt identifierbar information (PII) och policygranskning (ärende-ID:n, användarnamn, CI-namn, reglerade fält) innan något lämnar sandlådan eller går in i en genereringsprompt.
  • En mänsklig granskningskö för samplade syntetiska uppgifter och lärarspår (genomförbarhet, realism, verifierarens sundhet, fall av avslag/ogömförbarhet).
  • Rensa stoppvillkor: Rikta in dig på faserna och multiplicera dem; multiplicerade prover leder inte till ytterligare multiplikationsomgångar.

Exempelinstruktion

Plattformen leder till läroplansoperatören (eller till en orkestreringsassistent som bara utarbetar kort och granskar paket – den omskolar eller marknadsför inte modeller):

"Kör diagnostiken Pass@1 på de frysta ITSM- och Hybrid-skivorna mot vårt nuvarande mål och den utsedda läraren. För varje kontrast där målet misslyckas och läraren lyckas med minst två av tre försök, utarbeta ett sanerat kapacitetsspecifikationskort: namnge förmågan, lista relevanta verktyg, ange nödvändiga egenskaper för slutgiltigt tillstånd och lista kontrollerbara dimensioner (prioritetsband, relaterad CI-klass, flagga för ändringsfönster, typ av kunskapskonflikt). Ta bort ärendenummer, användaridentifierare, CI-namn och råa banor. Generera en målfasbatch med nya uppgifter endast från dessa kort. Låt läraren visa framgångar. Tillämpa svårighetsband (mål ≤1/3, lärare ≥2/3), positiv och negativ verifiering och begränsad kritik/reparation. Skapa ett granskningspaket med 5 % stratifierade prover plus varje avslags-/oföränderlighetskort. Starta inte SFT förrän två granskare godkänner paketet och PII-scrubkontroller är godkända. Efter SFT på en kandidatkontrollpunkt, utvärdera igen på den frysta sviten och på en holdout-exakt matchningsuppsättning som vi aldrig använde för generering. Rapportera täckning efter misslyckandeklass och regressionsfrekvens kontra den tidigare produktionskontrollpunkt. Marknadsför inte på gympoäng ensamt.”

Hur man testar det

  1. Baslinjelås: Registrera Pass@1- och verifierarframgångsfrekvenser på den frysta sviten per felklass (förutsättningsordning, vägran i ändringsfönster, hybrid-korsverktyg, kunskapskonflikt). Håll sviten och frön oföränderliga under cykeln.
  2. Kortrevision: Stickprovskontrollera att generatorer aldrig får originaluppmaningar, entiteter eller lärarspår – endast kort.
  3. Provkvalitetskontroll: Bekräfta att positiva banor klarar verifieringarna och att muterade felaktiga resultat misslyckas. Avvisa uppgifter som är triviala för målet eller slantsinglar för läraren.
  4. Mänsklig granskning: Granskare markerar varje prov som behåll/reparera/ta bort baserat på genomförbarhet, realism och policysäkerhet. Spåra granskarnas överenskommelse om en delad delmängd.
  5. Exakt matchning av utelämnade uppgifter: Efter kandidatens SFT, poängsätt en utelämnad mängd verkliga (eller tidigare frysta) uppgifter som aldrig var indata för kartläggning eller generering. Poängsätt separat nästan parafraser av träningsuppgifter för att upptäcka ytlig memorering.
  6. Regressionsgrind: Alla felklasser som förvärras jämfört med föregående produktionskontrollpunkt blockerar befordran tills de förklaras eller åtgärdas.

Resultat

Hitta inte på procentsatser för bake-off här. Använd en mätplan och märk publicerade forskningssiffror som ARTIKELPÅSTÅENDE när du citerar dem.

Mätplan (vad detta team ska rapportera):

  • Täckning av felklass: andel diagnostiserade gapklasser som producerade ≥N accepterade uppgifter i målfasen efter kvalitetskontroll (definiera N i förväg, t.ex. 20 accepterade uppgifter per klass).
  • Exakt matchning av holdout: Pass@1 / verifierare lyckades på den orörda holdouten före vs efter kandidat-SFT (samma seeds, samma verifierare).
  • Regressionsfrekvens: antal felklasser där Pass@1 faller jämfört med den tidigare produktionskontrollpunkten; blockera om någon säkerhetskritisk klass regredierar.
  • Granskningsutbyte: behåll/reparera/drop-frekvensen på det mänskliga granskningspaketet; om drop-frekvensen stiger, pausa Multiplicera och fixa kort eller verifierare.
  • Scrub-fel: antal prover som inte klarar PII/policykontroller före granskningsgodkännande (mål: noll escapes till SFT-mängden).

ARTIKELPÅSTÅENDE (författarrapporterat på EnterpriseOps Gym - inte detta teams uppmätta resultat): Hybridkörningar med Gemma-4-26B-A4B-it som mål och Qwen3.8-27B som lärare producerade cirka 2 000 prover på ungefär 18 timmar, med medelvärdet Pass@1 upp cirka 7,2 procentenheter och verifierarframgången som ökade från 63,01 % till 68,55 %. ITSM med DeepSeek-V4.1-Flash som lärare ökade medelvärdet Pass@1 från 18,77 % till 27,18 % på cirka 1 994 prover över en längre körning (~66 timmar). Behandla dessa som undersökta signaler på specifika domäner och parningar, inte en universell garanti för en brittisk produktionsstack.

Illustrativ programform (antaganden, inte uppmätta vinster): Om teamet accepterar ~2 000 QC-styrda prover för en ITSM-cykel, budgeterar lärarinferens plus granskning med 5 % stratifierat urval och endast främjar när holdout inte leder till regression av säkerhetskritiska klasser, är "resultatet" de kan hävda med ärligt talat processmognad - granskad läroplan, rengjorda spår och jämförbara frysta svitsdelta - inte en utlovad procentuell ökning.

Vad kan gå fel

  • Att behandla synth som fri sanning: Att hoppa över mänsklig granskning eller negativ verifiering låter tillåtande verifierare erkänna skräp i stor skala.
  • Entitetsläckage: Att mata in ursprungliga ärende-ID:n eller lärarspår i generatorn inbjuder till överanpassning av parafraser; det finns kort för att förhindra detta.
  • Obegränsad multiplikation: Att låta multiplicerade prover så ytterligare omgångar driver bort från den namngivna förmågan.
  • Gym-poängleverans: Marknadsföring eftersom fryst Pass@1 ökade medan holdout eller skuggtrafik i produktion försämrades.
  • Svagt lärartak: Om läraren inte klarar framgångsbandet ≥2/3, lär SFT ut otillförlitliga demonstrationer.
  • Fuzzy-verifierare: Chattrubriker istället för statsbaserade kontroller betygsätter flytande felaktiga slutresultat som lyckade.
  • Vägran att underutbilda: Att endast optimera för slutförbara mutationer gör förändringsfönstret och avslag på policyer sköra.
  • PII-escape: Syntetiska prompter som återinför riktiga CI eller användarnamn efter en ytlig scrub.

Praktisk avhämtning

Använd loopar i AutoSynthData-stil – eller ett motsvarande synth-från-fel-mönster om ServiceNow CoreAI-pipelinen inte är tillgänglig i din tenancy – för att multiplicera hårda, verifierbara ITSM-fall från diagnostiserade luckor. Sanera till kapacitetskort, gate med svårighetsgrad och positiv/negativ verifiering, skrubba PII och granska prover från människor före SFT. Mät täckning av felklass, exakt matchning för holdout och regressionsfrekvens. Citera endast Gym-siffror som externt forskningssammanhang. Synth-data är bränsle i läroplanen, inte en garanti: granska prover, håll sviten fryst för rättvis jämförelse och leverera aldrig på Gym-poäng ensam.

Vanliga frågor

Vad är AutoSynthData och vilket problem riktar det sig mot?

AutoSynthData är en ServiceNow CoreAI / ServiceNow-AI-pipeline, beskriven av Esakkivel Esakkiraja, som sammanför en målagents misslyckanden med en starkare lärares vinster till validerade syntetiska träningsuppgifter för företagsmiljöer. Den fokuserar på miljökompetens - lokala policyer, scheman, verktyg och tillstånd - snarare än bred allmän kunskap. Poängen är att mångfaldiga hårt, kontrollerbart arbete så att övervakad finjustering kan åtgärda miljöspecifika luckor istället för att spela upp samma trasiga ärende igen.

Varför skiljer sig miljökompetens från bred modellkapacitet?

Företagsagenter snubblar ofta eftersom själva miljön är specifik: ärendepolicyer, schemarelaterade egenheter, verktygskontrakt, seedade databaser och arbetsflöden mellan system. En modell som ser stark ut på öppna benchmarks kan fortfarande frysa i ett ändringsfönster, en CMDB-relation eller en verifierare som inspekterar slutgiltigt tillstånd. Bred kapacitet är inte detsamma som att veta hur dina system, regler och datatillstånd beter sig under policystyrda övergångar.

Vilken praktisk uppgiftsform använder AutoSynthData?

En fungerande form är uppgiften lika med systemspecifikation, användarprompt och verifierare. Systemspecifikationen innehåller begränsningar, policyer och initialt tillstånd såsom databasfrön och kunskapsartiklar. Användarprompter poängsätts utifrån genomförbarhet, realism och svårighetsgrad. Verifierare förlitar sig helst på SQL-baserade eller tillståndsbaserade resultatkontroller så att de betygsätter världen efter att agenten agerat, inte bara den exakta token-sökvägen som tagits.

Hur förhindrar sanerade funktionsspecifikationskort överanpassning?

Diagnostik körs i jämförelser där målet misslyckas och läraren lyckas, och destillerar sedan dessa fall till sanerade kapacitetsspecifikationskort. Ett kort registrerar kapacitet, verktyg eller arbetsflödesform, misslyckad/lyckad-kontrast, nödvändiga slutgiltiga tillståndsegenskaper och dimensioner som kan variera. Generatorn ser aldrig ursprungliga prompter, entiteter, banor eller verifierardetaljer - bara korten - så nya uppgifter pressar den hårda kärnan utan att parafrasera en memorerad episod.

Vilka är Target- och Multiply-faserna i pipelinen?

Målfasen koncentrerar sig på kärngranskade prover runt luckor - de uppgifter med högst signal nära där den svaga agenten bryts. Multiplikationsfasen snurrar nya varianter av accepterade mål. Multiplicerade prover kan inte så ytterligare multiplikationsomgångar, vilket håller driften bort från den namngivna förmågan i schack. Efter övervakad finjustering flyttar omvärderingen läroplanen mot återstående luckor som en rörlig gräns snarare än en statisk dump.

Hur säkerställer kvalitetskontroll på provnivå att syntetiska uppgifter säkerställs?

Ett filter för svårighetsgraden hos lösaren gynnar uppgifter som målet löser i högst ett av tre försök medan läraren lyckas i minst två av tre. Positiv verifiering behöver en referensbana för att klara sig; negativ verifiering behöver muterade felaktiga resultat för att misslyckas. En kritik- och reparationsslinga med en gräns för återförsök försöker reparera nära misslyckanden, och meta-granskning på batchnivå kontrollerar täckning, mångfald, redundans och misslyckade mål över hela uppsättningen.

Vilken arkitektur använder AutoSynthData över företagsdomäner?

Den parar ihop en delad styrenhet med en miljöadapter. Styrenheten kör diagnos, kartläggning, generering, lärardemonstrationer, kvalitetsgrindar och batchgranskning. Adaptern kopplar dessa steg till en konkret sandlåda – verktyg, tillstånd, policyer och verifierare – så att samma kontrollslinga kan peka på olika domäner utan att behöva skriva om läroplanens logik från grunden.

Vad är EnterpriseOps Gym i detta forskningssammanhang?

EnterpriseOps Gym är den storskaliga Enterprise Agent-bänken som används som stresstestbädd, med cirka 1 150 expertkurerade uppgifter över 8 domäner, ungefär 512 verktyg, cirka 164 databastabeller, containeriserad exekvering, SQL-baserad resultatverifiering, policystyrda operationer, hybridscenarier och långsiktiga tillståndsbaserade banor. AutoSynthData framställs inte som att den uppfann det gymmet; gymmet visar syntesloopen i aktion.

Vilka författarrapporterade resultat visas för Hybrid- och ITSM-inställningar?

På EnterpriseOps Gym producerade Hybrid-körningar med Gemma-4-26B-A4B-it som mål och Qwen3.8-27B som lärare cirka 2 000 prover på ungefär 18 timmar, med medelvärdet för Pass@1 upp cirka 7,2 procentenheter och verifierarframgången som ökade från 63,01 % till 68,55 %. ITSM med DeepSeek-V4.1-Flash som lärare ökade medelvärdet för Pass@1 från 18,77 % till 27,18 % på cirka 1 994 prover under en längre körning. Behandla dessa som undersökta signaler på specifika parningar, inte en universell produktionsgaranti.

Vilka misstag bör team undvika när de använder synth-from-failures-loopar?

Behandla inte syntetisk data som fri sanning och hoppa inte över mänsklig granskning och negativ verifiering. Undvik att mata in ursprungliga ärende-ID:n eller lärarspår i generatorn, låta multipla prover ge upphov till ytterligare omgångar eller att marknadsföra sig på Gym Pass@1 ensamt medan utebliven trafik eller skuggtrafik förvärras. Se även svaga lärare under framgångsbandet, suddiga chattrubriker istället för tillståndskontroller, fall av underutbildningsvägran och PII som undslipper efter en ytlig granskning.

Referenser

  1. Kramande ansikte — AutoSynthData — huggingface.co
  2. EnterpriseOps Gym — enterpriseops-gym.github.io
  3. arXiv — arxiv.org
  4. GitHub — EnterpriseOps-Gym — github.com
Frågesport
1. Vilket problem riktar sig ServiceNow CoreAIs AutoSynthData främst mot?

2. Varför destillerar AutoSynthData fel till sanerade funktionsspecifikationskort?

3. Vilket svårighetsintervall föredrar det beskrivna lösningsfiltret för träningsuppgifter?

4. Hur är AutoSynthDatas kontrollslinga strukturerad över olika miljöer?

5. Vilken författarrapporterad Pass@1-ändring citeras för Gemma-4-26B-A4B-it-målet på EnterpriseOps Gym Hybrid?


Tillbaka till bloggen