Синтетические данные для тестирования: пошаговый гайд

Как построить конвейер обезличенных синтетических данных и убедиться, что они не врут? Собрал полезную статью для руководителей разработки и QA, продакт-менеджеров и всех, кто работает с тестовым контуром.

Я уже более 10 лет работаю с тестовыми средами, и раньше делал ошибку: выгружал из прода 200 000 строк, менял фамилии на обезличенные шаблоны, и считал, что все окей. А затем как-то заметил, что в выгрузке остались номера договоров. Мне повезло, что именно я нашел их первым, особенно учитывая всё более суровую регуляторку. С тех пор я отношусь к тестовым данным также серьезно, как к проду.

И я такой не один. По опросу «Гарды» среди российских компаний почти половина регулярно переносит в тестовые среды копии продуктивных баз без изменений, а 18,8% держат тестовые базы в том же кластере, что и боевые. При этом с 30 мая 2025 года по 420-ФЗ утечка данных 1 000–10 000 человек стоит юрлицу от 3 до 5 млн рублей, а повторная – от 1% до 3% годовой выручки, минимум 25 млн.

Какие задачи решает создание синтетических массивов?

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

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

Уровни реалистичности синтетических тестовых данных

Синтетические данные бывают очень разными: от незаполненных болванок с правильными типами полей до почти полной копии прода.

Уровень выбирается под задачу (об этом писал выше). Для регресса хватает второго, для нагрузочного тестирования нужен четвертый, для машинного обучения – пятый. Шестой в корпоративной практике чаще всего не нужен.

Маскирование, псевдонимизация и синтез с юридической точки зрения

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

Маскирование с обратимым ключом – это псевдонимизация. Вы заменили фамилию на код, а ключ положили в хранилище. Субъекта без ключа не определить. Но ключ существует, а значит это по-прежнему персональные данные. Тестовый контур остается ИСПДн со всеми требованиями к защите, и штрафы за утечку из него ложатся на вас.

Обезличивание регулируется жестко. С 1 сентября 2025 года действует приказ Роскомнадзора № 140 от 19.06.2025 (замена прежнего № 996 от 2013 г.). Методы в целом те же: идентификаторы, перемешивание, изменение состава и семантики, декомпозиция – плюс новый метод преобразования массива. Очень важны требования к самому процессу, и их редко кто читает.

Что требует приказ № 140 и что из этого ломает привычную практику:

• Нельзя хранить обезличенные данные вместе с исходными. Никаких рядом лежащих clients и clients_masked.

• Ключ соответствия хранится отдельно и третьим лицам не передается. Имейте в виду, что, к примеру, подрядчик по нагрузочному тестированию – это третье лицо.

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

• Ведется учет всех действий. Каждую выгрузку нужно фиксировать в журнале.

Существует 6 основных способов получить тестовые данные. Рассмотрим их детально в таблице

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

Росстандарт выпустил первые нормативы – их подготовила Ассоциация больших данных. Три документа: ПНСТ 1064-2026 – основные понятия и термины, ПНСТ 1065-2026 – архитектура и методы синтеза, ПНСТ 1066-2026 – оценка качества результатов. Действуют они с 1 сентября 2026 года, то есть уже сейчас. Там наконец-то есть то, чего не хватало: как оценить достоверность, как измерить риск восстановления исходных данных, как валидировать, как маркировать и проводить аудит.

---

Как построить конвейер синтетических данных?

Теперь переходим к практике: от минимизации хаоса в тестовых данных до автоматизации за 7 шагов. Порядок действий здесь важен, не советую перескакивать этапы.

Шаг 1. Инвентаризация и профилирование

Классифицировать поля нужно по содержимому, а не по именам. В колонке field_17 в старой таблице вполне могут лежать паспортные данные, а колонка passport – красивая, но пустая с 2019 года. Классификатор, который смотрит только на заголовки, найдет passport и пропустит field_17. А отвечать за утечку придется именно за field_17.

