Makine Çevirisi Sonrası Düzeltme (MTPE): Nedir, Nasıl Çalışır ve Nasıl Daha İyi Yapılır

Yapay zeka mühendisi olmamın bir sebebi de kendi romanımı çevirmeye çalışmamdı. Yerelleştirme dünyasındaki herkesin farklı bir adla bildiği o kavramla ilk o zaman karşılaştım: Metni makineden geçirirsiniz, sonra bir insan üzerinden geçip düzeltir. Teknik olarak buna makine çevirisi sonrası düzeltme (MTPE) deniyor ve 2026 itibarıyla profesyonel çeviri dünyasında en yaygın kullanılan yöntem bu.

Kulağa mantıklı bir fikir gibi geliyor. Ancak gelişmiş büyük dil modellerinin (LLM) hüküm sürdüğü bu dönemde, bu yöntemin alışılagelmiş uygulanma biçimi artık eskidi. Önce makineye tam bir tur çeviri yaptırıp ardından bir insana her şeyi baştan sona düzelttirmek, hem insan emeğini hem de işlem gücünü yanlış bir sıralamayla harcamak demek.

Bunun altında çok daha ucuz ve daha iyi bir iş akışı gizli.

Bu rehber her iki konuyu da kapsıyor. Önce MTPE'nin ne olduğuna ve nasıl işlediğine dair dürüst bir tablo çizeceğim; zira gerek bir işe girmek gerekse B2B SaaS ürününüzü satmak için geleneksel ISO yöntemini bilmeniz gerekir. Ardından, standart toplu modelin nerede çuvalladığını ve insanı sürece daha erken dahil ederek bu işin nasıl daha iyi yapılabileceğini anlatacağım.

Makine çevirisi sonrası düzeltme (MTPE) nedir?

MTPE, diğer adıyla PEMT (post-edited machine translation), üç aşamalı bir iş akışıdır:

1. Makine çevirisi (MT). Bir makine çevirisi motoru veya büyük dil modeli, kaynak metnin bir taslak çevirisini üretir. Bu taslağa ham makine çevirisi (raw MT) denir.
2. Sonrası düzeltme (PE). Bir dil uzmanı, ham makine çevirisini kaynak metinle karşılaştırarak gözden geçirir; hataları düzeltir, terminolojiye bağlılığı sağlar ve metin hedeflenen kalite çıtasına ulaşana kadar üslubu ayarlar.
3. Kalite güvencesi. Tutarlılık, biçimlendirme ve ilk turda gözden kaçabilecek hatalar için yapılan son kontroldür.

Genellikle uygulandığı şekliyle bu, toplu bir devir sürecidir: Makine belgenin tamamını çevirir, ardından bir insan her şeyi baştan sona düzenler. Bu yapıyı aklınızda tutun; ileride itiraz edeceğim nokta tam da burası.

MTPE'nin var olma nedeni, "doğrudan çeviri" ya da "sadece makine" gibi uç yaklaşımların içeriklerin çoğu için yanlış tercihler olmasıdır.

Sıfırdan insan çevirisi yapmak, büyük ölçekli işlerde yavaş ve maliyetlidir. Ham makine çevirisi ise hızlı ve ucuz olsa da, gerçekten nitelikli sonuçlar veren sistemlerin geçmişi on yılı bile bulmaz; oysa bazı ilkel makine çevirisi yöntemleri on yıllardır hayatımızda. Üstelik en iyi LLM'ler ve iş akışları kullanılsa bile, bu çıktıları körü körüne kabul etmenin riski çok büyüktür; insanların metni ustalıkla çevirme yeteneği ise hâlâ çok daha üstündür.

Haliyle MTPE, pragmatik bir orta yol sunar: İşin mekanik olan %70'ini makineye bırakıp, insan dikkatini çevirinin güvenilirliğini belirleyen o kritik %30'luk kısma odaklamak.

(En azından ajansların ve şirketlerin hayali budur. Gerçek hayatta ise çevirmenler ya daha iyi sonuçlar elde etmek için —ekstra ücret almadan— işe daha çok asılırlar ya da sürece hiç dahil olmayıp vasat sonuçların ortaya çıkmasına neden olurlar.)

