Чому розмітка даних у Prodigy впирається в ручну працю
Розмітка даних у Prodigy побудована навколо одного прикладу: інтерфейс показує текст, підказку моделі й чекає на мітку. Інструмент акуратно фіксує відповідь, але не вирішує, які приклади взагалі варто показувати — порядок задає людина або випадкова вибірка.
Звідси перше вузьке місце розмітки: значна частина видачі — очевидні випадки, де мітка збігається з передбаченням моделі й навчанню нічого не дає. Аннотатор витрачає на них основний час, а спірні приклади отримують рівно одну мітку й ідуть у датасет без перевірки.
Другий збій — розбіжність міток між аннотаторами. Працюючи наосліп, кожен спирається на власне прочитання інструкції, тому на граничних прикладах з'являються протилежні відповіді. Узгодженість розмітки падає, а перевірити її нічим: немає ні другого проходу, ні розбору конфліктів.
У підсумку якість навчальної вибірки визначається не задачею, а тим, хто і в якому порядку розмічав. Модель доучується на спірних прикладах і завчає шум — якість на відкладеній вибірці стоїть на місці, а обсяг ручної розмітки датасету зростає разом із вимогами до точності.
Розбираємо, як це закривається: пріоритизація прикладів, контроль узгодженості та повторна розмітка граничних випадків.
Що дає навчання моделі на спірних прикладах
Активне навчання перевертає порядок розмітки: аннотатор більше не йде корпусом підряд, а отримує лише ті записи, де модель сумнівається. Черга формується за невпевненістю — за різницею ймовірностей між двома провідними класами та за ентропією розподілу.
Приклади з найменшим відривом ідуть до людини першими, впевнені передбачення чекають на вибірковий контроль.
У Prodigy цикл замкнено: мітка одразу потрапляє в навчальну вибірку, модель доучується й перераховує чергу наступної порції. Проєкт не чекає, поки розмітять увесь корпус — якість зростає на кожній сотні прикладів, і вже з перших проходів видно, яких класів бракує.
Ефект вимірний. Частка записів, які справді потребують ручної звірки, падає в 3–5 разів проти суцільної розмітки: 80–90 % корпусу — однозначні приклади, і вони йдуть у напівавтоматичну розмітку.
Точність на спірних зрізах при цьому вища, ніж за рівномірної вибірки: кожен спірний запис приносить моделі максимум нової інформації.
Відбір спірних прикладів розкриває й дефекти самої схеми: суперечливі мітки в схожих записів, перехресні класи, рідкісні категорії без жодного впевненого прикладу.
Ми розбираємо такі випадки до релізу — переносимо їх в інструкцію для аннотаторів і в перевірки на валідації, а не знаходимо в робочій експлуатації за скаргами користувачів.
Режими розмітки: ручний, напівавтоматичний, гібридний
Режим розмітки обирають за характером даних і ціною помилки, а не за зручністю виконавця.
Одна схема дає еталон на малому обсязі, друга розганяє пропускну здатність на однорідних класах, третя поєднує передрозмітку моделі з правкою людиною — і в кожної є умови, за яких вона починає працювати проти проєкту.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Ручна розмітка під контролем | Мала вибірка, висока ціна помилки, старт проєкту й калібрування інструкції | Час зростає лінійно до обсягу; наприкінці зміни трактування між розмітниками розходяться |
| Напівавтоматична (активне навчання) | Однорідні класи, тисячі прикладів, є стартова вибірка для ініціалізації моделі | Потрібен перезапуск циклу при дрейфі класів і перегляд міток при зміні схеми |
| Гібридна | Великі слабко розмічені потоки, кілька виконавців, розмітка в потоці продукту | Доводиться розділяти помилку моделі й помилку людини; дорожча в налаштуванні правил відбору |
Гібридний режим зазвичай беруть на довгих проєктах: модель пропонує варіант, людина підтверджує або відхиляє його, а спірні приклади йдуть в окрему чергу на перевірку.
Обсяг чистої ручної роботи падає, але без метрики згоди між розмітниками шум у навчальній вибірці залишається непоміченим — і проявляється вже на якості моделі.
Орієнтир при виборі — частка неоднозначних прикладів: якщо вона вища за третину, напівавтоматичний режим починає підказувати людині її ж помилки, і цикл замикається сам на себе.
Prodigy дозволяє вести всі три режими в одному інтерфейсі й перемикатися в міру зростання вибірки, не втрачаючи вже розмічені дані.
Як ми вибудовуємо цикл аннотування під задачу
Впровадження розмітки починаємо не із запуску інструмента, а з аудиту схеми міток: дивимося поточний корпус, знаходимо перехресні та «мертві» класи, оцінюємо, скільки прикладів на клас реально є.
Схема, де 40 міток і по три приклади на кожну, не дасть навчуваної моделі ні за активного навчання, ні за ручної вибірки — тому частину класів об'єднуємо, частину переводимо в атрибути.
Далі збираємо контур аннотування і лише потім садимо людей за розмітку, інакше переробляти доведеться вже готовий набір.
- Аудит схеми міток і корпусу. Перевіряємо узгодженість поточної розмітки, рахуємо частку спірних прикладів і класовий дисбаланс. На виході — скорочена схема з інструкцією щодо пограничних випадків.
- Проєктування контуру аннотування. Визначаємо інтерфейс під тип задачі — класифікація, сутності, зв'язки, — ролі розмітників, частку прикладів на взаємну перевірку та порядок зняття конфліктів.
- Налаштування активного навчання. Підключаємо модель-кандидат на актуальній гілці Prodigy: вона відбирає в чергу приклади з низькою впевненістю та спірні випадки, а не випадкову вибірку.
- Пілот на контрольній партії. Розмічаємо невеликий обсяг, заміряємо узгодженість між аннотаторами й правимо інструкцію до того, як розмітка піде в промисловий обсяг.
- Навчання й замір якості. Готуємо модель spaCy, звіряємо метрики на відкладеній вибірці й дивимося, які класи помилок зростають при додаванні нових даних.
- Регламент аннотування. Фіксуємо схему міток, критерії якості, порядок ескалації спірних випадків і правила версіонування наборів даних.
- Передача та супровід. Показуємо команді замовника чергу, метрики й точки доучування; окремо проговорюємо, як змінювати схему міток без втрати вже розміченого корпусу.
Контур залишається в замовника — з чергою, дашбордом якості та зрозумілим регламентом, щоб розмітка не перетворювалася на разовий проєкт.
Поставка: конфігурація, схема міток, регламент перевірки
Налаштований проєкт у Prodigy передаємо як робочий комплект, а не як архів файлів: команда замовника має запускати розмітку й доучування моделі без нас. Нижче — що саме залишається в репозиторії та в документації з розмітки.
- Конфігурація проєкту: інтерфейс розмітки під задачу, пороги відбору прикладів для активного навчання, зв'язка з моделлю spaCy та параметри її доучування.
- Схема міток: повний перелік класів, правила їх взаємовиключення та пріоритети, приклади на кожен клас і окремо — граничні випадки, де розмітники найчастіше розходяться.
- Інструкція для розмітників: довжина виділюваних фрагментів, дії зі спірними та вкладеними сутностями, порядок ескалації питань.
- Регламент перевірки розмітки: частка задач на повторну розмітку, розбір розбіжностей, поріг згоди та відповідальний за фінальне рішення.
- Критерії якості розмітки: метрики узгодженості між розмітниками, частка відбракованих задач, умова повернення моделі на нову ітерацію навчання.
- Еталонний набір прикладів: фіксована вибірка, на якій проганяємо кожну нову версію моделі й порівнюємо з попередньою.
- Схема руху даних: як розмічені приклади потрапляють у навчання, як версіонується набір даних і як відкотитися до попередньої версії.
Передаємо все з навчанням команди та стислими записами щодо кожного артефакту — щоб правки в схему міток вносилися усвідомлено. Обговоримо задачу — повернемося з планом поставки під ваш процес.
Кейс: класифікація звернень і зростання узгодженості міток
Що було до
Розмітку вели в таблицях: кілька аннотаторів проставляли категорії звернення в спільний аркуш, а спірні випадки розбирали ручною звіркою раз на тиждень.
Правила класів жили в листуванні й у кожного в голові, тому той самий запит «не проходить оплата» потрапляв то в «оплату», то в «збій інтеграції».
Узгодженість аннотаторів трималася близько 0.6 за часткою збіглих міток — модель навчалася на суперечливих прикладах і розвалювалася саме на пограничних класах.
Що змінили і що вийшло
Зібрали єдиний контур аннотування на Prodigy: таксономія з 14 класів, введення гарячими клавішами, обов'язковий коментар на спірну мітку.
Увімкнули Active Learning — модель відбирає на розмітку приклади з низькою впевненістю, а не випадкові, тому час аннотатора йде в пограничні випадки. Категорії, де люди частіше розходилися, розмічають двоє, розбіжності автоматично падають у чергу на розбір.
Метрики якості розмітки стали частиною процесу, а не звітом постфактум: узгодженість аннотаторів зросла до 0.9, частка спірних кейсів скоротилася приблизно втричі, а час на одне звернення впав у рази завдяки передрозмітці моделлю.
Класифікація звернень на утримуваній вибірці зросла помітно, при цьому ручні звірки пішли з регулярного циклу — перенавчання стало рідшим, а помилки на пограничних класах розбираються там, де вони з'являються.
Що робити, якщо модель уже навчена на шумних мітках?
Модель, навчена на шумних мітках, майже завжди переоцінює себе на валідації: вона вивчає не ознаку класу, а помилки конкретного розмітника.
Якщо шум розмазаний по вибірці, відкладена частина містить ті самі помилки, і метрика виглядає прийнятною, поки дані не починають надходити з реального потоку.
Тому перший крок — не перенавчання, а діагностика: рахуємо впевненість моделі на навчальному наборі й шукаємо, де вона розходиться з проставленою міткою.
Розбіжність поділяється на дві принципово різні сутності. Там, де модель упевнена в одному класі, а мітка стоїть на протилежному, це з високою ймовірністю шумна мітка — її виносимо на перевірку людиною.
Там, де впевненість тримається близько порога, йдеться радше про пограничні класи: приклад об'єктивно лежить на стику двох категорій, і винна не якість роботи розмітника, а нечітке правило. Такі приклади не видаляємо — узгоджуємо інструкцію й фіксуємо рішення в схемі.
Черга на перевірку будується не випадково: у робочому контурі на Prodigy ми пріоритизуємо саме розбіжності моделі й мітки, від найупевненіших до спірних.
Кожна правка зберігає початкове значення, вердикт рев'юера та причину — уже зібрані дані залишаються в базі аннотацій, нічого не перезаписується наосліп.
Далі йде очищення розмітки шарами: спірні рядки йдуть у карантин, навчальним стає узгоджений шар, а версії правил фіксуються, щоб доучування було відтворюваним.
У результаті метрика на відкладеній вибірці перестає бути завищеною, пограничні класи отримують окремі правила замість усередненого шуму.
Обмеження рішення та часті технічні сумніви
Контур розмітки в Prodigy впирається в межі інструмента, а не в його налаштування: активне навчання прискорює лише ті класи, які модель уже частково знає. Нижче — обмеження, які ми фіксуємо на старті, та інженерні способи їх обійти.
Як кілька аннотаторів працюють одночасно і не дублюють одне одного?
Завдання йдуть із спільної черги, кожен приклад закріплюється за одним виконавцем — паралельна робота без накладок, відповіді не губляться при обриві зв'язку. Частину вибірки розмічаємо перехресно: узгодженість рахуємо за часткою збігів і правимо інструкцію, а не окремі помилки.
Що робити, якщо рідкісний клас не набирає прикладів?
Модель-підказка відбирає лише те, що вже вміє, тому для рідкісних класів її вимикаємо й шукаємо кандидатів регулярками, словниками або близькістю векторів. Поріг впевненості знижуємо, зайві спрацювання йдуть на перевірку.
Чи можна перенести розмітку, зроблену раніше в інших інструментах?
Так: конвертуємо звичні формати — таблиці, JSON, розмітку сутностей у тексті — у потрібну схему, зберігаючи зсуви символів, інакше межі сутностей поїдуть. Розбіжності в правилах (вкладені сутності, різні трактування меж) розбираємо окремо.
Коли доучувати модель і як помітити, що стало гірше?
Цикл: партія розмітки, доучування, прогін по замороженій контрольній партії, відбір помилок у наступну партію. Набір у пару сотень прикладів із подвійною розміткою дає точність і повноту за класами — регресії видно до викату.
Обговоримо задачу: що надіслати і як піде робота
Щоб повернутися з оцінкою проєкту розмітки, а не зі здогадками, нам потрібен від вас мінімум контексту. Розмітка майже завжди займає більше часу, ніж навчання моделі, тому схему міток і вимоги до якості узгоджуємо до того, як перший розмітник відкриє перший запис.
- Приклад даних «як є» — кілька сотень реальних записів із шумом, одруками та неповними полями: на них перевіряємо, що схема міток витримує ваш домен, а не лише чисті приклади.
- Чернетка того, що модель має розрізняти: список сутностей або класів і по 10–15 випадків «так правильно / так неправильно». Спірні випадки тут цінніші за однозначні.
- Джерело й обсяг: звідки забираємо масив, у якому вигляді він лежить зараз, скільки записів планується розмітити і з якою періодичністю надходять нові.
- Обмеження щодо даних: персональні відомості, що не можна вивантажувати за периметр, вимоги до зберігання та видалення копій.
- Критерій приймання: яка частка збігів з еталоном вважається достатньою і на якому сценарії це перевіряється.
- Поточний процес, якщо він є: хто розмічає, у яких файлах ведеться облік, скільки часу йде на один запис.
- Словник домену й мова даних: терміни, скорочення, змішування мов — їх доведеться зафіксувати в інструкції розмітника.
Далі робота йде так: ми проводимо аудит надісланого масиву, повертаємося з оцінкою проєкту розмітки та планом впровадження розмітки — схема міток, обсяг, порядок ітерацій, точки контролю якості.
Перед масштабуванням запускаємо пілот на кількох сотнях прикладів і рахуємо узгодженість розмітників: якщо інструкція допускає різночитання, це видно до того, як розмічено весь масив.
Розмічаємо в Prodigy, де активне навчання підтягує в чергу найспірніші приклади, тому частка ручної роботи падає в ході проєкту. Опишіть задачу розмітки — повернемося з оцінкою та планом.