Для каждого поля нужно выяснить тип данных и посчитать пустые значения – отдельно пустые строки, это не одно и то же. Дальше считаем количество уникальных значений и собираем топ-20 из них: смотрим, какую долю они занимают суммарно, – так сразу видны перекосы в распределении. И вместо средней длины строки полезнее построить гистограмму распределения длин – по ней картина заметно нагляднее.

Где скрываются проблемы?

Поля-помойки, где лежит и телефон, и адрес, и переписка с юристом. Справочники, которые внезапно оказываются ПД: к примеру, контрагенты, где половина записей – ИП, а ИП это физлицо с ФИО в названии. И косвенные идентификаторы: номер офиса, дата открытия счета и сумма первого взноса (в небольшом городе этого достаточно, чтобы найти конкретного человека).

Какие инструменты использовать?

Для быстрого старта подойдет ydata-profiling, для повторяемых проверок – Great Expectations или Soda, а для больших таблиц – обычный SQL на ClickHouse: он быстрее любой библиотеки. Персональные данные хорошо находит из коробки «Гарда Data Masking» с машинным обучением – на старых схемах с полями f_01…f_88 она экономит недели работы.

Метрика готовности к следующему этапу – доля полей с подтвержденной классификацией. Если она ниже 95%, идти дальше бессмысленно: неизвестность просто переедет на следующий этап и найдется в проде. Да, это скучно. Да, займет две-три недели. И обойти это не получится – я пробовал трижды.

Шаг 2. Что такое контракт на данные и зачем его создавать?

Контракт на данные — это короткий документ о том, какой датасет считается правильным. Он защитит всех от бесконечных переписок. Пишет его потребитель, а не генератор, иначе получится описание того, что удобно отдавать, а не того, что нужно. Хранить – в YAML рядом с кодом, чтобы контракт жил в версиях и проходил ревью.

# contracts/acquiring_load.yamldataset: acquiring_load_4tbpurpose: performance          # одна из четырёх задач, не «универсальный»owner: perf-teamsource_profile: profiles/acquiring@2026-07-14.jsonvolume:  rows: 1_300_000_000  size_tb: 4.1  tolerance: 0.03must_preserve:  cardinality:    merchant_id: { value: 41_000, tol: 0.05 }    card_token:  { value: 78_000_000, tol: 0.05 }  skew:    merchant_id: { gini: 0.81, tol: 0.03 }  partitions:    last_90d_share: { value: 0.70, tol: 0.02 }  nulls:    mcc: { value: 0.031, tol: 0.005 }  string_length:    merchant_name: { mean: 34.2, p95: 61, tol: 0.10 }must_not_contain: [ real_pan, real_msisdn, real_fio, real_contract_no, real_inn ]edge_cases:                  # ссылки на каталог патологий, см. шаг 6  include: [ EC-014, EC-021, EC-088, EC-102, EC-137 ]  min_occurrences: 200privacy_gates:  exact_row_match: 0  dcr_p5: ">= holdout"  mia_auc: "<= 0.55"reproducibility:  seed: 20260901  generator_version: "2.3.1"lifecycle:  ttl_days: 14  storage_class: restricted-test

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

Шаг 3. Подбираем генератор для каждого типа данных

Главное не то, какой генератор выбрать, а какой генератор подходит каждой группе полей. В типичной корпоративной базе около 80% данных спокойно генерируются правилами, еще 15% требуют статистики, и лишь оставшиеся 5% – ради них и нужна нейросеть.

Разбивка по группам полей

Шаг 4. Чем кормить генератор, чтобы синтетические данные получились реалистичными?

Главное правило: модель учится там же, где живут данные – тот же контур, те же защиты и журналы доступа. Наружу выходит только готовая модель и только после проверки на утечку.

Теперь четыре важных вещи, о которых редко пишут

1. Размер выборки. Табличной модели хватает 1–5 млн строк. Больше – не лучше: модель дольше учится и сильнее запоминает конкретные записи.

2. Дедупликация. Дубликаты – главная причина запоминания вместо обобщения. Чистим через MinHash или SimHash с порогом схожести 0,8. На одном проекте только это уменьшило утечки в десять раз.

