Wewnątrz czterech potoków tłumaczeń obsługujących InterMIND

Stara strona /product/overview/how-it-works na mind.com jest nieaktualna od kilku dużych wersji. Opisuje pojedynczy "silnik tłumaczeń" w taki sam sposób, jak strony większości dostawców — jedna duża strzałka od "mówisz" do "słyszą". Ten obraz był uproszczeniem już dwa lata temu. Dziś jest błędny.

Prawda jest taka, że InterMIND obsługuje cztery osobne potoki tłumaczeń, z których każdy rozwiązuje inny problem za pomocą innego silnika, innego budżetu opóźnień i innej ramy jakościowej. Współdzielą one wybór języka. Nie współdzielą silnika.

To jest zaktualizowana odpowiedź na pytanie "jak to działa".

Tekst towarzyszący: "Ile języków obsługujecie?" omawia to, co każdy potok obejmuje (23 / 23 / 30 / 17). Ten post omawia to, co każdy potok robi — i dlaczego jest czymś odrębnym.

Dlaczego "jeden silnik do wszystkiego" to kłamstwo

Platforma spotkań na żywo ma do wykonania co najmniej cztery zadania naraz, a te zadania ciągną w niekompatybilnych kierunkach:

1. Głos w czasie rzeczywistym — dźwięk na wejściu, przetłumaczony dźwięk na wyjściu, w czasie poniżej jednej sekundy, każdy widz w swoim własnym języku. Twardym ograniczeniem jest opóźnienie.
2. Tekst czatu w czasie rzeczywistym — krótkie wiadomości, szybko, z zachowaniem edycji, cytatów i struktury HTML.
3. Współdzielone notatki w czasie rzeczywistym — wspólne wpisywanie znak po znaku, z hierarchią strukturalną (listy, nagłówki, pola wyboru), która musi przetrwać tłumaczenie.
4. Asynchroniczne pliki dokumentów — 40-stronicowy plik PDF wrzucony na czat. Brak budżetu na opóźnienia. Twardym ograniczeniem jest wierność — formatowanie, tabele, numery stron, czcionki.

Można zbudować jedno gigantyczne wywołanie LLM, które próbuje wykonać wszystkie cztery zadania. Próbowaliśmy. Radzi sobie źle we wszystkich czterech. Budżet opóźnień dla głosu oznacza, że model nie może myśleć; budżet wierności dla dokumentów oznacza, że model musi myśleć. Edycja na czacie wymaga diff'a w języku widza; 40-stronicowy plik PDF wymaga zachowania formatowania, którego żaden model strumieniujący tokeny nie zapewnia.

Dlatego obsługujemy cztery. Oto każdy z nich.

Potok 1: Tłumaczenie głosu w czasie rzeczywistym

Problem: Jeden z uczestników mówi po francusku. Inny dołączył po niemiecku, trzeci w brazylijskiej odmianie języka portugalskiego, czwarty po japońsku. Każdy z nich musi słyszeć mówiącego w swoim własnym języku, we własnym uchu, z opóźnieniem na tyle krótkim, aby utrzymanie kontaktu wzrokowego było nadal możliwe.

Budżet: Poniżej sekundy end-to-end. Wszystko powyżej ~1,2 sekundy i rozmowa zostaje przerwana — ludzie zaczynają mówić po przetłumaczonym głosie, a spotkanie dryfuje w kierunku "przełączmy się po prostu na angielski".

Jak faktycznie przemieszcza się dźwięk

Kilka rzeczy, które warto nazwać wprost:

• ASR działa na serwerze mediów. Dźwięk mówiącego przesyłany jest przez WebRTC do naszego własnego silnika — Mind API w OVH we Francji — i tam jest rozpoznawany, na tym samym serwerze, który obsługuje połączenie; przeglądarka tylko wysyła dźwięk i otrzymuje z powrotem słowa. Brak zewnętrznego dostawcy rozpoznawania mowy i brak dodatkowego przeskoku (hop), zanim tłumaczenie może się rozpocząć. (Notatki głosowe na czacie są wyjątkiem: ich funkcja zamiany mowy na tekst działa na Azure AI Speech, usłudze mowy domyślnej bramy AI.)
• Tłumaczenie nie jest jednym rozwidleniem (fan-out). Silnik tłumaczy według języka docelowego obecnego w pokoju, a nie według widza: tłumaczenie na dany język rozpoczyna się, gdy pierwszy słuchacz poprosi o przetłumaczony strumień, trzech uczestników, którzy wybrali niemiecki, współdzieli jedno tłumaczenie na język niemiecki, a brak osób słuchających po arabsku oznacza, że nic nie jest tłumaczone na arabski. Dlatego spotkanie w czterech językach kosztuje tyle samo co spotkanie w czterdziestu językach, aż do momentu, w którym widać, kto faktycznie się zjawił — nigdy nie tłumaczymy na języki, w których nie słucha żaden uczestnik.
• Syntezowana mowa jest przypisana do widza. Każdy uczestnik otrzymuje własną przetłumaczoną ścieżkę dźwiękową, zmiksowaną z wideo pierwotnego mówiącego. Nie oglądają głównego "przetłumaczonego spotkania" — oglądają to samo spotkanie, z ich osobistym kanałem audio przetłumaczonym na wybrany język. Dlatego dwie osoby w tym samym fizycznym pokoju mogą podłączyć słuchawki i słyszeć różne języki.

Dlaczego to ma znaczenie, gdy spotkanie wymyka się spod kontroli

Podczas 60-minutowego połączenia z ośmioma językami różne rzeczy psują się w ciekawy sposób: połączenia WebSocket zostają zerwane, ASR czasowo błędnie transkrybuje nazwę własną, sieć jednego z uczestników staje się niestabilna. Powyższa architektura pozwala nam odizolować błędy: zacięcie dźwięku u jednego widza nie wpływa na pozostałych siedmiu, ponieważ silnik tłumaczeń w ogóle nie wyprodukował "tłumaczenia" w pierwszej kolejności — wyprodukował osiem, równolegle, i tylko ten uszkodzony musi zostać przywrócony.

Sam silnik jest nasz, hostowany na naszej własnej infrastrukturze. Nie kierujemy głosu w czasie rzeczywistym przez ogólnego przeznaczenia LLM-y firm trzecich. Budżet opóźnień je wyklucza; kwestia rezydencji danych wyklucza je dla podlegających regulacjom klientów, którym faktycznie zależy.

Co publikujemy na temat jakości głosu: /benchmark uruchamia produkcyjny potok głosu na zdaniach FLORES-200 dla każdej opublikowanej pary języków, co miesiąc. Sędzia jest znany (główny Gemini 3.7 Flash, zapasowy Claude Sonnet 5). Pełny rozkład — mediana, p10, p90, min, max, wielkość próby — znajduje się na stronie. Zobacz metodologię, aby dowiedzieć się, co te liczby mierzą, a czego nie.

Potok 2: Tłumaczenie czatu w czasie rzeczywistym

Problem: Każda wiadomość na czacie na spotkaniu, przetłumaczona dla każdego uczestnika na jego własny język, w momencie wysyłania. Plus edycje — a edycje muszą wyglądać jak edycje, a nie jak ponowne tłumaczenia.

Budżet: Szybko, ale nie poniżej sekundy. Wiadomość na czacie może potrzebować pół sekundy, aby pojawić się w innym języku, a nikomu to nie przeszkadza. To, na czym zależy ludziom, to czy tłumaczenie jest właściwe i czy edycje mają sens.

Co faktycznie robi potok czatu

Każda wiadomość przechodzi przez ten sam silnik tłumaczeń, którego używa potok głosu — ale z innym przetwarzaniem wstępnym i końcowym (pre- i post-processing):

