Bak de fire oversettelses-pipelinene som driver InterMIND

Den gamle siden /product/overview/how-it-works på mind.com er flere store utgivelser på etterskudd. Den beskriver én enkelt «oversettelsesmotor», slik de fleste leverandørsider gjør: én stor pil fra «du snakker» til «de hører». Det bildet var en forenkling allerede for to år siden. I dag er det feil.

Sannheten er at InterMIND kjører fire separate oversettelses-pipelines. Hver løser sitt eget problem med sin egen motor, sitt eget latensbudsjett og sitt eget kvalitetsspenn. De deler en språkvelger. De deler ikke motor.

Dette er det oppdaterte svaret på «hvordan fungerer det?».

Et følgeinnlegg: «Hvor mange språk støtter dere?» tar for seg hva hver pipeline dekker (23 / 23 / 30 / 17). Dette innlegget tar for seg hva hver pipeline gjør, og hvorfor den er sin egen greie.

Hvorfor «én motor til alt» er en løgn

En plattform for live møter har minst fire jobber å gjøre samtidig, og de drar i uforenlige retninger:

1. Tale i sanntid — lyd inn, oversatt lyd ut mens den som snakker fortsatt snakker, med hver seer på sitt eget språk. Den harde begrensningen er latens.
2. Chattekst i sanntid — korte meldinger, raskt, med redigeringer og siteringer og HTML-struktur bevart.
3. Delte notater i sanntid — samskriving tegn for tegn, med strukturelt hierarki (lister, overskrifter, avkrysningsbokser) som må overleve oversettelsen.
4. Asynkrone dokumentfiler — en PDF på 40 sider som slippes i chatten. Ingen latensbudsjett. Den harde begrensningen er troskap: formatering, tabeller, sidetall, skrifttype.

Du kan bygge ett gigantisk LLM-kall som prøver å gjøre alle fire. Vi prøvde. Det er dårlig på alle fire. Latensbudsjettet for tale betyr at modellen ikke får tenke, mens troskapsbudsjettet for dokumenter betyr at den må. En chatredigering trenger en diff på seerens språk, og en PDF på 40 sider trenger formatbevaring som ingen modell som strømmer tokens kan gi deg.

Så vi kjører fire. Her er hver av dem.

Pipeline 1: Taleoversettelse i sanntid

Problemet: En deltaker snakker fransk. En annen ble med på tysk, en tredje på brasiliansk portugisisk, en fjerde på japansk. Hver enkelt må høre den som snakker på sitt eget språk, i sitt eget øre, med en forsinkelse så kort at øyekontakt fortsatt er mulig.

Budsjettet: lytteren skal aldri måtte vente på den. Når oversatt tale henger så mye etter at folk begynner å snakke i munnen på den, glir møtet mot «la oss bare bytte til engelsk».

Hvordan lyden faktisk beveger seg

Noen ting er verdt å nevne eksplisitt:

• ASR kjører på mediaserveren. Lyden fra den som snakker går over WebRTC til vår egen motor — Mind API hos OVH i Frankrike — og gjenkjennes der, på samme server som bærer samtalen. Nettleseren sender bare lyd og mottar ordene tilbake. Ingen separat taleleverandør og ingen ekstra omvei før oversettelsen kan starte. (Talenotater i chat er unntaket: talen til tekst kjører på Azure AI Speech, taletjenesten i standard AI-gateway.)
• Oversettelsen er ikke én enkelt fan-out. Motoren oversetter per målspråk som er til stede i rommet, ikke per seer: oversettelsen til et språk starter når den første lytteren på det språket ber om en oversatt strøm. Tre deltakere som valgte tysk, deler én tysk oversettelse, og hvis ingen lytter på arabisk, oversettes det ingenting til arabisk. Derfor koster et møte med fire språk det samme som et møte med førti språk, så lenge det gjelder hvem som faktisk dukket opp — vi oversetter aldri til språk ingen deltaker lytter på.
• Syntetisk tale er per seer. Hver deltaker mottar sitt eget oversatte lydspor, mikset mot videoen av den opprinnelige taleren. De ser ikke på et felles «oversatt møte» — de ser på det samme møtet, med sin personlige lydkanal oversatt til språket de har valgt. Derfor kan to personer i samme fysiske rom hver sette på hodetelefoner og høre ulike språk.

