Wewnątrz czterech potoków tłumaczenia, na których działa InterMIND

Stara strona /product/overview/how-it-works w mind.com jest nieaktualna o kilka dużych wydań. Opisuje jeden „silnik tłumaczeniowy” tak jak większość stron dostawców: jedna wielka strzałka od „ty mówisz” do „oni słyszą”. Dwa lata temu ten obraz był już uproszczeniem. Dziś jest błędny.

W rzeczywistości InterMIND uruchamia cztery oddzielne potoki tłumaczenia. Każdy rozwiązuje inny problem, na innym silniku, z innym budżetem opóźnień i innym zakresem jakości. Mają wspólny selektor języka, ale nie mają wspólnego silnika.

To zaktualizowana odpowiedź na pytanie „jak to działa”.

Tekst towarzyszący: „Ile języków obsługujecie?” opisuje, co każdy potok obejmuje (23 / 23 / 30 / 17). Ten wpis opisuje, co każdy potok robi i dlaczego jest osobną rzeczą.

Dlaczego „jeden silnik do wszystkiego” to mit

Platforma do spotkań na żywo ma co najmniej cztery zadania do wykonania jednocześnie, a wymagania te ciągną w niezgodnych kierunkach:

1. Głos w czasie rzeczywistym: dźwięk wchodzi, a przetłumaczony dźwięk wychodzi, gdy mówca jeszcze mówi, a każdy widz słyszy go w swoim języku. Najtrudniejszym 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ólne notatki w czasie rzeczywistym: współdzielone pisanie znak po znaku, ze strukturalną hierarchią (listy, nagłówki, pola wyboru), która musi przetrwać tłumaczenie.
4. Asynchroniczne pliki dokumentów: 40-stronicowy PDF wrzucony na czat. Nie ma budżetu opóźnień. Najtrudniejszym ograniczeniem jest wierność: formatowanie, tabele, numery stron, krój pisma.

Można zbudować jedno gigantyczne wywołanie LLM, które próbuje zrobić wszystkie cztery rzeczy. Próbowaliśmy. Wychodzi słabo we wszystkich czterech. Budżet opóźnień dla głosu oznacza, że model nie może „myśleć”, a budżet wierności dla dokumentów oznacza, że musi. Edycja na czacie wymaga różnicy (diffu) w języku widza, a 40-stronicowy PDF wymaga zachowania formatu, którego nie daje żaden model strumieniujący tokeny.

Dlatego uruchamiamy cztery. Oto każdy z nich.

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

Problem: Jeden uczestnik mówi po francusku. Drugi dołączył po niemiecku, trzeci po portugalsku brazylijskim, czwarty po japońsku. Każdy musi słyszeć mówcę we własnym języku, we własnym uchu, z opóźnieniem na tyle krótkim, by dało się utrzymać kontakt wzrokowy.

Budżet: słuchacz nigdy nie może na nic czekać. Gdy przetłumaczona mowa spóźnia się na tyle, że ludzie zaczynają mówić ponad nią, spotkanie zaczyna dryfować w stronę „przejdźmy po prostu na angielski”.

Jak naprawdę płynie dźwięk

Kilka rzeczy warto nazwać wprost:

• ASR działa na serwerze mediów. Dźwięk mówcy płynie przez WebRTC do naszego własnego silnika, czyli Mind API w OVH we Francji, i jest tam rozpoznawany, na tym samym serwerze, który obsługuje rozmowę; przeglądarka tylko wysyła dźwięk i odbiera słowa z powrotem. Nie ma osobnego dostawcy rozpoznawania mowy ani dodatkowego przeskoku, zanim zacznie się tłumaczenie. (Wyjątkiem są wiadomości głosowe na czacie: ich zamiana mowy na tekst działa na Azure AI Speech, usłudze mowy domyślnej bramy AI.)
• Tłumaczenie to nie jedno rozgałęzienie. Silnik tłumaczy na każdy język docelowy obecny w pokoju, a nie na każdego widza: tłumaczenie na dany język rozpoczyna się, gdy pierwszy słuchacz w tym języku poprosi o przetłumaczony strumień, trzech uczestników, którzy wybrali niemiecki, korzysta z jednego niemieckiego tłumaczenia, a jeśli nikt nie słucha po arabsku, nic nie jest tłumaczone na arabski. Dlatego spotkanie w czterech językach kosztuje tyle samo co spotkanie w czterdziestu, jeśli liczyć tylko języki, które faktycznie się pojawiły: nigdy nie tłumaczymy na języki, w których nikt nie słucha.
• Mowa syntetyczna jest przypisana do widza. Każdy uczestnik dostaje własną przetłumaczoną ścieżkę audio, zmiksowaną z oryginalnym obrazem mówcy. Nie ogląda jednego „przetłumaczonego spotkania” głównego, tylko to samo spotkanie z osobistym kanałem audio przetłumaczonym na wybrany język. Dlatego dwie osoby w tym samym fizycznym pomieszczeniu mogą założyć słuchawki i słyszeć różne języki.

