На Хабре тысячи статей про OCR, IDP, ML и искусственный интеллект. Все они сходятся в одном: «качественная разметка данных — ключ к точности модели». Но что это значит на практике?

Меня зовут Снежана Игнатенко, я руковожу отделом разметки данных в SL Soft AI. Каждый день моя команда работает с самыми разными документами: печатными, рукописными, строгими формами, свободными текстами, сканами и фотографиями, в которых встречаются печати, подписи, штампы, затертые области, перекосы и артефакты. Наша задача — создавать качественный, точный и контекстно корректный набор размеченных данных, который служит фундаментом для всех интеллектуальных систем класса IDP.

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

Разметка — это не просто маркировка

Каждый размеченный документ, выделенный текст или отмеченное поле на изображении можно сравнить со страницей в учебнике для машины. С их помощью алгоритм начинает понимать структуру нашего мира, взаимосвязи между объектами и смысл, который мы вкладываем в информацию. Представьте, что будет, если в школьный учебник по математике вкрались опечатки, и вместо правил сложения напечатали правила вычитания. Ученик, выучив такой учебник, будет постоянно ошибаться. Точно так же происходит и с моделью машинного обучения. В среде специалистов по данным, будь то аналитики, инженеры по машинному обучению или программисты, существует золотое, проверенное годами правило. Оно известно под емкой и аббревиатурой GIGO, что расшифровывается как Garbage In — Garbage Out. В дословном переводе это означает «мусор на входе — мусор на выходе».

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

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

Сравним два примера. Необходимо было разметить ключевые поля документа типа «счет», чтобы модель могла корректно извлекать из него структурированные данные. В рамках задачи требовалось указать следующие элементы:

• поле «Номер счета» — как InvoiceNumber;

• поле «Дата выставления» — как InvoiceDate;

• поле «Сумма к оплате» — как TotalAmount;

• поле «ИНН» — как TaxID.

Плохая разметка:

Допущенные ошибки: 

1. Поле «Дата выставления» (InvoiceDate) не размечено.

2. Поле «ИНН» (TaxID) не размечено и ошибочно отмечено как InvoiceNumber.

3. В строке с итоговой суммой разметчик выделил только целую часть суммы — значение после запятой (копейки) не размечено.

В результате система:

• путает налоговые идентификаторы с номерами счетов;

• неправильно сортирует документы по дате;

• некорректно рассчитывает общие суммы.

После корректной переразметки модель стала значительно точнее определять ключевые поля, а количество ручных исправлений заметно снизилось.

Теперь посмотрим на корректную разметку:

Верная разметка:

1. Поле «Номер счета» размечено как InvoiceNumber.

2. Поле «Дата выставления» — как InvoiceDate.

3. Поле «Сумма к оплате» — как TotalAmount.

4. Поле «ИНН» — как TaxID.

Такая разметка позволяет системе четко различать реквизиты, корректно сопоставлять данные и формировать точные отчеты.

Цепная реакция проблем: как ошибки разметчиков создают головную боль для всех

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

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

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

Плохая разметка — это фактор, который:

• значительно замедляет весь процесс разработки и обучения модели, вынуждая постоянно возвращаться к предыдущим этапам,

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

• вызывает необходимость в пересборке фич или даже в полном переобучении системы с нуля, что потребует дополнительных вычислительных ресурсов и времени,

• подрывает доверие не только внешнее, но и внутреннее — к компетенциям команды разметки и к процессам контроля качества в компании в целом.

Типичные ошибки разметки

Ошибка 1 — неоднозначные инструкции

Разметчики по‑разному трактуют, что считать сущностью (например, «InvoiceNumber» vs «DocumentNumber»).

Почему вредно: модель обучается на инконсистентных примерах → низкий precision и recall на граничных случаях.

Как найти: высокий разброс в метках между разметчиками, низкий IAA.

Ошибка 2 — неполные границы (span / bbox under‑/over‑trimming)

Выделен только фрагмент (как в нашем примере — без копеек) либо захвачены соседние токены.

Почему вредно: неправильно парсятся числовые поля, слипание токенов нарушает downstream‑пост‑процессинг.

Признак: частые ложные срабатывания при парсинге чисел, расхождения с валидатором форматов.

Ошибка 3 — label bleeding / label leakage

Один тег «захватывает» соседнюю сущность (в таблицах — merged cell).

Почему вредно: модель теряет пространственную локализацию в документе; ошибки в табличной структуре.

Признак: ошибки в привязке к колонкам/строкам, частые странные ассоциации.

Ошибка 4 — class confusion (synonyms and granularity)

Разные разметчики используют разные уровни детализации (TotalAmount vs AmountDue).

Почему вредно: модель учится «размытым» классам; downstream маппинги ломаются.

Признак: низкая F1 при оценке на валидном наборе, куча пересечений между классами.

Ошибка 5 — sampling bias (dataset shift)

80% выборки — спокойные печатные счета, 20% — рукописные/сканы плохого качества.

Почему вредно: модель хорошо работает на «простых» случаях и проваливается на реальных.

Признак: разрыв производительности train↔prod, много «edge» инцидентов.

Ошибка 6 — человеческие паттерны, они же копипаст ошибок

Разметчик повторяет старые ошибки по привычке.

Почему вредно: ошибки масштабируются линейно с объемом данных.

Признак: однотипные ошибки в сотнях примеров.

Ошибка 7 — отсутствие версионности инструкций

Инструкция меняется, но старые батчи остаются без ревизии.

Почему вредно: разметка дрейфует во времени.

Признак: статистические сдвиги в частоте меток по времени.

Что такое «хорошая разметка»

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

Признаки качественной разметки:

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

2. Внимательность к деталям: разметчик работает не на скорость, а на качество, замечая нюансы и неоднозначности.

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

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

5. Регулярные и системные проверки качества (QA и ревью): процесс включает в себя многоуровневый контроль, когда работа одного специалиста проверяется другим, а выборочные проверки проводятся на постоянной основе.

В нашем подразделении выработан строгий алгоритм работы с задачами. 

Шаг 1. Разметчик получает задание с подробными инструкциями, примерами и требованиями к оформлению. Его задача — внимательно изучить материалы.

Шаг 2. Выполнение разметки при строгом следовании установленным правилам, без вольных трактовок. Если в процессе возникают сомнения или неоднозначные ситуации (например, попался документ не того типа, присутствуют нестандартные формулировки или структура), разметчик обращается к руководителю отдела, а руководитель к менеджеру/руководителю проекта для уточнения. Это помогает избежать ошибок и обеспечивает единый подход в работе команды.

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

Типы документов и как они влияют на разметку

1. Формализованные документы (УПД, товарная накладная, КС-2, КС-3 и так далее, то есть все, что имеет унифицированную форму)

Характеристики: четкая структура, стабильные поля, ожидаемый формат.

Методы:

• фиксированные теги,

• строгие правила границ полей,

• минимальные допуски.

2. Полуформализованные документы (договоры, счета, акты выполненных работ, справки)

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

Методы:

• правила по контексту,

• типовые паттерны,

• расширенный набор категорий.

3. Неформализованные документы (письма, формы свободного вида)

Методы:

• разметка не конкретных полей, а смысловых блоков,

• много контекстной логики,

• обязательный QA.

4. Документы с подписями и печатями

Задачи: выделить границы подписей, исключить пересечение с текстом, правильно классифицировать тип печати.

Сколько документов нужно для корректной работы модели

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

В таблице ниже представлены ориентировочные цифры.

________________

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