Сбор данных и разметка: как с нуля собрать хорошие данные под реальную задачу?

Введение

Почему данные так важны в продакшн-решениях?

Данные — это те самые 80% успеха при решении прикладной ML-задачи. Это то, что определяет, как модель поведёт себя в проде: будет ли делать стабильные предсказания или повторять ошибки, которых можно было избежать на этапе подготовки.

Яркий пример — неудачный кейс Meta с моделью GALACTICA. Отчасти из-за слабой подготовки обучающих данных модель начала генерировать токсичные и фейковые утверждения. В итоге релиз откатили через 3 дня после запуска, и это в такой крупной компании (подробности — здесь)!

Кроме того, подготовка данных — это дорого и долго. По оценке Semianalysis, OpenAI потратили десятки миллионов долларов на сбор разметки для GPT.

И если вы работаете с ML на практике — вы знаете, сколько уходит на поиск разметчиков, согласование инструкций, валидацию качества, пересмотры, перекрёстную проверку и правки. А в финале можно получить данные, которые расходятся с видением задачи команды или менеджеров. Согласны, узнали? 😟

Что делать? Разберём в этой статье лучшие практики и обсудим, как меняется подход к сбору и разметке данных, а именно:

• как использовать LLM в качестве разметчика;
• где всё ещё нужен человек;
• как выстроить пайплайн с краудом, который можно масштабировать и контролировать и которому можно доверять.

Итак, начинаем! 😎

Новый стандарт: разметка через LLM и синтетические данные

Индустрия машинного обучения не стоит на месте, и методы работы с данными стремительно эволюционируют в последние годы. Сейчас всё чаще разметка переходит от человеческих усилий к автоматизации с использованием больших языковых моделей (как LLM, так и vLLM), которые уже содержат большое количество знаний о мире, полученных в процессе обучения.

И появляется всё больше кейсов как, например, в исследованиях:

• “The Importance of Human-Labeled Data in the Era of LLMs”, где ChatGPT превзошёл работников Amazon MTurk на некоторых задачах разметки текстов;
• «RLAIF: Reinforcement Learning from AI Feedback», где методы обучения на данных с AI-фидбеком обеспечивают ту же точность, что и классический RLHF, полностью заменяя человеческие метки на оценки другой LLM.

Так и в реальных задачах:

• Недавно у нас в поиске Яндекса автоматизировали сложную разметку данных с помощью LLM, что дало 105% качества относительно разметки людьми и 60% экономии денег. А ещё получилось построить надёжный продакшн-процесс, которому можно доверять (подробнее в посте).
• Anthropic, Meta, OpenAI активно добавляют синтетические данные при обучении моделей; Writer обучила модель почти полностью на синтетике за $0,7 млн vs $4,6 млн у OpenAI (techcrunch.com).

В результате сбор данных при помощи LLM становится новым стандартом и must-have скиллом для ML-инженера, ведь он упрощает жизнь, экономит ресурсы и сильно ускоряет выход моделей в продакшн.

Вы можете использовать это для генерации или оценки ответов, маркировки классов, генерации JSON-аннотаций и многого другого.

Получение данных при помощи предобученных LLM

Разберём это на несложной задаче: классификация школьных математических задач среди запросов пользователей в поисковой системе и в приложении. К примеру, мы хотим на запросах запускать отдельную LLM, которая хорошо умеет решать такие задачи и работать с математическими примерами.

Базовые этапы

1. Подбор первичного промпта

• Берём имеющуюся инструкцию для разметки. Если её нет — начинаем буквально с нескольких предложений, где просим модель разметить данные и дать ответ в удобном для нас формате.
  
• Прогоняем на нескольких примерах и тюним промпт.

Чтобы не держать в голове все промпт-инженерные техники и быстрее начать, лучше использовать саму же LLM для их генерации. Например, можно взять GPT c систем-промптом на основе курсов OpenAI:

• ссылка для обычных моделей;

• ссылка для reasoning (рассуждающих по типу o1 и deepseek r1).

Дальше проще улучшаться, отталкиваясь от предложенного промта. К примеру, модель также предложила добавить уверенность по ответу.

2. Замер качества промта, автометрики

