Så fungerar de fyra översättningsflödena bakom InterMIND

Den gamla sidan /product/overview/how-it-works på mind.com ligger flera stora versioner efter. Den beskriver en enda "översättningsmotor" på det sätt som de flesta leverantörers sidor gör: en stor pil från "du talar" till "de hör". Redan för två år sedan var den bilden en förenkling. Idag stämmer den inte.

Sanningen är att InterMIND kör fyra separata översättningsflöden. Vart och ett löser ett eget problem med en egen motor, en egen latensbudget och en egen kvalitetsram. De delar språkväljare. De delar inte motor.

Det här är det uppdaterade svaret på frågan "hur fungerar det?".

Ett kompletterande inlägg: "Hur många språk stöder ni?" går igenom vad varje flöde täcker (23 / 23 / 30 / 17). Det här inlägget handlar om vad varje flöde gör – och varför det är något eget.

Varför "en motor för allt" är en lögn

En plattform för levande möten har minst fyra uppgifter att sköta samtidigt, och de drar åt oförenliga håll:

1. Röst i realtid – ljud in, översatt ljud ut medan talaren fortfarande pratar, med varje åhörare på sitt eget språk. Det hårda kravet är latens.
2. Chatttext i realtid – korta meddelanden, snabbt, med redigeringar, citat och HTML-struktur bevarade.
3. Delade anteckningar i realtid – samarbetsskrivning tecken för tecken, med en struktur (listor, rubriker, kryssrutor) som måste överleva översättningen.
4. Asynkrona dokumentfiler – en PDF på 40 sidor som läggs i chatten. Ingen latensbudget. Det hårda kravet är fidelitet – formatering, tabeller, sidnummer, typsnitt.

Man kan bygga ett enda gigantiskt LLM-anrop som försöker sköta alla fyra. Vi försökte. Det blev dåligt på alla fyra. Latensbudgeten för röst betyder att modellen inte hinner tänka. Fidelitetskravet för dokument betyder att modellen måste det. En chattredigering behöver en diff på läsarens språk, och en PDF på 40 sidor kräver en formatbevarande som ingen modell som strömmar tokens kan ge dig.

Så vi kör fyra. Här är de, ett i taget.

Flöde 1: Röstöversättning i realtid

Problemet: En deltagare talar franska. En annan har anslutit på tyska, en tredje på brasiliansk portugisiska, en fjärde på japanska. Var och en behöver höra talaren på sitt eget språk, i sitt eget öra, med en fördröjning så kort att det går att hålla ögonkontakt.

Budgeten: lyssnaren ska aldrig behöva vänta på den. När översatt tal släpar så långt efter att folk börjar prata i mun på det glider mötet mot "vi byter bara till engelska".

Hur ljudet faktiskt rör sig

Några saker som är värda att nämna uttryckligen:

• ASR körs på mediaservern. Talarens ljud färdas över WebRTC till vår egen motor – Mind API hos OVH i Frankrike – och känns igen där, på samma server som bär samtalet. Webbläsaren skickar bara ljud och tar emot orden tillbaka. Ingen separat taligenkänningsleverantör och inget extra mellansteg innan översättningen kan börja. (Röstmeddelanden i chatten är undantaget: deras tal-till-text körs på Azure AI Speech, taltjänsten i den förvalda AI-gatewayen.)
• Översättningen är inte en enda fan-out. Motorn översätter per målspråk som finns i rummet, inte per tittare: översättningen till ett språk startar när den första lyssnaren på det språket ber om en översatt ström. Tre deltagare som valt tyska delar på en tysk översättning, och om ingen lyssnar på arabiska översätts ingenting till arabiska. Därför kostar ett möte med fyra språk lika mycket som ett med fyrtio, fram till frågan om vilka som faktiskt dök upp – vi översätter aldrig till språk som ingen deltagare lyssnar på.
• Syntetiserat tal är per tittare. Varje deltagare får sitt eget översatta ljudspår, mixat mot den ursprungliga talarens video. De tittar inte på ett centralt "översatt möte" – de tittar på samma möte, med sin personliga ljudkanal översatt till det valda språket. Därför kan två personer i samma fysiska rum sätta på sig varsina hörlurar och höra olika språk.

