Dentro le quattro pipeline di traduzione che alimentano InterMIND

La vecchia pagina /product/overview/how-it-works su mind.com è rimasta indietro di diverse versioni principali. Descrive un unico "motore di traduzione" come fanno le pagine della maggior parte dei fornitori — una grande freccia da "tu parli" a "loro ascoltano". Quell'immagine era già una semplificazione due anni fa. Oggi è sbagliata.

La verità è che InterMIND utilizza quattro pipeline di traduzione separate, ciascuna delle quali risolve un problema diverso con un motore diverso, un budget di latenza diverso e un livello di qualità diverso. Condividono un selettore di lingua. Non condividono un motore.

Questa è la risposta aggiornata a "come funziona".

Un articolo complementare: "Quante lingue supportate?" illustra ciò che ogni pipeline copre (23 / 23 / 30 / 17). Questo post illustra cosa fa ogni pipeline — e perché è unica.

Perché "un unico motore per tutto" è una bugia

Una piattaforma di riunioni in diretta ha almeno quattro compiti da svolgere contemporaneamente, e questi vanno in direzioni incompatibili:

1. Voce in tempo reale — audio in ingresso, audio tradotto in uscita, in meno di un secondo, ogni partecipante nella propria lingua. Il vincolo rigoroso è la latenza.
2. Testo della chat in tempo reale — messaggi brevi, veloci, con modifiche, citazioni e struttura HTML preservata.
3. Note condivise in tempo reale — digitazione collaborativa carattere per carattere, con gerarchia strutturale (elenchi, intestazioni, caselle di controllo) che deve sopravvivere alla traduzione.
4. File di documenti asincroni — un PDF di 40 pagine rilasciato in chat. Nessun budget di latenza. Il vincolo rigoroso è la fedeltà — formattazione, tabelle, numeri di pagina, caratteri.

Puoi creare un'unica gigantesca chiamata LLM che cerca di fare tutte e quattro le cose. Ci abbiamo provato. È scarso in tutte e quattro. Il budget di latenza per la voce significa che il modello non può pensare; il budget di fedeltà per i documenti significa che il modello deve farlo. Una modifica in chat necessita di un diff nella lingua del partecipante; un PDF di 40 pagine richiede la preservazione del formato che nessun modello di token-streaming ti offre.

Quindi ne utilizziamo quattro. Ecco ciascuna di esse.

Pipeline 1: Traduzione vocale in tempo reale

Il problema: Un partecipante parla francese. Un altro partecipante si è unito in tedesco, un terzo in portoghese brasiliano, un quarto in giapponese. Ciascuno di loro deve ascoltare l'oratore nella propria lingua, nelle proprie cuffie, con un ritardo sufficientemente breve da mantenere possibile il contatto visivo.

Il budget: Inferiore al secondo end-to-end. Oltre ~1,2 secondi la conversazione si interrompe — le persone iniziano a parlare sopra la traduzione, e la riunione scivola verso "passiamo direttamente all'inglese".

Come si muove effettivamente l'audio

Alcune cose vale la pena nominare esplicitamente:

• L'ASR viene eseguito sul media server. L'audio dell'oratore viaggia tramite WebRTC verso il nostro motore — la Mind API su OVH, Francia — e viene riconosciuto lì, sullo stesso server che gestisce la chiamata; il browser si limita a inviare l'audio e a ricevere le parole. Nessun fornitore di riconoscimento vocale separato e nessun hop aggiuntivo prima che la traduzione possa iniziare. (Le note vocali in chat sono l'eccezione: il loro speech-to-text viene eseguito su Azure AI Speech, il servizio vocale del gateway AI predefinito.)
• La traduzione non è un singolo fan-out. Il motore traduce per lingua di destinazione presente nella stanza, non per partecipante: la traduzione in una lingua inizia quando il primo ascoltatore la richiede, tre partecipanti che hanno scelto il tedesco condividono una traduzione in tedesco, e se nessuno ascolta in arabo significa che non viene tradotto nulla in arabo. Ecco perché una riunione in quattro lingue costa come una riunione in quaranta lingue, fino al limite di chi è effettivamente presente — non traduciamo mai in lingue in cui nessun partecipante sta ascoltando.
• La sintesi vocale è per partecipante. Ogni partecipante riceve la propria traccia audio tradotta, miscelata con il video originale dell'oratore. Non stanno guardando una "riunione tradotta" master — stanno guardando la stessa riunione, con il proprio canale audio personale tradotto nella lingua scelta. Ecco perché due persone nella stessa stanza fisica possono indossare le cuffie e ascoltare lingue diverse.

Perché questo è importante quando una riunione subisce imprevisti

In una chiamata di 60 minuti con otto lingue, le cose si rompono in modi interessanti: i WebSocket si interrompono, l'ASR trascrive temporaneamente in modo errato un nome proprio, la rete di un partecipante diventa instabile. L'architettura descritta sopra è ciò che ci permette di isolare i guasti: un problema audio di un partecipante non influisce sugli altri sette, perché il motore di traduzione non ha mai prodotto "la traduzione" in primo luogo — ne ha prodotte otto, in parallelo, e solo quella interessata deve riprendersi.

Il motore è nostro, ospitato sulla nostra infrastruttura. Non instradiamo la voce in tempo reale attraverso LLM general-purpose di terze parti. Il budget di latenza li esclude; le esigenze di residenza dei dati li escludono per i clienti regolamentati a cui importa davvero.

Cosa pubblichiamo sulla qualità vocale: /benchmark esegue la pipeline vocale di produzione sulle frasi FLORES-200 per ogni coppia di lingue pubblicata, mensilmente. Il valutatore è nominato (Gemini 3.7 Flash primario, Claude Sonnet 5 fallback). La distribuzione completa — mediana, p10, p90, min, max, dimensione del campione — è sulla pagina. Consulta la metodologia per ciò che questi numeri misurano e non misurano.

Pipeline 2: Traduzione chat in tempo reale

Il problema: Ogni messaggio di chat nella riunione, tradotto per ogni partecipante nella propria lingua, non appena viene inviato. Più le modifiche — e le modifiche devono sembrare modifiche, non ritraduzioni.

Il budget: Veloce, ma non sub-secondo. Un messaggio di chat può impiegare mezzo secondo per apparire in un'altra lingua senza che nessuno ci faccia caso. Ciò a cui le persone tengono è se la traduzione è corretta e se le modifiche hanno senso.

Cosa fa effettivamente la pipeline della chat

Ogni messaggio passa attraverso lo stesso motore di traduzione utilizzato dalla pipeline vocale — ma con pre- e post-elaborazione diverse:

• La struttura HTML viene preservata. La chat supporta il testo formattato (paragrafi, elenchi, citazioni, grassetto, corsivo). Convertiamo in testo semplice per il modello, traduciamo, poi re-inseriamo il risultato nei tag originali. Il modello non vede mai l'HTML — vede prosa pulita.
• Le citazioni vengono tradotte indipendentemente. Se rispondi a un messaggio e lo citi, il blocco [QUOTE]…[/QUOTE] e il nuovo contenuto vengono tradotti come unità separate, in modo che il modello non possa confonderli.
• I messaggi lunghi vengono suddivisi. Dividiamo sui confini dei paragrafi a 1.000 caratteri per blocco. Ogni blocco è una chiamata di traduzione a sé stante. Non passiamo romanzi di 4.000 caratteri al modello in un colpo solo — le modalità di fallimento (troncamento, paragrafi persi, tagli a metà frase) sono troppo brutte.
• La traduzione è pigra. Utilizziamo un IntersectionObserver: un messaggio viene tradotto solo quando scorre nel viewport del partecipante. Cambiare lingua in un canale di lunga durata richiedeva di ripetere ogni chiamata API di traduzione dalla cronologia. Ora non più.

La parte interessante: le modifiche come diff

Nella v1.2 abbiamo cambiato il comportamento delle modifiche in chat per i partecipanti in un'altra lingua. Il vecchio comportamento era: qualcuno modifica un messaggio, noi lo ritraduciamo tutto, tu vedi un nuovo paragrafo e devi individuare cosa si è mosso.

Il nuovo comportamento:

1. Il messaggio originale era già stato tradotto nella tua lingua.
2. Quando il mittente modifica, ritraduciamo la nuova versione.
3. Calcoliamo il diff tra la tua traduzione precedente e la tua nuova traduzione, nella tua lingua.
4. Mostriamo quel diff in linea — allo stesso modo in cui Git ti mostra cosa è cambiato.

Quindi quando "review by Tuesday" diventa "review by Thursday" in inglese, il tuo collega che legge in spagnolo vede martes → jueves evidenziato, non un paragrafo ritradotto che deve rileggere.

Questo ha richiesto di trattare la pipeline della chat come una cache stateful per partecipante, non un endpoint stateless di traduzione su richiesta. Documenti e voce non ne hanno bisogno. La chat sì.

Pipeline 3: Traduzione delle note condivise in tempo reale

Il problema: L'host apre un pannello di note condivise e inizia a digitare. Ogni partecipante vede le note nella propria lingua, carattere per carattere, con la struttura del documento — intestazioni, elenchi nidificati, checklist, blocchi di codice — intatta.

Il budget: Come per la chat (~mezzo secondo), ma con due vincoli extra:

• L'oggetto della traduzione cambia a metà della traduzione. L'host sta ancora digitando. Un sistema ingenuo che traduce "l'intero documento" a ogni battitura produce sfarfallio e brucia il budget dell'API. Traduciamo alla granularità dell'unità modificata, non dell'intero documento.
• La struttura deve sopravvivere. Se chiedi a un modello di traduzione di tradurre un blob markdown con tre elenchi nidificati, ottieni qualcosa che sembra l'originale ma con una gerarchia sottilmente appiattita, elementi rinumerati o indentazione spostata. Non permettiamo al modello di vedere l'intero blob.

Come differisce la pipeline delle note dalla chat

La preservazione strutturale è la cosa principale. Traduciamo ogni elemento dell'elenco indipendentemente anziché come un unico documento. Il modello vede:

"Revisione della conformità — deliverable Q2"

— non:

"# Project plan\n## Quarter\n- Revisione della conformità — deliverable Q2\n- Valutazione dei fornitori\n - Fornitori Tier 1..."

Il documento contenitore — gli <ul>, le intestazioni, l'indentazione — viene ricostruito lato client utilizzando la stessa struttura del documento originale, con ogni nodo foglia sostituito dalla sua traduzione. Il modello non ha mai la possibilità di "migliorare" la gerarchia.

Le note utilizzano anche lo stesso modello di diff per partecipante delle modifiche in chat: se l'host cambia una riga, i partecipanti in altre lingue vedono le parole modificate evidenziate, non un nuovo paragrafo.

Pipeline 4: Traduzione asincrona dei documenti

Il problema: Qualcuno rilascia un PDF di 40 pagine, un documento Word, una presentazione PowerPoint o un foglio Excel in chat. Ogni partecipante può richiedere una copia nella propria lingua. Il file tradotto deve sembrare come l'originale — stessi caratteri, stesse tabelle, stessi numeri di pagina, stesse intestazioni, stessi grafici al loro posto.

Il budget: Nessun vincolo di tempo reale. Un minuto va bene. Due minuti vanno bene. Il vincolo è la fedeltà — se il PDF tradotto non sembra l'originale, il destinatario non si fiderà.

Perché questa pipeline non condivide un motore con la voce

Un LLM generico, anche uno molto valido, ti restituirà un testo tradotto di un documento. Non ti restituirà un PDF tradotto con lo stesso layout. Il modello non ha alcun concetto di "interruzione di pagina che deve allinearsi con la sorgente" o di "cella di tabella che deve mantenere la larghezza della colonna."

Per questa superficie utilizziamo direttamente la DeepL Document API. È creata appositamente per tradurre file come file, non prosa estratta dai file. DeepL gestisce:

• PDF (con preservazione del layout)
• DOCX, DOC
• PPTX
• XLSX

Il documento viene caricato nella pipeline di DeepL, tradotto lato server con la formattazione intatta e restituito nello stesso formato. Carichiamo quindi il risultato nel nostro object storage e lo mostriamo nuovamente in chat come allegato scaricabile.

Quanto costa e perché non lo nascondiamo

DeepL fattura un minimo di 50.000 caratteri per documento — circa un dollaro USA per file sul piano Pro, indipendentemente dal fatto che il documento sia di una pagina o di trenta. Assorbiamo questo costo invece di far pagare ogni file; appare nell'utilizzo della traduzione della riunione come caratteri fatturati, convertiti in unità di parole che corrispondono al modo in cui il resto del prodotto riporta l'attività di traduzione.

Abbiamo scelto DeepL per questa superficie perché tradurre file come file è esattamente il lavoro per cui è stato creato — non abbiamo cercato di costruirne uno migliore. Non vale il contrario — DeepL non gestisce una pipeline vocale in diretta del tipo che abbiamo costruito noi per le riunioni. Problemi diversi; strumenti diversi. La versione onesta di "cosa alimenta la traduzione di InterMIND" è "il motore giusto per ogni pipeline" — non "il nostro motore, ovunque."

Lingue coperte da questa pipeline che la voce non copre

La pipeline dei documenti raggiunge 30 lingue, contro 23 per la voce. Le lingue in più includono: bulgaro, greco, estone, indonesiano, lituano, lettone, slovacco, sloveno. (L'arabo è anch'esso in questo elenco, ed è una delle lingue in più: è ritirato dal selettore in tempo reale mentre la sua qualità vocale è al di sotto del nostro standard, e i suoi punteggi per coppia rimangono pubblici su /benchmark — quel numero è ciò che lo riporterà indietro. L'asimmetria va nell'altra direzione per l'hindi — in diretta sulla voce, non ancora sui file.)

Questa asimmetria è reale. Significa che un partecipante francese in una riunione può richiedere il PDF del contratto in estone anche se non può ascoltare la riunione in estone. Lo segnaliamo nel selettore piuttosto che appianarlo con un unico numero. Il ragionamento è nel post sul conteggio delle lingue.

Dove le pipeline si incontrano

Le quattro pipeline non funzionano in isolamento. Una sala riunioni è dove si toccano a vicenda, e le cuciture contano:

• Un messaggio di chat con un allegato attiva la pipeline della chat per il testo e la pipeline dei documenti per il file. Il partecipante in un'altra lingua vede il messaggio tradotto immediatamente e la traduzione dell'allegato arrivare in modo asincrono come file scaricabile.
• Una nota condivisa che cita una riga della trascrizione incrocia note ↔ voce. La trascrizione è ciò che la pipeline vocale ha prodotto per la lingua del mittente; la traduzione della nota produce una copia per partecipante di quella citazione nella lingua di tutti gli altri, con l'attribuzione della sorgente preservata.
• Una trascrizione esportata dopo la riunione esegue la pipeline di testo in stile chat sull'intera conversazione, producendo un file per lingua che i partecipanti possono scaricare. Questo è lo stesso percorso di codice della traduzione della chat, solo in batch.

Il selettore della lingua è un unico elemento dell'interfaccia. L'infrastruttura sottostante è costituita da quattro pipeline, che comunicano tra loro.

Cosa non proviamo deliberatamente a fare

• Nessun "modello di traduzione unificato". Non stiamo costruendo un unico modello che fa voce, chat, note e documenti. Il compromesso tra latenza e fedeltà non ha un vincitore. Utilizziamo il motore giusto per ogni superficie.
• Nessun re-indirizzamento silenzioso. Se oggi la pipeline dei file non può tradurre in hindi, non ripieghiamo silenziosamente sul motore vocale fingendo che abbia funzionato — il selettore dei file evidenzia il divario invece di nasconderlo.
• Nessun "traduciamo in 200 lingue". Il nostro motore ne emette 24. Le superfici in diretta ne offrono 23, i documenti 30 — e invece di un unico numero adatto al marketing, la qualità per coppia che deve presentarsi davanti a un revisore è pubblicata su /benchmark, coppie più deboli incluse.

Provalo tu stesso

• Prova la demo dal vivo — esegue la pipeline vocale dal vivo sul tuo audio, in una qualsiasi delle 23 lingue del prodotto. La stessa pipeline che ottiene i punteggi su /benchmark.
• Consulta il benchmark — qualità per coppia, per mese su traffico reale. Ogni coppia nel selettore, forte o debole, con link diretto.
• Leggi la metodologia — cosa sono i numeri, cosa non sono, chi è il valutatore.

Quattro pipeline, quattro motori, una sala riunioni. Questa è la sostituzione onesta della vecchia pagina how-it-works.

— Il team di Mind.com

Fonti: DeepL — lingue supportate, DeepL — conteggio utilizzi e fatturazione (il minimo di 50.000 caratteri per file), FLORES-200; informazioni interne sulle pipeline verificate rispetto al codice rilasciato, verificato ad agosto 2026.