Генерація синтетичних тестових даних: підходи та реалізація

Уявіть: ваш ML-пайплайн падає в production, тому що синтетичні тестові дані не покривали розподілені дрифти. Або QA-команда витрачає тижні на ручну підготовку датасетів. Ми будуємо генератори синтетичних даних, які автоматично покривають 95% edge cases і скорочують час тестування в 3-5 разів. В одному fintech-проекті з 500+ API endpoints ми скоротили час регресії з 3 днів до 6 годин. Економія на QA-ресурсах склала 40%. Для фінтех-платформи з щомісячними транзакціями на мільйони гривень ми згенерували датасет, який виявив 12 прихованих багів до релізу.

Синтетичні дані цілеспрямовано перевіряють граничні випадки, аномалії та рідкісні події — те, що неможливо отримати з знеособлених датасетів. Ми гарантуємо покриття 95% погоджених сценаріїв, а час тестування скорочується в 3–5 разів.

Чому синтетичні тестові дані кращі за знеособлені?

Знеособлені дані містять legacy-аномалії, зміщення вибірки та неповне покриття. Синтетика ж цілеспрямовано перевіряє умови: граничні значення, відсутні поля, ін'єкції, rare events.

Які стратегії генерації ми використовуємо?

Ми застосовуємо три підходи: rule-based, LLM-генерацію та ML-based. Їх порівняння:

Rule-based генерація з Faker

Rule-based генерація — явний опис правил для структурованих даних. Працює швидко і дає повний контроль. Faker — бібліотека для генерації фейкових даних.

from faker import Faker from dataclasses import dataclass import random import uuid fake = Faker('ru_RU') @dataclass class TestUser: user_id: str email: str age: int balance: float subscription_tier: str class TestDataFactory: def create_valid_user(self) -> TestUser: return TestUser( user_id=str(uuid.uuid4()), email=fake.email(), age=random.randint(18, 80), balance=round(random.uniform(0, 100_000), 2), subscription_tier=random.choice(['free', 'basic', 'premium']) ) def create_edge_cases(self) -> list[TestUser]: """Edge cases для тестування""" return [ # Мінімальний вік TestUser(str(uuid.uuid4()), fake.email(), 18, 0.0, 'free'), # Максимальний баланс TestUser(str(uuid.uuid4()), fake.email(), 65, 999_999.99, 'premium'), # Нульовий баланс TestUser(str(uuid.uuid4()), fake.email(), 30, 0.0, 'premium'), # Спеціальні символи в email TestUser(str(uuid.uuid4()), "[email protected]", 25, 100.0, 'basic'), ] def create_ml_input_variants(self, n: int = 1000) -> pd.DataFrame: """Покриття feature space для тестування ML моделі""" return pd.DataFrame({ 'age': np.linspace(18, 80, n).astype(int), 'balance': np.logspace(0, 6, n), # Логарифмічний розподіл 'days_since_last_purchase': np.concatenate([ np.zeros(n//4), # 0 днів (щойно купили) np.ones(n//4) * 365, # Рік тому np.random.randint(1, 730, n//2) # Випадкові ]), 'subscription_tier': np.random.choice(['free', 'basic', 'premium'], n) }) 

Документація Faker — генерація фейкових даних.

LLM-генерація текстових сценаріїв

LLM-генерація — підходить для текстових даних: відгуки, запити, документи. Моделі на кшталт Claude 3.5 Sonnet та GPT-4o створюють різноманітні сценарії, включаючи сарказм, змішані тони та специфічні формати.

from anthropic import Anthropic class TextTestDataGenerator: def __init__(self): self.client = Anthropic() def generate_sentiment_test_cases(self) -> list[dict]: prompt = """Generate 20 test cases for sentiment analysis testing. Include: - 5 clearly positive reviews - 5 clearly negative reviews - 5 ambiguous/mixed reviews - 5 edge cases (sarcasm, neutral, very short, all caps) Format as JSON array with fields: text, expected_sentiment, category""" response = self.client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=2000, messages=[{"role": "user", "content": prompt}] ) return json.loads(response.content[0].text) def generate_rag_test_queries(self, knowledge_base_summary: str) -> list[dict]: """Генерація тестових запитів для RAG системи""" prompt = f"""Given this knowledge base: {knowledge_base_summary} Generate 30 test queries including: - Direct factual questions (should return answer from KB) - Questions outside KB scope (should return 'not found') - Ambiguous queries (testing retrieval quality) - Multi-hop questions requiring synthesis Return JSON array with: query, expected_type, expected_answer_present""" response = self.client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=3000, messages=[{"role": "user", "content": prompt}] ) return json.loads(response.content[0].text) 