Dlaczego to ma znaczenie, gdy spotkanie idzie źle

W 60-minutowej rozmowie w ośmiu językach psuje się różne rzeczy: zrywają się połączenia WebSocket, ASR chwilowo błędnie rozpoznaje nazwę własną, sieć jednego uczestnika zaczyna się chwiać. Opisana architektura pozwala izolować awarie: zakłócenia dźwięku u jednego widza nie wpływają na pozostałą siódemkę, bo silnik tłumaczenia nigdy nie tworzył „tego tłumaczenia”, tylko osiem równoległych, i odzyskać sprawność musi tylko to dotknięte problemem.

Sam silnik jest nasz i działa na naszej własnej infrastrukturze. Nie kierujemy głosu w czasie rzeczywistym przez zewnętrzne LLM ogólnego przeznaczenia. Wyklucza je budżet opóźnień, a dla klientów z regulowanych branż, którym naprawdę na tym zależy, wyklucza je także rezydencja danych.

Co publikujemy o jakości głosu: /benchmark co miesiąc uruchamia produkcyjny potok głosowy na zdaniach FLORES-200 dla każdej opublikowanej pary językowej. Sędzia jest wskazany z nazwy (Gemini 3.7 Flash jako główny, Claude Sonnet 5 jako zapasowy). Pełny rozkład (mediana, p10, p90, minimum, maksimum, liczebność próby) znajdziesz na stronie. W metodologii opisujemy, co te liczby mierzą, a czego nie.

Potok 2: Tłumaczenie czatu w czasie rzeczywistym

Problem: Każda wiadomość na czacie w trakcie spotkania ma być tłumaczona dla każdego uczestnika na jego język, w chwili wysłania. Do tego edycje, które mają wyglądać jak edycje, a nie jak ponowne tłumaczenia.

Budżet: luźniejszy niż dla głosu. Wiadomość na czacie może pojawić się w innym języku z chwilowym opóźnieniem i nikomu to nie przeszkadza. Ludzi obchodzi, czy tłumaczenie jest poprawne i czy edycje mają sens.

Co faktycznie robi potok czatu

Każda wiadomość przechodzi przez ten sam silnik tłumaczeniowy co potok głosowy, ale z innym przetwarzaniem wstępnym i końcowym:

• Struktura HTML jest zachowana. Czat obsługuje tekst sformatowany (akapity, listy, cytaty, pogrubienie, kursywę). Zamieniamy go na zwykły tekst dla modelu, tłumaczymy, a potem opakowujemy wynik z powrotem w oryginalne znaczniki. Model nigdy nie widzi HTML, widzi czystą prozę.
• Cytaty są tłumaczone niezależnie. Jeśli odpowiadasz na wiadomość i ją cytujesz, blok [QUOTE]…[/QUOTE] i nowa treść są tłumaczone jako osobne jednostki, żeby model nie mylił jednego z drugim.
• Długie wiadomości są dzielone. Dzielimy je na granicach akapitów, po 1000 znaków na fragment. Każdy fragment to osobne wywołanie tłumaczenia. Nie podajemy modelowi 4000-znakowych powieści naraz, bo skutki uboczne (obcinanie, gubienie akapitów, ucięcia w pół zdania) są zbyt paskudne.
• Tłumaczenie jest leniwe. Używamy IntersectionObservera: wiadomość jest tłumaczona dopiero wtedy, gdy przewinie się do widocznego obszaru widza. Przełączenie języka w długo działającym kanale kiedyś odtwarzało z historii każde wywołanie API tłumaczenia. Teraz już nie.

Ciekawa część: edycje jako różnice

W wersji 1.2 zmieniliśmy zachowanie edycji czatu dla widzów w innym języku. Dawniej wyglądało to tak: ktoś edytuje wiadomość, tłumaczymy całość od nowa, a ty widzisz świeży akapit i sam musisz wypatrzyć, co się zmieniło.

