AI-генерація тестових даних: схеми, граничні випадки, анонімізація

Генерація тестових даних за допомогою AI: від схеми до готового датасету

Уявіть: e-commerce база з 20 зв'язаними таблицями, ручне створення 10 000 записів займає тиждень, а після інтеграції тести падають через граничний випадок. Потрібні реалістичні дані: не просто user_1 та [email protected]. Щоб покрити всі сценарії, дані повинні мати правильні розподіли, граничні значення, різні символи та зв'язки між таблицями. Вручну це роблять погано: або даних мало, або вони нереалістичні.

Ручна генерація тестових даних забирає години й навіть дні. Потрібно придумати тисячі записів, узгодити зовнішні ключі, не забути про null та довгі рядки. AI-генерація тестових даних вирішує задачу за хвилини — масштабується від сотень до мільйонів записів без втрати якості. Ми автоматизуємо процес за допомогою LLM та кастомних промптів: створюємо структуровані датасети за схемою БД, семантичний контент під ваш домен та аномальні випадки для негативних тестів. Під ключ — від схеми до готового JSON/CSV.

Наш підхід дає покриття граничних випадків на рівні 10-15%. Ви отримуєте датасет, готовий для бойового тестування. Всі дані детерміновані та валідуються на льоту. Зв'яжіться з нами для консультації — ми підготуємо демо-датасет під вашу схему.

Проблеми, які вирішує AI-генерація

