Валидация качества датасета для дообучения LLM: аудит и очистка

Валидация качества датасета для дообучения LLM: аудит и очистка

Запустили fine-tuning на 100 A100, потратили трое суток, а модель выдаёт бессвязный бред? Или хуже — утекла конфиденциальность? Причина почти всегда в датасете. Мы это видели десятки раз: в одном проекте после обучения модель начала выдавать пароли из обучающих данных — оказалось, в QA-примерах ответ содержал следующий вопрос. Пустые строки, обрезанные тексты, несоответствие инструкциям — всё это убивает модель, если не провести системную валидацию до запуска.

Например, в датасете из 50 000 примеров мы нашли 6000 полных дубликатов и 2000 обрезанных ответов. После очистки модели показали прирост точности на 15%. Наш сервис проверяет датасет за 1–2 дня и выдаёт детальный отчёт с рекомендациями. Вы получаете готовый к обучению набор данных под ключ.

Как валидация датасета предотвращает деградацию модели?

Плохой датасет — не просто потеря GPU-часов. Это риск получить модель с низкой точностью, предвзятостью или уязвимостью к prompt injection. Наш опыт показывает: после валидации pass rate взлетает с 60% до 95% в среднем за счёт удаления дубликатов и обрезанных примеров. Alignment score тоже растёт — мы исправляем инструкции, которые ввели модель в заблуждение. Средняя экономия на повторном обучении составляет от 300 000 до 1 000 000 рублей.

Уровни валидации

Мы используем три уровня проверки, каждый закрывает свой класс проблем.

Уровень 1 — Технический (автоматизированный)

Здесь мы проверяем базовые вещи: пустые строки, длину в токенах, обрывы текста, кодировку, дубликаты. Всё это можно автоматизировать скриптом, но важно не пропустить пороговые значения.

from dataclasses import dataclass
import pandas as pd

@dataclass
class ValidationReport:
    total_examples: int
    issues: dict
    pass_rate: float
    recommendations: list[str]

class DatasetValidator:
    def validate(self, dataset: list[dict]) -> ValidationReport:
        issues = {
            'empty_outputs': [],
            'too_short': [],
            'too_long': [],
            'truncated': [],
            'encoding_issues': [],
            'near_duplicates': [],
        }

        tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")

        for i, ex in enumerate(dataset):
            output = ex.get('output', '')

            # Пустые outputs
            if not output.strip():
                issues['empty_outputs'].append(i)
                continue

            # Длина в токенах
            tokens = tokenizer.encode(output)
            if len(tokens) < 5:
                issues['too_short'].append(i)
            elif len(tokens) > 2000:
                issues['too_long'].append(i)

            # Потенциально обрезанный текст (заканчивается на незаконченной фразе)
            if output.strip()[-1] not in '.!?])"\'':
                if len(tokens) > 500:  # Длинный текст без финала
                    issues['truncated'].append(i)

            # Encoding issues
            try:
                output.encode('utf-8').decode('utf-8')
            except (UnicodeEncodeError, UnicodeDecodeError):
                issues['encoding_issues'].append(i)

        total_issues = sum(len(v) for v in issues.values())
        pass_rate = 1 - total_issues / len(dataset)

        return ValidationReport(
            total_examples=len(dataset),
            issues=issues,
            pass_rate=pass_rate,
            recommendations=self._generate_recommendations(issues, len(dataset))
        )

Уровень 2 — Семантический (автоматизированный)

Здесь мы используем LLM-судью: модель оценивает, насколько ответ соответствует инструкции. Это особенно важно для задач, где ожидается точное следование команде. Наш пайплайн в 10 раз быстрее ручной проверки и не устаёт.

