Головна / Статті

ai-voice-agentagentsarchitecturellmspeech-to-text

Як створити AI-голосового агента у 2026 році: архітектура та склад компонентів.

Як створити штучного інтелектуального голосового агента у 2026 році: каскадні, напівкаскадні та моделі «голос-у-голос», п’ятишарова архітектура, оптимізація затримок, тестування, відповідність стандартам та витрати.

Видавець: REACTAPP.TOP21 хв читання4860 слів

Джерела: How to Build an AI Voice Agent in 2026: Architecture & Stack

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

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

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

Створення за вісім рішень

Кожен вибір звужує можливості для наступного.

  1. Визначте процес роботи з дзвінками. Вирішіть, які типи дзвінків буде обробляти агент, що він може робити та коли саме переходить людина.
  2. Виберіть архітектуру. Каскадна, напівкаскадна або нативна трансляція мовлення в мовлення. Цей вибір визначає мінімальну затримку та максимальну вартість.
  3. Виберіть телекомунікаційне рішення. Twilio, AWS Connect або WebRTC — залежно від каналу та регіону.
  4. Додайте функцію перекладу мовлення в текст. Deepgram Nova-3 або AssemblyAI у режимі потокової передачі, із користувацьким словником термінів вашої галузі, завантаженим перед запуском.
  5. Під’єднайте ШІ та інструменти. Налаштуйте правила виклику функцій та ескалації, а також під’єднайте CRM або систему бронювання.
  6. Додайте функцію перекладу тексту в мовлення. Виберіть голос, увімкніть потокову передачу та прагніть, щоб час відтворення аудіо становив менше 200 мс.
  7. Перевірка затримок та перерв у роботі. Запускайте запрограмовані та стрес-тести та прагніть до часу виконання всієї процедури менше однієї секунди.
  8. Моніторинг після запуску. Слідкуйте за коефіцієнтом завершення завдань, ефективністю контролю ситуації, рівнем задоволення клієнтів та часом обробки з самого першого дня.

Чому компанії їх створюють

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

Меню з інтерактивною голосовою відповіддю відштовхують абонентів, які кладуть слухавку, як тільки опиняються поза межами доступних опцій. Голосовий агент поводиться інакше, адже може вести справжню розмову, ставити додаткові запитання, направляти складні справи та масштабно виконувати повторювані процеси обробки дзвінків. Дані щодо впровадження таких технологій підтверджують це. Опитування показують, що 97% користувачів мобільних пристроїв використовують голосових асистентів, 89% клієнтів віддають перевагу брендам, які пропонують підтримку голосового ШІ, а компанії, що її впроваджують, повідомляють про 20–30% менші операційні витрати. Вважайте це цифрами з галузевих опитувань, а не гарантіями.

Цей тиск проявляється у п’яти сферах, де людські команди не можуть впоратися:

Велика кількість повторюваних вхідних дзвінків. У логістиці, за оцінками, від 50 до 70% вхідних дзвінків — це запитання на кшталт „Де мій замовлення?“. Те саме запитання тисячі разів на день обробляється людьми, які могли б займатися складнішою роботою.

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

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

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

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

Три архітектури

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

1. Каскадна система

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

Реалістичний час відгуку від початку до кінця становить від 500 до 800 мс. Це не найшвидший варіант, але він забезпечує повну модульність. Ви можете замінити Deepgram на AssemblyAI, ChatGPT на Claude або Cartesia на ElevenLabs, не торкаючись нічого іншого. Кожен компонент створює журнали, а кожен шар можна вимірювати, налаштовувати та замінювати окремо. Системи з великим обсягом даних, що використовують телефонію та схильні до вимог щодо конфіденційності, здебільшого працюють саме так — не тому, що це найскладніший варіант, а тому, що він найбільш контрольований.

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

  • Стрім телефонії. Підключення через Twilio або AWS Connect з подальшою передачею вхідного аудіо на систему розпізнавання мовлення через SIP або WebRTC.
  • Стрімове розпізнавання мовлення. Deepgram Nova-3 у режимі стріму починає транскрибувати ще до того, як абонент закінчить речення.
  • Оркестрація LLM. Надайте транскрипт GPT-5 або Claude Sonnet разом із запитом, який визначає обсяг, тон та умови ескалації.
  • Виклик функцій. Під’єднайте CRM, систему бронювання чи базу даних. Модель викликає їх під час розмови та чекає на результат.
  • Стрімінговий TTS. Надсилайте результати роботи моделі до Cartesia чи ElevenLabs, щоб відтворення почалося ще до повного генерування відповіді.
  • Логування та повторне відтворення. Фіксуйте транскрипти та аудіо на кожному рівні, щоб можна було визначити конкретний компонент, який спричинив збій.
  • Передача людині. Визначте, які інтенти та ключові слова запускають передачу справи до живого агента.

