Чому 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, таблиця, вивантаження у вашу облікову систему.
Порядок старту такий: ми дивимося дані, фіксуємо схему розмітки й правила для спірних випадків, оцінюємо обсяг корпусу під навчання.
Повертаємося з планом за етапами — збір і розмітка, навчання й підбір порога впевненості, замір точності та повноти на відкладеній вибірці, впровадження й моніторинг після запуску. План спирається на ваш реальний корпус, тому строки й метрики приймання в ньому перевіряні.
Опишіть задачу — повернемося з оцінкою та планом робіт.
