Inde i de fire oversættelsespipelines, der driver InterMIND

Den gamle side /product/overview/how-it-works på mind.com er adskillige større udgivelser bagud. Den beskriver én enkelt "oversættelsesmotor", som de fleste leverandørsider gør: én stor pil fra "du taler" til "de hører". Det billede var allerede en forenkling for to år siden. I dag er det forkert.

Sandheden er, at InterMIND kører fire separate oversættelsespipelines, som hver løser et forskelligt problem med en forskellig motor, et forskelligt latensbudget og en forskellig kvalitetsramme. De deler en sprogvælger. De deler ikke motor.

Dette er det opdaterede svar på "hvordan virker det?"

Et ledsagende indlæg: "Hvor mange sprog understøtter I?" gennemgår, hvad hver pipeline dækker (23 / 23 / 30 / 17). Dette indlæg gennemgår, hvad hver pipeline gør — og hvorfor den er sin egen sag.

Hvorfor "én motor til det hele" er en løgn

En platform til live-møder har mindst fire opgaver at løse på samme tid, og de trækker i uforenelige retninger:

1. Tale i realtid — lyd ind, oversat lyd ud, mens taleren stadig taler, så hver deltager hører det på sit eget sprog. Den hårde begrænsning er latens.
2. Chattekst i realtid — korte beskeder, hurtigt, med redigeringer og citater og HTML-struktur bevaret.
3. Delte noter i realtid — fælles skrivning tegn for tegn, med strukturelt hierarki (lister, overskrifter, afkrydsningsfelter), som skal overleve oversættelsen.
4. Asynkrone dokumentfiler — en PDF på 40 sider, der bliver droppet i chatten. Intet latensbudget. Den hårde begrænsning er troskab — formatering, tabeller, sidetal, skrifttype.

Man kan bygge ét kæmpe LLM-kald, der forsøger at klare alle fire. Det har vi prøvet. Det er dårligt til alle fire. Latensbudgettet for tale betyder, at modellen ikke kan nå at tænke; troskabsbudgettet for dokumenter betyder, at den må. En chatredigering kræver en diff på seerens sprog; en PDF på 40 sider kræver en formatbevarelse, som ingen token-streamende model kan give.

Så vi kører fire. Her er hver af dem.

Pipeline 1: Oversættelse af tale i realtid

Problemet: En deltager taler fransk. En anden deltog på tysk, en tredje på brasiliansk portugisisk, en fjerde på japansk. Hver af dem skal høre taleren på sit eget sprog, i sit eget øre, med en forsinkelse, der er kort nok til, at øjenkontakt stadig er mulig.

Budgettet: lytteren må aldrig skulle vente på den. Når den oversatte tale halter så meget, at folk begynder at tale henover den, glider mødet mod "lad os bare skifte til engelsk".

Hvordan lyden egentlig bevæger sig

Et par ting er værd at nævne eksplicit:

• ASR kører på mediaserveren. Talerens lyd rejser over WebRTC til vores egen motor — Mind API hos OVH i Frankrig — og genkendes dér, på den samme server, som bærer opkaldet; browseren sender kun lyd og modtager ordene tilbage. Ingen separat taleleverandør og ingen ekstra omvej, før oversættelsen kan begynde. (Talebeskeder i chatten er undtagelsen: deres tale-til-tekst kører på Azure AI Speech, talesservicen i den standardindstillede AI-gateway.)
• Oversættelse er ikke én samlet udspredning. Motoren oversætter pr. målsprog, der er til stede i rummet, ikke pr. seer: oversættelsen til et sprog starter, når den første lytter på det sprog beder om en oversat strøm, tre deltagere, der har valgt tysk, deler én tysk oversættelse, og hvis ingen lytter på arabisk, oversættes der ikke noget til arabisk. Derfor koster et møde med fire sprog det samme som et møde med fyrre sprog, så længe man ser på, hvem der rent faktisk dukkede op — vi oversætter aldrig til sprog, som ingen deltager lytter på.
• Syntetiseret tale er pr. seer. Hver deltager modtager sit eget oversatte lydspor, mixet op mod den oprindelige talers video. De ser ikke et fælles "oversat møde" — de ser det samme møde, med deres personlige lydkanal oversat til det sprog, de har valgt. Derfor kan to personer i samme fysiske rum hver tage hovedtelefoner på og høre forskellige sprog.