2. Пів-каскад

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

Модель помічає роздратованого абонента, різкий підйом інтонації під час запитання чи зміну мови посеред речення. Між звуком та розумінням моделлю немає жодного кроку транскрипції. Результат все одно проходить через спеціалізовану модель TTS, тому якість голосу залишається точно контрольованою. ElevenLabs Agents та Google’s Gemini Live також використовують цю схему, і це правильний вибір, коли спосіб вимови має таке ж значення, як і сам зміст.

3. Нативний текст до голосу

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

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

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

Що обрати

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

| Criteria                 | Cascaded Pipeline                         | Half-Cascade                            | Native Speech-to-Speech                    |
|--------------------------|-------------------------------------------|-----------------------------------------|--------------------------------------------|
| Latency                  | 500-800ms                                 | 300-500ms                               | 200-300ms                                  |
| Approx. Cost/min         | Low                                       | Medium                                  | High ($0.30 can reach $1.50)               |
| Modularity               | Full, swap any component independently    | Partial, TTS is swappable, input        | None, one model, no layers                 |
|                          |                                           | model is not                            |                                            |
| Emotion & Tone Detection | No, transcription strips it              | Yes, model hears audio natively         | Yes                                        |
| Compliance Logging       | Per-layer logs on every component         | Partial                                 | Not possible                               |
| PSTN Compatibility       | Strong                                    | Strong                                  | Weak, 8kHz audio narrows the               |
|                          |                                           |                                         | quality advantage                          |
| Best For                 | Telephony, compliance-sensitive,          | Multilingual callers, emotional         | Sub-300ms use cases with manageable        |
|                          | high-volume deployments                   | context, tone detection                 | call volume                                |
| Avoid When               | Latency is a hard requirement             | You need full component control         | Long calls, regulated industries,          |
|                          | under 500ms                               | or strict cost caps                     | unpredictable volume                       |

П’ять шарів

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

| Layer         | Role                    | Common Tools                  | Enterprise Consideration          |
|---------------|-------------------------|-------------------------------|-----------------------------------|
| Telephony     | Call routing            | Twilio, AWS Connect, SIP      | Region coverage, number portability |
| STT           | Speech transcription    | Deepgram, AssemblyAI, Whisper | Accents, noise, vocabulary        |
| LLM           | Reasoning and response  | GPT, Claude, Gemini, Llama    | Latency, compliance, tool use     |
| TTS           | Voice output            | ElevenLabs, Cartesia, PlayHT  | First-byte latency, brand voice   |
| Orchestration | Turn-taking and routing | Retell AI, Vapi, LiveKit      | Barge-in, handoff, monitoring     |

