Как разметка данных влияет на fine-tuning LLM

Вы запустили fine-tuning своей LLM, а качество ответов оказалось ниже ожидаемого. Чаще всего причина не в архитектуре, а в данных. 70% проблем с fine-tuning связаны с качеством разметки, а не с выбором модели или гиперпараметрами. Неправильно собранный датасет приводит к падению метрик на 20‑30% по сравнению с хорошо размеченным. Разметка для дообучения принципиально отличается от классической ML‑разметки: здесь не присваивается метка, а создаётся идеальный ответ модели. Качество аннотаций напрямую определяет качество обученной модели. За 5 лет мы реализовали свыше 50 проектов — от поддержки клиентов до многошаговых агентов, и гарантируем профессиональный подход к каждому.

Типы аннотации

Выбор способа зависит от объёма, бюджета и требуемого качества. Ниже — сравнение основных подходов.

Direct annotation — разметчик создаёт пару (инструкция, идеальный ответ) с нуля. Самое высокое качество, самый высокий cost. Используем для критичных к качеству доменов (юриспруденция, медицина).

Edit-based annotation — разметчик улучшает ответ базовой модели. В 2‑3 раза быстрее, чем с нуля. Риск: разметчик принимает плохой ответ с минорными правками. Чтобы этого избежать, включаем обязательное поле «обоснование изменений».

Ranking/Preference annotation — разметчик ранжирует несколько ответов модели (используется для RLHF и DPO). Проще, чем создание с нуля, но требует чёткого понимания критериев качества. Без них kappa между аннотаторами редко превышает 0.4.

AI-assisted annotation — сильная модель (GPT‑4) генерирует ответы, люди проверяют и корректируют. Оптимальный баланс качества и скорости для большинства задач. На практике даёт 90% качества direct при 30% стоимости.

Как выбрать тип аннотации?

Если ваша задача — обучить модель отвечать на типовые вопросы (поддержка, FAQ), выбирайте AI-assisted с финальной вычиткой. Для творческих задач (генерация кода, креатив) — direct annotation. Для задач с ранжированием (рекомендательные системы) — ranking/Preference. Если бюджет ограничен, можно комбинировать: 20% direct для обучения аннотаторов и 80% edit-based для основного объёма. Получите консультацию по подбору типа аннотации для вашего проекта — мы поможем с выбором.

Руководство по аннотации (Annotation Guidelines)

Ключевой документ, без которого аннотаторы будут давать несогласованные результаты. Включаем в него:

• критерии качества (точность, полнота, тон, длина, структура);
• примеры хорошего ответа с разбором;
• примеры плохого ответа с объяснением ошибок;
• список запрещённых фраз («Я просто языковая модель…», «Я не могу…»);
• правила обработки неоднозначных запросов.

Мы разрабатываем guidelines под каждый проект и проводим calibration сессии перед стартом. Пример guidelines для Customer Support Assistant:

## Руководство по аннотации: Customer Support Assistant

### Критерии качества хорошего ответа:
1. Точность: Ответ соответствует политикам компании и фактически верен
2. Полнота: Решает проблему пользователя, не оставляя открытых вопросов
3. Тон: Профессиональный, эмпатичный, без извинений за несуществующие проблемы
4. Длина: Достаточная, но не избыточная (100-300 слов оптимально)
5. Структура: Абзацы, без списков для простых ответов

### Что НЕ должно быть в ответе:
- "Я просто языковая модель..."
- "Я не могу..."
- Повторение вопроса пользователя
- Неуместные извинения
- Устаревшая информация о продукте

### Примеры ХОРОШЕГО ответа: [примеры]
### Примеры ПЛОХОГО ответа: [примеры с объяснением]

Платформы для аннотации

Label Studio (open-source):

from label_studio_sdk import Client

ls = Client(url='http://localhost:8080', api_key='...')

# Создание проекта для LLM аннотации
project = ls.start_project(
    title='Customer Support Fine-tuning',
    label_config='''
<View>
    <Text name="instruction" value="$instruction"/>
    <TextArea name="response" toName="instruction"
              placeholder="Write ideal response..."
              rows="10" maxSubmissions="1"/>
    <Rating name="quality" toName="instruction"
            maxRating="5" icon="star" size="medium"/>
</View>
    '''
)

# Загрузка задач
tasks = [{"instruction": ex.instruction, "input": ex.input}
         for ex in unannotated_examples]
project.import_tasks(tasks)

Scale AI / Appen — для больших объёмов с профессиональными аннотаторами. Существенно дороже, но Quality Control включён. Используем их для проектов с объёмом от 50 000 пар.

Как контролировать качество аннотаций?

Основной метрикой является inter-annotator agreement (IAA) — согласованность между аннотаторами. Чем выше, тем надёжнее данные. Для контроля качества мы закладываем перекрытие 10–20% задач, которые размечаются двумя специалистами независимо. Считаем Cohen's Kappa — меру согласия, используемую в NLP.

from sklearn.metrics import cohen_kappa_score

def compute_iaa(annotations_a: list, annotations_b: list) -> float:
    """Cohen's Kappa для согласованности аннотаторов"""
    # Для ranking задач (1-5 rating)
    kappa = cohen_kappa_score(annotations_a, annotations_b)
    print(f"Cohen's Kappa: {kappa:.3f}")
    # < 0.4: низкое согласие, пересмотр guidelines
    # 0.6-0.8: хорошее согласие
    # > 0.8: отличное согласие
    return kappa

Низкая согласованность (< 0.4) — сигнал, что guidelines неоднозначны. Мы дорабатываем документ, проводим дополнительную calibration сессию и повторно замеряем IAA.

Calibration сессии перед стартом полноценной аннотации: совместная разметка 20‑50 примеров всей командой, обсуждение расхождений, уточнение guidelines. Это критически снижает варианс между аннотаторами. Без калибровки даже опытные аннотаторы дают kappa < 0.5 на сложных задачах. После калибровки — стабильно 0.7+.

Почему важны calibration сессии?

Потому что без них разброс между аннотаторами может свести на нет все усилия по сбору данных. Одна calibration сессия снижает количество переделок на 40% и повышает итоговую точность модели на 15‑20%. Это экономит до 30% бюджета проекта. Оптимизация разметки снижает затраты на 35–40% по сравнению с традиционными методами. Закажите пилотную калибровку — мы покажем эффект на ваших данных.

Что входит в нашу работу по разметке данных?

Ниже — основные этапы и их длительность.

Сроки зависят от объёма и сложности: от 2 недель для 1000 пар до 2‑3 месяцев для 50 000+. Стоимость рассчитывается индивидуально. Мы работаем как с разовыми проектами, так и с долгосрочным аутсорсингом аннотации. Получите консультацию для оценки вашего проекта — оценим объём работы, подберём оптимальный метод аннотации и рассчитаем сроки.

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