Розробка AI-асистента з реалістичною мімікою та жестами

Чому віртуальний асистент ламає живий діалог

Розмова з віртуальним асистентом ламається не на сенсі реплік, а на стиках. Міміка відстає від мовлення, контекст не переживає перезапуск сесії, а відповідь запізнюється настільки, що людина встигає перепитати.

Неприродна міміка — наслідок порядку обчислень: артикуляцію та жести рахують окремим проходом, коли звукова доріжка вже готова. Обличчя живе у власному ритмі, око зчитує розсинхрон у першу секунду — і далі людина стежить за невідповідністю, а не за сенсом відповіді.

Затримка відповіді асистента складається з послідовних кроків: розпізнавання репліки, пошук у базі знань, генерація, синтез мовлення. Якщо рахувати їх по черзі, пауза зростає до кількох секунд: за цей час користувач перебиває, повторює питання або йде в інший канал.

Втрата контексту діалогу б'є найсильніше. Коли стан живе всередині однієї сесії, після перезапуску або переходу з чату в дзвінок віртуальний асистент заново запитує те, що вже знає.

У клієнтському сервісі це виглядає як кожне звернення з нуля: клієнт повторює історію, оператор усе одно підключається.

Розбираємо, як це закривається: шари мовлення, міміки та пошуку по знаннях розводимо за часом, щоб вони працювали паралельно, а контекст розмови виносимо в спільне сховище сесій.

Що дає віртуальний асистент із живою мімікою

Перший ефект віртуального асистента з мімікою рахують за часткою діалогів, закритих без оператора.

Коли жести та лицьова анімація збігаються з реплікою, людина не втрачає нитку розмови на уточненнях: сценарій доходить до кінця в одному вікні, а автоматизація першої лінії перестає бути формальним фільтром.

На типових зверненнях — запис, статус заявки, підбір умов — це ті розмови, які раніше йшли в чергу й закінчувалися відмовою. Звідси ж іде клас відмов «не дочекався відповіді» та «пішов, поки шукали інформацію в базі».

Час першої відповіді перестає залежати від завантаження зміни: асистент відповідає одразу в пік і вночі. Міміка закриває окремий сумнів — «зі мною говорить людина чи заготовка», — на якому діалог зазвичай обривається на третій репліці.

Конверсія діалогу в заявку зростає завдяки тому, що розмову ведуть до мети: уточнюють параметри, знімають заперечення, пропонують наступний крок. Оператору передається не «вітаю», а картка з історією звернення — він входить у діалог на етапі рішення, а не з'ясування.

Розвантаження операторів видно за структурою навантаження, а не за її загальним обсягом: рутина осідає на асистенті, людям залишаються нестандартні та чутливі випадки.

Перевіряти це варто до і після впровадження на одних метриках — частка завершених діалогів, час першої відповіді, частка звернень без оператора, перехід у заявку.

Режими роботи асистента: потік, запис, гібрид

Режим роботи асистента визначає, де витрачається час під час відповіді: на генерацію в реальному часі або на відтворення заздалегідь зібраної сцени.

У потоковому режимі асистент починає говорити, поки решту тексту ще доганяють, а синтез мовлення та лицьової анімації йдуть паралельно за спільною фонемною розміткою — тому губи не відстають від звуку, а перша відповідь приходить швидше.

Гібридна схема генерації тримає попередньо записані сцени для типових блоків — привітання, регламентні відповіді, повторювані уточнення — і перемикається на потік для всього іншого.

Тут і виникає питання сумісності: інтеграція з каналами зв'язку влаштована по-різному, і перемикання режимів має жити на стороні нашого сервісу, а не каналу — інакше голосовий шлюз і веб-віджет дадуть різну затримку та різну міміку на одну й ту саму репліку.

Як ми впроваджуємо асистента: етапи інженерної роботи

Впровадження віртуального асистента йде від розбору реальних звернень, а не від вибору зовнішності персонажа. Спочатку рахуємо, які запити повторюються і в якій частці випадків асистент закриє питання сам, а де зобов'язаний передати діалог людині.

Далі збираємо схему діалогів, підключаємо канали і тільки після цього виводимо асистента на живий трафік під метрики.

