Sakhanda Wire
NVDA $230.86 +1.09% MSFT $512.80 -0.02% GOOGL $338.24 -1.70% META $725.93 +0.10% AMZN $248.23 -0.37%
← К новостям

AutoSynthData: Генерация обучающих данных для корпоративных агентов

AutoSynthData: создание обучающих данных для корпоративных агентов
Корпоративные решения Статья
Опубликовано 2 октября 2026 г.
AutoSynthData_thumbnail_1200x648 (2)

Корпоративным компаниям нужны агенты, которые хорошо работают в их собственных средах. Работа, которую они поручают этим агентам, определяется используемыми системами, соблюдаемыми правилами и состоянием данных. Модель может обладать широкими возможностями и при этом испытывать трудности в конкретной среде: плохо обрабатывать рабочий процесс, неправильно использовать определённую комбинацию инструментов или не соблюдать ограничение. Именно эти слабые места предприятию необходимо улучшать.

Сложность заключается в том, чтобы превратить эти слабые места в обучающие данные. Отдельная ошибка сообщает нам нечто важное, но для обучения модели требуется множество новых задач, проверяющих одну и ту же способность в разных ситуациях. Эти задачи также должны быть выполнимыми в данной среде, походить на работу, которую действительно мог бы запросить пользователь, и иметь надёжный способ проверки успеха агента.

В ServiceNow CoreAI мы создали AutoSynthData, чтобы превращать пробелы в возможностях в обучающие данные. Система использует ошибки целевой модели и успехи более сильной модели-учителя, чтобы определить, чему модель следует учиться дальше, а затем создаёт и проверяет новые задачи, развивающие эти способности. По мере улучшения модели учебная программа смещается к тому, что по-прежнему вызывает у неё трудности. Мы иллюстрируем этот конвейер с помощью EnterpriseOps Gym (Malay и др., 2026), используя опубликованный набор данных. Сначала мы опишем среду, в которой работает агент, и то, что делает задачу полезной для обучения.

Что делает агентную задачу полезной?

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

Задача создаётся внутри этой среды. Мы используем следующую абстракцию:

task = (спецификация системы, запрос пользователя, верификатор)

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

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

Спецификация должна быть совместима с инструментами, состоянием и поддерживаемыми действиями среды. Её инструкции должны быть понятными и не содержать произвольных ограничений, введённых исключительно для искусственного усложнения задачи.

Задача для агента

Запрос пользователя указывает, чего пользователь хочет добиться от агента, а также содержит ограничения на уровне пользователя. Сгенерированная задача должна обладать тремя свойствами.

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

Реалистичность. Запрос пользователя должен быть похож на то, что пользователь действительно мог бы попросить в целевой среде. Пространство исполнимых действий обычно значительно шире пространства реалистичных рабочих процессов.

Сложность. Для обучения задача должна выявлять слабое место текущего агента. Задачи, которые уже надёжно решаются, дают мало нового обучающего сигнала. Поэтому полезную область составляют задачи, которые выполнимы и реалистичны, но пока не решаются стабильно.

Верификатор

Верификатор определяет, успешно ли полученная траектория выполняет задачу. Он должен обладать тремя свойствами.

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

Корректность. Он должен отклонять траектории, которые не выполняют задачу или нарушают соответствующие ограничения.

Полнота. Он должен принимать корректные решения, а не кодировать одну конкретную эталонную траекторию.

Эти свойства непосредственно важны во время обучения. Слишком мягкий верификатор может вознаграждать неправильное поведение, а чрезмерно строгий — штрафовать корректные решения.

Обзор

Получив среду и целевую модель, AutoSynthData создаёт обучающие задачи, состоящие из спецификации системы, запроса пользователя и верификатора. Сгенерированные задачи привязаны к среде и отбираются так, чтобы предоставлять полезный обучающий сигнал для текущей модели.

figure-01

Сначала AutoSynthData оценивает целевую модель в среде с помощью диагностических задач и выявляет закономерности в задачах, которые ей не удаётся выполнить. Более сильная модель-учитель помогает определить, какие из этих задач решаемы, и показать, как выглядит успешное поведение. AutoSynthData превращает выявленные пробелы в возможностях в новые исполнимые задачи, проверяет каждую задачу в среде и использует принятые образцы для дообучения. Оценка обновлённой модели показывает, какие пробелы сохраняются, и может направить следующий раунд генерации.

figure-02

От ошибок модели к учебной программе

