A négy fordítási pipeline, amely az InterMIND-ot működteti

A mind.com régi /product/overview/how-it-works oldala több nagy kiadással le van maradva. Egyetlen „fordítómotort” ír le, ahogy a legtöbb gyártói oldal: egy nagy nyíl a „Ön beszél” és az „ők hallják” között. Ez a kép két éve is egyszerűsítés volt. Ma már téves.

Az igazság az, hogy az InterMIND négy különálló fordítási pipeline-t futtat, mindegyik más problémát old meg, más motorral, más késleltetési kerettel és más minőségi sávval. Egy nyelvválasztón osztoznak, motoron nem.

Ez a frissített válasz arra, hogy „hogyan működik”.

Kísérő írás: a „Hány nyelvet támogat az InterMIND?” azt mutatja be, mit fed le az egyes pipeline (23 / 23 / 30 / 17). Ez az írás azt, hogy mit csinál az egyes pipeline, és miért önálló egység.

Miért hazugság az „egy motor mindenre”

Egy élő meetingplatformnak legalább négy feladatot kell egyszerre ellátnia, és ezek összeegyeztethetetlen irányba húznak:

1. Valós idejű hang: bejövő hang, lefordított kimenő hang, miközben a beszélő még beszél, minden néző a saját nyelvén. A kemény korlát a késleltetés.
2. Valós idejű chatszöveg: rövid, gyors üzenetek, megőrzött szerkesztésekkel, idézetekkel és HTML-szerkezettel.
3. Valós idejű közös jegyzetek: karakterenkénti, közös gépelés, olyan szerkezeti hierarchiával (listák, címsorok, jelölőnégyzetek), amelynek túl kell élnie a fordítást.
4. Aszinkron dokumentumfájlok: egy 40 oldalas PDF, amely bekerül a chatbe. Nincs késleltetési keret. A kemény korlát a hűség: formázás, táblázatok, oldalszámok, betűtípus.

Építhet az ember egyetlen óriási LLM-hívást, amely mind a négyet megpróbálja ellátni. Mi megpróbáltuk. Mind a négyben rossz. A hang késleltetési kerete miatt a modell nem gondolkodhat, a dokumentumok hűségi igénye miatt viszont gondolkodnia kell. Egy chatszerkesztéshez a néző nyelvén készült diff kell, egy 40 oldalas PDF-hez pedig olyan formátummegőrzés, amelyet egyetlen tokenfolyamos modell sem ad.

Ezért négyet futtatunk. Lássuk őket egyenként.

1. pipeline: valós idejű hangfordítás

A probléma: egy résztvevő franciául beszél. Egy másik németül csatlakozott, egy harmadik brazil portugálul, egy negyedik japánul. Mindegyiküknek a saját nyelvén, a saját fülében kell hallania a beszélőt, olyan késleltetéssel, amely mellett még fenntartható a szemkontaktus.

A keret: a hallgatónak soha nem szabad várnia rá. Amint a lefordított beszéd annyira lemarad, hogy az emberek elkezdenek beleszólni, a meeting a „váltsunk inkább angolra” felé csúszik.

Hogyan mozog valójában a hang

Néhány dolgot érdemes külön megnevezni:

• Az ASR a médiaszerveren fut. A beszélő hangja WebRTC-n keresztül jut el a saját motorunkhoz — a franciaországi, OVH-nál futó Mind API-hoz —, és ott, ugyanazon a szerveren ismeri fel a rendszer, amely a hívást is hordozza; a böngésző csak hangot küld, és visszakapja a szavakat. Nincs külön beszédfelismerő szolgáltató, és nincs plusz ugrás, mielőtt a fordítás elkezdődhetne. (A chat hangüzenetei a kivétel: a beszédszöveg-átalakításuk az Azure AI Speech szolgáltatáson fut, amely az alapértelmezett AI-átjáró beszédszolgáltatása.)
• A fordítás nem egyetlen szétosztás. A motor a teremben jelen lévő célnyelvenként fordít, nem nézőnként: egy nyelvre a fordítás akkor indul, amikor az adott nyelv első hallgatója lefordított adatfolyamot kér. Három résztvevő, aki a németet választotta, egyetlen német fordításon osztozik, és ha senki nem hallgat arabul, akkor arabra semmi sem fordítódik. Ezért kerül egy négynyelvű meeting ugyanannyiba, mint egy negyvennyelvű, egészen addig, hogy ki jelent meg valójában: soha nem fordítunk olyan nyelvre, amelyen egyik résztvevő sem hallgat.
• A szintetizált beszéd nézőnkénti. Minden résztvevő a saját lefordított hangsávját kapja, az eredeti beszélő videójához keverve. Nem egy közös, „lefordított meetinget” néznek, hanem ugyanazt a meetinget, a saját hangcsatornájukkal a kiválasztott nyelvükre fordítva. Ezért tud két ember ugyanabban a fizikai szobában fejhallgatót feltenni, és mindketten más nyelvet hallanak.

