Внутрішній огляд чотирьох конвеєрів перекладу, на яких працює InterMIND

Стара сторінка /product/overview/how-it-works на сайті mind.com застаріла на кілька великих релізів. Вона описує єдиний «рушій перекладу», як це роблять сторінки більшості постачальників — одна велика стрілка від «ви говорите» до «вони чують». Ця картина була спрощенням ще два роки тому. Сьогодні вона є неправильною.

Правда полягає в тому, що InterMIND використовує чотири окремі конвеєри перекладу, кожен з яких вирішує іншу проблему за допомогою іншого рушія, іншого бюджету затримки та іншого запасу якості. Вони мають спільний селектор мов. Вони не мають спільного рушія.

Це оновлена відповідь на запитання «як це працює».

Супровідний матеріал: "Скільки мов ви підтримуєте?" розповідає, що охоплює кожен конвеєр (23 / 23 / 30 / 17). Цей допис розповідає, що кожен конвеєр робить — і чому він є самостійним утворенням.

Чому «один рушій для всього» — це брехня

Платформа для зустрічей у реальному часі має виконувати щонайменше чотири завдання одночасно, і вони тягнуть у несумісних напрямках:

1. Голос у реальному часі — вхідне аудіо, перекладене аудіо на виході, менше за секунду, кожен глядач своєю мовою. Жорстким обмеженням є затримка.
2. Текст чату у реальному часі — короткі повідомлення, швидко, зі збереженням редагувань, цитат та HTML-структури.
3. Спільні нотатки у реальному часі — спільний набір символів за символом, зі структурною ієрархією (списки, заголовки, прапорці), яка має пережити переклад.
4. Асинхронні файли документів — 40-сторінковий PDF, скинутий у чат. Без бюджету затримки. Жорстким обмеженням є точність — форматування, таблиці, номери сторінок, шрифт.

Можна створити один гігантський виклик LLM, який намагається робити все чотири. Ми пробували. Він погано справляється з усіма чотирма. Бюджет затримки для голосу означає, що модель не може думати; бюджет точності для документів означає, що модель повинна це робити. Редагування в чаті потребує diff мовою глядача; 40-сторінковий PDF потребує збереження форматування, яке не дасть жодна модель із потоковою передачею токенів.

Тому ми використовуємо чотири. Ось кожен з них.

Конвеєр 1: Голосовий переклад у реальному часі

Проблема: Один учасник говорить французькою. Інший приєднався німецькою, третій — бразильською португальською, четвертий — японською. Кожен з них повинен чути мовця своєю мовою, у своїх навушниках, із затримкою, достатньо короткою, щоб зберегти зоровий контакт.

Бюджет: Менше секунди від початку до кінця. Будь-що більше ~1,2 секунди зриває розмову — люди починають говорити поверх перекладу, і зустріч сповзає до «давайте просто перейдемо на англійську».

Як насправді рухається аудіо

Кілька речей, які варто назвати прямо:

• ASR працює на медіасервері. Аудіо мовця передається через WebRTC до нашого власного рушія — Mind API на OVH, Франція — і розпізнається там, на тому ж сервері, що обслуговує дзвінок; браузер лише надсилає аудіо і отримує слова назад. Немає окремого постачальника розпізнавання мовлення і немає зайвого переходу до того, як може початися переклад. (Голосові нотатки в чаті є винятком: їхнє перетворення мовлення на текст відбувається на Azure AI Speech, сервісі мовлення стандартного AI шлюзу.)
• Переклад — це не одне розгалуження. Рушій перекладає для кожної цільової мови, присутньої в кімнаті, а не для кожного глядача: переклад мовою починається, коли перший слухач у ній запитує перекладений потік, троє учасників, які обрали німецьку, ділять один німецький переклад, і якщо ніхто не слухає арабською, нічого не перекладається арабською. Ось чому зустріч чотирма мовами коштує стільки ж, скільки зустріч сорока мовами, аж до моменту, хто насправді з'явився — ми ніколи не перекладаємо мовами, які не слухає жоден учасник.
• Синтезоване мовлення є індивідуальним для кожного глядача. Кожен учасник отримує власну перекладену аудіодоріжку, змішану з відео оригінального мовця. Вони не дивляться на головний «перекладений мітинг» — вони дивляться ту саму зустріч, з їхнім особистим аудіоканалом, перекладеним обраною мовою. Ось чому двоє людей в одній фізичній кімнаті можуть підключити навушники і чути різні мови.