Hvorfor det betyder noget, når et møde går skævt

I et opkald på 60 minutter med otte sprog går tingene i stykker på interessante måder: WebSockets falder ud, ASR fejltranskriberer midlertidigt et egennavn, én deltagers netværk bliver ustabilt. Arkitekturen ovenfor er det, der gør det muligt for os at isolere fejl: at én seers lyd hakker, påvirker ikke de øvrige syv, fordi oversættelsesmotoren aldrig frembragte "oversættelsen" i første omgang — den frembragte otte, parallelt, og kun den berørte skal komme sig.

Selve motoren er vores egen, hostet på vores egen infrastruktur. Vi router ikke tale i realtid gennem generelle LLM'er fra tredjepart. Latensbudgettet udelukker dem; historien om dataplacering udelukker dem for de regulerede kunder, som rent faktisk går op i den.

Det offentliggør vi om talekvalitet: /benchmark kører den produktive talepipeline mod FLORES-200-sætninger for hvert offentliggjort sprogpar, hver måned. Dommeren er navngivet (Gemini 3.7 Flash som primær, Claude Sonnet 5 som reserve). Hele fordelingen — median, p10, p90, min, maks, stikprøvestørrelse — står på siden. Se metoden for, hvad tallene måler, og hvad de ikke måler.

Pipeline 2: Oversættelse af chat i realtid

Problemet: Hver chatbesked i mødet oversat til hver deltager på deres eget sprog, i det øjeblik den bliver sendt. Plus redigeringer — og redigeringer skal ligne redigeringer, ikke genoversættelser.

Budgettet: løsere end for tale. En chatbesked kan godt tage et øjeblik om at dukke op på et andet sprog, uden at nogen lægger mærke til det. Det, folk går op i, er, om oversættelsen er korrekt, og om redigeringer giver mening.

Hvad chatpipelinen egentlig gør

Hver besked går gennem den samme oversættelsesmotor, som talepipelinen bruger — men med anden for- og efterbehandling:

• HTML-struktur bevares. Chatten understøtter rig tekst (afsnit, lister, citater, fed, kursiv). Vi konverterer til ren tekst til modellen, oversætter og pakker så resultatet ind i de oprindelige tags igen. Modellen ser aldrig HTML'en — den ser ren prosa.
• Citater oversættes uafhængigt. Hvis du svarer på en besked og citerer den, oversættes [QUOTE]…[/QUOTE]-blokken og det nye indhold som separate enheder, så modellen ikke kan forveksle de to.
• Lange beskeder deles i bidder. Vi deler ved afsnitsgrænser ved 1.000 tegn pr. bid. Hver bid er sit eget oversættelseskald. Vi fodrer ikke modellen med romaner på 4.000 tegn i ét hug — fejlmønstrene (afkortning, tabte afsnit, afbrudte sætninger) er for grimme.
• Oversættelse sker efter behov. Vi bruger en IntersectionObserver: en besked oversættes først, når den ruller ind i seerens synsfelt. Når man skiftede sprog i en langvarig kanal, blev tidligere hvert eneste oversættelseskald fra historikken afspillet igen. Det sker ikke længere.

Den interessante del: redigeringer som diffs

I v1.2 ændrede vi, hvordan chatredigeringer opfører sig for seere på et andet sprog. Den gamle opførsel var: nogen redigerer en besked, vi genoversætter det hele, og du ser et nyt afsnit og må selv finde ud af, hvad der er flyttet.

Den nye opførsel:

1. Den oprindelige besked var allerede oversat til dit sprog.
2. Når afsenderen redigerer, genoversætter vi den nye version.
3. Vi beregner diffen mellem din forrige oversættelse og din nye oversættelse, på dit sprog.
4. Vi viser den diff inline — på samme måde som Git viser, hvad der er ændret.

Så når "review by Tuesday" bliver til "review by Thursday" på engelsk, ser din spansklæsende kollega martes → jueves fremhævet i stedet for et genoversat afsnit, som hun skal læse igen.