Компоненти, у порядку:

  1. Телефонія. Вхідні двері. Абонент дзвонить, і цей шар захоплює аудіо та передає його далі по ланцюгу обробки. Поширеними варіантами є Twilio, AWS Connect та WebRTC.
  2. Переклад мовлення у текст. Перетворює сказане абонентом на текст. Шум, акценти та спеціалізована термінологія впливають на якість, а будь-які помилки тут впливають на всі наступні шари.
  3. LLM. „Мозок“. Він читає транскрипцію, визначає намір, обирає дію та пише відповідь. Коли йому потрібні зовнішні дані, такі як статус замовлення чи баланс, він викликає відповідний інструмент та чекає.
  4. Переклад тексту у мовлення. Перетворює відповідь назад у аудіо, і якість голосу та швидкість реакції залежать від цього етапу.
  • Інтеграції. Підключення до реальних систем: CRM, платформи бронювання, бази даних та процесори платежів. Без них агент може спілкуватися, але не може нічого робити.

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

    Рівень 1: переклад мовлення у текст

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

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

    Інструменти.

    • Deepgram Nova-3 є стандартним вибором для прямих телефонних розмов, ефективно справляючись із шумними лініями, акцентами та низькою пропускною здатністю без особливих проблем.
    • AssemblyAI Universal-Streaming добре підходить, коли аудіо є чистим.
    • gpt-4o-transcribe від OpenAI є точним, проте додаткова затримка відчувається під час прямої розмови.
    • Whisper — потужна модель, розроблена для пакетної обробки, тому вона погано підходить для стрімінгу.

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

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

    Рівень 2: LLM

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

    Вибір моделі. GPT-5 та Claude Sonnet є найнадійнішими варіантами для голосового використання у 2026 році, оскільки обидві ефективно обробляють контекст, суворо дотримуються інструкцій та створюють достатньо короткі відповіді для озвучення. Gemini 3 Flash варто розглянути, якщо пріоритетом є низька затримка. Llama та Mistral підходять для команд, яким потрібна робота без підключення до Інтернету або більш суворий контроль витрат.

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

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

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

    Рівень 3: текст до голосу

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

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

    Інструменти.

    • Cartesia Sonic є лідером за швидкістю, адже перший аудіофайл генерується швидше, ніж у більшості конкурентів.
    • ElevenLabs створює найбільш реалістичні голоси та дозволяє клонувати їх з короткого аудіозразка.
    • gpt-4o-mini-tts від OpenAI є хорошим стандартним варіантом, якщо вся інфраструктура вже базується на OpenAI.
    • PlayHT та Rime варто спробувати, якщо потрібен певний акцент чи регіональний тон.

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

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

    Рівень 4: телефонія та канали

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

    Як з’єднуються дзвінки. PSTN, звичайна телефонна мережа, обмежує частоту аудіо до 8 кГц, що негативно впливає на всі наступні моделі. SIP використовується для трафіку VoIP та забезпечує більш точний контроль маршрутизації. WebRTC передається через Інтернет з кращою якістю аудіо, тому підходить для використання в браузерах та додатках. Поширеним рішенням є використання SIP для вхідних дзвінків та WebRTC для всього, що відбувається в Інтернеті.

    Постачальники.

    • Twilio є безпечним стандартним вибором завдяки широкому охопленню, надійному SIP-трункінгу та якісній документації, хоча його вартість зростає при великому обсязі використання.
    • AWS Connect підходить для команд, які вже працюють у середовищі AWS.
    • Vonage є гарним варіантом для міжнародного впровадження, особливо в Європі та на Близькому Сході.

    Платформи оркестрації. Retell AI, Vapi та LiveKit знаходяться посередині, між оператором та вашими варіантами STT, LLM та TTS. Вони керують маршрутизацією аудіо в реальному часі, чергуванням, виявленням перерв та передачею завдань. Для впровадження в телефонію Retell AI є найбільш розвиненою, Vapi надає найбільше можливостей для налаштування власних процесів, а LiveKit найкраще підходить для WebRTC.

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

    Рівень 5: інтеграції

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

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

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

    Де виникають проблеми. Найбільше проблем спричиняють два фактори. Повільний API безпосередньо збільшує затримку, і абонент не може визначити, чи модель обробляє інформацію, чи CRM витратив 800 мс на відповідь. Пауза залишається паузою. Іншою проблемою є обробка помилок. Коли пошук тайм-аутується, агенту потрібна підготовлена фраза для відповіді, а не мовчання чи цикл повторюваних речень.

    Аутентифікація. Креденціалами зазвичай є API-ключі або токени OAuth із обмеженими правами — лише на читання або обмежений запис. Для перевірки статусу замовлення потрібні лише права на читання. Для перенесення зустрічей необхідні права на запис у календарі, що підвищує складність обробки помилок, адже неправильний запит може змінити актуальні дані.

    Зниження затримки

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

    Причини затримки

    Кожен компонент додає свій власний час обробки. Стрімінговий STT займає від 50 до 150 мс, інференція LLM — від 200 до 500 мс залежно від моделі та довжини запиту, а обробка першого байту TTS потребує ще від 100 до 200 мс, до чого додається час передачі даних по мережі на кожному етапі. Система, яка має середні показники на кожному рівні, досягає приблизно 1,5 секунди часу обробки без будь-якої оптимізації. Виклики функцій погіршують ситуацію, оскільки обробка повністю зупиняється до повернення результату засобу, що додає ще від 300 до 800 мс.

    Що робити з цим

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

    Кешування також допомагає. Якщо більшість абонентів ставлять однакові три запитання, підготуйте їхні відповіді заздалегідь та надавайте їх миттєво. Також тримайте компоненти разом з географічної точки зору. Розділення модуля STT у регіоні US-East від моделі LLM у регіоні EU-West коштує від 80 до 120 мс на кожен запит через звичайну мережеву передачу даних.

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

    Втручання під час розмови

    Функція виявлення втручання прослуховує аудіо абонента під час відтворення TTS, перериває відповідь на середині речення та негайно перенаправляє розмову. Як Retell AI, так і Vapi підтримують її вбудовано. Налаштуйте поріг чутливості до аудіо, щоб фоновий шум не спричиняв хибних переривань.

    Де розгортати

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

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

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

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

    Дотримання правил

    • У сфері охорони здоров’я США стандарт HIPAA вимагає підписаних угод про співпрацю з кожним постачальником, шифрування аудіо-даних під час зберігання та ведення журналів доступу.
    • GDPR поширюється на всі системи, які працюють із резидентами ЄС, вимагаючи чітких повідомлень про отримання згоди для записаних дзвінків.
    • Правила резидентства даних у ОАЕ, Саудівській Аравії та Німеччині обмежують місце зберігання даних розмов, тому перед запуском необхідно перевірити кожного постачальника на відповідність цим правилам.

    Масштабування

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

    Моніторинг

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

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

    Тестування та оцінка

    Більшість проблем можна виявити перед запуском, якщо правильно протестувати всі необхідні аспекти.

    1. Почніть з сценаріїв, написаних заздалегідь, для 20–30 основних типів дзвінків.
    2. Переходьте до тестування в умовах конфліктів: переривайте агента, надавайте йому неповну інформацію та ставте запитання, що виходять за межі його функціоналу.
    3. Стежте за значущими помилками — це впевнені неправильні відповіді, передачі даних, які ніколи не відбуваються, та виклики інструментів, що залишають систему мовчазною.
    4. Використовуйте інструменти на кшталт Hamming чи набору інструментів оцінки Vapi для програмного моделювання сотень сценаріїв.

    Найважливішими є чотири показники: частка завершених завдань, частка контролю ситуації, CSAT та середній час обробки. Відстежуйте їх усі з першого дня. Компоненти, які працюють стабільно при 10 одночасних викликах, часто зламуються при 100, тому проводяться тести з навантаженням у три–п’ять разів. Після запуску щотижня переглядайте записи розмов та використовуйте їх для вдосконалення запитів, уточнення визначень функцій та розширення механізмів роботи з альтернативними сценаріями. Агенти, які покращуються найшвидше, мають за собою структуровану процедуру перевірки.

    Десять уроків з реальних реалізацій

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

    1. Транспортування даних важливіше, ніж вибір моделі. Заміна WebSockets на UDP може допомогти більше, ніж зміна самої LLM-моделі. Більшість моделей працюють добре за наявності хорошого запиту, тоді як затримки та інфраструктура зовсім не реагують на запити.
    2. Один агент — одна задача. Для кількох різних завдань слід використовувати кілька агентів, які можуть взаємодіяти між собою. Один агент, який має виконувати все, працює погано.
    3. Виклик функцій перешкоджає стрімінгу. Ніщо не стрімиться, поки не завершиться виклик інструменту. Створюйте потік розмови навколо цієї перерви, а не всупереч їй.
  • Великі вікна контексту вводять в оману. Намагання заповнити запит усіма можливими даними — це ставка, яка зазвичай програє, адже чим більше контексту, тим більше модель відхиляється від основної теми. Надавайте лише те, що необхідно.
  • RAG збільшує потужність, але й вимоги до обслуговування. Він забезпечує канал передачі даних, який тепер належить вам, його потрібно оновлювати та підтримувати у актуальному стані, тож чесно оцініть ці витрати.
  • Динамічні API кращі за статичні для отримання реального часу даних. Якщо важлива свіжість інформації, безпосереднє звернення до джерела дає кращі результати, ніж використання шару пошуку, заснованого на данах з минулого дня.
  • Результати роботи інструментів потребують повторного запиту. Модель бачить результат інструменту лише тоді, коли він додається до історії та надсилається назад. Якщо про це забути, агент буде відповідати на основі порожніх даних.
  • Запити — це частина архітектури. Тестуйте та вдосконалюйте їх так само, як код, адже саме вони містять основну логіку агента.
  • Аудіо та транскрипції не збігаються. Те, що почув абонент, та те, що було зафіксовано, не завжди збігаються, тому контроль якості не може покладатися лише на точність транскрипції.
  • Інфраструктура голосу — це не інфраструктура тексту. Уроки, отримані з роботи з текстом, не можна застосувати до голосу. У голосових комунікаціях є свої профілі затримок, характер пов’язування та способи збоїв, тому потрібно починати з нуля.

    • Яка це коштує

    Реалізація власними силами коштує приблизно 8 500 доларів для найпростішого демонстраційного проекту; ця сума змінюється залежно від обсягу та функцій. Для системи корпоративного рівня витрати становлять 100 000 доларів або більше, плюс три–шість місяців роботи інженерів перед запуском. Це ще до роботи зі впровадженням вимог та щорічних витрат у розмірі 15–20%, які зазвичай виникають після запуску в промислових умовах.

    | Tier                              | Upfront Cost | Timeline    | Key Features                                               |
