Як ми побудували real-time переклад голосу у Voicli

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Останні роки я багато працював із backend-розробкою, realtime-системами, WebSocket, Django Channels, Redis, Celery та AWS. Але Voicli почався не з бажання зробити ще один відеосервіс.

Проблема була значно простіша.

Є дуже багато сильних спеціалістів, які нормально читають документацію англійською, пишуть код, користуються Slack, Jira, GitHub, перекладачами та AI. Але коли доходить до live-розмови — співбесіди, дзвінка з клієнтом або міжнародною командою — все змінюється.

У тексті ти можеш подумати 20 секунд. У розмові — ні.

Треба одразу зрозуміти питання, сформулювати відповідь, підібрати правильні слова, не втратити контекст і ще й не виглядати так, ніби ти постійно зависаєш.

І в результаті людина може бути сильним backend engineer, designer, recruiter, sales specialist або founder, але просто не вийти на міжнародний ринок через рівень spoken English.

Саме цю проблему ми й вирішили спробувати прибрати.

Ідея була дуже проста

Ми хотіли зробити відеодзвінок, де кожна людина говорить своєю мовою.

Наприклад:

• я говорю українською;
• співрозмовник говорить англійською;
• я чую його українською;
• він чує мене англійською;
• паралельно можна бачити субтитри.

Без копіювання тексту в перекладач, без пауз між кожною реплікою, без окремого перекладача на дзвінку.

Фактично це звичайний meeting, але мовний бар’єр переноситься з людини на систему.

На словах усе звучить дуже просто, але на практиці ми дуже швидко зрозуміли, що сам переклад тексту — це далеко не найскладніша частина.

Чому просто «speech-to-text → translate → text-to-speech» недостатньо

Найочевидніший pipeline виглядає приблизно так:

microphone → speech recognition → translation → text-to-speech → listener

Здається, що достатньо підключити кілька API.

Але в real-time conversation одразу з’являється latency.

Припустимо:

• speech recognition займає 500–800 ms;
• переклад — ще кількасот мілісекунд;
• генерація голосу — ще час;
• плюс network latency;
• плюс доставка аудіо іншому учаснику.

І ось уже людина сказала фразу, а переклад приходить через дві-три секунди. Для перекладу відео це нормально. Для живої розмови — вже проблема.

Співрозмовник не розуміє, чи можна відповідати, перебиває переклад, система починає перекладати наступну репліку, а люди говорять одна поверх одної.

Тому головною проблемою для нас став не просто AI-переклад. Головною проблемою став turn-taking.

Коли людина закінчила говорити?

Для realtime voice translation це критичне питання. Якщо система починає перекладати занадто рано, вона може отримати щось на кшталт:

I think we should...

І перекласти це. А людина через пів секунди додає:

...not release this version yet.

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

точність ↔ швидкість

Ми експериментували з паузами, визначенням кінця репліки, buffering та різними правилами для того, коли дозволяти наступному перекладу починатися.

І чим більше ми це тестували, тим очевидніше ставало: realtime voice translation — це не просто задача NLP. Це задача взаємодії між людьми.

Ще одна проблема: що робити з оригінальним голосом

Є інша цікава UX-проблема.

Людина говорить японською. Ви чуєте:

спочатку японську фразу, а через секунду — англійський переклад.

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

Комусь комфортно чути оригінальну інтонацію, а комусь вона тільки заважає.

Архітектура

Основний backend Voicli побудований на:

• Django;
• Django REST Framework;
• Django Channels;
• Daphne;
• Celery;
• PostgreSQL;
• Redis.

Frontend:

• React;
• TypeScript;
• Vite.

WebRTC-інфраструктура для передачі аудіо та відео в реальному часі. Далі окремий AI pipeline займається speech processing, translation і voice generation.

Спрощено це виглядає так:

Browser → audio/video layer → speech processing → translation → voice generation → participant

При цьому є ще одна важлива проблема. У кожного слухача може бути своя мова.

Уявімо зустріч:

• українець;
• японець;
• француз;
• німець.

Українець говорить українською. А далі система повинна потенційно підготувати різні версії для різних учасників. Тобто логіка вже не:

1 speaker → 1 translation

а:

1 speaker → N listeners → N target languages

І тут уже починаються цікаві питання масштабування.

