Pohled do čtyř překladových pipeline, na kterých běží InterMIND

Stará stránka /product/overview/how-it-works na mind.com je o několik velkých verzí pozadu. Popisuje jediný „překladový engine“ tak, jak to dělá většina stránek dodavatelů: jedna velká šipka od „vy mluvíte“ k „oni slyší“. Takové zjednodušení bylo už před dvěma lety nepřesné. Dnes je prostě chybné.

Pravda je, že InterMIND provozuje čtyři samostatné překladové pipeline. Každá řeší jiný problém, používá jiný engine, má jiný rozpočet latence a jinou kvalitativní obálku. Sdílejí výběr jazyka, ale ne engine.

Tohle je aktualizovaná odpověď na otázku „jak to funguje“.

Doprovodný článek: „Kolik jazyků podporujete?“ popisuje, co každá pipeline pokrývá (23 / 23 / 30 / 17). Tento příspěvek popisuje, co každá pipeline dělá — a proč je samostatnou věcí.

Proč je „jeden engine pro všechno“ lež

Platforma pro živé schůzky musí plnit nejméně čtyři úlohy najednou a ty se táhnou nesluečitelnými směry:

1. Hlas v reálném čase — zvuk na vstupu, přeložený zvuk na výstupu, do jedné sekundy, každý posluchač ve svém jazyce. Tvrdým omezením je latence.
2. Chat v reálném čase — krátké zprávy, rychle, se zachovanými úpravami, citacemi a HTML strukturou.
3. Sdílené poznámky v reálném čase — společné psaní znak po znaku, se strukturní hierarchií (seznamy, nadpisy, zaškrtávací políčka), která musí přežít překlad.
4. Asynchronní dokumentové soubory — 40stránkové PDF vložené do chatu. Žádný rozpočet latence. Tvrdým omezením je věrnost — formátování, tabulky, čísla stránek, písmo.

Můžete postavit jedno obří volání LLM, které se pokusí zvládnout všechny čtyři. Zkoušeli jsme to. Je špatné ve všech čtyřech. Rozpočet latence pro hlas znamená, že model nemůže přemýšlet; rozpočet věrnosti pro dokumenty znamená, že přemýšlet musí. Úprava chatové zprávy potřebuje rozdíl (diff) v jazyce posluchače; 40stránkové PDF potřebuje zachování formátu, které žádný tokenově streamující model nedá.

Takže provozujeme čtyři. Tady je každá z nich.

Pipeline 1: Překlad hlasu v reálném čase

Problém: Jeden účastník mluví francouzsky. Druhý se připojil v němčině, třetí v brazilské portugalštině, čtvrtý v japonštině. Každý potřebuje slyšet mluvčího ve svém jazyce, ve svém uchu, se zpožděním dostatečně krátkým na to, aby bylo možné udržet oční kontakt.

Rozpočet: Méně než sekunda od začátku do konce. Cokoli nad ~1,2 sekundy konverzaci rozbije — lidé začnou mluvit přes překlad a schůzka sklouzne k „pojďme radši přejít do angličtiny“.

Jak se zvuk skutečně pohybuje

Několik věcí stojí za výslovné pojmenování:

• ASR běží na mediálním serveru. Zvuk mluvčího putuje přes WebRTC do našeho vlastního enginu — Mind API u OVH ve Francii — a je tam rozpoznán, na stejném serveru, který nese hovor; prohlížeč zvuk pouze posílá a slova dostává zpět. Žádný samostatný dodavatel rozpoznávání řeči a žádný další přeskok, než může překlad začít. (Výjimkou jsou hlasové poznámky v chatu: jejich převod řeči na text běží na Azure AI Speech, řečové službě výchozí AI brány.)
• Překlad není jedno rozvětvení. Engine překládá do každého cílového jazyka přítomného v místnosti, ne pro každého posluchače: překlad do daného jazyka se spustí, když o přeložený stream požádá první posluchač v něm, tři účastníci, kteří si zvolili němčinu, sdílejí jeden německý překlad, a pokud nikdo neposlouchá arabsky, nepřekládá se do arabštiny nic. Proto stojí čtyřjazyčná schůzka stejně jako čtyřicetijazyčná, a to až po bod, kdo se skutečně objevil — nikdy nepřekládáme do jazyků, ve kterých nikdo neposlouchá.
• Syntetizovaná řeč je pro každého posluchače zvlášť. Každý účastník dostává vlastní přeloženou zvukovou stopu, namixovanou k původnímu videu mluvčího. Nesledují hlavní „přeloženou schůzku“ — sledují tutéž schůzku s osobním zvukovým kanálem přeloženým do zvoleného jazyka. Proto si dva lidé ve stejné fyzické místnosti mohou připojit sluchátka a slyšet každý jiný jazyk.

