Интеграция Prodigy для разметки данных: Active Learning и spaCy

Почему разметка данных в Prodigy упирается в ручной труд

Разметка данных Prodigy устроена вокруг одного примера: интерфейс показывает текст, подсказку модели и ждёт метку. Инструмент аккуратно фиксирует ответ, но не решает, какие примеры вообще стоит показывать — порядок задаёт человек или случайная выборка.

Отсюда первое узкое место разметки: значительная часть выдачи — очевидные случаи, где метка совпадает с предсказанием модели и обучению ничего не даёт. Аннотатор тратит на них основное время, а спорные примеры получают ровно одну метку и уходят в датасет без перепроверки.

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

В итоге качество обучающей выборки определяется не задачей, а тем, кто и в каком порядке размечал. Модель доучивается на спорных примерах и затверживает шум — качество на отложенной выборке стоит на месте, а объём ручной разметки датасета растёт вместе с требованиями к точности. Разбираем, как это закрывается: приоритизация примеров, контроль согласованности и повторная разметка граничных случаев.

Что даёт обучение модели на спорных примерах

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

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

Эффект измерим. Доля записей, которые действительно требуют ручной сверки, падает в 3–5 раз против сплошной разметки: 80–90 % корпуса — однозначные примеры, и они уходят в полуавтоматическую разметку. Точность на спорных срезах при этом выше, чем при равномерной выборке: каждая спорная запись приносит модели максимум новой информации.

Отбор спорных примеров вскрывает и дефекты самой схемы: противоречивые метки у похожих записей, пересекающиеся классы, редкие категории без единого уверенного примера. Мы разбираем такие случаи до релиза — переносим их в инструкцию для аннотаторов и в проверки на валидации, а не находим в рабочей эксплуатации по жалобам пользователей.

Режимы разметки: ручной, полуавтоматический, гибридный

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

Гибридный режим обычно берут на длинных проектах: модель предлагает вариант, человек подтверждает или отклоняет его, а спорные примеры уходят в отдельную очередь на перепроверку. Объём чистой ручной работы падает, но без метрики согласия между разметчиками шум в обучающей выборке остаётся незамеченным — и проявляется уже на качестве модели.

Ориентир при выборе — доля неоднозначных примеров: если она выше трети, полуавтоматический режим начинает подсказывать человеку его же ошибки, и цикл замыкается сам на себя. Prodigy позволяет вести все три режима в одном интерфейсе и переключаться по мере роста выборки, не теряя уже размеченные данные.

Как мы выстраиваем цикл аннотирования под задачу

Внедрение разметки начинаем не с запуска инструмента, а с аудита схемы меток: смотрим текущий корпус, находим пересекающиеся и «мёртвые» классы, оцениваем, сколько примеров на класс реально есть. Схема, где 40 меток и по три примера на каждую, не даст обучаемой модели ни при активном обучении, ни при ручной выборке — поэтому часть классов объединяем, часть переводим в атрибуты. Дальше собираем контур аннотирования и только потом сажаем людей за разметку, иначе переделывать придётся уже готовый набор.

1. Аудит схемы меток и корпуса. Проверяем согласованность текущей разметки, считаем долю спорных примеров и классовый дисбаланс. На выходе — сокращённая схема с инструкцией по пограничным случаям.
2. Проектирование контура аннотирования. Определяем интерфейс под тип задачи — классификация, сущности, связи, — роли разметчиков, долю примеров на взаимную проверку и порядок снятия конфликтов.
3. Настройка активного обучения. Подключаем модель-кандидата на актуальной ветке Prodigy: она отбирает в очередь примеры с низкой уверенностью и спорные случаи, а не случайную выборку.
4. Пилот на контрольной партии. Размечаем небольшой объём, замеряем согласованность между аннотаторами и правим инструкцию до того, как разметка уйдёт в промышленный объём.
5. Обучение и замер качества. Готовим модель spaCy, сверяем метрики на отложенной выборке и смотрим, какие классы ошибок растут при добавлении новых данных.
6. Регламент аннотирования. Фиксируем схему меток, критерии качества, порядок эскалации спорных случаев и правила версионирования наборов данных.
7. Передача и сопровождение. Показываем команде заказчика очередь, метрики и точки дообучения; отдельно проговариваем, как менять схему меток без потери уже размеченного корпуса.

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

Поставка: конфигурация, схема меток, регламент проверки

Настроенный проект в Prodigy передаём как рабочий комплект, а не как архив файлов: команда заказчика должна запускать разметку и дообучение модели без нас. Ниже — что именно остаётся в репозитории и в документации по разметке.