• Struktura HTML jest zachowana. Czat obsługuje sformatowany tekst (akapity, listy, cytaty, pogrubienie, kursywa). Konwertujemy na zwykły tekst dla modelu, tłumaczymy, a następnie ponownie owijamy wynik w oryginalne tagi. Model nigdy nie widzi HTML-a — widzi czysty tekst.
• Cytaty są tłumaczone niezależnie. Jeśli odpowiadasz na wiadomość i ją cytujesz, blok [QUOTE]…[/QUOTE] oraz nowa treść są tłumaczone jako osobne jednostki, więc model nie może ich ze sobą pomylić.
• Długie wiadomości są dzielone. Dzielimy na granicach akapitów przy 1000 znaków na fragment. Każdy fragment to osobne wywołanie tłumaczenia. Nie podajemy modelowi 4000-znakowych powieści za jednym zamachem — tryby awarii (obcięcie, utracone akapity, cięcie w połowie zdania) są zbyt brzydkie.
• Tłumaczenie jest leniwe. Używamy IntersectionObserver: wiadomość jest tłumaczona dopiero wtedy, gdy przewinie się do widoku widza. Zmiana języka w długotrwałym kanale kiedyś odtwarzała każde wywołanie API tłumaczenia z historii. Teraz już nie.

Ciekawa część: edycje jako diffy

W wersji v1.2 zmieniliśmy sposób, w jaki edycje na czacie zachowują się dla widzów w innym języku. Stare zachowanie było: ktoś edytuje wiadomość, my tłumaczymy całość od nowa, ty widzisz nowy akapit i musisz zauważyć, co się zmieniło.

Nowe zachowanie:

1. Oryginalna wiadomość została już przetłumaczona na Twój język.
2. Gdy nadawca dokonuje edycji, ponownie tłumaczymy nową wersję.
3. Obliczamy diff między Twoim poprzednim tłumaczeniem a Twoim nowym tłumaczeniem, w Twoim języku.
4. Pokazujemy ten diff w tekście (inline) — w taki sam sposób, w jaki Git pokazuje Ci, co się zmieniło.

Więc gdy "review by Tuesday" zmienia się na "review by Thursday" w angielskim, Twój kolega czytający po hiszpańsku widzi martes → jueves podświetlone, a nie ponownie przetłumaczony akapit, który musi przeczytać od nowa.

Wymagało to traktowania potoku czatu jako stanowej (stateful) pamięci podręcznej per widz, a nie bezstanowego (stateless) punktu końcowego tłumaczenia na żądanie. Dokumenty i głos tego nie potrzebują. Czat tak.

Potok 3: Tłumaczenie współdzielonych notatek w czasie rzeczywistym

Problem: Host otwiera panel współdzielonych notatek i zaczyna pisać. Każdy uczestnik widzi notatki w swoim języku, znak po znaku, ze strukturą dokumentu — nagłówki, zagnieżdżone listy, listy kontrolne, bloki kodu — nienaruszoną.

Budżet: Taki sam jak czat (~pół sekundy), ale z dwoma dodatkowymi ograniczeniami:

• Rzecz, która jest tłumaczona, zmienia się w trakcie tłumaczenia. Host nadal pisze. Naiwny system, który tłumaczy "cały dokument" przy każdym naciśnięciu klawisza, powoduje migotanie i wypala budżet API. Tłumaczymy z granularnością zmienionej jednostki, a nie całego dokumentu.
• Struktura musi przetrwać. Jeśli poprosisz model tłumaczeniowy o przetłumaczenie blobu markdown z trzema zagnieżdżonymi listami, otrzymasz coś, co wygląda jak oryginał, ale z subtelnie spłaszczoną hierarchią, zmienioną numeracją elementów lub przesuniętym wcięciem. Nie pozwalamy modelowi zobaczyć całego blobu.

Czym potok notatek różni się od czatu

Zachowanie struktury to główna sprawa. Tłumaczymy każdy element listy niezależnie, a nie jako jeden dokument. Model widzi:

"Przegląd compliance — rezultaty Q2"

— a nie:

"# Plan projektu\n## Kwartał\n- Przegląd compliance — rezultaty Q2\n- Ocena dostawców\n - Dostawcy Tier 1..."

Opakowujący dokument — <ul>, nagłówki, wcięcia — jest przebudowywany po stronie klienta przy użyciu tej samej struktury, jaką miał oryginalny dokument, z każdym węzłem liścia (leaf node) zamienionym na jego tłumaczenie. Model nigdy nie dostaje możliwości "udoskonalenia" hierarchii.

Notatki również korzystają z tego samego modelu diff per widz, co edycje na czacie: jeśli host zmienia wiersz, widzowie w innych językach widzą zmienione słowa podświetlone, a nie nowy akapit.

Potok 4: Asynchroniczne tłumaczenie dokumentów

Problem: Ktoś wrzuca na czat 40-stronicowy plik PDF, dokument Word, prezentację PowerPoint lub arkusz Excel. Każdy uczestnik może poprosić o kopię w swoim języku. Przetłumaczony plik musi wyglądać jak oryginał — te same czcionki, te same tabele, te same numery stron, te same nagłówki, te same wykresy na swoich miejscach.

Budżet: Brak ograniczeń czasu rzeczywistego. Minuta jest w porządku. Dwie minuty są w porządku. Ograniczeniem jest wierność — jeśli przetłumaczony PDF nie wygląda jak oryginał, odbiorca nie będzie mu ufał.

Dlaczego ten potok nie współdzieli silnika z głosem

Ogólny LLM, nawet bardzo dobry, odda Ci przetłumaczony tekst dokumentu. Nie odda Ci przetłumaczonego PDF-a z tym samym układem. Model nie ma pojęcia o "podziale strony, który musi zachować zgodność ze źródłem" lub "komórce tabeli, która musi zachować szerokość kolumny".

Dla tej powierzchni używamy bezpośrednio DeepL Document API. Zostało ono stworzone specjalnie do tłumaczenia plików jako plików, a nie prozy wydobytej z plików. DeepL obsługuje:

• PDF (z zachowaniem układu)
• DOCX, DOC
• PPTX
• XLSX

Dokument jest przesyłany do potoku DeepL, tłumaczony po stronie serwera z nienaruszonym formatowaniem i zwracany w tym samym formacie. Następnie przesyłamy wynik do naszego magazynu obiektów i udostępniamy go z powrotem na czacie jako załącznik do pobrania.

Ile to kosztuje i dlaczego tego nie ukrywamy

DeepL nalicza opłatę za minimum 50 000 znaków za dokument — około jednego dolara amerykańskiego za plik w planie Pro, niezależnie od tego, czy dokument ma jedną stronę, czy trzydzieści. Pochłaniamy ten koszt, zamiast pobierać opłatę za każdy plik; pojawia się on w użyciu tłumaczenia na spotkaniu jako rozliczane znaki (billed characters), przeliczane na jednostki słów, które odpowiadają sposobowi, w jaki reszta produktu raportuje aktywność tłumaczeniową.

Wybraliśmy DeepL dla tej powierzchni, ponieważ tłumaczenie plików jako plików to dokładnie zadanie, do którego zostało stworzone — nie próbowaliśmy zbudować lepszego. W drugą stronę nie jest to prawdą — DeepL nie obsługuje potoku głosu na żywo takiego, jaki zbudowaliśmy dla spotkań. Różne problemy; różne narzędzia. Szczerą wersją tego, "co napędza tłumaczenie w InterMIND", jest "odpowiedni silnik dla każdego potoku" — a nie "nasz silnik wszędzie".

Języki, które obejmuje ten potok, a których nie obejmuje głos

