Класифікація звернень з AI: де ламається маршрутизація
Ручне сортування звернень тримається на одному припущенні: оператор встигає прочитати вхідний потік і розкласти його за категоріями раніше, ніж надійдуть нові. Поки це десятки запитів на день, схема працює.
На потоці в кілька сотень вона розсипається — черга першої лінії зростає швидше, ніж її розбирають, і частина звернень до вечора залишається без категорії та власника.
Перший збій — пріоритет звернення. У ручному режимі він ставиться за суб'єктивною ознакою: хто гучніше написав, хто раніше додзвонився, кого попросив керівник.
У практиці сервісного управління пріоритет рахують від впливу й терміновості, як описано в ITIL, — за ручного розбору ця логіка тримається на пам'яті оператора і розсипається за пікового навантаження.
Другий збій — маршрутизація звернень. Категорія, вибрана вручну, часто йде не до тієї групи, і звернення перекидають між лініями, втрачаючи контекст: клієнт повторює історію, вкладення пересилаються заново, час до першої відповіді подвоюється.
Великі інциденти тонуть у загальному потоці однотипних питань — не тому, що їх не помітили, а тому, що черга не розрізняє важливе й масове.
Розбираємо, як це закривається: де саме ламається маршрутизація, які ознаки звернення потрібно витягувати і як класифікація звернень з AI прибирає ручне сортування з першої лінії.
Що змінюється після впровадження: час відповіді та частка ручних розборів
Ефект від класифікації звернень ШІ видно на п'яти метриках першої лінії: час до першої відповіді, частка звернень, що потрапили до потрібної групи з першого разу, частка ручного сортування, кількість повторних ескалацій і поведінка на піку. Їх знімаємо до запуску і після — за журналами обробки, а не за відчуттями співробітників.
Перша лінія: швидкість, точність, розвантаження операторів
Модель розмічає вхідний потік за темою, терміновістю й потрібною компетенцією ще до того, як звернення потрапить до людини.
Час реакції на звернення падає з годин до хвилин: маршрут і пріоритет проставлені на вході, оператор не перебирає чергу цілком, а одразу відкриває призначене йому.
На сталих категоріях точність класифікації тримається близько 90%, спірні випадки йдуть на донавчання з розміткою межових прикладів.
Частка ручного сортування скорочується в рази: диспетчер перестає розкладати потік і займається лише змішаними темами, зверненнями без зрозумілого тексту та конфліктними формулюваннями. Звільнений час іде на змістовні відповіді, а не на маршрутизацію.
Суміжні процеси: навантаження, ескалації, аналітика
Пікове навантаження на підтримку перестає бути точкою відмови. Класифікатор тримає постійну пропускну здатність, тому за десятиразового зростання потоку черга не зростає кратно — збільшується лише частка звернень, що потребують відповіді людини. Пріоритет розводить чергу: термінові йдуть уперед, типові отримують готову відповідь.
Побічний ефект — керованість. З'являється розріз за темами й причинами, на якому видно, які збої породжують звернення і де накопичуються повторні ескалації. Це ефект уже на продукт, а не лише на першу лінію.
Варіанти класифікації: правила, навчання на розмітці, гібрид
Три підходи — не альтернативи «або-або», а різні точки на шкалі: правила й шаблони дають передбачуваний старт, навчання на розмітці — стійкість до формулювань, які ніхто не передбачив.
Що вибрати, вирішують два фактори: скільки вже накопичено розмічених звернень і як часто змінюється номенклатура причин.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила й шаблони | Причин небагато, формулювання сталі, потрібен передбачуваний старт без розмітки | Ламається на перефразуваннях і одруках; правила зростають у кількості й починають конфліктувати |
| Навчання на розмітці | Є історія звернень і зрозуміла схема класів | Потребує узгоджених міток; за зміни номенклатури потрібна перерозмітка |
| Гібридна схема класифікації | Потік неоднорідний: частина випадків формалізується, частина — ні | Потрібно версіонувати обидві частини й регулярно контролювати якість розмітки |
Що вирішує кожен підхід на короткому горизонті
Правила дають робочий маршрут за лічені дні: інженери описують умови, класифікатор одразу розводить звернення, а помилки видно й правляться без перенавчання.
Гібрид на старті поводиться так само, але шар правил від самого початку збирає статистику — які звернення модель розмічає невпевнено і що варто надіслати на розмітку першим.
На довгому горизонті
Навчання на розмітці виграє там, де потік зростає і формулювання змінюються: частка правильних маршрутів тримається завдяки новим прикладам, а не новим умовам. Тут вирішує якість розмітки — узгодженість міток між розмітниками і регулярний перегляд спірних класів. Інакше модель закріплює чужі помилки, і точність знижується непомітно.
Етапи впровадження: від розбору потоку до передачі в експлуатацію
Починаємо не з моделі, а з потоку: скільки звернень надходить, якими каналами, яка частка йде не туди і скільки часу оператор витрачає на ручне сортування. За цими цифрами видно, де класифікація дає ефект, а де достатньо регламенту.
- Аудит потоку звернень: вивантаження за період, розподіл за каналами й темами, замір частки помилок маршрутизації та часу до першої відповіді.
- Схема класів і пріоритетів: список тем і правила ескалації. Класів має бути небагато і без перетинів — інакше система плутається на межах.
- Підготовка розмітки: розмічаємо історичні звернення за схемою, спірні випадки виносимо окремо. Тут же видно, яких класів у даних не вистачає.
- Налаштування: підбираємо поріг впевненості, за якого звернення йде оператору, а не в автовідповідь. Помилка на терміновому дорожча за зайву ручну перевірку.
- Регламент маршрутизації: хто і коли переглядає класи, як оператор оспорює рішення системи і куди потрапляє його правка.
Перевірка на історичних даних
Проганяємо систему на зверненнях за минулий період, де маршрут відомий, і дивимося якість за кожним класом, а не загальну точність. Окремо перевіряємо термінові: частка пропущених критичних звернень має бути близькою до нуля навіть за рахунок ручного сортування частини звичайних.
Передача в експлуатацію
Передаємо налаштовану систему й документацію: схему класів, пороги, порядок розбору помилок. Навчаємо операторів і підтримку — як читати впевненість системи, що робити за зміни тематики звернень. Перший період після запуску залишаємося на зв'язку.
Що залишається в команди замовника: схеми, правила, розмітка
Систему має сенс приймати не за відповідями на тестовій вибірці, а за тим, що залишається всередині контуру замовника і дозволяє супроводжувати її власними силами. Передаємо документи, розмітку й правила роботи з даними — у початковому вигляді, з правом правки під свої процеси.
Склад документації
- Схема класів і пріоритетів: перелік категорій, межі між схожими класами й правила маршрутизації — який пріоритет і отримувач у кожної категорії.
- Розмічений набір звернень: еталонна вибірка з узгодженою розміткою, включно зі спірними випадками із зафіксованим обґрунтуванням. За нею перевіряють якість після будь-якої зміни.
- Правила розмітки нових даних: що робити зі зверненням поза наявними класами, коли вводити новий і хто це погоджує.
- Регламент супроводу: додавання класів, частота контрольних прогонів, поріг надсилання на донавчання, відповідальні за кожен крок.
- Опис вхідних полів: що подається на вхід, що ігнорується, як обробляються вкладення.
- Журнал рішень: де зберігається історія класифікації з пріоритетом і впевненістю і як за нею розбирати помилкові спрацювання.
Правила доступу до даних
- Розмежування ролей: хто бачить вихідні тексти, хто — лише знеособлені вивантаження, хто змінює розмітку.
- Порядок знеособлення: які поля маскуються або видаляються до потрапляння в розмітку й журнали.
- Зберігання й передача: терміни, відповідальний за контур, порядок вивантаження моделі й розмітки за зміни підрядника.
Кейс: як маршрутизація заявок стала передбачуваною після запуску
Потік звернень надходив з пошти, чату й телефонії в одну чергу, а далі оператори першої лінії вручну вирішували, кому адресована заявка.
Пріоритети й рівні обслуговування були описані за ITIL, а от розмітка вхідного потоку трималася на пам'яті людей — і ламалася першою за зростання навантаження.
Що було до
Заявки потрапляли до спільного пулу: тему, групу виконавця й пріоритет оператор визначав за текстом листа.
Коректно з першого разу йшло близько 71% звернень, решту перекидали між групами, і кожна передача додавала до відповіді новий цикл очікування — медіана до першої відповіді трималася близько чотирьох годин, за терміновими — до двох.
Ручний розбір займав близько 40% часу першої лінії: 3-5 хвилин на лист, а за піків черга просто зростала. Частина збоїв була передбачуваною: теми «оплата» й «доступ» плуталися між собою, а інциденти з високим пріоритетом ставали в загальну чергу поряд із консультаціями.
Що змінилося після
Ми розмітили архів звернень разом із замовником і навчили модель на цій розмітці: вона присвоює зверненню тему, групу й пріоритет, а спірні випадки з низькою впевненістю віддає людині й добирає їх у донавчання. Рішення логуються разом із текстом і ознаками, тому причину помилки видно без ручного відтворення.
- коректна маршрутизація — 94% проти 71%
- медіана часу до першої відповіді — 40 хвилин, за терміновими — 12
- частка звернень на ручному розборі — 9% замість 40%
- прострочення за рівнем обслуговування — 2% замість 11%
Чим відрізняється класифікація звернень правилами від моделі?
Правила дають детерміновану відповідь: є номер договору зі списку або слово зі словника — звернення йде до потрібної черги однаково за першого й тисячного запуску.
Плата за передбачуваність — крихкість: якщо клієнт напише «гроші пішли, а товару немає» замість «не надійшла оплата», словник схибить. Сотні виразів доводиться підтримувати вручну й проганяти по архіву звернень за кожної правки.
Модель розв'язує зворотну задачу: узагальнює формулювання, переносить досвід із частих прикладів на схожі рідкісні та переживає одруки, трансліт і зміну каналу.
Слабке місце — довгий хвіст: клас, який у розмітці трапляється одиницями, вивчити нема на чому, і якість за ним знижується. Відповідь моделі — ймовірність, а не інструкція, тому на питання «чому це спам» без атрибуції ознак не відповісти.
На практиці виграє дворівнева схема. Жорсткі правила закривають те, що не можна віддавати на відкуп статистиці: юридично значущі тригери, чорні списки, обов'язкова маршрутизація великих клієнтів — вони спрацьовують миттєво і пояснюються одним рядком.
Модель на базі scikit-learn або нейромережевий класифікатор бере решту: тему, тональність, ознаки терміновості й повторності.
Пояснюваність складається з двох частин: код причини від правила і впевненість моделі. Нижче порогу звернення йде оператору як сумнівне, а не в автоматичну чергу — це і є захист від тихих помилок.
Правки операторів повертаються в розмітку і раз на кілька тижнів ідуть на перенавчання, тому частка рідкісних класів поступово зростає, а передбачуваність залишається на боці правил.
Технічні сумніви: розмітка, рідкісні класи, контроль якості
Три питання звучать на кожній оцінці: скільки прикладів розмітити, що робити з класами, які трапляються рідко, і як помітити, що якість класифікації пішла вниз. Відповідаємо предметно — за цими запереченнями в нас є відпрацьовані схеми, перевірені на живому потоці звернень.
Скільки звернень потрібно розмітити на старті?
Обсяг залежить від кількості класів та їхньої змістової близькості.
Починаємо з кількох тисяч прикладів, що покривають кожен клас, а далі добираємо активним відбором: у розмітку йдуть спірні звернення, де модель невпевнена, — приріст якості на одиницю зусилля вищий, ніж за випадкової вибірки.
Що робити з рідкісними типами звернень?
Клас, що займає частки відсотка трафіку, загальним навчанням не підняти. Працює комбінація: ваги класів, окремі пороги впевненості для кожного типу, об'єднання близьких типів у надклас із подальшим розділенням. І метрика — повнота за рідкісним класом: у загальній точності його провал розчиняється.
Як зрозуміти, що якість класифікації знизилася?
Стежимо за двома сигналами: розбіжністю розподілу вхідних текстів з еталонною вибіркою і часткою класу «інше» разом із середнім рівнем впевненості — вони реагують на зміну формулювань раніше, ніж скарги операторів.
Кожне оновлення проходить регресійний набір з еталонними відповідями, а спірні випадки розбираємо за матрицею помилок з арбітражем розмітників. Якщо повнота за критичним класом падає, відкочуємо модель на попередню й розбираємо причину.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Для старту обговорення достатньо вивантаження звернень за кілька тижнів у тому вигляді, у якому вони лежать у системі: текст, канал, тема, підсумковий виконавець, мітки, виставлені операторами вручну.
Чим менш причесане вивантаження, тим точніше видно реальний розподіл класів і місця, де ручна маршрутизація розривається.
Корисно додати до неї довідник категорій і пріоритетів, регламент термінів реакції за кожним рівнем і десяток спірних випадків — тих, про клас яких оператори сперечаються досі.
- вивантаження звернень із текстом, каналом та історією обробки;
- актуальний довідник категорій, підкатегорій і пріоритетів;
- регламент термінів реакції та ескалації за рівнями;
- приклади спірних і помилково маршрутизованих звернень;
- перелік каналів надходження, включно з розшифровками дзвінків;
- обмеження щодо даних: що не можна виносити в зовнішній контур і які поля персональні;
- поточна схема маршрутизації: хто і за яким правилом призначає виконавця.
За цією картиною ми розберемо потік, оцінимо частку звернень з однозначним класом і повернемося з планом впровадження: підготовка розмітки й навчання моделі на ваших прикладах, пілотний запуск на одному каналі з паралельним ручним контролем, метрики якості та розбір помилок, потім передача в експлуатацію з моніторингом і регламентом донавчання. Опишіть задачу — повернемося з оцінкою та планом робіт.
