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

mind.com üzerindeki eski /product/overview/how-it-works sayfası, birkaç büyük sürüm geride kaldı. Sayfa, çoğu satıcı sayfasında olduğu gibi tek bir "çeviri motoru"nu anlatıyor: "siz konuşursunuz"dan "onlar duyar"a uzanan tek bir büyük ok. Bu tablo 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ır. Her biri farklı bir sorunu, farklı bir motorla, farklı bir gecikme bütçesi ve farklı bir kalite aralığıyla çözer. Dil seçiciyi paylaşırlar. Motoru paylaşmazlar.

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

Eşlikçi bir yazı: "Kaç dili destekliyorsunuz?" her hattın neleri kapsadığını (23 / 23 / 30 / 17) anlatır. Bu yazı ise her hattın ne yaptığını ve neden ayrı bir hat olduğunu anlatır.

"Her şey için tek motor" neden bir yalan

Canlı bir toplantı platformunun aynı anda yapması gereken en az dört iş vardır ve bunlar birbiriyle bağdaşmayan yönlere çeker:

1. Gerçek zamanlı ses: Ses girer, konuşmacı hâlâ konuşurken çevrilmiş ses çıkar; her izleyici kendi dilinde dinler. Zorlayıcı kısıt gecikmedir.
2. Gerçek zamanlı sohbet metni: Kısa mesajlar, hızlı; düzenlemeler, alıntılar ve HTML yapısı korunur.
3. Gerçek zamanlı ortak notlar: Karakter karakter ortak yazım; yapısal hiyerarşi (listeler, başlıklar, onay kutuları) çeviriden sağ çıkmalıdır.
4. Eşzamansız doküman dosyaları: Sohbete bırakılan 40 sayfalık bir PDF. Gecikme bütçesi yoktur. Zorlayıcı kısıt aslına uygunluktur: biçimlendirme, tablolar, sayfa numaraları, yazı tipi.

Dördünü birden yapmaya çalışan tek bir devasa LLM çağrısı kurabilirsiniz. Biz denedik. Dördünde de kötü. Ses için gecikme bütçesi modelin düşünemeyeceği anlamına gelir; doküman için aslına uygunluk bütçesi ise modelin düşünmek zorunda olduğu anlamına gelir. Bir sohbet düzenlemesi, izleyicinin dilinde bir fark (diff) ister; 40 sayfalık bir PDF ise token akışı yapan hiçbir modelin sunamadığı bir biçim korumasına ihtiyaç duyar.

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. Bir diğeri Almanca, üçüncüsü Brezilya Portekizcesi, dördüncüsü Japonca katılmış. Her biri konuşmacıyı kendi dilinde, kendi kulağında, göz teması kurmaya imkân verecek kadar kısa bir gecikmeyle duymalı.

Bütçe: Dinleyici bunun için asla beklememeli. Çevrilmiş konuşma, insanların üstüne konuşmaya başlayacağı kadar geride kalırsa toplantı "hadi İngilizceye geçelim" noktasına doğru kayar.

Ses gerçekte nasıl hareket eder

Açıkça belirtmeye değer birkaç nokta:

• ASR medya sunucusunda çalışır. Konuşmacının sesi WebRTC üzerinden kendi motorumuza (Fransa, OVH'deki Mind API) ulaşır ve görüşmeyi taşıyan aynı sunucuda tanınır; tarayıcı yalnızca ses gönderir ve sözcükleri geri alır. Ayrı bir konuşma tanıma sağlayıcısı yoktur ve çeviri başlamadan önce fazladan bir sıçrama yoktur. (Sohbetteki sesli notlar istisnadır: bunların konuşmadan metne dönüşümü, varsayılan yapay zekâ ağ geçidinin konuşma servisi olan Azure AI Speech üzerinde çalışır.)
• Çeviri tek bir dağıtım değildir. Motor, izleyici başına değil, odada bulunan hedef dil başına çeviri yapar: bir dile çeviri, o dildeki ilk dinleyici çevrilmiş akış istediğinde başlar, Almanca seçen üç katılımcı tek bir Almanca çeviriyi paylaşır ve kimse Arapça dinlemiyorsa Arapçaya hiçbir şey çevrilmez. Bu yüzden dört dilli bir toplantı, gerçekte kimlerin katıldığı noktasına kadar kırk dilli bir toplantıyla aynı maliyettedir: hiçbir katılımcının dinlemediği dillere asla çeviri yapmayız.
• Sentezlenen konuşma izleyici başınadır. Her katılımcı, özgün konuşmacının videosuyla karıştırılmış kendi çevrilmiş ses kanalını alır. Herkes ana bir "çevrilmiş toplantı"yı izlemez; aynı toplantıyı izler, yalnızca kişisel ses kanalı seçtiği dile çevrilmiştir. Bu yüzden aynı fiziksel odadaki iki kişi kulaklık takıp farklı dilleri duyabilir.

Bir toplantı ters gittiğinde bunun neden önemli olduğu

Sekiz dilli 60 dakikalık bir görüşmede işler ilginç şekillerde bozulur: WebSocket'ler kopar, ASR bir özel ismi geçici olarak yanlış yazıya döker, bir katılımcının ağı titrer. Yukarıdaki mimari arızaları yalıtmamızı sağlar: bir izleyicinin sesindeki aksama diğer yedisini etkilemez, çünkü çeviri motoru hiçbir zaman "tek bir çeviri" üretmedi; paralel olarak sekiz tane üretti ve yalnızca etkilenen kişinin toparlanması gerekir.

Motorun kendisi bize aittir ve kendi altyapımızda barındırılır. Gerçek zamanlı sesi üçüncü taraf genel amaçlı LLM'ler üzerinden yönlendirmeyiz. Gecikme bütçesi onları eler; veri yerleşimi hikâyesi de gerçekten buna önem veren düzenlemeye tabi müşteriler için onları eler.

Ses kalitesi hakkında yayımladıklarımız: /benchmark, üretimdeki ses hattını yayımlanmış her dil çifti için FLORES-200 cümlelerine karşı her ay çalıştırır. Hakem açıkça belirtilmiştir (birincil Gemini 3.7 Flash, yedek Claude Sonnet 5). Medyan, p10, p90, en düşük, en yüksek ve örneklem boyutunu içeren tüm dağılım sayfadadı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ı, gönderildiği anda her katılımcı için kendi dilinde çevrilir. Buna düzenlemeler de dahildir ve düzenlemelerin yeniden çeviri gibi değil, düzenleme gibi görünmesi gerekir.

Bütçe: Sesten daha gevşek. Bir sohbet mesajının başka bir dilde görünmesi bir an sürebilir ve kimse bunu umursamaz. İnsanların önemsediği şey çevirinin doğru olup olmadığı ve düzenlemelerin anlamlı olup olmadığıdır.

Sohbet hattı gerçekte ne yapar

Her mesaj, ses hattının kullandığı aynı çeviri motorundan geçer; ancak ön ve son işlemler farklıdır:

• 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 özgün etiketlerle yeniden sarmalarız. Model HTML'yi hiç görmez; temiz düzyazı görür.
• Alıntılar bağımsız çevrilir. Bir mesaja yanıt verip onu alıntılarsanız, [QUOTE]…[/QUOTE] bloğu ile yeni içerik ayrı birimler olarak çevrilir; böylece model ikisini birbirine karıştıramaz.
• Uzun mesajlar parçalara bölünür. Paragraf sınırlarında, parça başına 1.000 karakterde böleriz. Her parça kendi çeviri çağrısıdır. 4.000 karakterlik romanları modele tek seferde vermeyiz; hata biçimleri (kesilme, kaybolan paragraflar, cümle ortasında kopma) çok çirkindir.
• Çeviri tembeldir (lazy). Bir IntersectionObserver kullanırız: bir mesaj yalnızca izleyicinin görünüm alanına kaydırıldığında çevrilir. Uzun süredir açık bir kanalda dil değiştirmek, geçmişteki her çeviri API çağrısını yeniden oynatırdı. Artık oynatmıyor.

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

v1.2 sürümünde, başka bir dildeki izleyiciler için sohbet düzenlemelerinin davranışını değiştirdik. Eski davranış şuydu: biri bir mesajı düzenler, biz her şeyi yeniden çeviririz, siz yepyeni bir paragraf görür ve neyin değiştiğini kendiniz bulmak zorunda kalırdınız.

Yeni davranış:

1. Özgün mesaj zaten sizin dilinize çevrilmişti.
2. Gönderen düzenleyince yeni sürümü yeniden çeviriyoruz.
3. Önceki çevirinizle yeni çevirinizin farkını, sizin dilinizde hesaplıyoruz.
4. Bu farkı satır içinde gösteriyoruz; Git'in neyin değiştiğini gösterdiği gibi.

Yani İngilizcede "review by Tuesday" ifadesi "review by Thursday" olduğunda, İspanyolca okuyan iş arkadaşınız yeniden çevrilmiş bir paragraf yerine vurgulanmış martes → jueves değişimini görür ve baştan okumak zorunda kalmaz.

Bu, sohbet hattına istek üzerine çeviri yapan durumsuz bir uç nokta olarak değil, izleyici başına durumlu bir önbellek olarak yaklaşmayı gerektirdi. Doküman ve ses buna ihtiyaç duymaz. Sohbet duyar.

Hat 3: Gerçek zamanlı ortak not çevirisi

Sorun: Toplantı sahibi ortak notlar panelini açar ve yazmaya başlar. Her katılımcı notları kendi dilinde, karakter karakter görür; belgenin yapısı (başlıklar, iç içe listeler, kontrol listeleri, kod blokları) bozulmadan kalır.

Bütçe: Sohbetle aynı, ancak iki ek kısıtla:

• Çevrilen şey çeviri sırasında değişir. Toplantı sahibi hâlâ yazıyordur. Her tuş vuruşunda "tüm belgeyi" çeviren naif bir sistem titreşim üretir ve API bütçesini yakar. Tüm belgeyi değil, değişen birimin ayrıntı düzeyinde çeviri yaparız.
• Yapı sağ çıkmalıdır. Bir çeviri modelinden üç iç içe liste içeren bir markdown yığınını çevirmesini isterseniz, özgününe benzeyen ama hiyerarşisi ince biçimde düzleşmiş, öğeleri yeniden numaralanmış ya da girintisi kaymış bir şey alırsınız. Modelin tüm yığını görmesine izin vermeyiz.

Not hattı sohbetten nasıl ayrılır

Ana fark yapının korunmasıdır. Her liste öğesini tek bir belge olarak değil, bağımsız olarak çeviririz. Model şunu görür:

"Uyumluluk incelemesi — 2. çeyrek çıktıları"

şunu değil:

"# Proje planı\n## Çeyrek\n- Uyumluluk incelemesi — 2. çeyrek çıktıları\n- Tedarikçi puanlaması\n - 1. kademe tedarikçiler..."

Saran belge (<ul>, başlıklar, girinti) istemci tarafında, özgün belgenin sahip olduğu aynı yapı kullanılarak ve her yaprak düğüm kendi çevirisiyle değiştirilerek yeniden kurulur. Model hiyerarşiyi "iyileştirmeye" hiçbir zaman fırsat bulamaz.

Notlar ayrıca sohbet düzenlemeleriyle aynı izleyici başına fark modelini kullanır: toplantı sahibi bir satırı değiştirirse, diğer dillerdeki izleyiciler yeni bir paragraf değil, değişen sözcüklerin vurgulandığını görür.

Hat 4: Eşzamansız doküman çevirisi

Sorun: Biri sohbete 40 sayfalık bir PDF, bir Word belgesi, bir PowerPoint sunumu ya da bir Excel tablosu bırakır. Her katılımcı kendi dilinde bir kopya isteyebilir. Çevrilen dosya özgününe benzemelidir: aynı yazı tipleri, aynı tablolar, aynı sayfa numaraları, aynı üst bilgiler, grafikler yerlerinde.

Bütçe: Gerçek zamanlı kısıt yok. Bir dakika sorun değil. İki dakika da sorun değil. Kısıt aslına uygunluktur: çevrilen PDF özgününe benzemiyorsa alıcı ona güvenmez.

Bu hat neden sesle motor paylaşmaz

Genel amaçlı bir LLM, çok iyi olsa bile, size bir belgenin çevrilmiş metnini verir. Aynı düzene sahip çevrilmiş bir PDF vermez. Modelde "kaynakla hizalanması gereken sayfa sonu" ya da "sütun genişliğini korumak zorunda olan tablo hücresi" kavramı yoktur.

Bu yüzey için doğrudan DeepL Document API kullanırız. Dosyalardan çıkarılmış düzyazıyı değil, dosyaları dosya olarak çevirmek için tasarlanmıştır. DeepL şunları işler:

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

Belge DeepL'in hattına yüklenir, sunucu tarafında biçimlendirme bozulmadan çevrilir ve aynı biçimde geri döner. Ardından sonucu kendi nesne depolamamıza yükler ve sohbette indirilebilir bir ek olarak sunarız.

Bunun maliyeti nedir ve neden gizlemiyoruz

DeepL belge başına en az 50.000 karakter faturalandırır; belge bir sayfa da olsa otuz sayfa da olsa, Pro kademesinde dosya başına kabaca bir ABD doları eder. Bu maliyeti dosya başına ücret yansıtmak yerine biz üstleniriz; toplantının çeviri kullanımında faturalanan karakterler olarak görünür ve ürünün çeviri etkinliğini raporlama biçimine uyan sözcük birimlerine dönüştürülür.

Bu yüzey için DeepL'i seçtik, çünkü dosyaları dosya olarak çevirmek tam olarak onun yapmak için üretildiği iştir; daha iyisini yapmaya çalışmadık. Tersi için aynısı geçerli değil: DeepL, toplantılar için kurduğumuz türden bir canlı ses hattı çalıştırmaz. Farklı sorunlar, farklı araçlar. "InterMIND çevirisini ne güçlendiriyor?" sorusunun dürüst yanıtı "her hat için doğru motor"dur; "her yerde bizim motorumuz" değil.

Bu hattın kapsayıp sesin kapsamadığı diller

Doküman hattı sesteki 23'e karşılık 30 dile ulaşır. Ekstralar arasında şunlar var: Bulgarca, Yunanca, Estonca, Endonezce, Litvanca, Letonca, Slovakça, Slovence. (Arapça da bu listede ve ekstralardan biri: sesteki kalitesi çıtamızın altında olduğu sürece gerçek zamanlı seçiciden çekilmiştir; çift bazındaki puanları /benchmark sayfasında herkese açık kalır ve onu geri getirecek olan da bu sayıdır. Asimetri Hintçe için tersine işler: seste canlı, dosyalarda henüz değil.)

Bu asimetri gerçektir. Fransızca konuşan bir katılımcı, toplantıyı Estonca dinleyemese de sözleşme PDF'sini Estonca isteyebilir. Bunu tek bir sayıyla örtbas etmek yerine seçicide işaretleriz. Gerekçesi dil sayısı yazısında anlatılıyor.

Hatların buluştuğu yer

Dört hat birbirinden yalıtılmış çalışmaz. Bir toplantı odası, birbirlerine dokundukları yerdir ve bu birleşim yerleri önemlidir:

• Doküman eki olan bir sohbet mesajı, metin için sohbet hattını, dosya için doküman hattını tetikler. Başka bir dildeki katılımcı mesajı hemen çevrilmiş görür; ek çevirisi ise indirilebilir bir dosya olarak eşzamansız biçimde gelir.
• Bir transkript satırını alıntılayan ortak bir not, notlar ↔ ses sınırını aşar. Transkript, ses hattının gönderenin dili için ürettiği şeydir; not çevirisi bu alıntının, kaynak atfı korunarak, diğer 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 ve katılımcıların indirebileceği, dil başına bir dosya üretir. Bu, sohbet çevirisiyle aynı kod yoludur; yalnızca toplu çalışır.

Dil seçici tek bir arayüz parçasıdır. Altındaki altyapı, birbirleriyle konuşan dört hattır.

Bilerek denemediklerimiz

• "Birleşik çeviri modeli" yok. Ses, sohbet, notlar ve dokümanları birlikte yapan tek bir model kurmuyoruz. Gecikme ile aslına uygunluk arasındaki dengenin bir galibi yok. Her yüzey için doğru motoru kullanırız.
• Sessiz yeniden yönlendirme yok. Dosya hattı bugün Hintçeye çeviri yapamıyorsa, sessizce ses motoruna geri dönüp işe yaramış gibi davranmayız; dosya seçici boşluğu gizlemek yerine işaretler.
• "200 dile çeviri yapıyoruz" yok. Motorumuz 24 dil üretir. Canlı yüzeyler 23, dokümanlar 30 dil sunar. Pazarlamaya uygun tek bir sayı yerine, bir denetçinin karşısına çıkması gereken çift bazlı kalite, daha zayıf çiftler de dahil, /benchmark sayfasında yayımlanır.

Kendiniz deneyin

• Canlı demoyu deneyin: canlı ses hattını sizin sesinizle, 23 ürün dilinden herhangi birinde çalıştırır. /benchmark puanını üreten aynı hat.
• Benchmark'a bakın: gerçek trafikte çift bazında, aylık kalite. Seçicideki her çift, güçlü ya da zayıf, doğrudan bağlantıyla erişilebilir.
• Metodolojiyi okuyun: sayıların ne olduğu, ne olmadığı, hakemin kim olduğu.

Dört hat, dört motor, tek bir toplantı odası. Eski how-it-works sayfasının dürüst karşılığı budur.

— Mind.com Ekibi

Kaynaklar: DeepL — desteklenen diller, DeepL — kullanım sayımı ve faturalandırma (dosya başına 50.000 karakter asgari), FLORES-200; dahili hat bilgileri yayındaki kodla doğrulanmıştır, Ağustos 2026'da kontrol edilmiştir.