Как построить конвейер обезличенных синтетических данных и убедиться, что они не врут? Собрал полезную статью для руководителей разработки и 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.yaml
dataset: acquiring_load_4tb
purpose: performance          # одна из четырёх задач, не «универсальный»
owner: perf-team
source_profile: profiles/acquiring@2026-07-14.json

volume:
  rows: 1_300_000_000
  size_tb: 4.1
  tolerance: 0.03

must_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: 200

privacy_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_synth
SELECT
    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 mcc
FROM 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% прода: этого хватит почти всем, а второй домен затем делается за две недели. Соберете конвейер целиком — тесты на синтетике будут предсказывать прод. Соберете не все — будете третий день искать баг, который сидит в вашем генераторе. 

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