Голосовой поиск в мобильном приложении: интеграция Speech API

Представьте: пользователь нажимает кнопку микрофона, говорит запрос, но транскрипция появляется через 10 секунд после завершения речи. Или приложение запрашивает разрешение на микрофон — и молчит, потому что разработчик забыл проверить authorizationStatus. Это типичные ошибки интеграции голосового поиска, которые мы исправляем в каждом втором проекте. За 5+ лет мы реализовали 50+ проектов с голосовым вводом — от e-commerce до медицинских справочников. Голосовой поиск ускоряет ввод запроса в 3 раза и повышает конверсию поиска на 20%, но только если реализация корректна.

В этой статье на конкретных примерах разберем, как правильно интегрировать Speech API на iOS (Swift), Android (Kotlin) и Flutter, какие решения работают стабильно, а какие ведут к потере пользователей. Мы используем потоковое распознавание с частичными результатами — это даёт мгновенную обратную связь.

Где чаще всего ломается реализация

iOS: неправильная работа с SFSpeechRecognizer

Самая частая ошибка — запуск SFSpeechRecognitionTask без проверки прав. Пользователь нажимает кнопку, а приложение молчит. Вторая проблема — использование файлового запроса SFSpeechURLRecognitionRequest вместо потокового SFSpeechAudioBufferRecognitionRequest. В результате пользователь говорит, но транскрипция появляется только после остановки записи.

Правильный подход: использовать AVAudioEngine с SFSpeechAudioBufferRecognitionRequest и включить shouldReportPartialResults = true. Это дает частичные результаты по мере речи — как в системной Siri.

let request = SFSpeechAudioBufferRecognitionRequest()
request.shouldReportPartialResults = true

recognitionTask = speechRecognizer.recognitionTask(with: request) { result, error in
    guard let result else { return }
    self.searchBar.text = result.bestTranscription.formattedString
    if result.isFinal {
        self.submitSearch(query: result.bestTranscription.formattedString)
    }
}

let inputNode = audioEngine.inputNode
let format = inputNode.outputFormat(forBus: 0)
inputNode.installTap(onBus: 0, bufferSize: 1024, format: format) { buffer, _ in
    request.append(buffer)
}
audioEngine.prepare()
try audioEngine.start()

Apple Speech Framework Documentation

Android: выбор между SpeechRecognizer и RecognizerIntent

RecognizerIntent запускает системный диалог — быстро, но выглядит чужеродно и не всегда поддерживает EXTRA_PARTIAL_RESULTS. SpeechRecognizer дает полный контроль, но требует аккуратного управления жизненным циклом: вызов destroy() в onDestroy() обязателен. Реализация SpeechRecognitionListener через интерфейс RecognitionListener даёт доступ к частичным результатам.

Для inline-интеграции используем SpeechRecognizer с Intent, содержащим EXTRA_PARTIAL_RESULTS = true и языковую модель.

val recognizer = SpeechRecognizer.createSpeechRecognizer(context)
val intent = Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH).apply {
    putExtra(RecognizerIntent.EXTRA_LANGUAGE_MODEL, RecognizerIntent.LANGUAGE_MODEL_FREE_FORM)
    putExtra(RecognizerIntent.EXTRA_PARTIAL_RESULTS, true)
    putExtra(RecognizerIntent.EXTRA_LANGUAGE, "ru-RU")
}

recognizer.setRecognitionListener(object : RecognitionListener {
    override fun onPartialResults(partialResults: Bundle) {
        val partial = partialResults.getStringArrayList(SpeechRecognizer.RESULTS_RECOGNITION)
        searchInput.setText(partial?.firstOrNull() ?: "")
    }
    override fun onResults(results: Bundle) {
        val text = results.getStringArrayList(SpeechRecognizer.RESULTS_RECOGNITION)?.firstOrNull()
        text?.let { submitSearch(it) }
    }
    // ... остальные коллбэки
})
recognizer.startListening(intent)

Flutter: speech_to_text vs Platform Channels

Пакет speech_to_text покрывает 90% задач. Основная проблема — многоязычность: localeId нужно передавать явно, иначе Android использует системный язык. Также пакет не дает доступа к аудиопотоку, что ограничивает кастомизацию.

Сравнение подходов распознавания речи

