Jeg gav fire voice-modeller en times dansk tale

Jeg har brugt de sidste par uger på at lege med tale- og voice-modeller. Ikke sådan "jeg læste en tråd på X"-lege. Mere den slags hvor man ender med mapper fulde af lydklip, JSON-filer, timestamps, mærkelige edge cases og en voksende fornemmelse af, at nu bliver jeg nødt til at måle det her ordentligt.

I mandags fik jeg så en gave.

Jeg holdt et webinar i et studie. Rigtig mikrofon. Rigtig optagelse. Rigtig dansk. Og bagefter stod jeg med 68 minutters lyd af mig selv, hvor jeg taler nogenlunde naturligt om udvikling, AI, GitHub, Netlify, prompts, aktindsigt og alt muligt andet, som talegenkendelse typisk kan snuble over.

Perfekt testmateriale.

Ikke perfekt fordi jeg taler perfekt. Tværtimod. Jeg siger øh. Jeg starter sætninger forfra. Jeg sluger endelser. Jeg siger engelske produktnavne midt i danske sætninger. Jeg skifter tempo. Jeg taler som et menneske.

Og det er jo præcis pointen.

Fire motorer, samme lyd

Jeg kørte den samme optagelse gennem fire forskellige tale-til-tekst-motorer.

Først MAI-Transcribe 1.5 og MAI-Transcribe 1.0, som er Microsofts nye LLM-baserede tale-modeller via Azure Foundry. Det er dem, jeg egentlig var mest nysgerrig på, fordi de ikke bare føles som "klassisk ASR med lidt bedre akustik". De virker som modeller, der også bruger sprogforståelse aktivt.

Så kørte jeg Azure Fast Transcription. Det er den mere klassiske sky-model. Hurtig, praktisk, velkendt. Den slags man nemt ender med at bruge, fordi den er lige ved hånden.

Og til sidst Parakeet-v3, en lokal model som kører offline på CPU på min egen maskine. Gratis. Ingen upload. Ingen cloud-regning. Bare min computer, der tygger sig igennem lyden.

Det lyder som den svære del: at få fire motorer til at transskribere samme lyd.

Det var det ikke.

Det svære var at finde ud af, hvem der faktisk havde ret.

Enighed er ikke kvalitet

Når man sidder med fire transcripts ved siden af hinanden, er det fristende at tænke: hvis tre modeller siger det samme, så er det nok rigtigt.

Men det er en fælde.

Enighed mellem modeller er ikke kvalitet. Det er bare enighed. Hvis alle fire modeller hører "midt setup" i stedet for "mit setup", så er de enige — og stadig forkerte.

Hvis jeg ville måle det her ordentligt, havde jeg brug for et facit. Altså en ground truth. En menneskeligt godkendt tekst, som modellerne kunne måles op imod.

Når man har et facit, kan man regne WER og CER.

WER står for Word Error Rate. Det er groft sagt andelen af ord, der er forkerte: ord der mangler, ord der er sat ind, eller ord der er byttet ud. Hvis 10 ud af 100 ord er forkerte, har du cirka 10% WER.

CER er det samme princip på bogstav-niveau. Character Error Rate. Den er tit lidt mere fair på dansk, fordi små bøjninger, sammensætninger og endelser kan få WER til at se hårdere ud, end fejlen opleves for et menneske.

Jeg målte også en "renset" WER. Her fjernede jeg fyldord som "øh" fra både facit og model, så modeller der pænt-vasker teksten ikke bliver straffet uretfærdigt for at gøre transcriptet mere læsbart.

Men først skulle jeg altså lave facit.

Så jeg byggede et lille label-værktøj

Jeg kunne selvfølgelig have brugt aftenen på at lede efter et eksisterende værktøj.

Der findes sikkert noget. Et akademisk annotation-tool. Et labeling-interface. Et eller andet med Docker Compose, en login-skærm, en database og en README, der næsten passer.

Men jeg kendte allerede mit problem ret præcist.

Jeg havde lyd. Jeg havde fire forslag. Jeg havde brug for at lytte sætning for sætning, se forskellene, vælge eller rette facit, og komme videre uden friktion.

Så jeg byggede det selv.

Ikke stort. Ikke smukt. Bare præcist nok.

Værktøjet viser en tidslinje af korte sætnings-klip. For hvert klip ligger de fire model-forslag side om side. Ord hvor modellerne er uenige, bliver markeret med farve, så øjet hurtigt fanger de interessante steder. Og der er en afspilknap pr. klip, så jeg kan høre den konkrete sætning igen og igen, indtil jeg tør skrive facit.

Det tog en aften.

Og det var markant hurtigere end at finde, forstå og tilpasse noget generisk.

Den dumme bias, jeg selv byggede ind

Jeg lavede selvfølgelig en fejl.

Den første version af værktøjet forhåndsudfyldte facit-feltet med den model, jeg allerede mistænkte var bedst: MAI-Transcribe 1.5.

Det føltes smart. Den var jo ofte tæt på. Så kunne jeg bare rette de småting, der var galt.

Men da jeg bagefter regnede scorerne, så MAI 1.5 absurd god ud. 56 ud af 60 segmenter var identiske med facit.

Det var ikke en sejr. Det var en selvevaluering.

Jeg havde givet modellen et forspring, og så målte jeg, hvor ofte jeg ikke gad ændre dens svar. Det er ikke det samme som kvalitet.

Så jeg lavede en blind tilstand.

Tom facit-boks. Forslagene blandet i tilfældig rækkefølge. Ingen modelnavne. Ingen farver, der afslører hvem der er hvem. Kun lyd og tekst.

Det gjorde arbejdet langsommere. Men det gjorde tallet ærligt.