Hvorfor dette er viktig når et møte går skeis

I en samtale på 60 minutter med åtte språk går ting i stykker på interessante måter: WebSockets faller ut, ASR feiltranskriberer midlertidig et egennavn, nettverket til én deltaker blir hakkete. Arkitekturen over er det som lar oss isolere feil: at lyden hos én seer hakker, påvirker ikke de sju andre, fordi oversettelsesmotoren aldri laget «oversettelsen» i utgangspunktet — den laget åtte, parallelt, og bare den berørte må komme seg på beina igjen.

Selve motoren er vår, og den kjører på vår egen infrastruktur. Vi ruter ikke tale i sanntid gjennom tredjeparts generelle LLM-er. Latensbudsjettet utelukker dem, og dataresidens utelukker dem for de regulerte kundene som faktisk bryr seg om det.

Hva vi publiserer om talekvalitet: /benchmark kjører den faktiske talepipelinen i produksjon mot FLORES-200-setninger for hvert publiserte språkpar, hver måned. Dommeren er navngitt (Gemini 3.7 Flash som primær, Claude Sonnet 5 som reserve). Hele fordelingen — median, p10, p90, min, maks og utvalgsstørrelse — står på siden. Se metodikken for hva tallene måler og ikke måler.

Pipeline 2: Chatoversettelse i sanntid

Problemet: Hver chatmelding i møtet oversettes for hver deltaker på deres eget språk, i det den sendes. Pluss redigeringer — og redigeringer må se ut som redigeringer, ikke som nyoversettelser.

Budsjettet: romsligere enn for tale. En chatmelding kan bruke et øyeblikk på å dukke opp på et annet språk uten at noen bryr seg. Det folk bryr seg om, er om oversettelsen er riktig og om redigeringene gir mening.

Hva chatpipelinen faktisk gjør

Hver melding går gjennom den samme oversettelsesmotoren som talepipelinen bruker, men med annen for- og etterbehandling:

• HTML-strukturen bevares. Chatten støtter rik tekst (avsnitt, lister, sitater, fet, kursiv). Vi konverterer til ren tekst for modellen, oversetter og pakker deretter resultatet inn igjen i de opprinnelige taggene. Modellen ser aldri HTML-en — den ser ren prosa.
• Sitater oversettes uavhengig. Hvis du svarer på en melding og siterer den, oversettes blokken [QUOTE]…[/QUOTE] og det nye innholdet som separate enheter, slik at modellen ikke kan blande de to.
• Lange meldinger deles opp. Vi deler ved avsnittsgrenser på 1 000 tegn per bit. Hver bit er sitt eget oversettelseskall. Vi gir ikke modellen romaner på 4 000 tegn i ett jafs — feilmønstrene (avkorting, tapte avsnitt, avbrutte setninger) er for stygge.
• Oversettelsen er lat. Vi bruker en IntersectionObserver: en melding oversettes først når den ruller inn i seerens synsfelt. Å bytte språk i en kanal med lang historikk pleide å spille av hvert eneste oversettelseskall fra historikken på nytt. Nå gjør det ikke det.

Det interessante: redigeringer som diffs

I v1.2 endret vi hvordan chatredigeringer oppfører seg for seere på et annet språk. Den gamle oppførselen var: noen redigerer en melding, vi oversetter hele greia på nytt, og du får et helt nytt avsnitt og må selv finne ut hva som flyttet seg.

Den nye oppførselen:

1. Den opprinnelige meldingen var allerede oversatt til ditt språk.
2. Når avsenderen redigerer, oversetter vi den nye versjonen.
3. Vi beregner diffen mellom din forrige oversettelse og din nye oversettelse, på ditt språk.
4. Vi viser diffen direkte i teksten — på samme måte som Git viser deg hva som er endret.