|-----------------------------------|--------------|-------------|------------------------------------------------------------|
| MVP/Proof of Concept              | $8K-$30K     | 4-10 weeks  | Basic voice flows, single integrations, RAG memory         |
| Mid-Tier (CRM/multi-intent)       | $25K-$150K   | 2-6 months  | Contextual reasoning, telephony (Twilio), analytics        |
| Enterprise (autonomous, compliant)| $150K-$300K+ | 4-12 months | Multi-agent orchestration, multilingual, deep ERP/CRM,     |
|                                   |              |             | HITL governance                                            |

    Лише команда, яка включає інженерів з ШІ, розробників бекенду, фахівців з DevOps та QA, коштує 150 000 доларів або більше на рік, і ця команда витрачає свій час на інфраструктуру, а не на основний бізнес.

    Мінімальна життєздатна архітектура

    Перш за все потрібні шість компонентів:

    • Вхідний аудіо.** Twilio або WebRTC передають голос абонента у систему обробки.
    • Стрімінговий переклад тексту зі звуку.** Deepgram Nova-3 транскрибує текст у реальному часі, поки абонент ще говорить.
    • Модель із коротким запитом.** GPT-5 або Claude Sonnet, де запит системи залишається меншим за 500 токенів, оскільки довші запити уповільнюють відповіді.
    • Стрімінговий голосовий синтез.** Cartesia або ElevenLabs починає відтворення ще до того, як буде написана повна відповідь.
    • Логування.** Зберігати транскрипції та аудіо з кожного рівня з першого дня.
    • Альтернативний варіант та передача обов’язків. Встановіть правило передачі для ситуацій, які агент не може вирішити.

    Поширені запитання

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

    Чи може штучний інтелект для голосу обробляти дзвінки та SMS у одному додатку? Так. Як шар телефонії, так і шар оркестрації ШІ працюють у різних каналах, тож потік даних, що обробляє дзвінок, може направляти SMS-розмову через ту саму модель та логіку виклику функцій.

    Як виправити проблеми з інтонацією та темпом мовлення? Прозодія та темп залежать від моделі TTS, а не від сценарію. Cartesia та ElevenLabs за замовчуванням добре забезпечують природний підйом та спад голосу. Якщо мовлення все одно звучить рівно, зазвичай рішенням є використання іншої моделі голосу, а не іншого запиту.

    Як додати штучний інтелект для голосу до існуючої телефонної системи без зміни номерів? Перенесіть номер на SIP-трубку через оператора телефонії, а потім направляйте вхідний аудіо з цієї трубки до шару STT. Абоненти дзвонять за тим самим номером, що й раніше, просто маршрутизація сигналу стала іншою.

    Як уникнути залежності від постачальника? Використовуйте каскадну архітектуру. Кожен компонент працює незалежно, тож Deepgram можна замінити на AssemblyAI, а Cartesia — на ElevenLabs, не перебудовуючи решту системи. Як напівкаскадна, так і нативна архітектура «голос-до-голосу» відмовляються від цієї гнучкості заради нижчої затримки.

    Пов’язані матеріали

    ← Усі статтіНадіслати бриф