InterMIND'i çalıştıran dört çeviri hattının içinde

mind.com'daki eski /product/overview/how-it-works sayfası, birkaç büyük sürüm geride kaldı. Çoğu satıcı sayfasının yaptığı gibi tek bir "çeviri motorunu" tarif ediyor — "siz konuşursunuz"dan "onlar duyar"a giden tek bir büyük ok. Bu resim iki yıl önce bile bir basitleştirmeydi. Bugün ise yanlış.

Gerçek şu ki InterMIND, her biri farklı bir motorla, farklı bir gecikme bütçesiyle ve farklı bir kalite aralığıyla farklı bir sorunu çözen dört ayrı çeviri hattı çalıştırıyor. Bunlar bir dil seçiciyi paylaşır. Motoru paylaşmazlar.

Bu, "nasıl çalışıyor?" sorusunun güncellenmiş cevabıdır.

Eşlik eden yazı: "Kaç dili destekliyorsunuz?", her hattın neleri kapsadığını (24 / 24 / 30 / 17) ele alıyor. Bu yazı ise her hattın ne yaptığını — ve neden başlı başına bir şey olduğunu ele alıyor.

"Her şey için tek motor" neden bir yalandır

Canlı bir toplantı platformunun aynı anda yapması gereken en az dört iş var ve bunlar birbiriyle uyumsuz yönlere çekiyor:

1. Gerçek zamanlı ses — ses girişi, çevrilmiş ses çıkışı, bir saniyenin altında, her izleyici kendi dilinde. Zor kısıt gecikmedir.
2. Gerçek zamanlı sohbet metni — kısa mesajlar, hızlı, düzenlemeler, alıntılar ve HTML yapısı korunarak.
3. Gerçek zamanlı paylaşılan notlar — karakter karakter işbirlikçi yazım, çeviriden sağ çıkması gereken yapısal hiyerarşiyle (listeler, başlıklar, onay kutuları).
4. Eşzamanlı olmayan belge dosyaları — sohbete bırakılan 40 sayfalık bir PDF. Gecikme bütçesi yoktur. Zor kısıt sadakattir — biçimlendirme, tablolar, sayfa numaraları, yazı tipi.

Hepsini yapmaya çalışan tek dev bir LLM çağrısı kurabilirsiniz. Denedik. Dördünde de kötüdür. Ses için gecikme bütçesi, modelin düşünememesi anlamına gelir; belgeler için sadakat bütçesi, modelin düşünmesi gerektiği anlamına gelir. Bir sohbet düzenlemesi, izleyicinin dilinde bir fark (diff) gerektirir; 40 sayfalık bir PDF, hiçbir token akışlı modelin size vermediği biçim koruması gerektirir.

Bu yüzden dört tane çalıştırıyoruz. İşte her biri.

Hat 1: Gerçek zamanlı ses çevirisi

Sorun: Bir katılımcı Fransızca konuşuyor. Başka bir katılımcı Almanca, üçüncüsü Brezilya Portekizcesi, dördüncüsü Japonca katılmış. Her birinin konuşmacıyı kendi dilinde, kendi kulağında, göz temasını mümkün kılacak kadar kısa bir gecikmeyle duyması gerekiyor.

Bütçe: Uçtan uca bir saniyenin altında. ~1.2 saniyeyi geçen her şeyde sohbet bozulur — insanlar çevirinin üzerinden konuşmaya başlar ve toplantı "hadi İngilizceye geçelim"e kayar.

Ses aslında nasıl hareket ediyor

Açıkça adlandırılmaya değer birkaç şey:

• ASR, merkezi bir sunucuda değil, konuşmacının tarayıcısında çalışır. Mind SDK'yı yerel olarak kullanıyoruz; bu, bir gidiş-dönüş turunu kurtarır ve çeviri başlamadan önce bize mümkün olan en düşük gecikmeyle kaynak dil dökümünü verir.
• Çeviri tek bir dağıtım (fan-out) değildir. Çeviri motorumuza, odadaki mevcut her hedef dil için bir tane olacak şekilde bir WebSocket bağlantı havuzu tutarız. Üç katılımcı Almanca seçtiyse, Almanca tek bir bağlantıyı paylaşır. Kimse Arapça seçmediyse Arapça bağlantı açılmaz. Havuz, beş dakika sonra boşta olan bağlantıları bırakır. Dört dilli bir toplantının maliyetinin, kimin gerçekten katıldığı noktasına kadar kırk dilli bir toplantıyla aynı olmasının nedeni budur — hiçbir katılımcının dinlemediği dillere asla çeviri yapmayız.
• Sentezlenmiş konuşma izleyiciye özeldir. Her katılımcı, orijinal konuşmacının videosunun üzerine karıştırılmış kendi çevrilmiş ses parçasını alır. Onlar ana bir "çevrilmiş toplantı" izlemiyorlar — aynı toplantıyı kişisel ses kanalları kendi seçtikleri dile çevrilmiş halde izliyorlar. Bu nedenle aynı fiziksel odadaki iki kişi kendi kulaklıklarını takıp farklı dilleri duyabilir.

