Di balik empat pipeline terjemahan yang menjalankan InterMIND

Halaman lama /product/overview/how-it-works di mind.com sudah tertinggal beberapa rilis besar. Halaman itu menggambarkan satu "engine terjemahan" seperti kebanyakan halaman vendor: satu panah besar dari "Anda berbicara" ke "mereka mendengar." Gambaran itu sudah terlalu menyederhanakan dua tahun lalu. Sekarang gambaran itu keliru.

Kenyataannya, InterMIND menjalankan empat pipeline terjemahan yang terpisah, masing-masing menyelesaikan masalah yang berbeda dengan engine yang berbeda, anggaran latensi yang berbeda, dan standar kualitas yang berbeda. Mereka berbagi satu pemilih bahasa. Mereka tidak berbagi engine.

Inilah jawaban terbaru untuk pertanyaan "bagaimana cara kerjanya."

Tulisan pendamping: "Berapa banyak bahasa yang Anda dukung?" membahas apa yang dicakup setiap pipeline (23 / 23 / 30 / 17). Tulisan ini membahas apa yang dikerjakan setiap pipeline, dan mengapa masing-masing berdiri sendiri.

Mengapa "satu engine untuk segalanya" adalah kebohongan

Platform meeting langsung harus mengerjakan setidaknya empat tugas sekaligus, dan tuntutannya saling bertentangan:

1. Suara real-time: audio masuk, audio terjemahan keluar saat pembicara masih berbicara, dan setiap penonton mendengar dalam bahasanya sendiri. Kendala utamanya adalah latensi.
2. Teks chat real-time: pesan pendek dan cepat, dengan suntingan, kutipan, dan struktur HTML yang tetap terjaga.
3. Catatan bersama real-time: pengetikan kolaboratif karakter demi karakter, dengan hierarki struktur (daftar, judul, kotak centang) yang harus bertahan setelah diterjemahkan.
4. File dokumen asinkron: PDF 40 halaman yang dijatuhkan ke chat. Tidak ada anggaran latensi. Kendala utamanya adalah fidelitas: format, tabel, nomor halaman, jenis huruf.

Anda bisa membuat satu panggilan LLM raksasa yang mencoba mengerjakan keempatnya. Kami sudah mencobanya. Hasilnya buruk di keempat-empatnya. Anggaran latensi untuk suara berarti model tidak boleh "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 streaming token mana pun.

Jadi kami menjalankan empat. Berikut masing-masing.

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, yang keempat dalam bahasa Jepang. Masing-masing perlu mendengar pembicara dalam bahasanya sendiri, di telinganya sendiri, dengan jeda yang cukup singkat sehingga kontak mata tetap memungkinkan.

Anggarannya: pendengar tidak boleh sampai harus menunggu. Begitu ucapan terjemahan tertinggal cukup jauh hingga orang mulai berbicara menimpanya, meeting mulai condong ke "ya sudah, kita pakai bahasa Inggris saja."

Bagaimana audio sebenarnya bergerak

Beberapa hal yang perlu disebutkan secara eksplisit:

• ASR berjalan di media server. Audio pembicara berjalan lewat WebRTC ke engine kami sendiri, yaitu Mind API di OVH, Prancis, dan dikenali di sana, di server yang sama yang membawa panggilan. Browser hanya mengirim audio dan menerima kata-katanya kembali. Tidak ada vendor ucapan terpisah dan tidak ada lompatan tambahan sebelum terjemahan dapat dimulai. (Pesan suara di chat adalah pengecualian: speech-to-text-nya berjalan di Azure AI Speech, layanan ucapan dari gateway AI default.)
• Terjemahan bukan satu fan-out. Engine menerjemahkan per bahasa target yang ada di ruangan, bukan per penonton: terjemahan ke suatu bahasa dimulai saat pendengar pertama dalam bahasa itu meminta aliran terjemahan, tiga peserta yang memilih bahasa Jerman berbagi satu terjemahan Jerman, dan jika tidak ada yang mendengarkan dalam bahasa Arab, tidak ada yang diterjemahkan ke bahasa Arab. Inilah sebabnya meeting empat bahasa biayanya sama dengan meeting empat puluh bahasa, sejauh menyangkut siapa yang benar-benar hadir: kami tidak pernah menerjemahkan ke bahasa yang tidak didengarkan oleh satu peserta pun.
• Ucapan sintetis bersifat per penonton. Setiap peserta menerima trek audio terjemahannya sendiri, yang dicampur dengan video pembicara asli. Mereka tidak menonton "meeting terjemahan" induk; mereka menonton meeting yang sama, dengan kanal audio pribadi yang diterjemahkan ke bahasa pilihan mereka. Inilah sebabnya dua orang di ruangan fisik yang sama bisa masing-masing memasang headphone dan mendengar bahasa yang berbeda.