Durum ne olursa olsun, 2020'li yıllar itibarıyla şu veya bu şekilde MTPE uygulaması, çeviri sektörünün standart yöntemi haline gelmiş durumda.

Hafif ve tam kapsamlı sonrası düzeltme: İki seviye

Özetle: Gerçek hayatta böyle bir ayrım pek yoktur; ancak sektör bu ikili yapının farkında olmanızı bekler.

"Sonrası düzeltme" tek bir kalıptan ibaret değildir. Bir MTPE projesindeki en kritik karar, düzeltmenin hangi seviyede yapılacağıdır; çünkü her bir segmentin ne kadar zaman alacağını ve neleri olduğu gibi bırakabileceğinizi bu karar belirler.

Ekiplerin yaptığı hata, alışkanlık gereği her şeyi en yüksek kalitede düzenlemeye çalışmak (hafif düzeltmenin yeterli olacağı, göz önünde olmayan içerikler dahil) ve MTPE'nin sağlaması gereken zaman tasarrufunu heba etmektir. Bu hata genellikle sadece çevirmenlerin değil; hafif sonrası düzeltme için beklentileri çok yüksek tutan editörlerin ve yöneticilerin de sorumluluğundadır.

Bunun tam tersi olan hata ise daha vahimdir: Bir açılış sayfasını hafif düzeltmeden geçirip neredeyse doğruymuş hissi veren ama güven sarsan bir metni yayına almak. Claude Code ile yapılan çevirilerin çoğu tam olarak böyledir: İnsanlar, uygulamaları için tam makine çevirisi veya hafif MTPE yerelleştirmesi sunduktan sonra dönüşüm oranlarının düştüğünü bildiriyor.

Gerçek hayatta bu çizgi belirsizleşir ve asıl MTPE uygulaması bu iki ucun ortasında bir yerdedir. Platforma veya ajansa bağlı olarak çaba düzeyi ya keyfi olarak ya da proje bazında belirlenir. Ayrıca kalite güvence raporları ve onay zincirleriyle örülü pek çok kurum içi iş akışı ve rutin de mevcuttur.

Pek çok çevirmenin MTPE ile çalışmaktan soğumasının nedeni, tanımlardaki bu belirsizliktir. Bu süreç, iyi bir iş çıkarmış olmanın verdiği o mesleki tatmini sunmaz; üstelik işi hakkıyla yapmanın maddi bir karşılığı da yoktur.

Ham makine çevirisi neden hâlâ bir insana ihtiyaç duyuyor?

2026'da akla gelen o bariz itiraz şu: Modern LLM'ler artık çok akıcı. Ham makine çevirisi şu haliyle yeterince iyi değil mi?

Asıl tuzak da tam olarak bu akıcılık. Eski nesil makine çevirileri, gözle görülür şekilde bozuk çıktılar üretiyordu; bu yüzden kimse düzenlenmemiş metne güvenmezdi. Modern modeller ise okunuşu kulağa harika gelen sonuçlar üretiyor; bu da okuyucularda ve denetçilerde sahte bir güven hissi uyandırıyor.

Daha da kötüsü, anlamı koruyan ancak üslubu buram buram yapay zeka kokan çıktılar üretebiliyor. Bu durum markanın genel imajını zedeliyor ve ucuz bir izlenim bırakıyor; üstelik bu sorun kolayca çözülebilecekken pek çok kişi tam da bu tuzağa düşüyor.

Claude şunları da eklemem gerektiği konusunda ısrar etti:

• İtibar zedelenmesi. Motorlar, bir dilbilimcinin sahip olduğu kültürel nüans kavrayışına veya belirli bir pazarda neyin uygun neyin yersiz kaçacağına dair sezgiye sahip değildir. Kaynak metinde nötr olan bir ifade, hedef dilde hantal, küstahça veya ofansif bir hal alabilir ya da sadece garip kaçabilir; insanları uzaklaştıran o "yapay zeka belirtileri" işte bunlardır.
• Hatalı bilgilendirilen müşteriler. En iyi eğitilmiş modeller bile bazen sessiz sedasız bir yan cümleyi atlayabilir veya kaynakta olmayan bir kelime ekleyebilir. Akıcı ve kendinden emin tınlayan bir paragrafta, kazara yapılan bir eksikliği veya olgusal sapmayı fark etmek çok zordur; bu da hukuki, tıbbi veya finansal içeriklerde ciddi sonuçlar doğurabilir. Tekrar etmek gerekirse, bu teknik olarak çözülebilir bir sorundur (tam olarak bu tür eksiklikleri yakalamak için Smart Proofread mevcuttur), ancak yine de her zaman yaşanmaya devam ediyor.
• Zayıflayan marka imajı. Ham LLM çıktıları, bir markanın kendine has üslubunu ve terminolojisini nadiren yansıtır. Bir ürün adı veya imza bir ifade, site genelinde bir düzine farklı şekilde çevrildiğinde artık tanınabilir olmaktan çıkar ve markanın imajı her seferinde biraz daha bulanıklaşır. Bu sorunu üslup kılavuzları ve sözlükçelerle çözebilirsiniz; ancak eski makine çevirisi iş akışları bunları pek de verimli kullanamaz.

Dolayısıyla, en azından metnin asıl işini yapması gereken durumlarda —müşteri kazanmak veya hukuki bağlayıcılık sağlamak gibi— insan faktörü isteğe bağlı değildir. Standart iş akışlarının yanıtlamakta yetersiz kaldığı asıl soru ise, insanın ne zaman devreye girmesi gerektiğidir.

MTPE'yi asıl zorlaştıran nedir: Dört gerçek darboğaz

Uygulamada, sonrası düzeltme yapanları asıl yıldıran şey tırnak işaretleri veya tarih formatları değildir. Bunlar sadece kalite güvence (QA) kurallarıdır. Asıl zorluk; aldatıcı bir akıcılığa sahip çıktıları değerlendirmek, bir segmentin ne kadar müdahaleye ihtiyaç duyduğuna karar vermek ve tüm bunları, her makine taslağının aynı oranda zaman kazandırdığını varsayan bir ticari model altında yapmaktır.

Sonrası düzeltme çabası üzerine yapılan araştırmalar, bu işi bilişsel, teknik ve zamansal çaba olarak üç kategoriye ayırır. Bu boyutlar her zaman birbiriyle paralel gitmez: Bir cümle sadece iki tuş vuruşu gerektirebilirken dakikalarca doğrulama isteyebilir; bir başkası ise çözümü çok bariz olsa da tamamen yeniden yazılmaya ihtiyaç duyabilir.

Sıkça karşılaşılan darboğazlar şunlardır:

1. Kulağa doğru gelen ancak düzeltilmesi için bağlam gerektiren hataları tespit etmek. Modern makine çevirisi; bir yan cümleyi atlayarak, anlamı kaydırarak veya makul görünen ancak yanlış bir terim seçerek pürüzsüz bir hedef metin ortaya koyabilir. Akıcılık, uyarı sinyallerini ortadan kaldırdığı için editörün kaynak metni, belge bağlamını ve gerçek dünya olgularını sürekli kontrol etmesi gerekir. Tüm bunlar zaman ve çaba gerektirir. Araştırmalar; yanlış çevirilerin, tutarlılık sorunlarının ve yapısal hataların, sonrası düzeltme çabasını en çok artıran unsurlar arasında olduğunu tutarlı bir şekilde göstermektedir.
2. Kabul etme, onarma veya yeniden çevirme kararı. Her segment bir triyaj gerektirir: Olduğu gibi bırakmak, küçük bir düzeltme yapmak, yeniden yazmak veya makine versiyonunu çöpe atıp sıfırdan çevirmek. Hafif ve tam düzeltme arasındaki o belirsiz talimatlar bu karar sürecini daha da zorlaştırır. Editörler ya "mümkün olduğunca az değişiklik yap" kuralına uymak adına yetersiz düzeltme yapar ya da profesyonel kalite çıtaları kendilerine verilen iş özetinden daha yüksek olduğu için gereğinden fazla düzeltme yaparlar.
3. Makinenin çizdiği çerçeveden sıyrılmak. Sonrası düzeltme yapanlar işe boş bir sayfayla başlamazlar. Önce önerilen bir yanıtı okurlar; bu yanıt da kelime dağarcığını, söz dizimini ve yorumu bir noktaya sabitler. Profesyonel iş akışları üzerine yapılan araştırmalar, hazırlama etkilerini (priming effects) ortaya koymuştur: Makine çevirisindeki hatalar ve hantal tercihler, düzeltilmiş metne sızabilir veya düzeltme sürecinin kendisini şekillendirebilir. Cümle kulağa ne kadar iyi gelirse, kurgusunun hatalı olduğunu fark etmek o kadar zorlaşır. Bu durum, makine çevirisi aşamasında LLM'ler kullanıldığında özellikle yaygındır.
4. Yanlış verimlilik varsayımlarıyla çalışmak. MTPE genellikle, makine çıktısının insan emeğinde öngörülebilir bir tasarruf sağladığı varsayımıyla fiyatlandırılır. Ancak durum pek de öyle değil. Zorluk derecesi segmente, dil çiftine, uzmanlık alanına ve hata türüne göre değişirken; hız odaklı fiyatlandırma, müşteriler kusursuzluk beklemeye devam etse bile terminoloji araştırması yapma isteğini kırabilir. Bu değişkenliği çevirmen göğüsler: Kolay segmentler düşük ücreti bir nebze makul kılsa da zor olanlar sağlanan tüm tasarrufu sessizce silip süpürür.

