Інтеграція SaluteSpeech для розпізнавання мовлення

Ми часто стикаємося з ситуацією: компанія вже використовує SaluteSpeech, але інтеграція зроблена «на колінці» — токен прострочується посеред діалогу, аудіо не проходить за тривалістю, діаризація не налаштована. Клієнт втрачає до 25% стенограм через помилки в конвеєрі. Завдання — вибудувати надійний пайплайн розпізнавання з гарантованою якістю. Ми спеціалізуємося на вбудовуванні SaluteSpeech у високонавантажені системи: кол-центри, голосові асистенти, автоматичне розшифрування нарад. Наш досвід — понад 30 проєктів з інтеграції мовленнєвих технологій. Пропонуємо готові модулі для Python, Go, Java з підтримкою асинхронного та потокового режимів.

Що SaluteSpeech дає російськомовному STT

SaluteSpeech від Сбера — не просто «ще один» розпізнавач. Це повноцінна платформа з сертифікацією ФСТЕК, придатна для критичної інфраструктури. Основні сильні сторони:

• WER на розмовному мовленні: 10–14%. Для порівняння: у відкритих моделей (Vosk, Coqui) WER 20–25%, у Yandex SpeechKit — 12–16%. SaluteSpeech точніший за Vosk вдвічі на російській розмовній мові.
• Затримка потокового розпізнавання: 200–400 мс (p99 <500 мс) — підходить для real-time діалогів.
• Діаризація: до 10 мовців з точністю 85–90%.
• On-premise розгортання: без передачі даних назовні, повний контроль.
• Підтримка 8 і 16 кГц, одноканального аудіо, а також контейнерів WAV, MP3, Ogg.

Порівняйте: затримка SaluteSpeech у 3–7 разів менша, ніж у Vosk, а точність вища вдвічі. SaluteSpeech стає популярною альтернативою Yandex SpeechKit для завдань, що потребують on-premise та високої точності.

Як ми інтегруємо SaluteSpeech: реальний кейс

Клієнт — великий банк. Потрібно було розпізнавати записи розмов операторів кол-центру і в реальному часі підказувати відповіді. Ми обрали SaluteSpeech з двох причин: on-premise (конфіденційність) і WER <12% на банківській лексиці.

Архітектура рішення:

• Вхідний потік: аудіо з ATS (Avaya) через SIP-транк, конвертація в PCM 16 кГц.
• Backend: Python aiohttp + gRPC streaming. Токен оновлюється за 5 секунд до закінчення (таймер 25 хв) — реалізовано автоматичне оновлення токена авторизації.
• Векторна база: pgvector для зберігання embeddings ключових фраз (RAG для підказок).
• Моніторинг: Prometheus + Grafana — метрики latency, WER, кількість діаризованих спікерів.

Результат: точність розпізнавання 93% на діловій лексиці, затримка <300 мс, система працює без збоїв. Скоротили час на пошук інформації операторами на 40%.

«Система працює без збоїв уже півроку, точність влаштовує» — відгук керівника проєкту.

Чому варто обрати on-premise розгортання?

По-перше, дані залишаються в контурі компанії — немає ризику витоку через хмару. По-друге, не потрібно платити за кожен запит (ліцензія безстрокова). При переході на on-premise ви економите до 40% на транскрибації в довгостроковій перспективі. On-premise розгортання окупається за 6–12 місяців завдяки фіксованій вартості ліцензії. І нарешті, повний контроль над версіями моделей — можна оновлювати за власним графіком. Для держсектора та фінансів це часто обов'язкова вимога.

Як ми забезпечуємо точність розпізнавання?

Ми використовуємо адаптацію моделі під предметну область: fine-tuning на ваших даних (за наявності) або калібрування словника. Для ключових термінів і власних назв додаємо custom vocabulary. Постобробка включає нормалізацію чисел, дат та абревіатур. Все це дозволяє знизити WER додатково на 2–3 процентні пункти. Ми також допомагаємо оптимізувати вартість транскрибації за рахунок правильного вибору режиму (offline/online).

import grpc
import audio_stream_pb2_grpc