Miért számít ez, ha egy meeting félremegy

Egy nyolc nyelvű, 60 perces hívásban érdekes módokon romlanak el a dolgok: megszakadnak a WebSocketek, az ASR átmenetileg félreír egy tulajdonnevet, egy résztvevő hálózata akadozni kezd. A fenti architektúra teszi lehetővé, hogy elszigeteljük a hibákat: egy néző hangjának megakadása nem érinti a másik hetet, mert a fordítómotor soha nem állított elő „a fordítást” — nyolcat állított elő, párhuzamosan, és csak az érintettnek kell helyreállnia.

Maga a motor a miénk, a saját infrastruktúránkon fut. A valós idejű hangot nem vezetjük át harmadik fél általános célú LLM-jein. A késleltetési keret kizárja őket, az adatrezidencia szempontja pedig kizárja őket azoknál a szabályozott ügyfeleknél, akiknek ez valóban számít.

Amit a hangminőségről közzéteszünk: a /benchmark oldal havonta lefuttatja az éles hang-pipeline-t FLORES-200 mondatokon minden közzétett nyelvpárra. A bíráló megnevezett (elsődlegesen Gemini 3.7 Flash, tartalékként Claude Sonnet 5). A teljes eloszlás — medián, p10, p90, minimum, maximum, mintaméret — az oldalon látható. Hogy ezek a számok mit mérnek és mit nem, azt a módszertanban olvashatja.

2. pipeline: valós idejű chatfordítás

A probléma: a meetingben minden chatüzenetet le kell fordítani minden résztvevő saját nyelvére, ahogy elküldik. Plusz a szerkesztéseket — és a szerkesztéseknek szerkesztésnek kell látszaniuk, nem újrafordításnak.

A keret: lazább, mint a hangnál. Egy chatüzenet megjelenhet egy másik nyelven egy pillanatnyi késéssel anélkül, hogy bárkit zavarna. Az embereket az érdekli, hogy a fordítás helyes-e, és hogy a szerkesztések értelmesek-e.

Mit csinál valójában a chat-pipeline

Minden üzenet ugyanazon a fordítómotoron megy át, amelyet a hang-pipeline is használ, de eltérő előfeldolgozással és utófeldolgozással:

• A HTML-szerkezet megmarad. A chat támogatja a formázott szöveget (bekezdések, listák, idézetek, félkövér, dőlt). A modellnek sima szöveggé alakítjuk, lefordítjuk, majd az eredményt visszaburkoljuk az eredeti címkékbe. A modell soha nem látja a HTML-t, csak tiszta szöveget.
• Az idézeteket külön fordítjuk. Ha egy üzenetre válaszol és idézi azt, a [QUOTE]…[/QUOTE] blokkot és az új tartalmat külön egységként fordítjuk, hogy a modell ne keverhesse össze a kettőt.
• A hosszú üzeneteket darabokra bontjuk. Bekezdéshatárok mentén vágunk, darabonként 1000 karakternél. Minden darab külön fordítási hívás. Nem adunk egyben a modellnek 4000 karakteres regényeket — a hibamódok (csonkolás, elveszett bekezdések, mondat közepén megszakadt szöveg) túl csúnyák.
• A fordítás lusta. IntersectionObservert használunk: egy üzenet csak akkor fordítódik, amikor belép a néző nézetablakába. Egy hosszú ideje futó csatornában a nyelvváltás korábban az előzmények minden fordítási API-hívását újra lejátszotta. Most már nem.

Az érdekes rész: szerkesztések diffként

A v1.2-ben megváltoztattuk, hogyan viselkednek a chatszerkesztések a más nyelvű nézőknél. A régi működés ez volt: valaki szerkeszt egy üzenetet, mi az egészet újrafordítjuk, Ön pedig egy friss bekezdést lát, és magának kell kiszúrnia, mi mozdult el.

Az új működés:

1. Az eredeti üzenet már le volt fordítva az Ön nyelvére.
2. Amikor a feladó szerkeszt, az új változatot fordítjuk újra.
3. Kiszámítjuk a diffet az Ön előző fordítása és az Ön új fordítása között, az Ön nyelvén.
4. Ezt a diffet soron belül jelenítjük meg — ugyanúgy, ahogy a Git megmutatja, mi változott.

Így amikor angolul a „review by Tuesday” „review by Thursday”-re változik, a spanyolul olvasó kolléga kiemelve a martes → jueves változást látja, nem egy újrafordított bekezdést, amelyet újra át kell olvasnia.

