Binnen de vier vertaalpijplijnen die InterMIND draaien

De oude /product/overview/how-it-works-pagina op mind.com is achterhaald door meerdere grote releases. Het beschrijft een enkele "vertaalengine" op de manier waarop de meeste leveranciers dat doen — één grote pijl van "jij spreekt" naar "zij horen." Dat beeld was twee jaar geleden al een simplificatie. 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 latency-budget en een andere kwaliteitsenvelop. 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 dekkt (23 / 23 / 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 vergaderplatform heeft minstens vier taken tegelijk, en deze trekken in incompatibele richtingen:

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

Je kunt één gigantische LLM-aanroep bouwen die alle vier probeert te doen. We hebben het geprobeerd. Het is slecht in alle vier. Het latency-budget voor spraak betekent dat het model niet kan nadenken; het getrouwheidsbudget voor documenten betekent dat het model moet nadenken. Een chatbewerking heeft een diff nodig in de taal van de kijker; een 40-pagina's tellende PDF heeft opmaakbehoud nodig dat geen token-streaming model je geeft.

Dus we draaien er vier. Hier is elk ervan.

Pijplijn 1: Realtime spraakvertaling

Het probleem: Een deelnemer spreekt Frans. Een andere deelnemer is in het Duits aangesloten, 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 kort genoeg om oogcontact mogelijk te houden.

Het budget: Sub-seconde end-to-end. Alles boven ~1,2 seconden en het gesprek breekt — mensen beginnen door de vertaling heen te praten, en de vergadering drijft naar "laten we gewoon overschakelen naar het Engels."

Hoe de audio daadwerkelijk reist

Een paar dingen die het expliciet benoemen waard zijn:

• ASR draait op de mediaserver. De audio van de spreker reist via WebRTC naar onze eigen engine — de Mind API op OVH, Frankrijk — en wordt daar herkend, op dezelfde server die de verbinding afhandelt; de browser stuurt alleen audio en ontvangt de woorden terug. Geen aparte spraakleverancier en geen extra hop voordat de vertaling kan beginnen. (Chat-spraakberichten zijn de uitzondering: hun spraak-naar-tekst draait op Azure AI Speech, de spraakservice van de standaard AI-gateway.)
• Vertaling is niet één fan-out. De engine vertaalt per doeltaal dat in de ruimte aanwezig is, niet per kijker: vertaling naar een taal begint wanneer de eerste luisteraar erom vraagt, drie deelnemers die voor Duits hebben gekozen delen één Duitse vertaling, en niemand die in het Arabisch luistert betekent dat er niets naar het Arabisch wordt vertaald. Dit is waarom een vergadering met vier talen evenveel kost als een vergadering met veertig talen, tot het punt van wie er daadwerkelijk is verschenen — we vertalen nooit naar talen waarin geen deelnemer luistert.
• Gesynthetiseerde spraak is per kijker. Elke deelnemer ontvangt zijn eigen vertaalde audiotrack, gemixt tegen de video van de originele spreker. Ze kijken niet naar een master "vertaalde vergadering" — ze kijken naar dezelfde vergadering, met hun persoonlijke audiokanaal vertaald naar hun gekozen taal. Dit is waarom twee mensen in dezelfde fysieke ruimte elk een koptelefoon in kunnen pluggen en verschillende talen kunnen horen.

Waarom dit uitmaakt als een vergadering misgaat

In een vergadering van 60 minuten met acht talen, breken dingen op interessante manieren: WebSockets vallen weg, ASR transcribeert tijdelijk een eigennaam verkeerd, het netwerk van één deelnemer wordt instabiel (jitter). De bovenstaande architectuur is wat ons in staat stelt om storingen te isoleren: een haperende audio van de ene kijker beïnvloedt de andere zeven niet, omdat de vertaalengine in de eerste plaats nooit "de vertaling" produceerde — het produceerde er acht, parallel, en alleen de getroffen hoeft te herstellen.

De engine zelf is van ons, gehost op onze eigen infrastructuur. We routeren geen realtime spraak via third-party algemene LLM's. Het latency-budget sluit ze uit; het verhaal rond dataresidentie sluit ze uit voor de gereguleerde klanten die er daadwerkelijk om geven.

Wat we publiceren over spraakkwaliteit: /benchmark draait de productiespraakpijplijn tegen FLORES-200 zinnen voor elk gepubliceerd taalpaar, maandelijks. De beoordelaar is bekend (Gemini 3.7 Flash primair, Claude Sonnet 5 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 vergadering, 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 andere pre- en post-processing:

• HTML-structuur wordt behouden. Chat ondersteunt rich text (alinea's, lijsten, citaten, vetgedrukt, cursief). We converteren naar platte tekst voor het model, vertalen, en wikkelen het resultaat vervolgens weer in de originele tags. Het model ziet de HTML nooit — het ziet schone proza.
• Citaten worden onafhankelijk vertaald. Als je 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 gechunked. We splitsen op alineagrenzen op 1.000 tekens per chunk. Elke chunk is een eigen vertaalaanroep. We voeden geen romans van 4.000 tekens in één keer aan het model — de falingsmodi (truncatie, verloren alinea's, afbrekingen midden in een zin) zijn te lelijk.
• Vertaling is lui. We gebruiken een IntersectionObserver: een bericht wordt pas vertaald wanneer het in de viewport van de kijker scrolt. Het wisselen van taal in een langlopend kanaal speelde vroeger elke vertaal-API-aanroep uit de geschiedenis opnieuw af. Dat doet het nu niet meer.

Het interessante deel: bewerkingen als diffs

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

Het nieuwe gedrag:

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

Dus wanneer "review by Tuesday" "review by Thursday" wordt in het Engels, ziet jouw Spaans lezende 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-kijker 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 — koppen, geneste lijsten, checklisten, codeblokken — intact.

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

• Het ding dat wordt vertaald, verandert midden in de vertaling. De host is nog aan het typen. Een naief systeem dat "het hele document" bij elke toetsaanslag vertaalt, produceert flikkering en verbrandt het API-budget. We vertalen op de granulariteit van de gewijzigde eenheid, niet het hele document.
• Structuur moet overleven. Als je een vertaalmodel vraagt om een markdown-blob met drie geneste lijsten te vertalen, krijg je iets terug dat er uitziet 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 de structuur is het belangrijkste. We vertalen elk lijstitem onafhankelijk in plaats van als één document. Het model ziet:

"Compliance review — Q2 deliverables"

— niet:

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

Het omhullende document — de <ul>, de koppen, 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-kijker diff-model als chatbewerkingen: als de host een regel wijzigt, zien kijkers in andere talen de gewijzigde woorden gemarkeerd, en geen verse alinea.

Pijplijn 4: Asynchrone documentvertaling

Het probleem: Iemand dropt een 40-pagina's tellende PDF, een Word-doc, een PowerPoint-deck, of een Excel-sheet in de chat. Elke deelnemer kan een kopie in zijn eigen taal aanvragen. Het vertaalde bestand moet eruitzien als het origineel — dezelfde lettertypen, 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 getrouwheid — 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 je een vertaalde tekst van een document teruggeven. Het zal je geen vertaalde PDF met dezelfde lay-out teruggeven. Het model heeft geen concept van "pagina-einde dat moet aansluiten op de bron" of "tabelcel die zijn kolombreedte moet behouden."

Voor dit oppervlak gebruiken we direct de DeepL Document API. Het is specifiek gebouwd voor het vertalen van bestanden als bestanden, niet proza geëxtraheerd uit bestanden. DeepL handelt af:

• PDF (met lay-outbehoud)
• 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 tonen het terug in de chat als een downloadbare bijlage.

Wat dit kost en waarom we het niet verbergen

DeepL brengt een minimum van 50.000 tekens per document in rekening — ongeveer één Amerikaanse dollar per bestand op de Pro-tier, ongeacht of het document één pagina of dertig pagina's bevat. We nemen die kosten voor onze rekening in plaats van per bestand in rekening te brengen; het verschijnt in de vertaalgebruik van de vergadering als gefactureerde tekens, geconverteerd naar woord-eenheden 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 vergaderingen hebben gebouwd. Verschillende problemen; verschillende tools. 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 23 voor spraak. De extra's zijn onder andere: Bulgaars, Grieks, Ests, Indonesisch, Litouws, Lets, Slowaaks, Sloveens. (Arabisch staat ook op deze lijst, en het is een van de extra's: het is teruggetrokken uit de realtime-kiezer terwijl de spraakkwaliteit onder onze maatstaf ligt, en de scores per paar blijven openbaar op /benchmark — dat getal is wat het terugbrengt. De asymmetrie loopt andersom voor Hindi — live op spraak, nog niet op bestanden.)

Die asymmetrie is echt. Het betekent dat een Franse deelnemer in een vergadering de contract-PDF in het Ests kan aanvragen, zelfs als ze niet naar de vergadering in het Ests kunnen luisteren. We markeren het in de kiezer in plaats van het glad te strijken met één getal. De reden staat in het bericht over het aantal talen.

Waar de pijplijnen samenkomen

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

• Een chatbericht met een documentbijlage triggert 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 arriveren als downloadbaar bestand.
• Een gedeelde notitie die een transcriptieregel citeert kruist notities ↔ spraak. Het transcript is wat de spraakpijplijn produceerde voor de taal van de afzender; de notitievertaling produceert een per-kijker kopie van dat citaat in de taal van ieder ander, met de bronvermelding behouden.
• Een transcript dat na de vergadering wordt geëxporteerd draait de tekstpijplijn in chatstijl over het volledige gesprek, en produceert een per-taal bestand dat deelnemers kunnen downloaden. Dit is hetzelfde codepad als chatvertaling, alleen in batches verwerkt.

De taalkiezer is één stukje UI. De infrastructuur eronder is vier pijplijnen, die met elkaar praten.

Wat we opzettelijk niet proberen

• Geen "uniform vertaalmodel". We bouwen geen één model dat spraak, chat, notities en documenten doet. De latency vs. getrouwheid trade-off heeft geen winnaar. We gebruiken de juiste engine per oppervlak.
• Geen stille her-routering. 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 de kloof in plaats van deze te verbergen.
• Geen "we vertalen naar 200 talen." Onze engine zendt 24 uit. De live oppervlakken leveren 23, documenten 30 — en in plaats van één marketingvriendelijk getal, wordt de per-paar kwaliteit die voor een auditor moet staan, gepubliceerd op /benchmark, zwakkere paren inbegrepen.

Probeer het zelf

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

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

— Het Mind.com Team

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