Mengapa ini penting ketika meeting berjalan tidak mulus

Dalam panggilan 60 menit dengan delapan bahasa, hal-hal bisa rusak dengan cara yang menarik: WebSocket terputus, ASR sesaat salah menranskripsikan nama diri, jaringan salah satu peserta jadi tidak stabil. Arsitektur di atas membuat kami dapat mengisolasi kegagalan: gangguan audio pada satu penonton tidak memengaruhi tujuh penonton lainnya, karena engine terjemahan tidak pernah menghasilkan "terjemahan" tunggal sejak awal. Engine menghasilkan delapan secara paralel, dan hanya yang terdampak yang perlu pulih.

Engine-nya milik kami sendiri, di-host di infrastruktur kami sendiri. Kami tidak merutekan suara real-time lewat LLM serbaguna pihak ketiga. Anggaran latensi mengesampingkannya; kebutuhan residensi data mengesampingkannya 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 cadangan). Distribusi lengkapnya — median, p10, p90, minimum, maksimum, ukuran sampel — ada di halaman tersebut. Lihat metodologi untuk memahami apa yang diukur dan tidak diukur oleh angka-angka itu.

Pipeline 2: Terjemahan chat real-time

Masalahnya: Setiap pesan chat di dalam meeting diterjemahkan untuk setiap peserta dalam bahasanya sendiri, saat pesan dikirim. Ditambah suntingan, dan suntingan harus terlihat seperti suntingan, bukan seperti terjemahan ulang.

Anggarannya: lebih longgar daripada suara. Pesan chat boleh butuh sesaat untuk muncul dalam bahasa lain tanpa ada yang mempermasalahkan. Yang diperhatikan orang adalah apakah terjemahannya benar dan apakah suntingannya masuk akal.

Apa yang sebenarnya dilakukan pipeline chat

Setiap pesan melewati engine terjemahan yang sama dengan pipeline suara, tetapi dengan pra-pemrosesan dan pascapemrosesan yang berbeda:

• Struktur HTML dipertahankan. Chat mendukung teks kaya (paragraf, daftar, kutipan, tebal, miring). Kami mengubahnya menjadi teks biasa untuk model, menerjemahkan, lalu membungkus ulang hasilnya dalam tag aslinya. Model tidak pernah melihat HTML; ia melihat prosa yang bersih.
• Kutipan diterjemahkan secara terpisah. Jika Anda membalas sebuah pesan dan mengutipnya, blok [QUOTE]…[/QUOTE] dan konten baru diterjemahkan sebagai unit yang terpisah, sehingga model tidak bisa mencampuradukkan keduanya.
• Pesan panjang dipecah. Kami membagi pada batas paragraf dengan 1.000 karakter per potongan. Setiap potongan adalah satu panggilan terjemahan tersendiri. Kami tidak memasukkan "novel" 4.000 karakter ke model sekaligus; mode kegagalannya (terpotong, paragraf hilang, kalimat terputus di tengah) terlalu buruk.
• Terjemahan bersifat lazy. Kami menggunakan IntersectionObserver: pesan baru diterjemahkan ketika ia bergulir masuk ke viewport penonton. Dulu, berganti bahasa di kanal yang sudah lama berjalan akan 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 lamanya: seseorang menyunting pesan, kami menerjemahkan ulang seluruhnya, Anda melihat paragraf baru dan harus mencari sendiri 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 Anda yang baru, dalam bahasa Anda.
4. Kami menampilkan diff itu secara inline, seperti cara Git menunjukkan apa yang berubah.

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