А що буде, якщо учасників не 2, а 100?

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

Але якщо в meeting умовно 50 або 100 людей і кожен може використовувати свою мову, кількість потенційних realtime operations дуже швидко росте. Тому доводиться думати не тільки про AI.

Потрібні:

• правильний routing аудіо;
• кешування там, де воно можливе;
• повторне використання однакових перекладів;
• контроль concurrent connections;
• backpressure;
• поведінка під час reconnect;
• graceful degradation.

Окремо ми проводили load testing із десятками одночасних користувачів, тому що реальний multi-user call дуже швидко показує проблеми, яких немає під час локального тесту на двох браузерах.

Найскладніше — зробити так, щоб користувач не думав про всю цю систему

Це, мабуть, головний висновок. Користувачу абсолютно не цікаво, скільки в тебе WebSocket connections або як працює TTS pipeline.

Він очікує:

я сказав фразу → інша людина мене зрозуміла.

Все.

І навіть маленькі технічні нюанси одразу стають UX-проблемами. Переклад затримався, людина почала говорити раніше, один учасник reconnect-нувся, змінилася мова, мікрофон почав передавати шум, оригінальний звук наклався на переклад.

І система повинна якось усе це пережити.

Навіщо це взагалі потрібно, якщо всі можуть просто вивчити англійську

Це питання ми теж чуємо. Але, на мою думку, тут є велика різниця між «знати англійську» і «вільно працювати англійською в real-time».

Людина може мати B1 або B2, може нормально читати документацію, переписуватися, пройти technical assessment. Але на live interview вона витрачає половину уваги не на технічну відповідь, а на мову. І роботодавець у результаті оцінює вже не тільки engineering skills. Він частково оцінює швидкість spoken English.

Для міжнародного найму це створює досить дивну ситуацію. Умовно є чудовий senior engineer з України, Польщі, Японії, Кореї чи Туреччини. І є компанія, якій потрібен саме його досвід. Але вони можуть навіть не почати працювати разом через те, що одна година live interview стає мовним stress test. Ми хочемо зробити так, щоб мова перестала бути настільки сильним фільтром. Не тільки для розробників, те саме стосується sales, recruiting, consulting, support, founders та міжнародних команд загалом.

Чи означає це, що англійську більше не потрібно вчити?

Ні. Я не думаю, що AI повинен замінити вивчення мов. Але технологія може змінити момент, коли людина отримує доступ до можливості. Зараз логіка часто така:

спочатку кілька років покращуй англійську → потім спробуй міжнародну роботу.

Можливо, вона може бути іншою:

починай працювати міжнародно зараз → паралельно покращуй мову.

Для мене це набагато цікавіша модель.

Що маємо зараз

Зараз Voicli — це web-based продукт для відеозустрічей із realtime перекладом.

Система підтримує понад 20 мов.

Можна використовувати:

• голосовий переклад;
• субтитри;
• оригінальний звук;
• оригінал разом із перекладом;
• різні мови для різних учасників.

Окремо ми поступово додаємо звичайні meeting features, тому що переклад не повинен існувати у вакуумі.

Зрештою користувачу потрібен не «AI translation demo».

Йому потрібен нормальний робочий дзвінок.

Що я зрозумів за час роботи над Voicli

Перше — realtime AI значно складніший за звичайний request/response AI.

Друге — latency часто важливіша за невелике покращення quality.

Третє — хороша модель ще не означає хороший продукт.

І четверте — мовний бар’єр досі набагато серйозніша проблема, ніж може здаватися людям, які вже вільно говорять англійською.

Для когось це просто невелика незручність, а для когось це межа між локальною зарплатою і міжнародною вакансією. Між локальним клієнтом і клієнтом із США, між «я не готовий до цього дзвінка» і нормальною розмовою зі спеціалістом на іншому кінці світу.

Саме це ми й намагаємося змінити.

Мені було б особливо цікаво почути думку DOU-спільноти.

Якби ви будували realtime voice translation для 50–100 учасників, де кожен потенційно може вибрати власну мову, який компонент системи ви б вважали найбільшим bottleneck?

І друге питання: чи бачили ви серед знайомих сильних спеціалістів, яким саме spoken English заважав вийти на міжнародні вакансії?