Proč to záleží, když se schůzka pokazí

V hodinovém hovoru s osmi jazyky se věci kazí zajímavými způsoby: WebSockety vypadnou, ASR dočasně špatně přepíše vlastní jméno, síť jednoho účastníka začne kolísat. Výše popsaná architektura nám umožňuje poruchy izolovat: výpadek zvuku jednoho posluchače neovlivní ostatních sedm, protože překladový engine nikdy nevytvořil „ten překlad“ — vytvořil osm, paralelně, a zotavit se musí jen ten postižený.

Samotný engine je náš a běží na naší vlastní infrastruktuře. Hlas v reálném čase nesměrujeme přes cizí univerzální LLM. Vylučuje je rozpočet latence; a vylučuje je i příběh rezidence dat pro regulované zákazníky, kterým na ní skutečně záleží.

Co zveřejňujeme o kvalitě hlasu: /benchmark měsíčně spouští produkční hlasovou pipeline proti větám FLORES-200 pro každý zveřejněný jazykový pár. Rozhodčí je jmenovitě uveden (primárně Gemini 3.7 Flash, záložně Claude Sonnet 5). Celé rozdělení — medián, p10, p90, minimum, maximum, velikost vzorku — je na stránce. Co tato čísla měří a neměří, najdete v metodice.

Pipeline 2: Překlad chatu v reálném čase

Problém: Každá chatová zpráva na schůzce, přeložená pro každého účastníka do jeho jazyka, hned jak je odeslána. K tomu úpravy — a úpravy musí vypadat jako úpravy, ne jako nové překlady.

Rozpočet: Rychle, ale ne do sekundy. Chatová zpráva se může v jiném jazyce objevit za půl sekundy a nikomu to nevadí. Lidem záleží na tom, jestli je překlad správný a jestli úpravy dávají smysl.

Co chatová pipeline skutečně dělá

Každá zpráva prochází stejným překladovým enginem, který používá hlasová pipeline — ale s jiným předzpracováním a pozpracováním:

• HTML struktura je zachována. Chat podporuje formátovaný text (odstavce, seznamy, citace, tučné písmo, kurzívu). Pro model převedeme text na prostý, přeložíme a výsledek znovu zabalíme do původních značek. Model HTML nikdy nevidí — vidí čistou prózu.
• Citace se překládají nezávisle. Pokud odpovíte na zprávu a citujete ji, blok [QUOTE]…[/QUOTE] a nový obsah se překládají jako samostatné jednotky, takže model tyto dvě části nemůže zaměnit.
• Dlouhé zprávy se dělí na části. Dělíme na hranicích odstavců po 1 000 znacích na část. Každá část je samostatné volání překladu. Modelu nepodáváme najednou 4 000znakové romány — způsoby selhání (oříznutí, ztracené odstavce, useknutí uprostřed věty) jsou příliš ošklivé.
• Překlad je líný. Používáme IntersectionObserver: zpráva se přeloží, teprve když se posune do viewportu posluchače. Přepnutí jazyků v dlouho běžícím kanálu dříve znovu spustilo všechna volání překladového API z historie. Teď už ne.

Zajímavá část: úpravy jako diffy

Ve verzi v1.2 jsme změnili, jak se úpravy chatu chovají pro posluchače v jiném jazyce. Staré chování: někdo zprávu upraví, my přeložíme celou znovu, vy vidíte nový odstavec a musíte hledat, co se změnilo.

Nové chování:

1. Původní zpráva už byla přeložena do vašeho jazyka.
2. Když odesílatel zprávu upraví, přeložíme novou verzi.
3. Spočítáme rozdíl mezi vaším předchozím překladem a vaším novým překladem, ve vašem jazyce.
4. Ten rozdíl zobrazíme přímo v textu — stejně, jak vám změny ukazuje Git.

Takže když se v angličtině „review by Tuesday“ změní na „review by Thursday“, váš španělsky čtoucí kolega uvidí zvýrazněné martes → jueves, ne znovu přeložený odstavec, který by musel číst znovu.

