Класифікація тексту: чому ручний розбір не масштабується
Потік звернень зростає швидше, ніж команда встигає його розбирати. Ручний розбір звернень впирається у пропускну здатність людей: один оператор за зміну обробляє обмежену кількість листів, і як тільки потік перевищує норму, черга обробки заявок зростає швидше, ніж її розчищають. Затримка накопичується — нерозібране чекає, до нього додаються нагадування та повторні листи.
Ціна затримки — не лише час відповіді на звернення. Поки черга коротша за зміну, пауза майже непомітна; коли вона перевалює за добу, частина звернень перетворюється на «клієнт пішов, не дочекавшись».
Паралельно пливуть мітки: розбіжності в мітках між операторами стабільно виникають на спірних категоріях, і чим вищий темп, тим більша частка таких розбіжностей — у людей немає ні часу, ні єдиного критерію, щоб вирішувати однаково.
Далі страждає аналітика: накопичені розбіжності в мітках ламають зведені звіти, і рішення приймаються за шумними даними — тема здається непопулярною, хоча попит просто розмазався по сусідніх категоріях.
Класифікація тексту закриває най дорожчу сходинку — маршрутизацію: модель відносить звернення до категорії, віддає оцінку впевненості та передає людині лише спірні випадки.
Нижче розбираємо, як це закривається на практиці: від статистичних моделей на кшталт TF-IDF до мовних, чим вони відрізняються, як вимірюється якість і як нова сходинка вбудовується в поточну чергу обробки заявок без зупинки підтримки.
Де автоматичний розбір звернень дає вимірюваний ефект
Частка автоматично розібраних звернень — базова метрика, і рахувати її потрібно за зверненнями, закритими без участі людини, а не за кількістю відповідей моделі.
На типовому потоці — заявки, питання щодо замовлення, скарги, запити документів — класифікація тексту впевнено закриває від половини до трьох чвертей, решта усвідомлено йде оператору.
Швидкість сортування потоку змінюється помітніше, ніж здається: раніше звернення чекало оператора в загальній черзі, у пікові години — до наступної зміни.
Тепер маршрутизація заявок відбувається в момент надходження: тема, терміновість, мова та адресат визначаються відразу, а очікування вимірюється хвилинами, а не змінами.
Зниження ручної обробки — наслідок того, що оператор перестає бути сортувальником і працює лише зі складними випадками. Якщо впевненість моделі нижче порогу, звернення йде людині з позначкою та причиною рішення, а не у випадковий відділ чи в загальну чергу.
Найцінніше тут — зниклий клас помилок, а не швидкість. Це заявки, які добами лежали нерозібраними, дублі від одного клієнта, звернення не тому адресату й занижений пріоритет у термінових. Такий клас закривається правилом обробки, а не пильністю конкретного співробітника.
Перевірюваність ефекту закладається до старту автоматичного розбору: беремо історичний потік, розмічаємо вибірку й дивимося, яка частка розбирається без людини і на чому модель помиляється.
Якщо потік малий або однотипний, помітної частки автоматичних рішень не буде — це теж чесний результат розбору, і його краще отримати до початку робіт.
Порівняння підходів: правила, навчання на прикладах, готові моделі
Вибір підходу визначається трьома параметрами, які зазвичай не промовляють на старті: скільки класів потрібно розрізняти, скільки розмічених прикладів є в наявності й наскільки «живі» формулювання приходять у вхідних даних.
На формальному словнику виграють правила, на стійкій тематиці — навчання на розмічених прикладах, на довгому хвості класів і потоці нових формулювань — готова мовна модель. Нижче порівняння з обмеженнями, які виявляються в експлуатації, а не в демонстраціях.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та словники | Класи описуються формальними ознаками: реквізити, маркери, шаблонні звернення | Тримаються на ручній підтримці, ламаються на нових формулюваннях, кожна зміна словника — ризик регресу |
| Навчання на розмічених прикладах (TF-IDF та лінійні моделі) | Є 1–2 тис. прикладів на клас, тематика та стиль стабільні | Точність на рідкісних класах падає, розмітку доводиться оновлювати при зміні тематики |
| Готова мовна модель | Багато класів, мало розмітки, живі формулювання та запити користувачів | Дорожче на обсязі, потрібні контроль якості та явна точка відкату до попередньої версії |
Зовнішні вимірювання на відкритих наборах задач обробки тексту, які агрегує Papers with Code, показують: при 1–2 тис. розмічених прикладів на клас розрив між класичними моделями та готовими мовними моделями майже зникає.
Він тримається у двох місцях — рідкісні класи та формулювання, яких не було у вибірці. Тому при експлуатації частіше збирають гібрид: модель на ознаках закриває часті класи як швидкий фільтр, а готова модель підключається там, де впевненість класифікатора нижче порогу.
Впровадження класифікації тексту: етапи від аудиту до передачі
Розмітка та навчання — половина роботи; друга половина — відтворюваний порядок, при якому результат переноситься на нові дані. Нижче — етапи впровадження класифікації тексту в тому вигляді, в якому ми їх проходимо: від аудиту даних до передачі моделі в експлуатацію.
- Аудит даних. Вивантажуємо корпус, рахуємо частку дублів, порожніх полів і текстів без корисного навантаження, дивимося розподіл за темами. Фіксуємо, що розмічено, а що доведеться розмічати, і скільки прикладів потрібно добрати до робочого обсягу.
- Схема класів. Збираємо таксономію без перетинів: один текст — один клас або кілька, що робити зі змішаними випадками. Спірну вибірку проганяємо через двох розмітників і знімаємо розбіжності правилами, а не усними домовленостями.
- Робоча модель і базова лінія. Йдемо від простих частотних моделей до векторних представлень і мовних моделей, нарощуючи складність лише там, де вона дає приріст на відкладеній вибірці. Поріг впевненості підбираємо під ціну помилки.
- Налаштування та інтеграція. Описуємо попередню обробку входу, відсікання сміття, версіонування моделі та розмітки, логування передбачень разом із впевненістю — без цього розбір помилок через місяць перетворюється на ворожіння.
- Перевірка якості. Рахуємо точність і повноту за кожним класом, розбираємо матрицю помилок і прикордонні приклади. Окремо дивимося поведінку на даних іншого періоду або джерела: так видно, де модель тримається на ознаках часу, а не на сенсі тексту.
- Передача в експлуатацію. Віддаємо регламент дообучення, правила відкату на попередню версію, моніторинг частки невпевнених відповідей та інструкції для команди замовника.
Комплект постачання: моделі, схеми та регламенти розмітки
Модель без оточення — це артефакт, який через місяць ніхто не зможе ні перенавчити, ні пояснити. Тому комплект постачання збираємо так, щоб задача класифікації тексту жила без нас: від ваг до правил, за якими розмітники розбирають спірні випадки.
- Навчена модель і код виклику — ваги, обгортка для інференсу, зафіксовані залежності; піднімається на вашому контурі однією командою, без збірки «за пам'яттю».
- Схема класів — таксономія з межами між схожими категоріями, прикладами на кожну та списком пар, які плутаються найчастіше.
- Регламент розмітки — інструкція для анотаторів: розв'язання конфліктів, порядок ескалації спірних випадків, вимоги до узгодженості між розмітниками.
- Політика доступу до даних — де лежать тексти, хто і на якій підставі їх читає, що маскується перед журналюванням і як влаштований слід звернень.
- Документація по моделі — метрики якості за кожним класом, а не одне усереднене число; відомі обмеження та ознаки початку деградації.
- Набір перевірочних прикладів — еталонна вибірка з мітками, на якій проганяється кожна нова версія: просідання видно до викату, а не після скарг.
- Конфігурації розгортання — описи середовищ, схеми сервісів, ліміти та черги; стенд відтворюється без читання чужого коду та питань до нас.
Усе це передаємо разом із розбором для вашої команди: де змінювати список класів, як додавати приклади і коли пора перенавчати.
Кейс: розбір вхідних звернень до і після впровадження
Вихідна картина
Звернення падали в загальну чергу, а розбір тримався на правилах за ключовими словами: вони впевнено розбирали 42% потоку і розсипалися на перефразуваннях.
Решту вручну сортували оператори — медіана до потрапляння до потрібного спеціаліста становила близько трьох годин, а частка помилкових міток сягала 28%. У пікові дні черга зростала швидше, ніж її встигали розбирати.
Що змінили
З архіву зібрали корпус звернень і зафіксували схему класів, а контрольну вибірку — тисячу звернень — відклали і в навчанні не використовували.
На ній заміряли якість на кожному кроці: спочатку базова модель на частотних ознаках, потім модель на попередньо навченому мовному представленні, поверх — правила для рідкісних і юридично значущих категорій. Розмітку звірили з операторами, щоб мітки збігалися з їхньою картиною світу.
Після впровадження автоматично розбирається 88% звернень, частка помилкових міток — 6%, час сортування скоротився до 12 хвилин. Контрольна вибірка перерозмічається щомісяця: якщо розбіжностей на ній більше 5%, запускається повторне навчання на свіжих даних.
Такий контур показує зсув у мові клієнтів або появу нової категорії до того, як це помітять за скаргами, — логіка оцінки якості розібрана в публікаціях ACL Anthology.
Чим відрізняється власна модель від готової мовної моделі?
Це вибір не «краще чи гірше», а під які дані та яку ціну помилки. Власний класифікатор навчається на вашій розмітці, готова мовна модель розв'язує задачу за інструкцією, без навчання. Різниця проявляється на ваших класах, а не на демонстраційних прикладах.
Власна модель виграє там, де класи вузькі та близькі: «скарга на строки доставки» і «претензія до якості» для загальної моделі майже одне й те саме, а для бізнесу — різні маршрути обробки.
Навчаючись на ваших прикладах, класифікатор проводить межу так, як її провели ви, і на своїх класах дає якість, вимірювану на відкладеній вибірці.
Готова мовна модель потрібна, коли розмічених прикладів немає, а рішення потрібне швидко.
Вона розбирає формулювання, які не зустрічалися в навчанні, і не потребує підготовки корпусу — але на рідкісних рубриках відповідає нестабільно, а якість доводиться перевіряти вибірково: відповідь формується заново на кожному запиті.
Доопрацювання під нові класи теж влаштоване по-різному. Власній моделі додають розмічені приклади й перенавчають — поведінка відтворювана, метрики зіставні від версії до версії.
У готової моделі правлять інструкцію та підбирають вдалі приклади, і після правки не можна гарантувати, що раніше правильні відповіді не поїхали.
На практиці частіше працює зв'язка: готова мовна модель розмічає великий масив тексту, на цій розмітці навчається власний класифікатор, і далі він працює швидко та передбачувано. Критерій вибору один — якість на своїх класах і те, як часто ці класи будуть змінюватися.
Часті технічні питання по проєкту
Розмітка та підтримка моделі визначають, чи окупиться класифікація. Нижче — п'ять питань, які найчастіше звучать на технічних сесіях, з відповідями по суті.
Скільки даних потрібно розмітити для старту?
Для базової моделі за розрідженими ознаками вистачає кількох тисяч прикладів на клас — цього достатньо, щоб закрити 80–90% типових звернень. Нейромережа потребує більшого обсягу, але до неї ми переходимо лише там, де проста модель стабільно помиляється.
Що робити, якщо історичних даних немає?
Стартуємо з правил і пошуку за ключовими фразами: вони закривають очевидні випадки й попутно розмічають корпус. Упевнені відповіді стають навчальною вибіркою — історія накопичується в процесі, окремий архів не потрібен.
Розмітники трактують категорії по-різному — це проблема?
Це головна стеля якості. До розмітки фіксуємо інструкцію з прикордонними прикладами, потім рахуємо узгодженість між розмітниками, а спірне розбираємо на сесії. Якщо категорію можна прочитати двояко — правимо інструкцію, а не дані.
Як зловити деградацію якості?
Слідкуємо за часткою впевнених передбачень, розподілом класів і часткою звернень, що пішли на ручний розбір. Зміна вхідних текстів — дрейф даних, лікується перенавчанням; просідання метрик при тому ж вході — деградація, і відкат на попередню версію повертає якість.
Як часто потрібно дообучати модель?
За подією, а не за календарем: метрики пішли за поріг або накопичилася партія розмічених виправлень. Кожен цикл дає версію з журналом метрик і можливістю відкату, тому дообучення не стає незворотним.
Обговоримо задачу: що потрібно від вас і коли повернемося з планом
Щоб оцінка була предметною, а не «за відчуттями», нам потрібен мінімум контексту: де класифікація вбудовується в процес, який обсяг текстів через неї проходить і що вважається помилкою. Розмова займає у замовника одну розмову, зате знімає половину уточнень на етапі оцінки.
- Постановка задачі: який процес обслуговуємо — маршрутизацію звернень, розмітку відгуків, сортування документів — і що саме розв'язує модель.
- Вихідні дані від замовника: вивантаження текстів за період, бажано з уже проставленими мітками хоча б на частині прикладів.
- Список категорій і правила їх перетину: що робити, якщо текст підходить до двох одразу.
- Вимоги до якості: яка частка помилок припустима і яка помилка дорожча — пропуск чи хибне спрацювання.
- Точка інтеграції: куди повертаємо результат — у систему заявок, сховище документів чи внутрішній сервіс, і в якому вигляді.
- Обмеження: персональні дані, закритий контур, вимоги до зберігання — вони визначають, які моделі припустимі.
Порядок оцінки такий: розбираємо дані, перевіряємо, чи вистачає прикладів для навчання, і повертаємося з планом робіт. Першим етапом ставимо пілот на одному процесі — він показує реальну якість на ваших текстах, і тільки після нього масштабуємо на інші потоки.
Опишіть задачу та додайте, що є за даними, — повернемося з оцінкою та планом робіт.