На iOS SFSpeechRecognizer интегрируется нативно, работает офлайн и поддерживает частичные результаты. Его точность в тихой обстановке достигает 80%, но падает при шуме. На Android SpeechRecognizer дает полный контроль и тоже работает офлайн, однако требует ручного управления жизненным циклом и более чувствителен к совместимости устройств. RecognizerIntent проще, но его системный диалог выглядит чужеродно и не поддерживает частичные результаты на всех устройствах. Для кроссплатформенных проектов пакет speech_to_text удобен, но его гибкость ограничена.

Если требуется высокая точность на специфичной терминологии (медицина, юриспруденция), нативный API не справляется — точность падает до 60%. В таких случаях облачный ASR, например Google Cloud Speech-to-Text, с дообученными моделями повышает точность до 95%+. Облачный ASR точнее нативного в 1,5 раза на сложной лексике.

Как мы это делаем на практике

Однажды мы делали голосовой поиск для медицинского справочника. Требовалось распознавать сложные термины: «лапароскопия», «гастроскопия». Нативный Speech API давал точность около 60%. Мы подключили Google Cloud Speech-to-Text с кастомными SpeechContext и обучили модель на словаре из 5000 терминов. Точность выросла до 95%. Время поиска сократилось в три раза — пользователи оценили. Экономия времени обработки запроса составила 40% по сравнению с базовой интеграцией, а затраты на инфраструктуру ASR окупились за 3 месяца.

Для большинства приложений нативного API достаточно. Если нужна высокая точность на специфичной лексике или работа в шумной среде — подключаем облачный ASR. Анимация уровня звука во время записи не декоративная: на iOS используем AVAudioRecorder.averagePower, на Android — MediaRecorder.getMaxAmplitude. Это дает пользователю ощущение, что микрофон работает.

Почему важно правильно обрабатывать частичные результаты?

Частичные результаты — ключ к хорошему UX. Без них пользователь молчит в пустоту, не зная, слышит ли его приложение. На iOS флаг shouldReportPartialResults = true решает проблему. На Android — EXTRA_PARTIAL_RESULTS. Мы всегда включаем их в проектах — это повышает конверсию поиска на 20% и снижает процент незавершенных запросов в 1,5 раза.

Когда стоит подключить облачный ASR вместо нативного API?

Облачный ASR (Google, Whisper) нужен, когда точность нативного API падает ниже 70%: это происходит при сложной терминологии, шумной среде или мультиязычности. Мы используем его в медицинских, юридических и технических приложениях. Стоимость одного запроса минимальна, а результат — 95%+ точности. Время интеграции увеличивается на 3-5 дней, но окупается за счет качества.

Что входит в работу

• Документация по интеграции Speech API (с примерами кода)
• Исходный код модуля голосового ввода для целевых платформ
• Настройка частичных результатов и нормализации запроса
• Анимация микрофона с индикацией уровня громкости
• Интеграция с поисковым бэкендом
• Тестирование на 10+ реальных устройствах с разными акцентами
• 1 месяц гарантии и поддержки после деплоя

Процесс работы

1. Анализ — определяем языки, тип контента (команды или свободная речь), нужен ли offline.
2. Разработка — запрос разрешений, интеграция Speech API, обработка частичных результатов, анимация микрофона.
3. Нормализация — преобразуем текст в поисковый запрос, убираем шум.
4. Тестирование — проверяем на iOS (разные модели) и Android (версии 6+), исправляем баги.
5. Деплой — публикуем в App Store и Google Play, мониторим отзывы.

Ориентиры по срокам

Чек-лист для успешной интеграции

• [ ] Проверить права на микрофон и speech recognition
• [ ] Выбрать подходящий API (нативный/облачный)
• [ ] Включить частичные результаты на всех платформах
• [ ] Реализовать нормализацию запроса
• [ ] Протестировать на 10+ устройствах с разными акцентами
• [ ] Настроить анимацию уровня звука

Получите консультацию по вашему проекту — оценим задачу за 1 день бесплатно. Закажите реализацию голосового поиска под ключ — наши инженеры с 5+ летним опытом гарантируют результат. Свяжитесь с нами для бесплатной оценки вашего проекта.

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

Мы различаем два принципиально разных подхода: приложение с on-device AI и приложение, которое просто вызывает облачное API. Первое работает без интернета, не отправляет данные пользователя на сторонние серверы и отвечает за 50 миллисекунд. Второе зависит от задержки сети и тарифного плана. Выбор архитектуры — ключевой этап, который напрямую влияет на стоимость, приватность и пользовательский опыт. Наш опыт показывает: в 70% проектов on-device инференс оказывается дешевле в долгосрочной перспективе за счёт исключения серверных затрат.

