Точність ШІ-транскрипції: чому бенчмарки постачальників вводять в оману і як ми насправді тестуємо моделі

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

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

Головне коротко

• Бенчмарки точності від постачальників (єдиний показник WER, «98 % точності») — це здебільшого накручування результатів бенчмарку: вони виміряні на чистому, написаному за сценарієм аудіо з одним спікером, яке не має нічого спільного з реальними багатомовними записами, записами з акцентами чи з кількома спікерами.
• Тому ми не обираємо моделі за їхніми опублікованими цифрами. Ми тестуємо їх на власному «брудному», реальному аудіо й оцінюємо результат так, як це робив би літературний редактор: чи виправило воно неправильно почуті слова, чи читається як чиста писемна мова і — що найважливіше — чи не змінило воно жодного факту.
• В одному реальному оцінювальному прогоні маленька швидка модель перевершила наш важчий стандартний продакшен-варіант (приблизно 92 % переваги судді, приблизно у 13× швидше). Більше й повільніше не означало точніше.
• Збій, який доводить цю тезу: модель потайки переписала сенсор камери «LYT-828» на «LYT-808» — читається чисто, фактично хибно і невидимо для показника WER.
• Оцінюєте інструмент самостійно? Тестуйте своє найгірше реальне аудіо — акценти, перебивання, жаргон, перемикання мов, — стежте за таймкодами на екрані й полюйте на фактичні спотворення, а не на цифру з рейтингу.

Чому бенчмарки транскрипції від постачальників вводять в оману?

Опублікований коефіцієнт помилок за словами (Word Error Rate, WER) або відсоток точності — це одна-єдина цифра, отримана за умов, які обрав сам постачальник. Три речі роблять її майже непридатною для вибору моделі для продакшену:

• Тестовий набір чистий. Аудіо для бенчмарку зазвичай написане за сценарієм, з одним спікером, записане в тихій кімнаті, ресурсно багатою мовою. Реальне аудіо не таке нічим із цього.
• Метрика груба. WER однаково рахує заміни, вставки та пропуски. Але неправильно передати номер моделі (коли «Vivo X30» перетворюється на «Vivo X90») — це катастрофічна помилка, тоді як пропущена кома нешкідлива. WER оцінює їх однаково.
• Це власне табло постачальника. Кожна лабораторія повідомляє ту конфігурацію, у якій її модель виглядає найкраще. Ви читаєте максимум, а не очікуваний результат.

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

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

Що «точність» насправді означає для субтитру

Коли більшість людей кажуть «точність транскрипції», вони змішують дві цілком різні задачі:

1. Перетворення мовлення на текст (STT / ASR) — перетворення аудіо на сирий текст із таймкодами. Саме тут живе WER.
2. Очищення тексту — перетворення цього сирого, «брудного» ASR-тексту на придатний до публікації субтитр: виправлення неправильно почутих слів, переведення розмовних формулювань у чисту писемну форму, відновлення пробілів і пунктуації, видалення слів-паразитів і, що критично, незмінення жодного факту.

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

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

Як ми тестуємо етап очищення тексту: LLM-як-суддя на реальному аудіо

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

• Виправлення помилок — корекція слів і чисел, які перетворення мовлення на текст передало хибно: неправильно почута назва бренду, хибний номер моделі, пропущене заперечення.
• Очищення формулювань — переведення розмовної, побутової мови в чисту писемну, відновлення пунктуації та пробілів і обрізання слів-паразитів — без зміни сенсу. (У деяких мовах цей розрив великий: у кантонській, наприклад, є виразне перетворення усного мовлення на писемне, 口語 → 書面語.)

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

• Набір даних був невеликою, навмисно дібраною добіркою реальних зразків — у нашому випадку це гонконзька кантонська й англійська з перемиканням кодів — обраних не за обсягом, а за випадками, які «ламають» моделі: змішане письмо, технічні терміни й номери моделей, насичені пунктуацією уривки, короткі крихкі фрагменти та довгі відрізки. Конкретна мова важить менше, ніж принцип: жменя по-справжньому «злих» зразків із вашого власного сценарію виявляє більше реальних збоїв, ніж тисяча чистих.
• Порівняння було попарним. Для кожного зразка результат кожної моделі-кандидата йшов віч-на-віч проти нашого чинного продакшен-базису, а окрема модель-суддя обирала кращий — або оголошувала нічию.
• Критерії — це шість речей, які насправді визначають хороший субтитр, оцінювані незалежно для кожного зразка:
  • Виправлення неправильно почутих слів — чи виправило воно те, що перетворення мовлення на текст передало хибно?
  • Очищення з усного в писемне — чи перетворило воно розмовну мову на чисту писемну? (У наших кантонських зразках це перетворення 口語 → 書面語; у кожної мови є власний варіант упорядкування мовлення в прозу.)
  • Видалення слів-паразитів — чи прибрало воно всі «е-е» й фальстарти?
  • Збереження фактів — чи лишило воно імена, числа та факти недоторканими?
  • Заборона анотацій — чи утрималося воно від вигадування взятих у дужки приміток, яких спікер ніколи не промовляв?
  • Ретельність — чи справді воно прибрало текст, чи лишило очевидні помилки?