To vyžadovalo chápat chatovou pipeline jako stavovou cache pro každého posluchače, ne jako bezstavový koncový bod „přelož na požádání“. Dokumenty a hlas to nepotřebují. Chat ano.

Pipeline 3: Překlad sdílených poznámek v reálném čase

Problém: Hostitel otevře panel sdílených poznámek a začne psát. Každý účastník vidí poznámky ve svém jazyce, znak po znaku, a struktura dokumentu — nadpisy, vnořené seznamy, kontrolní seznamy, bloky kódu — zůstává nedotčena.

Rozpočet: Stejný jako u chatu (~půl sekundy), ale se dvěma dalšími omezeními:

• To, co se překládá, se během překladu mění. Hostitel stále píše. Naivní systém, který při každém stisku klávesy překládá „celý dokument“, způsobuje blikání a spaluje rozpočet API. My překládáme na úrovni změněné jednotky, ne celého dokumentu.
• Struktura musí přežít. Když požádáte překladový model, aby přeložil markdownový blok se třemi vnořenými seznamy, dostanete zpět něco, co vypadá jako originál, ale s nenápadně zploštělou hierarchií, přečíslovanými položkami nebo posunutým odsazením. Modelu celý blok nedáváme.

Čím se pipeline poznámek liší od chatu

Hlavní věcí je zachování struktury. Každou položku seznamu překládáme nezávisle, ne jako jeden dokument. Model vidí:

„Kontrola compliance — výstupy za Q2“

— ne:

„# Plán projektu\n## Čtvrtletí\n- Kontrola compliance — výstupy za Q2\n- Hodnocení dodavatelů\n - Dodavatelé úrovně 1...“

Obalující dokument — <ul>, nadpisy, odsazení — se na straně klienta sestaví znovu se stejnou strukturou, jakou měl originál, přičemž každý koncový uzel je nahrazen svým překladem. Model nikdy nedostane příležitost hierarchii „vylepšit“.

Poznámky také používají stejný model diffů pro každého posluchače jako úpravy chatu: pokud hostitel změní řádek, posluchači v jiných jazycích vidí zvýrazněná změněná slova, ne nový odstavec.

Pipeline 4: Asynchronní překlad dokumentů

Problém: Někdo vloží do chatu 40stránkové PDF, dokument Wordu, prezentaci PowerPointu nebo list Excelu. Každý účastník si může vyžádat kopii ve svém jazyce. Přeložený soubor musí vypadat jako originál — stejná písma, stejné tabulky, stejná čísla stránek, stejné záhlaví, stejné grafy na svých místech.

Rozpočet: Žádné omezení reálného času. Minuta je v pořádku. Dvě minuty jsou v pořádku. Omezením je věrnost — pokud přeložené PDF nevypadá jako originál, příjemce mu nebude důvěřovat.

Proč tato pipeline nesdílí engine s hlasem

Univerzální LLM, i velmi dobrý, vám vrátí přeložený text dokumentu. Nevrátí vám přeložené PDF se stejným rozvržením. Model nemá pojem „zalomení stránky, které musí sedět se zdrojem“ nebo „buňka tabulky, která si musí zachovat šířku sloupce“.

Pro tuto oblast přímo používáme DeepL Document API. Je vytvořeno pro překlad souborů jako souborů, ne prózy vytažené ze souborů. DeepL zvládá:

• PDF (se zachováním rozvržení)
• DOCX, DOC
• PPTX
• XLSX

Dokument se nahraje do pipeline DeepL, na serveru se přeloží se zachovaným formátováním a vrátí se ve stejném formátu. Výsledek pak nahrajeme do našeho objektového úložiště a v chatu ho zpřístupníme jako stažitelnou přílohu.

Kolik to stojí a proč to netajíme

DeepL účtuje minimálně 50 000 znaků na dokument — zhruba jeden americký dolar za soubor v tarifu Pro, bez ohledu na to, zda má dokument jednu stránku, nebo třicet. Tuto cenu neseme my, místo abychom účtovali za soubor; projeví se ve využití překladu na dané schůzce jako účtované znaky, převedené na slovní jednotky, které odpovídají tomu, jak zbytek produktu vykazuje překladovou aktivitu.