Bir toplantı ters gittiğinde bu neden önemli

Sekiz dilli 60 dakikalık bir aramada işler ilginç şekillerde bozulur: WebSocket'ler düşer, ASR geçici olarak bir özel ismi yanlış dökümler, bir katılımcının ağı dalgalanır. Yukarıdaki mimari, hataları yalıtmamızı sağlayan şeydir: bir izleyicinin sesinin takılması diğer yedisini etkilemez, çünkü çeviri motoru zaten "çeviriyi" üretmemiştir — paralel olarak sekiz tane üretmiştir ve yalnızca etkilenen olanın toparlanması gerekir.

Motorun kendisi bizimdir, kendi altyapımızda barındırılır. Gerçek zamanlı sesi üçüncü taraf genel amaçlı LLM'ler üzerinden yönlendirmiyoruz. Gecikme bütçesi onları eler; veri ikametgahı hikayesi, gerçekten umursayan regüle edilmiş müşteriler için onları eler.

Ses kalitesi hakkında yayınladıklarımız: /benchmark, üretim ses hattını her yayınlanmış dil çifti için aylık olarak FLORES-200 cümlelerine karşı çalıştırır. Jüri adlandırılmıştır (birincil Gemini 2.5 Flash, yedek Claude Sonnet 4). Tam dağılım — medyan, p10, p90, min, maks, örneklem boyutu — sayfada yer alır. Bu sayıların neyi ölçüp neyi ölçmediği için metodolojiye bakın.

Hat 2: Gerçek zamanlı sohbet çevirisi

Sorun: Toplantıdaki her sohbet mesajı, her katılımcı için kendi dilinde, gönderildiği anda çevrilir. Artı düzenlemeler — ve düzenlemeler yeniden çeviriler gibi değil, düzenlemeler gibi görünmelidir.

Bütçe: Hızlı, ama bir saniyenin altında değil. Bir sohbet mesajının başka bir dilde görünmesi için kimsenin umursamadan yarım saniye alabilir. İnsanların umursadığı şey, çevirinin doğru olup olmadığı ve düzenlemelerin mantıklı olup olmadığıdır.

Sohbet hattı aslında ne yapıyor

Her mesaj, ses hattının kullandığı aynı çeviri motorundan geçer — ancak farklı ön ve son işlemlerle:

• HTML yapısı korunur. Sohbet zengin metni destekler (paragraflar, listeler, alıntılar, kalın, italik). Model için düz metne dönüştürür, çevirir, ardından sonucu orijinal etiketlerde yeniden sararız. Model HTML'i asla görmez — temiz düz yazı görür.
• Alıntılar bağımsız olarak çevrilir. Bir mesajı yanıtlayıp alıntılarsanız, [QUOTE]…[/QUOTE] bloğu ve yeni içerik ayrı birimler olarak çevrilir, böylece model ikisini karıştıramaz.
• Uzun mesajlar parçalara ayrılır. Paragraf sınırlarında her parça için 1.000 karaktere kadar böleriz. Her parça kendi çeviri çağrısıdır. Modeli tek seferde 4.000 karakterlik romanlarla beslemiyoruz — hata modları (kesilme, kayıp paragraflar, cümlenin ortasında kesilmeler) çok çirkindir.
• Çeviri tembeldir. Bir IntersectionObserver kullanırız: bir mesaj yalnızca izleyicinin görüntü alanına kaydırıldığında çevrilir. Uzun süredir çalışan bir kanalda dili değiştirmek, geçmişten her çeviri API çağrısını yeniden oynatırdı. Artık oynamıyor.

İlginç kısım: fark olarak düzenlemeler

v1.2'de başka bir dildeki izleyiciler için sohbet düzenlemelerinin nasıl davrandığını değiştirdik. Eski davranış şuydu: biri bir mesajı düzenler, biz hepsini yeniden çeviririz, siz yeni bir paragraf görürsünüz ve neyin değiştiğini kendiniz bulmak zorunda kalırsınız.

Yeni davranış:

1. Orijinal mesaj zaten dilinize çevrilmişti.
2. Gönderen düzenlediğinde, yeni sürümü yeniden çeviririz.
3. Sizin dilinizde önceki çeviriniz ile yeni çeviriniz arasındaki farkı (diff) hesaplarız.
4. Bu farkı satır içinde gösteririz — tıpkı Git'in size neyin değiştiğini gösterdiği gibi.