Det krævede, at vi behandlede chatpipelinen som en tilstandsfuld cache pr. seer, ikke som et tilstandsløst oversæt-på-forespørgsel-endpoint. Dokumenter og tale har ikke brug for det. Chat har.

Pipeline 3: Oversættelse af delte noter i realtid

Problemet: Værten åbner et panel med delte noter og begynder at skrive. Hver deltager ser noterne på sit sprog, tegn for tegn, med dokumentets struktur — overskrifter, indlejrede lister, tjeklister, kodeblokke — intakt.

Budgettet: Det samme som for chat, men med to ekstra begrænsninger:

• Det, der oversættes, ændrer sig undervejs. Værten skriver stadig. Et naivt system, der oversætter "hele dokumentet" ved hvert tastetryk, giver flimmer og æder API-budgettet. Vi oversætter på den ændrede enheds granularitet, ikke hele dokumentet.
• Strukturen skal overleve. Hvis du beder en oversættelsesmodel om at oversætte en markdown-klump med tre indlejrede lister, får du noget tilbage, der ligner originalen, men med subtilt fladtrykt hierarki, omnummererede punkter eller flyttede indrykninger. Vi lader ikke modellen se hele klumpen.

Hvordan notepipelinen adskiller sig fra chat

Strukturbevarelsen er hovedpointen. Vi oversætter hvert listepunkt uafhængigt i stedet for som ét dokument. Modellen ser:

"Compliance review — Q2 deliverables"

— ikke:

"# Project plan\n## Quarter\n- Compliance review — Q2 deliverables\n- Vendor scoring\n - Tier 1 vendors..."

Det omgivende dokument — <ul>, overskrifterne, indrykningen — genopbygges på klientsiden med den samme struktur, som det oprindelige dokument havde, hvor hvert bladknudepunkt er skiftet ud med sin oversættelse. Modellen får aldrig lov til at "forbedre" hierarkiet.

Noter bruger også den samme diff-model pr. seer som chatredigeringer: hvis værten ændrer en linje, ser seere på andre sprog de ændrede ord fremhævet i stedet for et nyt afsnit.

Pipeline 4: Asynkron oversættelse af dokumenter

Problemet: Nogen dropper en PDF på 40 sider, et Word-dokument, en PowerPoint-præsentation eller et Excel-ark i chatten. Hver deltager kan anmode om en kopi på sit eget sprog. Den oversatte fil skal ligne originalen — samme skrifttyper, samme tabeller, samme sidetal, samme sidehoveder, samme diagrammer på plads.

Budgettet: Ingen begrænsning i realtid. Et minut er fint. To minutter er fint. Begrænsningen er troskab — hvis den oversatte PDF ikke ligner originalen, vil modtageren ikke stole på den.

Hvorfor denne pipeline ikke deler motor med tale

En generel LLM, selv en rigtig god en, giver dig en oversat tekst af et dokument tilbage. Den giver dig ikke en oversat PDF med samme layout. Modellen har ingen forestilling om "sideskift, der skal passe med kilden" eller "tabelcelle, der skal beholde sin kolonnebredde".

Til denne flade bruger vi direkte DeepL Document API. Den er bygget til at oversætte filer som filer, ikke prosa udtrukket fra filer. DeepL håndterer:

• PDF (med bevaret layout)
• DOCX, DOC
• PPTX
• XLSX

Dokumentet uploades til DeepL's pipeline, oversættes server-side med formateringen intakt og returneres i det samme format. Derefter uploader vi resultatet til vores objektlager og viser det i chatten som en vedhæftning, der kan downloades.

Hvad det koster, og hvorfor vi ikke skjuler det

DeepL fakturerer minimum 50.000 tegn pr. dokument — cirka én amerikansk dollar pr. fil på Pro-niveauet, uanset om dokumentet er én side eller tredive. Vi absorberer den omkostning i stedet for at opkræve pr. fil; den dukker op i mødets oversættelsesforbrug som fakturerede tegn, omregnet til ordenheder, der svarer til den måde, resten af produktet rapporterer oversættelsesaktivitet på.

