tgoop.com/dsinsights/340
Last Update:
Как размечать данные для промышленных ML моделей правильно?
Зачем это надо?
В индустрии существует такая парадигма Data-Centric AI. Ее в свое время сформулировал великий Andrew Ng. Она гласит, что важна не гонка за сложными моделями, а системная работа с данными. Т.е. большинство ошибок моделей происходит из-за некачественных, грязных данных. Не забываем правило: garbage in — garbage out.
При этом мало просто передать данные разметчикам, получить аннотации. Чаще всего появятся нюансы, из-за которых качественной разметки получить не удастся.
➡️В чем проблема разметки данных в промышленном масштабе?
- Плавающие инструкции: инструкция живёт в голове у тимлида, меняется в процессе, а команда может размечать по старой. В результате имеем в одном датасете — разные логики.
- Отсутствие версионирования: не фиксируется, кто, когда и по какой логике размечал. При проверке сложно понять: ошибка ли это или просто старая версия правила.
- Отсутствие описания пограничных случаев: инструкция охватывает только «идеальные» примеры. Разметчики по-разному трактуют сложные случаи → низкое согласие между ними.
- Отсутствие обратной связи: разметчик не знает, что он ошибается. Ошибки повторяются, система не обучается.
- Один разметчик — один мир: без перекрёстной проверки (двое размечают одно и то же) невозможно отследить согласие.
- Отсутствие контрольных примеров (golden set): Без заранее проверенного набора эталонных аннотаций невозможно оценить качество работы всей команды.
- Человеческий фактор: усталость, выгорание, желание «быстрее сдать». Если не учитывать мотивацию и рутину, качество страдает даже у отличных специалистов.
➡️ Настраиваем процесс разметки, начиная с коммуникаций
Четко ставим задачу и делаем пошаговый онбординг для разметчиков. Проходимся ручками по калибровочным задачам. Также наладиживаем канал обратной связи: куда задавать вопросы, как быстро получать ответы.
➡️ Валидация разметки
Проверка — обязательный этап, организовать ее можно следующим способами:
- Peer review: один разметчик проверяет другого
- Экспертная проверка: отдельный специалист валидирует выборку
- Перекрёстная аннотация: две разметки сравниваются, рассчитывается согласие (Cohen's Kappa)
- Модельный консенсус: если есть обученная модель, используйте её для нахождения расхождений.
К примеру, если мы сравниваем две разметки и рассчитываем согласие, то можем в случае разногласия передать на экспертную оценку. Или можем собрать консилиум из нескольких разметчиков, и выяснисть, кто прав. Или если меняются инструкции разметки, и определяются более чёткие границы для минимизации расхождения в пограничных случаях.
➡️ Версионирование инструкций
Поступаем аналогично, как если мы версионируем код в гите. Новые/ правленные инструкции ревьюим. Обязательно указываем, какая версия применялась при разметке конкретной партии данных. Если в процессе возникали спорные кейсы — добавляем их в инструкцию с пометкой «обновлено».
➡️ Контроль и метрики
Управлять можно только тем, что измеряется. Метрики помогают выявить слабые места и улучшить процесс:
- Согласие между аннотаторами (Inter-Annotator Agreement)
- Процент правок после валидации
- Скорость + качество: лучше жертвовать скоростью ради стабильности
- Количество уточнений по инструкции: если их много, нужно менять инструкцию
➡️Автоматизация процесса
- Предразметка моделью: человек проверяет вместо разметки с нуля
- Автопроверки на лету: например, логические правила: «если выбрано А, поле B не может быть пустым»
- Интеграция с тулзами: Label Studio, Prodigy, doccano позволяют встроить автоматическую проверку и экспорт / импорт в пайплайн
- Контроль качества через скрипты: сравнение с эталонными разметками, метрики качества, алерты на резкое падение согласия.
BY ML Advertising
Share with your friend now:
tgoop.com/dsinsights/340