Dolayısıyla İngilizcede "review by Tuesday" (Salı gününe kadar incele) "review by Thursday" (Perşembe gününe kadar incele) olduğunda, İspanyolca okuyan meslektaşınız yeniden okuması gereken yeniden çevrilmiş bir paragraf değil, vurgulanmış martes → jueves ifadesini görür.

Bu, sohbet hattını, talep üzerine çeviri yapan durum bilgisi olmayan (stateless) bir uç nokta olarak değil, durum bilgisi olan (stateful) izleyiciye özel bir önbellek olarak ele almayı gerektirdi. Belgeler ve ses buna ihtiyaç duymaz. Sohbet duyar.

Hat 3: Gerçek zamanlı paylaşılan notlar çevirisi

Sorun: Ev sahibi paylaşılan notlar bölmesini açar ve yazmaya başlar. Her katılımcı notları kendi dilinde, karakter karakter, belgenin yapısı — başlıklar, iç içe geçmiş listeler, kontrol listeleri, kod blokları — bozulmadan görür.

Bütçe: Sohbetle aynı (~yarım saniye), ancak iki ekstra kısıtlamayla:

• Çevrilen şey çeviri sırasında değişir. Ev sahibi hala yazıyor. Her tuş vuruşunda "tüm belgeyi" çeviren saf bir sistem titremeye neden olur ve API bütçesini yakar. Tüm belge yerine değişen birimin granülaritesinde çeviri yaparız.
• Yapı korunmalıdır. Bir çeviri modelinden üç iç içe geçmiş listesi olan bir markdown yığınını çevirmesini isterseniz, orijinaline benzeyen ancak hiyerarşisi inceltilmiş, öğeleri yeniden numaralandırılmış veya girintisi kaymış bir şey geri alırsınız. Modelin tüm yığını görmesine izin vermeyiz.

Notlar hattı sohbetten nasıl farklıdır

Yapısal koruma ana şeydir. Tek bir belge olarak değil, her liste öğesini bağımsız olarak çeviririz. Model şunu görür:

"Uyum incelemesi — Q2 teslimatları"

— değil:

"# Proje planı\n## Çeyrek\n- Uyum incelemesi — Q2 teslimatları\n- Tedarikçi puanlaması\n - 1. Kademe tedarikçiler..."

Sarmalayıcı belge — <ul>, başlıklar, girinti — her yaprak düğüm çevirisiyle değiştirilerek orijinal belgenin sahip olduğu aynı yapı kullanılarak istemci tarafında yeniden inşa edilir. Modelin hiyerarşiyi "iyileştirmesine" asla izin verilmez.

Notlar da sohbet düzenlemeleriyle aynı izleyiciye özel fark modelini kullanır: ev sahibi bir satırı değiştirirse, diğer dillerdeki izleyiciler yeni bir paragraf değil, vurgulanmış değiştirilen kelimeleri görür.

Hat 4: Eşzamanlı olmayan belge çevirisi

Sorun: Birisi sohbete 40 sayfalık bir PDF, bir Word belgesi, bir PowerPoint sunumu veya bir Excel tablosu bırakır. Her katılımcı kendi dilinde bir kopya talep edebilir. Çevrilmiş dosya orijinaline benzemelidir — aynı yazı tipleri, aynı tablolar, aynı sayfa numaraları, aynı başlıklar, yerinde aynı grafikler.

Bütçe: Gerçek zamanlı kısıt yoktur. Bir dakika iyidir. İki dakika iyidir. Kısıtlama sadakattir — çevrilmiş PDF orijinaline benzemiyorsa, alıcı ona güvenmez.

Bu hat neden sesle bir motor paylaşmıyor

Genel bir LLM, çok iyi bir tane bile olsa, size bir belgenin çevrilmiş metnini geri verecektir. Aynı düzene sahip çevrilmiş bir PDF geri vermez. Modelin "kaynakla hizalanması gereken sayfa sonu" veya "sütun genişliğini koruması gereken tablo hücresi" kavramı yoktur.

Bu yüzey için DeepL Document API'yi doğrudan kullanıyoruz. Dosyalardan çıkarılmış düz yazıyı değil, dosyaları dosya olarak çevirmek için özel olarak yapılandırılmıştır. DeepL şunları yönetir:

• PDF (düzen korunarak)
• DOCX, DOC
• PPTX
• XLSX

Belge DeepL'in hattına yüklenir, biçimlendirme bozulmadan sunucu tarafında çevrilir ve aynı biçimde geri döndürülür. Ardından sonucu kendi nesne depolamamıza yükleriz ve sohbette indirilebilir bir ek olarak gösteririz.

Bu neye mal oluyor ve neden bunu gizlemiyoruz

