AutoSynthData: Генериране на обучаващи данни за корпоративни агенти

Корпоративните организации се нуждаят от агенти, които работят добре в собствената им среда. Работата, която възлагат на тези агенти, се определя от използваните системи, правилата, които следват, и състоянието на данните им. Един модел може да е способен в широк спектър от задачи и въпреки това да изпитва затруднения в конкретна среда: работен процес, с който се справя зле, комбинация от инструменти, които използва неправилно, или ограничение, което не спазва. Именно тези слабости трябва да подобри една корпоративна организация.

Трудността се състои в превръщането на тези слабости в обучаващи данни. Един отделен неуспех ни дава определена информация, но обучението на модел изисква множество нови задачи, които упражняват същата способност в различни ситуации. Тези задачи трябва също да могат да бъдат изпълнени в съответната среда, да наподобяват работа, която някой действително би възложил, и да имат надежден начин за проверка дали агентът е успял.

В ServiceNow CoreAI създадохме AutoSynthData, за да превръщаме пропуските в способностите в обучаващи данни. То използва неуспехите на целевия модел и успехите на по-силен учител, за да определи какво трябва да научи моделът след това, а после генерира и проверява нови задачи, които упражняват тези способности. С подобряването на модела учебната програма се насочва към това, което той все още намира за трудно. Илюстрираме конвейера с EnterpriseOps Gym (Malay и др., 2026), като използваме публикувания набор от данни. Започваме с описание на средата, в която работи агентът, и на това, което прави една задача полезна за обучение.

Какво прави една агентска задача полезна?

Агентската среда определя света, в който работи агентът: състоянието, което той може да наблюдава и променя, инструментите и API интерфейсите, които може да извиква, и преходите между състоянията, породени от действията му.

Задачата се инстанцира в тази среда. Използваме следната абстракция:

задача = (системна спецификация, потребителска подкана, проверяващ механизъм)

Системна спецификация

Системната спецификация определя ограниченията, при които работи агентът, включително системните инструкции, политиките на средата и, когато е приложимо, специфична за задачата инициализация, като начално състояние на база данни или набор от информационни статии.

Спецификацията трябва да е съвместима с инструментите, състоянието и поддържаните действия на средата. Инструкциите ѝ трябва да са ясни и да избягват произволни ограничения, въведени единствено за изкуствено създаване на трудност.

Задача, предназначена за агента

Потребителската подкана указва какво иска потребителят да постигне агентът, заедно с ограниченията на потребителско ниво. Генерираната задача трябва да отговаря на три свойства.

Изпълнимост. В текущата среда трябва да съществува поне една траектория, която удовлетворява потребителската подкана, като същевременно спазва системната спецификация. Това изключва задачи, зависещи от недостъпни инструменти, недостъпни знания, невъзможни преходи между състояния или действия, забранени от политиката.

Реалистичност. Потребителската подкана трябва да наподобява нещо, което потребител правдоподобно би поискал в целевата среда. Пространството на изпълнимото поведение обикновено е много по-голямо от пространството на реалистичните работни процеси.

Трудност. За целите на обучението задачата трябва да разкрива слабост на текущия агент. Задачите, които вече се решават надеждно, предоставят малко нов обучаващ сигнал. Следователно полезният регион се състои от задачи, които са изпълними и реалистични, но все още не се решават последователно.

Проверяващ механизъм

Проверяващият механизъм определя дали получената траектория успешно изпълнява задачата. Той трябва да притежава три свойства.

Съгласуваност. Той трябва да съответства на потребителската подкана, системната спецификация и специфичното за задачата състояние на средата.

Коректност. Той трябва да отхвърля траектории, които не изпълняват задачата или нарушават съответните ограничения.

Пълнота. Той трябва да приема валидни решения, вместо да кодира една конкретна референтна траектория.

