Только 34% участников исследования доверяют тому, что синтетические данные сохраняют ссылочную целостность между таблицами. Для команд, которые хотят заменить копии боевых баз безопасными наборами для разработки и тестирования, это не мелкая придирка к качеству генерации, а стоп-сигнал для внедрения.
О проблеме сообщает The New Stack. Интерес к искусственно сгенерированным датасетам у компаний высокий: они обещают убрать из тестовых сред персональные и чувствительные сведения, сократить зависимость от согласований и быстрее выдавать разработчикам реалистичные данные. Но доверие к набору заканчивается там, где он перестаёт отражать реальные связи между сущностями.
Ссылочная целостность — это правило, по которому записи в связанных таблицах не существуют сами по себе. Заказ должен быть привязан к реальному клиенту, строка заказа — к существующему заказу, платёж — к корректному счёту. В реляционной базе такие ограничения обычно защищают внешние ключи. При генерации тестового набора нужно не просто создать правдоподобные имена, даты и суммы, а сохранить всю сеть зависимостей, включая многотабличные связи и бизнес-правила.
Если генератор создаёт красивую, но несогласованную витрину, тесты начинают врать. Часть сценариев падает на данных, которых в продакшене быть не может. Другая часть, наоборот, не воспроизводит ошибки, завязанные на историю клиента, статус документа или цепочку операций. В результате команда либо вручную чинит наборы, либо возвращается к копиям production-баз с маскировкой. Обе практики съедают то преимущество в скорости и безопасности, ради которого вообще затевались синтетические наборы.
Показатель в 34% важен ещё и потому, что речь не о недоверии к отдельным полям. Реалистично сгенерировать возраст, город или номер договора сравнительно несложно. Гораздо труднее воспроизвести распределение значений, иерархии, редкие комбинации статусов и временную последовательность событий. Для банка, маркетплейса, телеком-компании или SaaS-сервиса полезность данных определяется именно этими деталями: одна и та же запись клиента может быть связана с десятками сущностей и несколькими годами действий.
Для разработчиков вывод довольно приземлённый: синтетические данные нельзя принимать по принципу «генератор отработал без ошибки». Их стоит проверять теми же ограничениями, что и рабочую схему: внешними ключами, обязательностью полей, уникальностью идентификаторов и правилами доменной модели. Отдельный вопрос — статистическая пригодность. Набор может быть формально валидным, но не содержать редких кейсов, на которых ломается расчёт скидок, антифрод, биллинг или миграция.
Продуктовым и IT-руководителям полезно не сводить выбор инструмента к обещанию обезличить данные. Перед пилотом стоит определить, какие сценарии должен поддержать набор: модульные тесты, интеграционные проверки, нагрузочное тестирование, аналитические эксперименты или обучение моделей. Для каждого сценария нужны свои критерии качества. Например, тестировщикам критичны корректные связи и пограничные состояния, а аналитикам — сохранение распределений и закономерностей без раскрытия исходных записей.
Есть и организационная ловушка. Владельцы данных часто видят в синтетических наборах прежде всего способ снизить риски утечки, а инженерные команды — способ быстрее получить данные. Эти цели не конфликтуют, пока качество результата измеряется совместно. Если же безопасность проверяют отдельно от пригодности для тестов, компания получает формально безопасный, но практически бесполезный датасет — и закономерно объявляет технологию переоценённой.
Синтетическая генерация не отменяет работы с моделью данных: она делает её заметнее. Рынку ещё предстоит доказать, что такие наборы способны сохранять не только внешний правдоподобный вид, но и отношения, на которых держатся реальные бизнес-процессы. Пока доверие к ссылочной целостности остаётся на уровне 34%, главным конкурентом генераторов будут не другие инструменты, а привычные, рискованные и неудобные копии production-данных.