Di dalam empat pipeline terjemahan yang menjalankan InterMIND

Halaman /product/overview/how-it-works lama di mind.com sudah ketinggalan zaman beberapa rilis utama. Halaman tersebut menggambarkan satu "mesin terjemahan" seperti kebanyakan halaman vendor — satu panah besar dari "Anda berbicara" ke "mereka mendengar." Gambaran itu sudah merupakan penyederhanaan dua tahun lalu. Hari ini, gambaran itu salah.

Faktanya, InterMIND menjalankan empat pipeline terjemahan terpisah, masing-masing menyelesaikan masalah yang berbeda dengan mesin yang berbeda, anggaran latensi yang berbeda, dan batasan kualitas yang berbeda. Mereka berbagi pemilih bahasa. Mereka tidak berbagi mesin.

Ini adalah jawaban yang diperbarui untuk "bagaimana cara kerjanya."

Tulisan pendamping: "Berapa banyak bahasa yang Anda dukung?" membahas apa yang dicakup oleh setiap pipeline (24 / 24 / 30 / 17). Postingan ini membahas apa yang dilakukan oleh setiap pipeline — dan mengapa setiap pipeline adalah hal yang unik.

Mengapa "satu mesin untuk semuanya" adalah sebuah kebohongan

Platform rapat langsung memiliki setidaknya empat tugas yang harus dikerjakan sekaligus, dan semuanya menarik ke arah yang tidak saling kompatibel:

1. Suara real-time — audio masuk, audio terjemahan keluar, dalam waktu kurang dari satu detik, setiap peserta dalam bahasa mereka sendiri. Batasan utamanya adalah latensi.
2. Teks chat real-time — pesan singkat, cepat, dengan suntingan, kutipan, dan struktur HTML yang tetap terjaga.
3. Catatan bersama real-time — pengetikan kolaboratif karakter demi karakter, dengan hierarki struktural (daftar, judul, kotak centang) yang harus tetap utuh setelah diterjemahkan.
4. Berkas dokumen asinkron — PDF 40 halaman yang dijatuhkan ke dalam chat. Tidak ada anggaran latensi. Batasan utamanya adalah fidelitas — pemformatan, tabel, nomor halaman, font.

Anda bisa membangun satu panggilan LLM raksasa yang mencoba melakukan keempatnya. Kami sudah mencoba. Hasilnya buruk untuk keempatnya. Anggaran latensi untuk suara membuat model tidak bisa berpikir; anggaran fidelitas untuk dokumen mengharuskan model untuk berpikir. Suntingan chat membutuhkan diff dalam bahasa penonton; PDF 40 halaman membutuhkan pelestarian format yang tidak diberikan oleh model token-streaming mana pun.

Jadi kami menjalankan empat pipeline. Berikut adalah masing-masing pipeline tersebut.

Pipeline 1: Terjemahan suara real-time

Masalahnya: Seorang peserta berbicara dalam bahasa Prancis. Peserta lain bergabung dalam bahasa Jerman, yang ketiga dalam bahasa Portugis Brasil, dan yang keempat dalam bahasa Jepang. Setiap peserta perlu mendengar pembicara dalam bahasa mereka sendiri, di telinga mereka sendiri, dengan jeda yang cukup singkat agar kontak mata tetap memungkinkan.

Anggaran: Kurang dari satu detik secara menyeluruh. Jika melebihi ~1,2 detik, percakapan akan terputus — orang-orang mulai berbicara menumpuk dengan terjemahan, dan rapat mulai bergeser ke "ayolah kita ganti ke bahasa Inggris."

Bagaimana audio bergerak secara aktual

Beberapa hal yang perlu disebutkan secara eksplisit:

• ASR berjalan di browser pembicara, bukan di server pusat. Kami menggunakan Mind SDK secara lokal; ini menghemat satu round-trip dan memberi kami transkrip bahasa sumber dengan jeda serendah mungkin sebelum terjemahan bahkan bisa dimulai.
• Terjemahan bukan satu fan-out. Kami menyimpan kumpulan koneksi WebSocket ke mesin terjemahan kami, satu per bahasa target yang hadir di ruangan. Jika tiga peserta memilih bahasa Jerman, bahasa Jerman berbagi satu koneksi. Jika tidak ada yang memilih bahasa Arab, tidak ada koneksi bahasa Arab yang dibuka. Kumpulan koneksi ini menjatuhkan koneksi yang menganggur setelah lima menit. Inilah mengapa rapat dengan empat bahasa memiliki biaya yang sama dengan rapat dengan empat puluh bahasa hingga titik siapa yang benar-benar hadir — kami tidak pernah menerjemahkan ke bahasa yang tidak didengarkan oleh peserta mana pun.
• Suara sintetis adalah per penonton. Setiap peserta menerima trek audio terjemahan mereka sendiri, yang dicampur dengan video pembicara asli. Mereka tidak menonton "rapat terjemahan" induk — mereka menonton rapat yang sama, dengan saluran audio pribadi mereka yang diterjemahkan ke bahasa yang mereka pilih. Inilah mengapa dua orang di ruangan fisik yang sama dapat mencolokkan headphone masing-masing dan mendengar bahasa yang berbeda.

Mengapa ini penting ketika rapat berjalan tidak sesuai rencana

Dalam panggilan 60 menit dengan delapan bahasa, berbagai hal bisa rusak dengan cara yang menarik: WebSocket terputus, ASR salah menyalin nama diri untuk sementara, jaringan satu peserta menjadi tidak stabil. Arsitektur di ataslah yang memungkinkan kami mengisolasi kegagalan: gangguan audio pada satu penonton tidak memengaruhi tujuh penonton lainnya, karena mesin terjemahan tidak pernah menghasilkan "satu terjemahan" sejak awal — ia menghasilkan delapan terjemahan, secara paralel, dan hanya yang terpengaruh saja yang harus dipulihkan.

Mesinnya adalah milik kami, dihosting di infrastruktur kami sendiri. Kami tidak merutekan suara real-time melalui LLM tujuan umum pihak ketiga. Anggaran latensi menyingkirkan mereka; masalah residensi data menyingkirkan mereka untuk pelanggan teregulasi yang benar-benar peduli.

Apa yang kami publikasikan tentang kualitas suara: /benchmark menjalankan pipeline suara produksi terhadap kalimat FLORES-200 untuk setiap pasangan bahasa yang dipublikasikan, setiap bulan. Penilai disebutkan namanya (Gemini 2.5 Flash utama, Claude Sonnet 4 sebagai cadangan). Distribusi lengkap — median, p10, p90, min, maks, ukuran sampel — ada di halaman tersebut. Lihat metodologi untuk mengetahui apa yang diukur dan tidak diukur oleh angka-angka tersebut.

Pipeline 2: Terjemahan chat real-time

Masalahnya: Setiap pesan chat dalam rapat, diterjemahkan untuk setiap peserta dalam bahasa mereka sendiri, saat pesan dikirim. Termasuk suntingan — dan suntingan harus terlihat seperti suntingan, bukan seperti terjemahan ulang.

Anggaran: Cepat, tetapi tidak kurang dari satu detik. Pesan chat bisa memakan waktu setengah detik untuk muncul dalam bahasa lain tanpa ada yang peduli. Apa yang dipedulikan orang-orang adalah apakah terjemahannya tepat dan apakah suntingannya masuk akal.

Apa yang sebenarnya dilakukan oleh pipeline chat

Setiap pesan melewati mesin terjemahan yang sama dengan yang digunakan pipeline suara — tetapi dengan pemrosesan awal dan akhir yang berbeda:

• Struktur HTML tetap dijaga. Chat mendukung teks kaya (paragraf, daftar, kutipan, tebal, miring). Kami mengubahnya menjadi teks biasa untuk model, menerjemahkannya, lalu membungkus hasilnya kembali dengan tag asli. Model tidak pernah melihat HTML — model melihat prosa yang bersih.
• Kutipan diterjemahkan secara independen. Jika Anda membalas pesan dan mengutipnya, blok [QUOTE]…[/QUOTE] dan konten baru diterjemahkan sebagai unit terpisah, sehingga model tidak bisa mencampur keduanya.
• Pesan panjang dipecah. Kami membagi pada batas paragraf dengan 1.000 karakter per potongan. Setiap potongan adalah panggilan terjemahannya sendiri. Kami tidak memasukkan novel berukuran 4.000 karakter ke model dalam satu kali proses — mode kegagalannya (pemotongan, paragraf yang hilang, pemotongan di tengah kalimat) terlalu buruk.
• Terjemahan bersifat malas. Kami menggunakan IntersectionObserver: pesan hanya diterjemahkan saat pesan menggulir ke dalam viewport penonton. Beralih bahasa di saluran yang berjalan lama dulu memutar ulang setiap panggilan API terjemahan dari riwayat. Sekarang tidak lagi.

Bagian yang menarik: suntingan sebagai diff

Di v1.2 kami mengubah cara kerja suntingan chat bagi penonton dalam bahasa lain. Perilaku lamanya adalah: seseorang menyunting pesan, kami menerjemahkan ulang semuanya, Anda melihat paragraf baru dan harus mencari tahu apa yang berubah.

Perilaku barunya:

1. Pesan asli sudah diterjemahkan ke bahasa Anda.
2. Saat pengirim menyunting, kami menerjemahkan ulang versi baru.
3. Kami menghitung diff antara terjemahan Anda sebelumnya dan terjemahan baru Anda, dalam bahasa Anda.
4. Kami menampilkan diff tersebut secara inline — sama seperti cara Git menunjukkan kepada Anda apa yang berubah.

Jadi, ketika "review by Tuesday" menjadi "review by Thursday" dalam bahasa Inggris, rekan Anda yang membaca bahasa Spanyol melihat martes → jueves disorot, bukan paragraf yang diterjemahkan ulang yang harus mereka baca ulang.

Hal ini mengharuskan pipeline chat diperlakukan sebagai cache stateful per penonton, bukan endpoint translate-on-request yang stateless. Dokumen dan suara tidak membutuhkan ini. Chat membutuhkannya.

Pipeline 3: Terjemahan catatan bersama real-time

Masalahnya: Host membuka panel catatan bersama dan mulai mengetik. Setiap peserta melihat catatan dalam bahasa mereka, karakter demi karakter, dengan struktur dokumen — judul, daftar bertingkat, daftar centang, blok kode — yang utuh.

Anggaran: Sama seperti chat (~setengah detik), tetapi dengan dua batasan tambahan:

• Hal yang diterjemahkan berubah di tengah-tengah penerjemahan. Host masih mengetik. Sistem naif yang menerjemahkan "seluruh dokumen" pada setiap tombol yang ditekan akan menghasilkan kedipan dan membakar anggaran API. Kami menerjemahkan pada granularitas unit yang berubah, bukan seluruh dokumen.
• Struktur harus tetap utuh. Jika Anda meminta model terjemahan untuk menerjemahkan sebuah blob markdown dengan tiga daftar bertingkat, Anda akan mendapatkan kembali sesuatu yang terlihat seperti aslinya tetapi dengan hierarki yang halusnya diratakan, item yang dinomori ulang, atau indentasi yang berpindah. Kami tidak membiarkan model melihat seluruh blob.

Bagaimana pipeline catatan berbeda dari chat

Pelestarian struktural adalah hal utama. Kami menerjemahkan setiap item daftar secara independen alih-alih sebagai satu dokumen. Model melihat:

"Tinjauan kepatuhan — hasil kerja Q2"

— bukan:

"# Rencana proyek\n## Kuartal\n- Tinjauan kepatuhan — hasil kerja Q2\n- Penilaian vendor\n - Vendor Tingkat 1..."

Dokumen pembungkus — <ul>, judul, indentasi — dibangun ulang di sisi klien menggunakan struktur yang sama dengan dokumen asli, dengan setiap leaf node ditukar dengan terjemahannya. Model tidak pernah bisa "memperbaiki" hierarki.

Catatan juga menggunakan model diff per penonton yang sama seperti suntingan chat: jika host mengubah satu baris, penonton dalam bahasa lain melihat kata yang diubah disorot, bukan paragraf baru.

Pipeline 4: Terjemahan dokumen asinkron

Masalahnya: Seseorang menjatuhkan PDF 40 halaman, dokumen Word, dek PowerPoint, atau lembar Excel ke dalam chat. Setiap peserta dapat meminta salinan dalam bahasa mereka sendiri. File terjemahan harus terlihat seperti aslinya — font yang sama, tabel yang sama, nomor halaman yang sama, header yang sama, bagan yang sama pada posisinya.

Anggaran: Tidak ada batasan real-time. Satu menit tidak masalah. Dua menit tidak masalah. Batasannya adalah fidelitas — jika PDF terjemahan tidak terlihat seperti aslinya, penerima tidak akan mempercayainya.

Mengapa pipeline ini tidak berbagi mesin dengan suara

LLM umum, bahkan yang sangat bagus sekalipun, akan memberikan kembali teks terjemahan dari sebuah dokumen. LLM tidak akan memberikan kembali PDF terjemahan dengan tata letak yang sama. Model tidak memiliki konsep "page break yang harus sejajar dengan sumber" atau "sel tabel yang harus mempertahankan lebar kolomnya."

Untuk permukaan ini, kami menggunakan DeepL Document API secara langsung. Ini dirancang khusus untuk menerjemahkan file sebagai file, bukan prosa yang diekstrak dari file. DeepL menangani:

• PDF (dengan pelestarian tata letak)
• DOCX, DOC
• PPTX
• XLSX

Dokumen diunggah ke pipeline DeepL, diterjemahkan di sisi server dengan format yang utuh, dan dikembalikan dalam format yang sama. Kami kemudian mengunggah hasilnya ke penyimpanan objek kami dan menampilkannya kembali di chat sebagai lampiran yang dapat diunduh.

Berapa biaya ini dan mengapa kami tidak menyembunyikannya

DeepL menagih minimum 50.000 karakter per dokumen — kira-kira satu dolar AS per file di tier Pro, terlepas dari apakah dokumennya satu halaman atau tiga puluh. Kami menyerap biaya tersebut alih-alih menagih per file; biaya ini muncul dalam penggunaan terjemahan rapat sebagai karakter yang ditagihkan, dikonversi ke unit kata yang sesuai dengan cara produk lainnya melaporkan aktivitas terjemahan.

Kami memilih DeepL untuk permukaan ini karena menerjemahkan file sebagai file adalah pekerjaan yang memang dirancang untuknya — kami tidak mencoba membangun yang lebih baik. Hal yang sama tidak berlaku sebaliknya — DeepL tidak menjalankan pipeline suara langsung seperti yang kami bangun untuk rapat. Masalah yang berbeda; alat yang berbeda. Versi jujur dari "apa yang menggerakkan terjemahan InterMIND" adalah "mesin yang tepat per pipeline" — bukan "mesin kami, di mana-mana."

Bahasa yang dicakup oleh pipeline ini namun tidak oleh suara