Тези свойства имат пряко значение по време на обучението. Твърде либералният проверяващ механизъм може да възнаграждава неправилно поведение, докато прекалено рестриктивният може да санкционира валидни решения.

Общ преглед

Като получава среда и целеви модел, AutoSynthData генерира обучаващи задачи, състоящи се от системна спецификация, потребителска подкана и проверяващ механизъм. Генерираните задачи са обвързани със средата и подбрани така, че да предоставят полезен обучаващ сигнал за текущия модел.

AutoSynthData първо оценява целевия модел в средата с помощта на диагностични задачи и идентифицира модели в задачите, които той не успява да изпълни. По-силен учител помага да се определи кои от тези задачи са решими и как изглежда успешното поведение. AutoSynthData превръща получените пропуски в способностите в нови изпълними задачи, проверява всяка задача в средата и използва приетите примери за дообучаване. Оценяването на обновения модел разкрива кои пропуски остават и може да насочи следващия кръг на генериране.

От неуспехите на модела към учебна програма

AutoSynthData използва оценявания в целевата среда, за да определи какво трябва да научи моделът след това. В експеримента ни с EnterpriseOps Gym изпълняваме както целевия модел, така и по-силен учител върху задачите за оценяване. Анализираме тези изпълнения, за да идентифицираме:

• тестваната способност;
• използваните инструменти и структурата на работния процес;
• къде целевият модел се проваля и как учителят успява;
• свойствата, на които трябва да отговаря правилното крайно състояние;
• измеренията, които могат да се променят, без да се наруши тестваната способност.

Синтезираме тези констатации в карти със спецификации на анонимизирани способности. Задачите за оценяване определят какво трябва да научи моделът, но генераторът не получава техните оригинални подкани, обекти, траектории или подробности за проверяващите механизми. Той получава картите и ги използва за създаване на нови задачи с различни подкани, състояния и пътища към решението.

Генериране и мащабиране на задачи

Идентифицирането на пропуск в дадена способност ни показва какво трябва да преподаваме, но обучението изисква множество разнообразни задачи, които я упражняват. AutoSynthData използва картата със спецификация, за да генерира тези задачи.

Да предположим, че целевият модел изпитва затруднения със задачи, изискващи следния работен процес:

Генераторът създава нови задачи, които упражняват този работен процес, като променя обектите, началното състояние на средата, композицията на работния процес, комбинациите от инструменти, формулировката и трудността. След това по-силният учител демонстрира успешна траектория за всяка задача. При контролирано дообучаване (SFT) тези демонстрации учат целевия модел как да прилага способността в нови ситуации.

AutoSynthData изгражда набора от данни на два етапа: първо генерира и проверява основни примери, а след това ги разширява с нови варианти.

Target

Етапът Target създава основния набор от обучаващи примери от спецификациите на способностите. Работниците генерират независими задачи паралелно, като поемат нова цел, когато приключат. Всеки кандидат преминава през проверка, изпълнение, оценяване от решаващ механизъм и поправка, преди да бъде приет. Резултатът е пакет от проверени примери, изграден около това, което целевият модел трябва да научи.

Multiply

Етапът Multiply разширява набора от данни чрез създаване на нови варианти на приетите целеви примери. Всеки вариант има собствена потребителска заявка, състояние на средата, конфигурация на обектите, референтна траектория и проверяващ механизъм и трябва да премине същите проверки за валидиране и изпълнение. Умножен пример не може да служи като основа за друг умножен пример. Така разширяването се обвързва с проверения целеви набор и се ограничава отклонението между поколенията.

Подробности за реализацията

За да поддържа и двата етапа, AutoSynthData разделя контрола на генерирането от специфичното за средата изпълнение. Споделен контролер координира генерирането, контрола на качеството, покритието и изграждането на набора от данни, докато адаптерът обработва изпълнението в средата, управлението на задачите и състоянието, възпроизвеждането на референтни траектории, детерминистичната проверка, изпълнението на решаващия механизъм и профилирането на задачите.

