Binnen in de vier vertaalpijplijnen van InterMIND

De oude pagina /product/overview/how-it-works op mind.com is inmiddels verscheidene grote releases achterhaald. Het beschrijft één enkele "vertaalengine" zoals de meeste leverancierspagina's dat doen — één grote pijl van "u spreekt" naar "zij horen." Dat plaatje was twee jaar geleden al een versimplificering. Vandaag de dag is het onjuist.

De waarheid is dat InterMIND vier afzonderlijke vertaalpijplijnen draait, die elk een ander probleem oplossen met een andere engine, een ander latentiebudget en een andere kwaliteitsenveloppe. Ze delen een taalkiezer. Ze delen geen engine.

Dit is het bijgewerkte antwoord op "hoe het werkt."

Een begeleidend artikel: "Hoeveel talen ondersteunen jullie?" behandelt wat elke pijplijn dekt (24 / 24 / 30 / 17). Dit bericht behandelt wat elke pijplijn doet — en waarom het zijn eigen ding is.

Waarom "één engine voor alles" een leugen is

Een live meeting-platform moet minstens vier taken tegelijkertijd uitvoeren, en die trekken in incompatibele richtingen:

1. Realtime spraak — audio in, vertaalde audio uit, onder één seconde, elke viewer in zijn eigen taal. De harde beperking is latentie.
2. Realtime chattekst — korte berichten, snel, met bewerkingen en citaten en behoud van HTML-structuur.
3. Realtime gedeelde notities — teken voor teken collaboratief typen, met een structurele hiërarchie (lijsten, kopteksten, selectievakjes) die de vertaling moet overleven.
4. Asynchrone documentbestanden — een PDF van 40 pagina's die in de chat wordt gedropt. Geen latentiebudget. De harde beperking is nauwkeurigheid — opmaak, tabellen, paginanummers, lettertype.

U kunt één gigantische LLM-call bouwen die probeert alle vier te doen. We hebben het geprobeerd. Het is slecht in alle vier. Het latentiebudget voor spraak betekent dat het model niet kan nadenken; het nauwkeurigheidsbudget voor documenten betekent dat het model moet nadenken. Een chatbewerking heeft een diff nodig in de taal van de viewer; een PDF van 40 pagina's heeft behoud van opmaak nodig dat geen enkel token-streaming model u geeft.

Dus draaien we er vier. Hier is elk ervan.

Pijplijn 1: Realtime spraakvertaling

Het probleem: Een deelnemer spreekt Frans. Een andere deelnemer is Duits meegegaan, een derde in Braziliaans-Portugees, een vierde in Japans. Elk van hen moet de spreker in hun eigen taal horen, in hun eigen oor, met een vertraging die kort genoeg is om oogcontact mogelijk te houden.

Het budget: Sub-seconde end-to-end. Alles boven ~1,2 seconde en het gesprek valt uiteen — mensen beginnen door de vertaling heen te praten, en de meeting glijdt af naar "laten we gewoon overschakelen naar Engels."

Hoe de audio daadwerkelijk beweegt

Een paar dingen die het waard zijn om expliciet te benoemen:

• ASR draait in de browser van de spreker, niet op een centrale server. We gebruiken de Mind SDK lokaal; dit bespaart een round-trip en geeft ons het transcript in de brontaal met de laagst mogelijke vertraging voordat de vertaling überhaupt kan beginnen.
• Vertaling is niet één fan-out. We behouden een pool van WebSocket-verbindingen met onze vertaalengine, één per doeltaal die in de ruimte aanwezig is. Als drie deelnemers voor Duits kozen, deelt Duits één verbinding. Als niemand voor Arabisch koos, wordt er geen Arabische verbinding geopend. De pool verbreekt inactieve verbindingen na vijf minuten. Dit is de reden waarom een meeting met vier talen evenveel kost als een meeting met veertig talen, tot het punt van wie er daadwerkelijk is komen opdagen — we vertalen nooit naar talen waarnaar geen enkele deelnemer luistert.
• Gesynthetiseerde spraak is per viewer. Elke deelnemer ontvangt zijn eigen vertaalde audiospoor, gemengd met de video van de originele spreker. Ze kijken niet naar een master "vertaalde meeting" — ze kijken naar dezelfde meeting, met hun persoonlijke audiokanaal vertaald naar hun gekozen taal. Dit is de reden waarom twee mensen in dezelfde fysieke ruimte elk een koptelefoon kunnen inpluggen en verschillende talen kunnen horen.