Varför det spelar roll när ett möte spårar ur

I ett samtal på 60 minuter med åtta språk går saker sönder på intressanta sätt: WebSockets kopplas ned, ASR missar tillfälligt ett egennamn, någons nätverk blir ryckigt. Arkitekturen ovan gör att vi kan isolera felen: ljudet hos en tittare kan hacka utan att det påverkar de övriga sju, eftersom översättningsmotorn aldrig producerade "översättningen" – den producerade åtta, parallellt, och bara den drabbade behöver återhämta sig.

Själva motorn är vår egen och körs på vår egen infrastruktur. Vi skickar inte röst i realtid genom externa LLM:er för allmänt bruk. Latensbudgeten utesluter dem, och datalagringen utesluter dem för de reglerade kunder som faktiskt bryr sig.

Vad vi publicerar om rösten: /benchmark kör produktionens röstflöde mot meningar ur FLORES-200 för varje publicerat språkpar, varje månad. Bedömaren är namngiven (Gemini 3.7 Flash primärt, Claude Sonnet 5 som reserv). Hela fördelningen – median, p10, p90, min, max, urvalsstorlek – finns på sidan. I metodbeskrivningen står vad siffrorna mäter och vad de inte mäter.

Flöde 2: Chattöversättning i realtid

Problemet: Varje chattmeddelande i mötet ska översättas för varje deltagare till deras eget språk, i samma stund som det skickas. Dessutom redigeringar – och redigeringar ska se ut som redigeringar, inte som omöversättningar.

Budgeten: friare än för röst. Ett chattmeddelande kan få ta en stund på sig att dyka upp på ett annat språk utan att någon bryr sig. Det folk bryr sig om är om översättningen är rätt och om redigeringarna går att förstå.

Vad chattflödet faktiskt gör

Varje meddelande går genom samma översättningsmotor som röstflödet använder – men med annan för- och efterbearbetning:

• HTML-strukturen bevaras. Chatten stöder formaterad text (stycken, listor, citat, fet stil, kursiv). Vi konverterar till ren text åt modellen, översätter och lindar sedan in resultatet i de ursprungliga taggarna igen. Modellen ser aldrig HTML-koden – den ser ren prosa.
• Citat översätts oberoende. Om du svarar på ett meddelande och citerar det översätts blocket [QUOTE]…[/QUOTE] och det nya innehållet som separata enheter, så att modellen inte kan blanda ihop dem.
• Långa meddelanden delas upp. Vi delar vid styckegränser med 1 000 tecken per del. Varje del är ett eget översättningsanrop. Vi matar inte modellen med romaner på 4 000 tecken i ett svep – felmönstren (avkortning, borttappade stycken, avbrutna meningar) är för fula.
• Översättningen är lat. Vi använder en IntersectionObserver: ett meddelande översätts först när det rullar in i tittarens vyfönster. Att byta språk i en kanal som pågått länge brukade spela upp varje översättningsanrop ur historiken på nytt. Nu gör det inte det.

Det intressanta: redigeringar som diffar

I v1.2 ändrade vi hur chattredigeringar beter sig för tittare på ett annat språk. Förut var det så här: någon redigerar ett meddelande, vi översätter om hela texten, och du ser ett nytt stycke och får leta efter vad som flyttats.

Det nya beteendet:

1. Det ursprungliga meddelandet var redan översatt till ditt språk.
2. När avsändaren redigerar översätter vi den nya versionen.
3. Vi räknar fram diffen mellan din tidigare översättning och din nya översättning, på ditt språk.
4. Vi visar diffen inline – på samma sätt som Git visar vad som ändrats.

