Багатомікрофонне розпізнавання мови з діаризацією та AEC

Проблема та технічні складності

Уявіть переговорну на вісім осіб — кожен говорить, мікрофони на столі ловлять суміш голосів, луна від динаміків, шум кондиціонера. Звичайний STT з одним мікрофоном дає Word Error Rate (WER) 35–40% при двох активних мовцях. Без просторової обробки діалог перетворюється на нечитабельну кашу. Ми вирішуємо це завдання за допомогою масиву мікрофонів, адаптивного Beamforming, AEC та діаризації мовців. Після впровадження нашої системи в одного з клієнтів WER впав з 45% до 8%, а протокол зустрічі став придатним для аналізу. Економія на обробці записів зустрічей склала до 40% (вартість рішення від $15 000, окупність 3–6 місяців). Наша команда має понад 5 років досвіду в speech processing та виконала понад 50 проєктів.

Основні проблеми — перекриття мовлення, луна та реверберація, а також синхронізація багатоканального звуку. Перекриття: коли дві людини говорять одночасно, без просторового розділення діаризація помиляється в 30% випадків. Луна: динаміки відеоконференції повертають звук колонок назад у мікрофони — без AEC розпізнавання збивається (WER зростає до 60%). Реверберація в приміщенні з твердими стінами додає хвости тривалістю до 0.5 с — звичайний Delay-and-Sum їх не прибирає. Для синхронізації використовуємо PTP (Precision Time Protocol) на мікрофонних масивах, щоб уникнути дрейфу затримок. Допустиме розходження — не більше 1 семпла при частоті 16 кГц.

Кейс: зниження WER з 45% до 8% з нашої практики

У проєкті для конференц-залу нашого клієнта (виробнича компанія) ми зібрали лінійний масив з 4 мікрофонів, реалізували Delay-and-Sum beamformer, потім подавили луну через WebRTC AEC, і тільки після цього передавали сигнал у STT. Результат: точність розпізнавання зросла з 45% (один мікрофон) до 92%. Використання масиву мікрофонів знижує WER у 5 разів порівняно з одним мікрофоном. Код DelayAndSumBeamformer використовує координати мікрофонів і швидкість звуку для обчислення затримок. Але цього недостатньо в ревербераційних приміщеннях — там потрібен MVDR або GSC beamformer. Для типової переговорної достатньо лінійного масиву з відстанню 10 см між елементами.

import numpy as np
from scipy.signal import correlate

class DelayAndSumBeamformer:
    def __init__(self, mic_positions: np.ndarray, sample_rate: int = 16000):
        self.mic_positions = mic_positions  # (n_mics, 3) координати в метрах
        self.sample_rate = sample_rate
        self.speed_of_sound = 343.0  # м/с

    def compute_delays(self, direction: np.ndarray) -> np.ndarray:
        delays = np.dot(self.mic_positions, direction) / self.speed_of_sound
        delays -= delays.min()
        return (delays * self.sample_rate).astype(int)

    def beamform(self, signals: np.ndarray, direction: np.ndarray) -> np.ndarray:
        delays = self.compute_delays(direction)
        output = np.zeros(signals.shape[1])
        for i, delay in enumerate(delays):
            output += np.roll(signals[i], -delay)
        return output / len(delays)

Чому діаризація важлива? Налаштування

Після beamforming сигнал все ще може містити голоси кількох людей. pyannote.audio 3.1 з переднавченою моделлю дає розмітку з точністю до 0.5 секунди. Ми налаштовуємо поріг активності голосу (VAD), кількість мовців та мінімальну довжину фрагмента. Без діаризації транскрибація буде змішувати репліки.

from pyannote.audio import Pipeline

pipeline = Pipeline.from_pretrained(
    "pyannote/speaker-diarization-3.1",
    use_auth_token="YOUR_HF_TOKEN"
)

diarization = pipeline("beamformed_output.wav", num_speakers=4)
for turn, _, speaker in diarization.itertracks(yield_label=True):
    print(f"{speaker}: {turn.start:.1f}s - {turn.end:.1f}s")

Порівняння технологій

Порівняння алгоритмів beamforming

MVDR придушує реверберацію приблизно в 2 рази ефективніше за Delay-and-Sum, але вимагає більше обчислювальних ресурсів.

Порівняння мікрофонних масивів

Лінійний масив простіший у калібруванні, круговий дає краще розділення мовців по колу.

Як покроково налаштувати beamforming для переговорної?

1. Виміряйте акустику приміщення: рівень реверберації (RT60) та розташування джерел шуму.
2. Виберіть мікрофонний масив: лінійний 4–6 мікрофонів для стандартної кімнати.
3. Реалізуйте захоплення звуку з синхронізацією через PTP або програмну кореляцію.
4. Застосуйте Delay-and-Sum для первинного формування променя, потім MVDR при високому рівні реверберації.
5. Додайте AEC для придушення луни від динаміків відеоконференції.
6. Використовуйте VAD та діаризацію для розділення мовців, потім передайте кожен сегмент у STT.

Технічні деталі реалізації AEC

Терміни та обсяг робіт

Орієнтовні терміни

• Базовий прототип з beamforming та STT: від 1 тижня — якщо акустика приміщення проста.
• Додавання AEC та noise reduction: ще від 1 тижня.
• Повна система з діаризацією, dereverberation та калібруванням під масив: від 3 до 4 тижнів.
• Термін залежить від кількості мовців та рівня реверберації.

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

• Проєкт архітектури масиву мікрофонів.
• Реалізація beamforming, AEC, noise reduction, діаризації.
• Інтеграція з STT (Whisper, Vosk, Azure Speech).
• Розробка API для інтеграції у вашу систему.
• Документація з налаштування та експлуатації.
• Навчання ваших інженерів.
• Гарантійна підтримка 1 місяць.

Вартість рішення — від $15 000, економія до 40% операційних витрат (до $10 000 на рік для середнього бізнесу).

Типові помилки та наступні кроки

Типові помилки при впровадженні

• Використовувати WebRTC AEC без попереднього калібрування — луна залишається.
• Розміщувати мікрофони ближче 5 см до динаміків — AEC не справляється.
• Забувати про синхронізацію тактових частот — дрейф часових міток ламає beamforming.
• Відключати Voice Activity Detection — зайві шуми засмічують діаризацію.

Отримайте консультацію з оснащення переговорної

Зв'яжіться з нами — ми проаналізуємо акустику вашої переговорної, підберемо мікрофонний масив та алгоритми. Оцінимо проєкт за 1–2 дні. Наші інженери мають сертифікати з мовного аналізу та виконали понад 50 проєктів у галузі speech processing. Компанія працює на ринку з 2016 року. Замовте консультацію — розповімо, як знизити WER та налагодити транскрибацію зустрічей.

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

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