Ръководство за програмиране за Cactus Whistle: Как се представя речевият модел от 16,9 MB спрямо Whisper Base? Процент грешки на думите, скорост, стрийминг, времеви маркери, ключови думи и заявки от реч към инструменти на CPU

В този урок използваме Whistle — модела за преобразуване на реч в текст на Cactus Compute, файл с размер 16,9 MB, който работи на CPU, транскрибира седем езика и връща времеви маркери и вероятности за отделните думи. В картата на модела се твърди, че той превъзхожда Whisper base върху LibriSpeech; тестваме го върху фиксирани чрез seed извадки от test-clean и test-other, като сравняваме Whistle с Whisper tiny и base върху идентични клипове, оценени чрез сдвоени интервали, групирани по говорител, с корекция на Холм. Установяваме преднина пред Whisper base с жаден декодер върху test-other, липса на значима разлика при beam search и предимство по скорост, което се свива с увеличаването на дължината на клиповете. Освен основния резултат изследваме 30-секунден прозорец, при който фиксираният engine без предупреждение пропуска средната част на по-дълги аудиозаписи, както и латентността при поточно предаване, времевите маркери, приоритизирането на ключови думи, други езици, шума, embedding-ите и повикванията от реч към инструменти. Нашите графики са еднократни измервания от Apple M4, а публикуваните резултати за целите подмножества са цитирани, не измерени.

Инсталираме cactus-needle 3.2.0 с фиксирани версии на зависимостите и изключваме анонимната телеметрия. Пакетът изтегля теглата на Whistle, неговия engine и теглата на Needle 3 от хранилища на Hugging Face, чиито файлове се заменят на място, затова фиксираме и двете хранилища към конкретни ревизии и отпечатваме SHA-256 хешове. Помощната функция page() прочита API на datasets-server за редове с обратно изчакване при ограничаване на честотата, а load_audio() преобразува клиповете до 16 kHz. Първият клип от test-clean, съдържащ 3,5 секунди реч, се транскрибира за 33 ms реално време, като за всяка дума се посочват начало, край и вероятност.

Един извод има малка стойност, ако правилото му бъде определено след получаването на крайните резултати, затова записахме нашето в notebook-а преди окончателното изпълнение, след предварителни експерименти, обхванали някои от същите клипове. Избираме чрез seed извадка от 300 реда за всяко подмножество и изключваме клиповете, по-дълги от еднопроходния прозорец на Whistle, така че остават по 299 клипа във всяко. Сдвоените подмножества — първите 100 клипа от test-other и 60 от test-clean — преминават през Whisper, а малкият брой говорители прави интервалите приблизителни. Разликата се счита за значима само когато нейният 95% сдвоен bootstrap интервал, групиран по говорител, изключва нулата и коригираната по Холм p-стойност е под 0,05.

Декодерът по подразбиране на Whisper е жаден, с резервно използване на различни температури. Същевременно числата от статията за LibriSpeech са получени чрез beam search, а Whistle декодира с търсене с пет лъча, така че всяко сравнение трябва да посочва базовата линия. Оценен с един и същ нормализатор, WER на Whistle е 10,47% върху извадката от test-other, близо до публикуваните 10,49% за цялото подмножество, които цитираме, вместо да измерваме. Върху сдвоеното подмножество резултатът му е 10,27% спрямо 12,46% за жадния Whisper base и 10,83% при beam search. Преднината от 2,19 процентни пункта пред жадния декодер остава след корекцията на Холм, но разликата при beam search не е значима, така че тази базова линия печели.

Сравненията на скоростта се провалят, когато engine-ите споделят един процес, тъй като нишките на torch могат да забавят единия от тях. Затова всеки engine работи в отделен процес върху идентични масиви от float32, като времето се измерва като медиана след предварително загряване. Разликата се свива с увеличаването на дължината на клиповете — от 7,7 пъти времето на Whistle при 5 секунди до 2,8 пъти при 30 секунди, отчасти заради фиксирания прозорец за допълване на Whisper. Пиковата памет е 124 MB за Whistle и 823 MB за Whisper base. Времето на Whistle за отделен клип се различаваше почти трикратно между двете подмножества, което дължината на клипа не обяснява, затова приемайте съотношенията като приблизителни.

