Генерація синтетичних даних для донавчання LLM під ключ

Ви запускаєте fine-tuning LLM, але у вас лише кілька десятків тисяч прикладів. Ручна розмітка коштує сотні тисяч доларів і займає місяці. Ми вирішуємо це завдання за допомогою генерації синтетичних даних: вчительська модель (GPT-4, Claude) створює тисячі різноманітних інструкцій та відповідей, а ви потім донавчаєте свою модель. Такий підхід скорочує витрати на розмітку до 90% і дозволяє отримати датасет із потрібним розподілом за 2–4 тижні. Синтетична аугментація (LLM augmentation) — це не лише економія бюджету, але й контроль якості: ви керуєте стилем відповідей, складністю та доменом. На відміну від краудсорсингу, де якість анотацій нестабільна, тут кожен приклад проходить через LLM-суддю та вибіркову human-оцінку. Результат — датасет, який покращує метрики моделі на 15–20% без додаткових витрат.

Як Self-Instruct масштабує датасет?

Метод Self-Instruct, запропонований дослідниками з Університету Вашингтона, потребує всього 20–200 seed-прикладів. З них LLM генерує нові інструкції, потім відповіді, і повторює процес ітеративно. За 3–5 ітерацій із 100 seed-прикладів виходить 2 000–5 000 пар. Ми адаптували процес під російськомовні дані та додали фільтр якості (LLM-суддя), який відсіває повтори та нерелевантні приклади.

from anthropic import Anthropic
import json

client = Anthropic()

SEED_EXAMPLES = [
    {"instruction": "Объясни термин из ML", "output": "..."},
    {"instruction": "Напиши SQL запрос для...", "output": "..."},
    # 20-200 seed примеров
]

def generate_new_instructions(seed_examples: list, n: int = 20) -> list[str]:
    """Генерация новых инструкций на основе seed примеров"""
    examples_str = "\n".join([f"- {ex['instruction']}" for ex in seed_examples[:10]])

    response = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=2000,
        messages=[{
            "role": "user",
            "content": f"""Here are some example instructions for an AI assistant:
{examples_str}

Generate {n} NEW diverse instructions in the same domain.
Requirements:
- Each instruction should be unique and not repeat the examples
- Vary complexity: some simple, some multi-step
- Include different formats: questions, commands, completions
- Return as JSON array of strings"""
        }]
    )
    return json.loads(response.content[0].text)

def generate_response(instruction: str, context: str = None) -> str:
    """Генерация идеального ответа для инструкции"""
    prompt = f"Instruction: {instruction}"
    if context:
        prompt = f"Context: {context}\n\n{prompt}"

    response = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1000,
        system="You are an expert assistant. Provide accurate, helpful, and complete responses.",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.content[0].text

Як Evol-Instruct ускладнює інструкції?

Evol-Instruct, реалізований у WizardLM, бере існуючі приклади та застосовує методи ускладнення: додавання обмежень, поглиблення, конкретизація, збільшення кількості кроків міркування. Наприклад, просте запитання «Розкажи про React» перетворюється на «Порівняй React і Vue для великого enterprise-застосунку з урахуванням SSR та code-splitting». Це підвищує якість fine-tuning, особливо для завдань міркування.

EVOLUTION_METHODS = [
    "Add constraints: add a specific constraint or requirement to the instruction",
    "Deepening: ask for more depth or detail in the response",
    "Concretizing: replace general concepts with specific examples",
    "Increased reasoning steps: require multi-step reasoning",
    "Complicate input: add more complex or ambiguous input",
]

def evolve_instruction(original: str) -> str:
    """Усложнение инструкции одним из методов"""
    method = random.choice(EVOLUTION_METHODS)

    response = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=200,
        messages=[{
            "role": "user",
            "content": f"""Rewrite this instruction using this method: {method}

Original instruction: {original}

Return only the rewritten instruction, nothing else."""
        }]
    )
    return response.content[0].text.strip()

Як ми оцінюємо якість синтетичних даних?

Ми впровадили дворівневу валідацію: автоматичний LLM-суддя (на базі GPT-4) оцінює кожен приклад за шкалою 0–1, потім випадкові 10% вибірки перевіряє людський експерт. Якщо approval rate за human-оцінкою нижчий за 85% — коригуємо генерацію. Додатково вимірюємо різноманітність (distinct n-grams) та довжину в токенах, щоб уникнути однотипності.

Як ми генеруємо дані під ваш домен?