DeepL jsme pro tuto oblast zvolili proto, že překlad souborů jako souborů je přesně úloha, pro kterou byl vytvořen — nesnažili jsme se vytvořit lepší. Opačně to neplatí — DeepL neprovozuje pipeline pro živý hlas takového druhu, jaký jsme postavili pro schůzky. Různé problémy, různé nástroje. Upřímná verze odpovědi na otázku „co pohání překlad v InterMIND“ je „správný engine pro každou pipeline“ — ne „náš engine všude“.

Jazyky, které tato pipeline pokrývá a hlas ne

Dokumentová pipeline dosahuje 30 jazyků, oproti 23 u hlasu. Mezi navíc patří: bulharština, řečtina, estonština, indonéština, litevština, lotyština, slovenština, slovinština. (Na tomto seznamu je i arabština a patří mezi jazyky navíc: je stažena z výběru pro reálný čas, dokud je kvalita jejího hlasu pod naší laťkou, a skóre jejích jednotlivých párů zůstávají veřejně na /benchmark — právě to číslo ji vrátí zpět. U hindštiny je asymetrie opačná — živě u hlasu je, u souborů zatím ne.)

Tato asymetrie je skutečná. Znamená, že francouzský účastník schůzky si může vyžádat smlouvu v PDF v estonštině, i když schůzku v estonštině poslouchat nemůže. Označujeme to ve výběru, místo abychom to zahladili jediným číslem. Zdůvodnění najdete v příspěvku o počtu jazyků.

Kde se pipeline potkávají

Čtyři pipeline neběží izolovaně. Místnost schůzky je místo, kde se dotýkají, a na švech záleží:

• Chatová zpráva s přílohou dokumentu spustí chatovou pipeline pro text a dokumentovou pipeline pro soubor. Účastník v jiném jazyce vidí zprávu přeloženou okamžitě a překlad přílohy mu dorazí asynchronně jako stažitelný soubor.
• Sdílená poznámka citující řádek přepisu překračuje hranici poznámky ↔ hlas. Přepis je to, co hlasová pipeline vytvořila pro jazyk odesílatele; překlad poznámky vytvoří pro každého posluchače kopii této citace v jazyce všech ostatních, se zachovaným uvedením zdroje.
• Přepis exportovaný po schůzce projde textovou pipeline ve stylu chatu přes celou konverzaci a vytvoří soubor pro každý jazyk, který si účastníci mohou stáhnout. Je to tatáž cesta kódu jako u překladu chatu, jen dávkově.

Výběr jazyka je jeden kus uživatelského rozhraní. Infrastruktura pod ním jsou čtyři pipeline, které spolu komunikují.

Co záměrně nezkoušíme

• Žádný „sjednocený překladový model“. Nestavíme jeden model, který by dělal hlas, chat, poznámky i dokumenty. Kompromis mezi latencí a věrností nemá vítěze. Používáme správný engine pro každou oblast.
• Žádné tiché přesměrování. Pokud souborová pipeline dnes neumí překládat do hindštiny, nepřepneme potichu na hlasový engine a nebudeme předstírat, že to fungovalo — výběr souborů tuto mezeru označí, místo aby ji skryl.
• Žádné „překládáme do 200 jazyků“. Náš engine vydává 24. Živé oblasti nabízejí 23, dokumenty 30 — a místo jednoho marketingově líbivého čísla je kvalita jednotlivých párů, která musí obstát před auditorem, zveřejněna na /benchmark, včetně slabších párů.

Vyzkoušejte si to sami

• Vyzkoušejte živé demo — spustí pipeline živého hlasu na váš zvuk, v kterémkoli z 23 jazyků produktu. Tatáž pipeline, která dává skóre na /benchmark.
• Podívejte se na benchmark — kvalita po párech a po měsících na skutečném provozu. Každý pár ve výběru, silný i slabý, s odkazem přímo na něj.
• Přečtěte si metodiku — co ta čísla jsou, co nejsou a kdo je rozhodčí.

Čtyři pipeline, čtyři enginy, jedna místnost schůzky. To je upřímná náhrada staré stránky how-it-works.

— Tým Mind.com

Zdroje: DeepL — podporované jazyky, DeepL — počítání využití a fakturace (minimum 50 000 znaků na soubor), FLORES-200; interní fakta o pipeline ověřena podle nasazeného kódu, zkontrolováno v srpnu 2026.