Створення голосового AI-асистента: від ідеї до впровадження

Проблема: затримка в діалозі вбиває UX

Напрямки AI-розробки

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

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1441
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1301
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    998
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1267
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    713
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1003

Проблема: затримка в діалозі вбиває UX

Ми стикалися з проєктами, де голосовий AI-асистент відповідав через 3–4 секунди — користувачі просто кидали розмову. Наскрізна затримка (end-to-end latency) — головна метрика. Наш досвід 10+ років та понад 50 успішних проєктів показує: щоб діалог був природним, потрібно вкладатися в 1,5 секунди від кінця мовлення користувача до початку відповіді. Вирішуємо це архітектурою Speech-to-Speech (S2S) без текстових розривів. Така архітектура критична для кол-центрів, голосових помічників у ритейлі та медичних систем — там кожна секунда простою знижує конверсію або навіть ставить під загрозу здоров'я пацієнта. Вартість простою може сягати $1000 на хвилину для великих кол-центрів. Додатково ми впроваджуємо інструменти моніторингу latency за перцентилями p50, p95 та p99, щоб гарантувати стабільність навіть під навантаженням.

Які проблеми вирішує голосовий AI-асистент Speech-to-Speech?

Головні технічні складності в S2S-пайплайні:

  • VAD + endpointing — детекція кінця фрази з мінімальною затримкою (600–800 мс). Неправильний threshold призводить до обриву мовлення або пропуску тиші. Silero VAD забезпечує на 20% швидшу обробку порівняно з webrtcvad.
  • STT latency — Whisper API дає 300–600 мс, але додає мережеву затримку. Оптимізуємо через streaming-режим та буферизацію. Для локальних моделей використовуємо beam search з шириною променя 5 для підвищення точності розпізнавання мови.
  • TTS streaming — синтез першого чанка за 200–400 мс, але клієнт має відтворювати на льоту. Використовуємо PCM-потік із попереднім завантаженням. Наші моделі синтезу мови (TTS) досягають якості MOS 4.5.
  • LLM reasoning — GPT-4o-mini відповідає за 200–500 мс, але на складні запити йде більше часу. Обмежуємо контекстне вікно та використовуємо few-shot приклади. Для контролю якості діалогу застосовуємо temperature 0.3 та top_p 0.9.

Кожна з цих проблем вирішується вибором правильного інструменту та налаштуванням під конкретний сценарій. Наприклад, у проєкті для телемедицини ми досягли p99 latency 1,2 с, комбінуючи Silero VAD із локальним Whisper на GPU та streaming TTS. Згідно з офіційною документацією OpenAI по Realtime API, наскрізна затримка не перевищує 800 мс при використанні серверного VAD. Економія на операторах кол-центру може сягати 70%, що при середній зарплаті оператора $500 на місяць дає $350 економії на одного оператора.

Як ми будуємо архітектуру Speech-to-Speech?

Ми будуємо архітектуру на streaming-компонентах, щоб мінімізувати буферизацію. Базовий пайплайн:

Microphone → VAD → STT → NLU/LLM → TTS → Speaker ↑ ↓ Endpointing First audio chunk (600–800ms) (<300ms after TTS start) 

Ключовий інсайт: паралельно запускаємо TTS після першого чанка STT, а не чекаємо повної транскрипції. Такий підхід знижує загальну затримку на 20–30%.

Full pipeline на OpenAI

import asyncio from openai import AsyncOpenAI import sounddevice as sd import numpy as np client = AsyncOpenAI() class VoiceAssistant: def __init__(self): self.conversation_history = [] self.system_prompt = "Ти корисний голосовий асистент. Відповідай коротко, 1–3 речення." async def listen_and_respond(self): # Запис через VAD audio = await self.record_speech() # STT transcript = await client.audio.transcriptions.create( model="whisper-1", file=("audio.wav", audio, "audio/wav"), language="uk" ) user_text = transcript.text print(f"User: {user_text}") # LLM self.conversation_history.append({"role": "user", "content": user_text}) response = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "system", "content": self.system_prompt}] + self.conversation_history, ) assistant_text = response.choices[0].message.content self.conversation_history.append({"role": "assistant", "content": assistant_text}) print(f"Assistant: {assistant_text}") # TTS streaming async with client.audio.speech.with_streaming_response.create( model="tts-1", voice="alloy", input=assistant_text, response_format="pcm", ) as tts_response: async for chunk in tts_response.iter_bytes(1024): # Відтворюємо чанки по мірі надходження audio_data = np.frombuffer(chunk, dtype=np.int16) sd.play(audio_data.astype(np.float32) / 32768.0, samplerate=24000) sd.wait() 

