Багатомовне STT: гібридне розпізнавання мовлення з автоматичним визначенням мови

Багатомовне розпізнавання мовлення: де ламається потік

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

За неправильно обраної мови модель не мовчить — вона добудовує фонетику до слів чужої мови, і в розшифруванні з’являються осмислені, але хибні фрази, які потім ніхто не шукає і не перевіряє.

Визначення мови на льоту прибирає ручний крок, але додає свій клас помилок. Класифікатор, який дивиться на перші секунди запису, на коротких репліках не набирає статистики: «так», «ок», «добре» та власні назви потрапляють то в одну мову, то в іншу.

Кожне таке перемикання скидає контекст розпізнавання, і точність падає саме на службових фразах, де помилка викривляє зміст найсильніше.

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

Поверх цього лягає шум переговорних — далекий мікрофон, луна, накладання голосів — і предметна лексика: артикули, абревіатури, назви препаратів і деталей, яких немає в базовому словнику.

Модель впевнено замінює їх схожими за звучанням словами, і розшифрування стає формально читабельним, але непридатним для роботи.

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

Тому в гібридній схемі мова й мовець визначаються на коротких сегментах, гіпотези зберігаються поруч, а вибір робиться за накопиченим контекстом. Розбираємо, як це закривається на практиці.

Що дає автовизначення мови в гібридній схемі

Автовизначення мови прибирає зі схеми ручний крок, який найчастіше й дає помилки: оператор більше не обирає мову доріжки і не перемикає її на ходу.

Сегмент спочатку проходить детектор мови на короткому вікні — фонетичної та складової статистики достатньо, щоб ухвалити рішення до того, як у модель піде весь запис.

Якщо впевненість нижче порогу, фрагмент обчислюють дві акустичні моделі паралельно, а вибір іде за узгодженістю гіпотез із мовним профілем проєкту, тому спірна ділянка не «залипає» на неправильній мові до кінця доріжки.

Гібридна схема розпізнавання поєднує потоковий контур для коротких реплік і офлайн-модель Whisper для довгих фрагментів: чорновий текст з’являється майже одразу, а фінальний варіант перераховується з більшим контекстом.

Обидва контури працюють з одним мовним профілем — спільним словником термінів, імен, абревіатур і одиниць вимірювання. Це і є ключовим: під час перемикання контуру не розходяться написання, і вичитка не перетворюється на звіряння двох невідповідних транскриптів.

На змішаному мовленні — перемикання мов усередині однієї фрази, запозичення, терміни латиницею в російському реченні — мітка мови ставиться на рівні слова, а не абзацу.

Частка помилок на змішаному мовленні тримається в межах пари відсотків від одномовних сегментів замість кратного провалу. Частка правок після вичитки падає з 18–20% до 5–7%, а ручний вибір мови зникає з інтерфейсу оператора разом із класом помилок «забув перемкнути».

Режими роботи: потоковий, пакетний, відкладений розбір

Режим розбору обирається не за «якістю моделі», а за сценарієм: десь текст потрібен, поки людина ще говорить, а десь — вивірений документ після запису.

На практиці рішення визначають три питання: чи потрібен текст під час мовлення, чи важлива стійкість за нестабільного зв’язку і чи є запас часу на повторний прохід.

Три режими не конкурують між собою — на одному контурі вони часто працюють одночасно, а затримка видачі тексту стає усвідомленим компромісом.

Три режими та їхні межі

Автовизначення мови працює в усіх трьох режимах, але по-різному: у потоковому режимі мова фіксується за першими фразами й уточнюється далі, у пакетному — за всім файлом одразу, що стійкіше на коротких репліках.

Якщо сценарій не вкладається в один режим, збираємо гібрид: потоковий канал для оперативної видачі та відкладений прохід по спірних ділянках, при цьому зберігаються обидва варіанти тексту й розбіжності видно під час розбору.

Як ми впроваджуємо: етапи інженерної роботи

