Cum funcționează cele patru pipeline-uri de traducere din InterMIND

Vechea pagină /product/overview/how-it-works de pe mind.com este depășită cu mai multe versiuni majore. Descrie un singur „motor de traducere", așa cum fac majoritatea paginilor de prezentare ale furnizorilor: o singură săgeată mare de la „vorbești tu" la „aud ei". Imaginea aceasta era deja o simplificare acum doi ani. Astăzi este greșită.

Adevărul este că InterMIND rulează patru pipeline-uri de traducere separate, fiecare rezolvând o altă problemă, cu un alt motor, un alt buget de latență și o altă plajă de calitate. Au în comun un selector de limbă. Nu au în comun un motor.

Acesta este răspunsul actualizat la întrebarea „cum funcționează".

O postare complementară: „Câte limbi sunt acceptate?" arată ce acoperă fiecare pipeline (23 / 23 / 30 / 17). Postarea de față arată ce face fiecare pipeline și de ce este o piesă de sine stătătoare.

De ce „un singur motor pentru tot" este o minciună

O platformă de întâlniri live are cel puțin patru sarcini de îndeplinit simultan, iar acestea trag în direcții incompatibile:

1. Voce în timp real — audio la intrare, audio tradus la ieșire cât timp vorbitorul încă vorbește, fiecare participant în limba lui. Constrângerea dură este latența.
2. Text de chat în timp real — mesaje scurte, rapide, cu editări, citate și structură HTML păstrate.
3. Notițe comune în timp real — scriere colaborativă caracter cu caracter, cu o ierarhie structurală (liste, titluri, căsuțe de bifat) care trebuie să supraviețuiască traducerii.
4. Fișiere-document asincrone — un PDF de 40 de pagini aruncat în chat. Fără buget de latență. Constrângerea dură este fidelitatea: formatare, tabele, numere de pagină, font.

Se poate construi un singur apel uriaș către un LLM care încearcă să le facă pe toate patru. Am încercat. Se descurcă prost la toate patru. Bugetul de latență al vocii înseamnă că modelul nu are timp să „gândească"; bugetul de fidelitate al documentelor înseamnă că trebuie. O editare în chat cere un diff în limba spectatorului; un PDF de 40 de pagini cere o păstrare a formatului pe care niciun model cu generare token cu token nu o oferă.

Așa că rulăm patru. Iată-le pe rând.

Pipeline 1: Traducerea vocală în timp real

Problema: Un participant vorbește franceza. Altul s-a alăturat în germană, un al treilea în portugheză braziliană, un al patrulea în japoneză. Fiecare trebuie să audă vorbitorul în limba lui, în propria cască, cu o întârziere suficient de scurtă încât contactul vizual să rămână posibil.

Bugetul: ascultătorul nu trebuie să aștepte niciodată după traducere. Odată ce vorbirea tradusă rămâne atât de în urmă încât oamenii încep să vorbească peste ea, întâlnirea alunecă spre „hai să trecem pe engleză".

Cum circulă de fapt sunetul

Câteva lucruri merită numite explicit:

• ASR rulează pe serverul media. Sunetul vorbitorului călătorește prin WebRTC către propriul nostru motor — Mind API la OVH, Franța — și este recunoscut acolo, pe același server care transportă apelul; browserul doar trimite audio și primește cuvintele înapoi. Fără un furnizor separat de recunoaștere vocală și fără un salt suplimentar înainte ca traducerea să poată începe. (Mesajele vocale din chat sunt excepția: transcrierea lor rulează pe Azure AI Speech, serviciul de vorbire al gateway-ului AI implicit.)
• Traducerea nu este o simplă difuzare către toți. Motorul traduce pentru fiecare limbă țintă prezentă în încăpere, nu pentru fiecare spectator: traducerea într-o limbă pornește când primul ascultător din ea cere un flux tradus, trei participanți care au ales germana împart o singură traducere în germană, iar dacă nimeni nu ascultă în arabă, nu se traduce nimic în arabă. De aceea o întâlnire în patru limbi costă la fel ca una în patruzeci de limbi, până la punctul în care contează cine s-a prezentat de fapt — nu traducem niciodată în limbi în care nu ascultă niciun participant.
• Vorbirea sintetizată este per spectator. Fiecare participant primește propria piesă audio tradusă, mixată peste video-ul vorbitorului original. Nu urmăresc o „întâlnire tradusă" de referință — urmăresc aceeași întâlnire, cu canalul audio personal tradus în limba aleasă. De aceea două persoane din aceeași încăpere fizică își pot pune fiecare căștile și pot auzi limbi diferite.