När "review by Tuesday" blir "review by Thursday" på engelska ser din spansktalande kollega martes → jueves markerat, inte ett omöversatt stycke som hen måste läsa om.

Det krävde att vi behandlade chattflödet som en tillståndsbärande cache per tittare, inte som en tillståndslös översättningsändpunkt som svarar på begäran. Dokument och röst behöver inte det. Chatten gör det.

Flöde 3: Översättning av delade anteckningar i realtid

Problemet: Värden öppnar en panel för delade anteckningar och börjar skriva. Varje deltagare ser anteckningarna på sitt språk, tecken för tecken, med dokumentets struktur – rubriker, nästlade listor, checklistor, kodblock – intakt.

Budgeten: Densamma som för chatten, men med två extra villkor:

• Det som översätts ändras under pågående översättning. Värden skriver fortfarande. Ett naivt system som översätter "hela dokumentet" vid varje tangenttryckning ger flimmer och bränner API-budgeten. Vi översätter på nivån den ändrade enheten, inte hela dokumentet.
• Strukturen måste överleva. Om du ber en översättningsmodell översätta en markdown-klump med tre nästlade listor får du tillbaka något som ser ut som originalet men med subtilt tillplattad hierarki, omnumrerade punkter eller flyttade indrag. Vi låter inte modellen se hela klumpen.

Hur anteckningsflödet skiljer sig från chatten

Strukturbevarandet är det viktigaste. Vi översätter varje listpunkt oberoende i stället för som ett enda dokument. Modellen ser:

"Compliance-granskning — leveranser Q2"

– inte:

"# Projektplan\n## Kvartal\n- Compliance-granskning — leveranser Q2\n- Leverantörsbedömning\n - Leverantörer nivå 1..."

Det omgivande dokumentet – <ul>, rubrikerna, indragen – byggs upp på klientsidan igen med samma struktur som originaldokumentet hade, där varje lövnod byts ut mot sin översättning. Modellen får aldrig "förbättra" hierarkin.

Anteckningar använder dessutom samma diffmodell per tittare som chattredigeringar: om värden ändrar en rad ser tittare på andra språk de ändrade orden markerade, inte ett nytt stycke.

Flöde 4: Asynkron dokumentöversättning

Problemet: Någon lägger en PDF på 40 sidor, ett Word-dokument, en PowerPoint-presentation eller ett Excel-ark i chatten. Varje deltagare kan begära en kopia på sitt eget språk. Den översatta filen måste se ut som originalet – samma typsnitt, samma tabeller, samma sidnummer, samma sidhuvuden, samma diagram på plats.

Budgeten: Inget krav på realtid. En minut går bra. Två minuter går bra. Kravet är fidelitet – om den översatta PDF:en inte ser ut som originalet litar mottagaren inte på den.

Varför det här flödet inte delar motor med rösten

En allmän LLM, hur bra den än är, ger dig tillbaka en översatt text ur ett dokument. Den ger dig inte tillbaka en översatt PDF med samma layout. Modellen har inget begrepp om en "sidbrytning som måste stämma med källan" eller en "tabellcell som måste behålla sin kolumnbredd".

För den här ytan använder vi DeepL Document API direkt. Det är byggt för att översätta filer som filer, inte prosa utdragen ur filer. DeepL hanterar:

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

Dokumentet laddas upp till DeepL:s flöde, översätts på serversidan med formateringen intakt och returneras i samma format. Därefter laddar vi upp resultatet till vår egen objektlagring och visar det i chatten som en nedladdningsbar bilaga.

Vad detta kostar och varför vi inte döljer det

DeepL fakturerar minst 50 000 tecken per dokument – ungefär en amerikansk dollar per fil på Pro-nivån, oavsett om dokumentet är en sida eller trettio. Vi tar den kostnaden själva i stället för att ta betalt per fil. Den syns i mötets översättningsanvändning som fakturerade tecken, omräknade till ordenheter som stämmer med hur resten av produkten redovisar översättningsaktivitet.