Potok dokumentów dociera do 30 języków, w porównaniu do 23 dla głosu. Dodatkowe języki to: bułgarski, grecki, estoński, indonezyjski, litewski, łotewski, słowacki, słoweński. (Arabski również znajduje się na tej liście i jest jednym z dodatków: został wycofany z selektora w czasie rzeczywistym, podczas gdy jego jakość głosu jest poniżej naszego progu, a jego wyniki dla każdej pary pozostają publiczne na /benchmark — ta liczba to to, co sprowadzi go z powrotem. Asymetria działa w drugą stronę dla hindi — dostępne na żywo w głosie, ale jeszcze nie w plikach.)

Ta asymetria jest realna. Oznacza to, że francuski uczestnik spotkania może poprosić o plik PDF z umową w języku estońskim, mimo że nie może słuchać spotkania w języku estońskim. Oznaczamy to w selektorze zamiast wygładzać jednym numerem. Uzasadnienie znajduje się w poście o liczbie języków.

Gdzie potoki się spotykają

Cztery potoki nie działają w izolacji. Pokój spotkań to miejsce, w którym się one stykają, a łączenia mają znaczenie:

• Wiadomość na czacie z załącznikiem dokumentu uruchamia potok czatu dla tekstu i potok dokumentów dla pliku. Uczestnik w innym języku widzi wiadomość natychmiast przetłumaczoną, a tłumaczenie załącznika dociera asynchronicznie jako plik do pobrania.
• Współdzielona notatka, która cytuje wiersz transkrypcji łączy notatki ↔ głos. Transkrypcja to to, co potok głosu wyprodukował dla języka nadawcy; tłumaczenie notatki produkuje kopię tego cytatu dla każdego widza w języku wszystkich innych, z zachowaniem przypisania źródła.
• Transkrypcja wyeksportowana po spotkaniu przechodzi przez potok tekstu w stylu czatu w obrębie całej konwersacji, produkując plik dla każdego języka, który uczestnicy mogą pobrać. Jest to ta sama ścieżka kodu, co tłumaczenie czatu, tylko w przetwarzaniu wsadowym (batched).

Selektor języka to jeden element interfejsu. Infrastruktura pod spodem to cztery potoki, które ze sobą rozmawiają.

Czego celowo nie próbujemy

• Brak "ujednoliconego modelu tłumaczeń". Nie budujemy jednego modelu, który robi głos, czat, notatki i dokumenty. Kompromis między opóźnieniem a wiernością nie ma zwycięzcy. Używamy odpowiedniego silnika dla każdej powierzchni.
• Brak cichego przekierowywania. Jeśli potok plików nie może dziś przetłumaczyć na hindi, nie cofamy się po cichu do silnika głosu i nie udajemy, że zadziałało — selektor plików oznacza lukę, zamiast ją ukrywać.
• Brak "tłumaczymy na 200 języków". Nasz silnik emituje 24. Powierzchnie na żywo dostarczają 23, dokumenty 30 — a zamiast jednego przyjaznego dla marketingu numeru, jakość dla każdej pary, która musi zastać przed audytorem, jest publikowana na /benchmark, łącznie ze słabszymi parami.

Wypróbuj to sam

• Wypróbuj demo na żywo — uruchamia potok głosu na żywo na Twoim dźwięku, w jednym z 23 języków produktu. Ten sam potok, który zdobywa wyniki na /benchmark.
• Zobacz benchmark — jakość dla każdej pary, dla każdego miesiąca na prawdziwym ruchu. Każda para w selektorze, mocna czy słaba, z możliwością bezpośredniego linkowania (deep-linkable).
• Przeczytaj metodologię — czym są te liczby, czym nie są, kto jest sędzią.

Cztery potoki, cztery silniki, jeden pokój spotkań. To jest szczere zastępstwo dla starej strony how-it-works.

— Zespół Mind.com

Źródła: DeepL — obsługiwane języki, DeepL — liczba użycia i rozliczenia (minimum 50 000 znaków na plik), FLORES-200; wewnętrzne fakty o potokach zweryfikowane względem wysłanego kodu, sprawdzone w sierpniu 2026 r.