De ce contează asta când o întâlnire o ia razna

Într-un apel de 60 de minute cu opt limbi, lucrurile se strică în moduri interesante: WebSocket-urile cad, ASR transcrie temporar greșit un nume propriu, rețeaua unui participant devine instabilă. Arhitectura de mai sus ne permite să izolăm defecțiunile: sunetul unui spectator care are probleme nu îi afectează pe ceilalți șapte, pentru că motorul de traducere nu a produs niciodată „traducerea" — a produs opt, în paralel, și doar cea afectată trebuie să își revină.

Motorul în sine este al nostru, găzduit pe propria noastră infrastructură. Nu direcționăm vocea în timp real prin LLM-uri generale ale unor terți. Bugetul de latență le exclude; rezidența datelor le exclude pentru clienții reglementați, cărora chiar le pasă.

Ce publicăm despre calitatea vocii: /benchmark rulează lunar pipeline-ul vocal de producție pe propoziții FLORES-200, pentru fiecare pereche de limbi publicată. Judecătorul este numit (Gemini 3.7 Flash principal, Claude Sonnet 5 de rezervă). Distribuția completă — mediană, p10, p90, minim, maxim, dimensiunea eșantionului — se găsește pe pagină. Consultați metodologia pentru ce măsoară și ce nu măsoară aceste cifre.

Pipeline 2: Traducerea chatului în timp real

Problema: Fiecare mesaj de chat din întâlnire, tradus pentru fiecare participant în limba lui, în momentul trimiterii. Plus editările — iar editările trebuie să arate ca editări, nu ca retraduceri.

Bugetul: mai relaxat decât la voce. Un mesaj de chat poate dura o clipă până să apară în altă limbă, fără ca cineva să se supere. Oamenii se uită la dacă traducerea este corectă și la dacă editările au sens.

Ce face de fapt pipeline-ul de chat

Fiecare mesaj trece prin același motor de traducere pe care îl folosește și pipeline-ul vocal, dar cu o pre- și post-procesare diferite:

• Structura HTML este păstrată. Chatul acceptă text îmbogățit (paragrafe, liste, citate, bold, italic). Convertim în text simplu pentru model, traducem, apoi reîmpachetăm rezultatul în etichetele originale. Modelul nu vede niciodată HTML-ul — vede proză curată.
• Citatele sunt traduse independent. Dacă răspundeți la un mesaj și îl citați, blocul [QUOTE]…[/QUOTE] și conținutul nou sunt traduse ca unități separate, astfel încât modelul să nu le confunde.
• Mesajele lungi sunt împărțite în bucăți. Împărțim la granițele paragrafelor, la 1.000 de caractere per bucată. Fiecare bucată este un apel de traducere separat. Nu dăm modelului „romane" de 4.000 de caractere dintr-o dată — defectele (trunchiere, paragrafe pierdute, tăieri în mijlocul propoziției) sunt prea urâte.
• Traducerea este leneșă. Folosim un IntersectionObserver: un mesaj este tradus doar când ajunge în viewport-ul spectatorului. Schimbarea limbii într-un canal vechi redădea odinioară toate apelurile API de traducere din istoric. Acum nu mai face asta.

Partea interesantă: editările ca diff-uri

În v1.2 am schimbat comportamentul editărilor din chat pentru spectatorii dintr-o altă limbă. Comportamentul vechi era: cineva editează un mesaj, retraducem totul, vedeți un paragraf nou și trebuie să descoperiți ce s-a mutat.

Comportamentul nou:

1. Mesajul original era deja tradus în limba dvs.
2. Când expeditorul editează, retraducem versiunea nouă.
3. Calculăm diff-ul dintre traducerea dvs. anterioară și traducerea dvs. nouă, în limba dvs.
4. Afișăm diff-ul în linie — în același mod în care Git vă arată ce s-a schimbat.

Așadar, când „review by Tuesday" devine „review by Thursday" în engleză, colegul dvs. care citește în spaniolă vede evidențiat martes → jueves, nu un paragraf retradus pe care trebuie să îl recitească.

