Dentro le quattro pipeline di traduzione che fanno funzionare InterMIND

La vecchia pagina /product/overview/how-it-works su mind.com è indietro di diverse release maggiori. Descrive un unico «motore di traduzione», come fanno la maggior parte delle pagine dei fornitori: un'unica grande freccia da «tu parli» a «loro sentono». Già due anni fa era una semplificazione. Oggi è sbagliata.

In realtà InterMIND esegue quattro pipeline di traduzione separate. Ognuna risolve un problema diverso, con un motore diverso, un budget di latenza diverso e un livello di qualità diverso. Condividono un selettore della lingua. Non condividono un motore.

Questa è la risposta aggiornata alla domanda «come funziona».

Un articolo di accompagnamento: «Quante lingue supportate?» spiega che cosa copre ciascuna pipeline (23 / 23 / 30 / 17). Questo articolo spiega che cosa fa ciascuna pipeline e perché è una cosa a sé.

Perché «un solo motore per tutto» è una bugia

Una piattaforma per riunioni dal vivo ha almeno quattro compiti da svolgere contemporaneamente, e tirano in direzioni incompatibili:

1. Voce in tempo reale: audio in ingresso, audio tradotto in uscita mentre chi parla sta ancora parlando, con ogni partecipante nella propria lingua. Il vincolo più duro è la latenza.
2. Testo della chat in tempo reale: messaggi brevi e veloci, con modifiche, citazioni e struttura HTML preservate.
3. Note condivise in tempo reale: scrittura collaborativa carattere per carattere, con una gerarchia strutturale (elenchi, titoli, caselle di controllo) che deve sopravvivere alla traduzione.
4. File di documenti asincroni: un PDF di 40 pagine caricato in chat. Nessun budget di latenza. Il vincolo più duro è la fedeltà: formattazione, tabelle, numeri di pagina, caratteri.

Si può costruire un'unica gigantesca chiamata a un LLM che prova a fare tutte e quattro le cose. Ci abbiamo provato. Va male su tutte e quattro. Il budget di latenza della voce impone che il modello non possa «pensare»; il budget di fedeltà dei documenti impone che debba farlo. Una modifica in chat richiede un diff nella lingua di chi legge; un PDF di 40 pagine richiede una preservazione del formato che nessun modello in streaming di token è in grado di dare.

Quindi ne eseguiamo quattro. Ecco ciascuna.

Pipeline 1: traduzione vocale in tempo reale

Il problema: un partecipante parla francese. Un altro è entrato in tedesco, un terzo in portoghese brasiliano, un quarto in giapponese. Ognuno deve sentire chi parla nella propria lingua, nel proprio orecchio, con un ritardo abbastanza breve da permettere ancora il contatto visivo.

Il budget: chi ascolta non deve mai doverlo aspettare. Quando il parlato tradotto accumula un ritardo tale che le persone iniziano a parlarci sopra, la riunione scivola verso «passiamo all'inglese e basta».

Come si muove davvero l'audio

Alcune cose vale la pena nominarle esplicitamente:

• L'ASR gira sul media server. L'audio di chi parla viaggia tramite WebRTC fino al nostro motore — la Mind API presso OVH, in Francia — e lì viene riconosciuto, sullo stesso server che regge la chiamata; il browser si limita a inviare l'audio e a ricevere indietro le parole. Nessun fornitore di riconoscimento vocale separato e nessun passaggio aggiuntivo prima che la traduzione possa iniziare. (Le note vocali in chat sono l'eccezione: la loro trascrizione gira su Azure AI Speech, il servizio vocale del gateway AI predefinito.)
• La traduzione non è un'unica diramazione. Il motore traduce per lingua di destinazione presente nella stanza, non per partecipante: la traduzione verso una lingua parte quando il primo ascoltatore di quella lingua richiede un flusso tradotto, tre partecipanti che hanno scelto il tedesco condividono un'unica traduzione tedesca, e se nessuno ascolta in arabo non si traduce nulla in arabo. Per questo una riunione in quattro lingue costa quanto una in quaranta, fino al punto di chi si è davvero presentato: non traduciamo mai in lingue che nessun partecipante sta ascoltando.
• Il parlato sintetizzato è per partecipante. Ogni partecipante riceve la propria traccia audio tradotta, mixata con il video originale di chi parla. Non sta guardando una «riunione tradotta» principale: sta guardando la stessa riunione, con il proprio canale audio personale tradotto nella lingua scelta. Per questo due persone nella stessa stanza fisica possono infilarsi ciascuna le cuffie e sentire lingue diverse.

Perché conta quando una riunione va storta

In una chiamata di 60 minuti con otto lingue le cose si rompono in modi interessanti: i WebSocket cadono, l'ASR sbaglia temporaneamente la trascrizione di un nome proprio, la rete di un partecipante diventa instabile. L'architettura descritta sopra ci permette di isolare i guasti: se l'audio di un partecipante ha dei problemi, gli altri sette non ne risentono, 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 generalisti di terze parti. Il budget di latenza li esclude; la questione della residenza dei dati li esclude per i clienti regolamentati, quelli a cui importa davvero.