Робота починається не з вибору моделі, а з аудиту аудіоматеріалу: слухаємо вибірку реальних записів, рахуємо частку шуму й перекриттів, довжину реплік, число мов і частоту їх перемикання всередині однієї фрази.

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

1. Аудит аудіоматеріалу. Розбираємо канали, формати й якість запису, відзначаємо типи шуму, акценти та діалекти. На виході — перелік сценаріїв, які рішення зобов’язане тримати.
2. Розмітка мов. Вивіряємо навчальну та перевірну вибірки, окремо позначаємо фрагменти зі змішаним мовленням і перемиканням мови всередині фрази, фіксуємо критерії правильного розпізнавання.
3. Маршрутизація запитів. Визначаємо логіку: швидке визначення мови за коротким фрагментом, потім розпізнавання профільною моделлю; за низької впевненості запис іде на повторну обробку.
4. Налаштування та складання. Дообучуємо моделі на розмічених даних, налаштовуємо параметри визначення мови й нарізки на репліки, збираємо все в єдиний потік із журналом обробки.
5. Контрольна вибірка. Проганяємо фіксований набір записів, яких не було в навчанні, і звіряємо з еталоном за кожною мовою окремо — дивимося не середню точність, а найгірші сценарії.
6. Передавання в експлуатацію. Віддаємо регламент оновлення моделей, метрики якості та пороги спрацювання, навчаємо команду замовника розбирати спірні розшифрування.

Що залишається у вас: конфігурації, схеми, регламенти

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

• Конфігурація розпізнавання — робочі профілі під кожну мову та канал: пороги впевненості, параметри нарізки аудіо на фрагменти, розділення реплік за мовцями, поведінка за низької якості запису.
• Схема маршрутизації — як потік потрапляє на потрібний мовний модуль: автовизначення мови, пріоритети за змішаного мовлення, правила перемикання всередині однієї розмови.
• Словник предметної лексики — терміни, абревіатури, назви продуктів і посад із варіантами вимови. Це те, що знижує частку помилок на доменних словах.
• Регламент оновлення моделей — порядок викочування нових версій: як перевіряється якість до включення в потік, хто підтверджує заміну, як відкочуються за просідання точності.
• Набір перевірок якості — тестові записи з еталонними розшифруваннями, метрики за кожною мовою, звіт за часткою помилок на слові та за відмовами розпізнавання.
• Схема інтеграції — інтерфейси приймання аудіо та видачі тексту, формати обміну, поведінка системи за недоступності зовнішніх сервісів і за перевантаження.
• Експлуатаційна документація — розбір типових інцидентів, точки моніторингу, порядок видачі доступів і межі відповідальності між вашою та нашою командою.

Артефакти передаємо у вигляді, придатному для правок без нас: конфігурації в текстовому вигляді, схеми з описом зв’язків, словники й тестові набори у відкритих форматах.

Кейс: контакт-центр на п’яти мовах, метрики до і після

Контакт-центр працював на п’яти мовах — російська, англійська, німецька, польська та іврит, — причому мова змінювалася всередині одного діалогу: клієнт починав російською, уточнення йшло німецькою.

Розшифрування робили вручну, по одному запису за раз, тому аналітика якості надходила із затримкою в добу, а частка ручних правок сягала третини тексту.

Зібрали гібридну схему: визначення мови на коротких вікнах потоку, потім маршрутизація відрізка в потрібну мовну модель. База — відкрита модель Whisper з дообученням на галузевій лексиці: назви тарифів, обладнання, внутрішні абревіатури.

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

Що змінилося в метриках

Ручна вичитка перестала бути вузьким місцем: редактор переглядає лише позначені відрізки — це близько 6% тексту. Аналітика за скриптами та причинами звернень будується на повному масиві діалогів, а не на вибірці.

Відмов на змішаних фрагментах майже не залишилося: спірні вікна закриває другий прохід із мовною моделлю сусіднього відрізка. Колектив не збільшували, а обсяг оброблюваних звернень зріс майже вдвічі.

Чим відрізняється автовизначення мови від фіксованого профілю

