InterMIND'ı ç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ı gibi tek bir "çeviri motoru" anlatıyor: "siz konuşuyorsunuz"dan "onlar duyuyor"a giden 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, her biri farklı bir sorunu farklı bir motorla, farklı bir gecikme bütçesi ve farklı bir kalite aralığıyla çözen dört ayrı çeviri hattı çalıştırır. Hatlar bir dil seçiciyi paylaşır. Motoru paylaşmaz.

"Nasıl çalışıyor?" sorusunun güncel yanıtı bu yazıdır.

Eşlikçi 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 iş olduğunu anlatır.

"Her şey için tek motor" neden yanlış

Canlı bir toplantı platformunun aynı anda yapması gereken en az dört iş vardır ve bu işler 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. Temel kısıt gecikmedir.
2. Gerçek zamanlı sohbet metni: Kısa, hızlı mesajlar. Düzenlemeler, alıntılar ve HTML yapısı korunur.
3. Gerçek zamanlı ortak notlar: Karakter karakter ortak yazım. Listeler, başlıklar ve onay kutuları gibi yapısal hiyerarşi çeviriden sağ çıkmak zorundadır.
4. Eşzamansız belge dosyaları: Sohbete bırakılan 40 sayfalık bir PDF. Gecikme bütçesi yoktur. Temel kısıt aslına uygunluktur: biçim, tablolar, sayfa numaraları, yazı tipi.

Dördünü birden yapmaya çalışan tek bir dev LLM çağrısı kurabilirsiniz. Biz denedik. Dördünde de kötü. Ses için gecikme bütçesi modelin düşünememesi demektir. Belgeler için aslına uygunluk bütçesi ise modelin düşünmek zorunda olması demektir. Bir sohbet düzenlemesi izleyicinin dilinde bir fark (diff) ister. 40 sayfalık bir PDF ise hiçbir token akışlı modelin sağlayamadığı biçim korumasını ister.

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

Hat 1: Gerçek zamanlı ses çevirisi

Sorun: Bir katılımcı Fransızca konuşuyor. Bir başkası Almanca, üçüncüsü Brezilya Portekizcesi, dördüncüsü Japonca dinlemek üzere katıldı. Her biri konuşmacıyı kendi dilinde, kendi kulağında, göz teması kurmayı mümkün kılacak 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 kaldığında, toplantı "İngilizceye geçelim" yönüne kayar.

Ses aslında nasıl akar

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

• ASR medya sunucusunda çalışır. Konuşmacının sesi WebRTC üzerinden kendi motorumuza, yani Fransa'daki OVH'de bulunan Mind API'ye gider 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. Kimse Arapça dinlemiyorsa Arapçaya hiçbir şey çevrilmez. Bu yüzden dört dilli bir toplantı, gerçekte kimlerin geldiği 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ı, asıl konuşmacının görüntüsüyle karıştırılmış kendi çevrilmiş ses kanalını alır. Herkes ortak bir "çevrilmiş toplantı" 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ıklarını takıp farklı diller dinleyebilir.

Toplantı ters gittiğinde bu neden önemli

Sekiz dilli 60 dakikalık bir görüşmede ilginç şekillerde şeyler bozulur: WebSocket'ler düşer, ASR bir özel adı geçici olarak yanlış yazıya döker, bir katılımcının ağı kararsızlaşır. Yukarıdaki mimari, arızaları yalıtmamızı sağlar. Bir izleyicinin sesindeki aksaklık diğer yedisini etkilemez, çünkü çeviri motoru "çeviri"yi hiç tek parça üretmedi. Paralel olarak sekiz tane üretti ve yalnızca etkilenenin 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önlendirmiyoruz. Gecikme bütçesi onları eler. Veri yerleşimi açısından da, bunu gerçekten önemseyen düzenlemeye tabi müşteriler için 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ümleleri üzerinde her ay çalıştırır. Hakem model belirtilmiştir (birincil Gemini 3.7 Flash, yedek Claude Sonnet 5). Medyan, p10, p90, en küçük, en büyük ve örneklem büyüklüğü dahil dağılımın tamamı 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 esnektir. Bir sohbet mesajının başka bir dilde belirmesi bir an sürebilir ve kimse umursamaz. İnsanların umursadığı, çevirinin doğru olup olmadığı ve düzenlemelerin anlamlı olup olmadığıdır.

Sohbet hattı aslında ne yapar

Her mesaj, ses hattının kullandığı ç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'i hiç görmez, yalnızca temiz düzyazıyı görür.
• Alıntılar bağımsız çevrilir. Bir mesajı yanıtlayıp 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 karakterden böleriz. Her parça kendi çeviri çağrısıdır. 4.000 karakterlik romanları modele tek seferde vermeyiz: başarısızlık biçimleri (kesilme, kaybolan paragraflar, cümle ortasında kopmalar) fazla çirkindir.
• Çeviri tembeldir. Bir IntersectionObserver kullanırız: bir mesaj yalnızca izleyicinin görünür alanına kaydırıldığında çevrilir. Uzun soluklu 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'de, başka dildeki izleyiciler için sohbet düzenlemelerinin davranışını değiştirdik. Eski davranış şuydu: biri bir mesajı düzenler, biz hepsini yeniden çevirirdik, siz taze 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üzenlediğinde yeni sürümü yeniden çeviririz.
3. Sizin dilinizde, önceki çevirinizle yeni çevirinizi karşılaştırıp farkı hesaplarız.
4. Bu farkı satır içinde gösteririz, tıpkı Git'in neyin değiştiğini göstermesi gibi.

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