Så når «review by Tuesday» blir til «review by Thursday» på engelsk, ser din spansklesende kollega martes → jueves uthevet, ikke et nyoversatt avsnitt hun må lese på nytt.

Dette krevde at vi behandlet chatpipelinen som en tilstandsfull cache per seer, ikke som et tilstandsløst endepunkt som oversetter på forespørsel. Dokumenter og tale trenger ikke dette. Chat gjør.

Pipeline 3: Oversettelse av delte notater i sanntid

Problemet: Verten åpner et panel for delte notater og begynner å skrive. Hver deltaker ser notatene på sitt språk, tegn for tegn, med dokumentets struktur — overskrifter, nøstede lister, sjekklister, kodeblokker — intakt.

Budsjettet: Det samme som for chat, men med to ekstra begrensninger:

• Det som oversettes, endrer seg underveis. Verten skriver fortsatt. Et naivt system som oversetter «hele dokumentet» for hvert tastetrykk, gir flimmer og brenner opp API-budsjettet. Vi oversetter på granularitet av den endrede enheten, ikke hele dokumentet.
• Strukturen må overleve. Hvis du ber en oversettelsesmodell oversette en markdown-blokk med tre nøstede lister, får du tilbake noe som ser ut som originalen, men med subtilt flatet ut hierarki, omnummererte punkter eller flyttet innrykk. Vi lar ikke modellen se hele blokken.

Hvordan notatpipelinen skiller seg fra chat

Strukturbevaringen er hovedsaken. Vi oversetter hvert listepunkt uavhengig i stedet for som ett dokument. Modellen ser:

«Compliance-gjennomgang — leveranser Q2»

— ikke:

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

Det omsluttende dokumentet — <ul>, overskriftene, innrykket — bygges opp igjen på klientsiden med samme struktur som originaldokumentet hadde, og hver bladnode byttes ut med sin oversettelse. Modellen får aldri «forbedre» hierarkiet.

Notater bruker også den samme diff-modellen per seer som chatredigeringer: hvis verten endrer en linje, ser seere på andre språk de endrede ordene uthevet, ikke et nytt avsnitt.

Pipeline 4: Asynkron dokumentoversettelse

Problemet: Noen slipper en PDF på 40 sider, et Word-dokument, en PowerPoint-presentasjon eller et Excel-ark i chatten. Hver deltaker kan be om en kopi på sitt eget språk. Den oversatte filen må se ut som originalen — samme skrifttyper, samme tabeller, samme sidetall, samme topptekster, samme diagrammer på plass.

Budsjettet: Ingen sanntidsbegrensning. Ett minutt er greit. To minutter er greit. Begrensningen er troskap — hvis den oversatte PDF-en ikke ser ut som originalen, stoler ikke mottakeren på den.

Hvorfor denne pipelinen ikke deler motor med tale

En generell LLM, selv en veldig god en, gir deg tilbake en oversatt tekst av et dokument. Den gir deg ikke tilbake en oversatt PDF med samme layout. Modellen har ingen forestilling om «sideskift som må stemme med kilden» eller «tabellcelle som må beholde kolonnebredden sin».

For denne flaten bruker vi DeepL Document API direkte. Den er bygget for å oversette filer som filer, ikke prosa hentet ut av filer. DeepL håndterer:

• PDF (med layoutbevaring)
• DOCX, DOC
• PPTX
• XLSX

Dokumentet lastes opp til DeepLs pipeline, oversettes på serversiden med formateringen intakt og returneres i samme format. Deretter laster vi resultatet opp til vår egen objektlagring og viser det i chatten som et vedlegg som kan lastes ned.

Hva dette koster, og hvorfor vi ikke skjuler det

DeepL fakturerer minimum 50 000 tegn per dokument — omtrent én amerikansk dollar per fil på Pro-nivået, uansett om dokumentet er én side eller tretti. Vi tar den kostnaden selv i stedet for å fakturere per fil. Den dukker opp i møtets oversettelsesbruk som fakturerte tegn, omregnet til ordenheter som samsvarer med måten resten av produktet rapporterer oversettelsesaktivitet på.