Che cosa pubblichiamo sulla qualità della voce: /benchmark esegue ogni mese la pipeline vocale di produzione su frasi di FLORES-200 per ogni coppia di lingue pubblicata. Il giudice è dichiarato (Gemini 3.7 Flash come principale, Claude Sonnet 5 come riserva). La distribuzione completa — mediana, p10, p90, minimo, massimo, dimensione del campione — è sulla pagina. Consulta la metodologia per capire che cosa questi numeri misurano e che cosa no.

Pipeline 2: traduzione della chat in tempo reale

Il problema: ogni messaggio della chat nella riunione, tradotto per ogni partecipante nella sua lingua, nel momento in cui viene inviato. Più le modifiche, che devono apparire come modifiche e non come ritraduzioni.

Il budget: più ampio di quello della voce. Un messaggio di chat può impiegare un attimo ad apparire in un'altra lingua senza che nessuno ci badi. Ciò che conta per le persone è che la traduzione sia corretta e che le modifiche abbiano senso.

Che cosa fa davvero la pipeline della chat

Ogni messaggio passa per lo stesso motore di traduzione usato dalla pipeline vocale, ma con pre-elaborazione e post-elaborazione diverse:

• La struttura HTML viene preservata. La chat supporta il rich text (paragrafi, elenchi, citazioni, grassetto, corsivo). Lo convertiamo in testo semplice per il modello, traduciamo e poi riavvolgiamo il risultato nei tag originali. Il modello non vede mai l'HTML: vede prosa pulita.
• Le citazioni vengono tradotte in modo indipendente. Se rispondi a un messaggio e lo citi, il blocco [QUOTE]…[/QUOTE] e il nuovo contenuto vengono tradotti come unità separate, così il modello non può confonderli.
• I messaggi lunghi vengono suddivisi. Dividiamo ai confini di paragrafo a 1.000 caratteri per blocco. Ogni blocco è una chiamata di traduzione a sé. Non diamo in pasto al modello romanzi da 4.000 caratteri in un colpo solo: i modi in cui può fallire (troncamenti, paragrafi persi, interruzioni a metà frase) sono troppo brutti.
• La traduzione è pigra. Usiamo un IntersectionObserver: un messaggio viene tradotto solo quando entra nel viewport di chi legge. Cambiare lingua in un canale attivo da tempo faceva rieseguire ogni chiamata all'API di traduzione per tutta la cronologia. Ora non succede più.

La parte interessante: le modifiche come diff

Nella v1.2 abbiamo cambiato il comportamento delle modifiche in chat per chi legge in un'altra lingua. Il vecchio comportamento era: qualcuno modifica un messaggio, noi ritraduciamo tutto, e tu vedi un paragrafo nuovo e devi capire che cosa è cambiato.

Il nuovo comportamento:

1. Il messaggio originale era già stato tradotto nella tua lingua.
2. Quando il mittente lo 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, nello stesso modo in cui Git mostra che cosa è cambiato.

Così, quando in inglese «review by Tuesday» diventa «review by Thursday», il tuo collega che legge in spagnolo vede evidenziato martes → jueves, non un paragrafo ritradotto da rileggere.

Questo ha richiesto di trattare la pipeline della chat come una cache con stato per ogni partecipante, non come un endpoint senza stato che traduce a richiesta. I documenti e la voce non ne hanno bisogno. La chat sì.

Pipeline 3: traduzione delle note condivise in tempo reale

Il problema: chi ospita apre il pannello delle note condivise e inizia a scrivere. Ogni partecipante vede le note nella propria lingua, carattere per carattere, con la struttura del documento — titoli, elenchi annidati, checklist, blocchi di codice — intatta.

Il budget: lo stesso della chat, ma con due vincoli in più:

• Ciò che viene tradotto cambia mentre lo si traduce. Chi ospita sta ancora scrivendo. Un sistema ingenuo che traduce «l'intero documento» a ogni battuta produce sfarfallio e brucia il budget delle API. Noi traduciamo con la 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 annidati, ottieni qualcosa che sembra l'originale ma con la gerarchia sottilmente appiattita, voci rinumerate o indentazioni spostate. Non lasciamo che il modello veda l'intero blob.

In che cosa la pipeline delle note differisce dalla chat

La preservazione della struttura è l'aspetto principale. Traduciamo ogni voce di elenco in modo indipendente invece che come un unico documento. Il modello vede:

"Compliance review — Q2 deliverables"

— non:

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

Il documento che fa da contenitore — il <ul>, i titoli, l'indentazione — viene ricostruito lato client con la stessa struttura che aveva il documento originale, con ogni nodo foglia sostituito dalla sua traduzione. Il modello non ha mai occasione di «migliorare» la gerarchia.

Anche le note usano lo stesso modello di diff per partecipante delle modifiche in chat: se chi ospita cambia una riga, chi legge in altre lingue vede evidenziate le parole cambiate, non un paragrafo nuovo.

Pipeline 4: traduzione asincrona dei documenti