Asta a cerut tratarea pipeline-ului de chat ca un cache cu stare, per spectator, nu ca un endpoint fără stare de tip traduce-la-cerere. Documentele și vocea nu au nevoie de așa ceva. Chatul are.

Pipeline 3: Traducerea notițelor comune în timp real

Problema: Gazda deschide un panou de notițe comune și începe să scrie. Fiecare participant vede notițele în limba lui, caracter cu caracter, cu structura documentului — titluri, liste imbricate, liste de verificare, blocuri de cod — intactă.

Bugetul: La fel ca la chat, dar cu două constrângeri în plus:

• Ceea ce se traduce se schimbă în timpul traducerii. Gazda încă scrie. Un sistem naiv care traduce „tot documentul" la fiecare apăsare de tastă produce sfârâit și consumă bugetul API. Noi traducem la granularitatea unității modificate, nu a întregului document.
• Structura trebuie să supraviețuiască. Dacă cereți unui model de traducere să traducă un blob markdown cu trei liste imbricate, primiți ceva care arată ca originalul, dar cu ierarhia ușor aplatizată, elemente renumerotate sau indentare mutată. Nu lăsăm modelul să vadă tot blobul.

Cum diferă pipeline-ul de notițe de cel de chat

Păstrarea structurii este lucrul principal. Traducem fiecare element de listă independent, nu ca pe un singur document. Modelul vede:

„Revizuire de conformitate — livrabile T2"

— nu:

"# Plan de proiect\n## Trimestru\n- Revizuire de conformitate — livrabile T2\n- Evaluarea furnizorilor\n - Furnizori de nivel 1..."

Documentul-înveliș — <ul>, titlurile, indentarea — este reconstruit pe partea de client folosind aceeași structură pe care a avut-o documentul original, fiecare nod-frunză fiind înlocuit cu traducerea sa. Modelul nu apucă să „îmbunătățească" ierarhia.

Notițele folosesc și același model de diff per spectator ca editările din chat: dacă gazda modifică o linie, spectatorii din alte limbi văd evidențiate cuvintele modificate, nu un paragraf nou.

Pipeline 4: Traducerea asincronă a documentelor

Problema: Cineva aruncă în chat un PDF de 40 de pagini, un document Word, o prezentare PowerPoint sau un tabel Excel. Fiecare participant poate cere o copie în limba lui. Fișierul tradus trebuie să arate ca originalul — aceleași fonturi, aceleași tabele, aceleași numere de pagină, aceleași antete, aceleași grafice la locul lor.

Bugetul: Fără constrângere de timp real. Un minut e în regulă. Două minute sunt în regulă. Constrângerea este fidelitatea — dacă PDF-ul tradus nu arată ca originalul, destinatarul nu va avea încredere în el.

De ce acest pipeline nu împarte un motor cu vocea

Un LLM general, oricât de bun, vă va returna un text tradus al unui document. Nu vă va returna un PDF tradus cu aceeași așezare în pagină. Modelul nu are noțiunea de „sfârșit de pagină care trebuie să se alinieze cu sursa" sau de „celulă de tabel care trebuie să-și păstreze lățimea coloanei".

Pentru această suprafață folosim direct DeepL Document API. Este construit special pentru a traduce fișiere ca fișiere, nu proză extrasă din fișiere. DeepL gestionează:

• PDF (cu păstrarea așezării în pagină)
• DOCX, DOC
• PPTX
• XLSX

Documentul este încărcat în pipeline-ul DeepL, tradus pe server cu formatarea intactă și returnat în același format. Apoi încărcăm rezultatul în stocarea noastră de obiecte și îl afișăm înapoi în chat ca atașament descărcabil.

Cât costă și de ce nu ascundem asta

DeepL facturează un minim de 50.000 de caractere per document — aproximativ un dolar american per fișier pe nivelul Pro, indiferent dacă documentul are o pagină sau treizeci. Absorbim acest cost în loc să taxăm per fișier; apare în consumul de traducere al întâlnirii ca caractere facturate, convertite în unități-cuvânt care corespund modului în care restul produsului raportează activitatea de traducere.