Vi valgte DeepL for denne flaten fordi å oversette filer som filer er akkurat det den ble bygget for — vi prøvde ikke å bygge en bedre. Det samme gjelder ikke andre veien — DeepL driver ikke en live talepipeline av den typen vi bygde for møter. Ulike problemer, ulike verktøy. Den ærlige versjonen av «hva driver InterMIND-oversettelse» er «riktig motor per pipeline» — ikke «vår motor, overalt».

Språk denne pipelinen dekker som tale ikke gjør

Dokumentpipelinen når 30 språk, mot 23 for tale. Tilleggene inkluderer: bulgarsk, gresk, estisk, indonesisk, litauisk, latvisk, slovakisk, slovensk. (Arabisk står også på denne listen, og det er ett av tilleggene: det er tatt ut av sanntidsvelgeren så lenge talekvaliteten ligger under lista vår, og poengene per språkpar forblir offentlige på /benchmark — det er det tallet som bringer det tilbake. Asymmetrien går motsatt vei for hindi — tilgjengelig for tale, ennå ikke for filer.)

Den asymmetrien er reell. Den betyr at en fransk deltaker i et møte kan be om kontrakt-PDF-en på estisk selv om vedkommende ikke kan lytte til møtet på estisk. Vi markerer det i velgeren i stedet for å glatte det over med ett enkelt tall. Begrunnelsen står i innlegget om språkantall.

Der pipelinene møtes

De fire pipelinene kjører ikke isolert. Et møterom er stedet der de berører hverandre, og sømmene har betydning:

• En chatmelding med et dokumentvedlegg utløser chatpipelinen for teksten og dokumentpipelinen for filen. Deltakeren på et annet språk ser meldingen oversatt umiddelbart, og vedleggsoversettelsen kommer asynkront som en nedlastbar fil.
• Et delt notat som siterer en transkripsjonslinje krysser notater ↔ tale. Transkripsjonen er det talepipelinen produserte for avsenderens språk, og notatoversettelsen lager en kopi av sitatet per seer på alle andres språk, med kildehenvisningen bevart.
• En transkripsjon eksportert etter møtet kjører den chat-lignende tekstpipelinen over hele samtalen og lager en fil per språk som deltakerne kan laste ned. Dette er den samme kodeveien som chatoversettelse, bare i batch.

Språkvelgeren er én enkelt del av brukergrensesnittet. Infrastrukturen under er fire pipelines som snakker med hverandre.

Hva vi bevisst ikke prøver på

• Ingen «samlet oversettelsesmodell». Vi bygger ikke én modell som gjør tale, chat, notater og dokumenter. Avveiningen mellom latens og troskap har ingen vinner. Vi bruker riktig motor per flate.
• Ingen stille omruting. Hvis filpipelinen ikke kan oversette til hindi i dag, faller vi ikke stille tilbake på talemotoren og later som om det gikk bra — filvelgeren markerer hullet i stedet for å skjule det.
• Ingen «vi oversetter til 200 språk». Motoren vår gir ut 24. De live flatene har 23, dokumenter 30 — og i stedet for ett markedsvennlig tall publiseres kvaliteten per språkpar, den som må kunne stå frem foran en revisor, på /benchmark, svakere par inkludert.

Prøv selv

• Prøv live-demoen — kjører den levende talepipelinen mot din egen lyd, på alle de 23 produktspråkene. Den samme pipelinen som gir poengene på /benchmark.
• Se benchmarken — kvalitet per språkpar og per måned på reell trafikk. Hvert par i velgeren, sterkt eller svakt, kan lenkes direkte til.
• Les metodikken — hva tallene er, hva de ikke er, og hvem dommeren er.

Fire pipelines, fire motorer, ett møterom. Det er den ærlige erstatningen for den gamle how-it-works-siden.

— Mind.com-teamet

Kilder: DeepL — supported languages, DeepL — usage count and billing (minimumsgrensen på 50 000 tegn per fil), FLORES-200; interne pipelinefakta verifisert mot den utgitte koden, kontrollert august 2026.