ML-based генерація для тестування моделей

ML-based генерація — для тестування самих ML-моделей: concept drift, adversarial robustness, distribution shift. Ми створюємо дані, які цілеспрямовано ламають модель, щоб перевірити моніторинг та детекцію аномалій.

class MLModelTestDataGenerator: def generate_distribution_shift(self, train_data: pd.DataFrame, shift_type: str) -> pd.DataFrame: """Генерація даних з навмисним дрифтом для тестування моніторингу""" if shift_type == 'covariate': # Зсув розподілу ознак test_data = train_data.copy() test_data['age'] = test_data['age'] + 15 # Віковий зсув return test_data elif shift_type == 'concept': # Інвертуємо залежність (для тестування concept drift детекції) test_data = train_data.copy() test_data['target'] = 1 - test_data['target'] return test_data def generate_adversarial_examples(self, model, X: np.ndarray, epsilon: float = 0.1) -> np.ndarray: """FGSM adversarial examples для stress testing""" import torch X_tensor = torch.FloatTensor(X).requires_grad_(True) output = model(X_tensor) loss = output.sum() loss.backward() adversarial = X + epsilon * X_tensor.grad.sign().numpy() return np.clip(adversarial, X.min(), X.max()) 

Вибір стратегії

Для API-тестів та бізнес-логіки достатньо rule-based. Для NLP-пайплайнів (sentiment, RAG, NER) потрібні LLM. Для тестування моніторингу моделей — ML-based. Ми комбінуємо підходи і створюємо гібридні генератори, що покривають до 95% edge cases. Оцініть економію на вашому проекті — зв'яжіться з нами для консультації.

Процес розробки генератора

1. Аналітика — вивчаємо ваші тестові сценарії, виділяємо класи еквівалентності (1–2 дні).
2. Проектування — обираємо стратегії (rule-based, LLM, ML), пишемо специфікацію (2–5 днів).
3. Реалізація — кодуємо генератори, використовуємо Faker, LangChain, PyTorch (1–3 тижні).
4. Тестування — перевіряємо покриття метриками (BERTScore, coverage) (3–5 днів).
5. Деплой — пакуємо в Docker, налаштовуємо виклик із CI/CD (2–4 дні).

Що входить в розробку генератора

• Аналіз ваших сценаріїв тестування та складання карти edge cases
• Розробка генераторів на Python з документацією
• Інтеграція з CI/CD через Docker/CLI
• Набір прикладів використання та тестові датасети
• Навчання команди QA та підтримка 2 тижні після впровадження

Метрики якості

Для rule-based — покриття заявлених правил (кількість edge cases). Для LLM — точність семантичної відповідності (BERTScore). Для ML-тестів — відсоток знайдених дрифтів та adversarial success rate. В результаті ви отримуєте генератор, який автоматично покриває 95%+ погоджених сценаріїв.

Строки та вартість

Строки: від 2 тижнів для базового rule-based до 2 місяців для комплексної системи з ML-тестами. Вартість розраховується індивідуально, виходячи з обсягу сценаріїв та складності інтеграції. Економія на QA-ресурсах досягає 40% після впровадження. Середня окупність генератора — 3-6 місяців за рахунок скорочення ручного тестування. Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Замовте розробку генератора та отримайте консультацію.

Правильно розроблена система тестових даних покриває 95%+ edge cases автоматично, прискорює тестування в 3-5 разів і дозволяє команді QA зосередитися на дійсно складних сценаріях.