Несогласие разметчиков: как наладить рубрики и арбитраж

Почему разметчики расходятся в оценках

Даже хороший разметчик читает текст не как машина. Он опирается на опыт, привычки и на то, как понял задачу. Поэтому один и тот же пример люди часто трактуют по-разному.

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

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

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

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

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

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

Где чаще всего начинаются споры

Споры редко начинаются из-за невнимательности. Обычно текст можно честно прочитать двумя способами, и оба кажутся разумными.

Первый частый источник - пограничные случаи между двумя метками. Жалоба легко похожа на просьбу о помощи, а нейтральный вопрос - на скрытое недовольство. Если правило не объясняет, где проходит граница, люди опираются на свой опыт, а не на общий стандарт.

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

Часто споры вызывает текст, где смысл не сказан прямо. Сарказм, намеки, сухие формулировки и слабый контекст ломают простые правила. Фраза "Ну да, сервис просто отличный" может выглядеть как похвала только на бумаге. В живой переписке это нередко раздражение.

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

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

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

Как собрать понятную рубрику

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

Начните с коротких определений. У каждой метки должна быть одна простая мысль: что к ней относится, а что нет. Лучше написать: "Жалоба - пользователь явно недоволен и просит исправить проблему", чем давать общее описание на полстраницы.

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

Примеры и антипримеры снимают много споров. Если у вас есть метки "запрос на информацию" и "жалоба", покажите пограничный случай. Фраза "Где мой заказ?" может быть обычным вопросом, а "Где мой заказ, я жду уже неделю" уже ближе к жалобе. Людям проще сверяться с образцом, чем гадать по абстрактному описанию.

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

Похожие метки требуют явного порядка выбора. Если текст подходит сразу под две категории, рубрика должна отвечать на вопрос: "Что ставим сначала?" Удобно записывать это как короткое правило. Например: если клиент прямо просит вернуть деньги, ставим "возврат", даже если в сообщении есть жалоба на сервис.

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

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

Как вести арбитраж по шагам

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

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

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

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

После этого сверяйте пример с рубрикой. Не спрашивайте, "как мы обычно ставим". Смотрите, какой пункт правил подходит лучше и где проходит граница между метками.

Сразу фиксируйте итог. Запишите не только метку, но и причину решения. Через несколько дней команда забудет детали, а короткая запись снимет тот же спор в следующем раунде.

Если спор повторяется, меняйте правила сразу. Иногда хватает одной фразы, пары уточнений или нового примера, чтобы спор исчез.

Небольшой пример. Один разметчик помечает ответ службы поддержки как "полезный", потому что в нем есть инструкция. Второй ставит "неполный", потому что ответ не доводит клиента до решения. Арбитр не выбирает того, кто звучит увереннее. Он открывает рубрики для разметки и проверяет, что именно считать решением: наличие шага или закрытый вопрос клиента.

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

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

Когда пора пересматривать правила

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

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

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

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

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

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

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

Простой пример из службы поддержки

Команда размечает обращения клиентов тремя метками: "жалоба", "вопрос по оплате" и "отмена". На простых сообщениях споров почти нет. "Где мой счет за март?" идет в оплату. "Хочу удалить аккаунт" идет в отмену.

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

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

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

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

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

Как понять, что правила стали яснее

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

Удобно замерять три вещи: долю полных совпадений, долю случаев, которые ушли на арбитраж, и время на один объект. Бывает, что совпадений стало больше с 62% до 79%, а спорных карточек стало почти вдвое меньше. Это хороший знак: люди не угадывают логику, а понимают ее одинаково.

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

Проверяйте изменения на свежей выборке. Не берите те же примеры, по которым команда уже спорила раньше. Иначе разметчики просто запомнят решение арбитра. Лучше собрать новый набор из 100-200 объектов с обычными и пограничными случаями.

Отдельно смотрите на массовые и редкие случаи. Частые категории почти всегда выглядят лучше, потому что к ним быстро привыкают. Редкие метки показывают реальную ясность правил. Если по популярным меткам совпадение 90%, а по редким 45%, процесс еще не выровнялся.

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

Если три раунда подряд спор крутится вокруг одних и тех же примеров, проблема почти всегда в правилах, а не в людях. Хорошие рубрики для разметки снимают спор еще до разбора с арбитром.

Ошибки, которые быстро ломают процесс

Самая частая поломка начинается тихо: команда вводит новую метку, но не добавляет к ней примеры. Название кажется понятным, а на деле каждый читает его по-своему. Через несколько дней один разметчик ставит метку только в явных случаях, другой цепляет к ней все похожие обращения, и качество разметки данных проседает без видимой причины.

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

Арбитраж аннотаций быстро теряет смысл, если арбитр решает спор по воспоминаниям. Фраза "мы раньше так делали" не помогает, если текущая рубрика говорит другое или вообще молчит. Разметчики должны видеть, что решение опирается на текст правила, пример и дату правки. Иначе арбитраж превращается в угадайку.

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

Помогают простые ограничения. Новую метку добавляют только вместе с примерами и антипримерами. Каждую правку записывают с датой и номером версии. Арбитр цитирует правило, по которому принял решение. Команда обновляет обучение в тот же день, когда меняет рубрику.

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

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

Короткая проверка перед новым раундом

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

Минимальная проверка простая. У каждой метки должно быть короткое описание без общих слов. Для повторяющихся спорных случаев нужна отдельная пометка в рубрике. Арбитр должен понимать границу своих решений и момент эскалации. Вся команда должна работать по одной текущей версии правил. И заранее нужно решить, как считать спорные ответы.

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

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

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

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

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

Что сделать после первой правки правил

Сразу после первой правки правил не ждите чуда. Несогласие разметчиков обычно падает не в тот же день, а после короткой проверки на новых данных. Лучше взять 30-50 свежих примеров, которые команда еще не видела, и прогнать их по обновленной рубрике без подсказок от тимлида.

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

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

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

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

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

Для таких проверок многим командам удобен один общий шлюз к моделям. Например, AI Router на airouter.kz дает один OpenAI-совместимый endpoint для работы с разными моделями, а также аудит-логи и маскирование PII. Это удобно после правки правил: можно быстрее проверить один и тот же набор кейсов на нескольких моделях и понять, где ломается рубрика, а где сама модель.