Для domain-specific завдань ми додаємо контекст: базу знань, API-специфікації, корпоративні гайди. Наприклад, для донавчання чат-бота техпідтримки: завантажуємо FAQ та логи дзвінків, LLM генерує пари «питання клієнта — відповідь експерта». Пайплайн включає три кроки:

1. Генерація інструкцій — моделювання можливих запитів користувачів.
2. Генерація відповідей — з використанням релевантного контексту з вашої бази.
3. Фільтрація — видалення дублікатів, перевірка довжини (токени), оцінка якості LLM-суддею.

def generate_domain_dataset(domain: str, n_examples: int,
                             output_path: str):
    """Генерация датасета для конкретного домена"""
    examples = []

    for i in range(n_examples):
        # Шаг 1: Генерация разнообразной инструкции
        instruction = generate_instruction_for_domain(domain)

        # Шаг 2: Генерация ответа
        response = generate_response(instruction)

        # Шаг 3: Качественный фильтр (LLM-judge)
        quality_score = judge_quality(instruction, response)

        if quality_score >= 0.7:
            examples.append({
                "instruction": instruction,
                "output": response,
                "quality_score": quality_score,
                "generated_by": "claude-3-5-sonnet-20241022"
            })

        if (i + 1) % 100 == 0:
            print(f"Generated {i+1}/{n_examples}, kept {len(examples)}")

    with open(output_path, 'w') as f:
        for ex in examples:
            f.write(json.dumps(ex, ensure_ascii=False) + '\n')

Порівняння методів генерації

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

1. Аналіз завдання — визначення домену, вимог до датасету, метрик якості.
2. Підготовка seed-прикладів — збір 50–200 репрезентативних пар (можна ваші дані).
3. Генерація синтетичного датасету — Self-Instruct + Evol-Instruct, 5 000–50 000 пар.
4. Фільтрація та валідація — LLM-суддя + human-оцінка 10% вибірки.
5. Документація — model card, виміри різноманітності, approval rate.
6. Супровід — коригування промптів при необхідності, підтримка протягом місяця.

Терміни та вартість

Терміни залежать від обсягу датасету:

• 1 000–10 000 прикладів: від 1 до 3 тижнів
• 10 000–100 000 прикладів: від 3 до 6 тижнів

Вартість розраховується індивідуально — вона включає API-витрати, роботу інженера та валідацію. В середньому синтетика обходиться в 10–20% від вартості ручної розмітки аналогічного обсягу. Гарантуємо якість: approval rate не нижче 85% за результатами human-оцінки.

Типові помилки при генерації синтетики

• Overfitting на стиль вчителя — модель копіює тон GPT-4 замість цільового. Рішення: mix with real data, додавайте приклади з вашого домену.
• Недостатня різноманітність — всі інструкції схожі. Рішення: контролюйте тематичний розподіл, використовуйте Evol-Instruct.
• Галюцинації фактів — особливо в domain-specific даних. Рішення: вводьте контекстні фільтри та ручну перевірку.

Ми маємо 5+ років досвіду в NLP та MLOps, виконали понад 50 проектів з генерації синтетичних даних для LLM. Зв'яжіться з нами — оцінимо ваш проект і запропонуємо оптимальну стратегію. Отримайте консультацію прямо зараз.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для ML відрізняються від BI

ETL для аналітики та ETL для ML — різні завдання. В аналітиці важлива агрегація, у ML — індивідуальні записи з історією. В аналітиці train/val/test split не потрібен, у ML — критичний. В аналітиці skew даних заважає інтерпретації, у ML — безпосередньо впливає на якість моделі.

Інструменти. Apache Spark для великих обсягів (10GB+): PySpark з DataFrames, оптимізації через partitioning та caching. dbt для трансформацій поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версіонується, тестується. Pandas + Polars для обсягів до кількох GB — Polars у 5–10x швидше за Pandas на типових трансформаціях.

Temporal splits. Для ML важливо, що split за часом, а не випадковий. Якщо дані часові (транзакції, події користувачів), випадковий split дає data leakage: модель бачить «майбутні» дані при навчанні. Правило: train на періоді T1–T2, validation на T2–T3 (з gap для запобігання leakage), test на T3–T4. Неправильний split може коштувати 10–15% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

Інкрементальні пайплайни. Модель перенавчається щотижня на нових даних. Потрібен пайплайн, який інкрементально додає нові записи до навчальної вибірки, не перевантажуючи все з нуля. Delta Lake або Apache Iceberg — формати з ACID-транзакціями, Change Data Capture, time travel.