Formatlar, terminoloji kısıtlamaları, kilitli segmentler ve yerel ayar kuralları hâlâ önemini koruyor; ancak bunlar sözlükçeler, üslup kılavuzları veya çeviri belleği gibi araçlar vasıtasıyla iş akışının daha üst aşamalarında uygulanması gereken kontrollerdir.

Asıl MTPE sorunu, muhakeme gücünün nerede harcandığıdır: Akıcı tınlayan hataları yakalamak, müdahale dozunu doğru ayarlamak, makinenin kurgusuna hapsolmamak ve tüm bunları yaparken kaliteyi fiyatlandırma modelinin insafına bırakmamak.

İşte bu yüzden, insanın sürecin başında yer aldığı etkileşimli bir iş akışının, toplu bir düzeltme ekranından çok daha olumlu bir etki yarattığı sonucuna vardım. Peki ama sektör zaten bu noktaya gelmedi mi?

MTPE kalitesi nasıl ölçülür: BLEU ve ötesi

MTPE'nin bir ölçüm sorunu var: Kalite kısmen özneldir. Sektörün en bilinen otomatik metriği, bir makine çevirisini bir veya daha fazla yüksek kaliteli insan referans çevirisiyle karşılaştıran BLEU'dur (Bilingual Evaluation Understudy).

Bu metrik, makine çıktısını genellikle bir ila dört kelime uzunluğundaki kısa kelime dizilerine bölerek ve bunların kaçının referans metinlerde de yer aldığını ölçerek çalışır. Sistemin doğru bir kelimeyi tekrarlayarak puanını şişirmesini önlemek için tekrarlanan eşleşmeler sınırlandırılır; ayrıca çeviri şüpheli derecede kısaysa uygulanan kısalık cezası sonucu düşürür.

BLEU, bu örtüşme ölçümlerini 0 ile 1 arasında bir puanda birleştirir ve bu puan genellikle 0–100 şeklinde gösterilir. Puanın yüksek olması, kelime seçiminin referans metne daha yakın olduğu anlamına gelir; ancak bu, anlamın mutlaka daha iyi olduğu anlamına gelmez.

Şahsi fikrime göre, 2026 yılında bu pek de kullanışlı bir metrik değil; nedenleri ise şunlar:

BLEU puanları ancak motorlar aynı veri kümesi üzerinde aynı puanlama yapılandırmasıyla test edildiğinde anlamlı bir şekilde karşılaştırılabilir; bu nedenle “50 iyidir, 10 kötüdür” gibi evrensel bir eşik değer yoktur. Bu puanların asıl pratik değeri, kontrollü öncesi-sonrası karşılaştırmalarındadır.