Bu, sohbet hattına isteğe göre çeviri yapan durumsuz bir uç nokta olarak değil, izleyici başına durumlu bir önbellek olarak yaklaşmayı gerektirdi. Belgelerin ve sesin buna ihtiyacı yok. Sohbetin var.

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

Sorun: Ev sahibi ortak not 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, yapılacaklar 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. Ev sahibi hâlâ yazıyor. Her tuş vuruşunda "tüm belgeyi" çeviren naif bir sistem titreşim üretir ve API bütçesini yakar. Biz tüm belge yerine değişen birim ayrıntısında çeviri yaparız.
• Yapı sağ çıkmalı. Bir çeviri modelinden üç iç içe listeli bir markdown yığınını çevirmesini isterseniz, özgününe benzeyen ama hiyerarşisi ince biçimde düzleşmiş, maddeleri 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 maddesini tek bir belge olarak değil, bağımsız çeviririz. Model şunu görür:

"Uyumluluk incelemesi — 2. çeyrek teslimatları"

şunu değil:

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

Çevreleyen belge (<ul>, başlıklar, girintileme) istemci tarafında, özgün belgenin yapısı kullanılarak ve her yaprak düğüm kendi çevirisiyle değiştirilerek yeniden kurulur. Model hiyerarşiyi "iyileştirmeye" asla izin almaz.

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

Hat 4: Eşzamansız belge ç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. Çevrilmiş dosya özgününe benzemelidir: aynı yazı tipleri, aynı tablolar, aynı sayfa numaraları, aynı üst bilgiler, aynı grafikler yerinde.

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: çevrilmiş 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ı yerleşimle çevrilmiş bir PDF vermez. Modelin "kaynakla hizalanması gereken sayfa sonu" ya da "sütun genişliğini koruması gereken tablo hücresi" diye bir kavramı yoktur.

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

• PDF (yerleşim korumalı)
• DOCX, DOC
• PPTX
• XLSX

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

Bunun maliyeti nedir ve neden saklamıyoruz

DeepL, belge başına en az 50.000 karakter faturalar. Belge bir sayfa da olsa otuz sayfa da olsa, Pro katmanında bu dosya başına kabaca bir ABD dolarıdır. Dosya başına ücret almak yerine bu maliyeti biz üstleniriz. Maliyet, toplantının çeviri kullanımında faturalanan karakterler olarak görünür ve ürünün geri kalanının çeviri etkinliğini raporlama biçimiyle uyumlu 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 da onun için yapıldığı 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 kapsadığı, sesin kapsamadığı diller

Belge hattı ses için 23 dile karşılık 30 dile ulaşır. Fazladan olanlar arasında Bulgarca, Yunanca, Estonca, Endonezce, Litvanca, Letonca, Slovakça ve Slovence var. (Arapça da bu listede ve fazladan olanlardan biri: ses kalitesi çıtamızın altında olduğu sürece gerçek zamanlı seçiciden çekilmiştir. Dil çifti başına puanları /benchmark sayfasında herkese açık kalır ve onu geri getirecek olan da bu sayıdır. Asimetri Hintçe için ters yönde işler: seste canlı, dosyalarda henüz değil.)

Bu asimetri gerçektir. Bir toplantıdaki Fransız katılımcı, toplantıyı Estonca dinleyemese de sözleşme PDF'ini Estonca isteyebilir. Bunu tek bir sayıyla yumuşatmak yerine seçicide işaretleriz. Gerekçesi dil sayısı yazısında var.

Hatların buluştuğu yer

Dört hat birbirinden yalıtılmış çalışmaz. Toplantı odası hatların birbirine dokunduğu yerdir ve bu birleşim yerleri önemlidir:

• Belge eki olan bir sohbet mesajı, metin için sohbet hattını, dosya için belge hattını tetikler. Başka dildeki katılımcı mesajın hemen çevrilmiş halini görür. Ekin çevirisi ise indirilebilir bir dosya olarak eşzamansız ulaşır.
• 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 diğer herkesin dilinde, kaynak atfı korunmuş, 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ı ise birbiriyle konuşan dört hattır.

Bilerek denemediklerimiz

• "Birleşik çeviri modeli" yok. Ses, sohbet, notlar ve belgeleri yapan tek bir model kurmuyoruz. Gecikmeye karşı aslına uygunluk dengesinin bir kazananı yok. Her yüzey için doğru motoru kullanıyoruz.
• Sessiz yeniden yönlendirme yok. Dosya hattı bugün Hintçeye çeviremiyorsa, sessizce ses motoruna geri düşüp işe yaramış gibi yapmayız. Dosya seçici boşluğu gizlemek yerine işaretler.
• "200 dile çeviriyoruz" yok. Motorumuz 24 dil üretir. Canlı yüzeylerde 23, belgelerde 30 dil sunulur. Pazarlamaya uygun tek bir sayı yerine, bir denetçinin karşısında durması gereken dil çifti başına kalite, daha zayıf çiftler 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 puanlarını üreten aynı hat.
• Kıyaslamayı görün: gerçek trafikte dil çifti başına, ay başına 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ığı ve hakemin kim olduğu.

Dört hat, dört motor, tek 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 faturalama (dosya başına 50.000 karakter asgari), FLORES-200. Dahili hat bilgileri, gönderilen kodla karşılaştırılarak doğrulanmıştır, Ağustos 2026'da kontrol edilmiştir.