Зсередини: чотири конвеєри перекладу, що забезпечують роботу InterMIND

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ASR працює в браузері мовця, а не на центральному сервері. Ми використовуємо Mind SDK локально; це економить один round-trip і дає нам транскрипт мовою джерела з найменшою можливою затримкою ще до того, як переклад може розпочатися.
• Переклад — це не один fan-out. Ми тримаємо пул з'єднань WebSocket до нашого рушія перекладу, по одному на кожну цільову мову, присутню в кімнаті. Якщо троє учасників обрали німецьку, німецька користується одним з'єднанням. Якщо ніхто не обрав арабську, арабське з'єднання не відкривається. Пул скидає неактивні з'єднання через п'ять хвилин. Саме тому чотиримовна зустріч коштує стільки ж, скільки сорокамовна — аж до моменту, хто насправді з'явився: ми ніколи не перекладаємо мовами, які ніхто з учасників не слухає.
• Синтезоване мовлення — для кожного глядача окремо. Кожен учасник отримує власну перекладену звукову доріжку, зведену з відео оригінального мовця. Вони не дивляться на майстер-версію «перекладеної зустрічі» — вони дивляться ту саму зустріч, з особистим аудіоканалом, перекладеним обраною мовою. Саме тому двоє людей в одній фізичній кімнаті можуть увімкнути навушники і чути різні мови.

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

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

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

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

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

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

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

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

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

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

Цікаве: редагування як diff-и

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

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

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

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

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

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

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

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

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

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

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

"Compliance review — Q2 deliverables"

— а не:

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

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

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

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

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

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

Чому цей конвеєр не ділить рушій із голосом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Команда Mind.com

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