Nowe zachowanie:

1. Oryginalna wiadomość była już przetłumaczona na twój język.
2. Gdy nadawca ją edytuje, tłumaczymy ponownie jej nową wersję.
3. Obliczamy różnicę między twoim poprzednim tłumaczeniem a twoim nowym tłumaczeniem, w twoim języku.
4. Pokazujemy tę różnicę w tekście, tak jak Git pokazuje, co się zmieniło.

Gdy więc po angielsku „review by Tuesday” zmienia się w „review by Thursday”, hiszpańskojęzyczny kolega widzi podświetlone martes → jueves, a nie przetłumaczony od nowa akapit, który musiałby czytać jeszcze raz.

Wymagało to potraktowania potoku czatu jako stanowej pamięci podręcznej dla każdego widza, a nie bezstanowego punktu końcowego „przetłumacz na żądanie”. Dokumenty i głos tego nie potrzebują. Czat tak.

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

Problem: Gospodarz otwiera panel wspólnych notatek i zaczyna pisać. Każdy uczestnik widzi notatki w swoim języku, znak po znaku, z nienaruszoną strukturą dokumentu: nagłówkami, zagnieżdżonymi listami, listami zadań i blokami kodu.

Budżet: Taki sam jak dla czatu, ale z dwoma dodatkowymi ograniczeniami:

• Tłumaczona rzecz zmienia się w trakcie tłumaczenia. Gospodarz wciąż pisze. Naiwny system, który przy każdym naciśnięciu klawisza tłumaczy „cały dokument”, powoduje migotanie i spala budżet API. My tłumaczymy na poziomie zmienionej jednostki, a nie całego dokumentu.
• Struktura musi przetrwać. Jeśli poprosisz model tłumaczeniowy o przetłumaczenie bloku markdown z trzema zagnieżdżonymi listami, dostaniesz coś, co wygląda jak oryginał, ale z subtelnie spłaszczoną hierarchią, przenumerowanymi pozycjami albo przesuniętymi wcięciami. Nie pozwalamy modelowi zobaczyć całego bloku.

Czym potok notatek różni się od czatu

Najważniejsze jest zachowanie struktury. Tłumaczymy każdą pozycję listy niezależnie, a nie jako jeden dokument. Model widzi:

„Przegląd zgodności — rezultaty Q2”

a nie:

„# Plan projektu\n## Kwartał\n- Przegląd zgodności — rezultaty Q2\n- Ocena dostawców\n - Dostawcy tier 1...”

Dokument otaczający, czyli <ul>, nagłówki i wcięcia, jest odbudowywany po stronie klienta według tej samej struktury, jaką miał oryginał, z każdym liściem podmienionym na jego tłumaczenie. Model nigdy nie dostaje okazji, by „poprawić” hierarchię.

Notatki używają też tego samego modelu różnic dla każdego widza co edycje czatu: jeśli gospodarz zmieni wiersz, widzowie w innych językach widzą podświetlone zmienione słowa, a nie świeży akapit.

Potok 4: Asynchroniczne tłumaczenie dokumentów

Problem: Ktoś wrzuca na czat 40-stronicowy PDF, dokument Worda, prezentację PowerPoint albo arkusz Excela. 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 ograniczenia czasu rzeczywistego. Minuta jest w porządku. Dwie minuty też. Ograniczeniem jest wierność: jeśli przetłumaczony PDF nie wygląda jak oryginał, odbiorca mu nie zaufa.

Dlaczego ten potok nie 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 „podziału strony, który ma się zgadzać ze źródłem” ani „komórki tabeli, która ma zachować szerokość kolumny”.

Dla tej powierzchni używamy bezpośrednio DeepL Document API. Zostało zaprojektowane do tłumaczenia plików jako plików, a nie prozy wyciągniętej 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 wgrywamy wynik do naszego magazynu obiektów i udostępniamy go na czacie jako załącznik do pobrania.

Ile to kosztuje i dlaczego tego nie ukrywamy

DeepL nalicza minimum 50 000 znaków na dokument, czyli około jednego dolara amerykańskiego za plik w planie Pro, niezależnie od tego, czy dokument ma jedną stronę, czy trzydzieści. Ten koszt pokrywamy sami zamiast naliczać opłatę za plik; widać go w zużyciu tłumaczeń spotkania jako rozliczone znaki, przeliczone na jednostki słowne zgodne ze sposobem, w jaki reszta produktu raportuje aktywność tłumaczeniową.

