При разработке голосового 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. Свяжитесь с нами для оценки вашего проекта. Закажите аудит текущего решения — выявим узкие места и предложим план оптимизации.







