Почему NER модель ошибается на реальных данных
На демо NER модель уверенно находит компании и персон — кажется, задача решена. На реальном потоке из писем, чатов, сканов и выгрузок учётных систем распознавание сущностей проседает, причём незаметно: сравнить результат не с чем, а глазами ошибки в тысяче строк не отловить.
Первая причина — размытая схема меток. Когда «организация», «подразделение» и «продукт» свалены в один класс, а вложенные сущности описаны одной меткой, модель видит противоречивые примеры и угадывает компромисс: границы сущностей плывут. Схему пересобирают до старта обучения — плоские метки, явные правила вложенности, отдельный класс под каждую сущность, которая реально нужна в отчётности.
Вторая — качество разметки текста. Если два аннотатора по-разному ставят границы, а спорные случаи решаются «на ощущение», модель учится на шуме. Разметка в Label Studio с двойным проходом и разбором расхождений даёт измеримый процент совпадения — корпус ниже порога в обучение не уходит.
Третья — редкие классы сущностей. При перекосе корпуса редкая метка не набирает примеров, и ошибается модель чаще всего именно на ней. Отдельно бьёт смена форматов: новый источник приносит другой регистр, шум распознавания сканов, таблицы — распределение входных текстов уезжает от обучающего.
И главное — отсутствие контроля на отложенной выборке. Метрики на обучающем наборе ничего не говорят о поведении на свежих данных. Контроль на отложенной выборке из новых поступлений, не пересекающейся с обучением, даёт честную оценку и позволяет сравнивать версии между собой — без него любое «улучшение» непроверяемо.
Разбираем, как это закрывается: от схемы меток и инструкции для аннотаторов до регламента повторных проверок на новых данных.
Что даёт извлечение сущностей: измеримые эффекты
Извлечение сущностей окупается не абстрактной автоматизацией, а тремя конкретными сдвигами в процессе обработки документов.
Доля ручной проверки
Модель размечает сущности по типам — организации, персоны, даты, суммы, реквизиты, номера договоров. Оператор просматривает только поля, где уверенность модели ниже порога, выставленного под ваш процесс, а не читает документ целиком. Доля ручной проверки падает с полного прочтения до выборочного.
Порог настраиваем по матрице ошибок: там, где ложное срабатывание дороже пропуска, он выше. Так внимание проверяющих уходит на спорные случаи, а не размазывается равномерно по потоку.
Время обработки документа
Документ принимается, размечается и уходит в учётную систему без ручного переноса полей. Первый прогон по архиву идёт пакетно, дальше — инкрементально, по мере поступления файлов, поэтому очередь не копится.
Для сканов и таблиц добавляется приведение к тексту, и это время считаем отдельно — честнее, чем обещать единый срок на все типы входных данных.
Класс отказов, который перестаёт возникать
Ручной перенос полей даёт перепутанные реквизиты, потерянные номера, даты в неверном формате. Это не опечатки, а расхождения между документами и учётом, которые всплывают на сверке.
После внедрения они уходят системно: правило разбора одно для всех файлов, а каждое значение хранит ссылку на фрагмент исходного текста. Расхождение видно сразу, а не через месяц.
Подходы к разметке и обучению: сравнение режимов
Режим обучения выбирают не по вкусу, а по состоянию данных: есть ли готовый корпус, сколько типов сущностей нужно различать и насколько они редкие. Первый шаг — зафиксировать целевую метрику на отложенной выборке, иначе сравнивать варианты будет нечем.
Разметку собственными силами имеет смысл заводить, когда предметная область закрытая и экспертиза живёт внутри команды. Главный риск здесь — согласованность: на редких сущностях разметчики расходятся, и модель учится на противоречивых примерах. Дообучение готовой системы даёт первый рабочий результат быстрее всего, но перенимает чужую схему классов и её потолок качества.
Четыре режима и их пределы
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Разметка своими силами | Узкая область, эксперты в штате, объёмы небольшие | Расхождения между разметчиками, сроки растягиваются, инструкцию сложно удерживать стабильной |
| Разметка силами подрядчика | Нужен объём в сжатые сроки, схема сущностей уже описана | Требует приёмки на контрольной выборке и постоянного контроля качества |
| Дообучение готовой системы | Данных мало, схема сущностей близка к типовой | Чужая схема классов, редкие сущности различаются хуже, потолок метрики ниже |
| Обучение с нуля | Своя схема сущностей, область далека от общих корпусов, данные накапливаются | Нужен объём размеченных примеров, дольше до первого результата |
На практике режимы комбинируют: стартуют с дообучения, чтобы закрыть задачу, и параллельно накапливают собственную разметку для обучения с нуля. Разбираем, какая схема окупается в вашем случае.
Этапы обучения NER модели: от аудита данных до сдачи
Аудиторию технической части обычно интересует не «обучили модель», а по каким контрольным точкам видно, что она выдержит рабочие тексты. Поэтому этапы обучения модели мы привязываем к измеримым артефактам: корпус, схема сущностей, согласованность разметки, метрики на отложенной выборке.
Как идёт работа
- Аудит корпуса текстов. Смотрим реальные документы, считаем долю шума, дублей и языковых вкраплений. На выходе — ответ, хватает ли данных и что придётся доразмечать.
- Схема сущностей. Фиксируем список типов, правила границ и вложенности, поведение на пересечениях. Согласуем с вами до разметки: менять схему на середине дороже всего.
- Разметка и контроль согласованности. Несколько аннотаторов размечают перекрывающийся фрагмент, расхождения разбираются на спорных примерах. Порог совпадения задаём заранее.
- Обучение и настройка порогов. Модель учится на размеченной части, отдельно калибруется уверенность срабатываний, чтобы в результат не попадал шум.
- Проверка на отложенной выборке. Считаем полноту и точность по каждому типу сущности, а не одной усреднённой цифрой. Ошибки разбираем по классам и возвращаем в разметку.
- Интеграция. Отдаём модель отдельным сервисом с понятным интерфейсом, подключаем к вашему поиску или обработке документов, следим за временем ответа.
- Передача. Схема сущностей, инструкция для разметчиков, скрипты переобучения и порядок доразметки новых примеров — у вас на руках.
Что передаём на руки: артефакты и регламенты
Модель устаревает быстрее, чем меняется предметная область: появляются новые типы сущностей, меняется формат входных данных, накапливаются исправления разметчиков. Поэтому вместе с обученной системой передаём всё, что нужно для её самостоятельного сопровождения — чтобы дообучение и приёмка не зависели от нашей доступности.
- Обученная система — веса модели, сервис выдачи предсказаний, конфигурация порогов срабатывания и окружение с зафиксированными зависимостями.
- Схема сущностей — перечень типов с правилами границ, вложенности и приоритетов при пересечении.
- Инструкция по разметке — свод правил для аннотаторов с разбором спорных случаев и примерами «так верно / так нет».
- Набор проверочных примеров — отложенная выборка с эталонной разметкой для приёмочного прогона и контроля после дообучения.
- Регламент пополнения и переобучения — периодичность, критерии запуска и доля исправлений, после которой обучение обязательно.
- Скрипты оценки — расчёт точности и полноты по каждому типу сущностей с разбором ошибок по классам.
- Документация по развёртыванию — состав компонентов, параметры окружения, порядок обновления и откат на предыдущую версию.
На приёмке вы прогоняете контрольные примеры сами и сверяете результат с эталоном. Передача закрыта, когда метрики совпали и ваша команда повторила прогон без нашей помощи.
Кейс: разбор входящих обращений с извлечением данных
Сервисная компания принимала обращения по почте, через форму на сайте и в мессенджерах — поток около 4 000 в месяц. Данные для заявки (номер договора, адрес объекта, тип услуги, желаемая дата) операторы вытаскивали из текста руками: копировали, сверяли с базой, переносили в учётную систему.
До внедрения
На ручной разбор уходило 6 из 10 обращений — все, где не было готовой формы с полями. В среднем на одно письмо тратилось 8 минут, в пиковые недели очередь доходила до 2–3 часов, а часть заявок терялась в переписке. Рост потока закрывали новыми операторами, и качество при этом проседало: одно и то же поле разные сотрудники трактовали по-разному, из-за чего upstream-системы получали расхождения в справочниках.
Что изменили и что получилось
Собрали корпус из 12 000 реальных обращений и разметили сущности в Label Studio: пять типов полей плюс отдельный класс для противоречивых упоминаний. На этой разметке обучили NER-модель и обернули её в сервис извлечения — текст приходит из очереди, модель возвращает поля вместе со степенью уверенности, а порог отсечения настроен так, что при низкой уверенности обращение уходит оператору с подсветкой спорных мест.
После внедрения доля ручного разбора упала с 62% до 17%, среднее время обработки — с 8 минут до 40 секунд. Точность извлечения ключевых полей держится на 0,93 по F1, а оставшиеся 17% — это в основном составные обращения с вложенными таблицами и сканами. Новые типы полей добавляли переразметкой нескольких тысяч примеров, без переписывания логики приёма заявок.
Чем дообучение отличается от обучения с нуля?
Дообучение — это обновление весов готовой модели, уже натренированной на больших корпусах языка: мы снимаем выходной слой под ваш набор классов сущностей и доучиваем его на вашей разметке. Размечать нужно только то, чего нет в открытых данных, — внутренние номенклатуры, редкие формулировки, отраслевую лексику. Для модели распознавания сущностей обычно это несколько тысяч коротких фрагментов в BIO-разметке, и первая рабочая версия появляется за недели.
Обучение с нуля требуется, когда домен далёк от обычного языка, своих классов много, а готовых решений под них нет. Тогда добавляется подготовка на неразмеченном корпусе, сбор словарей и разметка с нуля по инструкции: объём размеченных данных вырастает на порядок, а сроки проекта измеряются кварталами. Открытые библиотеки вроде spaCy дают точку старта, но не заменяют вашу разметку и проверку качества по каждой сущности отдельно.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Дообучение готовой модели | Типовые сущности, есть сотни-тысячи размеченных примеров | Нужна проверка на расхождение с прежним корпусом |
| Дообучение плюс правила и словари | Точность на справочниках, артикулах, идентификаторах | Правила приходится сопровождать вручную |
| Обучение с нуля | Уникальный домен и собственные классы | Полный цикл разметки, долго до первой метрики |
Что это значит для сроков: дообучение — короткий цикл разметки и две-три итерации обучения, обучение с нуля — отдельный проект с подготовкой данных. И в том, и в другом случае мы сначала смотрим ваш корпус и оцениваем, сколько примеров действительно нужно, а не называем объём вслепую.
Технические сомнения перед стартом проекта
Перед стартом проекта почти всегда всплывают одни и те же вопросы: хватит ли данных, что делать без готовой разметки, как измерять качество и кто отвечает за результат. Ниже — короткие ответы на них, чтобы снять сомнения до оценки.
У нас мало данных — этого хватит для NER-модели?
Объём считается не в строках, а в числе упоминаний сущностей: для набора из 5–10 типов обычно достаточно нескольких тысяч размеченных упоминаний на класс. Если материала меньше, подключаем дообучение на открытых корпусах, аугментацию и активное обучение — модель сама указывает примеры, которые дадут максимум прироста. Достаточность проверяем по кривой обучения на пробной выборке ещё до старта.
Разметки нет совсем — это блокер?
Нет, но начинаем не с модели, а со схемы сущностей: описываем типы, границы и спорные случаи в инструкции для разметчиков. Затем размечаем пробную выборку и замеряем согласие между людьми — если оно низкое, правим инструкцию, а не нейросеть. Основной корпус размечаем итерациями, параллельно обучая и проверяя модель.
Как поймём, что качество достаточное?
Метрики precision, recall и F1 считаем по каждому типу сущности отдельно: общая оценка маскирует провал на редком классе, который в документе встречается чаще всего. Целевые значения фиксируем письменно до обучения и проверяем на отложенной выборке, которую модель не видела. Дополнительно прогоняем случайные примеры из вашего живого потока.
Кто отвечает за результат?
Ответственность делится прозрачно: мы — за разметку, обучение, замеры и воспроизводимость результата, заказчик — за доступ к данным и экспертизу в предметной области. Если целевые метрики на имеющихся данных недостижимы, говорим об этом до начала основного этапа, а не после сдачи. Условия приёмки и способ перепроверки качества описываем заранее.
Обсудим задачу и вернёмся с оценкой
Чтобы вернуться с оценкой и планом работ, а не с общими сроками, нам нужен контекст задачи. NER-модель обучается на ваших текстах и вашей схеме сущностей, поэтому вводные данные для оценки — это прежде всего корпус и точный перечень того, что модель должна извлекать.
Что прислать для старта разбора:
- 300–500 типичных документов или записей в исходном виде, включая неудобные случаи: сканы, таблицы, короткие сообщения;
- перечень типов сущностей с примерами значений и границами — где заканчивается организация и начинается подразделение;
- 20–30 спорных примеров, на которых ручной разбор или поиск по правилам ошибается;
- описание текущего процесса: кто и как извлекает сущности сейчас и сколько времени это занимает;
- требования к качеству: какие типы сущностей критичны, что допустимо пропустить, а что нет;
- ограничения по среде: закрытый контур без внешних запросов или облако, какие языки и кодировки встречаются;
- формат выдачи: JSON, таблица, выгрузка в вашу учётную систему.
Порядок старта такой: мы смотрим данные, фиксируем схему разметки и правила для спорных случаев, оцениваем объём корпуса под обучение. Возвращаемся с планом по этапам — сбор и разметка, обучение и подбор порога уверенности, замер точности и полноты на отложенной выборке, внедрение и мониторинг после запуска. План опирается на ваш реальный корпус, поэтому сроки и метрики приёмки в нём проверяемые.
Опишите задачу — вернёмся с оценкой и планом работ.