AutoSynthData использует результаты оценочных запусков в целевой среде, чтобы определить, чему модели необходимо учиться дальше. В эксперименте с EnterpriseOps Gym мы запускаем как целевую модель, так и более сильную модель-учитель на оценочных задачах. Мы анализируем эти запуски, чтобы определить:

  • проверяемую способность;
  • используемые инструменты и структуру рабочего процесса;
  • где целевая модель терпит неудачу и как добивается успеха учитель;
  • свойства, которым должно соответствовать корректное конечное состояние;
  • параметры, которые можно изменять, сохраняя проверяемую способность.

Мы сводим эти результаты в очищенные карточки спецификаций способностей. Оценочные задачи определяют, чему должна учиться модель, но генератор не получает их исходные запросы, сущности, траектории или сведения о верификаторах. Он получает карточки и использует их для создания новых задач с другими запросами, состояниями и путями решения.

figure-03

Генерация и масштабирование задач

Выявление пробела в способности говорит нам, чему нужно обучать, но для обучения требуется множество разнообразных задач, которые эту способность проверяют. AutoSynthData использует карточку спецификации для генерации таких задач.

Предположим, целевая модель испытывает трудности с задачами, требующими следующего рабочего процесса:

figure-04

Генератор создаёт новые задачи, проверяющие этот рабочий процесс, изменяя сущности, начальное состояние среды, состав рабочего процесса, комбинации инструментов, формулировки и уровень сложности. Затем более сильная модель-учитель демонстрирует успешную траекторию для каждой задачи. Для обучения с учителем (SFT) эти демонстрации учат целевую модель применять способность в новых ситуациях.

AutoSynthData создаёт набор данных в два этапа: сначала генерирует и проверяет основные образцы, а затем расширяет их новыми вариантами.

Target

На этапе Target создаётся основной набор обучающих образцов на основе спецификаций способностей. Воркеры параллельно генерируют независимые задачи, переходя к новой целевой задаче после завершения предыдущей. Каждый кандидат проходит проверку, выполнение, оценку решателем и исправление перед принятием. В результате формируется пакет проверенных примеров, ориентированных на то, чему необходимо научить целевую модель.

Multiply

На этапе Multiply набор данных расширяется за счёт создания новых вариантов принятых целевых образцов. Каждый вариант имеет собственный запрос пользователя, состояние среды, конфигурацию сущностей, эталонную траекторию и верификатор, а также должен пройти те же проверки и тесты выполнения. Умноженный образец не может служить основой для другого умноженного образца. Это привязывает расширение к проверенному целевому набору и ограничивает накопление отклонений между поколениями.

Детали реализации

Для поддержки обоих этапов AutoSynthData отделяет управление генерацией от выполнения, специфичного для среды. Общий контроллер координирует генерацию, контроль качества, покрытие и создание набора данных, а адаптер отвечает за выполнение в среде, управление задачами и состояниями, воспроизведение эталона, детерминированную проверку, запуск решателя и профилирование задач.

В совокупности параллельная генерация целевых задач и их умножение обеспечивают путь к наборам данных масштаба, необходимого для обучения. Их полезность зависит от проверок, применяемых к каждому кандидату: задача должна выполняться, решение должно работать, а верификатор должен отличать успех от неудачи.

figure-05

Для качественных синтетических данных одной генерации недостаточно

Одной правдоподобной формулировки запроса недостаточно для создания полезных обучающих данных. Задача может быть невыполнимой в целевой среде, её эталонное решение может завершиться ошибкой при выполнении, а верификатор может вознаграждать неправильное конечное состояние. AutoSynthData проверяет эти свойства, прежде чем принять задачу для обучения.

AutoSynthData оценивает качество на двух уровнях: отдельные кандидаты должны пройти проверку, а пакеты должны обеспечивать полезное покрытие и разнообразие.

Проверка и исправление на уровне образцов

Каждый кандидат должен пройти цикл контроля качества, прежде чем попасть в обучающий набор данных. Мы начинаем с оценки решателем, чтобы измерить сложность. В используемой здесь конфигурации мы отдаём предпочтение задачам, которые целевая модель решает не более чем в одной из трёх попыток, а более сильный решатель — как минимум в двух из трёх попыток. Кандидаты также проходят положительную и отрицательную проверку, а затем ограниченный процесс исправления.

figure-06

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

Положительная проверка задаёт вопрос: решает ли предполагаемое решение сгенерированную задачу?

Конвейер выполняет эталонную траекторию в целевой среде и сравнивает полученное состояние с верификатором кандидата. Это выявляет несоответствия между запросом, начальным состоянием, решением и критериями успеха.

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

Отрицательная проверка задаёт вопрос: приводят ли релевантные неправильные результаты к неудаче?

