Di balik empat pipeline terjemahan yang menjalankan InterMIND

Halaman /product/overview/how-it-works lama di mind.com sudah beberapa rilis mayor tertinggal. Halaman tersebut mendeskripsikan satu "mesin terjemahan" seperti cara yang dilakukan sebagian besar halaman vendor — satu panah besar dari "Anda berbicara" ke "mereka mendengar." Gambaran tersebut 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 terbaru untuk "bagaimana cara kerjanya."

Tulisan pendamping: "How many languages do you support?" membahas apa yang dicakup oleh masing-masing pipeline (23 / 23 / 30 / 17). Pos ini membahas tentang apa yang dilakukan oleh masing-masing pipeline — dan mengapa hal itu berbeda.

Mengapa "satu mesin untuk segalanya" adalah kebohongan

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

1. Suara real-time — audio masuk, audio terjemahan keluar, di bawah satu detik, setiap penonton dalam bahasa mereka sendiri. Batasan utamanya adalah latensi.
2. Teks chat real-time — pesan singkat, cepat, dengan suntingan, kutipan, dan struktur HTML yang dipertahankan.
3. Catatan bersama real-time — pengetikan kolaboratif karakter demi karakter, dengan hierarki struktural (daftar, judul, kotak centang) yang harus tetap utuh selama penerjemahan.
4. Berkas dokumen asinkron — PDF 40 halaman yang dimasukkan 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. Itu buruk dalam keempatnya. Anggaran latensi untuk suara berarti model tidak bisa berpikir; anggaran fidelitas untuk dokumen berarti model harus 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. Masing-masing perlu mendengar pembicara dalam bahasa mereka sendiri, di telinga mereka sendiri, dengan penundaan yang cukup singkat agar kontak mata tetap memungkinkan.

Anggarannya: Kurang dari satu detik secara end-to-end. Lebih dari ~1,2 detik dan percakapan akan rusak — orang-orang mulai berbicara menumpuk dengan terjemahan, dan rapat bergeser ke "ayo ganti ke bahasa Inggris saja."

Bagaimana audio sebenarnya bergerak

Beberapa hal yang patut disebutkan secara eksplisit:

• ASR berjalan di server media. Audio pembicara dikirim melalui WebRTC ke mesin kami sendiri — Mind API di OVH, Prancis — dan dikenali di sana, di server yang sama yang membawa panggilan; browser hanya mengirim audio dan menerima kembali kata-katanya. Tidak ada vendor speech terpisah dan tidak ada hop ekstra sebelum penerjemahan dapat dimulai. (Voice note chat adalah pengecualian: speech-to-text mereka berjalan di Azure AI Speech, layanan speech dari default AI gateway.)
• Terjemahan bukan satu fan-out. Mesin menerjemahkan per bahasa target yang ada di ruangan, bukan per penonton: penerjemahan ke dalam suatu bahasa dimulai ketika pendengar pertama di bahasa tersebut meminta stream terjemahan, tiga peserta yang memilih bahasa Jerman berbagi satu terjemahan Jerman, dan tidak ada yang mendengarkan dalam bahasa Arab berarti tidak ada yang diterjemahkan ke dalam bahasa Arab. Inilah sebabnya rapat empat bahasa memiliki biaya yang sama dengan rapat empat puluh bahasa hingga titik siapa yang sebenarnya hadir — kami tidak pernah menerjemahkan ke bahasa yang tidak didengarkan oleh peserta mana pun.
• Suara sintetis per penonton. Setiap peserta menerima trek audio terjemahan mereka sendiri, dicampur dengan video pembicara asli. Mereka tidak menonton "rapat terjemahan" induk — mereka menonton rapat yang sama, dengan saluran audio pribadi mereka diterjemahkan ke bahasa yang mereka pilih. Inilah sebabnya dua orang di ruangan fisik yang sama dapat memasang headphone masing-masing dan mendengarkan bahasa yang berbeda.

Mengapa ini penting ketika rapat bermasalah

Dalam panggilan 60 menit dengan delapan bahasa, hal-hal bisa rusak dengan cara yang menarik: WebSocket terputus, ASR salah transkrip nama secara sementara, jaringan salah 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 — mesin menghasilkan delapan terjemahan, secara paralel, dan hanya yang terpengaruh yang harus dipulihkan.

Mesinnya milik kami, dihosting di infrastruktur kami sendiri. Kami tidak merutekan suara real-time melalui LLM tujuan umum pihak ketiga. Anggaran latensi menyingkirkan mereka; cerita 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. Penilainya disebutkan namanya (Gemini 3.7 Flash utama, Claude Sonnet 5 fallback). Distribusi lengkap — median, p10, p90, min, maks, ukuran sampel — ada di halaman tersebut. Lihat metodologinya 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. Ditambah suntingan — dan suntingan harus terlihat seperti suntingan, bukan seperti terjemahan ulang.

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

Apa yang sebenarnya dilakukan oleh pipeline chat

Setiap pesan melewati mesin terjemahan yang sama yang digunakan oleh pipeline suara — tetapi dengan pra-pemrosesan dan pasca-pemrosesan yang berbeda:

• Struktur HTML dipertahankan. Chat mendukung rich text (paragraf, daftar, kutipan, tebal, miring). Kami mengubahnya menjadi plain text 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 mencampuradukkan keduanya.
• Pesan panjang di-chunk. Kami membagi pada batas paragraf dengan 1.000 karakter per chunk. Setiap chunk adalah panggilan terjemahannya sendiri. Kami tidak memasukkan novel 4.000 karakter ke model dalam satu kali jalan — mode kegagalannya (pemotongan, paragraf yang hilang, pemotongan di tengah kalimat) terlalu jelek.
• Terjemahan bersifat lazy. Kami menggunakan IntersectionObserver: pesan hanya diterjemahkan saat pesan bergulir ke dalam viewport penonton. Mengganti bahasa di saluran yang sudah berjalan lama sebelumnya harus memutar ulang setiap panggilan API terjemahan dari riwayat. Sekarang tidak lagi.

Bagian yang menarik: suntingan sebagai diff

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

Perilaku baru:

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 — cara yang sama seperti Git menunjukkan kepada Anda apa yang berubah.

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

Hal ini mengharuskan memperlakukan pipeline chat sebagai cache stateful per penonton, bukan endpoint stateless translate-on-request. 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 — utuh.

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

• Hal yang diterjemahkan berubah di tengah penerjemahan. Host masih mengetik. Sistem naif yang menerjemahkan "seluruh dokumen" pada setiap penekanan tombol 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 blob markdown dengan tiga daftar bertingkat, Anda mendapatkan kembali sesuatu yang terlihat seperti aslinya tetapi dengan hierarki yang halus dan merata, 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 daripada sebagai satu dokumen. Model melihat:

"Tinjauan kepatuhan — Q2 deliverables"

— bukan:

"# Rencana proyek\n## Kuartal\n- Tinjauan kepatuhan — Q2 deliverables\n- Penilaian vendor\n - Vendor Tier 1..."

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

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 memasukkan 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, grafik yang sama pada posisinya.

Anggarannya: Tidak ada batasan real-time. Satu menit tidak masalah. Dua menit juga 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, akan memberikan kembali teks terjemahan dari sebuah dokumen. LLM tidak akan memberikan kembali PDF terjemahan dengan layout yang sama. Model tidak memiliki konsep "page break yang harus selaras dengan sumbernya" atau "sel tabel yang harus menjaga lebar kolomnya."

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

• PDF (dengan pelestarian layout)
• 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 object storage kami dan menampilkannya kembali di chat sebagai lampiran yang dapat diunduh.

Berapa biayanya dan mengapa kami tidak menyembunyikannya

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

Kami memilih DeepL untuk surface ini karena menerjemahkan file sebagai file adalah pekerjaan yang memang dibangun untuk itu — kami tidak mencoba membangun yang lebih baik. Sebaliknya hal ini tidak berlaku — DeepL tidak menjalankan pipeline live-voice seperti yang kami bangun untuk rapat. Masalah berbeda; alat 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 tetapi tidak oleh suara

Pipeline dokumen mencapai 30 bahasa, dibandingkan 23 untuk suara. Bahasa tambahan mencakup: Bulgaria, Yunani, Estonia, Indonesia, Lithuania, Latvia, Slovakia, Slovenia. (Bahasa Arab juga ada dalam daftar ini, dan merupakan salah satu tambahan: bahasa ini ditarik dari pemilih real-time selama kualitas suaranya di bawah standar kami, dan skor per pasangannya tetap dipublikasikan di /benchmark — angka itulah yang akan mengembalikannya. Asimetri berjalan ke arah berlawanan untuk Hindi — langsung di suara, tetapi belum untuk file.)

Asimetri tersebut nyata. Artinya, peserta Prancis dalam suatu 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 pos jumlah bahasa.

Di mana pipeline bertemu

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

• Pesan chat dengan lampiran dokumen memicu pipeline chat untuk teks dan pipeline dokumen untuk file. Peserta dalam bahasa lain melihat pesan diterjemahkan secara langsung dan terjemahan lampiran tiba secara asinkron sebagai file yang dapat diunduh.
• 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 masing-masing, dengan atribusi sumbernya dipertahankan.
• 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 diproses 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. Trade-off latensi vs fidelitas tidak memiliki pemenang. Kami menggunakan mesin yang tepat per surface.
• Tidak ada re-routing diam-diam. Jika pipeline file tidak dapat menerjemahkan ke 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 memancarkan 24. Surface langsung mengirimkan 23, dokumen 30 — dan alih-alih satu angka 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 23 bahasa produk apa pun. Pipeline yang sama yang mencetak skor di /benchmark.
• Lihat benchmark — kualitas per pasangan, per bulan pada lalu lintas nyata. Setiap pasangan di pemilih, kuat atau lemah, dapat di-deep-link.
• Baca metodologi — apa angka-angka itu, apa 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 — supported languages, DeepL — usage count and billing (minimum 50.000 karakter per file), FLORES-200; fakta pipeline internal diverifikasi terhadap kode yang dikirim, diperiksa Agustus 2026.