Голосові агенти не слухають. Вони читають.

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

@miramurati

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

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

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

Я вважаю, що це найбільший розрив у голосовому ШІ сьогодні.

Ця стаття — мій погляд на статус-кво, і в ній я досліджую такі питання:

• Чи може агент добре ухвалювати рішення, якщо він ніколи не чує дзвінка?
• Чому мережа LLM не змогла закрити цю прогалину?
• Чому б не використати моделі speech-to-speech?
• Як виглядав би «мислячий шар», який справді слухає?

Де ринок перебуває сьогодні?

https://x.com/jordan_dearsley/status/2085602471918064064

Роками люди передбачали, що голос стане універсальним способом взаємодії з програмним забезпеченням. У 2026 році цей прогноз починає справджуватися. ШІ щороку обробляє мільярди бізнес-дзвінків завдяки таким компаніям, як @ElevenLabs та @DeepgramAI, а також понад 800 продуктам голосового ШІ.

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

Майже всі голосові агенти побудовані каскадно: спочатку speech-to-text (STT), потім LLM, а далі text-to-speech (TTS). Інженери люблять такий підхід, бо можуть обрати найкращу модель для кожного завдання, бачити кожен проміжний крок і жорстко контролювати, що саме агент говорить і робить.

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

Що саме відкидає транскрипт

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

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

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

Два аудіофрагменти з однаковим транскриптом: «Так, продовжуйте». Один адресований агенту, інший — комусь іншому в кімнаті. Лише аудіо дозволяє їх відрізнити.

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

Візьмімо перше питання. Ми всі знаємо, що людина ось-ось закінчить фразу, ще до того, як настане тиша: тон падає, темп уповільнюється, голос стихає. Моделі, які чують аудіо, навчаються використовувати саме ці сигнали (Ekstedt & Skantze, 2022). А от моделі, які читають лише транскрипти, цього не можуть, бо просодія ніколи не записується текстом (Rajaa, 2026).

Те саме з п'ятим питанням. Коли Apple тестувала, чи була мова адресована її асистенту, додавання аудіо до транскрипту зменшило кількість помилок на 39% порівняно з використанням лише тексту.

Найкращі рішення приймаються на основі аудіо та тексту разом. На жаль, сучасні агенти отримують лише текст.

Лише транскрипт: 74,8% реплік перебиваються зарано. З аудіо: 7,8%. Uniphore, arXiv 2609.11066.

Чому мережа LLM наштовхується на стіну

Для побудови «мислячого шару» інженери обрали жадібне рішення. Вони пішли найпростішим шляхом із максимальною миттєвою віддачею: взяти найкращу frontier-модель LLM на той момент і вручити їй одну гігантську інструкцію, що робити. Так пройшли весь 2023–24 роки.

Але тут є кілька проблем.

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

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

Це і є сучасний frontier-стек.

Але у продакшені ця архітектура показала дві тріщини:

• Кожен компонент досі читає той самий транскрипт. Додавання нових LLM не поверне паузу чи тон, які транскрипт уже відкинув.
• Компоненти чекають один на одного. Кожен виклик додає затримку. Розпізнавання репліки, ухвалення рішення та виконання завдань забирають до 80% часу відповіді.

Каскадний голосовий агент: аудіо абонента йде у speech-to-text, потім кілька викликів LLM, а далі у text-to-speech. Тон, паузи, емоційне забарвлення, фон і те, до кого звертаються, втрачаються ще на етапі speech-to-text.

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

Чому б не відмовитися від транскрипту взагалі?

Моделі speech-to-speech (STS) цього року почали подавати реальні ознаки життя. Їхня привабливість очевидна: менша затримка, краще розуміння розмови та менше інженерної роботи завдяки об'єднанню STT, LLM і TTS в одну модель.

Найбільший мінус — брак контролю та верифікованих даних. Ви не можете точно передбачити, що скаже STS-модель, а виклики інструментів і виконання коду не даються природно моделі, яка мислить аудіо.

Я вважаю, що STS поки що далека від реальності у короткостроковій перспективі. Навіть якщо розвиток прискориться, спершу вона підійде для простіших сценаріїв, як-от відповіді на FAQ. Розробники залишаться на каскадній архітектурі — частково через інерцію, а переважно тому, що їм потрібні її контроль і гнучкість.

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

Шар, який слухає

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

Придивіться до GPT-Live, і ви побачите рушій рішень у його ядрі. Багато разів на секунду він вирішує, чи говорити, продовжувати слухати, зробити паузу, перебити чи викликати інструмент. Каскаду потрібен такий самий рушій, але як окремий компонент, який можна бачити й контролювати.

Модель ухвалення рішень бере поточний стан і обмежений набір варіантів (говорити чи чекати, ескалювати чи продовжити, який інтент) і повертає один вибір із ймовірністю — швидше й набагато дешевше, ніж LLM. @typesafeai здивували всіх тим, наскільки добре це працює з текстом.

Я пропоную таке:

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

Модель ухвалення рішень бере аудіо, попередній контекст розмови та набір варіантів і повертає ймовірність для кожного: refund_status 0.91, cancel_order 0.06, escalate 0.03 (приклад).

Саме оцінка впевненості робить це можливим. Запитайте LLM, наскільки вона впевнена, і вона зазвичай відповість «дуже», навіть коли помиляється (Xiong et al., 2024). А оцінки класифікатора можна налаштувати так, щоб вони означали саме те, що кажуть: коли класифікатор каже, що впевнений, він зазвичай не бреше (Guo et al., 2017).

Наші ранні експерименти з партнерами показують, що 30–40% того, що LLM робить усередині агента, — це саме така робота: маршрутизація, сортування, вибір між обмеженою кількістю варіантів.

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

Ви не можете просто «прикрутити» аудіо до текстової моделі рішень. Щоб побудувати ту, яка слухає, потрібні три речі:

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

Правильна модель рішень для голосу — це та, яка слухає, тобто аудіо-нативний шар ухвалення рішень.

Що змінюється, коли шар рішень починає чути

З аудіо-нативною моделлю рішень вам відкриваються такі сценарії:

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

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

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

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

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

Дослідники з Meta та CMU продемонстрували вигоду: паралельне з мовленням користувача передбачення викликів інструментів скоротило їхню затримку на 20% і зробило відповіді точнішими.

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

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

https://x.com/signulll/status/2077444321243013306

Майбутнє голосового ШІ

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

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

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

Я будую цей шар рішень у @tazolabs і поділюся деталями про наші моделі в найближчі дні.

Якщо ви створюєте голосових агентів, мені було б цікаво дізнатися, з якими рішеннями ваш агент зараз справляється найгірше. А якщо ця візія вам близька — приєднуйтесь до нас у Tazo Labs.

Яке одне рішення ваш голосовий агент найчастіше ухвалює неправильно?