Розробка NLP-систем: де падає точність
Готова модель з відкритого репозиторію Hugging Face на демонстраційній вибірці показує якість класифікації вище 0.9 — і на цьому пілот зазвичай зупиняють.
Набір для перевірки зібрано з коротких чистих текстів, він збігається за розподілом з навчальним, а мітки проставлено за одним зрозумілим правилом. У реальному потоці ті самі класи дають помітно меншу точність моделі, і розрив пояснюється не моделлю.
Обробка звернень приносить змішаний вхід: одруки й трансліт, уривки з чатів, листи з історією листування та підписами, дві-три мови всередині одного повідомлення.
Зверху лягає внутрішня термінологія — абревіатури продуктів, назви тарифів, жаргон відділу, — якої немає в жодному відкритому корпусі, тому модель упевнено відносить такі тексти до неправильного класу.
Третя причина — розмітка даних. Якщо інструкція для розмітників описує класи прикладами, а не вирішальними правилами, узгодженість падає: на пограничних випадках мітки розходяться, і модель вчиться відтворювати ці розбіжності.
Далі вмикається дрейф — з'являється новий продукт або змінюється формулювання звернення, точність іде, а без окремого контуру контролю це помічають уже за скаргами.
Тому розробка NLP-систем починається не з вибору моделі, а з профілю даних: вимірюємо довжину текстів, частку змішаних мов, частоту одруків, збираємо словник термінів замовника.
Далі — схема розмітки з правилами й арбітражем спірних випадків, відкладений набір для контролю та регулярна перевірка на живому потоці. Розбираємо, як це закривається на кожному кроці.
Що дає вибудуваний конвеєр обробки тексту
Звернення, які закриваються без людини, — це не «повна автоматизація», а частка запитів, що потрапляють у впевнений інтервал моделі. Ми рахуємо її на розміченій вибірці й підбираємо поріг так, щоб спірні випадки йшли оператору, а не клієнту. Пропускна здатність зростає без розширення штату: пікову чергу розбирають ті самі люди.
Час відповіді складається з роботи моделі та постобробки. Затримку частіше дає не вона, а синхронні виклики довідників і записи в облікову систему.
Вимірявши кожен етап, ми прибираємо зайві очікування: перша осмислена відповідь іде за частки секунди, а важкі перевірки йдуть фоном.
Простій коштує дорого, коли розбір тексту вбудовано в єдину точку. Тому моделі та правила валідації версіонуються, обробка йде на кількох екземплярах, а при збої конвеєр переходить у спрощений режим — сортування за правилами й передача оператору замість відмови в обслуговуванні.
Контроль якості — це регулярна перевірка на відкладеній вибірці, а не звіт після запуску. Рахуємо частку помилок за класами: вилучення сутностей, визначення наміру, тональність — і стежимо, щоб зростання в одному класі не маскувалося середнім по системі. Окремо фіксуємо зниклий клас відмов: наприклад, листи, які губилися через формат або мову.
Готові моделі та бібліотеки екосистеми на кшталт Hugging Face закривають базовий шар NLP-конвеєра, тому час іде не на навчання з нуля, а на розмітку під ваш домен і розбір помилок. Це й визначає, яка частка звернень реально закривається без людини.
Варіанти реалізації: хмара, власні потужності, гібрид
Вибір схеми диктують три речі: чутливість даних, обсяг розмічених прикладів і швидкість зміни предметної області. Нижче — чотири альтернативи, між якими реально обирають на старті проєкту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова модель | Швидкий старт, типові задачі, своїх даних мало | Якість упирається в чужу предметну область: терміни та внутрішні позначення розпізнаються нестабільно |
| Дообучення моделі | Є кілька тисяч узгоджених прикладів і зрозуміла метрика якості | Потрібна регулярна розмітка; при зміні даних якість падає, потрібен новий цикл |
| Контур на власних потужностях | Дані не можна виносити за периметр, потрібен повний контроль над журналами | Запуск довший: резервування, моніторинг і оновлення моделей усередині закритої мережі |
| Гібридна схема | Частина запитів нечутлива, частина — строго внутрішня | Складніше в супроводі: два контури, узгодження форматів, маршрутизація запитів |
Вимоги до даних однакові для всіх варіантів: єдиний формат, узгоджена розмітка й зафіксоване правило, що вважається правильною відповіддю. Зазвичай стартують з готової моделі — вона дає робочий прототип на реальних запитах, і відразу видно, де саме бракує якості.
Дообучення підключають, коли під свої класи накопичено приклади, а контур на власних потужностях або гібрид — коли периметр важливіший за швидкість запуску.
Схему не обирають раз і назавжди: при зростанні обсягу запитів і накопиченні розмітки перехід між варіантами — це планова робота, а не переписування системи з нуля.
Етапи впровадження: від аудиту даних до розгортання
Проєкт з обробки мови частіше провалюється не на моделі, а на невідповідності даних: у розробці — охайне вивантаження, у роботі — живий потік з одруками, змішаними мовами та порожніми полями. Тому йдемо фіксованою послідовністю, де в кожного кроку є перевірюваний результат.
- Аудит даних. Розбираємо джерела: обсяг, частку нерозмічених записів, дублі, персональні дані. На виході — придатність кожного джерела й список того, що чистимо руками.
- Схема рішення. Визначаємо, де модель стає в контур: що закриваємо правилами й словниками, що — навчанням, який формат входу й виходу потрібен сусіднім системам. Схему узгоджуємо до старту, щоб не переробляти інтеграцію.
- Еталонна вибірка. Збираємо вручну розмічений набір, що покриває рідкісні та спірні випадки, і фіксуємо метрики за кожним класом, а не одну загальну цифру. Це база порівняння для всіх наступних версій.
- Налаштування й навчання. Готуємо ознаки та розмітку, навчаємо модель, підбираємо пороги спрацювання під допустиму частку хибних. Кожна версія зберігається разом з параметрами й результатом на еталонній вибірці.
- Перевірка на потоці. Запускаємо в тіньовому режимі: модель відповідає, рішення ухвалює поточний процес. Порівнюємо з еталоном, дивимося частку невпевнених відповідей, затримку та поведінку на рідкісних класах.
- Розгортання. Переносимо в робочий контур з версіонуванням моделей, журналом запитів і відкатом на попередню версію. Налаштовуємо контроль дрейфу: падіння якості видно раніше, ніж його помітить замовник.
- Передача. Документація, регламент перенавчання й розбору помилок, доступи — команда замовника розвиває рішення далі без нас.
Комплект постачання: конфігурації, схеми, регламенти
Комплект постачання — це те, що дозволяє експлуатувати й розвивати систему без нашої участі: конфігурації середовищ, схеми обробки даних, правила розмітки, документація та регламенти.
Усе перелічене передається в репозиторій замовника й приймається разом з кодом — не окремим «пакетом документів», який відкривають один раз при здачі й більше ніколи.
- Конфігурації середовищ: розгортання, змінні середовища, ліміти ресурсів, доступи до зовнішніх сервісів — з поясненням, який параметр на що впливає і що буде, якщо його змінити.
- Схема обробки: шлях запиту від приймання до відповіді — де модель, де правила-фільтри, де кеш, які точки логуються й як пов'язати запис у журналі з конкретним рішенням системи.
- Правила розмітки: інструкція для анотаторів, словник спірних випадків, критерії згоди між розмітниками та порядок розв'язання конфліктів в оцінках.
- Документація щодо моделі: склад ознак, походження навчального набору, метрики якості за класами, відомі межі застосовності та типові помилки на живих даних.
- Регламент експлуатації: що моніторимо, пороги деградації якості, порядок відкату на попередню версію, частота оновлення словників і правила перенавчання.
- Схема оповіщень: які метрики збираються, де дивитися, при яких значеннях черговий отримує сигнал і що робить першим кроком.
- Порядок передачі рішення: доступи й ролі, запуск системи з нуля на чистому середовищі та інструкція для інженера замовника, який увійде в проєкт після нас.
Кейс: обробка звернень у службі підтримки
Клієнтська підтримка приймала кілька тисяч звернень на місяць, і всі вони йшли в ручну обробку. Оператор сам визначав тему й терміновість, сам шукав відповідь у базі знань і сам вирішував, на яку лінію передати запит.
На піку перше змістовне повідомлення клієнт отримував через кілька годин, а близько п'ятої частини звернень пересилалося між лініями — кожне переведення додавало затримку й повторне пояснення проблеми.
Ми зібрали конвеєр: обробка тексту звернення, визначення теми й терміновості, пошук відповідного фрагмента бази знань, автоматична відповідь при впевненості моделі вище порога й маршрутизація на потрібну лінію при впевненості нижче.
Робоче місце оператора підключили до Zendesk: співробітник бачить запропоновану тему та чернетку відповіді й підтверджує або править їх однією дією, а не збирає відповідь з нуля.
| Метрика | До | Після |
|---|---|---|
| Частка автоматичних відповідей | 0% | 63% |
| Час до першої відповіді | години | хвилини |
| Помилкові маршрутизації | 18% | 4% |
| Звернення, закриті вручну | 100% | 37% |
Поріг упевненості — головне налаштування в такій системі: нижчий поріг — більше автоматичних відповідей і більше помилок, тому ми підбирали його на розміченій вибірці реальних звернень, а не на відкладеній тестовій.
Спірні випадки модель не «додумує», а віддає оператору разом з фрагментом, на який спиралася, — це прибирає клас відмов, коли клієнт отримує впевнену, але неправильну відповідь.
Чим відрізняється дообучення NLP-моделі від навчання з нуля?
Різниця — у точці старту. Навчання з нуля ініціалізує ваги випадковими значеннями, і модель виводить мовні закономірності лише з того корпусу, який їй показали.
Дообучення стартує з попередньо навченої моделі, де вже зафіксовано синтаксис, морфологію та загальні смислові зв'язки, і налаштовує її під конкретну задачу — класифікацію звернень, вилучення сутностей, розбір діалогів.
Звідси різниця в обсязі вибірки на порядки. Для дообучення під домен зазвичай достатньо кількох сотень розмічених прикладів на клас, щоб метрики на відкладеній вибірці вийшли на робоче плато.
Навчання з нуля потребує корпусу в мільярди слів і токенів і розподілених обчислень на тижні — і на вузькому домені все одно часто програє перенесенню моделі.
Навчання з нуля виправдане, коли домен радикально розходиться з навчальним корпусом: рідкісна мова без цифрових текстів, вузька нотація на кшталт телеметрії обладнання або генетичних послідовностей, або вимоги замовника забороняють використовувати зовнішні попередньо навчені ваги з ліцензійних причин чи за вимогами до приватності даних.
На практиці частіше працює гібрид: спочатку продовжене попереднє навчання на власному нерозміченому корпусі — воно підтягує словник і розподіли до лексики домену, — потім дообучення на невеликій розміченій вибірці.
Таке перенесення моделі скорочує потребу в розмітці приблизно на два порядки, а якість ми перевіряємо на відкладеній вибірці з реальних даних домену.
Тому ми спочатку рахуємо, чи достатньо дообучення до потрібної якості, і тільки потім обговорюємо корпус і розмітку під навчання з нуля.
Технічні сумніви: дані, розмітка, навантаження
Інженерні сумніви стосуються не моделі, а всього навколо неї: чи вистачить розмітки, чи витримає рішення пікове навантаження, чи не витечуть дані й хто відповідає за якість через пів року. Нижче — відповіді на те, що найчастіше виринає на технічній прийомці.
Скільки розмітки потрібно, щоб модель працювала?
Обсяг рахуємо від задачі: на старті достатньо кількох сотень розмічених прикладів на клас, далі добираємо на спірних випадках з реального потоку. Важливіша якість схеми — подвійна розмітка частини вибірки й замір згоди показують, чи суперечлива інструкція. Якщо розмітники розходяться, дообучення не допоможе: спочатку правимо правила.
Що буде при піковому навантаженні?
Профіль трафіку знімаємо до проєктування: пікові години, сезонні сплески, частку важких запитів. Під пік закладаємо чергу й пріоритети, щоб система деградувала — відповідала повільніше — замість відмови. Навантажувальні випробування проганяємо за реальним профілем, а не за середнім.
Як забезпечується конфіденційність даних?
Модель розгортаємо в контурі замовника: дані не покидають інфраструктуру й не беруть участі в навчанні сторонніх рішень. Персональні поля знеособлюємо до потрапляння у вибірку, доступ до сирих даних розмежовано, звернення до моделі журналюються.
Хто відповідає за дрейф якості після запуску?
Дрейф ловимо метриками на потоці, а не скаргами: відстежуємо частку впевнених відповідей і відмов, накопичуємо спірні приклади. Дообучення запускаємо за тригером — коли метрика виходить за поріг, — і після проганяємо регресійний набір, щоб не зламати те, що працювало. Регламент оновлення й передача чергування входять у постачання.
Обговоримо задачу: що надіслати для оцінки
Щоб повернутися з оцінкою проєкту й планом робіт, а не із загальними словами, потрібен мінімум контексту. Готувати документи не доведеться: зазвичай достатньо того, що вже є в команди — вивантаження звернень, чернетки процесу, прикладів листів. Чим ближчі ці матеріали до реальності, тим менше правок вирине на етапі прийомки.
- Приклади даних — кілька сотень реальних звернень, листів або розшифровок у тому вигляді, у якому вони потрапляють у систему: з одруками, змішуванням мов, вкладеннями й порожніми полями.
- Опис потоку — звідки надходить текст, хто і що з ним робить далі, які системи отримують результат: облік заявок, внутрішній портал, звітність.
- Вимоги до якості — які помилки неприпустимі, а які припустимі, чи потрібна оцінка впевненості й що система має робити при низькій.
- Обмеження за контуром — де дозволено обробляти дані: зовнішня хмара, захищений контур або повністю локальний запуск, і скільки їх можна зберігати.
- Обсяги й режим — скільки документів надходить на добу, чи потрібна відповідь у реальному часі або достатньо обробки за розкладом.
- Критерії приймання — на якому наборі прикладів перевіряємо якість і яке розходження з очікуванням вважаємо прийнятним для запуску.
Цього достатньо, щоб зібрати план робіт: етапи, склад команди, строки й точки, де ви бачите проміжний результат. Розмова займає близько години — за підсумками ви отримуєте оцінку з явно названими припущеннями й відкритими питаннями, а не презентацію. Далі узгоджуємо старт робіт і ритм демонстрацій, щоб результат був перевірюваний на кожному кроці.
