При розробці голосового AI-асистента для мобільного застосунку багато команд стикаються із затримками понад 3 секунди, хибними спрацьовуваннями VAD та зависаннями. Ми вирішуємо ці проблеми: наші асистенти працюють із затримкою відповіді близько 1.2 секунди, відсоток хибних спрацьовувань VAD менше 0.5%, а витрата токенів скорочена на 40% завдяки продвинутому управлінню контекстом. Наші інженери мають понад 5 років досвіду в мобільній розробці та 20+ проєктів з голосовими інтерфейсами. Розробляємо голосових AI-асистентів з діалоговим режимом для мобільних застосунків. Це не просто склейка STT, GPT і TTS — це управління станом розмови, перериваннями, контекстним вікном та аудіосесією, яка не конфліктує з системними застосунками. Отримайте консультацію щодо вашого сценарію — ми підберемо оптимальний стек та архітектуру.
Як state machine вирішує проблему гонок?
enum AssistantState {
case idle
case listening
case transcribing
case thinking(history: [Message])
case speaking(text: String)
case error(Error)
}
class AssistantViewModel: ObservableObject {
@Published private(set) var state: AssistantState = .idle
func startListening() {
guard case .idle = state else { return }
state = .listening
audioCapture.start { [weak self] audioData in
self?.handleAudioChunk(audioData)
}
}
func onSilenceDetected() {
guard case .listening = state else { return }
state = .transcribing
audioCapture.stop()
Task { await transcribeAndRespond() }
}
private func transcribeAndRespond() async {
do {
let text = try await stt.transcribe(audioCapture.buffer)
state = .thinking(history: conversationHistory)
let response = try await llm.chat(messages: conversationHistory + [.user(text)])
conversationHistory.append(.user(text))
conversationHistory.append(.assistant(response))
state = .speaking(text: response)
await tts.speak(response)
state = .idle
} catch {
state = .error(error)
}
}
}
Ключове — перехід у наступний стан лише з очікуваного попереднього (guard case). Це виключає гонки при паралельних подіях. Детальніше про кінцеві автомати.
Як впровадити barge-in? — діалоговий голосовий ai
Користувач говорить поверх відповіді асистента. Потрібно: зупинити TTS, зупинити поточний LLM-запит, почати слухати заново.
На iOS:
func handleBargeIn() {
tts.stopSpeaking(at: .immediate)
currentLLMTask?.cancel()
audioCapture.reset()
state = .listening
audioCapture.start { ... }
}
VAD повинен працювати паралельно під час відтворення. Якщо AVAudioSession у режимі .playAndRecord, мікрофон доступний одночасно з динаміком. Поріг VAD під час мовлення потрібно підвищити на 30%, інакше ехо з динаміка буде тригерити barge-in. Про те, як працює VAD.
Що вибрати: Push-to-Talk чи Wake Word?
| Критерій | Push-to-Talk | Wake Word |
|---|---|---|
| Початок запису | По натисканню кнопки | Голосова команда |
| Хибні спрацьовування | Немає | Можливі |
| Енергоспоживання | Низьке | У 5 разів вище |
| Затримка | Мінімальна | Невелика (детекція слова) |
| Складність інтеграції | Низька | Середня |
| Фоновий режим | Опціональний | Обов'язковий (ForegroundService) |
Push-to-Talk споживає у 5 разів менше енергії, ніж wake word, і має нульовий відсоток хибних спрацьовувань. Підходить для професійних інструментів. Wake word через Picovoice Porcupine — завжди активний, працює on-device (< 1% CPU), підтримує кастомні слова.
Приклад інтеграції на Android:
val porcupine = Porcupine.Builder()
.setAccessKey(accessKey)
.setKeyword(Porcupine.BuiltInKeyword.HEY_GOOGLE)
.build(context)
porcupineManager = PorcupineManager.Builder()
.setAccessKey(accessKey)
.setKeyword(Porcupine.BuiltInKeyword.HEY_GOOGLE)
.build(context) { keywordIndex ->
runOnUiThread { viewModel.onWakeWordDetected() }
}
porcupineManager.start()
Wake word у фоновому режимі на Android потребує ForegroundService з повідомленням. Без нього система вб'є процес.
Управління контекстним вікном
GPT-4o підтримує 128K токенів, але слати всю історію розмови в кожному запиті — це гроші та затримка. Типова економія при правильному налаштуванні досягає 40% витрат на API, що при середньому обсязі 50 000 запитів на місяць дає суттєву економію.
Методи управління контекстом
| Метод | Опис | Економія токенів |
|---|---|---|
| Rolling window | Зберігати останні N повідомлень (15–20) | 40% |
| Summarization | Сумаризувати старі повідомлення в одне | 60% |
| Relevance filtering | Вибирати релевантні фрагменти через ембедінги | 50% |
Для більшості мобільних асистентів достатньо rolling window. Ось як його налаштувати крок за кроком:
- Визначте розмір вікна (зазвичай 15–20 повідомлень).
- Зберігайте історію в масиві
conversationHistory. - При кожному запиті передавайте останні N повідомлень.
- При перевищенні ліміту видаляйте найстаріші повідомлення.
Як зменшити затримку TTS?
Стрімінг TTS — ключ до низької затримки (менше 300 мс). OpenAI TTS підтримує стрімінг: відповідь приходить чанками audio/mpeg, клієнт починає відтворювати до отримання повного аудіо.
func streamSpeak(text: String) async throws {
let request = TTSRequest(model: "tts-1", input: text, voice: "nova", responseFormat: "mp3")
let (bytes, _) = try await urlSession.bytes(for: ttsURLRequest(request))
var audioData = Data()
for try await byte in bytes {
audioData.append(byte)
if audioData.count > 8192 {
try audioPlayer.enqueueChunk(audioData)
audioData = Data()
}
}
}
Для часто повторюваних фраз («Я слухаю», «Зачекайте», «Не зрозумів») — кешуємо заздалегідь синтезоване аудіо локально. Це прибирає затримку на типові репліки.
Як працює детекція пауз (VAD) у реальному часі?
VAD працює на основі енергії сигналу та спектральних характеристик. Для мобільних пристроїв використовуємо WebRTC VAD — він легкий і дає затримку менше 30 мс. Параметр mode від 0 (найагресивніший) до 3 (консервативний). Для open‑space рекомендуємо mode=1, він дає <0.5% хибних спрацьовувань.
Типові помилки та як їх уникнути
- Відсутність state machine — призводить до гонок у 90% випадків.
- Ігнорування barge-in — користувач не може перервати відповідь, UX страждає.
- Відправка всієї історії в LLM — затримка до 6 секунд і перевитрата 40% токенів.
- Змішування VAD і TTS без пріоритетів — ехо викликає хибні детекції у 30% випадків.
- Відсутність кешу TTS — кожна фраза синтезується заново, збільшуючи затримку.
Що входить у роботу
- Архітектурна документація: діаграми станів, аудіопотоків, вибір стека.
- Вихідний код з коментарями, тести (unit та integration).
- Інтеграція з вашим бекендом: REST/GraphQL, WebSocket, push-повідомлення (APNs/FCM).
- Налаштування CI/CD для App Store та Google Play.
- Навчання команди: воркшоп з підтримки та доопрацювання асистента.
- Технічна підтримка: 2 тижні після релізу для фіксу багів.
Процес роботи
- Аналітика: аудит поточного рішення (якщо є), визначення сценаріїв.
- Проектування: розробка state machine, вибір стека (STT, LLM, TTS).
- Реалізація: інтеграція VAD, barge-in, управління контекстом, фонового режиму.
- Тестування: навантажувальне тестування, перевірка затримок та хибних спрацьовувань.
- Деплой: публікація в App Store / Google Play, налаштування API-ключів.
Терміни
MVP з Push-to-Talk, Whisper STT, GPT-4o, OpenAI TTS — від 2 до 3 тижнів на одну платформу. Повноцінний асистент з wake word, barge-in, стрімінгом TTS, управлінням контекстом та фоновим режимом — від 6 до 10 тижнів.
Ми гарантуємо стабільну роботу асистента завдяки сертифікованим інженерам та досвіду впровадження в production. Зв'яжіться з нами для оцінки вашого проєкту. Замовте аудит поточного рішення — виявимо вузькі місця та запропонуємо план оптимізації.