Bir TAUS vaka çalışmasında, dar bir hukuk alanından alınan 172.980 Fransızca-Almanca segment üzerindeki eğitim, 7,23 BLEU puanı ekleyerek %19'luk bir nispi iyileşme sağladı. Ayrı bir Rusça-İngilizce havacılık vakasında ise, bir milyon segment içeren temizlenmiş bir çeviri belleği, Globalese'in puanını 23,6'dan yaklaşık 51 BLEU'ya çıkararak %115,5'lik bir nispi kazanç sağladı. İyileşmenin boyutu; alana, dil çiftine, temel motora ve veri kalitesine göre büyük farklılıklar gösterse de, her iki vaka da ilgili ve titizlikle temizlenmiş çeviri belleklerinin neden genel eğitim verilerinden daha iyi performans gösterebileceğini ortaya koyuyor.

Ancak BLEU bir benzerlik puanıdır, doğruluk ölçütü değil. Akıcı ve kendinden emin bir hatalı çeviri yüksek puan alabilir; referansla eşleşmeyen ancak gayet başarılı olan alternatif bir ifade ise düşük puan alabilir. Dolayısıyla BLEU alt sınırı belirler (ham makine çevirisinin makul bir durumda olduğunu söyler); çevirinin doğru, marka kimliğine uygun ve yayına hazır olup olmadığına ise hâlâ insan incelemesi karar verir.

Ekipler bunu giderek daha fazla "hakem olarak LLM" tabanlı kalite tahminleriyle destekliyor; ancak bu, tek başına pek de mantıklı değil.

Genelde uygulandığı haliyle MTPE'nin yarattığı sorunlar

İşte burada betimlemeyi bırakıp argümanlarımı sunmaya başlıyorum. Temel tezim şu:

2. sayfada aldığınız bir karar —bu karakter 'siz' diliyle konuşsun, bu kelime oyununu yerel bir politikacıya atıfta bulunacak şekilde uyarla, şu yer adını Latinize etme gibi— belgenin geri kalanını yeniden oluşturmak için sisteme geri beslenebilir.

Örnekler ve çoklu örnekli istemleme (multi-shot prompting), gelişmiş bağlam mühendisliği olmasa bile, hatta bağlam %100 uyuşmasa dahi LLM'ler için harikalar yaratır. Başka bir dildeki ilgili tür örneklerini dahil etmek bile Transept'in dahili performans ölçümlerinde önemli iyileşmeler sağladı.

Önce tam bir makine çevirisi aşaması çalıştırırsanız, hem insanın kısmen çöpe atacağı sayfaları üretmek için işlem kredilerini tüketmiş hem de o ruhsuz çıktıyı adam etmek için insan mesaisi harcamış olursunuz.

Üstelik model, insandan çok daha hızlıdır. Çevirmen işe başlamadan önce 10.000 kelimenin tamamının taslağının hazır olmasına gerek yoktur.

Daha iyi bir MTPE iş akışı; önce ilk birkaç bin kelimeyi üretmek, çevirmenin kritik kararları vermesine olanak tanımak ve çevirmen henüz beşinci sayfadayken bu kararları ve çeviri belleğini bağlama dahil ederek yola devam etmektir. Transept'in testlerinde, çevrilmemiş kaynak metne eklenen ve çevirmenin genel yaklaşımını yansıtan birkaç kısa yorum bile sonraki çıktıları ölçülebilir düzeyde iyileştirdi.

Sonraki sayfalar, birinin düzeltmesi gereken tek düze bir döküntü yığını olarak değil, önceki kararlar doğrultusunda çoktan şekillenmiş bir halde önünüze gelir.

Bunların hiçbiri MTPE'nin yanlış olduğu anlamına gelmez. Göz önünde olmayan toplu işler için, tam bir makine çevirisi aşamasının ardından hafif bir düzenleme yapmak, pek keyifli bir iş sayılmasa da verimli bir seçimdir.

Ancak içerik gerçekten önemliyse, toplu model hem kaliteden hem de paradan kaybettirir. Bunun tek sebebi de yinelemeli bir sürecin kısa vadede daha maliyetliymiş gibi hissettirmesidir.

Oysa genellikle öyle değildir.

Daha iyi bir yöntem: İnsanı sürece erkenden dahil etmek

Yukarıda anlatılanların hepsi aynı yönteme işaret ediyor: Makine tam bir taslak oluşturmaya girişmeden önce insanın değerlendirmelerini sisteme aktarın ve belleğin bu kararları ileriye taşımasını sağlayın. İşin büyük kısmını şu dört uygulama halleder.