Waarom dit ertoe doet wanneer een meeting de verkeerde kant op gaat

In een call van 60 minuten met acht talen gaan dingen op interessante manieren stuk: WebSockets vallen uit, ASR transcribeert een eigennaam tijdelijk verkeerd, het netwerk van één deelnemer wordt jittery (schokkerig). De bovenstaande architectuur is wat ons in staat stelt storingen te isoleren: als de audio van één viewer hapert, heeft dit geen invloed op de andere zeven, omdat de vertaalengine in de eerste plaats nooit "de vertaling" produceerde — het produceerde er acht, parallel, en alleen de getroffen vertaling hoeft te herstellen.

De engine zelf is van ons, gehost op onze eigen infrastructuur. We routeren realtime spraak niet via LLM's van derden voor algemene doeleinden. Het latentiebudget sluit ze uit; het verhaal rondom dataresidency sluit ze uit voor de gereguleerde klanten wie het er daadwerkelijk om gaat.

Wat we publiceren over spraakkwaliteit: /benchmark draait de productie-spraakpijplijn tegen FLORES-200 zinnen voor elk gepubliceerd taalpaar, maandelijks. De beoordelaar wordt benoemd (Gemini 2.5 Flash primair, Claude Sonnet 4 als fallback). De volledige verdeling — mediaan, p10, p90, min, max, steekproefgrootte — staat op de pagina. Zie de methodologie voor wat die getallen wel en niet meten.

Pijplijn 2: Realtime chatvertaling

Het probleem: Elk chatbericht in de meeting, vertaald voor elke deelnemer in hun eigen taal, zoals het wordt verzonden. Plus bewerkingen — en bewerkingen moeten eruitzien als bewerkingen, niet als hervertalingen.

Het budget: Snel, maar niet sub-seconde. Een chatbericht kan een halve seconde duren om in een andere taal te verschijnen zonder dat iemand zich daar druk om maakt. Waar mensen zich druk om maken, is of de vertaling juist is en of bewerkingen logisch zijn.

Wat de chatpijplijn daadwerkelijk doet

Elk bericht gaat door dezelfde vertaalengine die de spraakpijplijn gebruikt — maar met verschillende pre- en post-processing:

• HTML-structuur blijft behouden. Chat ondersteunt rich text (alinea's, lijsten, citaten, vetgedrukt, cursief). We converteren naar platte tekst voor het model, vertalen, en verpakken het resultaat vervolgens weer in de originele tags. Het model ziet de HTML nooit — het ziet schone proza.
• Citaten worden onafhankelijk vertaald. Als u op een bericht antwoordt en het citeert, worden het [QUOTE]…[/QUOTE]-blok en de nieuwe inhoud als afzonderlijke eenheden vertaald, zodat het model de twee niet door elkaar kan halen.
• Lange berichten worden opgesplitst. We splitsen op alineagrenzen bij 1.000 tekens per chunk. Elke chunk is een eigen vertaalcall. We voeden geen romans van 4.000 tekens in één keer aan het model — de falingsmodi (afkapping, verloren alinea's, midden in een zin afgebroken) zijn te lelijk.
• Vertaling is lui. We gebruiken een IntersectionObserver: een bericht wordt pas vertaald wanneer het in de viewport van de viewer scrolt. Het wisselen van taal in een langlopend kanaal vroeg elke vertaal-API-call uit de geschiedenis opnieuw af. Dat is nu niet meer het geval.

Het interessante deel: bewerkingen als diffs

In v1.2 hebben we veranderd hoe chatbewerkingen zich gedragen voor viewers in een andere taal. Het oude gedrag was: iemand bewerkt een bericht, wij vertalen het geheel opnieuw, u ziet een verse alinea en moet ontdekken wat er veranderd is.

Het nieuwe gedrag:

1. Het originele bericht was al naar uw taal vertaald.
2. Wanneer de afzender bewerkt, vertalen we de nieuwe versie opnieuw.
3. We berekenen de diff tussen uw vorige vertaling en uw nieuwe vertaling, in uw taal.
4. We tonen die diff inline — op dezelfde manier als Git u laat zien wat er veranderd is.

Dus wanneer "review by Tuesday" in het Engels "review by Thursday" wordt, ziet uw Spaanslezende collega martes → jueves gemarkeerd, en niet een opnieuw vertaalde alinea die hij opnieuw moet lezen.

Dit vereiste het behandelen van de chatpijplijn als een stateful per-viewer cache, niet als een stateless translate-on-request endpoint. Documenten en spraak hebben dit niet nodig. Chat wel.

Pijplijn 3: Realtime vertaling van gedeelde notities

Het probleem: De host opent een paneel met gedeelde notities en begint te typen. Elke deelnemer ziet de notities in hun taal, teken voor teken, met de structuur van het document — kopteksten, geneste lijsten, controlelijsten, codeblokken — intact.

Het budget: Hetzelfde als chat (~een halve seconde), maar met twee extra beperkingen:

• Dat wat wordt vertaald, verandert tijdens de vertaling. De host is nog steeds aan het typen. Een naïef systeem dat "het hele document" vertaalt bij elke toetsaanslag produceert flikkering en verbrandt het API-budget. We vertalen op de granulariteit van de gewijzigde eenheid, niet het hele document.
• Structuur moet overleven. Als u een vertaalmodel vraagt om een markdown-blob met drie geneste lijsten te vertalen, krijgt u iets terug dat eruitziet als het origineel, maar met een subtiel afgevlakte hiërarchie, hernummerde items of verschoven inspringing. We laten het model de hele blob niet zien.

Hoe de notities-pijplijn verschilt van chat

Het behoud van structuur is het belangrijkste. We vertalen elk lijstitem onafhankelijk in plaats van als één document. Het model ziet:

"Compliance review — Q2-leveringen"

— niet:

"# Projectplan\n## Kwartaal\n- Compliance review — Q2-leveringen\n- Leveranciersbeoordeling\n - Tier 1-leveranciers..."

Het omhullende document — de <ul>, de kopteksten, de inspringing — wordt aan de clientzijde herbouwd met dezelfde structuur als het originele document, waarbij elk leaf-node is vervangen door zijn vertaling. Het model krijgt nooit de kans om de hiërarchie te "verbeteren".

Notities gebruiken ook hetzelfde per-viewer diff-model als chatbewerkingen: als de host een regel wijzigt, zien viewers in andere talen de gewijzigde woorden gemarkeerd, en niet een verse alinea.

Pijplijn 4: Asynchrone documentvertaling

Het probleem: Iemand dropt een PDF van 40 pagina's, een Word-document, een PowerPoint-presentatie of een Excel-spreadsheet in de chat. Elke deelnemer kan een kopie in zijn eigen taal aanvragen. Het vertaalde bestand moet eruitzien als het origineel — dezelfde lettertypes, dezelfde tabellen, dezelfde paginanummers, dezelfde kopteksten, dezelfde grafieken op hun plek.

Het budget: Geen realtime-beperking. Een minuut is prima. Twee minuten is prima. De beperking is nauwkeurigheid — als de vertaalde PDF er niet uitziet als het origineel, zal de ontvanger het niet vertrouwen.

Waarom deze pijplijn geen engine deelt met spraak

Een algemene LLM, zelfs een hele goede, zal u een vertaalde tekst van een document teruggeven. Het zal u geen vertaalde PDF met dezelfde lay-out teruggeven. Het model heeft geen concept van "paginabreuk die moet aansluiten op de bron" of "tabelcel die zijn kolombreedte moet behouden."

Voor dit oppervlak gebruiken we direct de DeepL Document API. Deze is speciaal gebouwd voor het vertalen van bestanden als bestanden, niet proza geëxtraheerd uit bestanden. DeepL verwerkt:

• PDF (met behoud van lay-out)
• DOCX, DOC
• PPTX
• XLSX

Het document wordt geüpload naar de pijplijn van DeepL, server-side vertaald met intacte opmaak, en teruggegeven in hetzelfde formaat. We uploaden het resultaat vervolgens naar onze objectopslag en bieden het in de chat aan als downloadbare bijlage.

Wat dit kost en waarom we het niet verbergen

DeepL factureert een minimum van 50.000 tekens per document — ruwweg één Amerikaanse dollar per bestand op de Pro-tier, ongeacht of het document één pagina of dertig pagina's lang is. We nemen die kosten voor onze rekening in plaats van per bestand in rekening te brengen; het verschijnt in het vertaalgebruik van de meeting als gefactureerde tekens, geconverteerd naar woordeenheden die overeenkomen met de manier waarop de rest van het product vertaalactiviteit rapporteert.

We hebben DeepL gekozen voor dit oppervlak omdat het vertalen van bestanden als bestanden precies de taak is waarvoor het is gebouwd — we hebben niet geprobeerd een betere te bouwen. Hetzelfde geldt niet andersom — DeepL draait geen live-spraakpijplijn van het soort dat we voor meetings hebben gebouwd. Verschillende problemen; verschillende gereedschappen. De eerlijke versie van "wat de InterMIND-vertaling aandrijft" is "de juiste engine per pijplijn" — niet "onze engine, overal."

Talen die deze pijplijn dekt, maar spraak niet

De documentpijplijn bereikt 30 talen, tegenover 24 voor spraak. De extra's zijn onder meer: Bulgaars, Grieks, Ests, Indonesiaans, Litouws, Lets, Slowaaks, Sloveens. (Arabisch stond vroeger in deze lijst terwijl de spraakkwaliteit onder onze lat was; het staat nu in de realtime-kiezer, met de scores per paar openbaar op /benchmark zoals elke andere taal. De asymmetrie loopt nu andersom voor Hindi — live op spraak, nog niet op bestanden.)

Die asymmetrie is reëel. Het betekent dat een Franse deelnemer in een meeting de contract-PDF in het Ests kan aanvragen, ook al kunnen ze niet naar de meeting in het Ests luisteren. We markeren dit in de kiezer in plaats van het glad te strijken met één getal. De redenatie staat in het artikel over het aantal talen.

Waar de pijplijnen elkaar raken

De vier pijplijnen draaien niet geïsoleerd. Een meetingruimte is de plek waar ze elkaar raken, en de naden doen ertoe:

• Een chatbericht met een documentbijlage activeert de chatpijplijn voor de tekst en de documentpijplijn voor het bestand. De deelnemer in een andere taal ziet het bericht onmiddellijk vertaald en de vertaling van de bijlage asynchroon aankomen als downloadbaar bestand.
• Een gedeelde notitie die een regel uit het transcript citeert kruist notities ↔ spraak. Het transcript is wat de spraakpijplijn heeft geproduceerd voor de taal van de afzender; de notitievertaling produceert een per-viewer kopie van dat citaat in de taal van iedereen anders, met behoud van de bronvermelding.
• Een transcript dat na de meeting wordt geëxporteerd draait de tekstpijplijn in chat-stijl over het volledige gesprek, en produceert een bestand per taal dat deelnemers kunnen downloaden. Dit is hetzelfde codepad als chatvertaling, alleen gebatched.

De taalkiezer is één stukje UI. De onderliggende infrastructuur bestaat uit vier pijplijnen, die met elkaar communiceren.

Wat we opzettelijk niet proberen

• Geen "uniform vertaalmodel". We bouwen geen één model dat spraak, chat, notities en documenten kan doen. De trade-off tussen latentie en nauwkeurigheid kent geen winnaar. We gebruiken de juiste engine per oppervlak.
• Geen stille herverwijzing. Als de bestandspijplijn vandaag niet naar het Hindi kan vertalen, vallen we niet stilletjes terug op de spraakengine en doen alsof het werkte — de bestandskiezer markeert het gat in plaats van het te verbergen.
• Geen "wij vertalen naar 200 talen". Onze engine zendt 24 uit. De live-oppervlakken leveren alle 24, documenten 30 — en in plaats van één marketingvriendelijk getal, wordt de kwaliteit per paar die voor een auditor moet kunnen staan, gepubliceerd op /benchmark, zwakkere paren inbegrepen.

Probeer het zelf

• Probeer de live demo — draait de live-spraakpijplijn tegen uw audio, in elk van de 24 producttalen. Dezelfde pijplijn die /benchmark scoort.
• Bekijk de benchmark — kwaliteit per paar, per maand op echt verkeer. Elk paar in de kiezer, sterk of zwak, deep-linkable.
• Lees de methodologie — wat de getallen zijn, wat ze niet zijn, wie de beoordelaar is.

Vier pijplijnen, vier engines, één meetingruimte. Dat is de eerlijke vervanging voor de oude how-it-works-pagina.

— Het Mind.com-team

Bronnen: DeepL — ondersteunde talen, DeepL — gebruik en facturering (de 50.000-tekens per bestand minimum), FLORES-200; interne pijplijnfeiten geverifieerd tegen de verzonden code, gecontroleerd augustus 2026.