I den første, biased runde lignede MAI 1.5 en model med cirka 0,3% WER. Efter den blinde runde landede den omkring 2,5%. Stadig virkelig stærkt. Bare ikke magisk.

Det er en vigtig forskel.

Resultaterne

Her er den korte version.

Jeg tog 20 segmenter fra optagelsen, labellede dem blindt i hånden, og målte alle fire motorer mod samme facit.

MAI-Transcribe 1.5 var klart bedst i den her test. Ikke lidt bedst. Markant bedst.

2,5% WER. 2,1% renset WER. 1,5% CER.

Det betyder ikke, at den aldrig fejler. Det gør den. Men fejlene er små nok til, at transcriptet føles brugbart med det samme. Det er forskellen på "jeg skal korrekturlæse" og "jeg skal redde teksten".

Azure Fast Transcription og MAI 1.0 landede næsten ens på rå WER: cirka 15%. Men de føltes ikke ens at læse.

Og Parakeet-v3 var klart bagefter på dansk i min test. 28,3% WER er meget, hvis transcriptet skal bruges til noget, der skal kunne søges i, citeres fra eller danne grundlag for en agent.

Til gengæld kører den lokalt. Offline. Gratis. Det er ikke uvæsentligt.

WER fortæller ikke hele historien

Den mest interessante måling var faktisk ikke WER.

Det var keyword recall.

Altså: hvor ofte fanger modellen de vigtige ord?

For et transcript af et teknisk webinar er det ikke lige meget, om modellen rammer "GitHub", "Netlify", "aktindsigt", "spec" og "prompt". Det er de ord, jeg senere vil søge efter. Det er de ord, en opsummering skal forstå. Det er de ord, en agent skal kunne hænge handlinger op på.

Her afslører tallene noget, WER skjuler.

Azure Fast Transcription ser egentlig fin ud med omkring 15% WER. Men den fangede kun 39% af nøgleordene i min lille test. Cirka 2 ud af 5 fagord.

Det er et problem.

For en bruger kan transcriptet godt se nogenlunde pænt ud, samtidig med at de vigtigste ord er forkerte. Så har man en tekst, der ligner dokumentation, men ikke fungerer som dokumentation.

MAI-modellerne klarede sig helt anderledes. MAI 1.0 ramte 78% af nøgleordene, selv om den havde problemer andre steder. MAI 1.5 ramte 100% i de segmenter, jeg målte.

Det er her, LLM-delen bliver tydelig.

De modeller virker ikke bare til at høre lyde. De virker til at forstå, hvilke ord der sandsynligvis giver mening i konteksten. Når jeg siger "Netlify" i en sætning om deployment, så er det ikke et tilfældigt mærkeligt lydmønster. Det er et produktnavn, der passer ind.

Og for mig er det næsten vigtigere end rå WER.

Hvis jeg bygger værktøjer ovenpå transcripts — søgning, resumeer, klipning, RAG, agent-flows — så er det afgørende, at de rigtige begreber er med.

De fejler på forskellige måder

Det blev også tydeligt, at modellerne ikke bare har "mere eller mindre fejl". De har forskellige personligheder.

Parakeet-v3 hører forkert.

Det er den klassiske ASR-fejl. "Mit setup" bliver til "midt setup". "Værktøjerne" bliver til noget i retning af "mærktøjne". Små lydlige forskydninger, som giver mening, hvis man kun tænker i fonetik, men som et menneske hurtigt ville rette ud fra konteksten.

MAI-Transcribe 1.0 renser for meget.

Den vil gerne lave en pæn tekst. Det er sympatisk, men farligt. Den sletter indhold, glatter sætninger ud og fjerner fyldord eller mellemled, som nogle gange faktisk betyder noget. Hvis man vil have et læsbart referat, kan det være fint. Hvis man vil have et transcript, er det et problem.

Azure Fast Transcription er ordtro, men ordblind.

Den prøver ikke at være smart på samme måde. Den holder sig tættere til det, den hører. Det giver en vis ærlighed i teksten. Men når der kommer fagord, engelske navne eller danske sammensætninger, falder den oftere af.

MAI-Transcribe 1.5 er ikke perfekt. Men den laver færre af de irriterende fejl. Den rammer både almindeligt dansk og de tekniske ord bedre. Den bevarer nok talesprog til, at det stadig er et transcript, men uden at efterlade mig med en masse støj.

Det lille værktøj var pointen

Hvis jeg kun skulle vælge en model ud fra den her test, ville svaret være nemt: MAI-Transcribe 1.5.

På dansk, i den her optagelse, var den i en helt anden liga. Omkring 10 gange bedre WER end den lokale Parakeet-model, hvis man sammenligner 2,5% med 28,3%. Og vigtigere: den fangede de ord, jeg faktisk har brug for.

Men det er næsten ikke den del, jeg tager mest med mig.

Det vigtigste var, at jeg manglede et måleværktøj — og byggede det.

Ikke som et produkt. Ikke som en platform. Bare som et lille, specifikt stykke værktøj til et konkret problem: "hjælp mig med at lave et ærligt facit og sammenligne fire transcripts".

Det tog en aften. Nu har jeg det. Næste gang jeg tester en tale-model, skal jeg ikke starte forfra. Jeg kan smide ny lyd ind, labelle blindt, regne scorer og se forskellene.

Det er hele ånden i "Byg dit eget" for mig.

Ikke fordi alt skal hjemmelaves. Ikke fordi man skal ignorere eksisterende værktøjer. Men fordi der er en særlig kraft i at kunne bygge præcis det værktøj, man mangler, når man mangler det.

Lille nok til at blive færdigt. Konkret nok til at være nyttigt. Dit nok til at passe i hånden.

Og nogle gange er det nok til, at resultaterne kan tale for sig selv.