Vi valde DeepL för den här ytan eftersom att översätta filer som filer är precis det jobb det byggdes för – vi försökte inte bygga ett bättre. Omvänt gäller inte detsamma: DeepL har inget flöde för levande röst av det slag vi byggt för möten. Olika problem, olika verktyg. Den ärliga versionen av "vad driver översättningen i InterMIND" är "rätt motor per flöde" – inte "vår motor överallt".

Språk som det här flödet täcker och rösten inte gör

Dokumentflödet når 30 språk, mot 23 för röst. Till tilläggen hör: bulgariska, grekiska, estniska, indonesiska, litauiska, lettiska, slovakiska, slovenska. (Arabiska finns också på den här listan och är ett av tilläggen: det är borttaget från realtidsväljaren så länge röstkvaliteten ligger under vår nivå, och dess poäng per språkpar finns kvar offentligt på /benchmark – det är de siffrorna som för tillbaka språket. Asymmetrin går åt andra hållet för hindi – live för röst, ännu inte för filer.)

Den asymmetrin är verklig. Den betyder att en fransk deltagare i ett möte kan begära kontrakts-PDF:en på estniska trots att hen inte kan lyssna på mötet på estniska. Vi flaggar det i väljaren i stället för att släta över det med en enda siffra. Resonemanget finns i inlägget om språkantal.

Där flödena möts

De fyra flödena körs inte isolerade från varandra. Ett mötesrum är platsen där de berör varandra, och skarvarna spelar roll:

• Ett chattmeddelande med en dokumentbilaga startar chattflödet för texten och dokumentflödet för filen. Deltagaren på ett annat språk ser meddelandet översatt direkt, och bilagans översättning kommer asynkront som en nedladdningsbar fil.
• En delad anteckning som citerar en transkriptrad korsar anteckningar ↔ röst. Transkriptet är det röstflödet producerade för avsändarens språk, och anteckningsöversättningen skapar en kopia av det citatet per tittare på allas andra språk, med källhänvisningen bevarad.
• Ett transkript som exporteras efter mötet kör textflödet i chattstil över hela samtalet och ger en fil per språk som deltagarna kan ladda ned. Det är samma kodväg som chattöversättningen, bara i batch.

Språkväljaren är en enda bit gränssnitt. Infrastrukturen under den är fyra flöden som talar med varandra.

Vad vi medvetet inte försöker oss på

• Ingen "enhetlig översättningsmodell". Vi bygger inte en modell som gör röst, chatt, anteckningar och dokument. Avvägningen mellan latens och fidelitet har ingen given vinnare. Vi använder rätt motor per yta.
• Ingen tyst omdirigering. Om filflödet inte kan översätta till hindi idag faller vi inte i det tysta tillbaka på röstmotorn och låtsas att det fungerade – filväljaren flaggar luckan i stället för att dölja den.
• Inget "vi översätter till 200 språk". Vår motor ger 24. De levande ytorna levererar 23, dokument 30 – och i stället för en säljvänlig siffra publiceras kvaliteten per språkpar, den som måste stå sig inför en revisor, på /benchmark, svagare par inräknade.

Prova själv

• Prova livedemon – kör röstflödet live mot ditt ljud, på vilket som helst av de 23 produktspråken. Samma flöde som ger poängen på /benchmark.
• Se benchmarken – kvalitet per språkpar och månad på verklig trafik. Varje par i väljaren, starkt eller svagt, går att djuplänka.
• Läs metodbeskrivningen – vad siffrorna är, vad de inte är och vem bedömaren är.

Fyra flöden, fyra motorer, ett mötesrum. Det är den ärliga ersättaren till den gamla how-it-works-sidan.

— Mind.com-teamet

Källor: DeepL — supported languages, DeepL — usage count and billing (minimiavgiften på 50 000 tecken per fil), FLORES-200. Interna fakta om flödena är verifierade mot den levererade koden, kontrollerade augusti 2026.