Голосова взаємодія в реальному часі пропонує принципово новий спосіб взаємодії з застосунками на основі ШІ. Замість введення тексту чи навігації меню користувачі говорять природно й отримують відповіді з живим темпом та емоційним контекстом.
Щоб створити якісну голосову взаємодію в реальному часі, потрібно координувати живу розмову. Саме тут починається справжня робота над продуктом. Взаємодія в реальному часі миттєва й природна, а створити застосунок, здатний постійно підтримувати таку якість, — окреме інженерне завдання.
Модель — лише одна частина системи. Робочим застосункам потрібні орієнтована на голос інфраструктура, чітке розмежування плину розмови й глибшого міркування та подієве керування сеансом у процесі його перебігу.
Захисні механізми й оцінювання залишаються джерелом значної частини труднощів. Перевірки безпеки мають не відставати від живого аудіо, а мінливі характеристики розмови — своєчасність, тон і плинність — складно оцінювати традиційними методами.
Більшість сучасних застосунків ШІ з голосовими функціями досі працюють однаково: мовлення перетворюється на текст, модель його опрацьовує, а синтезований голос озвучує відповідь. Це працює. Але взаємодія й відчувається відповідно: як технологічний конвеєр, а не розмова.
Голосова взаємодія в реальному часі це змінює. Користувачі говорять природно й отримують відповіді з відповідним темпом, тоном та емоційним контекстом. Така взаємодія швидша й плавніша, ніж у ланцюжках перетворення мовлення на текст, і більше нагадує розмову з людиною, ніж керування системою.
Ми побачили, що це відкриває нові можливості для продуктів, які важко реалізувати за допомогою конвеєрних архітектур. Голосові агенти реального часу можуть обслуговувати клієнтів у ситуаціях, де інакше знадобилися б довгі, незручні меню IVR і переведення між відділами. Вони можуть навчати, допомагати з адаптацією, покращувати доступність у різних каналах і не тільки. Голос у реальному часі варто впроваджувати скрізь, де усна розмова має перевагу над текстовими інтерфейсами.
Більшість застосунків із голосовими функціями використовують так званий «ланцюжковий підхід»: конвеєр з окремих моделей для перетворення мовлення на текст, мовної обробки й перетворення тексту на мовлення. Ці системи добре працюють і відкривають широкий спектр можливостей, але аудіо використовується лише на початку та наприкінці процесу. Окремі етапи створюють вимушену структуру й затримку, тому взаємодія здається менш природною, ніж справжня розмова.
Голосова взаємодія в реальному часі використовує інший підхід. Замість окремих моделей для слухання, мислення й мовлення одна модель виконує всі три функції нативно, одночасно розуміючи та генеруючи аудіо й транскрипти. Вхідні й вихідні дані передаються безперервно, тому система відповідає з природним темпом і належною емоційністю, зберігаючи реалістичний ритм живої розмови. У результаті своєчасність, тон і обробка переривань стають центральними складовими продукту.
Взаємодія в реальному часі приваблює своєю миттєвістю, але її складність у тому, що ніхто не чекає своєї черги. Для її підтримки недостатньо швидко й точно генерувати аудіо. Складність полягає в усьому іншому. Модель працює в межах живого сеансу, тому все довкола неї — стан, безпека, оркестрація та керування — має працювати паралельно з розмовою й у тому самому темпі.
У голосовому застосунку з ланцюжковою обробкою почергові репліки створюють чітку структуру діалогу. Користувач говорить, система відповідає, а потім починається наступний етап. Голосова взаємодія в реальному часі не має такої структури. Обидві сторони можуть говорити одночасно або ж мовчати. Користувач може перервати відповідь або поставити додаткове запитання, перш ніж система завершить говорити. Переривання перестають бути винятковими ситуаціями й стають одним з основних сценаріїв взаємодії.
Саме тому застосунки реального часу передусім потребують координації, а система довкола моделі важить не менше за саму модель.
Щоб підтримувати таку систему у великих масштабах, її слід проєктувати спеціально для живої взаємодії. Для цього потрібні три складові, які постійно зустрічаються в системах, доведених до робочого середовища.
Голосові сеанси реального часу мають підтримувати потокове аудіо, черговість реплік, переривання, життєвий цикл з’єднання та виконання агента. Залежно від середовища розгортання застосунку може також знадобитися підтримка телефонії. Це базові складові взаємодії, від яких безпосередньо залежить масштабування застосунку.
Перша вимога — орієнтований на голос рівень керування сеансом. Фреймворки комунікації в реальному часі (RTC) дають застосунку середовище для керування учасниками, потокового передавання аудіо та запуску агентів у телефонній інфраструктурі. З нашого досвіду особливо корисним є Livekit: він пропонує стек WebRTC із низькою затримкою, якісним шумозаглушенням і зменшенням джитеру без додаткового налаштування. Самостійна реалізація цього рівня рідко виправдовує додаткову складність.
Мультиагентна архітектура для голосу в реальному часі передусім передбачає розмежування відповідальності.
Голосові моделі реального часу дуже ефективні для потокової передачі розмовного аудіо, але не оптимізовані для глибшого міркування. Такі завдання, як виклик інструментів, пошук даних або структуроване ухвалення рішень, краще доручати іншій моделі.
Корисний шаблон — архітектура «відповідач — аналітик».
Відповідач — це голосовий агент реального часу. Він відповідає за підтримання живої взаємодії: слухає, говорить, обробляє переривання та зберігає плинність розмови. У його основі — швидкість реагування, зрозумілість та емоційна послідовність.
Аналітик — це окремий агент на основі моделі, здатної до міркування. Він працює поза основним каналом і виконує такі завдання, як використання інструментів, пошук даних і планування. Відповідач може за потреби звернутися до нього й використати результати в подальшій розмові.
У деяких випадках аналітик може самостійно виконувати міркування. В інших — виконувати роль оркестратора для групи спеціалізованих агентів. Головна ідея полягає в тому, що цю роботу виконує модель, краще пристосована до завдань із міркування.
Перевага проста: відповідач залишається швидким, природним у розмові та зосередженим, а аналітик виконує роботу, що потребує більше часу, контексту чи структури.
Майбутній розвиток передових моделей може зробити цей підхід непотрібним, але наразі, за нашими спостереженнями, цей шаблон стабільно перевершує підходи з одним агентом.
Голосові системи реального часу природно створюють безперервний потік подій.
Користувачі починають говорити, роблять паузи й перебивають. Транскрипти оновлюються поступово. Відповіді генеруються й передаються потоково. Надходять результати із зовнішніх джерел. Умови в межах сеансу змінюються. Усе це можна фіксувати, передавати й зберігати як ключові події, що сформували поточний стан конкретної розмови. Без них ми втрачаємо можливість здійснювати точкові й цілеспрямовані втручання.
Подієвий підхід дає чіткий спосіб керувати цим процесом. Система фіксує події в момент їх виникнення, оновлює стан сеансу й запускає відповідні подальші дії.
Легкі обробники підтримують швидкодію тракту реального часу, а складніші завдання — оновлення автоматів станів, журналювання метрик, видалення конфіденційних даних, оновлення баз даних і завершення сеансу — запускаються асинхронно у фоновому режимі.
З додаванням функцій кількість таких фонових завдань може швидко зростати. Навіть невеликі зміни продукту можуть створювати нові потоки подій і залежності. Добре структурована архітектура паралельного виконання важлива, щоб зі зміною системи вона залишалася зрозумілою та надійною.
Цей подієвий підхід також допомагає вирішувати критично важливе продуктове завдання — формувати саму розмову. Аудіосистема реального часу не лише генерує відповіді: вона керує темпом, обробляє тишу й переривання та визначає, як і коли завершити сеанс. Ці моделі поведінки є частиною взаємодії з продуктом, тому їх варто проєктувати свідомо.
Коли стан сеансу змінюється залежно від кількості реплік, тривалості чи поведінки користувача, система може надавати відповідачу цільові вказівки. Наприклад, вона може підказати агенту допомогти користувачеві завершити розмову з наближенням ліміту сеансу або надати уточнення, якщо взаємодія зайшла в глухий кут. Такі втручання незначні, але завдяки їм взаємодія сприймається продуманою та цілісною.
Добре спроєктована система чітко відстежує стан сеансу: хто говорить, як розвивається розмова та які умови вже виконано. Цей стан, який безперервно оновлюється потоком подій, дає змогу надати належні вказівки в потрібний момент.
У користувацьких ШІ-системах захисні механізми обов’язкові. Вони забезпечують безпеку, відповідність вимогам, запобігання зловживанням і надійність. У системі з почерговою взаємодією є очевидні моменти для їх запуску: після репліки користувача або перед надсиланням відповіді.
Голосова взаємодія в реальному часі усуває більшість цих зручних контрольних точок. Вхідні дані від користувача надходять безперервно. Виведення аудіо вже може тривати в потоковому режимі. Готові транскрипти часто відстають від звуку. Якщо система чекатиме на повні повідомлення, перш ніж перевіряти їх, розмова перестане здаватися живою.
Натомість захисні механізми мають працювати паралельно з розмовою, зберігаючи природність взаємодії. Один із підходів — передавати аудіо в буфер, водночас асинхронно оцінюючи доступні фрагменти транскрипту. Це дає змогу виконувати перевірки безпеки майже в реальному часі, не блокуючи взаємодію.
Коли спрацьовує захисний механізм, система може відреагувати з урахуванням контексту: спрямувати розмову в інше русло, скоригувати поведінку або, за потреби, завершити сеанс. Так захисні механізми працюють у реальному часі, не погіршуючи взаємодію з користувачем.
Найскладніше в оцінюванні розмовної системи реального часу те, що деякі з найважливіших характеристик — своєчасність, переривання, плинність і тон — неможливо охопити тестуванням лише за транскриптами.
Стандартні процеси оцінювання подають системі реалістичні сценарії, спостерігають за результатами й виставляють оцінки. Для текстових систем або ланцюжків обробки аудіо все просто: подати текст і перевірити текстову відповідь. У режимі реального часу на вхід надходить живе аудіо, а найважливіша динаміка розмови проявляється в часі: як агент обробляє одночасне мовлення, наскільки швидко відповідає та як відновлює розмову після переривання.
Ручне тестування — безпосередня розмова з агентом — охоплює ці характеристики, але погано масштабується. Автоматизація на основі транскриптів масштабується, але втрачає сигнали, що відрізняють якісну взаємодію в реальному часі від неякісної.
Одного методу недостатньо. Практичне рішення — поєднати кілька рівнів:
Оцінювання «агент — агент»: другий агент реального часу, якому доручено втілити певний образ користувача, спілкується із системою, що тестується. Третя LLM у ролі судді оцінює взаємодію. Це дає змогу у великих масштабах тестувати весь аудіотракт, зокрема своєчасність і обробку переривань.
Нефункціональні метрики: час до початку відтворення аудіо й аналіз тональності транскрипту слугують кількісними непрямими показниками якості розмови.
Ручна якісна перевірка: досі необхідна, щоб виявляти проблеми, які пропускають автоматизовані метрики, особливо щодо тону та природності.
Жоден окремий метод не охоплює всього. Для впровадження агентів реального часу в робоче середовище потрібно поєднувати всі три підходи. Та навіть тоді інструменти оцінювання аудіо в реальному часі залишаються незрілими порівняно з інструментами для текстового ШІ.
Голосова взаємодія в реальному часі змінює саму природу продукту. Для користувачів своєчасність, переривання, тиша й відновлення розмови важать не менше за слова.
Отже, модель — лише частина системи. Для робочої голосової системи реального часу потрібні орієнтований на голос рівень керування сеансом, чітке розмежування мовлення й міркування та подієве керування живим сеансом. Захисні механізми залишаються вузьким місцем щодо затримки, але творчі підходи дають змогу значною мірою зберегти ефект реального часу.
Найслабша частина технологічного стека — усе ще оцінювання. Досі немає усталеного способу тестувати характеристики, завдяки яким голосова взаємодія в реальному часі сприймається природно: своєчасність, тон, обробку переривань і плинність розмови. Поки такого способу немає, командам, які працюють із цією технологією, доведеться поєднувати автоматизовані тести, сеанси «агент — агент» і ручну перевірку.