Il problema: qualcuno carica in chat un PDF di 40 pagine, un documento Word, una presentazione PowerPoint o un foglio Excel. Ogni partecipante può richiederne una copia nella propria lingua. Il file tradotto deve assomigliare all'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 assomiglia all'originale, chi lo riceve non si fiderà.

Perché questa pipeline non condivide il motore con la voce

Un LLM generalista, anche molto bravo, ti restituirà un testo tradotto di un documento. Non ti restituirà un PDF tradotto con lo stesso layout. Il modello non ha il concetto di «interruzione di pagina che deve combaciare con l'originale» o di «cella di tabella che deve mantenere la larghezza della colonna».

Per questa superficie usiamo direttamente la Document API di DeepL. È progettata 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. Poi carichiamo il risultato nel nostro object storage e lo riproponiamo 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 a file sul piano Pro, indipendentemente dal fatto che il documento abbia una pagina o trenta. Questo costo lo assorbiamo noi invece di addebitarlo per file; compare nell'utilizzo di traduzione della riunione come caratteri fatturati, convertiti in unità di parole in linea con il modo in cui il resto del prodotto riporta l'attività di traduzione.

Per questa superficie abbiamo scelto DeepL perché tradurre file come file è esattamente il lavoro per cui è stato creato: non abbiamo cercato di costruirne uno migliore. Non vale lo stesso al contrario: DeepL non gestisce una pipeline vocale dal vivo del tipo che abbiamo costruito per le riunioni. Problemi diversi, strumenti diversi. La versione onesta di «che cosa alimenta la traduzione di InterMIND» è «il motore giusto per ogni pipeline», non «il nostro motore, ovunque».

Le lingue che questa pipeline copre e la voce no

La pipeline dei documenti arriva a 30 lingue, contro le 23 della voce. Tra le lingue in più: bulgaro, greco, estone, indonesiano, lituano, lettone, slovacco, sloveno. (Anche l'arabo è in questo elenco ed è una delle lingue in più: è ritirato dal selettore in tempo reale finché la qualità della sua voce è sotto la nostra soglia, e i suoi punteggi per coppia restano pubblici su /benchmark: è quel numero a riportarlo. L'asimmetria funziona al contrario per l'hindi: attivo sulla voce, non ancora sui file.)

Quell'asimmetria è reale. Significa che un partecipante francese a una riunione può richiedere il PDF del contratto in estone anche se non può ascoltare la riunione in estone. La segnaliamo nel selettore invece di appianarla con un numero unico. Il ragionamento è nell'articolo sul numero di lingue.

Dove le pipeline si incontrano

Le quattro pipeline non girano isolate. La stanza di una riunione è il luogo in cui si toccano, e i punti di giunzione contano:

• Un messaggio di chat con un documento allegato attiva la pipeline della chat per il testo e quella dei documenti per il file. Il partecipante in un'altra lingua vede subito il messaggio tradotto, mentre la traduzione dell'allegato arriva in modo asincrono come file scaricabile.
• Una nota condivisa che cita una riga della trascrizione attraversa note ↔ voce. La trascrizione è ciò che la pipeline vocale ha prodotto per la lingua di chi ha scritto; la traduzione della nota produce una copia di quella citazione per ogni partecipante, nella lingua di tutti gli altri, con l'attribuzione della fonte preservata.
• Una trascrizione esportata dopo la riunione fa passare l'intera conversazione nella pipeline di testo in stile chat, producendo un file per lingua che i partecipanti possono scaricare. È lo stesso percorso di codice della traduzione della chat, solo eseguito in batch.

Il selettore della lingua è un unico elemento di interfaccia. L'infrastruttura sottostante è fatta di quattro pipeline che dialogano tra loro.

Che cosa deliberatamente non proviamo a fare

• Nessun «modello di traduzione unificato». Non stiamo costruendo un unico modello che faccia voce, chat, note e documenti. Il compromesso tra latenza e fedeltà non ha un vincitore. Usiamo il motore giusto per ogni superficie.
• Nessun instradamento silenzioso. Se la pipeline dei file oggi non può tradurre in hindi, non ripieghiamo di nascosto sul motore vocale facendo finta che abbia funzionato: il selettore dei file segnala la lacuna invece di nasconderla.
• Nessun «traduciamo in 200 lingue». Il nostro motore ne emette 24. Le superfici dal vivo ne offrono 23, i documenti 30 — e invece di un unico numero da slogan pubblichiamo su /benchmark la qualità per coppia, quella che deve reggere davanti a un auditor, coppie più deboli incluse.

Provalo di persona

• 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 produce i punteggi di /benchmark.
• Consulta il benchmark: qualità per coppia e per mese su traffico reale. Ogni coppia del selettore, forte o debole, con link diretto.
• Leggi la metodologia: che cosa sono i numeri, che cosa non sono, chi è il giudice.

Quattro pipeline, quattro motori, una sola stanza di riunione. Questa è la sostituzione onesta della vecchia pagina how-it-works.

— Il team di Mind.com

Fonti: DeepL — lingue supportate, DeepL — conteggio dell'utilizzo e fatturazione (il minimo di 50.000 caratteri per file), FLORES-200; i fatti interni sulle pipeline sono stati verificati sul codice rilasciato, controllo di agosto 2026.