Ehhez a chat-pipeline-t állapottartó, nézőnkénti gyorsítótárként kellett kezelni, nem állapotmentes, kérésre fordító végpontként. A dokumentumoknak és a hangnak erre nincs szükségük. A chatnek igen.

3. pipeline: valós idejű közös jegyzetek fordítása

A probléma: a házigazda megnyit egy közös jegyzetpanelt, és gépelni kezd. Minden résztvevő a saját nyelvén látja a jegyzeteket, karakterenként, a dokumentum szerkezetével — címsorok, egymásba ágyazott listák, ellenőrzőlisták, kódblokkok — együtt.

A keret: ugyanaz, mint a chatnél, de két további megszorítással:

• A fordított tartalom a fordítás közben változik. A házigazda még gépel. Egy naiv rendszer, amely minden billentyűleütésnél „a teljes dokumentumot” fordítja, villódzást okoz, és elégeti az API-keretet. Mi a megváltozott egység szintjén fordítunk, nem a teljes dokumentumén.
• A szerkezetnek túl kell élnie. Ha egy fordítómodellt arra kér, hogy fordítson le egy háromszintes, egymásba ágyazott listákat tartalmazó markdown-tömböt, olyat kap vissza, ami az eredetinek látszik, de a hierarchia finoman ellaposodott, a tételek átszámozódtak, vagy a behúzás elmozdult. Mi nem engedjük, hogy a modell lássa az egész tömböt.

Miben különbözik a jegyzet-pipeline a chattől

A fő dolog a szerkezet megőrzése. Minden listaelemet külön fordítunk, nem egyetlen dokumentumként. A modell ezt látja:

„Compliance review — Q2 deliverables”

— nem ezt:

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

A körülvevő dokumentumot — az <ul>-t, a címsorokat, a behúzást — az ügyfél oldalán építjük újra, ugyanazzal a szerkezettel, amellyel az eredeti dokumentum rendelkezett, minden levélcsomópontot a fordítására cserélve. A modell soha nem „javíthatja” a hierarchiát.

A jegyzetek ugyanazt a nézőnkénti diffmodellt használják, mint a chatszerkesztések: ha a házigazda módosít egy sort, a más nyelvű nézők a megváltozott szavakat látják kiemelve, nem egy friss bekezdést.

4. pipeline: aszinkron dokumentumfordítás

A probléma: valaki bedob a chatbe egy 40 oldalas PDF-et, egy Word-dokumentumot, egy PowerPoint-prezentációt vagy egy Excel-táblázatot. Minden résztvevő kérhet egy példányt a saját nyelvén. A lefordított fájlnak ugyanúgy kell kinéznie, mint az eredetinek: ugyanazok a betűtípusok, ugyanazok a táblázatok, ugyanazok az oldalszámok, ugyanazok a fejlécek, ugyanazok a diagramok a helyükön.

A keret: nincs valós idejű korlát. Egy perc belefér. Két perc is belefér. A korlát a hűség — ha a lefordított PDF nem úgy néz ki, mint az eredeti, a címzett nem fog bízni benne.

Miért nem osztozik ez a pipeline motoron a hanggal

Egy általános LLM, még egy nagyon jó is, egy dokumentum lefordított szövegét adja vissza. Egy lefordított PDF-et ugyanazzal az elrendezéssel nem. A modell nem ismeri a „forrással összhangban lévő oldaltörés” vagy a „táblázatcella, amelynek meg kell tartania az oszlopszélességét” fogalmát.

Erre a felületre közvetlenül a DeepL Document API-t használjuk. Kifejezetten fájlok fájlként való fordítására készült, nem a fájlokból kinyert szövegére. A DeepL kezeli:

• a PDF-et (elrendezésmegőrzéssel)
• a DOCX-et és a DOC-ot
• a PPTX-et
• az XLSX-et

A dokumentumot feltöltjük a DeepL pipeline-jába, ott a formázás érintetlenül hagyásával, szerveroldalon lefordítják, és ugyanabban a formátumban adják vissza. Az eredményt ezután feltöltjük az objektumtárolónkba, és letölthető mellékletként megjelenítjük a chatben.

Mibe kerül ez, és miért nem titkoljuk

A DeepL dokumentumonként minimum 50 000 karaktert számláz — a Pro csomagban nagyjából egy amerikai dollárt fájlonként, függetlenül attól, hogy a dokumentum egy vagy harminc oldalas. Ezt a költséget mi vállaljuk, nem számlázzuk fájlonként; a meeting fordítási használatában számlázott karakterekként jelenik meg, szóegységekre átváltva, úgy, ahogy a termék többi része is jelenti a fordítási tevékenységet.