3. Канарейки. Перед обучением подмешиваем 300–1000 выдуманных записей с редкими сочетаниями – редкая фамилия, необычный диагноз, точная дата. После генерации ищем их в результате. Нашли – модель течет. Не нашли – гарантий нет, но есть дешевый ежедневный сигнал для CI.

4. Дифференциальная приватность. Для внутреннего контура обычно лишняя: при ε ≤ 1 вымываются хвосты распределения, ради которых все и затевалось. Вдобавок шум дает ложные срабатывания статистических тестов – аналитик путает его с реальным эффектом. Данные уходят за периметр – нужна. Остаются внутри – без нее почти наверняка обойдетесь.

Шаг 5. Двухконтурная схема, без которой терабайты синтетики не получить

Суть в том, что нейросеть дает структуру, а не объем. Гнать миллиард строк через CTGAN – как возить щебень на велосипеде: можно, но бессмысленно.

Цифры простые: глубокая табличная модель на видеокарте делает десятки тысяч строк в секунду, то есть миллиард – это дни непрерывной работы. А копула или сэмплер на Spark и ClickHouse выдают миллионы строк в секунду с одной машины и растут линейно. Разница – в тысячи раз. Поэтому нужны два контура: медленный учит модель, быстрый размножает результат по требованию.

Главное в размножителе – предсказуемость. Заданы три параметра: слепок модели, seed и диапазон номеров строк – и результат всегда один и тот же. Поэтому каждый воркер генерирует свой кусок сам, без общего состояния и координации, и итог сходится побайтово.

-- ClickHouse: скелет размножителя. Zipf по мерчантам через словарь весов,-- детерминированный PRNG от (seed, номер строки)INSERT INTO tx_synthSELECT    cityHash64(:seed, n)                                  AS rid,    dictGet('merchant_zipf', 'merchant_id',            toUInt64(zipf_bucket(rid)))                   AS merchant_id,    dictGet('card_pool', 'token',            toUInt64(rid % 78000000))                     AS card_token,    -- 70% объёма — в последние 90 дней, как в проде    now() - toIntervalSecond(        if(rid % 100 < 70, rid % 7776000, 7776000 + rid % 86400000)) AS ts,    -- логнормаль по суммам + магнит на круглые значения    round_magnet(exp(4.1 + 0.92 * randNormal(rid)))       AS amount,    if(rid % 1000 < 31, NULL, dictGet('mcc', 'code', rid % 400)) AS mccFROM numbers_mt(:row_from, :row_count)

И три тонкости, которые я узнал благодаря проблемам с нагрузочным тестом.

Первая – порядок вставки. Если генерировать данные по возрастанию ключа, соседние строки станут похожими, сжатие улучшится, а 4 терабайта прода на стенде ужмутся в 1,5 – тест покажет отличные, но фальшивые цифры. В проде данные приходят вперемешку, поэтому перемешивайте их перед загрузкой, хотя бы блоками по несколько миллионов строк. Одна строчка кода – и на диске вдвое больше места.

Вторая – длина строк и доля пустых значений. Скучные метрики, но обе работают. В проде merchant_name в среднем 34 символа, а генератор выдает 12 – таблица выходит в два с половиной раза меньше. В MCC в проде 3,1% пустых значений, у вас ноль – вы не словите ни одного падения на пустом поле и получите другой размер строки в колоночном хранилище.

Третья – сколько терабайт нужно. Большинству команд – ноль. Терабайты нужны нагрузочникам и тем, кто отлаживает запросы на больших таблицах. Остальным хватает среза: 2–3% от прода со связностью покрывают около 95% сценариев, генерируются за минуты и влезают на ноутбук. Просьбы полной копии – это не потребность в данных, а недоверие к срезу, и лечится оно контрактом из шага 2, а не терабайтами.

Шаг 6. Заводим каталог патологий