Ми запустили в цей прогін 31 конфігурацію моделей. Лише 17 узагалі були здатні запуститися — решта «впала» на етапі передперевірки через недійсні ID моделей, тайм-аути запитів чи непідтримувані налаштування, що саме собою є корисним результатом: модель, яку ви не можете надійно викликати, не є кандидатом, хай яким буде її показник у бенчмарку.

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

Що ми виявили: цифри з нашого власного прогону

Кілька результатів вирізнялися. Усі показники — з нашого власного оцінювання; це частки перемог за перевагою судді та швидкість на задачі очищення субтитрів, а не чийсь відсоток точності STT.

Три висновки з наших даних:

• Найкраща середня перевага судді в усьому прогоні становила приблизно 92 % — це легка конфігурація Gemini 3.1 Flash Lite, якій суддя віддав перевагу над нашим продакшен-базисом на переважній більшості зразків. Маленька швидка модель перевершила важчий стандартний варіант.
• Найощадливіша запускна конфігурація була приблизно у 13× швидшою за базис — близько 19 секунд проти приблизно 4 хвилин — за частку вартості, і все ж виграла очне порівняння у виправленні помилок беззастережно. Більше й повільніше не було кращим.
• Обмеження бюджету «мислення» моделі стало найбільшим окремим виграшем в ефективності. Базис витрачав переважну частину свого бюджету на токени міркувань, яких йому здебільшого не було потрібно. Вимкнення цього бюджету міркувань на тій самій родині моделей дало результат, який суддя оцінив як такий самий або кращий, — приблизно на порядок швидше й набагато ощадливіше. Для обмеженої, чітко окресленої задачі на кшталт очищення субтитрів розширені міркування були здебільшого марними зусиллями.

Ви помітите, що жодне з цього не є «відсотками точності». Це відносні оцінки переваги від моделі-судді, на нашому аудіо, проти нашого власного базису. Це навмисно скромніше твердження, ніж «98 % точності», і воно значно корисніше для реального вибору моделі.

Збій, який доводить, чому важливе тестування з оцінюванням людиною на реальному сценарії

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

Джерело:   T-828 的 sensor 啦。那這顆 LYT-828 呢，我們，我們又來……
Базис:     ……呢粒 LYT-828 呢……
Кандидат:  ……嗰呢粒 LYT-808 呢……

Модель потайки переписала сенсор камери «LYT-828» на «LYT-808». Той самий клас помилки ми бачили й в іншому місці прогону, де інший кандидат перетворив «Vivo X30 Pro» на «Vivo X90 Pro».

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

Урок не про якусь одну мову. Він про те, що найнебезпечніші помилки транскрипції — це плавні: чисто читабельне речення з потай підміненим технічним терміном, номером моделі чи власною назвою. Такі ховаються саме в тому насиченому жаргоном аудіо зі змішаним письмом, яке записують реальні користувачі, будь-якою мовою. Жоден опублікований бенчмарк точності не вловив би цього; це випливло лише тому, що ми оцінювали результат так, як це робив би літературний редактор, — за конкретним запитанням «чи змінила модель факт?» — на тому типі аудіо, де цей збій справді трапляється. Це й є різниця між накручуванням результатів бенчмарку і тестуванням, прив'язаним до реального сценарію.

Це також показує, чому «збереження фактів» — один із наших шести критеріїв і чому ми читаємо його як порівняльний сигнал, а не як буквальний підрахунок помилок. У тому самому прогоні одна модель передала «дев'яносто відсотків» двома однаково правильними способами (百分之九十 проти 九成) — семантично тотожно, узагалі без помилки. Наївна метрика поскаржилася б на переформулювання й проґавила б підміну сенсора. Судження на правильному матеріалі вибудовує цей порядок правильно.

А що з етапом сирого перетворення мовлення на текст?