Заедно паралелното генериране на целеви примери и умножаването предоставят път към набори от данни с мащаба, необходим за обучение. Полезността им зависи от проверките, прилагани към всеки кандидат: задачата трябва да е изпълнима, решението трябва да работи, а проверяващият механизъм трябва да разграничава успеха от неуспеха.

Висококачествените синтетични данни изискват повече от генериране

Генерирането на правдоподобна заявка не е достатъчно за създаването на полезни обучаващи данни. Една задача може да е невъзможна в целевата среда, референтното ѝ решение може да се провали при изпълнение или проверяващият ѝ механизъм може да възнаграждава неправилно крайно състояние. AutoSynthData проверява тези свойства, преди да приеме задача за обучение.

AutoSynthData преглежда качеството на две нива: отделните кандидати трябва да преминат проверка, а пакетите трябва да осигуряват полезно покритие и разнообразие.

Проверка и поправка на ниво пример

Всеки кандидат трябва да премине цикъл за контрол на качеството, преди да влезе в обучаващия набор от данни. Започваме с оценяване от решаващ механизъм, за да измерим трудността. В използваната тук конфигурация предпочитаме задачи, които целевият модел решава в не повече от един от три опита, а по-силният решаващ механизъм решава в поне два от три опита. Кандидатите преминават също през положителна и отрицателна проверка и ограничен процес на поправка.

Положителна проверка

Положителният етап задава въпроса: Решава ли предвиденото решение генерираната задача?

Конвейерът изпълнява референтната траектория в целевата среда и сравнява полученото състояние с проверяващия механизъм на кандидата. Това разкрива несъответствия между подканата, началното състояние, решението и критериите за успех.

Отрицателна проверка

Отрицателният етап задава въпроса: Неуспешни ли са съответните неправилни резултати?

Например той може да промени части от очаквания резултат и да потвърди, че тези състояния вече не преминават проверката. Така се откриват слаби проверяващи механизми, които отчитат успех, без да изискват предвиденото поведение.

Критика и поправка

Неуспешните кандидати се изпращат на критик, преди да бъдат отхвърлени. Критикът изследва примера и неговия неуспех, като търси несъгласувано състояние, невъзможни работни процеси, неправилно конструиране на задачата, лоши референтни траектории, слаба логика на проверяващия механизъм или несъответствие с предвидената способност. Констатациите на критика насочват поправките, с фиксиран лимит на повторните опити:

кандидат
↓
неуспех
↓
критика / диагностика
↓
целева поправка
↓
повторно изпълнение на етапите
↓
приемане или нов опит

Поправената задача трябва отново да премине съответните проверки. Диагностиката насочва поправките към съществуващия кандидат, вместо да изисква генерирането да започне отначало.

Преминаването на тези проверки прави примера допустим за обучение, но отделни валидни примери все пак могат да образуват повтарящ се или небалансиран набор от данни. Затова AutoSynthData преглежда генерирането и на ниво пакет.

Преглед на ниво пакет

Един пакет може да представя прекомерно няколко лесни семейства задачи, да пропусне определена способност или да отразява прекалено много усилия за генериране, вложени в модел с ниска възвръщаемост.

Метаанализът разглежда приетите и отхвърлените примери, както и поведението при генериране във всеки пакет. Той задава следните въпроси:

• Кои семейства задачи са представени прекомерно и кои измерения на способностите липсват?
• Появяват ли се многократно едни и същи видове примери?
• Има ли конкретни цели, при които генерирането постоянно се проваля?
• Появяват ли се систематични проблеми в критиките?
• Какви насоки трябва да се променят за следващия пакет?

Контролерът проследява покритието в приетия набор от данни, намалява генерирането в прекомерно представените области и насочва повече работа към пропуските. Когато дадена област многократно генерира лоши кандидати, критиките и метаанализът насочват промените в стратегията за генериране. Тези корекции балансират полезния обучаващ сигнал, качеството на задачите, покритието, разнообразието и ниската излишност в рамките на наличния бюджет за генериране и изискванията за размера на набора от данни.