Vi valgte DeepL til denne flade, fordi oversættelse af filer som filer er præcis det, det er bygget til — vi forsøgte ikke at bygge en bedre. Det modsatte gælder ikke — DeepL kører ikke en live-talepipeline af den slags, vi byggede til møder. Forskellige problemer; forskellige værktøjer. Den ærlige version af "hvad driver InterMIND-oversættelse" er "den rigtige motor til hver pipeline" — ikke "vores motor, overalt".

Sprog, som denne pipeline dækker, og som tale ikke gør

Dokumentpipelinen når 30 sprog mod 23 for tale. Ekstrasprogene omfatter: bulgarsk, græsk, estisk, indonesisk, litauisk, lettisk, slovakisk, slovensk. (Arabisk står også på denne liste og er et af ekstrasprogene: det er trukket tilbage fra vælgeren til realtid, mens dets talekvalitet ligger under vores standard, og dets scores pr. sprogpar forbliver offentlige på /benchmark — det tal er det, der får det tilbage. Asymmetrien går den anden vej for hindi — live på tale, endnu ikke på filer.)

Den asymmetri er reel. Den betyder, at en fransk deltager i et møde kan anmode om kontrakt-PDF'en på estisk, selv om vedkommende ikke kan lytte til mødet på estisk. Vi markerer det i vælgeren i stedet for at glatte det ud med ét enkelt tal. Begrundelsen står i indlægget om sprogantal.

Hvor pipelinerne mødes

De fire pipelines kører ikke isoleret. Et mødelokale er stedet, hvor de rører ved hinanden, og sammenføjningerne har betydning:

• En chatbesked med en dokumentvedhæftning udløser chatpipelinen for teksten og dokumentpipelinen for filen. Deltageren på et andet sprog ser beskeden oversat med det samme, mens oversættelsen af vedhæftningen ankommer asynkront som en fil, der kan downloades.
• En delt note, der citerer en transskriptionslinje, krydser noter ↔ tale. Transskriptionen er det, talepipelinen frembragte for afsenderens sprog; noteoversættelsen frembringer en kopi pr. seer af det citat på alle andres sprog, med kildeangivelsen bevaret.
• En transskription eksporteret efter mødet kører tekstpipelinen i chatstil over hele samtalen og producerer en fil pr. sprog, som deltagerne kan downloade. Det er den samme kodesti som chatoversættelse, bare i batch.

Sprogvælgeren er ét stykke brugerflade. Infrastrukturen nedenunder er fire pipelines, der taler sammen.

Hvad vi bevidst ikke forsøger

• Ingen "samlet oversættelsesmodel". Vi bygger ikke én model, der klarer tale, chat, noter og dokumenter. Afvejningen mellem latens og troskab har ingen vinder. Vi bruger den rigtige motor til hver flade.
• Ingen stiltiende omdirigering. Hvis filpipelinen i dag ikke kan oversætte til hindi, falder vi ikke stille tilbage på talemotoren og lader, som om det virkede — filvælgeren markerer hullet i stedet for at skjule det.
• Ingen "vi oversætter til 200 sprog". Vores motor udsender 24. De live flader leverer 23, dokumenter 30 — og i stedet for ét markedsføringsvenligt tal offentliggøres kvaliteten pr. sprogpar, som skal kunne stå foran en revisor, på /benchmark, svagere par inklusive.

Prøv det selv

• Prøv live-demoen — kører den levende talepipeline mod din lyd, på et hvilket som helst af de 23 produktsprog. Den samme pipeline, som scorer /benchmark.
• Se benchmarken — kvalitet pr. par og pr. måned på rigtig trafik. Hvert par i vælgeren, stærkt eller svagt, kan deep-linkes.
• Læs metoden — hvad tallene er, hvad de ikke er, og hvem dommeren er.

Fire pipelines, fire motorer, ét mødelokale. Det er den ærlige afløser for den gamle how-it-works-side.

— Mind.com-teamet

Kilder: DeepL — understøttede sprog, DeepL — forbrugsopgørelse og fakturering (minimum på 50.000 tegn pr. fil), FLORES-200; interne pipelinefakta verificeret mod den udrullede kode, kontrolleret i august 2026.