DeepL, belge başına en az 50.000 karakter faturalandırır — belge tek sayfa da olsa otuz sayfa da olsa, Pro katmanında dosya başına kabaca bir ABD dolarıdır. Bu maliyeti dosya başına ücret almak yerine biz üstleniriz; toplantının çeviri kullanımında faturalandırılan karakterler olarak görünür ve ürünün geri kalanının çeviri etkinliğini raporlama şekliyle eşleşen kelime birimlerine dönüştürülür.

Bu yüzey için DeepL'i seçtik çünkü dosyaları dosya olarak çevirmek tam olarak onun için yapıldığı iştir — daha iyisini yapmayı denemedik. Aynı durum tersi için geçerli değildir — DeepL, toplantılar için yaptığımız türden canlı bir ses hattı çalıştırmaz. Farklı sorunlar; farklı araçlar. "InterMIND çevirisini neyin çalıştırdığı"nın dürüst versiyonu "her hat için doğru motor"dur — "her yerde bizim motorumuz" değil.

Bu hattın sesin kapsamadığı dilleri kapsaması

Belge hattı seste 24'e kıyasla 30 dile ulaşır. Ekstra olanlar şunları içerir: Bulgarca, Yunanca, Estonca, Endonezyaca, Litvanca, Letonca, Slovakça, Slovence. (Arapça, ses kalitesi çıtımızın altındayken bu listede yer alırdı; artık gerçek zamanlı seçicide yer alıyor ve diğer her dil gibi çift başına puanları /benchmark adresinde herkese açık. Asimetri şimdi Hintçe için tersine çalışıyor — seste canlı, dosyalarda henüz değil.)

Bu asimetri gerçektir. Bir toplantıdaki Fransız katılımcının, toplantıyı Estonca dinleyemese bile sözleşme PDF'ini Estonca talep edebileceği anlamına gelir. Bunu tek bir sayıyla düzeltmek yerine seçicide işaretliyoruz. Gerekçe dil sayısı yazısında.

Hatların buluştuğu yer

Dört hat izole çalışmaz. Bir toplantı odası bunların birbirine değdiği yerdir ve dikişler önemlidir:

• Belge eki olan bir sohbet mesajı, metin için sohbet hattını ve dosya için belge hattını tetikler. Başka bir dildeki katılımcı, mesajın anında çevrildiğini ve ek çevirisinin indirilebilir olarak eşzamanlı olmayan bir şekilde geldiğini görür.
• Bir döküm satırını alıntılayan paylaşılan bir not, notlar ↔ ses arasında geçiş yapar. Döküm, ses hattının gönderenin dili için ürettiği şeydir; not çevirisi, kaynak atıfı korunarak herkesin kendi dilinde o alıntının izleyiciye özel bir kopyasını üretir.
• Toplantıdan sonra dışa aktarılan bir döküm, tüm sohbet boyunca sohbet tarzı metin hattını çalıştırır ve katılımcıların indirebileceği dil başına bir dosya üretir. Bu, sohbet çevirisiyle aynı kod yoludur, sadece toplu işlenmiştir.

Dil seçici tek bir UI parçasıdır. Altındaki altyapı, birbiriyle konuşan dört hattır.

Bilerek denemediğimiz şeyler

• "Birleşik bir çeviri modeli" yok. Ses, sohbet, notlar ve belgeleri yapan tek bir model inşa etmiyoruz. Gecikme ve sadakat dengesinde bir kazanan yoktur. Her yüzey için doğru motoru kullanırız.
• Sessiz yeniden yönlendirme yok. Dosya hattı bugün Hintçeye çeviremezse, sessizce ses motoruna geri dönüp çalışmış gibi yapmıyoruz — dosya seçici açığı gizlemek yerine işaretliyor.
• "200 dile çeviriyoruz" yok. Motorumuz 24 tane üretir. Canlı yüzeyler 24'ünü de yayınlar, belgeler 30 — ve pazarlama dostu tek bir sayı yerine, bir denetçinin önünde durması gereken çift başına kalite, zayıf çiftler dahil /benchmark adresinde yayınlanır.

Kendiniz deneyin

• Canlı demoyu deneyin — canlı ses hattını sesinizle, 24 ürün dilinin herhangi birinde çalıştırır. /benchmark puanlayan aynı hattır.
• Kıyaslamayı görün — gerçek trafikte çift başına, aylık kalite. Seçicideki her çift, güçlü veya zayıf, derin bağlantı verilebilir.
• Metodolojiyi okuyun — sayılar ne, ne değil, jüri kim.

Dört hat, dört motor, bir toplantı odası. Bu, eski how-it-works sayfasının dürüst bir yerine konmasıdır.

— Mind.com Ekibi

Kaynaklar: DeepL — desteklenen diller, DeepL — kullanım sayısı ve faturalandırma (dosya başına 50.000 karakter alt sınırı), FLORES-200; dahili hat bilgileri gönderilen koda göre doğrulandı, Ağustos 2026'da kontrol edildi.