• Производим хотя бы на небольшом количестве примеров с идеальными (ожидаемыми) ответами (допустим, на 100-200 примерах в зависимости от задачи). Чтобы понимать, как часто ошибается модель. И при изменении промпта — действительно ли улучшаете качество!
• Разбираемся с автометриками:
  — качество по ground truth разметке: здесь метрики классификации для бинарного предикта (prec, recal, f1);
  — формат: на каком проценте ответ не следует формату?
  — есть ли байесы? для разметки выбора вариантов ответа это может быть более частый выбор одного из ответов, например, первого;
  — погрешности: расхождения между запусками.

3. Итеративное улучшение

• Декомпозируем задачу
  Например, во взятой задаче мы сталкиваемся со следующими проблемами:
  — относится ли определённая тема, например, «Интегралы», к школьным темам? ⇒ добавляем в промт разметку тематики задач из заданного списка.False postive срабатывания на задачах, смежных с информатикой, физикой и др. ⇒ добавляем в промпт разметку, относится ли текст к определённому предмету.
• Просим модель улучшить промпт на основе требований
  И если в ответе модели видим ошибки — спрашиваем у LLM, почему так, и чего не было в исходном промпте.
• Для каждого ответа и действия требуем chain-of-thoughts
  Просим reasoning для каждого поля перед принятием LLM всех решений, как на скрине выше. Так мы сможем понимать, почему получился такой результат.
• Пробуем разные модели Используем как open-source (Qwen, Deepseek), так и проприетарные и reasoning модели.

Полезные советы

• Использование строгого формата данных и вывода (например, JSON schema) позволяет как легко парсить ответ, так и стабилизировать и стандартизировать результаты. Несколько раз сталкивался с тем, что в данных, которые нужно было разметить был prompt injection, перезатиравший текст выше. И строгий формат позволил решить это.
• Добавление few-shot примеров
• Распределение данных на выборках важно, чтобы совпадало с тем, с чем будет работать модель в продакшене (и даже в самом промте, например few-shot примерах)
• Версионирование: может быть полезно особенно в случае для production-ready решений К примеру по некоторым проектам в своих командах мы версионируем промты LLM в git также как код:
  — принимаем каждое изменение: когда другой разработчик проверяет изменения
  — фиксируем метрики качества
  — параметры запуска этого промта (версия модели, температура и тд), чтобы результаты были воспроизводимыми
• Боремся с шумом: результаты при повторных повторных инференсах
  — выставляем температуру в 0, top_p=0.0001 => стабильность
  — агрегация нескольих запусков: мажоритарное голосование между разными LLM или одной LLM с разными версиями промптов снижает влияние случайных ошибок конкретной модели и может улучшить качество
• Не забываем про классический ML:
  — оцениваем шум
  — шафлим даные
  — избегаем переобучения и откладываем тестовые/валидационныевыборки
• Обогащение промта: дать больше контекста и иформации модели, и возможо терминологии, которая испольуется в вашей инструкции, но может быть не до конца понятна для LLM.

Технические детали

• начальный подбор промпта проще начать в интерфейсе самих моделей, также есть специальные сервисы, например, promptmetheus;
• когда уже собраны автометрики, лучше написать код так, чтобы автоматически запускать инференс и метрики для очередной модели, либо можно также собрать пайплайн в сервисе n8n.

Ручная разметка

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

Когда именно стоит переходить к ручной разметке?

• Когда нужно валидировать автоматическую разметку от LLM
  Особенно если вы используете эти данные в обучении или отслеживаете метрики качества продукта. Слепо доверять и думать: «кажется, всё нормально» — это плохая стратегия. Регулярная проверка и ручная валидация — must-have.
• Когда задача сложная, и нужен контекст
  Например, когда нужно не просто классифицировать запрос, а учесть контекст поведения пользователя или цепочку его предыдущих действий. LLM тут либо путается, либо галлюцинирует.

Комбинированный подход — золотая середина

Простые и однозначные случаи можно с уверенностью оставлять за LLM (при этом, желательно отслеживать метрики уверенности). А вот сложные, edge-кейсы, и те, где есть разночтения, — отправлять к экспертам.

Это поможет:

• улучшить качество. Например, в статье “If in a Crowdsourced Data Annotation Pipeline, a GPT-4” GPT-4 разметил данные с точностью 83,6% против 81,5% у коллективной разметки, вместе достигли 87,5%.
• оптимизировать бюджет. Например, в статье смешивание синтетических и ручных меток оптимально при малом бюджете: на $200 синтетических данных достигнуто то же качество, что и на $1 600 ручных.

Как понять, что пример «сложный»?

Один из простых способов — учитывать значение логитов на выходе или энтропию предсказаний. Такой способ использовался при автоматизации разметки в кейсе Яндекса выше. Если модель «сомневается» — скорее всего, это хороший кандидат для ручной проверки.

Крауд и организация процесса

Если вы всё-таки дошли до ручной разметки, важно сделать её максимально системной и управляемой. Крауд — мощный инструмент, если подойти к нему как к полноценному процессу, а не просто «отдать данные на разметку». Про один из проектов, где получилось построить успешный пайплайн и разметку на реальной задаче в Яндексе, рассказывал в рамках доклада на DataFest: “Улучшение достоверности генеративных моделей: подход к оценке и подготовка данных”.

Как это обычно строится на практике:

1. Инструкция

Здесь процесс похож на то, что описано выше, только вместо LLM у нас асессоры, и взаимодействие с ними приводит к итеративному улучшению инструкции.

При этом, не начинайте разметку с краудом, пока не проверите всё на себе. Сначала разметьте сами несколько десятков примеров. Это поможет выловить все граничные случаи.

Затем дайте разметить редактору — ещё одному человеку в команде. Чтобы проверить, как читается инструкция.

Только после этого переходите к асессорам и запускайте в крауд-платформе (Toloka, Яндекс Задания и др).

2. Шаблон и формат задания

Нужно сразу продумать формат: как должен выглядеть интерфейс задания, как будет вводиться контекст, какие примеры показать (в идеале: хороший, плохой и пограничный).

Подумайте, где будете это запускать: если в Toloka, Яндекс Задания — там можно настроить как свой кастомный формат, через UI и шаблоны.

3. Обучение ассессоров

Если разметка регулярная или критически важная — обязательно запускайте обучение + экзамен. Без этого качество может сильно плавать.

Сделайте хотя бы 5–10 учебных примеров с объяснениями, потом — экзамен с задачами с автоматическим фидбеком и порогом прохождения.

4. Контроль качества разметки

Асессоры могут «читерить», поэтому нужно следить за ними не вручную, а через систему:

• сделать ханипоты (скрытые контрольные задания в заданиях с известным ответом);
• сделать статистику по каждому работнику: процент совпадений, количество потраченного времени, резкие изменения поведения и др.;
• агрегация и перекрытие: дать задачу 2–3 разным людям и посчитать согласие между ними; если не сошлись — передать на редактора или старшего ассессора.

Продвинутые практики

• Используйте знания о качестве ассессоров при обучении ML-модели:
• можно взвешивать примеры в зависимости от надёжности;
• можно фильтровать плохих исполнителей и даже автоматически дообучать LLM только на качественно размеченных примерах.
• Active Learning — не даём ассессору весь датасет, а только самые «неуверенные» или спорные примеры. Также итеративно дообучаем модель на полученных данных и обновляем.
• Визуализация ошибок — строим дашборды, на которых видно, где чаще всего расходятся асессоры и LLM, и куда направить усилия на улучшение инструкции.

Это полноценный production-процесс, и если его выстроить один раз — он масштабируется, переносится на другие задачи и становится реальным преимуществом команды.

Заключение

Качество модели начинается с качества данных. К счастью, сегодня у нас есть мощные инструменты: от LLM, которые могут взять на себя большую часть рутины, до гибридных пайплайнов, где люди подключаются только на нужных им этапах.

Если подойти к процессу сбора и разметки системно, шаг за шагом, — можно кратно сократить стоимость, ускорить вывод моделей в прод и избежать множества багов. А главное — это всё действительно работает в боевых проектах, что мы сейчас видим во многих компаниях.

Если было полезно — в Telegram канале более лично делюсь, как сам использую AI и LLM в работе и жизни ML инженера.