Свързването на изказванията на един говорител създава дълъг клип с точна референция, а README файлът обещава прозоречна обработка над ограничението от 30 секунди. По-късият отрязък се връща почти дума по дума, но engine-ът 3.3.0, фиксиран в нашия тест, безшумно пропуска средата на целия клип и връща по-малко от половината му думи, без да генерира грешка. Engine-ът 3.2.0 отказва подобен аудиозапис с RuntimeError, така че двете версии се държат различно и разделянето остава наша задача. Разделянето в тихи точки дава WER 3,75% спрямо 6,74% при фиксирани прозорци, макар че един клип не е достатъчен за окончателен извод.

Поточното предаване чрез stream() транскрибира повторно последния аудиосегмент и фиксира дума, когато два последователни прохода съвпаднат, така че изчакването нараства с размера на порцията. Осем сесии на един и същ говорител, създадени чрез свързване на изказвания, постигат WER 10,05% при порции от една секунда спрямо 10,41%, когато същите изказвания се транскрибират поотделно — разлика без статистическа значимост. Думата се фиксира средно 1,68 секунди след края си, а при две сесии медианата нараства от 0,78 секунди при порции от половин секунда до 3,44 секунди при порции от две секунди. Свързванията са изкуствени, така че този тест оценява механизма, а не разговорната реч.

Без златни подравнявания проверяваме времевите маркери спрямо това, на което те задължително трябва да отговарят. Времената на думите са монотонни във всеки проверен клип, а добавянето на две секунди тишина в началото на двадесет клипа измества първата дума с медиана 2,000 секунди. Отрязването в края на дадена дума би трябвало да възпроизведе началната ѝ последователност, но това се случва само в една пета от тези двадесет клипа; тестът проверява стабилността, а не точността на крайното време. Вероятността е по-силен сигнал: думите с оценка под 0,5 са грешни в 69,2% от случаите спрямо 2,5% при оценка 0,9 или по-висока, а AUROC за грешните думи е 0,916 спрямо 0,509 за продължителността.

Приоритизирането на ключови думи изисква контролни условия, защото оракул, който прочита отговора, може да изглежда като победа. Оракулът изброява думите, които Whistle е объркал; съпоставеният контрол използва думите от друг клип, като премахва всички, които се срещат в текущия клип. При 185-те клипа с грешки оракулът намалява WER от 14,74% на 7,62%, докато неправилните съпоставени думи го оставят на 14,82% — несъществена промяна. Осем често срещани думи, които липсват в клипа, повишават WER с 2,05 процентни пункта. Спрямо оракула неправилните съпоставени думи са с 7,20 пункта по-лоши, като разликата остава значима след корекцията на Холм, така че правилните думи имат значение.

Принуждаването към истинския език би скрило грешките при разпознаването му, затова всеки модел трябва също да идентифицира езика. Избираме по 12 клипа за всеки език от три случайни страници, като правилото е фиксирано предварително, и оценяваме и двете страни с BasicTextNormalizer. Не фиксираме ревизия на MLS, затова хешираме всеки клип поотделно. Върху 72 клипа от 22 говорители Whistle с принудително зададен език постига 26,40% спрямо 24,06% за жадния Whisper base — разлика в полза на Whisper, която не е значима. И двата модела разпознават езика правилно и на 72-те клипа. Резултатите по езици са само описателни.

Проблемите при сравняване на малки модели често остават скрити зад средни стойности. Затова проверяваме тишина, слаб говор, бял шум и тонове при контролирани нива, както и добавен шум върху реални клипове. Празен изход от Whisper е резултат от неговия филтър за липса на реч, а не доказателство за качество; празен изход от Whistle при реална реч би бил пропуск.