Компанія обирає постачальника розпізнавання мовлення для голосового агента приблизно так: відкриває лідерборд, дивиться на верхній рядок, перевіряє, чи є українська в списку підтримуваних мов. Українська там є майже скрізь. На цьому перевірка зазвичай закінчується.
Проблема в тому, що число з верхнього рядка зміряне не на тому, з чим агент працюватиме. А заміру, зробленого саме на тому, ми не знайшли: ні на сторінках вендорів, ні в незалежних лідербордах, ні в публікаціях на arXiv.
Три публічні числа про українську — і жодне не про ваш дзвінок
Ці три числа цитують найчастіше, коли заходить мова про українське розпізнавання.
Число | Що саме зміряно | Хто міряв | Умови запису |
|---|---|---|---|
3,5% WER | Scribe v1, українська | ElevenLabs, власна сторінка | FLEURS — читана студійна мова |
2,3% WER | Scribe v2, загальний залік | Artificial Analysis, AA-WER v2.0 | набір без української |
8,5% WER | модель Soniox, українська | Soniox, порівняння з Google | YouTube-аудіо, 2025 рік; сторінка вже не відкривається |
Кожне з цих чисел коректне. Проблема виникає в момент, коли їх ставлять поруч і починають порівнювати.
Перше — з фірмової сторінки ElevenLabs про українську мову. Там наведено 3,5% WER на бенчмарку FLEURS, і в таблиці прямо зазначено, що це Scribe v1. FLEURS — це читана вголос мова, записана в хороших умовах: диктор, тиша, повна смуга частот.
Друге число — з індексу AA-WER v2.0 від Artificial Analysis, незалежної сторони. Scribe v2 очолює цей індекс із результатом 2,3%, за ним Gemini 3 Pro із 2,9%. Тільки індекс складається з трьох датасетів: AA-AgentTalk (вага 50%), VoxPopuli-Cleaned-AA (25%) і Earnings22-Cleaned-AA (25%), і жодного українського результату там не опубліковано — як і розбивки за мовами взагалі. «Найкраща модель у світі» — коректне твердження про індекс, у якому вашої мови не було.
З третім числом сталося найцікавіше. Сторінка порівняння Soniox із Google наводила 8,5% WER українською проти 18,3% — вендорський матеріал, де умови були вказані чесно: дослідження 2025 року на реальному YouTube-аудіо. Станом на кінець серпня 2026 року ця сторінка вже не відкривається. Пошукові системи її ще пам'ятають, а сервер віддає 404.
Що залишилось замість неї на живій сторінці Soniox про українську мову — формулювання «proven lowest error rates», тобто твердження про найнижчий рівень помилок без жодного числа. Розділ бенчмарків у цього ж вендора існує, але міряє тільки англійську.
Різниця між 3,5% і 8,5% читалася як дворазова перевага першої моделі. Насправді це різниця між дикторським записом у студії та роликами з ютубу: порівнювались умови, а не моделі. Ще й у різні роки, ще й за версіями, які вендори обирали самі. А тепер одне з двох чисел просто зникло — і перевірити його на першоджерелі більше не можна.
Чому телефонний канал доводиться рахувати окремо
Усі три заміри мають спільну рису: жоден не робився на телефонії.
Телефонний дзвінок — це вузькосмуговий сигнал, як правило 8 кГц, стиснутий кодеком G.711. Порівняно зі студійним записом у 16 кГц і вище, з нього фізично вирізано верхню частину спектра. Саме там живуть ознаки, за якими розрізняються глухі приголосні — і українські шиплячі та свистячі, яких у мові багато, страждають від цього першими. Додайте до цього фоновий шум із боку абонента: вулиця, авто, магазин, дитина поруч.
Модель, що показує 3,5% на дикторському записі, на цьому матеріалі показуватиме інше число. Наскільки інше, залежить від конкретної моделі — і саме цієї перевірки українською ми у відкритих джерелах не знайшли.
Є ще одна пастка, суто технічна. Багато хто розраховує забрати аудіо дзвінка через звичайний HTTP-API провайдера телефонії, а потім виявляє, що там лежить тільки запис постфактум, коли розмова вже завершилася. Для аналітики дзвінків цього достатньо, для діалогу — ні. Живий потік дає SIP-транк, а це вже власний медіа-шар у контурі: SBC, який приймає RTP і віддає його розпізнаванню. Побічна перевага такої схеми в тому, що на цьому ж шарі можна прибрати шум до того, як аудіо потрапить у модель.
Де саме ламається українська в дзвінку
Акцент — не головна складність. Реальні місця зривів інші, і вони специфічні для українського ринку.
Перемикання мов усередині репліки. Людина починає українською, вставляє російське слово, повертається назад. Суржик у побутовому мовленні — норма, а не виняток, і для моделі це найважчий клас: вона мусить утримувати дві фонетичні системи одночасно й вирішувати, до якої належить конкретне слово.
Власні назви. Назви міст, селищ і районів, прізвища, назви компаній і брендів. Тут модель не має підказки з контексту речення й помиляється саме на тому слові, заради якого дзвінок і відбувався.
Швидка емоційна мова, перебивання, обриви. Людина, яка дзвонить із проблемою, говорить не так, як диктор: швидше, з проковтуванням закінчень, перебиваючи співрозмовника на середині фрази.
Перші два класи — не здогад із практики, а вимірюваний факт. Просто виміряний іншими мовами.
Урок про вендорські числа: версія, дата, умови
Коли Grow2.ai пропрацьовував архітектуру голосового агента для кваліфікації лідів, оцінка почалася з тривожного числа: українське розпізнавання в одного з кандидатів нібито дає 13,5% помилок. Для сценарію, де агент має правильно почути назву міста, це виглядало як вирок — і мало не закрило варіант ще до перевірки.
При спробі знайти джерело числа воно розсипалося. Цифра стосувалася попереднього покоління моделі й була зміряна на брудному аудіо з ютубу — на матеріалі, свідомо складнішому за середній. До поточної версії, яка на той момент вже вийшла, вона стосунку не мала.
Висновок з цього епізоду не про конкретного постачальника. Він про те, що будь-яке число про точність розпізнавання без трьох координат — версія моделі, дата заміру, умови запису — не є інформацією. Це маркетинговий рядок, який однаково легко використати і щоб щось продати, і щоб щось помилково відхилити.
Обидві пастки, до речі, чекають на одній і тій самій сторінці вендора: українське число там наведено для першої версії моделі, а заголовок про перше місце у світі спирається на індекс, у якому української немає.
Що вміє корекційний шар — і чого він не робить
21 серпня 2026 року The Batch у випуску 367 виніс у заголовок покращення в корекції розпізнавання мовлення. Йдеться про роботу Agentic ASR (arXiv:2605.29430) дослідників Shanghai Jiao Tong University, Zhejiang University, Fudan University та Microsoft Xiaoice.
Ідея в тому, щоб не покладатися на один прохід розпізнавання. Поверх ASR-моделі ставиться мовна модель, яка веде багатокрокове уточнення: класифікує репліку користувача як підтвердження, нову інформацію або виправлення, знаходить помилковий фрагмент у транскрипті й редагує його, спираючись на те, що людина насправді мала на увазі. У роботі використано Qwen3-ASR-1.7B для розпізнавання і Qwen3-32B як коригувальну модель.
Результати за десять кроків уточнення:
Бенчмарк | Було | Стало |
|---|---|---|
GigaSpeech (семантична помилка) | 21,5% | 3,5% |
AISHELL-NER (імена, дати) | 19,9% | 2,0% |
ASRU2019 (змішана англо-мандаринська мова) | 28,6% | 1,4% |
Два нижні рядки — це рівно ті класи, що ламають українську телефонію: власні назви й перемикання мов. Показові й самі початкові рівні: у межах одного дослідження імена й дати стартують з 19,9%, змішана мова — з 28,6%, тоді як загальний бенчмарк розбірливої мови дає 21,5%. Складність цих класів вимірювана, а не гіпотетична.
Переносити цифри буквально не можна. Заміри зроблено на англійській та мандаринській, українською такого дослідження ми не знайшли. Аналогія працює в один бік: якщо змішана мова дає 28,6% помилок там, де для мов існують великі корпуси й десятиліття роботи, то розраховувати на кращий старт для суржику підстав немає.
Для впровадження тут важливіша механіка, ніж відсотки. Корекція працює через діалог: модель уточнює те, у чому не впевнена. У голосовому агенті це перекладається на просту поведінку — перепитати, а не вгадати. Агент, який перепитує назву міста при низькій впевненості розпізнавання, робить те саме, що робить коригувальна модель у цій роботі, тільки замість другої моделі використовує співрозмовника.
Дослівна точність вам не потрібна
Більшу частину тривоги навколо WER знімає одне спостереження про те, що саме агент має почути.
WER міряє частку неправильно розпізнаних слів у всьому транскрипті. Але агент кваліфікації не пише стенограму. Він має витягнути з розмови кілька полів, від яких залежить, куди піде лід далі: наприклад, місто співрозмовника й суть звернення. Решта розмови може бути розпізнана як завгодно приблизно — на маршрутизацію це не впливає.
Отже, значуща метрика — не WER, а точність по полях рішення. Транскрипт із 12% помилок, де жодна з них не припала на назву міста, для задачі кваліфікації кращий за транскрипт із 6% помилок, де половина зіпсувала саме топоніми. Модель, яка загалом виглядає слабшою, може виявитися придатнішою — якщо вона краще тримає власні назви.
Звідси випливає і те, як зменшувати ризик. Замість гнатися за останнім відсотком загальної точності, звужують задачу: короткий сценарій, у якому агент має з'ясувати дві-три речі за 20–30 секунд; перепит при низькій впевненості; підказка моделі списком очікуваної лексики — переліком міст, які реально трапляються у ваших дзвінках. Останній прийом підтримують моделі напряму: у Scribe v2, наприклад, keyterm-prompting дозволяє передати до ста слів і фраз, на які модель має звертати особливу увагу.
План перевірки до запуску, а не після
Оскільки публічного числа немає, його доводиться отримувати самостійно. Нижче наведено те, що Grow2.ai закладає в план перевірки перед пілотом. Це саме план, а не звіт про заміряний результат: коректні числа з'являються тільки на аудіо конкретного проєкту, і взяти їх звідкись іще неможливо.
- Зібрати власний тестовий набір. Реальні записи дзвінків з вашої телефонії, а не студійні фрази. Достатньо кількох десятків розмов, але обов'язково з тим розподілом, який у вас справді є: міста, суржик, шум, обриви.
- Розмітити еталон вручну. Без правильної відповіді порівнювати нема з чим. Розмічається не весь текст дослівно, а поля рішення — що людина насправді сказала про місто й про суть звернення.
- Прогнати кількох кандидатів на одному наборі. Порівняння має сенс лише тоді, коли умови однакові для всіх — саме те, чого бракує публічним числам.
- Рахувати точність по полях, а не WER. Плюс окремо: частку випадків, коли модель була не впевнена і агент мав би перепитати.
- Тестувати розпізнавання й логіку діалогу окремо. Інакше незрозуміло, що саме зламалося: агент не почув місто чи почув і неправильно вирішив, куди вести лід.
- Перевірити денойзинг як окремий варіант. Той самий набір, прогнаний з очищенням аудіо перед розпізнаванням і без нього, показує, чи вартий цей шар ускладнення архітектури.
Такий прогін коштує кількох днів роботи й дає число, якого немає в жодному лідерборді, зате саме про ваші дзвінки. Логіка тут та сама, що й у чеклісті запуску агента за два тижні: перевірка на реальних даних ставиться перед масштабуванням, а не після.
Що міряти після запуску
Пілот дає стартову точку, далі потрібен постійний нагляд. З першого дня на моніторинг варто вивести точність по полях рішення, тобто частку дзвінків, де місто й суть звернення визначені правильно, а поруч із нею помилки маршрутизації з розділенням причини: лід поїхав не в ту стадію, бо агент не почув, чи бо неправильно вирішив.
Окремо йде частота перепитів, і в неї немає бажаного напрямку. Якщо агент перепитує надто часто, розмова стає виснажливою і люди кладуть слухавку. Якщо не перепитує зовсім, він вгадує. Нормальний коридор доводиться намацувати на живому трафіку, і він різний для різних сценаріїв.
Четвертий показник — частка розмов, які агент визнав нетиповими й віддав оператору. Це не ознака слабкості системи. Агент, який вчасно передає складний випадок людині, поводиться правильно; проблема виникає тоді, коли він не передає нічого. Ця межа компетенції задається так само, як і решта захисних механізмів — про них докладніше в розборі трьох рівнів захисту AI-агента.
Що з цього випливає для рішення про впровадження
Відсутність публічного заміру — не привід відмовлятися від голосового агента українською. Це привід не купувати рішення за лідербордом.
Вибір постачальника розпізнавання перестає бути частиною закупівлі й стає частиною пілота. Це змінює й формат домовленості з підрядником: перевірка на ваших записах має стояти в плані до фіксації остаточної архітектури, а не після підписання акту. Загальний підхід до того, які завдання взагалі варто віддавати агенту в продажах, розібраний у гайді для керівника, а арифметика порівняння з роботою менеджера — окремо.
Наступний крок:
- Обговорити пілот голосового агента — за одну зустріч визначаємо, які поля рішення критичні у ваших дзвінках і як побудувати перевірку на ваших записах
І деталь, яку зазвичай помічають уже після запуску: тестовий набір має жити далі. Дзвінки змінюються разом із рекламними кампаніями та сезоном, і набір, зібраний один раз перед пілотом, за кілька місяців перестає описувати те, що реально приходить на лінію.
Джерела:
- The Batch, Issue 367 — «Agents Come to Speech Recognition» (21.08.2026)
- Agentic ASR — arXiv:2605.29430
- Artificial Analysis — Speech to Text Leaderboard (AA-WER v2.0)
- ElevenLabs — Ukrainian Speech to Text
- Soniox — Ukrainian Speech to Text (сторінка порівняння з Google, що наводила 8,5% WER, станом на 25.08.2026 віддає 404)