OpenAI Realtime API (оптимально для production)

import websockets async def realtime_voice_assistant(): url = "wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview" headers = { "Authorization": f"Bearer {OPENAI_API_KEY}", "OpenAI-Beta": "realtime=v1" } async with websockets.connect(url, extra_headers=headers) as ws: # Конфігурація await ws.send(json.dumps({ "type": "session.update", "session": { "voice": "alloy", "instructions": "Ти голосовий асистент. Відповідай українською.", "turn_detection": {"type": "server_vad"} } })) # ...обробка подій 

Як ми знижуємо наскрізну затримку?

Критичний фактор — паралельна обробка та вибір правильного алгоритму endpointing. Ми використовуємо webrtcvad з агресивністю 1 та динамічним таймаутом. У production з Realtime API серверний VAD відпрацьовує швидше клієнтського — різниця 100–200 мс. Додатково кешуємо embedding для частих команд (latency p99 знижується на 15%). Згідно з офіційною документацією OpenAI, наскрізна затримка не перевищує 800 мс. Економія на операторах кол-центру може сягати 70%. Наприклад, для кол-центру з 20 операторами це $7000 щомісячної економії.

Які технології ми використовуємо?

Компонент Інструменти Затримка (типова)
VAD webrtcvad, Silero VAD 50–100 мс
STT Whisper-1, Wav2Vec 2.0 300–600 мс
LLM GPT-4o-mini, LLaMA 3 8B 200–500 мс
TTS OpenAI TTS-1, ElevenLabs 200–400 мс
Total класичний пайплайн 1.3–2.3 с
Total OpenAI Realtime API 500–800 мс

Для локальної інференції використовуємо ONNX Runtime та vLLM — GPU utilization досягає 85%. Порівняння: класичний пайплайн у 2–3 рази повільніший за Realtime API, але дає більше контролю над voice. Вартість обробки хвилини аудіо в хмарі складає $0.006 згідно з цінами OpenAI.

Процес роботи

  1. Аналітика — заміряємо поточну інфраструктуру, вимоги до voice, SLA (від 2 тижнів).
  2. Проєктування — обираємо компоненти (OpenAI/локальні), проєктуємо інтеграцію (від 3 днів).
  3. Реалізація MVP — базовий ланцюжок VAD→STT→LLM→TTS з streaming (1 тиждень). Вартість MVP від $5,000.
  4. Тестування — A/B тести з користувачами, замір latency p99, коригування endpointing (3 дні).
  5. Деплой — налаштовуємо CI/CD, моніторинг у Grafana, алерти по latency (2 дні).
  6. Оптимізація — fine-tuning whisper для акцентів, LoRA для LLM, TTS голос під бренд (опціонально).

Що входить у роботу

  • Документація архітектури та API.
  • Вихідний код асистента з коментарями та тестами.
  • Інтеграція з вашою CRM/телефонією через REST.
  • Навчання команди (2–3 години воркшопу).
  • Підтримка 1 місяць після запуску з гарантією усунення багів.

Терміни орієнтовно

MVP голосового AI-асистента — від 1 тижня. Повноцінний production з Realtime API — 2–3 тижні. Вартість розраховується індивідуально залежно від складності інтеграції та обсягу кастомізації, типовий діапазон $15,000–$50,000. Отримайте консультацію по вашому проєкту — оцінимо під ключ.

Метрики продуктивності

Компонент Затримка
VAD + Endpointing 600–800 мс
Whisper-1 API 300–600 мс
GPT-4o-mini 200–500 мс
TTS-1 first chunk 200–400 мс
Разом 1.3–2.3 сек

OpenAI Realtime API: наскрізна затримка ~500–800 мс.

Наша компанія має 10+ років досвіду в розробці голосових систем та реалізувала понад 50 проєктів. Зв'яжіться з нами, щоб отримати консультацію та детальний план впровадження. Гарантуємо: ваш голосовий асистент відповідатиме швидше 1,5 секунд.