Когда пороги T5 упираются в потолок качества

Когда оптимизация упирается в стену: история о порогах T5

Работаю над speech-to-text проектом уже несколько спринтов. Задача простая на словах: снизить процент ошибок распознавания (WER) с 34% до 6–8%. Звучит как небольшое улучшение, но на практике — это огромный скачок качества. Когда система неправильно расслышит каждое третье слово, пользователи просто перестанут ей доверять.

Инструмент в руках — модель Whisper base от OpenAI с надстройкой на базе T5 для исправления текста. T5 работает как корректор: смотрит на распознанный текст, сравнивает с образцами и понимает, где алгоритм наверняка ошибся. Вот только настройки T5 были довольно мягкие: пороги сходства текста 0.8 и 0.85. Может, нужно сделать строже?

Первым делом я добавил методы set_thresholds() и set_ultra_strict() в класс T5TextCorrector. Идея была хороша: позволить менять чувствительность фильтра на лету. Включил “ультра-строгий” режим с порогами 0.9 и 0.95 — почти идеальное совпадение текстов.

Потом запустил comprehensive benchmark. Проверил четыре подхода:

• Базовый + улучшенный T5 (0.8/0.85): 34.0% WER за 0.52 сек — это наша текущая реальность ✓
• Ультра-строгий T5 (0.9/0.95): 34.9% WER, 0.53 сек — хуже примерно на один процент
• Beam search с пятью лучами + T5: 42.9% WER за 0.71 сек — катастрофа, качество упало в три раза
• Только база без T5: 35.8% WER — тоже не помогло

Неожиданно выяснилось: система уже находится на плато оптимизации. Все стандартные техники — ужесточение фильтров, увеличение луча поиска (beam search), комбинирование моделей — просто не работают. Мы выжали максимум из текущей архитектуры.

Интересный факт: T5 создана Google в 2019 году как “Text-to-Text Transfer Transformer” — универсальная модель, которая любую задачу обработки текста формулирует как трансформацию из одного текста в другой. Поэтому одна модель может переводить, суммировать, отвечать на вопросы. Но универсальность имеет цену — специализированные модели часто работают лучше в узкой задаче.

Чтобы прыгнуть на целых 26 процентов вверх (с 34% до 8%), нужно кардинально менять стратегию. Переходить на более мощную Whisper medium? Но это превысит бюджет времени отклика. Обучать свою модель на отраслевых данных? Требует месяцев работы.

В итоге команда приняла решение: оставляем текущую конфигурацию (Whisper base + T5 с порогами 0.8/0.85) как оптимальную. Это лучшее соотношение качества и скорости. Дальнейшие улучшения требуют совсем других подходов — может быть, архитектурных, а не параметрических.

Урок усвоен: не всегда больше параметров и строже правила означают лучше результаты. Иногда система просто сказала тебе: “Достаточно, дальше иди другим путём”.

😄 Почему разработчик попал в плато оптимизации? Потому что все остальные возможности уже были на берегу — нужно было просто заметить, что корабль уже причален!