Чому це важливо, коли зустріч йде не за планом

У 60-хвилинному дзвінку з вісьмома мовами речі ламаються цікавими способами: WebSockets відключаються, ASR тимчасково неправильно транскрибує власну назву, мережа одного з учасників стає нестабільною. Вищезгадана архітектура дозволяє нам ізолювати збої: збої аудіо одного глядача не впливають на інших семеро, оскільки рушій перекладу ніколи не створює «переклад» у першу чергу — він створює вісім паралельно, і лише пошкоджений потік має відновитися.

Сам рушій наш, розміщений на нашій власній інфраструктурі. Ми не маршрутизуємо голос у реальному часі через загальнозначущі LLM сторонніх виробників. Бюджет затримки виключає їх; історія резидентності даних виключає їх для регульованих клієнтів, яким це дійсно важливо.

Що ми публікуємо щодо якості голосу: /benchmark запускає робочий конвеєр голосу на реченнях FLORES-200 для кожної опублікованої мовної пари щомісяця. Суддя названий (Gemini 3.7 Flash основний, Claude Sonnet 5 резервний). Повний розподіл — медіана, p10, p90, мінімум, максимум, розмір вибірки — розміщено на сторінці. Дивіться методологію, щоб дізнатися, що ці числа вимірюють, а що ні.

Конвеєр 2: Переклад чату в реальному часі

Проблема: Кожне повідомлення в чаті під час зустрічі, перекладене для кожного учасника його мовою, щойно воно надіслане. Плюс редагування — і редагування мають виглядати як редагування, а не як повторні переклади.

Бюджет: Швидко, але не менше секунди. Повідомлення в чаті може з'явитися іншою мовою за пів секунди, і ніхто не зверне уваги. Людей хвилює, чи переклад правильний і чи мають зміст редагування.

Що насправді робить конвеєр чату

Кожне повідомлення проходить через той самий рушій перекладу, що використовує голосовий конвеєр — але з іншою попередньою та фінальною обробкою:

• HTML-структура зберігається. Чат підтримує форматований текст (абзаци, списки, цитати, жирний шрифт, курсив). Ми перетворюємо його на простий текст для моделі, перекладаємо, а потім знову обертаємо результат у вихідні теги. Модель ніколи не бачить HTML — вона бачить чистий текст.
• Цитати перекладаються незалежно. Якщо ви відповідаєте на повідомлення і цитуєте його, блок [QUOTE]…[/QUOTE] та новий вміст перекладаються як окремі одиниці, тому модель не може їх переплутати.
• Довгі повідомлення розбиваються на частини. Ми розбиваємо по межах абзаців на 1000 символів на частину. Кожна частина — це окремий виклик перекладу. Ми не завантажуємо моделі романи на 4000 символів за один раз — режими збоїв (обрізання, втрачені абзаци, переривання на пів речення) надто потворні.
• Переклад є лінивим. Ми використовуємо IntersectionObserver: повідомлення перекладається лише тоді, коли воно прокручується у вікно перегляду глядача. Раніше зміна мови в довготривалому каналі призводила до повторного відтворення кожного виклику API перекладу з історії. Тепер цього не відбувається.

Цікава частина: редагування як diff

У версії v1.2 ми змінили поведінку редагувань чату для глядачів іншою мовою. Стара поведінка була такою: хтось редагує повідомлення, ми перекладаємо все знову, ви бачите новий абзац і повинні самі помітити, що змінилося.

Нова поведінка:

1. Оригінальне повідомлення вже було перекладено вашою мовою.
2. Коли відправник редагує, ми знову перекладаємо нову версію.
3. Ми обчислюємо diff між вашим попереднім перекладом та вашим новим перекладом вашою мовою.
4. Ми показуємо цей diff інлайн — так само, як Git показує вам, що змінилося.