Ручні датасети містять 10-100 записів, а потрібно 100 000+. AI масштабується без втрати якості. Граничні випадки (порожні рядки, SQL-ін'єкції, рядки >1000 символів) вручну забувають у 80% проєктів. При кількох зв'язаних таблицях ручне створення порушує референційну цілісність — AI-генератор будує топологічний порядок і підтягує існуючі ID. Production-дані містять персональну інформацію — DataAnonymizer замінює email, телефон, паспорт на синтетичні аналоги, зберігаючи структуру.

Як AI забезпечує реалістичність даних?

Використовуємо комбінацію: Faker для базових провайдерів (імена, адреси); LLM (GPT-4o) для семантичного контексту — діагнози за МКХ-10, торгові найменування препаратів, суми з логнормальним розподілом; кастомні провайдери для доменів: медичні коди, IBAN. Температура моделі 0.8 дає різноманіття при збереженні правдоподібності.

Навіщо потрібні граничні випадки?

Граничні дані виявляють баги, які не відтворюються на «красивих» даних. Наш генератор включає 10-15% аномальних записів у кожному батчі. Це null, max int, спецсимволи, SQL-ін'єкції, довгі рядки. В одному проєкті e-commerce це допомогло знайти integer overflow при обробці великих сум — баг жив у продакшені 2 роки.

Як працює генерація зв'язаних даних?

Генератор будує топологічний порядок залежностей. Спочатку створюються батьківські таблиці, потім дочірні — з підстановкою існуючих FK. Це гарантує цілісність зв'язків. Замовте консультацію, і ми налаштуємо генератор під вашу схему.

Процес роботи

1. Аналітика — вивчаємо схему БД, бізнес-правила, вимоги до тестових даних.
2. Проектування — налаштовуємо провайдери Faker, пишемо промпти для LLM, визначаємо розподіли.
3. Реалізація — код генератора, інтеграція з CI/CD (GitHub Actions, GitLab CI).
4. Тестування — валідація датасету: схема, дублікати, FK, граничні випадки.
5. Деплой — передача скрипту або API, навчання команди, документація.

Порівняння: ручна vs AI-генерація

AI-генератор створює датасети в 100 разів швидше за ручну працю.

Що входить у послугу

• Архітектура AI-генератора під вашу схему БД.
• Кастомні провайдери Faker для домену.
• Модуль анонімізації PII.
• Інтеграція з CI/CD (контейнеризація, Makefile).
• Документація з використання та налаштування.
• Навчання команди (1-2 години онлайн).
• Підтримка 2 тижні після здачі.

Практичний кейс

Наш клієнт — e-commerce платформа з тестовим оточенням з 50 000 рядків production-даних (анонімізованих). Після впровадження AI-генератора тестовий датасет розширено до 500 000 записів з реалістичними розподілами. Знайдено 3 продуктивнісних баги (slow queries), які не відтворювалися на малому датасеті. Граничні дані виявили помилку в обробці великих сум (integer overflow у старому PHP-коді). Економія часу тестування — 4 години на тиждень.

Код генерації

from faker import Faker
from langchain_openai import ChatOpenAI
from pydantic import BaseModel
import json
import random

fake = Faker("uk_UA")

class TestDataGenerator:
    SEMANTIC_PROMPT = """Згенеруй {count} реалістичних записів для таблиці.

Схема таблиці:
{schema}

Контекст домену: {domain}

Вимоги:
- Дані повинні виглядати реалістично (не "test_value_1")
- Числові значення в розумних діапазонах для домену
- Дати розподілені по різних періодах
- Статуси/категорії розподілені нерівномірно (реалістично)
- Пов'язані поля узгоджені (напр., місто та регіон)
- Включи 10-15% граничних випадків: min/max значення, порожні опціональні поля

Поверни JSON-масив з {count} об'єктів."""

    def __init__(self):
        self.llm = ChatOpenAI(model="gpt-4o", temperature=0.8)

    def generate_for_table(
        self,
        schema: dict,
        domain: str,
        count: int = 100
    ) -> list[dict]:
        result = self.llm.invoke(
            self.SEMANTIC_PROMPT.format(
                count=min(count, 50),
                schema=json.dumps(schema, ensure_ascii=False, indent=2),
                domain=domain
            )
        )
        batch = json.loads(result.content)

        if count > 50:
            all_data = batch
            while len(all_data) < count:
                more = self.generate_for_table(schema, domain, min(50, count - len(all_data)))
                all_data.extend(more)
            return all_data[:count]

        return batch

    def generate_boundary_cases(self, schema: dict) -> list[dict]:
        boundary_prompt = f"""Створи граничні та невалідні тестові дані для схеми.

Схема:
{json.dumps(schema, ensure_ascii=False, indent=2)}

Створи по 2–3 випадки кожного типу:
1. Порожні значення (null, "", [])
2. Максимальні значення (max int, max string length)
3. Мінімальні значення (min int, 0, negative)
4. Спеціальні символи: <, >, &, ', ", \\n, \\t, emoji 🎉
5. SQL-injection рядки (для перевірки sanitization)
6. Дуже довгі рядки (>1000 символів)
7. Неправильні типи (рядок замість числа тощо)

Поверни JSON з позначкою expected_behavior для кожного випадку."""

        return json.loads(
            self.llm.invoke(boundary_prompt).content
        )

class RelationalDataGenerator:
    def generate_dataset(
        self,
        schema: dict,
        counts: dict
    ) -> dict[str, list[dict]]:
        result = {}
        order = self._topological_sort(schema["tables"])

        for table_name in order:
            table_schema = next(t for t in schema["tables"] if t["name"] == table_name)
            count = counts.get(table_name, 10)

            fk_pools = {}
            for fk in table_schema.get("fk_relations", []):
                ref_table = fk["references_table"]
                if ref_table in result:
                    fk_pools[fk["column"]] = [r[fk["references_column"]] for r in result[ref_table]]

            records = self._generate_with_fk(table_schema, count, fk_pools)
            result[table_name] = records

        return result

    def _generate_with_fk(
        self,
        table_schema: dict,
        count: int,
        fk_pools: dict
    ) -> list[dict]:
        records = []
        for _ in range(count):
            record = {}
            for col in table_schema["columns"]:
                if col["name"] in fk_pools:
                    record[col["name"]] = random.choice(fk_pools[col["name"]])
                else:
                    record[col["name"]] = self._generate_field_value(col)
            records.append(record)
        return records

from faker.providers import BaseProvider

class MedicalDataProvider(BaseProvider):
    DIAGNOSES = ["J00", "K21.0", "I10", "E11", "M79.3"]
    MEDICATIONS = ["Амоксициллин 500мг", "Метформин 850мг", "Лизиноприл 10мг"]

    def diagnosis_code(self) -> str:
        return self.random_element(self.DIAGNOSES)

    def medication(self) -> str:
        return self.random_element(self.MEDICATIONS)

class FinanceDataProvider(BaseProvider):
    def iban(self) -> str:
        return f"BY{fake.numerify('##')}ALFA{fake.numerify('################')}"

    def transaction_amount(self) -> float:
        weights = [0.5, 0.3, 0.15, 0.05]
        ranges = [(1, 100), (100, 1000), (1000, 10000), (10000, 100000)]
        chosen_range = random.choices(ranges, weights=weights)[0]
        return round(random.uniform(*chosen_range), 2)

class DataAnonymizer:
    PII_FIELDS = {
        "email": lambda v: fake.email(),
        "phone": lambda v: fake.phone_number(),
        "name": lambda v: fake.name(),
        "inn": lambda v: fake.numerify("############"),
        "passport": lambda v: f"{fake.numerify('####')} {fake.numerify('######')}",
        "ip_address": lambda v: fake.ipv4_private(),
        "address": lambda v: fake.address(),
    }

    def anonymize_dataset(self, data: list[dict], pii_field_names: list[str]) -> list[dict]:
        result = []
        for record in data:
            anonymized = dict(record)
            for field in pii_field_names:
                if field in anonymized:
                    field_type = self._detect_field_type(field)
                    if field_type in self.PII_FIELDS:
                        anonymized[field] = self.PII_FIELDS[field_type](anonymized[field])
            result.append(anonymized)
        return result

Строки орієнтовно

• Генератор структурованих даних: 1–2 тижні.
• З анонімізацією та relational generation: 3–4 тижні.

Вартість розраховується індивідуально. Отримайте консультацію — ми підготуємо демо-датасет під вашу схему БД. Зв'яжіться з нами для оцінки вашого проєкту.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.