Щодо самого етапу STT — аудіо на вході, текст із таймкодами на виході — наші висновки навмисно якісні. Ми не публікуємо таблицю WER, ні нашу, ні чиюсь, бо збої, які тут важливі, погано схоплюються одним коефіцієнтом помилок. Те, що валить STT-модель у продакшені, — це зазвичай щось одне з: галюцинований вміст, якого спікер ніколи не промовляв; пропущене справжнє мовлення; нестабільна робота на ресурсно бідніших чи змішаних за кодами мовах; або таймкоди, що «пливуть» і розсинхронізуються з аудіо.

Кілька речей, яких ми навчилися, тестуючи моделі на власному аудіо, а не читаючи їхні специфікації:

• Хороший текст не означає хороших таймкодів. Ми оцінювали передову мультимодальну модель як транскрипційний рушій: якість її сирого тексту була справді хорошою, але таймкоди реплік «попливли» — годяться для читального транскрипту, непридатні для субтитрів, які мають влучати в потрібний кадр.
• Деякі моделі дають непридатний тайминг просто з порога. Інша модель, яку ми тестували для тієї самої задачі, мала, як зазначено в наших нотатках, «сміттєві таймкоди» — сильна на папері, цілковито непридатна для синхронізованих за часом субтитрів.
• Ресурсно бідні та змішані за кодами мови — це там, де загальні моделі хитаються. Чистіші, ресурсно багаті мови, на які спирається бенчмарк, — це простий випадок; хитання проявляється на акцентах, діалектах і аудіо, що перемикається між мовами всередині одного запису. Subanana починала з однієї відомої STT-моделі, і нас змусив відмовитися від підходу з єдиним постачальником саме той тип збоїв, який бенчмарки приховують: галюцинації та пропущене мовлення в реальних умовах, причому складніші мови — кантонська серед них — були найменш стабільними. Саме тому ми тепер маршрутизуємо через кілька оцінених рушіїв і автоматично відкочуємося, коли один із них видає поганий сегмент.
• Справжня інженерія живе в проміжках. Коли ми додавали нового STT-постачальника, робота полягала не в тому, «чи нижчий WER». Вона полягала в: уривку фонової музики, який хибно прив'язувався до тайминга не того субтитру; розрізнених тегах [upbeat music], які треба було видалити; сегментах, що склеювалися без пробілів. Нічого з цього не з'являється в показнику точності; усе це з'являється для користувача.

Чесний підсумок такий: ми обираємо найкращу за результатами STT-модель для кожної вихідної мови та кожного сценарію використання, і ми постійно перевіряємо наново — бо модель, яка добре проходить бенчмарк, усе одно може «попливти» в таймкодах чи галюцинувати на складніших мовах, і єдиний спосіб дізнатися — запустити її на реальному матеріалі. Більше про те, як працюють ця маршрутизація та стек якості, можна прочитати на наших сторінках про інструмент ШІ-субтитрування і ШІ-транскрипцію нарад.

Як вам самостійно оцінити точність транскрипції?

Вам не потрібен оцінювальний фреймворк, щоб уникнути пастки бенчмарків. Принцип простий: тестуйте на власному аудіо, оцінюйте за тим, що важливо саме вам.

• Беріть своє найгірше реальне аудіо, а не чистий кліп. Оберіть файл з акцентами, перебиваннями, жаргоном, перемиканням мов. Саме там моделі розходяться.
• Перевіряйте таймкоди, а не лише слова. Програйте відео з увімкненими субтитрами. Репліки, що «попливли», невидимі в текстовому diff і очевидні на екрані.
• Полюйте саме на фактичні спотворення. Перегляньте імена, числа та назви продуктів/брендів. Чисто читабельний субтитр із хибним числом гірший за відверто грубий.
• Оцінюйте готовий результат, а не сирий транскрипт. Те, що ви випускаєте, — це виправлений, відформатований субтитр, тож оцінюйте саме його, зокрема й те, скільки ручного доопрацювання він іще потребує.
• Перетестовуйте з часом. Моделі змінюються. Найкраща для вашої мови цього кварталу може не бути такою наступного. Ми перезапускаємо наше оцінювання саме тому, що відповідь постійно зміщується.

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

Поширені запитання

Чи є вищий опублікований відсоток точності надійним способом обрати інструмент транскрипції?

Ні. Опубліковані цифри — це оптимізовані результати на чистому аудіо (часто з одним спікером) ресурсно багатими мовами. Вони рідко передбачають роботу на реальному аудіо з акцентами, перебиваннями, технічними термінами чи перемиканням мов. Натомість тестуйте на власних файлах.

Яка різниця між точністю транскрипції та якістю субтитрів?

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

Чому ви оцінюєте моделі за допомогою іншої моделі як судді?

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

Чи завжди модель із хорошим транскрипційним текстом дає хороші субтитри?

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

Чому Subanana використовує кілька моделей перетворення мовлення на текст замість однієї?

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