Ini mengharuskan kami memperlakukan pipeline chat sebagai cache per penonton yang stateful, bukan endpoint terjemahan stateless yang bekerja per permintaan. 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 bahasanya, karakter demi karakter, dengan struktur dokumen (judul, daftar bersarang, daftar periksa, blok kode) tetap utuh.

Anggarannya: Sama seperti chat, tetapi dengan dua kendala tambahan:

• Hal yang diterjemahkan berubah di tengah penerjemahan. Host masih mengetik. Sistem naif yang menerjemahkan "seluruh dokumen" pada setiap ketukan tombol menghasilkan kedipan dan menghabiskan anggaran API. Kami menerjemahkan pada granularitas unit yang berubah, bukan seluruh dokumen.
• Struktur harus bertahan. Jika Anda meminta model terjemahan menerjemahkan gumpalan markdown dengan tiga daftar bersarang, Anda mendapat sesuatu yang tampak seperti aslinya tetapi dengan hierarki yang diratakan secara halus, butir yang dinomori ulang, atau indentasi yang bergeser. Kami tidak membiarkan model melihat seluruh gumpalan itu.

Bagaimana pipeline catatan berbeda dari chat

Pelestarian struktur adalah hal utamanya. Kami menerjemahkan setiap butir daftar secara terpisah, bukan sebagai satu dokumen. Model melihat:

"Compliance review — Q2 deliverables"

— bukan:

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

Dokumen pembungkusnya, yaitu <ul>, judul, dan indentasi, dibangun ulang di sisi klien dengan struktur yang sama seperti dokumen aslinya, dengan setiap simpul daun diganti oleh terjemahannya. Model tidak pernah diberi kesempatan untuk "memperbaiki" hierarkinya.

Catatan juga memakai model diff per penonton yang sama dengan suntingan chat: jika host mengubah satu baris, penonton dalam bahasa lain melihat kata-kata yang berubah disorot, bukan paragraf baru.

Pipeline 4: Terjemahan dokumen asinkron

Masalahnya: Seseorang menjatuhkan PDF 40 halaman, dokumen Word, presentasi PowerPoint, atau lembar Excel ke chat. Setiap peserta dapat meminta salinan dalam bahasanya sendiri. File terjemahan harus tampak seperti aslinya: jenis huruf yang sama, tabel yang sama, nomor halaman yang sama, header yang sama, bagan yang tetap di tempatnya.

Anggarannya: Tidak ada kendala real-time. Satu menit tidak masalah. Dua menit pun tidak masalah. Kendalanya adalah fidelitas: jika PDF terjemahan tidak tampak seperti aslinya, penerima tidak akan memercayainya.

Mengapa pipeline ini tidak berbagi engine dengan suara

LLM umum, sebagus apa pun, akan menyerahkan kembali teks terjemahan dari sebuah dokumen. Ia tidak akan menyerahkan kembali PDF terjemahan dengan tata letak yang sama. Model tidak mengenal konsep "pemisah halaman yang harus sejajar dengan sumber" atau "sel tabel yang harus mempertahankan lebar kolomnya."

Untuk permukaan 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 tata letak)
• DOCX, DOC
• PPTX
• XLSX

Dokumen diunggah ke pipeline DeepL, diterjemahkan di sisi server dengan format tetap utuh, lalu dikembalikan dalam format yang sama. Kami kemudian mengunggah hasilnya ke penyimpanan objek 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 pada paket Pro, terlepas dari apakah dokumennya satu halaman atau tiga puluh. Kami menanggung biaya itu alih-alih mengenakan biaya per file; biaya itu muncul dalam penggunaan terjemahan meeting sebagai karakter yang ditagih, dikonversi ke satuan kata yang sesuai dengan cara bagian produk lainnya melaporkan aktivitas terjemahan.