Отже, коли «review by Tuesday» змінюється на «review by Thursday» англійською, ваш колега, який читає іспанською, бачить виділеним martes → jueves, а не повторно перекладений абзац, який йому доведеться перечитати.

Це потребувало ставлення до конвеєра чату як до кешу зі збереженням стану (stateful) для кожного глядача, а не як до stateless-ендпоінту перекладу за запитом. Документам та голосу це не потрібно. Чату — так.

Конвеєр 3: Переклад спільних нотаток у реальному часі

Проблема: Ведучий відкриває панель спільних нотаток і починає друкувати. Кожен учасник бачить нотатки своєю мовою, символ за символом, зі збереженням структури документа — заголовків, вкладених списків, чек-листів, блоків коду.

Бюджет: Як у чаті (~пів секунди), але з двома додатковими обмеженнями:

• Річ, що перекладається, змінюється під час перекладу. Ведучий все ще друкує. Наївна система, яка перекладає «весь документ» при кожному натисканні клавіші, виробляє мерехтіння і спалює бюджет API. Ми перекладаємо з гранулярністю зміненої одиниці, а не всього документа.
• Структура має вижити. Якщо ви попросите модель перекладу перекласти markdown-блок із трьома вкладеними списками, ви отримаєте щось, що виглядає як оригінал, але з ледь помітно сплощеною ієрархією, перенумерованими елементами або зміщеним відступом. Ми не дозволяємо моделі бачити весь блок.

Як конвеєр нотаток відрізняється від чату

Збереження структури — це головне. Ми перекладаємо кожен елемент списку незалежно, а не як один документ. Модель бачить:

«Огляд комплаєнсу — результати Q2»

— а не:

"# План проєкту\n## Квартал\n- Огляд комплаєнсу — результати Q2\n- Оцінка постачальників\n - Постачальники 1-го рівня..."

Документ-обгортка — <ul>, заголовки, відступи — перебудовується на стороні клієнта з використанням тієї ж структури, яку мав оригінальний документ, де кожен листовий вузол замінено на його переклад. Модель ніколи не може «покращити» ієрархію.

Нотатки також використовують ту саму модель diff для кожного глядача, що й редагування чату: якщо ведучий змінює рядок, глядачі іншими мовами бачать змінені слова виділеними, а не новий абзац.

Конвеєр 4: Асинхронний переклад документів

Проблема: Хтось скидає 40-сторінковий PDF, документ Word, презентацію PowerPoint або таблицю Excel у чат. Кожен учасник може надіслати запит на копію своєю мовою. Перекладений файл має виглядати як оригінал — ті ж шрифти, ті ж таблиці, ті ж номери сторінок, ті ж заголовки, ті ж діаграми на своїх місцях.

Бюджет: Без обмежень у реальному часі. Хвилина — нормально. Дві хвилини — нормально. Обмеженням є точність — якщо перекладений PDF не виглядає як оригінал, отримувач не довірятиме йому.

Чому цей конвеєр не має спільного рушія з голосом

Загальна LLM, навіть дуже хороша, поверне вам перекладений текст документа. Вона не поверне вам перекладений PDF з тим самим макетом. Модель не має поняття «розрив сторінки, який має вирівнятися з джерелом» або «комірка таблиці, яка має зберегти ширину стовпця».

Для цієї поверхні ми використовуємо DeepL Document API безпосередньо. Він спеціально створений для перекладу файлів як файлів, а не тексту, витягнутого з файлів. DeepL обробляє:

• PDF (із збереженням макета)
• DOCX, DOC
• PPTX
• XLSX

Документ завантажується у конвеєр DeepL, перекладається на сервері зі збереженим форматуванням і повертається в тому самому форматі. Потім ми завантажуємо результат у наше об'єктне сховище та повертаємо його в чат як вкладення, доступне для завантаження.

Скільки це коштує і чому ми це не приховуємо

DeepL виставляє рахунок за мінімум 50 000 символів на документ — приблизно один долар США за файл на тарифі Pro, незалежно від того, чи документ має одну сторінку, чи тридцять. Ми беремо ці витрати на себе, замість того, щоб стягувати плату за файл; вони відображаються у використанні перекладу на зустрічі як оплачені символи, перетворені на одиниці слів, які відповідають способу, яким решта продукту звітує про активність перекладу.