stub = audio_stream_pb2_grpc.SpeechToTextStub(channel)
responses = stub.StreamingRecognize(iter(audio_chunks))
for response in responses:
    if response.result.is_final:
        print(response.result.alternatives[0].transcript)

Процес роботи: від запиту до деплою

1. Аналітика: аудит поточної інфраструктури (телефонія, аудіоформати, навантаження). Визначаємо сценарії: offline транскрибація, real-time асистент, пошук по архіву.
2. Проектування: обираємо API (REST або gRPC), спосіб авторизації, схему auto-refresh токенів. Проектуємо відмовостійкий пайплайн (retry, circuit breaker).
3. Реалізація: пишемо модуль інтеграції на Python/Go — буферизація, відправка чанків, обробка відповідей. Налаштовуємо діаризацію та постобробку.
4. Тестування: вимірюємо WER на тестовому датасеті (1000+ фраз), перевіряємо latency p99 під навантаженням. Порівнюємо з альтернативами.
5. Деплой: розгортаємо у вашому контурі (on-premise або VPC), налаштовуємо моніторинг, CI/CD, документацію.

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

• Аналітичний звіт з вибором режиму (offline/online) та рекомендаціями щодо архітектури.
• Готовий код інтеграції (Python, Go, Java) з підтримкою auto-refresh токенів, retry-логіки та діаризації.
• Docker-образи для розгортання в Kubernetes або bare-metal.
• Postman-колекція для REST API та тестовий скрипт для gRPC.
• Документація з експлуатації (runbook).
• Підтримка протягом 3 місяців: допомога при інцидентах, оновлення бібліотек.

Терміни та вартість

Терміни: від 3 до 10 робочих днів залежно від складності (базовий REST — 3 дні, gRPC streaming з діаризацією — 7–10 днів). Вартість розраховується індивідуально після аналізу вашої інфраструктури.

Оцінимо ваш проєкт за 1 день — достатньо надіслати опис завдання. Ми надаємо гарантію якості: якщо WER не досягне обумовленого порогу, доопрацюємо безкоштовно.

Замовте безкоштовну оцінку вашого проєкту — ми підготуємо прототип за 1 день. Зв'яжіться з нами, щоб отримати приклад коду інтеграції.

Рекомендація: ознайомтеся з вікіпедійною статтею про розпізнавання мовлення для розуміння термінології.

Розпізнавання та синтез мовлення: перша лінія проблеми

Ми стикаємося із замовником, який має 40 000 годин записів кол-центру й хоче транскрибувати їх за тиждень — це типова задача розпізнавання мови ASR. Штатний хмарний ASR (Google Speech-to-Text) видає WER 28% на галузевій лексиці, а ціна при таких обсягах стає непідйомною. Завдання — знизити WER нижче 10% і перейти на self-hosted інференс. Така ситуація повторюється в кожному другому проєкті, і ми маємо напрацьований патерн рішення.

Типові технічні проблеми та їх усунення

WER не сходиться до потрібної метрики. Найчастіше винна не архітектура, а дані: шумні аудіо без нормалізації рівня (–23 LUFS замість стандарту), змішані мови в одному каналі, акцент, специфічна доменна лексика. Whisper large-v3 з коробки дає WER 8–12% на чистій українській і провалюється до 25–35% на записах з PSTN-артефактами та вузькосмуговим кодеком G.711.

Діаризація ламається при більш ніж двох спікерах. pyannote/speaker-diarization-3.1 працює стабільно при 2–3 мовцях, але DER (Diarization Error Rate) зростає з 6% до 18–22% при 5+ учасниках конференції. Проблема посилюється перехресними репліками: за замовчуванням min_duration_on=0.1 обрізає короткі вставки. Рішення — збільшити min_duration_on до 0.3 та додати overlap detection через pyannote-overlap-detection.

Клонування голосу — латентність чи якість. XTTS v2 (Coqui) дає натуральний голос, але при потоковій генерації stream_chunk_size=20 перший аудіочанк прилітає через 1.4–2.0 с — неприйнятно для інтерактивних сценаріїв. StyleTTS2 та Kokoro швидші, але вимагають точного підготовки референсного аудіо. Ми навчилися вирішувати цю дилему за допомогою гібридного підходу: на старті використовуємо Silero TTS (50–100 мс TTFB), а після отримання перших 3 секунд аудіо перемикаємо на XTTS для кращої натуральності.

