Разметка данных (data labeling)

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

Простыми словами

Если у вас есть письма клиентов, изображения, аудио или документы, модель сама не знает, что именно считать «спамом», «дефектом», «договором» или «именем компании». Разметка данных дает ей правильные примеры. По сути, это ответ на вопрос: что в этих данных нужно предсказывать и как выглядит правильный ответ.

Метка может быть очень простой, например класс spam или not_spam. А может быть сложной:

• рамка вокруг объекта на изображении;
• маска пикселей для сегментации;
• выделение сущностей в тексте;
• оценка тональности;
• пара предпочтений «ответ A лучше ответа B» для настройки генеративной модели.

На практике под «разметкой» часто понимают не только проставление меток, но и весь контур: проектирование схемы классов, написание инструкций, обучение разметчиков, контроль качества и переразметку спорных случаев.

Как это работает

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

1. Определяют целевую задачу. Например, классифицировать обращения клиентов, находить дефекты на фото или извлекать реквизиты из документов.
2. Проектируют схему меток. Классы должны быть полезны бизнес-процессу и различимы по данным. Если два класса нельзя надежно отделить, схема еще не готова.
3. Пишут инструкцию. В ней фиксируют определения классов, правила приоритета, примеры и антипримеры, а также порядок работы со спорными случаями.
4. Готовят пилотный набор. Небольшую выборку размечают несколько человек, чтобы найти неоднозначности и поправить инструкцию до массовой разметки.
5. Запускают основную разметку. Это могут делать внутренние специалисты, внешние подрядчики, эксперты предметной области или гибридная команда.
6. Проверяют качество. Используют контрольные задания, двойную разметку части выборки, разбор расхождений и аудит сложных классов.
7. Итерируют. После первых запусков модели схема меток нередко уточняется: появляются новые классы, исключения и правила нормализации.

Шаг	Что важно проверить	Типичный риск
Формулировка задачи	Что именно предсказывает модель	Метки не соответствуют реальному процессу принятия решений
Схема меток	Классы взаимно различимы	Перекрывающиеся категории
Инструкция	Есть примеры, исключения и приоритеты	Каждый разметчик понимает правило по-своему
Контроль качества	Есть эталон и разбор расхождений	Тихое накопление шумных меток
Поддержка датасета	Схема обновляется при изменении данных	Дрейф понятий и устаревшая разметка

Важно понимать, что разметка — это не разовый этап «перед обучением», а часть жизненного цикла данных. Как только меняется продукт, источник данных или критерий качества, разметку приходится пересматривать.

Зачем нужно

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

• Обучение моделей. Классификация, детекция, извлечение сущностей, ранжирование и многие виды тонкой настройки требуют меток.
• Оценка качества. Нужен валидный тестовый набор, иначе нельзя понять, улучшилась модель или нет.
• Фиксация экспертного знания. Хорошая инструкция переводит неявные решения экспертов в воспроизводимые правила.
• Снижение операционного шума. Единая схема меток уменьшает хаос между командами аналитики, продукта и ML.
• Подготовка генеративных систем. Для LLM часто нужны пары «вопрос–ответ», ранжирование ответов, правки и предпочтения, а это тоже формы разметки.

При этом задача не в том, чтобы получить «как можно больше размеченных данных», а в том, чтобы получить данные нужного типа и нужного качества. Тысячи шумных меток часто хуже, чем меньший, но хорошо определенный набор с понятными правилами.

Пример

Практический пример: компания хочет автоматически маршрутизировать обращения клиентов в службу поддержки. Цель — присвоить каждому сообщению один из классов: billing, technical, account, other.

Текст обращения	Метка	Комментарий
«С карты списались деньги дважды»	billing	Финансовый вопрос
«Не могу войти после смены телефона»	account	Проблема с доступом и учетной записью
«Приложение вылетает при оплате»	technical	Сбой в работе продукта
«Хочу узнать о партнерской программе»	other	Не относится к основным очередям

Как это делают на практике:

1. Берут исторические обращения и удаляют дубликаты, пустые сообщения и явно некорректные записи.
2. Согласуют таксономию с операционной командой: куда реально должны попадать тикеты и какие очереди существуют в системе.
3. Пишут инструкцию. Например, если в одном сообщении есть и ошибка приложения, и вопрос о возврате денег, первичной меткой считается та, по которой тикет должен пойти первым.
4. Размечают пилотную выборку двумя независимыми разметчиками и разбирают расхождения. Обычно именно здесь выясняется, что класс other стал «свалкой» и правила нужно уточнить.
5. Формируют небольшой эталонный набор для контроля качества и только потом масштабируют процесс.
6. После обучения модели просматривают ошибки. Если модель системно путает billing и technical, проблема может быть не в модели, а в том, что в инструкциях смешаны причины обращения и маршрутизация.

Этот пример показывает ключевой принцип: разметка должна отражать рабочее решение, которое потом будет принимать система. Если метки описывают данные красиво, но не совпадают с реальным процессом, модель окажется бесполезной.

Заблуждения и ограничения

• «Разметка — это механическая работа». Нет. Самая дорогая часть часто не клики в интерфейсе, а проектирование схемы меток и снятие неоднозначностей.
• «Чем больше данных, тем лучше». Не всегда. Объем не компенсирует плохие определения классов, смещенную выборку и слабый контроль качества.
• «Можно полностью отдать разметку подрядчику». Рискованно. Без участия владельца задачи быстро накапливаются ошибки в правилах и приоритетах.
• «У каждого объекта есть единственно правильная метка». Не во всех задачах. В модерации, медицине, праве, тональности и оценке ответов часто существует допустимая зона несогласия.
• «Автоматическая предразметка всегда ускоряет процесс». Только если есть контроль. Иначе разметчики начинают подтверждать подсказку модели, а не независимо принимать решение.

Ограничения у метода тоже существенные. Разметка плохо масштабируется в задачах, где требуются редкие эксперты, например в узкой медицине, патентном анализе или сложной юридической классификации. Она неудобна там, где классы быстро меняются или сами данные нестабильны. Не лучший выбор и для ранних исследовательских этапов, когда вы еще не уверены, какие классы вообще существуют. В таких случаях иногда полезнее сначала применить кластеризацию, поиск аномалий, weak supervision, retrieval-подходы или правила, а уже потом инвестировать в дорогую ручную разметку.

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

Частые вопросы

Сколько данных нужно размечать?

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

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

Да, но только как ускоритель, а не как источник истины. Предразметка полезна, если у вас есть правила проверки, выборочный аудит и запрет на слепое подтверждение подсказок. Иначе вы просто переносите ошибки модели в датасет.

Нужна ли разметка для LLM?

Во многих сценариях да. Для instruction tuning, preference learning, оценки безопасности, извлечения структурированных полей и доменной адаптации нужны размеченные примеры, ранжирования или исправления. Но для предобучения на больших массивах текста используется и неразмеченный корпус.

Как проверять качество разметки?

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

Связанные понятия

• Аннотация данных. Близкий термин; часто используется как синоним разметки, особенно в CV и NLP.
• Обучение с учителем. Подход, в котором модель учится по парам «вход–правильный ответ».
• Активное обучение. Стратегия, при которой на разметку отправляют наиболее информативные или сомнительные примеры.
• Weak supervision. Получение приблизительных меток из правил, эвристик, внешних источников и программных функций разметки.
• Gold set. Небольшой эталонный набор с проверенными метками для контроля качества.
• Согласие разметчиков. Показатель того, насколько разные люди одинаково трактуют правила разметки.
• Таксономия и онтология. Формальная структура классов, атрибутов и связей, на которой строится схема меток.