Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Синтетические корпоративные данные научились создавать без доступа к схеме базы, сохраняя связи и бизнес-правила. В препринте SAP, который не прошёл рецензирование и приводит замеры самих авторов, подход дал среднее сходство распределений отдельных полей 0,88 и выполнил 100% программных проверок в десяти средах. Для команд, которые обучают и тестируют агентов на закрытых системах, это предлагает альтернативу выгрузке производственных баз.
Корректность обеспечивает API, а не генератор
Обычный генератор табличных данных пытается воспроизвести строки из исходной выборки. Он может правдоподобно распределить должности или классы билетов, но не знает, что отпуск нельзя оформить сверх накопленного остатка, а бронирование должно ссылаться на существующий рейс.
STS меняет точку генерации. LLM-агент не пишет строки напрямую, а вызывает API имитационной корпоративной системы. API проверяет бизнес-правила перед каждой записью: недопустимую операцию отклоняет, допустимую сохраняет. Полученный снимок базы поэтому остаётся структурно корректным при условии, что сами проверки API полностью описывают нужные правила.
Агент Generalist Populator получает только перечень функций API, их аргументы и описания. Схему базы, готовые сценарии и настройки для конкретной отрасли ему не показывают. Это соответствует ситуации, когда команда может открыть интеграционный интерфейс, но не может передать разработчикам или внешней модели внутреннюю структуру производственной базы.
Работа агента разделена на три этапа. Сначала он изучает доступные операции, отличает чтение от записи и восстанавливает зависимости между сущностями. Затем формулирует ограниченную задачу, например создаёт клиента и оформляет для него поездку с заданными признаками. На последнем этапе он находит актуальные идентификаторы, выполняет вызовы в нужном порядке и сохраняет удачные способы обходить тупиковые ветки.
Так авторы разделяют две задачи. Среда отвечает за допустимость состояния, а модель — за то, насколько часто встречаются разные значения и сочетания. Если доступны эталонные распределения, планировщик использует их; иначе опирается на знания LLM, а значит переносит в данные её представления и перекосы.
Планирование оказалось важнее объёма записей
Метод проверяли на средах для кадрового учёта, авиабронирования, банковских операций, торговли, облачной инфраструктуры и других корпоративных областей. Сравнение включало CTGAN, TVAE, SDV HMA и REaLTabFormer, а также EnvScaler — агента, которому были доступны схема базы, её текущее состояние и бизнес-правила.
Качество распределений измеряли на трёх уровнях: отдельно для каждого поля, для пар полей внутри таблицы и для числа связанных дочерних записей. Последний уровень, например, показывает, похоже ли количество подсетей у виртуальной сети на эталонное, а не только допустима ли сама связь.
Доступ к схеме не гарантировал успеха. В среде авиабронирования EnvScaler не записал ничего в 82% попыток: он подставлял идентификаторы при составлении задачи, а к моменту выполнения они уже не соответствовали состоянию среды. Generalist Populator сначала запрашивал актуальные сущности через API и поэтому не зависел от заранее встроенных ссылок.
Три ознакомительные попытки повысили сходство совместных распределений в авиасреде с 0,813 до 0,900. Дальнейшее изучение заметной пользы не дало. Без накопленных подсказок агенту требовалось на 96% больше вызовов API на одну успешную запись: даже короткая рекомендация сначала запросить существующие бронирования устраняла повторяющиеся ошибки.
Простая команда «заполни базу» создавала больше записей, но ухудшала все показатели сходства. Агент повторял лёгкие операции и редко собирал сложные сценарии. Узкий план на каждую попытку лучше удерживал нужное соотношение типов операций, чем максимизация количества записей.
Архитектуру стенда можно менять, производственный контур — пока нет
Работа даёт практичный шаблон для учебных и тестовых сред: сделать генератор обычным клиентом API и запретить ему прямую запись в базу. Тогда команда поддерживает правила в одном месте, а разные модели и стратегии генерации не дублируют ограничения в приглашениях, сценариях и валидаторах.
Этот вывод применим прежде всего к реляционным системам, где операции проходят через явный программный интерфейс. Если часть правил существует только в ручных процедурах, фоновых заданиях или коде других сервисов, формальная гарантия STS их не охватит. Перед внедрением придётся проверить полноту имитационного API — это может оказаться основной инженерной работой.
STS также не решает автоматически задачу статистического сходства с производством. Без безопасно подготовленных агрегатов агент угадывает частоты по знаниям модели. Для оценки агентов этого иногда достаточно, но обучение на таких данных может закрепить неверное соотношение редких и типовых случаев.
Авторы показали дальнейшее обучение Qwen2.5-7B на снимке авиасреды, однако набор включал всего 19 подходящих примеров. Результат подтверждает, что снимок можно использовать в полном цикле подготовки агента, но пока не обосновывает замену реальных или тщательно откалиброванных учебных данных.
Поэтому ближайшее применение STS — не генерация производственного двойника, а быстрое наполнение изолированных стендов связными состояниями. Командам, у которых уже есть имитационный API с полными проверками, стоит испытать такой подход вместо отдельного генератора по схеме. Если интерфейс покрывает лишь часть бизнес-логики, сначала нужно достроить среду, иначе STS гарантирует только соблюдение неполного набора правил.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