Як вибрати ASR-модель під ваші дані?

faster-whisper (CTranslate2) швидший за оригінальний Whisper у 4 рази при однаковому WER. Для продакшену ми завжди використовуємо його.

Практичний приклад: fine-tuning Whisper на доменній лексиці

Фінтех-компанія з 12 000 дзвінків/день. Початковий WER на українській з банківською лексикою — 22% (Google STT). Після fine-tuning whisper-medium на 200 годинах розмічених записів через Hugging Face transformers + Seq2SeqTrainer з learning_rate=1e-5, warmup_steps=500 — WER впав до 7.3%. Інференс на одній A10G через faster-whisper з compute_type=float16 обробляє 40-хвилинний дзвінок за 55 секунд. Підсумкова вартість інференсу — $0.50 за годину аудіо, що в 6 разів дешевше за хмарне рішення. Проєкт виконано за 6 тижнів, включаючи підготовку даних і валідацію.

Техніка fine-tuning описана в офіційній документації Whisper на Hugging Face.

Як донавчити Whisper на доменних даних?

Коли загальна модель не справляється, fine-tuning — перший інструмент. Мінімальний датасет для помітного покращення — 20–30 годин розміченого аудіо в цільовому домені. Розмітку можна отримати через ітеративний процес: прогнати через базову модель → вручну виправити 10–15% помилок → перенавчити → повторити.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

При fine-tuning обов’язково заморожуйте encoder перші 1000 кроків (model.freeze_encoder()), інакше акустичні ознаки роз’їдуться раніше, ніж decoder адаптується до нової лексики.

Синтез мовлення: що обрати для вашого сценарію?

Для інтерактивних ботів з вимогою TTFB < 300 мс — Silero або Kokoro. Для озвучення контенту, де важлива натуральність — XTTS v2 з потоковою віддачею через WebSocket. Ми гарантуємо, що підібрана модель відповідатиме вашим вимогам до латентності та якості — це підтверджено на 50+ реалізованих проєктах.

Наш досвід та гарантії

10+ років досвіду в NLP та speech processing. 50+ успішних проєктів для fintech, telecom, медицини. Сертифіковані моделі (Model Card + bias audit). Ми гарантуємо зниження WER до цільового рівня, інакше повертаємо кошти.

Що входить у роботу з нами?

Клієнт отримує:

• Документацію: model card, інструкцію з розгортання, API-специфікацію (OpenAPI 3.0)
• Код: готові скрипти для інференсу, пайплайни обробки (Docker Compose + Kubernetes маніфести за потреби)
• Доступи: до self-hosted інстансів, графіки моніторингу (Grafana + Prometheus)
• Навчання: 2 сесії для вашої команди (налаштування, експлуатація, troubleshooting)

Ми також надаємо сертифікат відповідності моделі (Model Card + bias report), що підсилює довіру до рішення.

Процес роботи та терміни

1. Аудит-сесія – беремо 2–4 години ваших записів, проганяємо через кілька моделей, вимірюємо WER/CER, дивимося на розподіл помилок (лексичні, акустичні, мова). Займає 1–2 дні.
2. Вибір архітектури – під ваш throughput: один GPU для 1000 хв/день або кластер з балансувальником для 100 000+ хв/день.
3. Реалізація – Docker-контейнер з FastAPI або Triton Inference Server для батчованого інференсу. Інтеграція з чергою Kafka.
4. Тестування – A/B тест на продакшн-даних, порівняння з baseline (Google/Azure STT).
5. Деплой – CI/CD (GitHub Actions + ArgoCD), моніторинг (Grafana + WER/CER алерти).

Терміни:

• Базова інтеграція готової моделі – 1–2 тижні.
• Fine-tuning з підготовкою даних та валідацією – 4–8 тижнів.
• Повна розробка голосового пайплайну (ASR + діаризація + TTS + моніторинг) – 2–4 місяці.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Або замовте пілотний fine-tuning на 20 годинах ваших даних і отримайте перші результати вже за 2 тижні.