Как вы управляете качеством разметки (label quality) для DPO датасетов?
Краткий тезис
Качество разметки в DPO-датасетах критически важно, потому что DPO (Direct Preference Optimization) обучается на парах предпочтений (chosen/rejected). Плохая разметка приводит к шумным градиентам и нестабильному обучению. Управление качеством строится на комбинации метрик согласованности аннотаторов (agreement|Cohen's Kappa), золотых тестовых примерах (goldenset), детекции выбросов, мажоритарном голосовании и арбитраже спорных случаев. Системный подход включает итеративное улучшение инструкций и постоянный мониторинг.
1. Термин: DPO (Direct Preference Optimization)
DPO — метод обучения языковых моделей, который напрямую оптимизирует политику модели на основе пар предпочтений (chosen/rejected), без отдельной модели вознаграждения. Датасет для DPO состоит из троек: (prompt, chosen_response, rejected_response). Качество разметки напрямую влияет на то, какие паттерны модель выучит.
Почему качество разметки критично
- Шумные пары (например, chosen на самом деле хуже rejected) заставляют модель учиться неправильным предпочтениям.
- DPO чувствителен к перекосу: если большинство пар размечено неверно, модель может схлопнуться к тривиальным ответам.
- Разметка обычно делается людьми или сильными LLM (например, GPT-4), и оба источника содержат ошибки.
2. Inter-annotator agreement (согласованность между аннотаторами)
Inter-annotator agreement — метрика, показывающая, насколько разные аннотаторы согласны друг с другом при разметке одних и тех же примеров. Основной инструмент — Cohen's Kappa (для двух аннотаторов) или Kappa|Fleiss' Kappa (для нескольких).
Cohen's Kappa учитывает случайное совпадение:
κ = (P_o - P_e) / (1 - P_e)
где P_o — наблюдаемая доля согласия, P_e — ожидаемая доля случайного согласия.
Интерпретация
| Значение κ | Согласованность |
|---|---|
| < 0 | Хуже случайной |
| 0.0–0.2 | Очень слабая |
| 0.21–0.40 | Слабая |
| 0.41–0.60 | Умеренная |
| 0.61–0.80 | Хорошая |
| 0.81–1.0 | Очень хорошая |
Рекомендация на пилотном сете (100–200 примеров) добиться κ > 0.7. Если ниже — пересматривать инструкции для аннотаторов.
Пример расчёта на Python
from sklearn.metrics import cohen_kappa_score
annotator1 = [1, 0, 1, 1, 0, 1] # 1 = chosen, 0 = rejected
annotator2 = [1, 0, 0, 1, 0, 1]
kappa = cohen_kappa_score(annotator1, annotator2)
print(f"Cohen's Kappa: {kappa:.2f}")
3. Goldenset (золотой набор)
Goldenset — небольшой набор примеров (обычно 5% от всего датасета), для которых метки (какой ответ chosen, какой rejected) известны с высокой достоверностью. Эти примеры специально отбираются экспертами, включая сложные пограничные случаи.
Как используется
- Все аннотаторы обязательно размечают goldenset (вперемешку с обычными примерами).
- Если аннотатор ошибается на goldenset чаще порога (например, >10% ошибок), его разметка отбраковывается или пересматривается.
- Goldenset обновляется по мере появления новых сложных кейсов.
Пример структуры goldenset
| prompt | chosen_response | rejected_response | пояснение |
|---|---|---|---|
| "Как приготовить яичницу?" | "Разбейте яйца на сковороду..." | "Сначала включите духовку..." | rejected нерелевантен |
4. Outlier detection (детекция выбросов)
Outlier detection — поиск аннотаторов, чьи метки систематически отклоняются от консенсуса. Методы:
- Низкое согласие с goldenset (см. выше).
- Статистика по времени: аннотатор размечает слишком быстро (менее 5 секунд на пример) — признак невнимательности.
- Постоянные ошибки: например, всегда выбирает первый ответ как chosen, независимо от содержания.
- Анализ распределения меток: если у аннотатора 90% меток "chosen", а у остальных ~50%, это подозрительно.
Действия таких аннотаторов исключают из пула или отправляют на переобучение.
5. Consensus (мажоритарное голосование)
Consensus — каждый пример размечается несколькими аннотаторами (обычно 3). Итоговая метка определяется majority vote (большинством голосов).
Преимущества
- Снижает влияние случайных ошибок одного аннотатора.
- Позволяет оценить уверенность в метке (3/3 — высокая, 2/1 — спорная).
Недостатки
- Увеличивает стоимость разметки в 3 раза.
- Требует координации и платформы для распределения задач.
Пример:
| Пример | Аннотатор 1 | Аннотатор 2 | Аннотатор 3 | Итог (majority) |
|---|---|---|---|---|
| prompt_1 | chosen | chosen | rejected | chosen (2/3) |
| prompt_2 | rejected | rejected | rejected | rejected (3/3) |
6. Adjudication (арбитраж)
Adjudication — процесс разрешения спорных примеров, где голоса разделились 2:1. Такие примеры передаются senior-аннотатору (эксперту), который принимает окончательное решение.
Правила
- Senior-аннотатор видит все три исходные метки и может запросить пояснения.
- Решение senior'а считается истиной и добавляется в goldenset для будущих проверок.
- Доля спорных примеров — индикатор сложности датасета. Если >20% — нужно уточнять инструкции.
7. Дополнительные методы контроля качества
7.1 Итеративное улучшение инструкций
После каждого раунда разметки анализируются ошибки (особенно на goldenset) и обновляется guideline (инструкция для аннотаторов). Пример: если аннотаторы путают "фактическую точность" и "стилистическую привлекательность", в инструкцию добавляются чёткие критерии.
7.2 Активное обучение (active learning)
Модель предсказывает, какие примеры будут наиболее информативными (например, с низкой уверенностью). Эти примеры отправляются на разметку нескольким аннотаторам для повышения качества.
7.3 Кросс-валидация аннотаторов
Каждый аннотатор время от времени получает примеры, уже размеченные другими. Сравнение меток позволяет выявить дрейф качества.
7.4 Использование LLM как второго аннотатора
Можно использовать сильную LLM (GPT-4, Claude) для предварительной разметки, а человек проверяет только спорные случаи. Это снижает стоимость, но требует валидации согласованности человек-LLM.
8. Метрики качества разметки
Помимо Cohen's Kappa, полезны:
- Accuracy на goldenset — доля правильных меток аннотатора на золотом наборе.
- Fleiss' Kappa — для более чем двух аннотаторов.
- Confusion matrix — показывает, какие типы ошибок чаще всего допускаются (например, chosen путают с rejected).
- Время на пример — слишком быстрое или медленное разметка может указывать на проблемы.
9. Инструменты для управления качеством
| Инструмент | Назначение |
|---|---|
| Label Studio | Платформа для разметки с поддержкой multiple annotators и экспортом метрик согласия |
| Prodigy | Инструмент для активного обучения и быстрой разметки с возможностью калибровки |
| Amazon SageMaker Ground Truth | Облачный сервис с встроенными механизмами консенсуса и арбитража |
| Open-source скрипты | На Python: расчёт Cohen's Kappa, детекция выбросов (scipy, sklearn) |
10. Практические рекомендации
- Начинайте с пилота 100–200 примеров, 3 аннотатора, расчёт κ.
- Создайте goldenset из 5% примеров, включая сложные кейсы.
- Установите пороги κ > 0.7, accuracy на goldenset > 90%, время на пример > 10 сек.
- Автоматизируйте детекцию выбросов скрипт, который ежедневно проверяет метрики каждого аннотатора.
- Используйте мажоритарку + арбитраж для финального датасета.
- Итеративно улучшайте инструкции на основе анализа ошибок.
Пет-проект для закрепления
Задача Разработать пайплайн контроля качества разметки для DPO-датасета на 10 000 примеров.
Инструменты Python, Label Studio (или локальный скрипт), библиотеки sklearn, pandas.
Шаги:
- Создать синтетический датасет из 1000 примеров (prompt + 2 ответа) с известными "истинными" метками.
- Симулировать 5 аннотаторов с разным уровнем шума (от 0% до 30% ошибок).
- Реализовать:
- Расчёт Cohen's Kappa для каждой пары аннотаторов.
- Выделение goldenset (5% примеров) и проверку accuracy.
- Majority vote для каждого примера.
- Детекцию аннотаторов-выбросов (низкая accuracy на goldenset, подозрительное распределение меток).
- Арбитраж для спорных примеров (2:1) — назначение "истинной" метки.
- Сравнить итоговый датасет (после всех фильтров) с истинным — измерить accuracy финальных меток.
Ожидаемый результат Пайплайн, который повышает accuracy датасета с 85% (сырые метки) до 95%+ (после контроля качества). Код с комментариями и визуализацией метрик.
Связь с другими вопросами
| Вопрос | Тема |
|---|---|
| 515 | Как собирать данные для DPO? |
| 517 | Как оценивать качество DPO-модели? |
| 520 | Что такое RLHF и чем отличается от DPO? |
| 510 | Как аугментировать данные для обучения LLM? |
| 508 | Как детектить и удалять дубликаты в датасете? |
| 503 | Какие метрики качества данных вы знаете? |
Навигация
- Предыдущий: 515
- Следующий: 517
- Индекс: 00. Индекс разборов