class SemanticValidator:
    def check_instruction_output_alignment(self, dataset: list[dict],
                                            sample_size: int = 200) -> float:
        """Насколько output соответствует instruction"""
        sample = random.sample(dataset, min(sample_size, len(dataset)))

        alignment_scores = []
        for ex in sample:
            score = self._compute_alignment(
                ex['instruction'], ex.get('input', ''), ex['output']
            )
            alignment_scores.append(score)

        return np.mean(alignment_scores)

    def _compute_alignment(self, instruction: str, input: str, output: str) -> float:
        """LLM-judge для оценки релевантности"""
        prompt = f"""Does this output correctly address the instruction?

Instruction: {instruction}
Input: {input}
Output: {output[:500]}

Rate relevance 1-5, return only number."""

        response = llm_client.complete(prompt, max_tokens=5)
        try:
            score = int(response.strip()) / 5.0
        except ValueError:
            score = 0.5  # Неопределённость → средний балл

        return score

Уровень 3 — Содержательный (ручная проверка)

Автоматика не видит всего. Мы делаем стратифицированную выборку (по длине ответов) и отправляем на проверку эксперту. Это выявляет логические ошибки, системные предубеждения и утечку контекста.

def sample_for_human_review(dataset: list[dict],
                              n: int = 100) -> list[dict]:
    """Стратифицированная выборка для ручной проверки"""
    short = [ex for ex in dataset if len(ex['output'].split()) < 50]
    medium = [ex for ex in dataset if 50 <= len(ex['output'].split()) < 200]
    long = [ex for ex in dataset if len(ex['output'].split()) >= 200]

    sample = []
    per_stratum = n // 3
    for stratum in [short, medium, long]:
        sample.extend(random.sample(stratum, min(per_stratum, len(stratum))))

    return sample

Почему автоматической проверки недостаточно?

Автоматика вылавливает 80% технических проблем, но не видит семантических ловушек. Например, в датасете из 50 000 примеров мы нашли 12% дубликатов — модель просто запомнила их. А ручная проверка вскрыла 30 примеров с утечкой контекста: ответ содержал информацию из будущего диалога. Только комбинация трёх уровней даёт уверенность перед обучением.

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

Собираем всё в единый отчёт с чётким вердиктом: GO или NO-GO.

def generate_pre_training_report(dataset: list[dict]) -> str:
    validator = DatasetValidator()
    semantic_val = SemanticValidator()

    tech_report = validator.validate(dataset)
    alignment_score = semantic_val.check_instruction_output_alignment(dataset)

    report = f"""
## Dataset Validation Report

**Total examples:** {tech_report.total_examples:,}
**Technical pass rate:** {tech_report.pass_rate:.1%}
**Instruction-Output alignment:** {alignment_score:.2f}/1.0

### Issues Found:
- Empty outputs: {len(tech_report.issues['empty_outputs'])}
- Too short (<5 tokens): {len(tech_report.issues['too_short'])}
- Too long (>2000 tokens): {len(tech_report.issues['too_long'])}
- Potentially truncated: {len(tech_report.issues['truncated'])}
- Near-duplicates: {len(tech_report.issues['near_duplicates'])}

### Recommendations:
{chr(10).join('- ' + r for r in tech_report.recommendations)}

**GO / NO-GO:** {'GO' if tech_report.pass_rate > 0.9 and alignment_score > 0.7 else 'NO-GO — fix issues before training'}
"""
    return report

Порог для go/no-go: технический pass rate > 90%, alignment score > 0.70. При alignment < 0.70 — датасет содержит примеры, где output не отвечает на instruction, что активно деградирует модель.

Что входит в работу по валидации?

Под ключ: вы получаете очищенный датасет с метриками качества и рекомендациями по доработке. Оценим ваш датасет за 1 день — получите консультацию.

Типичные ошибки, которые мы находим

Все эти проблемы мы фиксируем в отчёте и даём конкретные правки.

Как заказать валидацию датасета?

1. Отправьте датасет в формате JSONL или CSV.
2. Мы проводим технический аудит за 1 день.
3. Семантический анализ и выборка для ручной проверки — ещё 1 день.
4. Вы получаете отчёт и очищенный датасет.

Наш опыт и гарантии

За 5 лет мы провели более 50 аудитов для стартапов и крупных компаний. Наши инженеры имеют сертификаты по PyTorch и Hugging Face. Гарантируем конфиденциальность данных и точность оценки. Свяжитесь с нами — разберём ваш датасет бесплатно и предложим оптимальный план валидации.

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-пайплайна под ключ.