Фіксований мовний профіль — це коли акустична та мовна моделі налаштовані під одну мову, а потік не переоцінюється на кожному кадрі. Рішення ухвалюється один раз, на вході каналу, далі розпізнавання йде за передбачуваним словником. На коротких репліках — «так», «алло», продиктований номер — такий варіант найточніше визначає мову.

Автовизначення мови влаштовано інакше: класифікатор ковзає по вікну й перераховує гіпотезу кожні кілька кадрів. Стійке рішення потребує 3–5 секунд безперервного мовлення — на коротких репліках частка помилок різко зростає, і система стрибає між мовами.

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

Перемикання мов у діалозі закривається гістерезисом: зміна приймається, лише якщо нова гіпотеза підтвердилася кількома вікнами поспіль, а попередня впевнено поступилася. Плюс згладжування за історією каналу — вкраплення чужого слова не перемикає всю розмову. Якщо мовлення змішане всередині фрази, вікно дробиться, і кожна частина йде у свою модель.

Профіль надійніший там, де мова каналу відома: виділена лінія, інтерв’ю, розмова оператора. Автовизначення виграє на загальному потоці — звернення з різних країн, голосові повідомлення, публічні записи.

Міряємо це на розмічених наборах на кшталт Common Voice і на записах замовника: частка правильних рішень, час до стійкої гіпотези, число хибних перемикань на годину аудіо.

За цими метриками й обирається схема — жорсткий профіль, чиста автоматика або гібрид, де профіль слугує якорем, а автоматика підстраховує.

Технічні сумніви: шум, діалекти, змішане мовлення

Розпізнавання в бойових каналах рідко схоже на демо зі студійним записом. Нижче — заперечення, які інженери піднімають першими, і те, як ми їх закриваємо на рівні підготовки даних, налаштування акустичної моделі та постобробки, а не «підпорок» в інтерфейсі.

Що робити з діалектами та сильними акцентами?

Єдина модель на всі акценти дає рівний, але середній результат. Під потрібний регіон робимо адаптацію: дообучення на розміченому мовленні носіїв акценту помітно знижує помилки в іменах, топонімах і термінах.

Якщо своїх даних немає, розмічаємо фрагменти з ваших записів — зазвичай достатньо кількох десятків годин.

А якщо в одній фразі звучать дві мови?

Визначення мови на рівні цілого висловлювання тут ламається. Ми визначаємо мову на коротких вікнах і склеюємо результат, а спірні фрагменти проганяємо через дві моделі й вибираємо варіант за впевненістю. Перемикання всередині речення не рве транскрипт і не переносить слова в сусідній рядок.

Запис зроблено слабким мікрофоном — це вирок?

Частина інформації втрачається безповоротно, але втрати обмежуються: приводимо гучність до єдиного рівня, давимо низькочастотний гул, обрізаємо перевантаження.

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

Модель знає лексику нашої предметної області?

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

Обговоримо задачу: багатомовні потоки та якість запису

Щоб оцінка проєкту спиралася на факти, а не на припущення, нам достатньо кількох вхідних даних. Вони ж показують, де проходить межа між тим, що вирішується налаштуванням, і тим, що потребує окремого інженерного рішення.

• Записи з усіх багатомовних потоків: по 15–30 хвилин на кожну мову та канал — мікрофон зали, телефонна лінія, відеоконференція. Фрагменти з шумом, перекриттям мовлення та зміною мови всередині фрази цінніші за студійні зразки.
• Схема потоків: скільки джерел, як вони змішуються, чи розділені вони за каналами або все йде в одну доріжку.
• Як мова фіксується зараз: вручну, за розкладом або не фіксується — від цього залежить логіка автовизначення.
• Вимоги до результату: текст із таймкодами, розділення за спікерами, переклад або лише розшифрування.
• Обсяг і режим: години запису на добу, обробка в реальному часі або відкладена, глибина зберігання архіву.
• Обмеження за інфраструктурою: де допустимо розміщувати обробку, чи потрібен закритий контур, які системи отримують результат.

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