Pipeline dokumen mencapai 30 bahasa, dibandingkan 24 bahasa untuk suara. Bahasa tambahan termasuk: Bulgaria, Yunani, Estonia, Indonesia, Lituania, Latvia, Slowakia, Slovenia. (Bahasa Arab dulu ada dalam daftar ini saat kualitas suaranya masih di bawah standar kami; sekarang sudah ada di pemilih real-time, dengan skor per pasangannya yang dipublikasikan di /benchmark seperti bahasa lainnya. Asimetri sekarang berjalan ke arah lain untuk Hindi — langsung di suara, tapi belum di file.)

Asimetri itu nyata. Artinya, peserta Prancis dalam rapat dapat meminta PDF kontrak dalam bahasa Estonia meskipun mereka tidak dapat mendengarkan rapat dalam bahasa Estonia. Kami menandainya di pemilih daripada menutupinya dengan satu angka. Alasannya ada di postingan jumlah bahasa.

Di mana pipeline-pipeline bertemu

Keempat pipeline tidak berjalan secara terisolasi. Ruang rapat adalah tempat mereka saling bersinggungan, dan jahitannya penting:

• Pesan chat dengan lampiran dokumen memicu pipeline chat untuk teks dan pipeline dokumen untuk file. Peserta dalam bahasa lain melihat pesan yang segera diterjemahkan dan terjemahan lampiran yang tiba secara asinkron sebagai unduhan.
• Catatan bersama yang mengutip baris transkrip melintasi catatan ↔ suara. Transkrip adalah apa yang dihasilkan oleh pipeline suara untuk bahasa pengirim; terjemahan catatan menghasilkan salinan kutipan tersebut per penonton dalam bahasa orang lain, dengan atribusi sumbernya tetap terjaga.
• Transkrip yang diekspor setelah rapat menjalankan pipeline teks bergaya chat ke seluruh percakapan, menghasilkan file per bahasa yang dapat diunduh oleh peserta. Ini adalah jalur kode yang sama dengan terjemahan chat, hanya saja dilakukan secara batch.

Pemilih bahasa adalah satu bagian UI. Infrastruktur di bawahnya adalah empat pipeline, yang saling berbicara satu sama lain.

Apa yang dengan sengaja tidak kami coba lakukan

• Tidak ada "model terjemahan terpadu." Kami tidak membangun satu model yang melakukan suara, chat, catatan, dan dokumen. Pertukaran antara latensi dan fidelitas tidak memiliki pemenang. Kami menggunakan mesin yang tepat per permukaan.
• Tidak ada rute ulang diam-diam. Jika pipeline file tidak dapat menerjemahkan ke bahasa Hindi hari ini, kami tidak diam-diam beralih ke mesin suara dan berpura-pura itu berhasil — pemilih file menandai celah tersebut alih-alih menyembunyikannya.
• Tidak ada "kami menerjemahkan ke 200 bahasa." Mesin kami menghasilkan 24. Permukaan langsung mengirimkan semua 24, dokumen 30 — dan alih-alih satu angka yang ramah pemasaran, kualitas per pasangan yang harus berdiri di depan auditor dipublikasikan di /benchmark, termasuk pasangan yang lebih lemah.

Cobalah sendiri

• Coba demo langsung — menjalankan pipeline suara langsung terhadap audio Anda, dalam salah satu dari 24 bahasa produk. Pipeline yang sama yang mencatat skor di /benchmark.
• Lihat benchmark — kualitas per pasangan, per bulan pada traffic nyata. Setiap pasangan di pemilih, kuat atau lemah, dapat ditautkan secara mendalam.
• Baca metodologi — apa angka-angka tersebut, apa yang bukan, siapa penilainya.

Empat pipeline, empat mesin, satu ruang rapat. Itulah pengganti yang jujur untuk halaman how-it-works yang lama.

— Tim Mind.com

Sumber: DeepL — bahasa yang didukung, DeepL — penghitungan penggunaan dan penagihan (minimum 50.000 karakter per file), FLORES-200; fakta pipeline internal diverifikasi terhadap kode yang dikirim, diperiksa Agustus 2026.