1. Аудит сценаріїв. Вивантажуємо історію звернень з телефонії, месенджерів і пошти, розмічаємо теми та рахуємо частки. На виході — перелік сценаріїв з оцінкою, скільки звернень вони покривають і де потрібна ескалація.
2. Проєктування схеми діалогів. Фіксуємо гілки, обов'язкові уточнення, умови передачі оператору та формулювання на випадок нерозуміння. Схема узгоджується до розробки, щоб правки не переробляли логіку.
3. Налаштування інтеграцій. Підключаємо канали зв'язку, базу знань і систему обліку: права доступу, обробка повторів при збої, поведінка при недоступності зовнішнього сервісу.
4. Міміка, жести та мовлення. Налаштовуємо поведінку в паузах, темп, синхронізацію артикуляції з голосом. Окремо перевіряємо довгі відповіді — саме там асистент найчастіше втрачає природність.
5. Тестові прогони. Прогоняємо типові та пограничні діалоги, ведемо регрес: після кожної правки сценарію переперевіряємо раніше закриті гілки.
6. Приймання на живих діалогах. Запускаємо на обмеженій частці трафіку й дивимося частку самостійних рішень, час відповіді та причини ескалацій.
7. Передача команді замовника. Віддаємо документацію, доступи та інструкцію з правки сценаріїв, щоб зміни вносилися без нас.

Що передаємо на руки: моделі, схеми, регламенти

Проєкт закінчується не демонстрацією, а передачею: у команди замовника залишається все, чим віртуальний асистент живе і змінюється далі.

Склад робіт фіксуємо заздалегідь — що саме переходить на руки, у якому вигляді та з якою документацією, щоб не з'ясовувати це вже на етапі запуску в роботу.

• Налаштована модель асистента із закріпленою робочою версією — і зрозумілою процедурою відкату до попередньої, якщо після правок якість просіла.
• Схеми діалогів: гілки та розвилки, межі теми, фрази-перехоплення та умови, за яких розмова переходить до живого оператора.
• Політики доступу: які ролі бачать історію діалогів, хто має право змінювати сценарії та міміку, де зберігаються записи і за яким правилом видаляються.
• Матриця міміки та жестів: яка емоція прив'язана до якої репліки, де асистент мовчить, як реагує на перебивання та паузу.
• Регламент експлуатації асистента: порядок оновлення сценаріїв, чищення логів, контроль затримки відклику, дії чергового при збої.
• Точки замірювання якості: частка діалогів, доведених до мети, частота відходів від теми, швидкість відповіді — із зазначенням, де ці числа збираються.
• Матеріали для навчання команди замовника: короткі розбори з екрана, де правити репліку без розробника, і чек-лист перед випуском нової версії.

Навчаємо команду замовника на цих самих артефактах: змінюємо репліку, проганяємо її за схемою, дивимося, як зсунулися метрики.

Окремо промовляємо, які правки безпечно робити самим, а які потребують узгодження — після цього типове оновлення сценарію займає хвилини й не тягне за собою розробку.

Кейс: асистент у клієнтському сервісі, до і після

До впровадження клієнтський сервіс тримався на операторах: звернення потрапляло в загальну чергу й чекало на відповідь, у пікові години час реакції розтягувався до кількох хвилин. Уночі та у вихідні лінія не працювала, частина питань ішла в пошту й там осідала. Кожен оператор заново збирав контекст — номер замовлення, історію, минулі обіцянки клієнту.

Змінили точку входу. Віртуальний асистент першим приймає звернення, розпізнає намір і веде діалог до рішення: статус замовлення, повернення, перенесення запису. Якщо питання виходить за сценарій, оператор отримує картку з історією та вже зібраними даними, а не порожній запит.

Метрики після: частка діалогів, закритих без оператора, — близько семи з десяти, час реакції на звернення скоротився з хвилин до кількох секунд, лінія працює цілодобово.

За галузевими оцінками Gartner, самообслуговування знімає з першої лінії близько третини типових звернень — у нас вийшло більше, бо асистент закриває не лише довідкові, а й транзакційні сценарії.

Окремо зняли клас відмов «звернення втрачено під час передачі між змінами та каналами». Картка діалогу живе незалежно від того, хто відповідає — асистент чи оператор, тому контекст не розсипається і клієнту не доводиться пояснювати все заново.

Побічний ефект того ж механізму: повторні звернення з уже вирішеного питання скоротилися приблизно вдвічі.