Ми обрали DeepL для цієї поверхні, оскільки переклад файлів як файлів — це саме та робота, для якої він був створений — ми не намагалися створити кращий. Але не навпаки — DeepL не запускає конвеєр живого голосу того типу, який ми створили для зустрічей. Різні проблеми; різні інструменти. Чесна версія того, «що живить переклад InterMIND» — це «правильний рушій для кожного конвеєра» — а не «наш рушій скрізь».

Мови, які охоплює цей конвеєр, а голос — ні

Документний конвеєр охоплює 30 мов, проти 23 для голосу. Додаткові включають: болгарську, грецьку, естонську, індонезійську, литовську, латиську, словацьку, словенську. (Арабська також у цьому списку, і вона є однією з додаткових: вона виведена з селектора в реальному часі, поки її голосова якість нижча за наші стандарт, а її оцінки за парами залишаються публічними на /benchmark — саме це число поверне її. Асиметрія працює в інший бік для гінді — жива на голосі, але ще не на файлах.)

Ця асиметрія реальна. Це означає, що учасник зустрічі, який слухає французькою, може замовити PDF контракту естонською мовою, навіть якщо він не може слухати зустріч естонською. Ми позначаємо це у селекторі, замість того, щоб згладжувати це єдиним числом. Обґрунтування наведено у дописі про кількість мов.

Де конвеєри перетинаються

Чотири конвеєри не працюють в ізоляції. Кімната зустрічей — це місце, де вони стикаються, і шви мають значення:

• Повідомлення в чаті з вкладеним документом запускає конвеєр чату для тексту та конвеєр документів для файлу. Учасник іншою мовою бачить повідомлення перекладеним негайно, а переклад вкладення надходить асинхронно як файл для завантаження.
• Спільна нотатка, яка цитує рядок транскрипту перетинає нотатки ↔ голос. Транскрипт — це те, що голосовий конвеєр створив для мови відправника; переклад нотаток створює індивідуальну копію цієї цитати мовою кожного іншого учасника зі збереженням атрибуції джерела.
• Транскрипт, експортований після зустрічі, проходить через текстовий конвеєр у стилі чату для всієї розмови, створюючи файл для кожної мови, який учасники можуть завантажити. Це той самий шлях коду, що й переклад чату, просто пакетний.

Селектор мов — це один елемент UI. Інфраструктура під ним — це чотири конвеєри, які спілкуються між собою.

Що ми навмисно не намагаємося робити

• Жодної «єдиної моделі перекладу». Ми не будуємо одну модель, яка робить голос, чат, нотатки та документи. Компроміс між затримкою та точністю не має переможця. Ми використовуємо правильний рушій для кожної поверхні.
• Жодного тихого перенаправлення. Якщо сьогодні файловий конвеєр не може перекласти гінді, ми тихо не переходимо на голосовий рушій і не робимо вигляд, що це спрацювало — замість цього селектор файлів позначає прогалину, а не приховує її.
• Жодного «ми перекладаємо 200 мовами». Наш рушій видає 24. Живі поверхні поставляються з 23, документи — з 30 — і замість одного зручного для маркетингу числа, якість для кожної пари, яка має витримати перевірку аудитора, публікується на /benchmark, включаючи слабші пари.

Спробуйте самі

• Спробуйте живе демо — запускає конвеєр живого голосу для вашого аудіо, будь-якою з 23 мов продукту. Той самий конвеєр, який отримує оцінки на /benchmark.
• Перегляньте бенчмарк — якість для кожної пари, щомісяця на реальному трафіку. Кожна пара у селекторі, сильна чи слабка, з можливістю глибокого посилання.
• Прочитайте методологію — що таке ці числа, чого вони не враховують, хто є суддею.

Чотири конвеєри, чотири рушії, одна кімната зустрічей. Це чесна заміна старій сторінці how-it-works.

— Команда Mind.com

Джерела: DeepL — підтримувані мови, DeepL — підрахунок використання та виставлення рахунків (мінімум 50 000 символів на файл), FLORES-200; внутрішні факти про конвеєри перевірені щодо відправленого коду, перевірено серпень 2026.