Azért választottuk erre a felületre a DeepL-t, mert a fájlok fájlként való fordítása pontosan az, amire készült — nem próbáltunk jobbat építeni. Fordítva ez nem igaz: a DeepL nem működtet olyan élőhang-pipeline-t, amilyet mi építettünk a meetingekhez. Más problémák, más eszközök. A „mi hajtja az InterMIND fordítását” őszinte válasza az „a megfelelő motor pipeline-onként” — nem az „a mi motorunk, mindenhol”.

Nyelvek, amelyeket ez a pipeline lefed, a hang pedig nem

A dokumentum-pipeline 30 nyelvet ér el, szemben a hang 23 nyelvével. A többletnyelvek között van: bolgár, görög, észt, indonéz, litván, lett, szlovák, szlovén. (Az arab is ezen a listán szerepel, és az egyik többletnyelv: a valós idejű nyelvválasztóból visszavontuk, amíg a hangminősége a mércénk alatt van, páronkénti pontszámai pedig nyilvánosak maradnak a /benchmark oldalon — ez a szám hozza vissza. Az aszimmetria a hindinél fordítva áll fenn: hangban él, fájlokban még nem.)

Ez az aszimmetria valódi. Azt jelenti, hogy egy francia résztvevő a meetingben kérheti a szerződés PDF-jét észtül, még ha a meetinget nem is tudja észtül hallgatni. Ezt jelezzük a nyelvválasztóban, ahelyett hogy egyetlen számmal elsimítanánk. Az indoklás a nyelvszámról szóló írásban olvasható.

Ahol a pipeline-ok találkoznak

A négy pipeline nem elszigetelten fut. A meetingterem az a hely, ahol érintkeznek egymással, és a találkozási pontok számítanak:

• Egy dokumentummellékletet tartalmazó chatüzenet a szöveghez a chat-pipeline-t, a fájlhoz a dokumentum-pipeline-t indítja el. A másik nyelvű résztvevő azonnal lefordítva látja az üzenetet, a melléklet fordítása pedig aszinkron módon, letölthető fájlként érkezik meg.
• Egy közös jegyzet, amely egy átirati sort idéz, a jegyzetek és a hang határát lépi át. Az átirat az, amit a hang-pipeline a feladó nyelvén előállított; a jegyzetfordítás ebből az idézetből nézőnkénti másolatot készít mindenki más nyelvén, a forrásmegjelöléssel együtt.
• A meeting után exportált átirat a chatszerű szöveg-pipeline-on fut végig a teljes beszélgetésen, és nyelvenként egy fájlt állít elő, amelyet a résztvevők letölthetnek. Ez ugyanaz a kódút, mint a chatfordításnál, csak kötegelve.

A nyelvválasztó egyetlen felületi elem. Alatta az infrastruktúra négy pipeline, amelyek beszélgetnek egymással.

Amit tudatosan nem próbálunk meg

• Nincs „egységes fordítómodell”. Nem építünk egyetlen modellt, amely hangot, chatet, jegyzeteket és dokumentumokat is csinál. A késleltetés és a hűség közötti kompromisszumnak nincs győztese. Felületenként a megfelelő motort használjuk.
• Nincs néma átirányítás. Ha a fájl-pipeline ma nem tud hindire fordítani, nem esünk vissza csendben a hangmotorra azt színlelve, hogy működött — a fájlválasztó jelzi a hiányt ahelyett, hogy elrejtené.
• Nincs „200 nyelvre fordítunk”. A motorunk 24 nyelvet bocsát ki. Az élő felületek 23-at, a dokumentumok 30-at kínálnak — és egyetlen marketingbarát szám helyett a nyelvpáronkénti minőséget, amelynek egy auditor előtt is helyt kell állnia, a /benchmark oldalon tesszük közzé, a gyengébb párokkal együtt.

Próbálja ki maga

• Próbálja ki az élő demót — az élő hang-pipeline-t futtatja az Ön hangján, a 23 terméknyelv bármelyikén. Ugyanaz a pipeline, amely a /benchmark pontszámait adja.
• Nézze meg a benchmarkot — nyelvpáronkénti, havi minőség valós forgalmon. A nyelvválasztó minden párja, erős vagy gyenge, közvetlenül linkelhető.
• Olvassa el a módszertant — mik a számok, mik nem azok, és ki a bíráló.

Négy pipeline, négy motor, egy meetingterem. Ez a régi how-it-works oldal őszinte pótlása.

— A Mind.com csapata

Források: DeepL — támogatott nyelvek, DeepL — használatszámlálás és számlázás (a fájlonkénti 50 000 karakteres minimum), FLORES-200; a belső pipeline-tényeket a kiadott kóddal egyeztettük, ellenőrizve 2026 augusztusában.