Генеративная модель по своей природе сглаживает редкие случаи. Это не баг, а ее работа: она держится плотности распределения, а редкие события низкой плотности и бывают по определению. GAN к тому же схлопывает моды, VAE – размывает. Аналитику это не мешает: ему нужны среднее и корреляции. А для тестировщика это беда, потому что баги прячутся именно в хвостах. 

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

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

Багтрекер за два-три года: выгружайте дефекты, где упоминаются данные, форматы, пустые значения и кодировки, – это золотая жила. 

Постмортемы прода: каждый инцидент, вызванный данными, становится записью каталога – это дисциплина, а не техника. 

Ограничения схемы: для каждого CHECK, NOT NULL и лимита длины нужны значения на границе и за ней. 

И наконец, просто подумайте, как вы ломали бы свою систему, если бы за это платили.

Шаг 7. Как не дать синтетике сломать прод с помощью независимых проверок?

Невалидный датасет не публикуется. Точка. Ворота стоят в CI, у каждого – жесткий порог из контракта.

Лучший тест пригодности данных – не статистика, а планы запросов. Берете топ-50 запросов из pg_stat_statements, прогоняете EXPLAIN (ANALYZE, BUFFERS) на проде и на синтетике и сравниваете типы узлов и оценки кардинальности. Совпало – данные годные. Не совпало – сломано ровно одно распределение, и сразу видно какое. Так я за час нахожу то, что метриками искал бы неделю.

Ловушка DCR. Расстояние до ближайшей реальной записи часто выдают за доказательство приватности – это ничего не значит. Честная проверка такая: отложите часть реальных данных, которых модель не видела, и сравните DCR для этого холдаута и для синтетики. Если синтетика ближе к обучающей выборке, модель просто запоминает. За эту ошибку критикуют половину работ по синтетическим данным.

Тонкости работы с синтетическими данными в России

Тут шаблоны не работают. Зарубежные инструменты в наших реалиях выдают номер соцстрахования вместо СНИЛС и адрес в духе «улица, город, штат». Даже локаль ru_RU в популярных библиотеках дает правдоподобные строки, которые не проходят валидацию.

Следствие простое и обидное: сгенерируете ИНН двенадцатью случайными цифрами – валидатор отсеет около 90% записей. Вы будете тестировать не систему, а свой генератор, и узнаете об этом дня через три.

Правила, которые придётся написать самим. Хорошая новость: это пишется один раз и переиспользуется на всех проектах. У меня эта библиотека живёт уже пятый год и обросла тестами толще, чем сам генератор. Хорошо ещё дописать «Даты и время», «Календарь нагрузки», «Суммы и НДС».

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

Какие инструменты выбрать в российских реалиях?

Ландшафт собран по слоям, а не по вендорам: вендоры меняются, слои – нет. Часть зарубежных платформ недоступна, а часть неприменима, потому что это SaaS: данные для обучения за периметр не выпускаешь. Открытые библиотеки ставятся локально и работают у всех одинаково. 

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

План создания конвейера синтетических данных на 90 дней с раскладкой по неделям

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

Подводим итоги

Синтетические данные – не панацея. Модель сглаживает хвосты, генератор путает СНИЛС с зарубежной страховкой, а терабайты прода на стенде лгут, если данные вышли слишком прилизанными. Работает только связка: инвентаризация по содержимому полей, контракт с порогами в CI, каталог патологий из реальных инцидентов, проверка приватности через холдаут и планы запросов как главный тест.

Юридические требования зафиксируйте до первой выгрузки – ошибки, связанные с приказом № 140 и штрафы по 420-ФЗ стоят слишком дорого, будьте аккуратны. Начните с одного домена и среза на 2–3% прода: этого хватит почти всем, а второй домен затем делается за две недели. Соберете конвейер целиком – тесты на синтетике будут предсказывать прод. Соберете не все – будете третий день искать баг, который сидит в вашем генераторе. 

Если тема построения синтетического конвеера, да и вообще совершенствования тестового контура вам близка, – заходите в телеграм-канал о тестировании. Там вы найдете больше информации на эту тему.