Чому intent detection ламається на живому трафіку
У пілоті розпізнавання намірів дає точність під 95% на розміченому наборі в кілька сотень реплік. На живому трафіку та сама модель помиляється на кожній третій фразі, і частка ручного переведення на оператора зростає з перших днів роботи.
Перше джерело помилок — довгий хвіст запитів. Люди пишуть так, як модель не бачила: «а можна з доставкою, але не цього тижня», «підкажіть, я заплуталася в тарифах».
Кожне таке формулювання трапляється один раз, до навчальної вибірки не потрапляє, а в сумі ці репліки дають половину звернень.
Друге — неоднозначні формулювання та змішані теми в одній репліці. «Поверніть гроші та відключіть підписку» — це два різних наміри в одному повідомленні, а класифікатор навчений вибирати один клас і мовчки губить другий. Користувач не отримує відповіді на половину питання і повторює його, вже роздратовано.
Третє — відсутність єдиного словника. Поки розмітники й аналітики не домовилися, де межа між «скасувати замовлення» та «змінити замовлення», схожі фрази роз'їжджаються в різні класи.
Таксономія розпливається, метрика на відкладеній вибірці виглядає пристойно, а помилки розпізнавання намірів спливають уже в діалозі.
Згори лягає шум введення — одруки, трансліт, розпізнане мовлення. Саме на ньому ламається все, що добре працювало в демо. Далі розбираємо, як це закривається.
Що дає керована таксономія намірів
Поки наміри зібрані списком фраз «як вийшло», близькі класи перекриваються, і бот відповідає не в тему. Керована таксономія — це ієрархія домен → інтент → під-інтент, де в кожного класу є правило відповіді, а для всього непокритого заведений окремий клас поза сценарієм. Точність рахується по кожному домену окремо, і слабкий домен не розмиває загальну картину.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Плоский список, 30–50 інтентів | Один сценарій підтримки, вузька продуктова база | Нові теми падають у найближчий інтент — зростають хибні спрацювання |
| Ієрархія домен → інтент → під-інтент | Кілька напрямів, різні команди | Потрібна розмітка й арбітраж спірних прикладів |
| Таксономія з явним класом поза сценарієм | Відкрита база, потік незнайомих формулювань | Потребує регулярного перегляду: частина нових тем переводиться в реальні інтенти |
Ефект видно на трьох метриках. Частка автовідповідей зростає з 50–60% до 85%: модель перестає вгадувати між схожими намірами. Частка ручних переведень падає в 2–3 рази — оператор підключається лише при впевненості нижче порога або при явному запиті поза сценарієм.
Стійкість на нових темах дає клас поза сценарієм: незнайоме формулювання не притягується до найближчого інтенту, а потрапляє в чергу на розбір, і таксономія переглядається за цими прикладами.
Зникає й цілий клас відмов — «бот упевнено відповів не те», який дорожчий за чесне переведення на оператора. Поріг впевненості по кожному домену та явна ієрархія — відпрацьована практика у відкритих платформах на кшталт Rasa.
Підходи до intent detection: правила, навчання, гібрид
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Правила та словники | 10–30 інтентів, стабільні формулювання, розмітки поки немає | рветься на перефразуваннях та одруках; словник зростає швидше, ніж точність |
| Навчання на розмічених діалогах | живе мовлення, тисячі прикладів, інтенти перетинаються | потрібна розмітка та її перезбирання при зміні таксономії; рідкісні інтенти просідають |
| Гібридний підхід | правила як швидкий шар на критичних інтентах, модель — на решті | складніше налагодження: помилка живе або в правилі, або в моделі |
Вибір тут визначається не модою, а обсягом діалогів і стабільністю предметної області. Правила та словники дають передбачуваність на вузькому наборі інтентів, навчання на розмітці — узагальнення на перефразування, гібрид — компроміс між керованістю та гнучкістю.
Гібрид зазвичай збирається каскадом: словниковий шар знімає однозначні звернення, модель розподіляє залишок, а поріг впевненості вирішує, відповідати автоматично чи уточнювати.
Поріг підбирається за матрицею помилок — завищений жене частку передач оператору вгору, занижений збільшує кількість неправильних відповідей. Ми фіксуємо його на валідації та переглядаємо при кожній зміні таксономії, інакше якість тихо з'їжджає.
Що вибрати — залежить від того, що дорожче саме вам: хибна відповідь чи зайве переведення оператору. Опишіть задачу та покажіть логи діалогів — повернемося з оцінкою, який із трьох варіантів закриє ваші інтенти.
Впровадження: від аудиту діалогів до передачі регламентів
Впровадження intent detection — це не разове тренування моделі, а цикл: аудит реальних діалогів задає таксономію, розмітка її уточнює, а відкладена вибірка показує, де класифікатор помиляється на нових формулюваннях.
Ідемо етапами, після кожного видно вимірюваний результат — частка вірних спрацювань, кількість зайвих уточнень, глибина черги на оператора.
- Аудит діалогів. Вивантажуємо історію звернень за період, рахуємо частку нерозпізнаних і сценарії з повторними уточненнями. Так видно, які наміри варто виділяти окремо, а які закриває звичайне меню.
- Схема таксономії. Збираємо наміри в ієрархію: згори задача клієнта, нижче уточнення та сутності. Перевіряємо перетини класів, щоб близькі запити не сперечалися за одну мітку.
- Розмітка намірів. Пишемо правила для спірних випадків і тримаємо контрольну вибірку для перевірки узгодженості. Розходження розмітників вище порога повертає нас до правок схеми, а не до навчання.
- Налаштування впевненості. Задаємо поріг, нижче якого бот ставить уточнювальне питання замість здогаду, і правило переведення оператору. Хибна впевненість на рідкісному класі коштує дорожче за зайве уточнення.
- Відкладена вибірка. Набір діалогів, що не потрапив у навчання, проганяємо перед викаткою: дивимося матрицю помилок по класах, а не одну загальну точність — інакше рідкісні наміри ховаються за середнім.
- Перевірка та передача регламентів. Випускаємо в тіньовому режимі: модель класифікує, відповідає поки старий сценарій. Потім віддаємо регламент оновлення — періодичність перенавчання, метрики деградації, відповідальний за правки таксономії.
Комплект постачання: таксономія, схема, регламенти
Артефакти, які описують, що ми вважаємо наміром і як поводимося з кожною відповіддю, залишаються в замовника разом із кодом. Без них модель через місяць перетворюється на чорну скриньку, а будь-яка зміна сценарію вимагає повернення до підрядника. Нижче — комплект, який фіксуємо в прийманні.
- Словник намірів (таксономія). Дерево інтентів з описом, прикладами фраз на кожен клас, межами між близькими намірами та правилами розмітки спірних випадків. Окремим блоком — те, що свідомо не відносимо до жодного інтенту.
- Схема маршрутизації. Таблиця «намір → сценарій або оператор», пороги впевненості, поведінка при низькій впевненості та пріоритети, якщо спрацювало кілька класів одночасно.
- Політики обробки. Що потрапляє в логи, що маскується або не зберігається взагалі, термін зберігання, ролі доступу та порядок вивантаження даних для розбору помилок.
- Документація таксономії. Порядок додавання та перейменування намірів, версіонування словника, власник з боку замовника та точки узгодження з бізнесом.
- Регламент перенавчання. Тригери оновлення (частка нерозпізнаних, зсув формулювань користувачів), частота, хто розмічає нові приклади і як перевіряємо якість до викатки.
- Контрольний набір і звіт якості. Фіксована вибірка діалогів, метрики по кожному наміру, порівняння з попередньою версією та порядок відкату при просіданні.
- Інструкції для підтримки. Куди заводити нетипові звернення, як ескалювати і хто оновлює словник, щоб нові випадки не губилися між командами.
Кейс: як прибрали хибні переведення на оператора
Що було
Клієнт прийшов із ботом підтримки, який переводив на оператора більше третини діалогів — включно з тими, де відповідь уже лежала в базі знань.
Таксономія намірів збиралася вручну і містила перетинні класи: «статус замовлення» та «де посилка» йшли в різні категорії, а модель із рівною впевненістю відносила запит до обох. Поріг впевненості зафіксували при запуску і не переглядали.
На відкладеній вибірці частка вірних розпізнавань становила 72%, частка хибних переведень на оператора — 34%. Кожен третій діалог забирав час оператора, хоча автоматика закрила б його швидше.
Що змінили
Перезібрали таксономію: прибрали перетини, розвели близькі наміри та додали окремий клас «не розпізнано» замість натягування запиту на найближчу категорію. Розмітили стратифіковану відкладену вибірку в Label Studio — тепер метрики рахуються на одних і тих самих даних.
Поріг впевненості підібрали за матрицею помилок: хибне переведення дорожче за уточнювальне питання, тому бот спочатку перепитує, а не кличе людину.
Що стало
Частка вірних розпізнавань на тій самій вибірці — 94%, хибні переведення на оператора — 7%. Частка діалогів, закритих без участі оператора, зросла з 58% до 88%.
Моніторинг повісили на частку низьковпевнених розпізнавань, розподіл намірів по днях і розходження з ручною розміткою: після правки формулювань в інтерфейсі зростання таких відповідей було видно того ж дня, і перенавчання зайняло години замість тижня скарг.
Чим відрізняється намір від сценарію діалогу
Намір — це те, що людина хоче отримати однією реплікою: повернути замовлення, дізнатися статус доставки, змінити адресу. Сценарій — послідовність кроків і станів діалогу, яка це бажання обслуговує: уточнення деталей, слоти, виклики внутрішніх систем, точка завершення.
Шари живуть за різними законами: намір визначається моделлю за текстом і оновлюється перенавчанням на розмітці, сценарій описаний графом переходів і оновлюється правкою вітки.
Якщо змішати їх в одній схемі, кожне нове формулювання клієнта перетворюється на окрему вітку графа. Таксономія розростається, кількість переходів зростає комбінаторно, і будь-яка правка формулювання вимагає регресії всього діалогу цілком.
Гірше інше: репліки зі змішаними темами — «хочу повернути замовлення і заразом змінити адресу» — нікуди покласти, бо вітка графа передбачає одну ціль на вході.
Між цими шарами потрібен шар маршрутизації. Він отримує репліку, рахує оцінку впевненості по кожному наміру з таксономії, застосовує поріг і правило вирішення конфліктів, і лише потім передає управління сценарію разом із поточним станом діалогу.
Сценарій при цьому нічого не знає про формулювання, а модель — про слоти та кроки. Правки з обох боків залишаються локальними, і регресія не роз'їжджається по всій схемі.
Уточнювальне питання — частина маршрутизації, а не окрема вітка. Коли два наміри близькі за впевненістю або в репліці змішані теми, роутер ставить уточнювальне питання і утримує діалог, поки не вибере одну ціль.
Так граф сценаріїв залишається лінійним і передбачуваним, а спірні випадки вирішуються в одному місці — там, де їм і належить вирішуватися.
Технічні сумніви перед стартом
Перед стартом замовник перевіряє не саму модель, а її експлуатацію: як переноситься поточна логіка, скільки потрібно даних і що буде з якістю через пів року. Нижче — п'ять питань, які найчастіше розбираємо на технічному обговоренні.
Що робити зі старими правилами?
Залишаємо їх окремим шаром: регулярки закривають жорсткі випадки на кшталт номерів замовлень, модель — вільні формулювання. Пріоритет при конфлікті задається явно і видно в логах.
Скільки фраз потрібно розмітити вручну?
Обсяг рахуємо від кількості інтентів і варіативності формулювань, а не «на око». Старт — кілька сотень фраз на клас, далі вибірка зростає за невпевненими передбаченнями.
Куди дівати нерозпізнані фрази?
У чергу розбору, а не в заглушку. Вводимо поріг впевненості та клас «не зрозумів»; частка таких звернень — метрика, що показує, де таксономії не вистачає.
Модель деградує з часом?
Так, якщо змінюється мова клієнтів. Стежимо за розподілом запитів і точністю на контрольній вибірці, при просіданні доучуємо на свіжих даних — у стеку на Rasa це регулярний цикл.
Як оновлюється таксономія?
Нові класи заводимо за статистикою нерозпізнаних фраз, зберігаючи сумісність назв. Старі не видаляємо різко — переводимо в архів, щоб звіти залишалися зіставними.
Обговоримо задачу та повернемося з оцінкою
Для оцінки потрібні не загальні побажання, а ваші дані: на першій розмові розбираємо, як бот обробляє запити зараз і де втрачає користувачів. Якщо є вивантаження листування та список інтеграцій, обсяг таксономії інтентів і склад робіт прикидаємо вже за підсумками розмови.
Що обговоримо і які ввідні знадобляться з вашого боку:
- Аудит поточного бота — який шар відповідає за розпізнавання: правила, регулярні вирази чи навчена модель, і на яких запитах він помиляється.
- Ввідні по діалогах — вивантаження логів за період, частка нерозпізнаних реплік, кілька сотень розмічених прикладів за ключовими сценаріями.
- Межі таксономії — перелік сценаріїв і бажана деталізація: великі інтенти чи підкласи з окремою реакцією на неясний ввід.
- Дані та доступи — канали (месенджери, веб-віджет, телефон), інтеграції з CRM або довідником, тестовий контур для прогону моделі.
- Мова та стиль — мови й діалекти, що обслуговуються, частка одруків і трансліту, чи потрібна обробка голосових повідомлень.
- Критерії приймання — цільова частка вірних спрацювань, допустимий рівень хибних, на якій вибірці рахуємо якість.
- Порядок старту — що робимо в першу чергу: замір поточної якості, розмітка, чернетка таксономії.
- План робіт — етапи, точки звірки, склад команди та порядок передачі моделі вашим інженерам.
Після розмови повернемося з оцінкою, планом робіт і переліком ризиків. Опишіть задачу та надішліть вивантаження логів — цього достатньо, щоб рухатися далі.
