Fine-tuning LLM: подготовка датасета — форматы, дедупликация и чеклист

Как подготовить датасет для fine-tuning LLM: форматы, дедупликация и чеклист

Допустим, вы решили дообучить LLaMA 3 под генерацию SQL. Собрали 50 000 примеров, но модель выдаёт ерунду. В чём дело? Скорее всего, в датасете: дубли, неверный формат, утечка промпта. Мы в TrueTech готовим датасеты много лет и знаем: без системного подхода 80% данных — мусор. Согласно документации Hugging Face Datasets, качество датасета — главный фактор успеха fine-tuning. «Мусор на входе — мусор на выходе» работает вдвойне для LLM: плохо структурированные или нерелевантные примеры не просто не помогают — они активно деградируют модель. Гарантируем чистоту данных — каждая запись проходит валидацию на дубли, PII и утечку промпта.

Проблемы, которые мы решаем

Типичные ошибки при подготовке датасета: неверный выбор формата, несбалансированность классов, дубли (exact и near-duplicate), утечка промпта в ответ, присутствие PII (имена, email, телефоны). Неравномерное распределение длины ответов приводит к смещению модели. Мы видим это на каждом втором проекте. Наши инженеры используют автоматические валидаторы и стратифицированное разбиение, чтобы исключить эти проблемы. Например, избыточный вес длинных ответов может исказить распределение вероятностей модели.

Как мы это делаем: стек и кейс из нашей практики

Для нашего клиента из финтеха мы подготовили датасет для дообучения LLaMA 3 под генерацию SQL-запросов. Использовали формат ChatML с системным промптом, добавили 15 000 примеров с различной сложностью (от SELECT до JOIN и подзапросов). Каждый пример проверяли семантической дедупликацией с порогом 0.93 — убрали 12% near-дублей. Экономия бюджета клиента составила 30% (около $4 500).

Форматы датасетов для fine-tuning

Instruction following (Alpaca формат):

{"instruction": "Переведи на английский", "input": "Привет мир", "output": "Hello world"}
{"instruction": "Напиши SQL запрос", "input": "Выбери всех пользователей старше 30", "output": "SELECT * FROM users WHERE age > 30;"}

Chat format (ShareGPT/ChatML):

{
  "conversations": [
    {"from": "system", "value": "Ты помощник по SQL"},
    {"from": "human", "value": "Как выбрать уникальные значения?"},
    {"from": "gpt", "value": "Используй SELECT DISTINCT: `SELECT DISTINCT column FROM table;`"}
  ]
}

Сравнение форматов датасетов

Как правильно структурировать датасет для fine-tuning?

Каждый пример должен содержать чёткую инструкцию, контекст (если нужен) и идеальный ответ. Длина output — от 10 до 2000 токенов. Ответ не должен содержать фрагментов инструкции или устаревших данных. Мы используем класс FineTuningExample с валидацией полей:

class FineTuningExample:
    instruction: str    # Чёткая задача без двусмысленности
    input: str          # Конкретный контекст/данные (опционально)
    output: str         # Идеальный ответ модели

    def validate(self) -> list[str]:
        issues = []
        if len(self.output) < 10:
            issues.append("Output too short")
        if len(self.output) > 2000:
            issues.append("Output may be too long for this task")
        if self.output in ["I don't know", "N/A", ""]:
            issues.append("Uninformative output")
        if self.instruction.lower()[:20] in self.output.lower():
            issues.append("Output contains instruction text")
        return issues

Требования к объёму датасета

Почему важна дедупликация?

Дубли (exact и near-duplicate) искажают распределение данных, заставляя модель «заучивать» одни и те же паттерны. Это снижает обобщающую способность и увеличивает риск переобучения. Мы применяем два уровня дедупликации:

def deduplicate_exact(examples: list) -> list:
    seen = set()
    unique = []
    for ex in examples:
        h = hashlib.md5(f"{ex.instruction}{ex.input}".encode()).hexdigest()
        if h not in seen:
            seen.add(h)
            unique.append(ex)
    return unique

def deduplicate_semantic(examples: list, threshold: float = 0.95) -> list:
    model = SentenceTransformer('all-MiniLM-L6-v2')
    texts = [f"{e.instruction} {e.input}" for e in examples]
    embeddings = model.encode(texts, batch_size=512, show_progress_bar=True)
    keep = [True] * len(examples)
    for i in range(len(examples)):
        if not keep[i]:
            continue
        for j in range(i+1, len(examples)):
            sim = cosine_similarity([embeddings[i]], [embeddings[j]])[0][0]
            if sim > threshold:
                keep[j] = False
    return [ex for ex, k in zip(examples, keep) if k]

Разделение на train/eval

Стратифицированное разбиение по длине output — обязательное требование. Группируем примеры на короткие (<200 токенов), средние (200–500) и длинные (>500). Внутри каждой группы — случайное разделение 90/10. Eval set не должен пересекаться с train ни по exact, ни по semantic.

Финальный чеклист перед обучением

• [ ] Нет дублей (exact и near-duplicate)
• [ ] Нет PII в датасете (имена, email, телефоны)
• [ ] Output не содержит ссылок на даты/версии
• [ ] Равномерное распределение по типам задач
• [ ] Eval set не пересекается с train
• [ ] Токенизированные примеры не превышают max_length модели

Что входит в работу (deliverables)

• Анализ исходных данных и выявление проблем
• Структурирование в выбранный формат (Alpaca/ChatML)
• Валидация каждого примера (PII, утечка, длина)
• Дедупликация exact и semantic
• Подготовка train/eval сплита с сохранением распределения
• Документация по датасету (статистика, описание полей)
• Поддержка на этапе обучения модели

Процесс работы

1. Аналитика — изучаем задачу и исходные данные.
2. Проектирование — выбираем формат и схему валидации.
3. Реализация — пишем скрипты для структурирования и очистки.
4. Тестирование — проверяем качество на пилотном датасете.
5. Деплой — передаём готовый датасет с документацией.

Сроки и стоимость

Сроки: от 3 до 14 рабочих дней в зависимости от объёма и сложности. Стоимость рассчитывается индивидуально — оценим ваш проект за 2 дня. Свяжитесь с нами, чтобы получить консультацию по вашему датасету. Закажите подготовку датасета уже сегодня. Опыт наших инженеров — 5+ лет в дообучении LLM, мы гарантируем чистоту и сбалансированность данных.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

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

Инструменты. Apache Spark (Wikipedia) для больших объёмов (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% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. 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.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для 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.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

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

Как мы строим пайплайн: пошагово

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

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

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