Как выбрать между CoreML и TFLite для on-device инференса?

CoreML — нативный фреймворк Apple для запуска ML-моделей на устройстве. Поддерживает Neural Engine (начиная с A11 Bionic), GPU и CPU как fallback. Модели конвертируются в формат .mlmodel через coremltools из PyTorch, ONNX или TensorFlow. Конвертация — не всегда тривиальна: кастомные слои требуют реализации MLCustomLayer, а квантизация до INT8 иногда заметно роняет точность на специфических данных. Мы гарантируем, что итоговая модель проходит валидацию на реальных данных до и после конвертации.

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На Android использует NNAPI (Neural Networks API) для хардварного ускорения — с Android 10 NNAPI стабильнее, до этого лучше явно использовать GPU delegate через GpuDelegate. Типичная ошибка: модель обучена на нормализованных данных в диапазоне [0,1], а в приложении на вход подаётся [0,255] — инференс работает, но с бессмысленными результатами без ошибки. Мы включаем модуль автоматической валидации входных данных в SDK.

Для задач классификации изображений, детекции объектов и сегментации доступны готовые оптимизированные модели. YOLOv8 в CoreML формате запускает детекцию кадра 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite с GPU delegate — около 8 мс на Pixel 7 при классификации.

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. Apple Intelligence использует собственные модели через Private Cloud Compute, но для сторонних разработчиков доступны другие пути.

llama.cpp с Metal backend на iOS — работающий подход для phi-3-mini (3.8B параметров, 4-bit квантизация, ~2.3 ГБ). Инференс: 15–25 токенов/секунду на iPhone 15 Pro. Для интеграции в Swift используем Swift Package llama.swift или обёртку через C-интерфейс llama.h. Бинарник к приложению не прикладываем — модель скачивается при первом запуске и хранится в Application Support. Наши сертифицированные разработчики настраивают инкрементальную загрузку, чтобы не блокировать первый запуск.

На Android аналог — Google AI Edge (бывший MediaPipe LLM Inference API) с поддержкой Gemma-2B. Работает через GPU delegate, на Tensor G3 чипе Pixel 8 Pro — около 20 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция OpenAI API и других облачных моделей

Для сценариев, где cloud inference допустим, интеграция OpenAI, Anthropic или Google Gemini — это HTTP клиент + streaming SSE. В Swift удобно через AsyncThrowingStream для стриминговых ответов. В Kotlin — через Flow.

Критически важно: API-ключи никогда не хранятся в бандле приложения. Даже обфусцированный ключ извлекается из IPA за 10 минут через strings или frida. Правильная архитектура: мобильное приложение → собственный backend → OpenAI API. Backend контролирует rate limiting, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

• Обученная и квантизированная модель под целевое устройство (документация по метрикам)
• SDK для интеграции (Swift/Kotlin/Flutter) с примерами вызова
• Тесты производительности на 3–5 реальных устройствах
• Инструкция по обновлению модели OTA
• Поддержка при прохождении модерации App Store / Google Play (проверка соответствия Guidelines 4.2, 5.1)
• 2 недели технической поддержки после релиза

Типичный пайплайн проекта

1. Анализ задачи — замеряем latency, privacy, size, поддерживаемые устройства.
2. Прототипирование модели — в Python, оценка accuracy на целевых данных.
3. Конвертация и квантизация — под CoreML/TFLite с валидацией.
4. Интеграция в приложение — модель оборачивается в сервисный слой (легко подменять CoreML → TFLite → облако).
5. Тестирование — на реальных девайсах, замер FPS, RAM, батареи.
6. Деплой — через TestFlight / Firebase App Distribution, мониторинг метрик.

Сроки: интеграция готовой CoreML/TFLite модели — 1–2 недели, разработка кастомной модели с мобильной оптимизацией — от 6 недель, on-device LLM чат с персонализацией — 4–8 недель.

Почему мы беремся за сложные кейсы?

10+ лет опыта в мобильной разработке, 50+ внедрённых AI/ML решений, гарантия совместимости с актуальными версиями iOS и Android. Все проекты проходят code review и нагрузочное тестирование. В стоимость уже входит подготовка документации для модерации и обучение вашей команды.

Свяжитесь с нами — мы поможем выбрать архитектуру и внедрить ML в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).