WER однаково оцінює неправильне ім’я, хибне число та пропущене «not» і пропущений артикль «the». Оцінюйте систему транскрибування за тим, які помилки вона ловить і чи видно її виправлення, а не за загальним числом.
Частота помилок у словах (word error rate, WER) є стандартним еталоном для розпізнавання мовлення. Візьміть еталонний транскрипт, який перевірила людина, вирівняйте вихід машини з ним слово за словом і порахуйте три типи помилок: заміни (неправильне слово), вставки (слово, якого не казали) і пропуски (слово, яке зникло). Додайте їх разом і поділіть на кількість слів в еталоні.
WER = (заміни + вставки + пропуски) / кількість слів в еталоні
Вирівнювання не робиться на око. Два транскрипти вирівнюються за мінімальною відстанню редагування (відстань Левенштейна, застосована до слів, а не до літер): серед усіх способів поставити вихід у пару з еталоном оцінювач обирає той, де найменше правок, і рахує їх. Оскільки вставки враховуються, а знаменник дорівнює довжині еталону, WER може перевищувати 100 відсотків: модель, яка заповнює тиху хвилину текстом, отримує гірший результат, ніж та, що не пише нічого.
Припустімо, еталон — «we will meet Dr Okafor at nine on Thursday», дев’ять слів, а машина пише «we will meet the doctor at nine on Tuesday». Це три заміни (Dr, Okafor, Thursday) на дев’ять слів: WER 33 відсотки. Дві третини слів правильні, але ви все одно на неправильній зустрічі в неправильний день. Якби помилковим було лише «Thursday», результат був би 11 відсотків. Версія, де кожне слово правильне, але додано «um», якого ніхто не казав, теж отримає 11 відсотків, бо вставка рахується так само, як заміна.
Перед підрахунком обидва тексти зазвичай нормалізують, і вибори на цьому етапі змінюють результат не менше, ніж сама модель. Чи є «Dr» тим самим словом, що й «Doctor»? Чи є «nine» тим самим, що й «9»? Чи враховуються регістр і пунктуація? Строга оцінка зарахує «Dr» проти «Doctor» як заміну. Більшість опублікованих результатів переводять весь текст у нижній регістр, прибирають пунктуацію і записують усі числа однаково, словами або цифрами, перш ніж порівнювати. Тому цифра постачальника тихо залежить від нормалізатора, якого ви не бачите. Мови, які пишуться без пробілів між словами, як китайська, японська і тайська, не мають чіткої межі слова для підрахунку, тож їх оцінюють за частотою помилок у символах (CER): та сама формула, але застосована до символів.
З цього випливає дві речі. По-перше, WER 5 відсотків означає одне слово з двадцяти, а це кілька сотень слів у годинній доповіді. Для порівняння: людські транскриптори зазвичай мають близько 4–5 відсотків на розмовному мовленні, а часто цитований результат 2017 року на телефонному корпусі Switchboard дав машині близько 5.1 відсотка, хоча обидві цифри залежать від аудіо та правил оцінювання. По-друге, число повністю залежить від тестового аудіо: чисте читання дає одну цифру, а шумна панель з акцентами та перебиванням — зовсім іншу. Заявлений WER описує тестовий набір постачальника так само, як і його систему.
Це підрахунок. Чого він не враховує, так це ціни кожної помилки для того, хто читає.
WER ставиться до кожного слова однаково. Читачі — ні:
Кожна з них — це одна-дві помилки в колонці WER. У колонці читача вони варіюються від нічого до іншої зустрічі в інший день. Тому питання не лише в тому, «яка частота помилок», а й «які саме помилки і що їх ловить».
Кілька шарів ловлять те, що розпізнавання помилково пропускає, і кожна зміна записується, щоб її можна було перевірити та скасувати. У живому транскрибуванні це відбувається, поки текст ще надходить: кожен рядок спочатку з’являється як чернетка, яка ще може змінитися, а потім стає остаточним (Затримка живого перекладу: пояснення розповідає, чому так).
Деякі помилки пасують до звуку, але не до речення: «their» там, де потрібне «there». Їх можна знайти за контекстом, і виправлення доходить до читачів як видиме оновлення (transcript.amended в API), а не як тиха заміна. Контекст добре працює зі словами, які речення може передбачити. З тими, яких воно не може передбачити, він безсилий.
Імена і технічні терміни — це помилки, яких контекст не виправить, адже ім’я часто з’являється лише раз, і навколо немає нічого, з чого його можна було б передбачити. Довідковий сценарій це вирішує: передайте системі мовлення, слайди або список імен і термінів до початку, і її слова матимуть пріоритет над тим, що рушій почув неправильно. Під час запису сценарій рухається разом із транскриптом, як телесуфлер, тож ведучий бачить, наскільки далеко просунувся рушій. Сценарій покриває слова, які можна передбачити; шумне аудіо та акценти породжують ті, які передбачити не можна.
Деякі помилки бачить лише людина в залі. Ручні виправлення дозволяють ведучому переписати будь-яке слово або рядок, поки транскрибування ще триває, і кожен слухач трансляції бачить зміну. Система вказує ведучому на ймовірні кандидати: слова, в яких рушій не був упевнений, можна підсвітити кольором і підкреслити, а ведучий може переходити між сумнівними фрагментами по одному, а не перечитувати весь транскрипт. Через API GET /v1/recordings/{id}/corrections показує виправлення запису, а POST /v1/corrections/{id}/revert скасовує одне; див. довідку API. Але навіть людина в залі не може виправити рядок, який ніхто не зміг почути.
Останній шар приймає, що деяке аудіо не відновити. Якщо рядок набирає нижче за поріг впевненості транскрибування (confidence.hideBelow, за замовчуванням 0.60), слухачі бачать замість нього «Аудіо нерозбірливе», а цей рядок ніколи не озвучується. Читачі втрачають рядок, але не отримують вигаданого.
Ті самі питання, що сформували ці шари, працюють із будь-якою заявою постачальника про точність, зокрема і з нашою.
Короткий перелік для читання будь-якої заяви про точність:
VocalStack не публікує внутрішнього показника WER з першої причини, наведеної вище: він описував би наш тестовий набір, а не ваше аудіо. Ми вимірюємо точність безперервно. Коли порівнюємо інші системи, використовуємо опубліковані незалежні бенчмарки та цифри, опубліковані самими постачальниками, але ніколи не приватні тести. Решту має вирішити ваше власне аудіо.
