AI-чатбот психологічної підтримки: що ламається на проді
AI-чатбот психологічної підтримки майже завжди проходить демо і майже завжди розсипається на проді. Модель впевнено відповідає на ввічливі репліки, але на фразі на кшталт «я більше не бачу сенсу» видає техніку дихання замість протоколу кризового реагування.
Безпека відповідей асистента — це не ввічливий тон, а окремий шар: класифікатор ризику на вході, жорсткі правила на виході, заборона на діагностику та обіцянки, перевірка кожної репліки до надсилання користувачу.
Друга точка відмови — втрата контексту діалогу. Сесія закрилася на телефоні, людина повернулася з ноутбука, і асистент знайомиться заново: втрачається історія, тригери, вже пройдені вправи.
Пам'ять між сесіями вимагає явного зберігання стану з розмежуванням доступу, строком життя і правом на видалення — інакше діалоговий асистент підтримки або забуває все, або пам'ятає зайве.
Третє — відсутність ескалації до живого спеціаліста. Асистент не розпізнає момент, коли розмову час передавати людині, і продовжує утримувати користувача в діалозі.
Далі черга на черговій лінії зростає, чергові отримують розмиті звернення без історії листування, а частина людей іде мовчки.
Розбираємо, як це закривається: правило-маршрутизація за рівнем ризику, передача контексту разом з ескалацією, версіонування системних інструкцій з можливістю відкотити поведінку асистента та розбір логів на кожному релізі.
Що змінюється після впровадження: вимірювані ефекти
Ефект від впровадження асистента вимірюється не відчуттям «стало зручніше», а величинами, які знімаються з одного й того самого потоку звернень до і після запуску. Нижче — перевірювані показники, за якими ми звітуємо на прийманні.
- Частка автоматичних звернень — 60–70% типових діалогів (первинна стабілізація, дихальні та поведінкові вправи, щоденник настрою, нагадування про сесію) асистент закриває сам, без підключення психолога.
- Час першої відповіді — секунди замість хвилин очікування в черзі: частка діалогів, покинутих на першому повідомленні, падає кратно, бо людина отримує осмислену відповідь одразу, а не відсилання до розкладу.
- Пропущені кризові сигнали — нуль на контрольній вибірці: прямі та непрямі маркери розпізнаються на кожному повідомленні, і за протоколом, звіреним із рекомендаціями NICE, діалог негайно переходить до чергового спеціаліста разом з контактами екстреної служби.
- Навантаження на чергову лінію — у години пік черга не зростає: спеціалісти займаються складними випадками, а не розбором однотипних скарг і уточнень.
- Стійкість у пікові години — вечірні та нічні сплески звернень тримаються без розширення зміни, відповідь не деградує за швидкістю.
- Збереження контексту — під час передачі людині спеціаліст бачить історію діалогу та вже зібраний анамнез, повторне розпитування не потрібне.
Мета не в тому, щоб звести ескалації до нуля, а в тому, щоб жоден кризовий сигнал не залишився без реакції. Тому метрики знімаємо на розміченій вибірці діалогів, а не за агрегатами, і звіряємо їх з оцінкою самих психологів.
Режими роботи асистента та порівняння підходів
Режим роботи асистента — це не налаштування тону, а межі того, що модель має право сказати.
У психологічній підтримці помилка коштує дорожче, ніж у довідковому чаті: невдале формулювання в кризовому діалозі читається як знецінення, тому свободу генерації обмежують заздалегідь, а не після інциденту.
Інженерно вибір зводиться до чотирьох схем, і вони не виключають одна одну: маршрутизатор вирішує, куди йде запит — у сценарій, у генеративну відповідь за перевіреною базою або в гібрид із перевіркою.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Сценарії на правилах | Передбачувані маршрути: кризовий протокол, запис до спеціаліста, типові питання | Живе формулювання ламає гілку, нестандартний запит упирається в глухий кут |
| Генеративні відповіді за базою знань | Потрібна розгорнута розмова за перевіреним матеріалом: техніки КПТ, щоденник настрою, вправи | Модель може домислити деталь, потрібен фільтр і опора на джерело |
| Гібридна схема з перевіркою | Теми, де потрібні і емпатія, і контроль: самодопомога, розбір стану | Відповідь дорожча за часом, потрібен шар перевірки та журнал рішень |
| Асистент-навігатор | Завдання вузьке: підказати послугу, спеціаліста, формат роботи | Глибини розмови немає, за емоційного запиту потрібен перехід в інший режим |
На практиці режими комбінують: кризові повідомлення йдуть жорстким маршрутом, нейтральні — у генеративний шар із перевіркою відповіді, сумнівні асистент передає живому спеціалісту.
Частка діалогів, що потребують ручного розбору, падає, а відкат до сценарію залишається доступним у разі збою генеративного шару.
Етапи впровадження: від аудиту діалогів до передачі
Порядок робіт у такому проєкті фіксований: спочатку розбираємо те, що вже відбувається в діалогах, потім проєктуємо маршрути й правила, і лише після цього навчаємо модель і людей.
Причина проста — ціна помилки тут не «негарна відповідь», а пропущений кризовий сигнал, тому кожне рішення перевіряється на реальних зверненнях, а не на демо-сценаріях.
- Аудит звернень. Вивантажуємо історію діалогів і розмічаємо її: теми, частка кризових повідомлень, місця, де людина обривала розмову, випадки, що вимагали живого спеціаліста. На виході — карта ризиків і частота сценаріїв, за якою розставляємо пріоритети.
- Схема маршрутів діалогу. Збираємо переходи між станами: привітання, уточнення стану, вправи з КПТ, відмова від теми, повернення до розмови, передача людині. Окремо фіксуємо межі — що бот не обговорює і не коментує.
- Правила відповіді та ескалації. Прописуємо маркери кризових формулювань, обов'язкові фрази-мости, порядок передачі черговому спеціалісту та час, за який відповідь має бути отримана.
- Стрес-перевірка сценаріїв. Проганяємо кризові гілки, спроби відвести розмову, провокації та обриви. Перевіряємо, що бот не ставить діагнозів, не призначає препарати і не залишає людину в глухому куті без варіанта продовжити.
- Приватність і доступи. Визначаємо, що зберігаємо, що знеособлюємо, скільки зберігаємо і хто бачить розшифрування. Це впливає на схему маршрутів, тому вирішується до запуску, а не після.
- Навчання команди. Передаємо операторам регламент чергування, розбір ескалацій і правила ведення складних діалогів.
- Передача в експлуатацію. Віддаємо документацію за маршрутами, доступи та метрики: частка ескалацій, час реакції, частка доведених до кінця діалогів — і порядок оновлення сценаріїв.
Що передаємо замовнику: конфігурації, схеми, регламенти
Матеріальний результат — не доступ до панелі керування, а набір артефактів, за якими ваша команда експлуатує чатбот і розвиває його без нас. Усе лежить у вашому контурі й передається разом із правами та журналами перевірок.
- Налаштовані сценарії та правила відповіді: гілки діалогу, пороги, за яких бот уточнює або переходить на людину, заготовки для типових станів.
- Карта маршрутів ескалації: які сигнали (пряме висловлювання про ризик, різка зміна тону, тривале мовчання) переводять діалог на чергового і що відбувається, якщо той не відповідає у вікні.
- Політики доступу до історії діалогів: ролі, кому видно розшифрування, що зберігається знеособленим, як фіксується кожне відкриття картки.
- Регламент роботи чергової лінії: вікна чергування, передача зміни, час реакції, порядок дій у разі сплеску звернень.
- Інструкції для спеціалістів: як читати зведення за діалогом, що не можна обіцяти, куди передавати випадки поза своєю компетенцією.
- Документація щодо чатбота: схема сервісів, опис моделей та їхніх обмежень, порядок оновлення і повернення до попередньої версії.
- Звіт про перевірки: тестові діалоги, зокрема кризові, частка пройдених шляхів і результат повторного прогону після змін.
Кейс: лінія психологічної підтримки під навантаженням
Лінія психологічної підтримки починалася як група операторів і чергового психолога.
У пікові години — вечірні та після публічних інфоприводів — черга звернень сягала кількох десятків осіб, середній час до першої відповіді становив 8-12 хвилин, близько чверті діалогів закривалися без відповіді взагалі.
Уночі лінія не працювала, і людина в гострому стані залишалася без реакції до ранку — цей клас відмов і потрібно було прибрати.
Що змінили в маршрутах і правилах відповіді
На вході поставили чат-бота, який веде первинний діалог: уточнює стан, розпізнає маркери кризи й одразу передає звернення черговому спеціалісту разом із контекстом.
Типові запити — тривожність, безсоння, вигорання — бот веде сам за технікою КПТ-вправ: дихання, щоденник думок, розбір тригера.
Правила ескалації описали як код, а не як інструкцію: набір формулювань, різка зміна тону, згадки про самопошкодження — будь-який сигнал піднімає діалог у пріоритетну чергу за секунди.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Час до першої відповіді | 8-12 хв | до 40 с |
| Звернення без відповіді | ~25% | менше 2% |
| Покриття нічних годин | немає | цілодобово |
| Кризові діалоги без реакції | поодинокі, але були | нуль |
Клас відмов «людина в гострому стані залишилася без відповіді» прибрано повністю: маршрут більше не залежить від того, чи вільний оператор. До 70% типових звернень закриває бот, а спеціаліст підключається там, де справді потрібна людина.
Що робити, якщо чатбот уже розгорнуто на готовій платформі?
Розгорнутий асистент майже ніколи не буває непотрібним — проблема в нерівності: на одних темах він відповідає доречно, на інших переходить у загальні поради або обриває діалог.
Починаємо з аудиту поточного асистента: проганяємо через нього корпус реальних звернень і розмічаємо, де він втрачає контекст, де дає небезпечну рекомендацію, а де не розпізнає кризову репліку. Без цієї розмітки доопрацювання перетворюється на вгадування.
Поверх працюючої платформи добудовується більше, ніж здається. Шар системних інструкцій задає рамку: асистент тримає роль, не ставить діагнозів і повертає розмову до переживання, а не до порад.
Окремим шаром ідуть кризові тригери — за ключовими формулюваннями діалог одразу переводиться в протокол безпеки. Добудова ескалації підключається до поточного каналу: асистент збирає контекст листування і передає його спеціалісту, щоб людина не починала з нуля.
Перенесення сценаріїв робимо в новий шар, а не через переписування ядра: робоча логіка залишається, поверх лягає структура терапевтичної сесії — прояснення, перевірка автоматичної думки, домовленість про крок до наступної розмови.
Повна переробка виправдана, коли платформа не дає керувати системними інструкціями та історією діалогу або не дозволяє зберігати чутливі дані так, як вимагає замовник.
Тоді міняємо ядро, але зібрані сценарії та розмітку переносимо — вони залишаються активом і скорочують строк запуску.
Технічні сумніви: безпека, емпатія, межі відповідей
Сумніви інженерів і керівників напряму зазвичай одні й ті самі: коректність у кризових темах, персональні дані в діалогах, передбачуваність відповідей і відповідальність за помилку. Відповідаємо по суті, без обіцянок «повністю безпечної моделі».
Базовий принцип: там, де ціна помилки висока, асистент не вигадує, а вибирає із заздалегідь перевіреного набору формулювань. Вільна генерація залишається в підтримувальних репліках, а межі відповідей задані системною інструкцією та фільтрами, а не побажаннями в описі.
Як асистент поводиться в кризових темах?
Маркери ризику — згадки про самопошкодження, безнадію, погрози — розпізнаються до формування відповіді. Діалог переходить в окремий сценарій із фіксованими формулюваннями, контактами екстреної допомоги та пропозицією живого спеціаліста.
Вільна генерація в цьому режимі вимикається: передбачувана суха репліка краща за гарну й неправильну.
Що відбувається з персональними даними в діалогах?
Дані мінімізуються на вході: імена, телефони, адреси вирізаються до обробки, листування зберігається знеособлено й з обмеженим строком життя. Доступ до необроблених логів — за ролями та з журналом звернень; за замовчуванням інженер бачить лише знеособлену вибірку. Видалення на запит користувача відпрацьовує по всій історії, включно з резервними копіями.
Як перевіряються відповіді перед надсиланням?
Два бар'єри: правила відсікають заборонені теми та медичні призначення, класифікатор оцінює тон і ризик. За низької впевненості вмикається м'яка гілка — уточнювальне питання або пропозиція допомоги спеціаліста. Рахуємо частку відповідей, прийнятих без переписування, — це і є вимірювана передбачуваність.
Хто відповідає за помилку у відповіді?
Межу продукту зафіксовано: асистент не ставить діагнози і не призначає препарати. Наша зона — механізми контролю: фільтри, логування, відкат сценарію та розбір інциденту в узгоджений строк.
Кожен розібраний випадок потрапляє до набору регресійних перевірок, щоб те саме формулювання не пройшло повторно.
Обговоримо задачу: з чого починається робота
Щоб повернутися з оцінкою та планом робіт, а не загальними словами, нам потрібно зрозуміти, як влаштована ваша лінія підтримки сьогодні.
Розкажіть, звідки надходять звернення, хто і за якими правилами їх розбирає, які теми вважаються чутливими і де обов'язковий перехід на живого спеціаліста.
Що варто обговорити на першій розмові:
- Тематику звернень та їхні частки: тривожність, вигорання, стосунки, кризові стани — що асистент бере на себе, а що одразу передає людині.
- Вимоги до асистента: тон, межі відповідей, прийнятна емпатія, опора на протоколи когнітивно-поведінкової терапії в діалозі.
- Правила безпеки: як розпізнається ризик самопошкодження, що асистент робить у цей момент, кому і як швидко передає діалог.
- Канали та системи: чат на сайті, месенджери, облік звернень, графік чергових спеціалістів — куди вбудовується асистент і звідки бере контекст.
- Регламент та обмеження: заборонені теми й формулювання, робота з персональними даними, журнал діалогів і строки зберігання.
- Критерії приймання: які сценарії вважаємо відпрацьованими і хто з боку сервісу підтверджує якість відповідей.
У відповідь ми повертаємося з планом робіт: етапи, ролі, строки впровадження, точки контролю та письмово зафіксовані вимоги до асистента. Перший запуск робимо пілотом на частині звернень — одна тема або одна зміна, з щоденним розбором діалогів і правками до розширення. Опишіть задачу — повернемося з оцінкою та планом.
