Google lancerer Gemini 3.5 Transcribe
Ifølge MarkTechPost har Google frigivet Gemini 3.5 Transcribe som to separate endpoints: gemini-3.5-transcribe til forudindspillede filer via Interactions API og gemini-3.5-transcribe-live til bidirektionel streaming via Live API. MarkTechPost skriver, med henvisning til Artificial Analysis, at gennemsnitlig WER måles til 2,6 procent for ikke‑streaming og 4,0 procent for streaming. Samme artikel tilføjer, at Google rapporterer en 70 procents forbedring i tid‑til‑endelig transkription i forhold til Chirp 3, samt automatisk sprogdetektion for 85+ sprog og håndtering af code‑switching midt i sætninger.
De tal er operationelt vigtige, men de er tredjepartsrapporterede. API‑navne, parametre, sessionslofter og ordlyd for privatliv i betalt spor bør derfor verificeres i Googles egne dokumenter, før nogen binder sig i kontrakter eller SLA’er.
To endpoints, to forskellige virkeligheder
Live API’et er bygget til realtid. Ifølge MarkTechPost leverer det løbende under‑sekunds transskription og sender både spekulative delvise tekster, mens der tales, og endelige transskriptioner, når en taletur afsluttes. Lyden forventes som rå 16‑bit PCM i mono ved 16 kHz, typisk i bidder på cirka 100 ms. Omtalen nævner understøttelse af automatisk, hybrid og manuel voice activity detection samt brug af kortlivede tokens på mobil og web.
Begrænsningerne er tydelige ifølge samme kilde: Live‑sessions stopper omkring 10 minutters kontinuerlig streaming. Der er ingen speaker diarization og ingen ordniveau‑tidsstempler. Det er byttet for lav latens og kontinuitet.
Interactions API’et dækker det, streaming ikke kan. MarkTechPost beskriver speaker diarization, ordniveau‑start og ‑sluttoffsets og mulighed for at give modellen en vokabularliste til biasing. Her angives “op til 1.000 termer” som loft, med bedst kvalitet under 100 – igen som rapporteret, ikke som verificerede ingeniørgrænser. Standardforespørgsler accepterer cirka én times lyd, men loftet falder til cirka 30 minutter, når man aktiverer diarization eller ordtidsstempler.
Verbatim eller smart er et reelt designvalg
Begge endpoints tilbyder to output‑modes. Verbatim gengiver alt. Fillerord, gentagelser, halve rettelser. Smart fjerner disfluenser, retter selvkorrektioner ind i sætningen og formaterer pænere. Ifølge MarkTechPost, med et eksempel Google selv bruger: “Um, so for the meeting, I think we should, uh, invite Alice and, wait no, Bob and Carol.” Verbatim beholder hele sekvensen. Smart returnerer: “For the meeting, I think we should invite Bob and Carol.”
Det praktiske greb: Smart kan ikke kombineres med ordtidsstempler eller diarization. En læsbar, stram tekst og en reviderbar, auditbar transskription er to forskellige kald. Det rammer produktdesign direkte, især hvis man både vil have skærmtekst til mennesker og dyb efterbehandling i systemer.
Et konkret valg i hverdagen: live captions i et webinar, hvor publikum skal kunne følge med, fungerer ofte bedst med verbatim. En efterfølgende post‑call analytics‑pipeline vil som regel kræve Interactions med diarization og tidsstempler.
Hvad WER‑tal siger – og hvad de ikke siger
MarkTechPost tilskriver Artificial Analysis målingerne på gennemsnitlig WER: 4,0 procent for streaming og 2,6 procent for ikke‑streaming. I samme gennemgang nævnes FLEURS‑benchmark med 5,50 procent (streaming) og 5,04 procent (ikke‑streaming) på tværs af sprog og lokationer. Tallene er lovende, men de er indikatorer, ikke garantier. Uden fuld metodebeskrivelse for dataset, støjforhold og sprogfordeling kan de ikke sammenlignes én‑til‑én med andre leverandører.
Den rapporterede 70 procents forbedring i tid‑til‑endelig transkription over Chirp 3 er også stærk på papiret, men oplevet latens afhænger i praksis af netværk, buffere og hvor ofte interim‑tekster omskrives, før de låses.
Arkitekturvalg med regnearkskanter
To endpoints betyder to produktlinjer i praksis. Live til hurtige assistenter, push‑to‑talk, live captions og voice UI’er, hvor et sekund føles langt. Interactions til længere optagelser, speaker‑split og efterbehandling. Det er ikke bare et flag i et API‑kald – det ændrer dataflow, backlog og testcases.
For lange møder er der to realistiske spor: 1) chunk live‑lyden og acceptér små huller, eller 2) kør Live til skærmtekst og Interactions bagefter for compliance og analyse. Dobbeltarbejde, ja, men ofte rigtigt i drift.
Omkostningerne følger med. Ifølge MarkTechPost er feature‑sæt, grænser og pris ikke ens. Modellér derfor forbrug per use case: minutter live vs. batch, varighed pr. session, andel med diarization/tidsstempler og overhead fra retries. Små valg skalerer i volumen.
Privatliv, EU‑hensyn og enterprise‑vejbanen
MarkTechPost anfører, at udviklere kan starte via Google AI Studio på en gratis bane, og at betalte planer giver højere rate limits. Samme artikel fremhæver, at betalt spor lover, at kundeindhold ikke bruges til at forbedre Googles produkter. Den formulering bør altid tjekkes i officielle vilkår og databehandleraftaler – særligt med EU‑krav til dataflow og opbevaring.
For regulerede kunder beskriver MarkTechPost en Enterprise Agent Platform med provisioneret throughput, compliance‑kontroller og volumenrabatter. Ifølge samme kilde er både udvikler‑ og enterprise‑spor i public preview. Det kalder på forsigtighed i go‑live, change management og fallback.
Og en simpel, men vigtig konstatering fra kilden: API‑only, managed service. Ingen åbne vægte, ingen self‑hosting. On‑prem‑scenarier er dermed ikke på bordet.
Realtime UX uden rod i teksten
Live API’et sender midlertidige, spekulative bidder, der siden kan blive til en endelig sætning. Det er effektivt – men kræver design, så skiftet ikke ligner en fejl. Marker tydeligt forskel på midlertidig og endelig tekst. I voice‑agenter bør intents ikke låses, før den endelige transskription bekræfter budskabet.
Gå praktisk til værks i piloten: mål procent‑del af ord der ændres fra interim til final, gennemsnitlig finaliseringslatens, og hvor ofte brugere misforstår skiftet (en simpel UI‑prompt efter opgaven er nok). Følg også VAD‑fejl, hvor talestop klippes for tidligt.
Mikrofonkontrol, automatisk VAD, edge‑buffering ved dårlig mobilforbindelse og en hurtig “gentag sidste sætning”‑funktion er de små ting, der får realtid til at føles som realtid.
Drift og kvalitet uden tomgang
Selv lave WER‑tal kræver overvågning. Track WER pr. sprog, latens pr. region, antal interim‑til‑final‑omskrivninger, fejl ved code‑switching og hvor ofte Live rammer sessionsloftet. Det peger hurtigt på, om designet bør chunkes, eller om en del skal ud i Interactions.
Testcases skal ligne hverdagen: mødelokale med let ekko, medicinske termer, juridiske navne, dialoger med mange selvkorrektioner. Tjek hvor meget smart‑mode hjælper, og hvornår den går for langt.
Top 5 acceptance‑kriterier til jeres pilot
- WER‑mål per sprog og domæne (baseline vs. mål, fx 2–5 procent afhængigt af støj).
- End‑to‑end latens i Live (median og P95 fra tale til final).
- Stabilitet i interim→final: andel ord ændret, og hvor ofte sætninger vendes 180 grader.
- Diarization‑nøjagtighed i Interactions (speaker‑switch‑fejl pr. minut).
- Compliance‑check: dokumenteret datapolitik i betalt spor og aftalt dataopbevaring.
Omkostninger uden tåge
Byg en enkel model: minutpriser pr. endpoint, andel streaming vs. batch, gennemsnitlig varighed og tilvalg som diarization/tidsstempler. Læg 10–20 procent oveni til retries og gentagelser. Justér efter første måneds faktiske brug. Bland ikke live‑captions og post‑call analytics i samme pipeline – de har forskellige kvalitets‑ og latenskrav og giver pænere cost‑rapportering, når de deles op.
Top 5 risici at skrive på tavlen
- API‑only uden self‑hosting (ingen on‑prem‑vej).
- Live‑sessions omkring 10 minutter, ifølge MarkTechPost.
- Ingen diarization eller ordtidsstempler i Live, ifølge MarkTechPost.
- Ufulde pris‑ og kvotedetaljer pr. endpoint i offentlige kilder.
- Public preview‑status for både udvikler‑ og enterprise‑spor.
Hvad man bør gøre nu
Hold en kort intern session på tværs af produkt, arkitektur og drift. Udpeg to pilotcases: én live‑orienteret (captions eller simpel voice‑agent) og én batch‑orienteret (mødenotat med diarization og tidsstempler). Sæt klare acceptance‑kriterier som ovenfor.
Byg en lille proof‑of‑concept med begge endpoints. I Live testes interim‑output, VAD‑robusthed og session‑timeouts. I Interactions testes diarization‑kvalitet, tidsstempler og vokabular‑biasing (kapaciteter og “bedst under 100” som rapporteret af MarkTechPost). Dokumentér hvor smart‑mode hjælper, og hvor den går for langt.
Afslut piloten med et verifikations‑tjek: API‑navne/parametre i Googles dokumenter, sessionsgrænser, audioformat, token‑håndtering, samt skriftlig ordlyd for betalt‑spors datapolitik og eventuelle enterprise‑SLA’er. Så bliver tallene til beslutninger.