Чим лицьова анімація відрізняється від синтезу мовлення

Синтез мовлення відповідає за аудіоряд: він видає звук і разом із ним розмітку — межі фонем, тривалості, паузи та наголоси. Для голосового бота в навушниках цього достатньо, а віртуальному асистенту з обличчям потрібна ще артикуляція — і її на цьому етапі ніхто не розрахував.

Лицьова анімація будується саме на цій розмітці. Синхронізація губ і звуку — не «влучання в такт», а прив'язка артикуляції до фонем із точністю до кадру: рот закривається там, де закінчується звук, а не після.

Якщо міміку накладають поверх готового запису окремим проходом, розходження накопичується до кінця фрази, і обличчя починає «плисти» — на короткій репліці це непомітно, на розгорнутій відповіді впадає в око.

Керування жестами — третій шар, і з аудіо він не виводиться. Кивок, розворот корпусу або акцент рукою прив'язані до сенсу: вони стають на паузу, на зміну теми, на питання співрозмовника. Тому жест планується разом із текстом та інтонацією, а не домальовується після.

Різниця між «говорящою головою» та асистентом — у єдиному контурі генерації. Репліку розмічають цілком: де фраза, яка інтонація, куди стає жест, — і вже з однієї часової шкали збираються голос, міміка та рух.

Окремо ці шари не оцінюють: чистий синтез мовлення без міміки залишається подкастом, а лицьова анімація без керованих жестів — мультиплікацією.

Тому приймання робимо на стиках: чи збігається закриття рота із закінченням звуку, чи не роз'їжджається обличчя на довгій репліці, чи реагує жест на смисловий акцент.

Технічні сумніви: затримка, мови, навантаження, збої

Затримка відповіді складається не лише з генерації: до неї входять розпізнавання мовлення, синтез і передача аудіо. Орієнтир — вкладатися в природну паузу діалогу, щоб асистент не перебивав людину.

Це дає потокова віддача: репліка починається раніше, ніж готовий її повний текст, а міміка синхронізується за вже отриманим фрагментом.

Багатомовний асистент визначає мову за самою реплікою, а не за профілем, тому змішане мовлення всередині діалогу не ламає сценарій. Пікове навантаження та збої каналу — окремі режими, які проєктують заздалегідь.

Як асистент перемикається між мовами?

Перемикання йде за реплікою користувача, включно зі змішаними фразами. Мови фіксуються на старті проєкту: для кожної окремо перевіряються розпізнавання, відповідь та артикуляція.

Що відбувається при піковому навантаженні?

Асистент переходить у чергу: частина діалогів обслуговується паралельно, решта отримує зрозумілу затримку замість обриву. Поріг деградації задається заздалегідь.

Як поводиться асистент при збої каналу?

Резервний сценарій продовжує діалог в полегшеному режимі — голос і текст без відео. Після відновлення зв'язку розмова йде з того самого місця, користувач не починає заново.

Обговоримо задачу і повернемося з оцінкою та планом

Щоб повернутися з оцінкою та планом впровадження, нам потрібен мінімум контексту: для чого асистент — вітрина, підтримка, навчання — на яких сценаріях він має працювати і який рівень міміки та жестів ви вважаєте достатнім.

Додайте референси: як він виглядає, говорить і рухається, і хто на вашій стороні ухвалює рішення щодо зовнішності та тону.

Далі йдемо за етапами, і на кожному ви бачите результат, а не звіт:

• Розбір задачі та сценаріїв: збираємо список реплік, питань і глухих гілок, де асистент має коректно перевести розмову на людину.
• Оцінка та план впровадження: схема рішення, склад команди — техлід, інженер із синтезу мовлення та лицьової анімації, розробник інтеграцій — і строки етапів.
• Пілотний запуск асистента: один сценарій на одному майданчику, перевіряємо затримку відповіді та природність міміки на живих людях.
• Допрацювання за підсумками пілоту: правимо артикуляцію під голос, додаємо жести під ключові фрази, закриваємо провали в діалозі.
• Інтеграція та передача: підключення до ваших систем, правила оновлення контенту, документація та навчання тих, хто буде вести асистента далі.

Чим раніше розберемо сценарії, тим менше переробок на етапі анімації. Опишіть задачу — повернемося з оцінкою, схемою та строками етапів.