Чому діалоговий менеджмент розсипається на живих сценаріях
Найчастіше сценарій проходить демонстрацію й розвалюється на третьому-четвертому повідомленні живої людини. Причина не в моделі, а в тому, що стан розмови ніде не зберігається окремо: наступна репліка виводиться з останньої фрази, а не з усієї історії.
Щойно людина відповідає не за шаблоном — «так, але краще в середу» — гілка перестає збігатися з реальністю.
Звідси втрата контексту діалогу: бот плутає відповіді, повторно запитує вже заповнені поля й відкочується на два кроки назад. Користувач читає це як «мене не чують» і йде, а в логах залишається формально успішний діалог без результату.
Необроблені звернення — друга точка відмови. Намір, якого немає в дереві розгалужень, обриває розмову: бот мовчить або повторює меню. Список таких фраз зростає швидше за сценарій, і без окремого шару розпізнавання кожне нове звернення знову впирається в глухий кут.
Третє — передача оператору. Діалог обривається на півслові: співробітник не отримує ні історію реплік, ні заповнені поля, і людина знову пояснює завдання. На виході — втрачений клієнт або ручне перенесення даних із чату в облікову систему.
Це не помилки окремих реплік, а відсутність керуючого шару, який утримує стан, розпізнає намір і передає контекст цілком. Розбираємо, як це закривається.
Ефект у метриках: частка автовідповідей, передача оператору, відмови
Вважаємо ефект за наскрізною воронкою звернення, а не за логами бота: частка автовідповідей — це звернення, де останнє повідомлення належить боту й передачі оператору не було протягом вікна очікування.
Метрика рухома: зсунули поріг упевненості — автовідповідей менше, але й помилкових спрацювань менше. Тому пороги фіксуємо разом із замовником до запуску й змінюємо лише за накопиченою статистикою.
Час відповіді бота на піках не зростає, бо маршрут за намірами детермінований: типові сценарії закриваються правилами й слотами, а мовна модель підключається лише на гілках, де шаблонної відповіді немає.
Плюс кеш частих формулювань і явна деградація: якщо зовнішній сервіс не відповів, бот не мовчить, а пропонує повтор, альтернативний крок або передачу оператору.
Класи відмов рахуємо окремо. Не розпізнано намір — лікується розміткою й уточнювальними питаннями в гілці. Намір зрозуміло, але немає даних у системі — виправляється інтеграцією та зрозумілим повідомленням про причину.
Спрацювала політика передачі за ризиком або емоцією — це не відмова, а планове спрацювання, його частку тримаємо керованою. Збій зв’язку — повторні спроби й деградація без втрати контексту діалогу.
Підсумок видно у зниженні навантаження на підтримку: падає не просто число звернень до оператора, а змінюється їхній склад — залишаються складні, спірні та емоційні.
Політики розгалуження описуємо декларативно, як правила й сценарії в Rasa, тому межу передачі можна переставити без переписування діалогу.
Три режими збирання логіки відповідей та їхні обмеження
Режими різняться тим, де ухвалюється рішення про наступну репліку: в описаних правилах, у пошуку по базі знань або в генеративній моделі. Нижче — де кожен упирається в стелю й у якому випадку його змінюють на інший.
Сценарний бот передбачуваний: відповідь однакова в будь-який момент, його легко перевірити й пояснити, але зі зростанням числа тем комбінація гілок зростає швидше за список питань, а неописаний шлях перетворюється на глухий кут.
Пошук по базі знань закриває довгий хвіст формулювань, відповідаючи за змістом, але не веде багатокроковий діалог. Генеративні відповіді звучать природно, однак без опори на знайдений фрагмент домислюють і дають різний результат на одне й те саме питання.
| Режим | Коли підходить | Де упирається |
|---|---|---|
| Сценарний бот | Повторювані операції: заявка, статус, запис — де важливе однакове формулювання | Комбінацій гілок більше, ніж питань; незаданий шлях — глухий кут |
| Пошук по базі знань | Довідка за документами, інструкціями, умовами — довгий хвіст формулювань | Не веде діалог, легко втрачає контекст попередніх реплік |
| Генеративні відповіді | Вільна мова, перефразування, уточнення | Без джерела домислює, результат не повторюється від запуску до запуску |
| Гібридна схема | Різні типи запитів: операції, довідка й вільний діалог разом | Потрібні маршрутизація та журнал запитів, щоб налагоджувати межі режимів |
Робоча конфігурація в більшості проєктів — гібридна: запит проходить маршрутизацію й потрапляє у свій режим, критичні операції залишаються на сценарії. Так довідка не ламає облікову логіку, а генерація відповідає лише там, де під нею є перевірене джерело.
Етапи впровадження: від аудиту сценаріїв до передачі в експлуатацію
Діалоговий менеджмент погано піддається «доналаштуванню» на живому боті: правила переходів розповзаються, а вузьке місце стає видно лише на потоці. Тому працюємо етапами, і кожен завершується артефактом, який можна перевірити до наступного кроку.
Порядок робіт
- Аудит сценаріїв і поточних звернень — вивантажуємо історію діалогів, рахуємо частку обривів на кожному кроці та теми, які найчастіше йдуть оператору. На виході — карта проблемних переходів.
- Розмітка намірів — збираємо корпус реальних фраз, позначаємо інтенти, слоти, відмови, питання поза сценарієм і друкарські помилки. Узгоджена розмітка стає еталоном для перевірки.
- Проєктування схеми діалогу — граф станів, обов’язкові уточнення, правила перепитування, ескалація на оператора та запасні гілки. Схему фіксуємо до налаштування.
- Налаштування й збирання — правила переходів, формулювання реплік, пороги впевненості, обмеження довжини діалогу. Усе, що змінюється без переписування коду, виносимо в конфігурацію.
- Тестування бота — прогін еталонної розмітки, діалоги «наосліп» силами інженерів, перевірка відмов і тупикових гілок. Помилки ловимо до бойового запуску.
- Перевірка на бойовому трафіку — запуск на частину звернень за паралельної роботи оператора. Дивимося частку діалогів, закритих без людини, і число перепитувань.
- Введення в експлуатацію та передача — схема діалогу, регламент правки сценаріїв, панелі моніторингу й навчання вашої команди. Далі зміни вносите самі.
Комплект постачання: конфігурації, схеми діалогів і регламенти
Працююча модель — не єдине, що залишається в замовника. Діалоговий менеджмент живе довше за першу версію бота: змінюються теми звернень, додаються послуги, уточнюються правила ескалації.
Тому комплект постачання збираємо так, щоб гілки діалогу правилися без розбору чужого коду й без звернення до нас за кожним формулюванням.
- Схема діалогу як граф станів: гілки, переходи, точки повернення, поведінка на нерозпізнану репліку — за нею видно, куди вбудовувати новий сценарій.
- Набір намірів і сутностей із прикладами реплік — він же слугує регресійним набором: після правок проганяємо й бачимо, чи не деградували сусідні гілки.
- Політики передачі оператору: умови ескалації — скільки непорозумінь підряд, ключові слова, теми поза компетенцією — склад контексту, що передається, і правила повернення в бота.
- Налаштування журналювання: спрацьований намір, упевненість розпізнавання, факт ескалації, ідентифікатор сесії; форма вивантаження для розбору.
- Документація щодо бота: карта інтеграцій, поведінка за недоступності зовнішніх систем, точки відмови та дії за кожної з них.
- Регламент правок: хто змінює гілки, які перевірки обов’язкові перед викладенням, як відкочується версія й ведеться історія змін.
- Інструкція для операторів і чек-ліст приймання — щоб експлуатація не трималася на одній людині.
Кейс: менше передач оператору та стабільні відповіді на піках
Що було
Бот збирався під один сценарій і розбирав репліку за ключовими словами й регулярками — на перефразування «а якщо я хочу повернути» він відповідав не тією гілкою.
Контекст жив усередині одного кроку: слоти, названі на початку розмови, до третьої репліки губилися, і бот знову запитував номер замовлення.
Підсумок — 41% діалогів закінчувалися передачею людині, очікування оператора в пік сягало семи хвилин, а потік звернень до підтримки зростав швидше за число діалогів.
Що змінили
Ядро діалогового менеджменту зібрали на Rasa і перевели на явну модель: інтенти з порогом упевненості, слоти з обов’язковістю та джерелом заповнення, стани сценарію, що зберігаються окремо від тексту репліки. Розгалуження описано декларативно, тому нова тема додається налаштуванням, а не патчем коду.
Правило ескалації стало частиною сценарію: три нерозпізнані репліки підряд, прямий запит на людину або критичний інтент — і діалог передається з історією та заповненими слотами, оператор не перепитує заново.
Що стало
Частка самостійних відповідей зросла до 79%, очікування в пік скоротилося до 40 секунд, число передач оператору зменшилося вдвічі за зростаючого трафіку.
Кожен крок пишеться в лог разом з інтентом і впевненістю, а набір реальних звернень став регресійним тестом: перед викладенням видно, які сценарії просіли й де поріг упевненості спрацьовує запізно.
Чим діалоговий менеджмент відрізняється від сценарію бота
Сценарій — це дерево переходів: стан бота дорівнює номеру кроку, а репліка користувача лише вибирає наступну гілку. Поки людина йде очікуваним шляхом, усе передбачувано.
Але якщо вона змінює тему, ставить зустрічне питання або повертається на два кроки назад, дерево ламається — бот повторює меню або заводить у глухий кут.
Діалоговий менеджмент замість номера кроку утримує модель стану розмови. У ній окремо живуть розпізнані наміри, заповнені поля, стек незакритих тем і ознака, що користувача не зрозуміли.
Репліка не перемикає бота на гілку, а оновлює цю модель — тому зміна теми й повернення до відкладеного питання всередині однієї сесії не потребують нових гілок у схемі.
Керування контекстом — це набір правил, а не пам’ять моделі. Ми задаємо, скільки реплік зберігати, які значення вважати підтвердженими, коли поставити уточнення й коли мовчки прийняти відповідь.
Окрема політика відповідає за ескалацію: явне прохання покликати людину, два непорозуміння підряд, негатив або вихід за межі теми — діалог переходить оператору разом з історією та вже зібраними даними.
Сценарій при цьому не викидається. Гілки, де помилка неприпустима — оплата, ідентифікація, підтвердження заявки — залишаються жорстко детермінованими, а діалоговий шар працює навколо них.
Такий гібрид дає свободу в розмові, не втрачаючи контролю на критичних кроках, у будь-якому каналі — від віджета на сайті до Telegram.
Технічні сумніви: контекст, доступи, відкат змін
Глибина контексту — параметр конфігурації, а не властивість моделі.
Ми тримаємо останні репліки цілком, а раніші згортаємо в зведення, яке оновлюється після кожного блоку ходів: бот пам’ятає суть звернення й домовленості, але не тягне в кожен запит усю переписку — час відповіді залишається передбачуваним.
Доступи видаємо точково: сценарій отримує лише ті операції внутрішніх систем, які йому справді потрібні, з обмеженням за статусом звернення та роллю оператора, усе інше запитує людина. Оновлення викладаємо ревізіями, тому вчорашня робоча версія залишається під рукою.
Наскільки глибоко бот пам’ятає діалог?
Вікно контексту налаштовується: скільки останніх реплік передається дослівно й після якого порогу історія згортається в зведення. Зведення зберігається окремо від журналу переписки, тому довга розмова не роздуває запит і не знижує швидкість відповіді.
Якщо клієнт повертається через тиждень, піднімаємо його картку за ідентифікатором, а не всю минулу переписку.
Як бот отримує доступ до внутрішніх систем?
Через окремий сервісний шар з обмеженим набором операцій: прочитати статус заявки, додати коментар, створити звернення. Облікові дані лежать у сховищі секретів і боту недоступні, а кожен виклик фіксується в журналі з ідентифікатором діалогу. Доступ відкликається в будь-який момент, без зупинки бота.
Що робити, якщо нова версія сценарію спрацює гірше?
Сценарії версіонуються як код: кожна ревізія — окремий артефакт, інструкції моделі змінюються незалежно від логіки. Випускаємо спочатку на малу частку трафіку й звіряємо метрики з попередньою версією.
Якщо частка діалогів, де знадобився оператор, зростає — перемикаємося на попередню ревізію, це займає хвилини й не потребує перезбирання.
Як обробляються персональні дані?
У журналах маскуємо номери, адреси та реквізити, сирі записи живуть обмежений строк і потім видаляються. Для доопрацювання сценаріїв використовуємо знеособлені вибірки.
Якщо за вимогами замовника дані не повинні залишати його контур — розгортаємо обробку всередині, доступ до журналів видаємо за ролями.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб розбір задачі зайняв один прохід, а не серію уточнювальних листів, корисно одразу надіслати вхідні дані — у тому вигляді, у якому вони вже є. Ідеально оформлені документи не потрібні, вистачить робочих матеріалів.
- Сценарії: що бот закриває сам, а де зобов’язаний передати діалог оператору.
- Реальні звернення: 30–50 діалогів із поточного каналу підтримки в початковому вигляді — за ними видно живі формулювання, а не вигадані.
- Системи-джерела: CRM, база знань, система розрахунків, запис — що доступно програмно, а що доведеться віддавати вивантаженням.
- Правила ескалації: у який момент і до кого переходить діалог, що оператор бачить у картці.
- Канали й обмеження: месенджери, чат на сайті, голос; вимоги до швидкості відповіді та достовірності даних.
- Критерії успіху: частка діалогів, закритих без людини, число уточнювальних питань на діалог, частка помилок у відповідях.
Із цього збираємо оцінку проєкту та план робіт: етапи, склад робіт за кожним, залежності від вашої сторони й точки, де показуємо проміжний результат.
Діалоговий менеджмент проєктуємо до написання коду — схема переходів і правила розгалуження узгоджуються заздалегідь, тому дорогі переробки на пізніх етапах не виникають.
Опишіть задачу — повернемося з оцінкою та планом робіт.
