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 motoru" tanımlıyor — "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 dört ayrı çeviri hattı çalıştırıyor ve her biri farklı bir motorla, farklı bir gecikme bütçesiyle ve farklı bir kalite aralığıyla farklı bir sorunu çözüyor. Bir dil seçiciyi paylaşıyorlar. Bir motor paylaşmıyorlar.

İşte "nasıl çalışıyor?" sorusunun güncellenmiş yanıtı.

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

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

Gerçek zamanlı bir toplantı platformunun aynı anda yapması gereken en az dört iş var ve bunlar birbirleriyle uyuşmayan yönlere çekiyor:

1. Gerçek zamanlı ses — ses girer, çevrilmiş ses çıkar, 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 — harf harf işbirlikçi yazım, çeviriden sağ çıkması gereken yapısal hiyerarşiyle (listeler, başlıklar, onay kutuları).
4. Zaman uyumsuz belge dosyaları — sohbete bırakılan 40 sayfalık bir PDF. Gecikme bütçesi yok. Zor kısıt sadakattir — biçimlendirme, tablolar, sayfa numaraları, font.

Dördünü de yapmaya çalışan tek dev bir LLM çağrısı kurabilirsiniz. Denedik. Dördünde de kötü.

Ses için gecikme bütçesi, modelin düşünememesi anlamına gelir; belgeler için sadakat bütçesi, modelin düşünmesi gerekmesi anlamına gelir. Bir sohbet düzenlemesi izleyicinin dilinde bir diff gerektirir; 40 sayfalık bir PDF hiçbir token akış modelinin 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ıldı. Her birinin konuşmacıyı kendi dilinde, kendi kulağında, göz temasını mümkün kılacak kadar kısa bir gecikmeyle dinlemesi gerekiyor.

Bütçe: Uçtan uca bir saniyenin altında. ~1.2 saniyeyi geçen herhangi bir şey ve konuşma 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ılması değer birkaç şey:

• ASR medya sunucusunda çalışır. Konuşmacının sesi WebRTC üzerinden kendi motorumuza — OVH, Fransa'daki Mind API'ye — seyahat eder ve aramayı taşıyan sunucuda tanınır; tarayıcı yalnızca ses gönderir ve kelimeleri geri alır. Çeviri başlamadan önce ayrı bir konuşma satıcısı veya ek bir atlama yok. (Sohbet sesli notları istisnadır: bunların konuşmadan metne işlemi Azure AI Speech'te, varsayılan AI ağ geçidinin konuşma hizmetinde çalışır.)
• Çeviri tek bir fan-out değildir. Motor odada bulunan her hedef dile göre çevirir, her izleyiciye göre değil: bir dile çeviri, o dile çevrilmiş akış isteyen ilk dinleyici olduğunda başlar, Almanca seçen üç katılımcı bir Almanca çeviriyi paylaşır ve Arapça dinleyen kimse yoksa Arapçaya hiçbir şey çevrilmez. Bu nedenle dört dilli bir toplantı, kimin gerçekten katıldığı noktasına kadar kırk dilli bir toplantıyla aynı maliyete sahiptir — hiçbir katılımcının dinlemediği dillere asla çevirmeyiz.
• Sentezlenmiş konuşma her izleyiciye özeldir. Her katılımcı, orijinal konuşmacının videosuyla karıştırılmış kendi çevrilmiş ses parçasını alır. Onlar ana bir "çevrilmiş toplantı" izlemiyorlar — aynı toplantıyı izliyorlar, kişisel ses kanalları seçtikleri dile çevrilmiş olarak. Bu nedenle aynı fiziksel odadaki iki kişi kulaklık takıp farklı diller dinleyebilir.

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ış transkribe eder, bir katılımcının ağı dalgalanır. Yukarıdaki mimari, başarısızlıkları izole etmemizi sağlayan şeydir: bir izleyicinin sesinde oluşan bir sorun diğer yedisini etkilemez, çünkü çeviri motoru zaten "çeviriyi" üretmemiştir — paralel olarak sekiz tane üretmiştir ve yalnızca etkilenen olanın kurtarması 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 ikameti hikayesi, gerçekten önemseyen düzenlenmiş 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 FLORES-200 cümlelerine karşı her ay çalıştırır. Hakem adlandırılmıştır (birincil Gemini 3.7 Flash, yedek Claude Sonnet 5). Tam dağılım — medyan, p10, p90, min, maks, örneklem boyutu — sayfada. 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ı, gönderildiği anda her katılımcı için kendi dilinde ç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ı başka bir dilde görünmesi için yarım saniye alabilir ve kimse umursamaz. İnsanların umursadığı, ç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 — ama 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 çeviririz, çeviririz, sonra sonucu orijinal etiketlerde yeniden sararız. Model HTML'yi hiç 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çalanır. Paragraf sınırlarında her parça için 1.000 karakterde bölüyoruz. Her parça kendi çeviri çağrısıdır. 4.000 karakterlik romanları tek seferde modele beslemiyoruz — başarısızlık modları (kesilme, kayıp paragraflar, cümle ortası kesilmeler) çok çirkin.
• Çeviri tembelidir. 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 dil değiştirmek geçmişte her çeviri API çağrısını geçmişten 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 tümünü 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önderici düzenlediğinde, yeni sürümü yeniden çeviririz.
3. Önceki çeviriniz ve yeni çeviriniz arasındaki diff'i sizin dilinizde hesaplarız.
4. Bu diff'i satır içinde gösteririz — Git'in size neyin değiştiğini gösterdiği gibi.

Böylece İngilizce'de "review by Tuesday" "review by Thursday" olduğunda, İspanyolca okuyan meslektaşınız martes → jueves vurgulanmış olarak görür, yeniden okuması gereken yeniden çevrilmiş bir paragraf değil.

Bu, sohbet hattını durumsuz bir talep üzerine çeviri uç noktası olarak değil, durumlu izleyici başına 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, harf harf, belgenin yapısıyla — başlıklar, iç içe listeler, kontrol listeleri, kod blokları — bozulmamış olarak görür.

Bütçe: Sohbetle aynı (~yarım saniye), ama iki ek 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 titreme üretir ve API bütçesini yakar. Tüm belge yerine değişen birim granülaritesinde çeviririz.
• Yapı sağ çıkmalı. Bir çeviri modelinden üç iç içe listeden oluşan bir markdown yığınını çevirmesini isterseniz, orijinaline benzeyen ama 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ı

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

"Uyumluluk incelemesi — Q2 teslimatları"

— değil:

"# Proje planı\n## Çeyrek\n- Uyumluluk incelemesi — Q2 teslimatları\n- Satıcı puanlaması\n - Tier 1 satıcılar..."

Sarmalayan belge — <ul>, başlıklar, girinti — istemci tarafında, orijinal belgenin sahip olduğu aynı yapı kullanılarak yeniden oluşturulur, her yaprak düğüm çevirisiyle değiştirilir. Model hiyerarşiyi "iyileştirme" fırsatı asla bulamaz.

Notlar ayrıca sohbet düzenlemeleriyle aynı izleyici başına diff modelini kullanır: ev sahibi bir satırı değiştirirse, diğer dillerdeki izleyiciler değiştirilen kelimeleri vurgulanmış olarak görür, yeni bir paragrafı değil.

Hat 4: Zaman uyumsuz belge çevirisi

Sorun: Biri 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 isteyebilir. Çevrilmiş dosya orijinaline benzemeli — aynı fontlar, aynı tablolar, aynı sayfa numaraları, aynı başlıklar, aynı grafikler yerinde.

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

Bu hat neden sesle motor paylaşmıyor

Genel bir LLM, çok iyi biri bile, size bir belgenin çevrilmiş metnini geri verecektir. Aynı düzene sahip çevrilmiş bir PDF geri vermeyecektir. Modelin "kaynağa 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ırız. 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ı işler:

• PDF (düzen korumasıyla)
• DOCX, DOC
• PPTX
• XLSX

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

Bu ne kadara mal oluyor ve neden gizlemiyoruz

DeepL belge başına en az 50.000 karakter faturalandırır — Pro katmanında dosya başına kabaca bir ABD doları, belge bir sayfa mı yoksa otuz sayfa mı olduğuna bakılmaksızın. Bu maliyeti dosya başına ücretlendirmek yerine emeriz; toplantının çeviri kullanımında faturalandırılan karakterler olarak görünür, ürünün geri kalanının çeviri etkinliğini raporlama şekliyle eşleşen kelime birimlerine dönüştürülür.

DeepL'i bu yüzey için seçtik çünkü dosyaları dosya olarak çevirmek tam olarak onun için yapıldığı iş — daha iyisini yapmayı denemedik. Ters yönünde aynı şey doğru değil — DeepL, toplantılar için inşa ettiğimiz türden bir canlı ses hattı çalıştırmaz. Farklı sorunlar; farklı araçlar. "InterMIND çevirisini ne çalıştırıyor?"un 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ı 30 dile ulaşır, ses için 23'e karşılık. Ekstralar şunları içerir: Bulgarca, Yunanca, Estonca, Endonezce, Litvanca, Letonca, Slovakça, Slovence. (Arapça da bu listede ve ekstralardan biri: ses kalitesi çubuğumuzun altındayken gerçek zamanlı seçiciden çekildi ve çift başına puanları /benchmark üzerinde herkese açık kalır — o sayı onu geri getirendir. Asimetri Hindi için diğer yönde çalışır — seste canlı, dosyalarda henüz değil.)

Bu asimetri gerçektir. Bir toplantıdaki Fransız katılımcının toplantıyı Estonca dinleyemediği halde sözleşme PDF'ini Estonca isteyebileceği anlamına gelir. Tek bir sayıyla düzeltmek yerine seçicide işaretleriz. Gerekçe dil sayısı yazısında.

Hatların buluştuğu yer

Dört hat izole olarak çalışmaz. Bir toplantı odası onların birbirine dokunduğu 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 zaman uyumsuz olarak indirilebilir olarak geldiğini görür.
• Transkript satırını alıntılayan paylaşılan bir not notlar ↔ ses'i geçer. Transkript, ses hattının gönderenin dili için ürettiği şeydir; not çevirisi, o alıntının kaynak atıfı korunarak herkesin dilinde izleyici başına bir kopyasını üretir.
• Toplantıdan sonra dışa aktarılan bir transkript tüm konuşma üzerinde sohbet tarzı metin hattını çalıştırır, katılımcıların indirebileceği dil başına bir dosya üretir. Bu, sohbet çevirisiyle aynı kod yoludur, sadece toplu halde.

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

Bilinçli olarak denemediğimiz şeyler

• "Birleşik çeviri modeli" yok. Ses, sohbet, notlar ve belgeleri yapan tek bir model inşa etmiyoruz. Gecikme ve sadakat dengesinin bir kazananı yok. Her yüzey için doğru motoru kullanırız.
• Sessiz yeniden yönlendirme yok. Dosya hattı bugün Hindi'ye çeviremezse, sessizce ses motoruna geri dönüp çalıştığını göstermeyiz — dosya seçici boşluğu gizlemek yerine işaretler.
• "200 dile çeviriyoruz" yok. Motorumuz 24 yayıyor. Canlı yüzeyler 23, belgeler 30 gönderir — ve pazarlama dostu tek bir sayı yerine, bir denetçinin önünde durması gereken çift başına kalite /benchmark adresinde yayınlanır, zayıf çiftler dahil.

Kendiniz deneyin

• Canlı demoyu deneyin — canlı ses hattını sesinize karşı, 23 ürün dilinden herhangi birinde çalıştırır. /benchmark puanlayan aynı hat.
• Benchmark'u görün — gerçek trafikte çift başına, ay başına kalite. Seçicideki her çift, güçlü veya zayıf, derin bağlantı verilebilir.
• Metodolojiyi okuyun — sayılar ne, ne değil, hakem kim.

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

— Mind.com Ekibi

Kaynaklar: DeepL — desteklenen diller, DeepL — kullanım sayısı ve faturalandırma (dosya başına 50.000 karakter minimum), FLORES-200; iç hat gerçekleri gönderilen koda karşı doğrulandı, Ağustos 2026'da kontrol edildi.