Kami memilih DeepL untuk permukaan ini karena menerjemahkan file sebagai file persis pekerjaan yang dibuatnya; kami tidak mencoba membuat yang lebih baik. Sebaliknya tidak berlaku: DeepL tidak menjalankan pipeline suara langsung seperti yang kami bangun untuk meeting. Masalahnya berbeda, alatnya berbeda. Versi jujur dari "apa yang menggerakkan terjemahan InterMIND" adalah "engine yang tepat untuk setiap pipeline", bukan "engine kami, di mana-mana."

Bahasa yang dicakup pipeline ini tetapi tidak dicakup suara

Pipeline dokumen menjangkau 30 bahasa, dibandingkan 23 untuk suara. Bahasa tambahannya meliputi: Bulgaria, Yunani, Estonia, Indonesia, Lituania, Latvia, Slovakia, Slovenia. (Bahasa Arab juga ada dalam daftar ini, dan termasuk bahasa tambahan: bahasa Arab ditarik dari pemilih real-time selama kualitas suaranya masih di bawah standar kami, dan skor per pasangannya tetap publik di /benchmark; angka itulah yang akan mengembalikannya. Asimetrinya berlaku sebaliknya untuk bahasa Hindi: sudah tersedia untuk suara, belum untuk file.)

Asimetri itu nyata. Artinya, peserta berbahasa Prancis dalam sebuah meeting dapat meminta PDF kontrak dalam bahasa Estonia meskipun ia tidak dapat mendengarkan meeting dalam bahasa Estonia. Kami menandainya di pemilih alih-alih menutupinya dengan satu angka tunggal. Alasannya dijelaskan di tulisan tentang jumlah bahasa.

Di mana pipeline-pipeline itu bertemu

Keempat pipeline tidak berjalan terpisah. Ruang meeting adalah tempat mereka saling bersentuhan, dan sambungan-sambungannya penting:

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

Pemilih bahasa hanyalah satu bagian antarmuka. Infrastruktur di baliknya adalah empat pipeline yang saling berkomunikasi.

Apa yang sengaja tidak kami coba

• Tidak ada "model terjemahan terpadu." Kami tidak sedang membangun satu model yang menangani suara, chat, catatan, dan dokumen. Pertukaran antara latensi dan fidelitas tidak punya pemenang. Kami memakai engine yang tepat untuk setiap permukaan.
• Tidak ada pengalihan rute secara diam-diam. Jika pipeline file hari ini tidak dapat menerjemahkan ke bahasa Hindi, kami tidak diam-diam beralih ke engine suara dan berpura-pura berhasil; pemilih file menandai celah itu alih-alih menyembunyikannya.
• Tidak ada "kami menerjemahkan ke 200 bahasa." Engine kami mengeluarkan 24. Permukaan langsung mendukung 23, dokumen 30. Alih-alih satu angka yang enak dipasarkan, kualitas per pasangan bahasa yang harus tahan di hadapan auditor dipublikasikan di /benchmark, termasuk pasangan yang lebih lemah.

Coba sendiri

• Coba demo langsung: menjalankan pipeline suara langsung terhadap audio Anda, dalam salah satu dari 23 bahasa produk. Pipeline yang sama yang menghasilkan skor di /benchmark.
• Lihat benchmark: kualitas per pasangan, per bulan, pada lalu lintas nyata. Setiap pasangan di pemilih, kuat maupun lemah, dapat ditautkan langsung.
• Baca metodologinya: apa arti angka-angka itu, apa yang bukan, dan siapa penilainya.

Empat pipeline, empat engine, satu ruang meeting. 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 internal pipeline diverifikasi terhadap kode yang dirilis, diperiksa pada Agustus 2026.