• Конфигурация проекта: интерфейс разметки под задачу, пороги отбора примеров для активного обучения, связка с моделью spaCy и параметры её дообучения.
• Схема меток: полный перечень классов, правила их взаимоисключения и приоритеты, примеры на каждый класс и отдельно — граничные случаи, где разметчики чаще всего расходятся.
• Инструкция для разметчиков: длина выделяемых фрагментов, действия со спорными и вложенными сущностями, порядок эскалации вопросов.
• Регламент проверки разметки: доля задач на повторную разметку, разбор расхождений, порог согласия и ответственный за финальное решение.
• Критерии качества разметки: метрики согласованности между разметчиками, доля отбракованных задач, условие возврата модели на новую итерацию обучения.
• Эталонный набор примеров: фиксированная выборка, на которой прогоняем каждую новую версию модели и сравниваем с предыдущей.
• Схема движения данных: как размеченные примеры попадают в обучение, как версионируется набор данных и как откатиться к предыдущей версии.

Передаём всё с обучением команды и краткими записями по каждому артефакту — чтобы правки в схему меток вносились осознанно. Обсудим задачу — вернёмся с планом поставки под ваш процесс.

Кейс: классификация обращений и рост согласованности меток

Что было до

Разметку вели в таблицах: несколько аннотаторов проставляли категории обращения в общий лист, а спорные случаи разбирали ручной сверкой раз в неделю. Правила классов жили в переписке и у каждого в голове, поэтому один и тот же запрос «не проходит оплата» попадал то в «оплату», то в «сбой интеграции». Согласованность аннотаторов держалась около 0.6 по доле совпавших меток — модель училась на противоречивых примерах и разваливалась именно на пограничных классах.

Что изменили и что получилось

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

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

Что делать, если модель уже обучена на шумных метках?

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

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

Очередь на перепроверку строится не случайно: в рабочем контуре на Prodigy мы приоритизируем именно расхождения модели и метки, от самых уверенных к спорным. Каждая правка сохраняет исходное значение, вердикт ревьюера и причину — уже собранные данные остаются в базе аннотаций, ничего не перезаписывается вслепую.

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

Ограничения решения и частые технические сомнения

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

Что делать, если редкий класс не набирает примеров?

Модель-подсказка отбирает только то, что уже умеет, поэтому для редких классов её отключаем и ищем кандидатов регулярками, словарями или близостью векторов. Порог уверенности опускаем, лишние срабатывания уходят на проверку.

Можно ли перенести разметку, сделанную раньше в других инструментах?

Да: конвертируем привычные форматы — таблицы, JSON, разметку сущностей в тексте — в нужную схему, сохраняя смещения символов, иначе границы сущностей поедут. Расхождения в правилах (вложенные сущности, разные трактовки границ) разбираем отдельно.

Когда дообучать модель и как заметить, что стало хуже?

Цикл: партия разметки, дообучение, прогон по замороженной контрольной партии, отбор ошибок в следующую партию. Набор в пару сотен примеров с двойной разметкой даёт точность и полноту по классам — регрессии видны до выката.

Обсудим задачу: что прислать и как пойдёт работа

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

• Пример данных «как есть» — несколько сотен реальных записей с шумом, опечатками и неполными полями: на них проверяем, что схема меток выдерживает ваш домен, а не только чистые примеры.
• Черновик того, что модель должна различать: список сущностей или классов и по 10–15 случаев «так правильно / так неправильно». Спорные случаи здесь ценнее однозначных.
• Источник и объём: откуда забираем массив, в каком виде он лежит сейчас, сколько записей планируется разметить и с какой периодичностью поступают новые.
• Ограничения по данным: персональные сведения, что нельзя выгружать за периметр, требования к хранению и удалению копий.
• Критерий приёмки: какая доля совпадений с эталоном считается достаточной и на каком сценарии это проверяется.
• Текущий процесс, если он есть: кто размечает, в каких файлах ведётся учёт, сколько времени уходит на одну запись.
• Словарь домена и язык данных: термины, сокращения, смешение языков — их придётся зафиксировать в инструкции разметчика.

Дальше работа идёт так: мы проводим аудит присланного массива, возвращаемся с оценкой проекта разметки и планом внедрения разметки — схема меток, объём, порядок итераций, точки контроля качества. Перед масштабированием запускаем пилот на нескольких сотнях примеров и считаем согласованность разметчиков: если инструкция допускает разночтения, это видно до того, как размечен весь массив. Размечаем в Prodigy, где активное обучение подтягивает в очередь самые спорные примеры, поэтому доля ручной работы падает по ходу проекта. Опишите задачу разметки — вернёмся с оценкой и планом.