Заедно тези контури за обратна връзка подобряват както отделните задачи, така и набора от данни, който те образуват: проверките на ниво пример насочват поправката на кандидатите, а прегледът на ниво пакет насочва бъдещото генериране.

Преместване на границата на обучението

Полезното разпределение на обучението се променя с подобряването на модела. AutoSynthData разглежда генерирането на синтетични данни като търсене на задачи близо до границата на способностите на целевия модел: достатъчно трудни, за да разкрият слабости, но достатъчно решими, за да може учителят да предостави надеждни демонстрации.

След дообучаването оценяваме обновения модел в същата среда. Задачите, които той вече решава надеждно, са по-малко полезни за следващия кръг на обучение; постоянните неуспехи сочат към способности, които все още изискват внимание. Тези резултати могат да насочат следващия кръг на генериране.

Експериментите ни са съсредоточени върху SFT, но същият механизъм би могъл да поддържа и обучение с подсилване (RL): генериране на задачи, които предизвикват текущата политика и предоставят надежден обучаващ сигнал, обучение, а след това преместване на целта за генериране с обновената политика. Планираме да тестваме тази подвижна, калибрирана спрямо трудността граница отвъд SFT.

Експерименти с EnterpriseOps Gym

Използваме EnterpriseOps Gym, за да проверим дали този подход подобрява модел при задачи в корпоративна среда със състояние. Генерираме обучаващи задачи в средите Hybrid и ITSM на Gym, дообучаваме целевия модел върху приетите примери и оценяваме получените контролни точки.

Hybrid

Тествахме конвейера в домейна Hybrid на EnterpriseOps Gym, като използвахме Gemma-4-26B-A4B-it като целеви модел и Qwen3.8-27B като учител.

AutoSynthData генерира 2000 синтетични обучаващи примера за около 18 часа. Дообучихме Gemma върху този набор от данни и оценихме получените контролни точки върху бенчмарка. Най-добрата контролна точка беше епоха 5.

Резултати за Hybrid

Синтетичната SFT контролна точка подобрява средния Pass@1 със 7,2 процентни пункта, което е относително подобрение от 35%, и повишава успеха на проверяващия механизъм от 63,01% на 68,55%. Тя заличава 59% от първоначалната разлика в Pass@1 между Gemma и референтния модел.

Обучаващите задачи бяха новогенерирани от спецификации на способностите; генераторът не получи оригиналните задачи за оценяване. Резултатът демонстрира подобрение в Hybrid на EnterpriseOps Gym — средата, използвана за този експеримент.

ITSM

Приложихме AutoSynthData и към домейна ITSM на EnterpriseOps Gym, като използвахме Gemma-4-26B-A4B-it като целеви модел и DeepSeek-V4.1-Flash като учител. AutoSynthData генерира 1994 синтетични обучаващи примера за 66 часа. Генерирането отне повече време, отколкото при последвалото изпълнение на Hybrid, описано по-горе, главно защото ITSM изпълнението използваше по-голям учителски модел и предхождаше оптимизациите на конвейера, които подобриха производителността.

В ITSM синтетичното SFT повишава средния Pass@1 от 18,77% на 27,18%, което показва, че подходът подобрява производителността и във втори домейн.

Затваряне на цикъла

Задачите, които са най-полезни за обучение, зависят както от средата, така и от модела, работещ в нея. AutoSynthData използва неуспехите на модела, за да избере какво да генерира, проверява новите задачи спрямо средата и ги предоставя за дообучаване. Резултатите ни от EnterpriseOps Gym показват стойността на този подход в контролирана среда. С промяната на модела същият процес може да се съсредоточи върху оставащите пропуски.

Модели, споменати в тази статия 3

Набори от данни, споменати в тази статия 1

Още от този автор