Налаштування Google Cloud Speech-to-Text для продакшену

Налаштування Google Cloud Speech-to-Text для високої точності

Уявіть: ваш додаток щодня обробляє 10 000 годин діалогів, і клієнти скаржаться, що система розпізнає лише 70% імен. WER (Word Error Rate) на російській у Google Cloud STT без адаптації — 8–12%, цього недостатньо для продакшену. У кол-центрах кожна помилка в імені клієнта — втрата довіри, а в медичній транскрибації — ризик для пацієнта. Ми вже стикалися з такими завданнями: налаштування adaptive vocabulary та діаризації піднімає точність до 95%+. Зниження WER на 10% може заощадити до 30% бюджету на ручну перевірку транскрибації, а оптимізація витрат на інфраструктуру — ще 15–20%.

У цій статті ми розберемо, як налаштувати Google Cloud Speech-to-Text для досягнення максимальної точності. Згідно з офіційною документацією, правильний вибір моделі та конфігурації може знизити WER удвічі. За визначенням з Вікіпедії, WER — стандартна метрика для оцінки точності розпізнавання. Розглянемо ключові параметри, які ми налаштовуємо в кожному проєкті.

Проблеми, які ми вирішуємо

• Низька точність на доменній лексиці. Без адаптивного словника модель ріже рідкісні терміни, імена та жаргон. Наприклад, у кол-центрах WER на назвах продуктів може досягати 25%.
• Затримки в реальному часі. Неправильний вибір режиму (пакетний замість потокового) додає секунди до latency, що критично для голосових асистентів.
• Висока вартість при великих обсягах. Використання універсальної моделі chirp для коротких аудіо подвоює витрати. Оптимізація під сценарій знижує вартість на 15–20%.

Як адаптивний словник знижує WER?

Adaptive vocabulary (PhraseSets) з коробки вирішує проблему рідкісних слів. Ви додаєте до 5000 фраз — імена, жаргон, назви продуктів. Приклад: при розпізнаванні технічної документації WER падає з 12% до 6%. Без цього модель часто ріже специфічні терміни, особливо в потоці.

На практиці ми збираємо корпус із типових діалогів, очищаємо його та формуємо PhraseSets з вагами. Це потребує всього 1–2 дні, але окупається на першому ж тижні експлуатації.

Чому варто використовувати потокове розпізнавання?

Потокове краще для інтерактивних продуктів, але пакетне дає точніші таймкоди та дешевше на великих обсягах. Ми комбінуємо обидва підходи, щоб збалансувати latency та cost. Наприклад, для кол-центру потокове розпізнавання обробляє live-діалоги, а пакетне — нічні ретроспективні звіти.

Порівняння моделей Google Cloud STT

Вибір моделі безпосередньо впливає на вартість. Наприклад, chirp коштує дорожче, тому для коротких аудіо вигідніше latest_short.

Як налаштувати адаптивний словник: покрокова інструкція

1. Зберіть мінімум 50–100 типових фраз з рідкісними словами.
2. Створіть PhraseSet у GCP Console або через API.
3. Вкажіть ваги (boost) для ключових фраз.
4. Протестуйте на тестовій вибірці та оцініть WER.
5. Повторіть цикл до досягнення цільової точності.

Цей процес займає 1–2 дні, але знижує WER на 10–15% на доменній лексиці.

Базова інтеграція

from google.cloud import speech

client = speech.SpeechClient()
config = speech.RecognitionConfig(
    encoding=speech.RecognitionConfig.AudioEncoding.LINEAR16,
    sample_rate_hertz=16000,
    language_code="ru-RU",
    model="latest_long",
    enable_automatic_punctuation=True,
    enable_word_time_offsets=True,
    use_enhanced=True,
)

Цей код — стартова точка. Для продакшену додаємо обробку помилок, таймаути та пул з'єднань gRPC. Також варто налаштувати моніторинг latency та кількості помилок через Cloud Monitoring.

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

• Аналіз вашого аудіотракту: формат, бітрейт, частота дискретизації.
• Вибір моделі та оптимізація конфігурації під ваш сценарій (діаризація, фільтри, мовні підказки).
• Інтеграція потокового та/або пакетного розпізнавання з вашим бекендом.
• Налаштування адаптивного словника: збір та чистка фраз, тестування на тестовій вибірці.
• Документація API, опис архітектури, навчання ваших інженерів.
• Підтримка при релізі та гарантія стабільної роботи 3 місяці.

Типові помилки при інтеграції

• Використання моделі chirp для коротких аудіо — вона дорожча і не дає виграшу в точності.
• Ігнорування частоти дискретизації: невідповідність sample_rate призводить до артефактів.
• Відсутність пулу gRPC-з'єднань — при високому навантаженні latency зростає.
• Пропуск етапу тестування адаптивного словника на реальних даних.

Строки інтеграції

Базова інтеграція: 2–4 дні. З адаптивним словником та діаризацією — 5–7 днів. Повне рішення з streaming + batch під ключ: 10–14 днів.

Отримайте консультацію щодо вашого проекту — ми оцінимо обсяг аудіо, вимоги до точності та запропонуємо оптимальну архітектуру. Замовте пілотну інтеграцію одного сценарію для перевірки якості.

Досвід: ми працюємо з GCP Speech-to-Text та супутніми сервісами, маємо сертифікати професійних інженерів. За кілька років реалізували понад 20 інтеграцій для кол-центрів, EdTech та медичних застосунків.

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

Ми стикаємося із замовником, який має 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 тижні.