Компанія обирає постачальника розпізнавання мовлення для голосового агента приблизно так: відкриває лідерборд, дивиться на верхній рядок, перевіряє, чи є українська в списку підтримуваних мов. Українська там є майже скрізь. На цьому перевірка зазвичай закінчується.
Проблема в тому, що число з верхнього рядка зміряне не на тому, з чим агент працюватиме. А заміру, зробленого саме на тому, ми не знайшли: ні на сторінках вендорів, ні в незалежних лідербордах, ні в публікаціях на 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 — це word error rate, частка неправильно розпізнаних слів у транскрипті, — на бенчмарку 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-аудіо. Станом на 25.08.2026 ця сторінка вже не відкривається. Пошукові системи її ще пам'ятають, а сервер віддає 404.
Що залишилось замість неї на живій сторінці Soniox про українську мову — формулювання «proven lowest error rates», тобто твердження про найнижчий рівень помилок без жодного числа. Розділ бенчмарків у цього ж вендора існує, але міряє тільки англійську.
Різниця між 3,5% і 8,5% читалася як дворазова перевага першої моделі. Насправді це різниця між дикторським записом у студії та роликами з ютубу: порівнювались умови, а не моделі. Ще й у різні роки, ще й за версіями, які вендори обирали самі. А тепер одне з двох чисел просто зникло — і перевірити його на першоджерелі більше не можна.
Чому телефонний канал доводиться рахувати окремо
Усі три заміри мають спільну рису: жоден не робився на телефонії.
Телефонний дзвінок — це вузькосмуговий сигнал: частота дискретизації 8 кГц, корисна смуга приблизно 3,4 кГц, стиснення кодеком G.711. Порівняно зі студійним записом із дискретизацією 16 кГц і вище, з нього фізично вирізано верхню частину спектра. Саме там живуть ознаки, за якими розрізняються глухі приголосні — і українські шиплячі та свистячі, яких у мові багато, страждають від цього першими. Додайте до цього фоновий шум із боку абонента: вулиця, авто, магазин, дитина поруч.
Модель, що показує 3,5% на дикторському записі, на цьому матеріалі показуватиме інше число. Наскільки інше, залежить від конкретної моделі — і саме цієї перевірки українською ми у відкритих джерелах не знайшли.
Є ще одна пастка, суто технічна. Багато хто розраховує забрати аудіо дзвінка через звичайний HTTP-API провайдера телефонії, а потім виявляє, що там лежить тільки запис постфактум, коли розмова вже завершилася. Для аналітики дзвінків цього достатньо, для діалогу — ні. Живий потік дає SIP-транк, а це вже власний медіа-шар у контурі: SBC, який приймає RTP і віддає його розпізнаванню. Побічна перевага такої схеми в тому, що на цьому ж шарі можна прибрати шум до того, як аудіо потрапить у модель.
Де саме ламається українська в дзвінку
Акцент — не головна складність. Реальні місця зривів інші, і вони специфічні для українського ринку.
Перемикання мов усередині репліки. Людина починає українською, вставляє російське слово, повертається назад. Суржик у побутовому мовленні — норма, а не виняток, і для моделі це найважчий клас: вона мусить утримувати дві фонетичні системи одночасно й вирішувати, до якої належить конкретне слово.
Власні назви. Назви міст, селищ і районів, прізвища, назви компаній і брендів. Тут модель не має підказки з контексту речення й помиляється саме на тому слові, заради якого дзвінок і відбувався.
Швидка емоційна мова, перебивання, обриви. Людина, яка дзвонить із проблемою, говорить не так, як диктор: швидше, з проковтуванням закінчень, перебиваючи співрозмовника на середині фрази.
Перші два класи — не здогад із практики, а вимірюваний факт. Просто виміряний іншими мовами.
Урок про вендорські числа: версія, дата, умови
Коли Grow2.ai пропрацьовував архітектуру голосового агента для кваліфікації лідів, оцінка почалася з тривожного числа: українське розпізнавання в одного з кандидатів нібито дає 13,5% помилок. Для сценарію, де агент має правильно почути назву міста, це виглядало як вирок — і мало не закрило варіант ще до перевірки. Це епізод нашої внутрішньої оцінки, а не публікований замір: постачальника й дату ми не називаємо, бо саме число тут не доказ, а ілюстрація.
При спробі знайти джерело числа воно розсипалося. Цифра стосувалася попереднього покоління моделі й була зміряна на брудному аудіо з ютубу — на матеріалі, свідомо складнішому за середній. До поточної версії, яка на той момент вже вийшла, вона стосунку не мала.
Висновок з цього епізоду не про конкретного постачальника. Він про те, що будь-яке число про точність розпізнавання без трьох координат — версія моделі, дата заміру, умови запису — не є інформацією. Це маркетинговий рядок, який однаково легко використати і щоб щось продати, і щоб щось помилково відхилити.
Обидві пастки, до речі, чекають на одній і тій самій сторінці вендора: українське число там наведено для першої версії моделі, а заголовок про перше місце у світі спирається на індекс, у якому української немає.
Дослівна точність вам не потрібна
Більшу частину тривоги навколо WER знімає одне спостереження про те, що саме агент має почути.
WER міряє частку неправильно розпізнаних слів у всьому транскрипті. Але агент кваліфікації не пише стенограму. Він має витягнути з розмови кілька полів, від яких залежить, куди піде лід далі: наприклад, місто співрозмовника й суть звернення. Решта розмови може бути розпізнана як завгодно приблизно — на маршрутизацію це не впливає.
Отже, значуща метрика — не WER, а точність по полях рішення. Транскрипт із 12% помилок, де жодна з них не припала на назву міста, для задачі кваліфікації кращий за транскрипт із 6% помилок, де половина зіпсувала саме топоніми. Модель, яка загалом виглядає слабшою, може виявитися придатнішою — якщо вона краще тримає власні назви.
Звідси випливає і те, як зменшувати ризик. Замість гнатися за останнім відсотком загальної точності, звужують задачу: короткий сценарій, у якому агент має з'ясувати дві-три речі за 20–30 секунд; перепит при низькій впевненості; підказка моделі списком очікуваної лексики — переліком міст, які реально трапляються у ваших дзвінках. Останній прийом підтримують моделі напряму: у Scribe v2, наприклад, keyterm-prompting дозволяє передати до ста слів і фраз, на які модель має звертати особливу увагу.
План перевірки до запуску, а не після
Оскільки публічного числа немає, його доводиться отримувати самостійно. Нижче наведено те, що Grow2.ai закладає в план перевірки перед пілотом. Це саме план, а не звіт про заміряний результат: коректні числа з'являються тільки на аудіо конкретного проєкту, і взяти їх звідкись іще неможливо.
- Зібрати власний тестовий набір. Реальні записи дзвінків з вашої телефонії, а не студійні фрази. Достатньо кількох десятків розмов, але обов'язково з тим розподілом, який у вас справді є: міста, суржик, шум, обриви.
- Розмітити еталон вручну. Без правильної відповіді порівнювати нема з чим. Розмічається не весь текст дослівно, а поля рішення — що людина насправді сказала про місто й про суть звернення.
- Прогнати кількох кандидатів на одному наборі. Порівняння має сенс лише тоді, коли умови однакові для всіх — саме те, чого бракує публічним числам.
- Рахувати точність по полях, а не WER. Плюс окремо: частку випадків, коли модель була не впевнена і агент мав би перепитати.
- Тестувати розпізнавання й логіку діалогу окремо. Інакше незрозуміло, що саме зламалося: агент не почув місто чи почув і неправильно вирішив, куди вести лід.
- Перевірити денойзинг як окремий варіант. Той самий набір, прогнаний з очищенням аудіо перед розпізнаванням і без нього, показує, чи вартий цей шар ускладнення архітектури.
Такий прогін коштує кількох днів роботи й дає число, якого немає в жодному лідерборді, зате саме про ваші дзвінки. Логіка тут та сама, що й у чеклісті запуску агента за два тижні: перевірка на реальних даних ставиться перед масштабуванням, а не після.
Що міряти після запуску
Пілот дає стартову точку, далі потрібен постійний нагляд. З першого дня на моніторинг варто вивести точність по полях рішення, тобто частку дзвінків, де місто й суть звернення визначені правильно, а поруч із нею помилки маршрутизації з розділенням причини: лід поїхав не в ту стадію, бо агент не почув, чи бо неправильно вирішив.
Окремо йде частота перепитів, і в неї немає бажаного напрямку. Якщо агент перепитує надто часто, розмова стає виснажливою і люди кладуть слухавку. Якщо не перепитує зовсім, він вгадує. Нормальний коридор доводиться намацувати на живому трафіку, і він різний для різних сценаріїв.
Четвертий показник — частка розмов, які агент визнав нетиповими й віддав оператору. Це не ознака слабкості системи. Агент, який вчасно передає складний випадок людині, поводиться правильно; проблема виникає тоді, коли він не передає нічого. Ця межа компетенції задається так само, як і решта захисних механізмів — про них докладніше в розборі трьох рівнів захисту AI-агента.
Що з цього випливає для рішення про впровадження
Відсутність публічного заміру — не привід відмовлятися від голосового агента українською. Це привід не купувати рішення за лідербордом.
Вибір постачальника розпізнавання перестає бути частиною закупівлі й стає частиною пілота. Це змінює й формат домовленості з підрядником: перевірка на ваших записах має стояти в плані до фіксації остаточної архітектури, а не після підписання акту. Загальний підхід до того, які завдання взагалі варто віддавати агенту в продажах, розібраний у гайді для керівника, а арифметика порівняння з роботою менеджера — окремо.
Для власника з цього розділу випливає одне питання до підрядника: що ви робите з реплікою, яку модель розпізнала неправильно, — переписуєте її цілком чи перепитуєте людину. Відповідь «переписуємо» означає, що назви міст і прізвища ваших клієнтів агент правитиме навмання. Далі — механіка цього шару для тих, хто його будуватиме.
Для технічної команди: корекційний шар над розпізнаванням
Поверх одного проходу розпізнавання можна поставити мовну модель, яка веде багатокрокове уточнення: класифікує репліку співрозмовника як підтвердження, нову інформацію або виправлення, знаходить помилковий фрагмент у транскрипті й редагує саме його, а не переписує всю репліку. Так побудована робота Agentic ASR (arXiv:2605.29430, препринт подано 28 травня 2026 року), і в ній найбільша частина смислових помилок знімається вже на першому уточненні — зокрема на бенчмарку з власними назвами, тобто в тому самому класі, що ламає українську телефонію.
Механіку корекції, метрику S²ER, повні таблиці й межі цього результату ми розібрали окремо: виправлення помилок розпізнавання мовлення — три кроки. Там же — що з цих чисел переноситься на українську, а що ні, і що це означає для ціни й строків пілота.
Для впровадження тут важливіша механіка, ніж відсотки. Корекція працює через діалог: модель уточнює те, у чому не впевнена. У голосовому агенті це перекладається на просту поведінку — перепитати, а не вгадати. Агент, який перепитує назву міста при низькій впевненості розпізнавання, робить те саме, що робить коригувальна модель у цій роботі, тільки замість другої моделі використовує співрозмовника.
Наступний крок — обговорити пілот голосового агента: за одну зустріч визначаємо, які поля рішення критичні у ваших дзвінках і як побудувати перевірку на ваших записах. Напишіть нам.
І деталь, яку зазвичай помічають уже після запуску: тестовий набір має жити далі. Дзвінки змінюються разом із рекламними кампаніями та сезоном, і набір, зібраний один раз перед пілотом, за кілька місяців перестає описувати те, що реально приходить на лінію.
Джерела:
- 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)