ИИАвтоматизация

Пока вы выбираете ИИ модель, эхо выбирает ваш результат

Андрей Мелков
6

Если вы делаете “ИИ-протокол по аудиозаписи”, вы очень быстро понимаете неприятное: точность чаще ломает не модель, точность ломает помещение. Мы делали систему автоматического формирования протокола судебных заседаний. Вводные были жёсткие:

  • проект под NDA
  • запись длинная, много участников, важны формулировки
  • нельзя зависеть от “сторонних сервисов”, нужна работа на локальном сервере
  • цель — сократить ручной труд и ускорить подготовку протокола

Подробнее в кейсе Судебный протокол

Если вы делаете “ИИ-протокол по аудиозаписи”, вы очень быстро понимаете неприятное: точность чаще ломает не модель. Точность ломает помещение.

Контекст проекта

Мы делали систему автоматического формирования протокола судебных заседаний. Вводные были жёсткие:

  • проект под NDA
  • запись длинная, много участников, важны формулировки
  • нельзя зависеть от “сторонних сервисов”, нужна работа на локальном сервере
  • цель — сократить ручной труд и ускорить подготовку протокола

Подробнее в кейсе: Судебный протокол

Где ломается магия: аудио ≠ текст

Классическая ошибка в таких проектах: считать, что распознавание речи — это “выбор модели”.

На практике получилось, что это сам сигнал. Потому что запись заседания — это:

  • расстояние до микрофона
  • разные тембры и громкость
  • бумага, шаги, вентиляция
  • и главный враг: реверберация (эхо помещения)

Шум вы хотя бы замечаете.
А эхо часто “вроде терпимо” для человека, но для распознавания речи оно размывает границы слов — и дальше модель начинает уверенно угадывать.

И вот тут появляется риск: “красивый текст” может быть неверным по смыслу.

Что мы сделали: перестали “просить модель” и начали лечить вход

Мы провели свое небольшое исследование - как предобработка аудио влияет на качество распознавания. Тестировали 16 вариантов обработки на 9 аудиозаписях и сравнили распознавание:

  • локальной моделью Whisper (faster-whisper, large-v3)
  • и облачным вариантом (OpenAI Whisper API, whisper-1) — как контроль/сравнение подходов.

Метрики — WER/CER (ошибки по словам/символам), чтобы не спорить “на слух”.

3 базовых подхода, которые реально можно внедрить

  1. FFmpeg-пайплайн (быстро и дёшево)
    highpass (убираем гул) → afftdn (подавляем шум) → loudnorm (нормализуем громкость)

  2. Denoise (шумоподавление)
    Spectral gating (noisereduce) — полезно, когда шум реально доминирует.

  3. Dereverb (убрать реверберацию)
    WPE (nara-wpe) — когда запись сделана в большом помещении и эхо съедает разборчивость.

Плюс — комбинации и порядок применения (и вот тут начинается самое интересное).

Главный результат: лучший метод зависит от того, чем распознаёте

Если распознаёте локально

Лучший результат дал dereverb (WPE):

  • средний WER: 0.9295
  • улучшение к baseline: 6.9%

Если распознаёте через облачный API

Лучший результат дала связка FFmpeg → dereverb:

  • средний WER: 1.0007
  • улучшение к baseline: 23.9%

То есть для облака “подготовить сигнал” перед dereverb оказалось критично.

Еще важно заметить, что мы сравнивали с реальным текстом, который прослушали и записали как оригинал, и сравнение шло "распознанный текст" - "оригинальный текст".

Второй результат: порядок методов важнее, чем кажется

Одинаковые методы в разном порядке дают разный итог:

  • ffmpeg-dereverb лучше, чем dereverb-ffmpeg (особенно для API)
  • для некоторых связок “сначала denoise” лучше, чем “denoise потом” — но это зависит от провайдера

Тут важно понимать, что просто добавить фильтры “на всякий случай” может привести к худшему результату.

Третий результат: “чем больше обработок — тем хуже”

Трёхэтапные цепочки в среднем показали худшие результаты, чем простые методы или пары.
Это важный вывод: не надо усложнять пайплайн, надо усложнять только там, где есть понятная выгода.

Итог исследования

Если вам нужно “протоколирование из аудио” в рабочей среде, то логика следующая:

  • Есть эхо/большое помещение/"бульканье" → начинайте с dereverb (локально — это часто лучший первый шаг).
  • Нужно быстро, дешево, массовоFFmpeg как базовая санитарная обработка.
  • Используете облачный ASR → в большинстве случаев выигрывает FFmpeg → dereverb.
  • Не “переобрабатывайте”: несколько фильтров подряд часто ухудшают итог.

И дальше начинается продуктовый уровень: контроль качества (ОТК) — когда система сама понимает, что запись “плохая” и требует проверки человеком.

Где ещё применимо (кроме судов)

Это один класс задач: “длинная речь → документ, который становится источником правды”. Поэтому применимость ровно там же, где в кейсе: корпоративные совещания, комитеты/советы директоров, интервью, адвокатские структуры, вузы.

Если вы строите систему протоколирования, вы строите не чат-бота. Вы строите конвейер качества: звук → обработка → распознавание → структура → контроль.

И самый быстрый прирост точности часто даёт не новая модель, а правильный ответ на вопрос: “что у нас на входе?”

Каждый из таких клиентов (задач, кейсов... как угодно называйте), дает понимание, что базовые настройки и подходы дают очень плохой результат, и поэтому при внедрении искусственного интеллекта в процессы нужно понимать, даст ли решение вашей задачи с помощью ИИ реальную выгоду в бизнесе или это будет очередной слив денег в дорогую игрушку. Подходите к внедрению рационально.

Подпишитесь на наш блог

Получайте новые статьи и полезные материалы о автоматизации бизнеса прямо на почту