Например, она может изменять части ожидаемого результата и подтверждать, что такие состояния больше не проходят проверку. Это выявляет слабые верификаторы, которые засчитывают успех без требования предполагаемого поведения.

Критика и исправление

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

кандидат
↓
неудача
↓
критика / диагностика
↓
целевое исправление
↓
повторный запуск проверок
↓
принять или повторить

Исправленная задача должна снова пройти соответствующие проверки. Диагностика направляет исправление существующего кандидата, поэтому генерацию не нужно начинать заново.

Прохождение этих проверок делает образец пригодным для обучения, но по отдельности корректные образцы всё ещё могут образовать повторяющийся или несбалансированный набор данных. Поэтому AutoSynthData также оценивает генерацию на уровне пакета.

Проверка на уровне пакета

В пакете могут быть чрезмерно представлены несколько простых семейств задач, может отсутствовать определённая способность или слишком много усилий генерации может быть потрачено на малопродуктивный шаблон.

Метаанализ изучает принятые и отклонённые образцы, а также поведение генерации в каждом пакете. Он задаёт следующие вопросы:

  • Какие семейства задач представлены чрезмерно, а какие измерения способностей отсутствуют?
  • Повторяются ли одни и те же типы примеров?
  • Продолжают ли определённые цели регулярно приводить к сбоям генерации?
  • Появляются ли в критике систематические проблемы?
  • Какие рекомендации следует изменить для следующего пакета?

Контроллер отслеживает покрытие в принятом наборе данных, сокращает генерацию в чрезмерно представленных областях и направляет больше работы на пробелы. Если определённая область неоднократно порождает плохих кандидатов, критика и метаанализ направляют изменения стратегии генерации. Эти корректировки обеспечивают баланс между полезным обучающим сигналом, качеством задач, покрытием, разнообразием и низкой избыточностью в рамках доступного бюджета генерации и требований к размеру набора данных.

В совокупности эти циклы обратной связи улучшают как отдельные задачи, так и образуемый ими набор данных: проверки на уровне образца направляют исправление кандидатов, а проверка на уровне пакета — будущую генерацию.

Расширение границы обучения

Полезное распределение обучающих данных меняется по мере улучшения модели. AutoSynthData рассматривает генерацию синтетических данных как поиск задач вблизи границы возможностей целевой модели: достаточно сложных, чтобы выявлять слабые места, но достаточно решаемых, чтобы учитель мог предоставлять надёжные демонстрации.

После дообучения мы оцениваем обновлённую модель в той же среде. Задачи, которые она теперь решает надёжно, менее полезны для следующего раунда обучения; сохраняющиеся ошибки указывают на способности, требующие дальнейшего внимания. Эти результаты могут направить следующий раунд генерации.

figure-07

Наши эксперименты сосредоточены на 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 на этом наборе данных и оценили полученные контрольные точки на бенчмарке. Лучшей стала контрольная точка пятой эпохи.

Результаты Hybrid

Синтетическая контрольная точка SFT повышает средний Pass@1 на 7,2 процентного пункта, что соответствует относительному улучшению на 35%, и увеличивает долю успеха верификатора с 63,01% до 68,55%. Она закрывает 59% исходного разрыва по Pass@1 между Gemma и эталонной моделью.

figure-08

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

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%, показывая, что этот подход также улучшает производительность во втором домене.

figure-09

Замыкая цикл

Наиболее полезные для обучения задачи зависят как от среды, так и от модели, работающей в ней. AutoSynthData использует ошибки модели, чтобы выбрать, что генерировать, проверяет новые задачи в среде и делает эти задачи доступными для дообучения. Наши результаты в EnterpriseOps Gym демонстрируют ценность этого подхода в контролируемых условиях. По мере изменения модели тот же процесс может сосредоточиться на сохраняющихся пробелах.

Модели, упомянутые в этой статье 3

Наборы данных, упомянутые в этой статье 1

Сообщество

Загружайте изображения, аудио и видео, перетаскивая их в текстовое поле, вставляя или нажимая здесь.
Нажмите или вставьте сюда, чтобы загрузить изображения

· Зарегистрируйтесь или войдите, чтобы оставить комментарий

Модели, упомянутые в этой статье 3

Наборы данных, упомянутые в этой статье 1

Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.

Впервые опубликовано изданием Hugging Face

Читать оригинал на Hugging Face ↗

Текст и изображения принадлежат Hugging Face и приводятся здесь с указанием авторства и ссылкой на оригинальную публикацию.

← К новостям

Ещё новости

Все последние новости