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