Önce editör, sonra çevirmen olun. Herhangi bir içerik üretmeden önce kaynak metni okuyun ve kilit pasajlara belirleyici notlar bırakın: Bu şaka mutlaka korunmalı; bu terim kritik; burada anlamı korumak için kaynaktan sapabiliriz gibi. Ardından, bu notları ve belleğinizi temel alan bir taslak oluşturun.

Niyetinizi zaten bilen bir taslak üzerinde son düzenleme (post-editing) yapmak, ruhsuz bir metne ince ayar yapmaktan çok daha az can sıkıcıdır. Bunu kendi kitabımda her iki yöntemi de defalarca uygulamış biri olarak söylüyorum.

Belleği en iyi işlerinizle besleyin (eğer sizin MT'niz bunu destekliyorsa). Çeviri belleğinin yapay zeka için önemi genellikle göz ardı edilir. Zorlu bir pasaj veya çetrefilli bir dil çifti için birkaç kesiti tamamen elle çevirip sisteme girin; model, ses tonunu ve üslubu gerçek örneklerden, her türlü talimattan çok daha iyi kavrar.

Sadece TM bile uzun bir metnin üslup bütünlüğünü korumaya yeter. Doğru geçmiş örneği bulmak (anlamsal ve bulanık arama) başlı başına bir sanattır; ancak kaliteli bir örnek üretmek çok daha zordur. Bu süreç aynı zamanda insan yönlendirmesi de gerektirir; zira bir cümleyi ifade etmenin istatistiksel olarak geçerli pek çok yolu olsa da, hangisinin sizin tarzınızı yansıttığını yalnızca siz bilebilirsiniz.

Ancak her araç, nitelikli metinler üretmek için TM'den yararlanamaz. Transept'te, insan onaylı bölümlerin ve bu bölümlerin ardındaki bağlam ile çalışma geçmişinin LLM çevirisini iyileştirmesini sağlamak için kapsamlı araştırmalar yaptık (bu konuyu yapay zeka yerelleştirmesi için çeviri belleği üzerine yazdığımız makalede detaylandırdık).

Tek bir büyük model yerine birkaç modeli sırayla kullanın. Hem akademik çalışmalarda hem de kendi iç araştırmalarımızda tutarlılığını koruyan bir sonuç var: Bir dizi yapay zeka rolünü ardışık olarak çalıştırmak, hem kalite hem de maliyet açısından tek bir güçlü aşamadan daha iyi sonuç veriyor.

Taslağı ucuz ve hızlı bir modelle hazırlayın. Güçlü bir modele bu taslağı inceletip nelerin iyileştirilmesi gerektiğine dair notlar aldırın. Ardından hızlı bir modele bu notları uygulatın.

Bunun, her şeyi güçlü modele yaptırmaktan daha ucuza geldiği ortaya çıktı. Üstelik genellikle daha iyi sonuç veriyor. Güçlü ve zayıf modellerin birleşiminin, devasa bir güçlü modelin tek başına üretebileceğinden daha iyi bir çıktı sunabileceğine ihtimal vermediğim için bu durum benim için büyük bir sürpriz oldu.

Ama işe yarıyor. Hipotezim şu: Eleştiri ve üretim, farklı işler ve farklı aktivasyon kalıpları gerektiriyor. Bunları birbirinden ayırmak, her modelin güçlü yanlarından yararlanılmasını sağlıyor ve "bilişsel yükü" hafifleterek enerjinin doğru noktaya odaklanmasına yardımcı oluyor.

Temelde bu; modelin farklı ayarlar ve görevlerle yapılandırıldığında kendi hatalarını düzeltebildiği tüm o çoklu ajan paradigmasının bel kemiğidir.

Altyapıyı sağlam kurun. Gerçek performans; uzun sistem istemleri ve ürün katmanlarının araya girdiği sohbet uygulamalarından değil, API'den gelir.

LLM çıktıları çevirmenler tarafından genellikle yeterince takdir edilmez çünkü yanlış 'pişirilmişlerdir'; tıpkı koyu soya ve susam soslu bir ton balığı bifteğinin, ton balığı denince akla gelen o tatsız konserve balıkla uzaktan yakından ilgisi olmaması gibi.

Girdiyi temiz ve önbellek dostu olacak şekilde yönetin; böylece hem maliyet hem de gecikme süresi düşer. Modelin ek bağlamı (TM, kararlar, üslup kılavuzları) ne kadar kaldırabildiğini test edin, ardından performans değerleri düşene kadar yükleme yapın. LLM üzerinde doğru adımları atıp atmadığınızı gerçekten görmek için birden fazla dilde sağlam performans kriterlerine sahip olmanız gerekir.

Transept olarak biz, bunu çözmek için üç yılımızı kendi yazılarımız üzerinde araştırma ve deneyler yaparak geçirdik.

Romanımı çevirirken keşke elimde olsaydı dediğim araç: Transept'in MTPE'ye yaklaşımı

Teknik altyapıya sahip disiplinli bir çevirmen; model API'leri, bir çeviri belleği ve sabırla bu iş akışını yeniden kurgulayabilir. Ancak insanı sürece dahil eden MTPE'nin *harika bir şekilde çalışmasını, *hem keyif hem de iyi sonuçlar getirmesini sağlamak epey araştırma gerektirir.

Transept'i geliştirdik çünkü kendi uzun soluklu metinlerimizi çevirirken bu parçaları elle bir araya getirmek bizi usandıran kısımdı.

Yukarıdaki vizyonu tek bir çalışma alanına dönüştürdük: Modeli erkenden yönlendirin, kararları koruyun, özelleşmiş aşamalar yürütün ve incelemeyi yerinde yapın.

Üretimden önce yönlendirin. Doküman editörü kaynağı, çeviriyi ve çevreleyen bağlamı bir arada tutar. Çevirmen, bir blok hakkında yorum yapabilir, bir cümleyi belirli bir talimatla yeniden üretebilir, alternatifleri karşılaştırabilir veya diğer kısımları bozmadan elle düzenleme yapabilir. Yorumlar ve inceleme dizileri metne bağlı kaldığı için "metaforu koru" gibi notlar, bir sohbet günlüğünde kaybolup gitmek yerine bir karar olarak saklanır.

Reddettiğiniz alternatifler bile korunur: Vazgeçilen bir ifade ve onu neden elediğinize dair not, bir sonraki aşamada yeniden kullanılabilecek birer veriye dönüşür. Çeviri varyantlarına ve çeviri belleğinin geçmiş kararları nasıl bir bağlam olarak ele aldığına göz atın.

Kararları belleğe dönüştürün. Transept’in çeviri belleği, onaylanmış çevirileri ve bunlara dair karar bağlamını sonraki çalışmalara aktarır. Sözlükler isimleri, ürün terimlerini ve kalıplaşmış ifadeleri sabitler; üslup kılavuzları ise tonu, dil düzeyini, ritmi ve kuralları taşır. Her ikisi de güvendiğiniz eski çalışmalarınızdan veya müşterinin marka materyallerinden otomatik olarak üretilebilir ve yapay zeka tarafından kullanılmadan önce gözden geçirilebilir.

Aşamaları birbirinden ayırın. Tek bir modelden çeviri yapmasını, metni değerlendirmesini ve son dokunuşları yapmasını tek bir seferde istemek yerine, Transept bu görevleri sıraya dizebilir. Smart Proofread, çeviriyi kaynak metin, sözlük ve üslup kılavuzuyla karşılaştırarak yeniden okur; ardından eksikleri, terminoloji sapmalarını ve üslup kaymalarını gözden geçirilebilir düzeltmeler olarak karşınıza çıkarır.

Manuel kontrolden ziyade orkestrasyonun ön plana çıktığı durumlar için; çeviri, düzeltme, son dokunuş ve kalite kontrol (QA) süreçlerini bir araya getiren Çevir, düzelt ve cilala gibi iş akışları da sunuyoruz. Üstelik bu, aynı belgenin farklı dil sürümleri için de geçerli!

Uzun dokümanlar için birden fazla ajanın aynı doküman üzerinde birlikte çalışmasını sağlayan bir yöntem de geliştirdik. Bu ajanlar üslup kılavuzlarını ve sözlükleri paylaşıp güncelliyor, kararlarını senkronize etmek içinse özel bir gradyan bellek kullanıyorlar.

Yerelde gözden geçirin, küresel ölçekte büyütün. Son düzenleme işlemleri blok veya cümle düzeyinde ilerler: Varyantları karşılaştırın, bir satırı yeniden oluşturun, önerilen bir düzeltmeyi onaylayın veya metni kendiniz baştan yazın. Literess iş akışını yönetmenize ve sapmaları tespit etmenize yardımcı olur; toplu çeviri ise projeyi karmaşık tablolara boğmadan ortak bağlamı, sözlükleri, üslup kılavuzlarını ve kalite kontrolü birçok dosyada birden uygular.

Yerleşik aşamalar istediğiniz dizilime uymadığında, adım adım kendi iş akışınızı kurgulayabilirsiniz: adımları seçin, dilediğinizi inceleme aşamasına bağlayın ve maliyeti en baştan görerek süreci başlatın.

Transept'te ortaya koyduğumuz işle içtenlikle gurur duyuyorum. Bu özellikler, insanın kıymetli zamanının ve yeteneğinin LLM'lerin işleyişi üzerindeki etkisini en üst düzeye çıkarmaya yardımcı oluyor.

Tüm bunların gerçekleştirilebileceğine sadece az sayıda profesyonel çevirmenin ihtimal vermiş olması beni hâlâ şaşırtıyor. Teknik olarak, etkileşimli bir MTPE iş akışı kurmak 2023'te bile mümkündü; üstelik henüz yolun çok başındayız.

MTPE en iyi uygulamaları: Bir kontrol listesi

Transept sizi etkilememiş olsa bile (ki bu haksız bir kanaat olur), işte MTPE hakkında öğrenmeniz gereken her şeyi ve bu süreci nasıl daha az yıpratıcı hale getirebileceğinizi içeren bir liste.

• İnsanı sürece erkenden dahil edin. Önemli pasajlar için yönlendirmelerinizi üretimden sonra değil, önce yapın.
• Belleği gerçek örneklerle besleyin. En zorlandığınız kısımlardan birkaçını kendiniz çevirin ve modelin üslubu bu örneklerden kavramasını sağlayın.
• Modellerinizi kademelendirin. Ucuz taslak, güçlü eleştiri, hızlı uygulama; kalite ve maliyet açısından tek bir büyük modeli geride bırakır.
• İçeriğinizi kademelendirin. Görünürlüğü düşük yığın içerikler için tam kapsamlı toplu MTPE; marka itibarının söz konusu olduğu noktalarda ise ince ince işleyin.
• Terminolojiyi en başta sabitleyin. "Çevrilmeyecekler" ve "yasaklı hedef" kuralları, en yaygın ve en çok zarar veren hataları daha kaynağındayken engeller.
• Yerel varyantlara ve üslup kaymalarına dikkat edin. Bölgesel ağızlar, resmiyet düzeyi ve zamir tutarlılığı; doğal hissettiren bir çeviriyi, ruhsuz ve mekanik bir metinden ayıran temel farklardır.
• Akıcı metinleri daha gevşek değil, daha sıkı denetleyin. Ham makine çevirisi kulağa ne kadar hoş gelirse, içindeki eksikleri gözden kaçırmak o kadar kolay olur.

---

MTPE kalıcı bir yöntem ve pek çok içerik türü için en doğru araç. Ancak "önce toplu çevir, sonra düzelt" mantığına dayalı iş akışı, çeviri teknolojisi tarihinde yanlış bir yöne sapılmasına neden oldu.

Bunu düzeltmek teoride oldukça basit. İnsanı sürece erkenden dahil edin, bağlamı gerçek örneklerle ve bellekle besleyin, taslağı ucuz modellere hazırlatıp güçlü olanlara denetletin; böylece daha düşük maliyetle daha kaliteli çeviriler elde edin. Bu, tam da hem ajansların hem de çevirmenlerin kazançlı çıkacağı bir sonuçtur.

İnsanı sürece erkenden dahil eden döngüyü bizzat görmek isterseniz bir dokümanla başlayın; Ücretsiz plan, kart bilgisi istemeden ilk çeviriyi kapsar.

Önce sorularınızı sormak isterseniz Literess'e danışın veya bu rehber size nereden ulaştıysa bana oradan ulaşın.