Голосовий ШІ для вхідних дзвінків: як вибрати рішення за затримкою та якістю

Голосовий ШІ «без затримки» не існує, тому вибирати треба за виміряною затримкою всієї розмови на ваших реальних дзвінках і за тим, наскільки природно система передає чергу реплік: коли починає говорити, коли замовкає, як реагує на перебивання. Цифра «час відповіді моделі — N мілісекунд» з демонстрації чи сайту постачальника описує лише один шар. Клієнт чує суму: визначення кінця його фрази, розпізнавання мови, рішення моделі, запит до CRM чи календаря, синтез голосу і телефонну мережу.

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

З чого складається пауза в голосовій розмові

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

1. Визначення кінця репліки. Система має вирішити, що людина договорила, а не просто зробила паузу, щоб подумати. Для цього використовують детектор голосової активності, аналіз тексту або окрему модель визначення черги. Більшість платформ чекають певний мінімальний час тиші, перш ніж закрити репліку. Наприклад, одна з платформ у типовій конфігурації використовує мінімальне очікування 0,5 секунди й максимальне — 3 секунди. Це приклад налаштувань, а не універсальна норма чи гарантія затримки.
2. Розпізнавання мови. Перетворення звуку на текст, якщо архітектура каскадна. Частина розпізнавання може відбуватися в потоці, поки людина ще говорить.
3. Рішення моделі. Мовна модель формує відповідь. Важливий не загальний час генерації, а час до перших слів, які можна озвучити.
4. Звернення до зовнішніх систем. Перевірити вільний слот у календарі, знайти клієнта в CRM, дізнатися статус замовлення. Цей крок часто додає більше часу, ніж сама модель, і повністю залежить від швидкості ваших систем.
5. Синтез мови. Перетворення тексту на голос; знову важливий час до першого звуку.
6. Телефонія і мережа. Передача аудіо між оператором зв'язку, платформою та серверами, де працюють моделі. Регіон серверів і маршрут дзвінка тут мають значення.

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

Які архітектури порівнювати

На ринку переважно зустрічаються два підходи.

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

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

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

Жоден із підходів не можна назвати завжди кращим. Realtime-модель може виграти на короткій розмові без інтеграцій і програти, коли кожна відповідь потребує запиту до CRM. Каскад може бути повільнішим, але краще розпізнавати назви вулиць і прізвища вашою мовою. Відповідь дає лише тест на ваших сценаріях.

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

Чому перебивання важливі

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

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

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

Є ще одна тонкість, яку легко пропустити: бот має пам'ятати, що клієнт справді почув. Якщо бот почав говорити «Ваш запис підтверджено на четвер о 15:00, а також…», і клієнт перебив на слові «четвер», то в історії розмови не повинно залишитися, ніби клієнт почув і час, і все, що мало бути далі. Інакше наступна відповідь спиратиметься на інформацію, якої людина не отримала.

Тест реального дзвінка

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

Запропонований протокол: 20 однакових сценаріїв

Сценарії. 20 сценаріїв, однакових для всіх кандидатів, наприклад:

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

Ускладнення. Для частини дзвінків додайте фоновий шум (вулиця, офіс, автомобіль) і паузу всередині репліки, коли клієнт замовкає, щоб подумати, але ще не договорив.

Умови. Реальна телефонія, а не браузерна демонстрація; регіон серверів, який ви плануєте використовувати; та мова чи мови, якими говорять ваші клієнти.

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

Повторення. 20 дзвінків на кандидата — замало для стабільного 95-го перцентиля. Кожен сценарій варто повторити кілька разів, різними голосами учасників тесту.

Таблиця фіксації для кожного дзвінка:

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

Метрики: що порівнювати

Час до першої чутної реакції. Від кінця мовлення клієнта до першого звуку бота, який чує абонент. Це головна метрика сприйнятої швидкості.

p50 і p95. p50 — медіана: половина відповідей швидша, половина повільніша. p95 — значення, повільніше за яке лише 5% відповідей. Середнє тут погано підходить: кілька дуже довгих пауз можуть ховатися за непоганим середнім, а клієнт запам'ятовує саме їх. Для p95 потрібно достатньо вимірювань: на двадцяти дзвінках це фактично одне-два найповільніші значення.

Хибні та пропущені перебивання. Скільки разів бот зупинився через шум і скільки разів продовжував говорити, коли клієнт намагався перебити.

Якість розпізнавання критичних даних. Імена, номери, дати, адреси. Помилка в номері телефону дорожча за помилку в слові привітання.

Успішне виконання задачі. Чи записаний клієнт, чи перенесено запис, чи з'єднано з потрібним співробітником.

Передача оператору. Скільки часу займає, чи доходить дзвінок, чи отримує оператор стислий опис розмови.

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

Вибір і бюджет

Ціна хвилини одного компонента не дорівнює вартості дзвінка. Типова структура витрат складається з кількох шарів:

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

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

Практично вартість типового дзвінка зручно рахувати як суму шарів для однієї й тієї самої розмови:

> вартість дзвінка = телефонія × тривалість + платформа × тривалість + розпізнавання (за хвилину або за обсяг) + модель (за обсяг вхідного та вихідного аудіо чи тексту) + синтез (за обсяг мовлення бота) + виклики інструментів × кількість + частка дзвінків, переданих оператору × вартість хвилини оператора × середня тривалість після передачі

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

Решта критеріїв вибору:

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

Що зробити на своєму процесі

1. Виберіть 15–20 типових сценаріїв вхідних дзвінків, включно зі з'єднанням зі співробітником і важкими для розпізнавання даними.
2. Задайте приймальні пороги до тесту: допустимі p50 і p95 часу до першої чутної реакції, частку виконаних задач, частку правильно розпізнаних номерів.
3. Проведіть однаковий тест для 2–3 кандидатів через реальну телефонію, з шумом і паузами, з CRM і без неї.
4. Вимірюйте з боку абонента і зберігайте записи для розбору.
5. Порахуйте вартість типового дзвінка за всіма шарами для кожного кандидата.
6. Оцініть налаштування пауз і перебивань окремо: інколи вони змінюють досвід більше, ніж зміна моделі.
7. Ухвалюйте рішення за сукупністю: якість, p95, інтеграції, вартість і підтримка, а не лише найнижча медіана.

Часті запитання