Wybraliśmy DeepL dla tej powierzchni, bo tłumaczenie plików jako plików to dokładnie to, do czego został stworzony, a my nie próbowaliśmy zbudować lepszego. W drugą stronę już tak nie jest: DeepL nie prowadzi potoku głosowego na żywo takiego, jaki zbudowaliśmy dla spotkań. Inne problemy, inne narzędzia. Uczciwa odpowiedź na pytanie „co napędza tłumaczenie w InterMIND” brzmi: „odpowiedni silnik dla każdego potoku”, a nie „nasz silnik wszędzie”.

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

Potok dokumentów obsługuje 30 języków, wobec 23 dla głosu. Dodatkowe to między innymi: bułgarski, grecki, estoński, indonezyjski, litewski, łotewski, słowacki, słoweński. (Arabski także jest na tej liście i należy do tych dodatkowych: jest wycofany z selektora czasu rzeczywistego, dopóki jakość jego głosu jest poniżej naszego progu, a jego wyniki dla poszczególnych par pozostają publiczne na /benchmark, i to ta liczba go przywróci. W przypadku hindi asymetria działa w drugą stronę: jest dostępny dla głosu, ale jeszcze nie dla plików.)

Ta asymetria jest prawdziwa. Oznacza, że francuski uczestnik spotkania może poprosić o umowę w PDF po estońsku, choć nie może słuchać spotkania po estońsku. Oznaczamy to w selektorze, zamiast wygładzać jedną liczbą. Uzasadnienie znajdziesz we wpisie o liczbie języków.

Gdzie potoki się spotykają

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

• Wiadomość na czacie z załączonym dokumentem uruchamia potok czatu dla tekstu i potok dokumentów dla pliku. Uczestnik w innym języku widzi wiadomość przetłumaczoną od razu, a tłumaczenie załącznika dociera asynchronicznie jako plik do pobrania.
• Wspólna notatka cytująca wiersz transkrypcji łączy notatki z głosem. Transkrypcja to to, co potok głosowy wytworzył dla języka nadawcy; tłumaczenie notatki tworzy dla każdego widza kopię tego cytatu w języku wszystkich pozostałych, z zachowaniem wskazania źródła.
• Transkrypcja wyeksportowana po spotkaniu przechodzi przez potok tekstowy w stylu czatu obejmujący całą rozmowę i tworzy plik dla każdego języka, który uczestnicy mogą pobrać. To ta sama ścieżka kodu co tłumaczenie czatu, tylko wsadowa.

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

Czego świadomie nie próbujemy

• Żadnego „zunifikowanego modelu tłumaczenia”. Nie budujemy jednego modelu, który robi głos, czat, notatki i dokumenty. W kompromisie między opóźnieniem a wiernością nie ma zwycięzcy. Używamy odpowiedniego silnika dla każdej powierzchni.
• Żadnego cichego przekierowywania. Jeśli potok plików nie potrafi dziś tłumaczyć na hindi, nie przełączamy się po cichu na silnik głosowy, udając, że zadziałało. Selektor plików zaznacza tę lukę zamiast ją ukrywać.
• Żadnego „tłumaczymy na 200 języków”. Nasz silnik obsługuje 24. Powierzchnie na żywo mają 23, dokumenty 30, a zamiast jednej marketingowej liczby jakość dla poszczególnych par, która musi się obronić przed audytorem, jest publikowana na /benchmark, łącznie ze słabszymi parami.

Wypróbuj sam

• Wypróbuj demo na żywo: uruchamia potok głosu na żywo na twoim dźwięku, w dowolnym z 23 języków produktu. Ten sam potok, który zasila wyniki w /benchmark.
• Zobacz benchmark: jakość dla każdej pary i każdego miesiąca na prawdziwym ruchu. Każda para w selektorze, mocna czy słaba, z linkiem bezpośrednim.
• Przeczytaj metodologię: czym są te liczby, czym nie są i kim jest sędzia.

Cztery potoki, cztery silniki, jeden pokój spotkania. To uczciwy zamiennik starej strony how-it-works.

— Zespół Mind.com

Źródła: DeepL — obsługiwane języki, DeepL — liczenie zużycia i rozliczenia (minimum 50 000 znaków na plik), FLORES-200; wewnętrzne fakty o potokach zweryfikowane z wdrożonym kodem, sprawdzone w sierpniu 2026.