Як уникнути training-serving skew за допомогою Feature Store

Feature Store вирішує проблему розсинхронізації між навчанням та інференсом. Найпідступніша помилка в ML-інфраструктурі — training-serving skew: ознака обчислюється по-різному в навчанні та в продакшені. Модель вчиться на «правильних» даних, а інференс отримує інші.

Feast (open source) — офлайн store на Parquet/Delta в S3 для навчання, онлайн store на Redis для low-latency інференсу (<10ms). Feature definitions як Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition використовується всюди — немає розбіжностей.

Потокові ознаки. Коли ознака має оновлюватися в реальному часі (кількість транзакцій за останні 10 хвилин), потрібна потокова обробка. Apache Kafka + Apache Flink або Kafka Streams для обчислення ознак у реальному часі → запис в онлайн store. Складніше, дорожче, потрібно лише коли staleness ознак критична для якості.

Розмітка даних: як не витратити бюджет даремно

Розмітка — найтрудомісткіша та недооцінювана частина ML-проекту. Погано розмічені дані не виправить жодна архітектура.

Label Studio — open source, підтримує розмітку зображень (bounding box, polygon, segmentation), тексту (NER, класифікація), аудіо, відео. Піднімається за 10 хвилин через Docker. Для невеликих команд — перший вибір.

Оцінка якості розмітки. Inter-annotator agreement — наскільки згодні розмітники між собою. Cohen's Kappa > 0.8 — добре, 0.6–0.8 — прийнятно, < 0.6 — завдання неоднозначне або інструкція погана. Перетин розміток (10–20% прикладів розмічають два незалежних анотатори) — обов'язкова практика.

Active learning. Не розмічати випадкові приклади, а вибирати ті, на яких модель найбільш невпевнена (low confidence, high uncertainty). Дозволяє досягти тієї ж якості при 50–70% обсягу розмітки. Modals, Prodigy, Label Studio підтримують active learning workflows. На одному з проектів для NLP ми скоротили бюджет на розмітку в 2,5 рази завдяки active learning — економія склала $15 000 на 100 000 розмічених прикладів.

Синтетичні дані. Коли реальних даних мало або отримати їх дорого. Для CV: рендеринг у Blender/Unity з реалістичними текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Ризик: модель навчається на distribution синтетичних даних, а не реальних — потрібна обережність і перевірка на реальному holdout.

Якість даних: валідація та моніторинг

Great Expectations — de facto стандарт для data validation у ML-пайплайнах. Expectations — це декларативні твердження про дані: «колонка age містить значення від 0 до 120», «колонка user_id не містить null», «розподіл amount не відхиляється більш ніж на 20% від baseline». Запускається в пайплайні, при провалі — блокує проходження.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation з type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель очікує дані за останні N днів. ETL впав, дані не оновилися — модель використовує застарілі ознаки. Моніторинг свіжості даних: timestamp останнього запису в кожній таблиці, алерт при затримці > порога.

Дедуплікація. Дублікати в навчальній вибірці завищують метрики (одні й ті самі приклади в train і val) і спотворюють ваги моделі. MinHash LSH для наближеної дедуплікації великих датасетів. Для точної — хеш за нормалізованим контентом.

Сховища та формати

Для більшості ML-проектів на старті: Parquet в S3 + DVC для версіонування. Delta Lake або Iceberg — коли з'являється потреба в інкрементальних оновленнях або time travel.

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

• Аудит існуючих даних та пайплайнів (1 тиждень).
• Проектування архітектури: вибір інструментів, форматів, способів розмітки.
• Реалізація ETL/ELT пайплайну з валідацією та моніторингом.
• Документація коду та процесів (model card, data card).
• Навчання вашої команди роботі з пайплайном.
• SLA на супровід та підтримку.

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

1. Аудит існуючих даних. Профілювання: ydata-profiling (колишній pandas-profiling) генерує HTML-репорт зі статистиками, дистрибуціями, кореляціями, missing values за хвилини.
2. Проектування пайплайну. Визначаємо джерела даних, частоту оновлення, вимоги до latency ознак, обсяги.
3. Реалізація та тестування. Unit-тести на трансформації, integration-тести на пайплайн, data validation через Great Expectations.
4. Деплой та моніторинг. Алерти на freshness, quality checks, аномалії в обсягах даних.

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

Зв’яжіться з нами для безкоштовного аудиту ваших даних — оцінимо поточний пайплайн і запропонуємо roadmap. Замовте побудову ML-пайплайну під ключ.