Am ales DeepL pentru această suprafață pentru că traducerea fișierelor ca fișiere este exact lucrul pentru care a fost construit — nu am încercat să construim unul mai bun. Invers nu este valabil — DeepL nu rulează un pipeline de voce live de felul celui construit de noi pentru întâlniri. Probleme diferite; instrumente diferite. Versiunea onestă a răspunsului la „ce alimentează traducerea InterMIND" este „motorul potrivit pentru fiecare pipeline" — nu „motorul nostru, peste tot".

Limbile pe care le acoperă acest pipeline și vocea nu

Pipeline-ul de documente ajunge la 30 de limbi, față de 23 la voce. Printre cele în plus se numără: bulgara, greaca, estona, indoneziana, lituaniana, letona, slovaca, slovena. (Araba se află și ea pe această listă și este una dintre cele în plus: este retrasă din selectorul în timp real cât timp calitatea ei vocală este sub pragul nostru, iar scorurile ei pe perechi rămân publice pe /benchmark — acea cifră este cea care o readuce. Asimetria merge în sens invers pentru hindi — disponibilă la voce, încă nu și la fișiere.)

Asimetria aceasta este reală. Înseamnă că un participant francez dintr-o întâlnire poate cere PDF-ul contractului în estonă, chiar dacă nu poate asculta întâlnirea în estonă. Semnalăm asta în selector, în loc să o netezim cu o singură cifră. Raționamentul se găsește în postarea despre numărul de limbi.

Unde se întâlnesc pipeline-urile

Cele patru pipeline-uri nu rulează în izolare. O încăpere de întâlnire este locul unde se ating între ele, iar îmbinările contează:

• Un mesaj de chat cu un document atașat declanșează pipeline-ul de chat pentru text și pipeline-ul de documente pentru fișier. Participantul dintr-o altă limbă vede imediat mesajul tradus, iar traducerea atașamentului sosește asincron, ca fișier descărcabil.
• O notiță comună care citează o linie din transcriere traversează notițe ↔ voce. Transcrierea este ceea ce a produs pipeline-ul vocal pentru limba expeditorului; traducerea notiței produce o copie per spectator a acelui citat în limba tuturor celorlalți, cu atribuirea sursei păstrată.
• O transcriere exportată după întâlnire rulează pipeline-ul de text în stil chat peste întreaga conversație, producând un fișier per limbă pe care participanții îl pot descărca. Este aceeași cale de cod ca la traducerea chatului, doar că în loturi.

Selectorul de limbă este o singură piesă de interfață. Infrastructura de dedesubt este formată din patru pipeline-uri care comunică între ele.

Ce nu încercăm în mod deliberat

• Niciun „model unificat de traducere". Nu construim un singur model care să facă voce, chat, notițe și documente. Compromisul dintre latență și fidelitate nu are un câștigător. Folosim motorul potrivit pentru fiecare suprafață.
• Nicio redirecționare silențioasă. Dacă pipeline-ul de fișiere nu poate traduce astăzi în hindi, nu cădem discret pe motorul vocal pretinzând că a mers — selectorul de fișiere semnalează golul în loc să-l ascundă.
• Niciun „traducem în 200 de limbi". Motorul nostru emite 24. Suprafețele live oferă 23, documentele 30 — și, în loc de o singură cifră prietenoasă pentru marketing, calitatea pe perechi, care trebuie să reziste în fața unui auditor, este publicată la /benchmark, inclusiv perechile mai slabe.

Încercați chiar acum

• Încercați demo-ul live — rulează pipeline-ul vocal live pe sunetul dvs., în oricare dintre cele 23 de limbi ale produsului. Este același pipeline care obține scorurile de pe /benchmark.
• Vedeți benchmarkul — calitate pe perechi, pe luni, pe trafic real. Fiecare pereche din selector, puternică sau slabă, cu link direct.
• Citiți metodologia — ce sunt cifrele, ce nu sunt, cine este judecătorul.

Patru pipeline-uri, patru motoare, o singură încăpere de întâlnire. Acesta este înlocuitorul onest al vechii pagini how-it-works.

— Echipa Mind.com

Surse: DeepL — limbi acceptate, DeepL — contorizarea consumului și facturarea (minimul de 50.000 de caractere per fișier), FLORES-200; faptele interne despre pipeline-uri au fost verificate în raport cu codul livrat, la data de august 2026.