15  Makine Çevirisi

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 15. bölüm. Bu sayfadaki her sayı WMT16 newstest2016 Türkçe–İngilizce üzerinde ölçüldü (WMT, her yıl düzenlenen Makine Çevirisi Konferansıdır; newstest2016 onun 2016 haber test kümesi) — her yönde 3.000 profesyonelce çevrilmiş cümle çifti. Test kümesini sacrebleu’nun kendisi indirdi; böylece küme yalnızca tarif edilmiyor, adı ve sürümüyle kesin olarak belirleniyor. Bir tablo aksini söylemedikçe sistemler ilk 1.000 cümlede puanlandı. Örneklem büyüklüğü deneye göre değişiyor: kod çözme (decoding) taraması ilk 500 cümleyi kullanıyor, morfolojik bozma deneyi alt kümelerini ilk 1.000 cümleden çekiyor, LLM ile birebir karşılaştırma ise ilk 400 cümleyi kullanıyor; çünkü bütçeyi cümle başına bir saniye harcayan 9B’lik bir model belirliyor. Her tablo kendi \(n\) değerini belirtiyor. Bölüm 15.5, alanın varsayılan metriğinin neden Türkçeye İngilizceden daha sert davrandığını ölçüyor; bunun için iki dile de karşılaştırılabilir bir hata ekleyen keşifsel bir deney kullanıyor. Yazılım: sacrebleu 2.6.0, transformers 5.15.1, PyTorch 2.13.0, Python 3.14.5; MT modeli Apple M serisi GPU’da, LLM ise ollama 0.24.0 üzerinden.

Öğrenme hedefleri. Bu bölümün sonunda:

• attention (dikkat mekanizması) fikrini doğuran görevin neden çeviri olduğunu ve attention’ın hangi darboğazı kaldırdığını açıklayabilirsiniz;
• sohbete değil çeviriye uygun bir kod çözme stratejisi seçebilir ve aynı ayarın neden birinde doğru, diğerinde yanlış olduğunu söyleyebilirsiniz;
• BLEU’yu elle hesaplayabilir, neyi görüp neyi göremediğini açıkça belirtebilir ve yanında daha fazlasını gören bir metrikle raporlayabilirsiniz;
• kelime düzeyinde bir metriğin eklemeli bir dile İngilizceden neden daha sert davrandığını, iddia etmek yerine niceliklendirebilirsiniz;
• ölçülmüş kalite, gecikme ve maliyet üzerinden özel bir MT modeli ile bir LLM arasında karar verebilirsiniz;
• translate-train (çeviri ile eğitim: eğitim verisini çevirip modeli hedef dilde eğitme), translate-test (çeviri ile test: girdiyi kullanım sırasında modelin diline çevirme) ya da hiçbiri arasında seçim yapabilir ve her birinde hataların nerede biriktiğini söyleyebilirsiniz.

15.1 Attention çeviriden çıktı

Bölüm 7 attention’ı bir mekanizma olarak öğretti. Attention’ın köken hikâyesi ise bu bölümde anlatılıyor, çünkü bugün kullandığımız biçimiyle attention genel bir fikir olarak değil, çeviride belirli ve ölçülebilir tek bir kusuru düzeltmek için önerildi. (Benzer yumuşak adresleme fikirleri aynı yıllarda başka görevlerde de, örneğin el yazısı üretiminde, deneniyordu.)

2014 mimarisi (Sutskever vd. 2014) kaynak cümleyi okuyup tek bir sabit uzunlukta vektöre sıkıştıran bir encoder (kodlayıcı) RNN ile, çeviriyi yalnızca o vektörden üreten bir decoder (kod çözücü) RNN’den oluşuyordu.

Zarif bir tasarımdı ve işe yaradı — ama yalnızca bir noktaya kadar ve o noktayı bulmak zor değildi. Decoder’ın kırk kelimelik bir cümle hakkında bileceği her şey, dört kelimelik bir cümle hakkında bileceği her şeyle aynı sayıda kayan noktalı sayıya (float) sığmak zorundaydı.

Belirti açıktı: kaynak cümleler uzadıkça çeviri kalitesi hızla düşüyordu. Üstelik belirli bir biçimde düşüyordu: model cümlenin başını iyi çeviriyor, sonra kaynaktan uzaklaşıp savruluyordu. Çünkü sabit boyutlu bir vektör uzun bir cümlenin bütün ayrıntılarını taşıyamaz; kaybolan ayrıntılar da decoder’ın ilerleyen adımlarda ihtiyaç duyacağı ayrıntılardır.

Bahdanau vd.’nin (2015) çözümü sıkıştırmayı bırakmaktı: her kaynak token’ı için ayrı bir vektör tutmak ve decoder’ın her çıktı adımında bu vektörlerin hepsinin ağırlıklı ortalamasını almasına izin vermek. Ağırlıklar da decoder’ın o anda üretmeye çalıştığı şeye bağlıdır.

İşte attention budur. Fikrin çeviride bu kadar açıkça doğru olmasının nedeni, çevirinin bu mekanizmanın birebir yansıttığı bir özelliği olmasıdır: çıktı kelimeleri girdi kelimelerine karşılık gelir. Decoder Istanbul ürettiğinde işe yarar bilgi tek bir kaynak konumda yoğunlaşmıştır ve ağırlığını oraya yoğunlaştırabilen bir ortalama, sabit bir özetten daha iyi bir arayüzdür.

İlk attention makalelerinin kelime hizalamalarına benzeyen hizalama ısı haritaları yayımlayabilmesinin nedeni budur; transformer attention head’lerini (katman içinde paralel çalışan attention birimleri) açıklama olarak okuma girişimlerinin sonradan hayal kırıklığı yaratmasının nedeni de. Bir çeviri encoder-decoder’ında attention ağırlıklarını hizalama olarak yorumlamanın gerekçesi görevin kendi yapısıdır. 24 katmanlı bir dil modelinde ise bu yorum bir hipotezdir; attention ağırlıklarının güvenilir bir açıklama olup olmadığı literatürde hâlâ tartışmalıdır (Jain ve Wallace, 2019; Wiegreffe ve Pinter, 2019).

İki yıl sonra Vaswani vd. (2017) tekrarlayan (recurrent) yapıyı kaldırıp yalnızca attention’ı tuttu; Bölüm 7’nin konusu budur. Soy zincirini akılda tutun: makine öğrenmesindeki baskın mimari, bir çeviri hatasının onarımı olarak başladı.

Neye bakacağız. Önce kısaca çeviri sistemlerinin üç dönemi, çünkü her biri bir sonrakine bir şey bıraktı. Sonra alanın dayandığı metrik: doğru bir çeviri olduğu hâlde 50 alan bir cümle üzerinde elle hesaplanmış hâliyle. Sonra kod çözme: sohbet yanıtını doğal gösteren ayarlar burada bir çevirinin BLEU puanını yarıya indiriyor. Sonra bu bölümün var olma nedeni olan ölçüm: kelime düzeyinde bir metrik Türkçeye İngilizceden ne kadar daha sert davranıyor? Bunu iki dile de karşılaştırılabilir bir hata ekleyen keşifsel bir deneyle ölçüyoruz. Son olarak bir LLM’i ondan yaklaşık kırk kat küçük bir modelle karşılaştırıyor ve her birinin nerede kullanılması gerektiğini tartışıyoruz.

15.2 Üç dönem ve her birinin doğru yaptığı

Aynı probleme üç yanıt; her biri bir öncekinin yerini aldı ve her biri arkasında bir sonraki dönemin hâlâ ihtiyaç duyduğu bir şey bıraktı. (Üçünden önce, 1950’lerden itibaren kural tabanlı MT vardı: iki dilli sözlükler ve dilbilimcilerin elle yazdığı dilbilgisi kuralları. Kuralların kapsadığı yerde isabetliydi, geri kalan her yerde kırılgandı; bir dilin tamamına yetecek kadar kural yazmak da hiçbir zaman karşılanabilir bir maliyete inmedi.)

İstatistiksel MT kelime tabanlı hizalama modelleriyle başladı (Brown vd. 1993) ve öbek tabanlı sistemlerle olgunlaştı (Koehn vd. 2003). Öbek tabanlı bir sistem bir öbek tablosu (bu kaynak öbek şu hedef öbeğe şu olasılıkla eşlenir), çıktıyı akıcı tutacak bir hedef dil modeli ve bir yeniden sıralama modeli öğreniyordu. İnceleyebileceğiniz parçalardan kurulmuştu. Bir çeviri yanlışsa sorumlu öbek tablosu satırını bulup okuyabilirdiniz.

O dönemden bugüne taşınması gereken şey kelime hizalamasıdır. Alanın bir çeviri sisteminin ne yaptığını tümüyle yorumlanabilir biçimde açıklayabildiği son dönem buydu. Terminoloji denetimi ve yerelleştirme kalite kontrolü hâlâ kelime hizalaması üzerine kuruludur. (Çeviri bellekleri de yakın akrabasıdır: cümle düzeyinde hizalanmış çiftleri saklarlar.)

Hangi kaynak kelimelerin hangi hedef kelimeleri ürettiğini söyleyemeyen bir sistemi hiçbir insan çevirmen denetleyemez. Düzenlemeye tabi yerelleştirmede ise bu denetim vazgeçilmez bir koşuldur.

Nöral MT bu çok parçalı sistemin yerine tek bir eğitilmiş model koydu. Yeniden sıralamayı ve akıcılığı neredeyse anında düzeltti; istatistiksel çıktı, istatistiksel bir sistemden çıktığını ilk okuyuşta belli ediyordu. Bunun yanında öbek tablosunun üretemeyeceği hata biçimleri de getirdi: akıcı uydurmalar, atlanan yan cümleler ve nadir bir kelimeyi eğitimde gördüğü akla yatkın herhangi bir şeyle çevirme alışkanlığı. Koehn ve Knowles (2017) bunları kataloglamıştır. Nadir kelime sorunu kalıcı bir miras da bıraktı: bugün neredeyse her dil modelinin kullandığı BPE alt kelime tokenization’ı, nöral MT’nin açık sözlük problemine çözüm olarak önerildi (Sennrich vd. 2016b); Bölüm 8.3.1 onu ayrıntılı anlatıyor.

Genel amaçlı LLM’ler çeviri için geliştirilmedi ama yine de çeviriyor, çünkü çok dilli bir web üzerinde eğitilmiş ve sonraki token’ı tahmin eden bir model aynı içeriği pek çok dilde görmüştür. Özel bir modele kıyasla ekledikleri şey bağlamdır: belge düzeyinde bir bakış, prompt’ta (istemde) bir sözlük, bir üslup talimatı. Buna karşılık maliyet ve belirlenimcilikte kaybediyorlar; Bölüm 15.6 ikisini de ölçüyor.

15.3 Değerlendirme ve BLEU’nun gerçekte nasıl çalıştığı

Çevirinin tek bir doğru yanıtı yoktur. Bu yüzden referans tabanlı her otomatik metrik, çıktıyı bir veya daha fazla insan çevirisiyle (referansla) karşılaştırır ve bir benzerlik puanı raporlar. Referanssız bir aile de var: kalite kestirimi (quality estimation, QE) metrikleri puanı yalnızca kaynağa ve çıktıya bakarak tahmin eder; referans çevirinin bulunmadığı üretim ortamında kullanılabilecek otomatik sinyal odur. Hangi sistemlerin daha iyi olduğuna inanacağınızı seçtiğiniz metrik belirler; dolayısıyla her metriğin neyi saydığını bilmeniz gerekir.

15.3.1 BLEU elle

BLEU (Papineni vd. 2002), modified n-gram precision (kırpılmış n-gram kesinliği: her n-gram sayımı referanstaki sayımla sınırlanır) üzerine kuruludur. Bu precision n = 1..4 için hesaplanır, dört değerin geometrik ortalaması alınır ve sonuç bir kısalık cezasıyla çarpılır. Tanımın tamamı budur ve çözümlü bir örneğe sığar.

BLEU — adayın kelime n-gram’larının referansta geçen oranı; n = 1’den 4’e kadar ortalaması alınır ve fazla kısa olmanın cezası uygulanır. 2002’den beri alanın varsayılan metriği ve aynı anlamı farklı kelimelerle veren her doğru çeviriye kör. ↩︎

Örneğe geçmeden önce tanımdaki iki kavramı açalım. Modified (kırpılmış) precision, adaydaki bir n-gram’ın referansta geçtiğinden daha fazla kez puan alamaması demektir. Kırpma olmasaydı the the the the adayı, the cat sat on the mat referansına karşı kusursuz bir unigram (tek kelimelik n-gram) precision değeri alırdı; kırpmayla yalnızca referanstaki iki the sayılır ve precision 2/4 olur. Kısalık cezası ise precision’ın tek başına az konuşmayı ödüllendirmesi yüzünden vardır: dört doğru kelimeden oluşan dört kelimelik bir aday, yirmi kelimelik bir referansa karşı bile kusursuz precision alır. \(p_n\) kırpılmış n-gram precision’ı, \(c\) adayın uzunluğu, \(r\) referansın uzunluğu olmak üzere:

\[ \text{BLEU} = \text{BP}\cdot\exp\Big(\frac{1}{4}\sum_{n=1}^{4}\log p_n\Big), \qquad \text{BP} = \begin{cases} 1 & c > r \text{ ise} \\ e^{\,1 - r/c} & c \le r \text{ ise} \end{cases} \]

Logaritmaların ortalamasının üsteli, dört precision değerinin geometrik ortalamasından başka bir şey değildir; sonuç genellikle 100 ile çarpılır. Bir test kümesinin tamamında BLEU, cümle puanlarının ortalaması değildir: eşleşen ve toplam n-gram sayıları ile \(c\) ve \(r\) uzunlukları önce bütün cümleler üzerinde toplanır, formül bir kez uygulanır. Bu bölümdeki her tablo bu derlem düzeyi BLEU’yu raporluyor. Aşağıdaki gibi tek cümlelik bir puan öğretim amaçlıdır ve herhangi bir n-gram derecesinde hiç eşleşme olmadığında smoothing (düzleştirme: sıfır sayımlara küçük bir pay verme) gerektirir, çünkü \(\log 0\) tanımsızdır.

REF: In Istanbul , heavy rain caused flooding on Monday evening .   (11 tokens)
HYP: Heavy rain in Istanbul caused flooding on Monday evening .     (10 tokens)

Aday doğru bir çeviridir. Yer belirten öbeği cümlenin ortasına taşımıştır; İngilizce buna izin verir ve bu taşıma anlamı hiç değiştirmez. BLEU’nun bundan çıkardığı sonuç aşağıda. Bu bölümün metin bloklarındaki sayılar, program çıktısında olduğu gibi İngilizce gösterimle yazıldı (ondalık ayırıcı nokta, binlik ayırıcı virgül):

  1-gram precision   8/10 = 0.8000
  2-gram precision   5/9  = 0.5556
  3-gram precision   4/8  = 0.5000
  4-gram precision   3/7  = 0.4286

  kısalık cezası     len(hyp)=10, len(ref)=11  ->  exp(1 - 11/10) = 0.9048
  dört precision'ın geometrik ortalaması       =  0.5555

  BLEU = 0.9048 x 0.5555 = 50.27

Çeviriyi düzenleyin ve BLEU'nun hareketini izleyin

viewof bleuRef = Inputs.text({label: "referans",
  value: "In Istanbul , heavy rain caused flooding on Monday evening .", width: 560})

viewof bleuHyp = Inputs.text({label: "aday",
  value: "Heavy rain in Istanbul caused flooding on Monday evening .", width: 560})

viewof bleuLower = Inputs.toggle({label: "önce ikisini de küçük harfe çevir", value: false})

bleuScore = {
  const prep = t => (bleuLower ? t.toLowerCase() : t).trim().split(/\s+/).filter(x => x);
  const ref = prep(bleuRef), hyp = prep(bleuHyp);
  const grams = (a, n) => a.slice(0, Math.max(0, a.length - n + 1))
                           .map((_, i) => a.slice(i, i + n).join(" "));
  const rows = [];
  let logsum = 0;
  for (let n = 1; n <= 4; n++) {
    const h = grams(hyp, n), r = grams(ref, n);
    const need = new Map();
    for (const g of r) need.set(g, (need.get(g) ?? 0) + 1);   // kırpılmış sayımlar
    let hit = 0;
    for (const g of h) if ((need.get(g) ?? 0) > 0) { hit++; need.set(g, need.get(g) - 1); }
    const p = h.length ? hit / h.length : 0;
    rows.push({n: `${n}-gram`, matched: hit, total: h.length, precision: p});
    logsum += Math.log(Math.max(p, 1e-12));
  }
  const bp = hyp.length > ref.length ? 1 : Math.exp(1 - ref.length / Math.max(hyp.length, 1));
  const geo = Math.exp(logsum / 4);
  return {rows, bp, geo, bleu: bp * geo * 100, hlen: hyp.length, rlen: ref.length};
}

Inputs.table(bleuScore.rows, {
  columns: ["n", "matched", "total", "precision"],
  header: {n: "derece", matched: "eşleşen", total: "adayda", precision: "precision"},
  format: {precision: v => v.toFixed(4)},
  width: {n: 90, matched: 90, total: 110, precision: 100},
  rows: 4})

md`kısalık cezası **${bleuScore.bp.toFixed(4)}** (aday ${bleuScore.hlen}
token, referans ${bleuScore.rlen}) × geometrik ortalama
**${bleuScore.geo.toFixed(4)}** = **BLEU ${bleuScore.bleu.toFixed(2)}**`

Doğru bir çeviri için 50,27. Puanı iki şey düşürdü; ikisi de bu bölümde sürekli karşımıza çıkacak:

• in Istanbul öbeğini taşımak, taşınan öbeğin sınırından geçen her n-gram’ı bozdu. Unigram’lar zarar görmedi; 4-gram’lar gördü.
• Heavy, heavy ile eşleşmedi; in de In ile eşleşmedi. BLEU varsayılan olarak büyük-küçük harfe duyarlıdır. Yalnızca bu, on unigram’dan ikisini ve iki bigram’ı (heavy rain, in Istanbul) kaybettirdi. Yukarıdaki küçük harf anahtarını açarsanız aynı çift 57,81 alır; geri kalan kayıp yer değiştirmeden gelir.

Aynı çift için chrF2 83,23 veriyor — 1’den 6’ya kadar uzunluktaki karakter n-gram’ları, \(\beta = 2\), sacrebleu’nun varsayılanı ve bu bölümdeki her chrF sayısının kullandığı varyant. Puanın bu kadar yüksek çıkması, karakter düzeyinde neredeyse her şeyin hâlâ eşleşmesinden. Kelime unigram ve bigram’larını da ekleyen chrF++ varyantı bu çifti daha düşük puanlıyor (78,07): saf karakter metriğinin affettiği yer değiştirme, kelimeler devreye girer girmez yeniden görünür hâle geliyor.

Yeniden üretin, tam olarak 50,27 alırsınız — ama yalnızca hangi BLEU olduğunu söylerseniz. Tokenization, büyük-küçük harf ve smoothing ayarlarının hepsi sayıyı değiştirir; sacrebleu’nun var olma nedeni ve Post’un makalesinin (2018) yazılmak zorunda kalmasının nedeni budur: imzası olmayan bir BLEU puanı başka bir BLEU puanıyla karşılaştırılabilir değildir. İmzayı her zaman raporlayın. Bu kural bizi de bağlıyor. Bu bölümdeki her BLEU, varsayılan ayarlarıyla sacrebleu 2.6.0 ile hesaplandı: case:mixed | tok:13a | smooth:exp | nrefs:1. Her chrF ise chrF2 ile hesaplandı: case:mixed | nc:6 | nw:0 | eff:yes. Buradaki tok:13a, aşağıdaki Türkçe ölçümler için her zamankinden daha önemli. 13a tokenization’ında kesme işareti kelimeyi bölmez; dolayısıyla İstanbul'da tek bir token’dır ve ekte yapılan bir değişiklik token’ın tamamını bozar. intl’de ise kesme işareti kelimeyi böler ve aynı değişiklik daha azını bozar. Bu yüzden morfolojik bozma deneyi (Bölüm 15.5) bir tok:13a sonucudur. Deneyi intl ile yeniden koşmak iyi bir alıştırmadır ve sayıyı değiştirecektir.

15.3.2 Metrik ailesi ve her birinin gördüğü

BLEU’nun kör noktaları ölçmeyi bırakmayı gerektirmez; yalnızca başka hangi seçeneklerin olduğunu bilmeyi gerektirir. Aşağıda, gördükleri de maliyetleri de sırayla artan dört seçenek var:

Bir çeviriyi puanlamanın dört yolu

metrik	birim	gördüğü	kaçırdığı
BLEU	kelime n-gram’ları	tam öbek eşleşmeleri	aynı anlamı başka kelimelerle veren her ifade; kısmen doğru kelimeler
chrF (Popović 2015)	karakter n-gram’ları	kısmen doğru kelimeler, morfoloji	anlam; doğru karakterlerden kurulmuş akıcı bir cümle
COMET (Rei vd. 2020)	öğrenilmiş	eğitim verisinin öğrettiği kadarıyla anlam	eğitim verisinde olmayan her şey; ayrıca GPU olmadan yavaştır
İnsan MQM (Multidimensional Quality Metrics) (Freitag vd. 2021)	etiketlenmiş hatalar	kategori ve şiddetiyle birlikte en geniş yelpaze	etiketleyicilerin kaçırdığı ya da üzerinde anlaşamadığı her şey — puanla birlikte etiketleyiciler arası uyumu da bildirin; ayrıca para ister ve günler sürer

chrF — karakter n-gram’ları üzerinde bir F-skoru. Uzunluk cezası eklenmiş salt bir precision ölçüsü olan BLEU’nun aksine chrF precision’ı ve recall’u (duyarlılık) birleştirir ve recall’a \(\beta\) kat ağırlık verir; sacrebleu’nun varsayılanı 1’den 6’ya kadar uzunluktaki karakter n-gram’ları üzerinde \(\beta = 2\), yani chrF2. Eksik bir eki fark etmesini sağlayan o recall terimidir; eklemeli bir dilin sürekli ürettiği durum da budur. ↩︎

COMET — nöral bir metrik: kaynak, hipotez ve referanstan insan kalite yargılarını tahmin etmek üzere fine-tuning (ince ayar) ile eğitilmiş bir model. İnsan yargılarıyla BLEU’dan çok daha yüksek korelasyon gösterir ve eğitildiği yargıların her yanlılığını da devralır. ↩︎

İnsan değerlendirmesinin birbirinden ayırt edilmesi gereken iki ana biçimi var. Doğrudan değerlendirmede (Direct Assessment, DA) değerlendiriciler her çeviriye 0–100 arasında bir puan verir; çok sayıda değerlendiriciyle yapılabilecek kadar ucuzdur ve yaygın kullanılan COMET modelleri tam da bu puanları tahmin etmek üzere eğitilmiştir. MQM’de ise eğitimli çevirmenler her hatalı bölümü işaretler, ona bir kategori (doğruluk, akıcılık, terminoloji …) ve bir şiddet derecesi verir; puan, hataların ağırlıklı sayımıdır. MQM daha yavaş ve pahalıdır, ama Freitag vd. (2021) onu kitle kaynaklı puanlamadan daha güvenilir buldu; üstelik size yalnızca ne kadar değil, neyin yanlış gittiğini de söyler.

2026 uzlaşısı şu: chrF ve bir nöral metrik (COMET ya da xCOMET, MetricX gibi yenileri) raporlayın; herkes yaptığı için BLEU’yu da raporlayın; sistemleri asla yalnızca BLEU üzerinden sıralamayın. Kocmi vd. (2024), her metrikte bir farkın anlamlı olması için ne kadar büyük olması gerektiğine dair güncel rehberdir.

Bu bölüm o kuralın yalnızca üçte ikisine uyuyor. Eksik kalan nöral metriği bölümün bir zayıflığı olarak not edin. Aşağıdaki her tablo BLEU ile chrF2 raporluyor, nöral metrik raporlamıyor. Bunun nedeni, buradaki her şeyin CUDA GPU’su olmayan tek bir dizüstü bilgisayarda çalıştırılmış olması (MT modeli Apple’ın GPU arka ucu MPS’i, yani Metal Performance Shaders’ı kullanıyor). COMET orada da çalışırdı, yalnızca yavaş; bu yavaşlık da nöral metriklerin gerçek bedelidir, onlara karşı bir argüman değil. Aşağıdaki sıralamaları geçici sayın ve bunlardan birine dayanarak karar vermeden önce bir COMET sütunu ekleyin.

15.4 Çeviri için kod çözme

Bölüm 18, açık uçlu üretim için istediğiniz şeyin örnekleme (sampling) olduğunu savunacak. Çeviri bunun karşı örneğidir; bu karşıtlığı genel bir kural olarak değil, somut bir örnekle göreceğiz.

Fark görevde. Açık uçlu üretimin pek çok iyi yanıtı vardır ve çeşitliliği istersiniz, dolayısıyla dağılımdan örneklemek zaten amaçtır. Çevirinin de pek çok geçerli karşılığı vardır; bu bölümdeki metriklerin çıktıyı “tek doğru” ile değil, olası pek çok doğrudan biri olan bir referansla karşılaştırmasının sebebi de budur. Ama kullanıcının istediği şey bu çeşitlilik değildir. Örneklenen bir token’ın daha kötü bir karşılık olma ihtimali, farklı ama eşdeğer bir karşılık olma ihtimali kadar yüksektir. İstediğiniz şey, modelin kendisinin en yüksek puanladığı dizidir. Bu yüzden çeviri beam search (ışın araması) kullanır: her adımda tek bir en iyi token’a karar vermek yerine en iyi k kısmi hipotezi tutar ve hepsini genişletir.

Helsinki-NLP’nin OPUS derlemi üzerinde eğittiği, yalnızca çeviri yapan Marian tabanlı opus-mt-tc-big-tr-en modeliyle newstest2016 tr-en’in 500 cümlesi üzerinde kod çözme uzayının tamamı şöyle:

kind      value    BLEU    chrF  len ratio  ms/sent
beam          1   29.45   58.01      1.015       51
beam          2   30.06   58.36      1.021       66
beam          4   30.17   58.41      1.022       80
beam          8   30.23   58.42      1.021      119
beam         16   30.25   58.41      1.022      166
beam         32   30.36   58.44      1.020      273
beam         64   30.63   58.58      1.018      459

lenpen      0.2   30.51   58.30      1.007       76
lenpen      0.6   30.44   58.42      1.013       74
lenpen      1.0   30.17   58.41      1.022       73
lenpen      1.4   29.83   58.37      1.031       75
lenpen      2.0   29.25   58.39      1.041       74

sample      0.3   28.95   57.42      1.016       45
sample      0.7   25.90   55.17      1.013       45
sample      1.0   14.34   45.27      1.111       53

Satırlar şöyle okunur. beam 1 tek bir hipotez tutar; bu, greedy (açgözlü) kod çözmedir: her adımda en olası token alınır. lenpen satırları beam’i 4’te sabit tutup aşağıda açıklanan uzunluk cezasını değiştirir. sample satırları her token’ı verilen sıcaklıkta rastgele çeker. Sıcaklık, çekilişten önce modelin olasılıklarını yeniden ölçekler: 1’in altında dağılımı en olası token’a doğru keskinleştirir, 1,0’da ise çekiliş modelin kendi dağılımını izler. len ratio, çıktı uzunluğunun referans uzunluğuna oranıdır.

15.4.1 Örnekleme burada puanın yarısına mal oluyor

Beam 4’te BLEU 30,17’ye karşılık 1,0 sıcaklıkta 14,34. Aynı model, aynı cümleler ve puanda %52,5’lik bir düşüş. Puan deyin, kalite değil: BLEU bir n-gram örtüşme istatistiğidir, sayının yarısının çevirinin yarısı demek olduğu bir oran ölçeği değil. Saf örnekleme bir token’ı olasılığıyla orantılı seçer, yani her token’da daha kötü olanı alma ihtimali vardır ve bir cümle boyunca bu ihtimal birikir. Bir sohbet yanıtında aynı davranışın adı tekrara düşmemektir.

Ders çevirinin ötesine genellenir: kod çözme parametreleri model ayarları değil, görev ayarlarıdır ve bir sohbet örneğinden bir çeviri hattına sıcaklık kopyalamak, modele hiç dokunmadan dört (0,7’de) ile on altı (1,0’da) BLEU arasında kaybetmenin bir yoludur.

15.4.2 Beam search: yaygın kanı burada doğrulanmıyor

Yaygın kanı, kalitenin büyük beam genişliklerinde bozulduğudur. Buna “beam search laneti” denir: modelin en yüksek olasılıklı dizisi kısa, bozuk (hatta boş) bir dizi çıkar. Bu modelde lanet görülmüyor. BLEU beam 1’den beam 64’e monoton biçimde yükseliyor ve uzunluk oranı yaklaşık 1,02’de sabit kalıyor; yani bozulan bir şey yok.

Verinin gösterdiği şey ise getirinin sert biçimde azalması:

  beam 1 -> 2      +0.61 BLEU     süre 1.3 katına çıkarken
  beam 2 -> 64     +0.57 BLEU     süre 7.0 katına çıkarken

Tek bir fazladan beam, ondan sonraki altmış iki beam’in toplamda kazandırdığı kadar kazandırıyor. Ama bu sonucu başka bir yerde kullanmadan önce, üzerinde neyin yapılmadığına dikkat edin. Bunlar 500 cümlede ölçülmüş 0,6 puanlık BLEU farkları ve ikisi de anlamlılık testinden geçirilmedi. 500 cümle üzerinde eşleştirilmiş bir bootstrap (cümleleri yeniden örnekleyerek güven aralığı çıkaran yöntem), her birinin çevresinde kabaca bir puanlık bir BLEU aralığı verir. İki fark da, yukarıda metrikleri tartışırken tam da bu amaçla atıf yaptığımız Kocmi vd.’nin (2024) verdiği eşiklerin altında kalıyor. Bu tablonun savunulabilir okuması, hiçbir beam genişliğinin komşularından ölçülebilir biçimde daha iyi olduğunun gösterilmediğidir. Bu, ham sayıların davet ettiğinden daha temkinli bir iddiadır ve yazıya geçirilmesi gereken de budur. Beam 4 yine de doğru varsayılan. Nedeni beam 2’den ölçülebilir biçimde iyi olması değil; maliyetinin neredeyse sıfır, geniş ayarların maliyetinin ise yüksek olması.

Testi kendiniz yapmak tek satırlık iş. sacrebleu, iki sistemin çıktısını aynı referansa karşı eşleştirilmiş bootstrap ile karşılaştırır; ilk verilen sistem karşılaştırmanın tabanıdır ve --paired-bs yerine --paired-ar yazarsanız yaklaşık rastgeleleştirme (approximate randomization) testi yapılır:

sacrebleu ref.en -i beam2.en beam64.en -m bleu chrf --paired-bs -f text

Lanetin görülmemesinin en olası açıklaması model değil, kod çözücü. generate() bir beam’i, log-olasılığını uzunluğunun length_penalty kuvvetine bölerek puanlıyor. Bu argümanın varsayılan değeri 1.0, yani tam uzunluk normalleştirmesi: laneti üreten uzunluk yanlılığına karşı kullanılan standart düzeltmelerden biri. Murray ve Chiang (2018) bu yanlılığı inceliyor ve alternatif olarak ayarlanabilir, kelime başına bir ödül öneriyor. Bunun bir sonuç değil bir hipotez olduğunu unutmayın: burada normalleştirme kapalıyken beam taraması yapılmadı. Bir sonraki alt bölümün gösterdiği şey, bu düğmenin Marian ağırlıklarının bir özelliği değil, bir generate() argümanı olduğu. Laneti gerçekten aramak istiyorsanız length_penalty=0.0 yapıp beam genişliğini yeniden tarayın. Koehn ve Knowles (2017) bu bozulmayı belgeledi; Meister vd. (2020) ise beam search’ün tam da en yüksek olasılıklı diziyi bulamadığı için iyi çalıştığını savunuyor.

15.4.3 Uzunluk cezası kaliteyi değil BLEU’yu oynatır

Uzunluk cezası bir hipotezin puanını uzunluğunun bir kuvvetine böler; bu yüzden daha yüksek bir değer daha uzun çıktıya izin verir. Geri kalan her şeyi sabit tutup bu değeri taradığımızda:

  lenpen 0.2 -> 2.0     BLEU  30.51 -> 29.25    1.26 puanlık oynama
                        chrF  58.30 -> 58.39    0.09 puanlık oynama
                        uzunluk oranı 1.007 -> 1.041

BLEU chrF’in on dört katı hareket ediyor ve çıktı uzunluğuyla birlikte hareket ediyor. İki metriğin ayrışması tek başına hangisinin haklı olduğunu çözmez — sabit duran bir chrF, kalitenin korunduğunun kanıtı değildir. Buradaki okumayı güvenli kılan şey üçüncü satır: uzunluk oranı chrF ile değil BLEU ile birlikte oynuyor. Hangi mekanizmanın oynadığına da dikkat edin: oran her satırda 1’in üstünde, yani çıktı referanstan uzun ve kısalık cezası hiç devreye girmiyor (BP = 1). BLEU’yu oynatan precision paydası: fazladan üretilen her kelime, eşleşse de eşleşmese de paydaya yeni n-gram’lar ekler. Kesin cevabı bir insan ya da MQM kontrolü verir; uzunluk oranı ise bunun kontrol edilmesi gerektiğinin ucuz kanıtı. Uzunluk cezasını BLEU’ya göre ayarlamak çıktı uzunluğunu referans uzunluğuna doğru çeker; çıktısı referanstan uzun olan bu sistemde bu, biraz daha kısa çıktı demek (çıktılar kısa olsaydı ayar ters yöne iterdi). Bu da hiçbir okurun fark etmeyeceği bir puanlık BLEU artışı elde etmenin gerçek ve yaygın bir yoludur.

15.5 BLEU Türkçe için neden her zamankinden kötü

“BLEU morfolojik olarak zengin dillere haksızlık eder” cümlesi yaygın kanı olacak kadar sık tekrarlanır. Doğrudur, mekanizması basittir ve etkinin büyüklüğü ölçülebilir — o yüzden burada iddia edilmek yerine ölçülüyor.

15.5.1 Mekanizma, iki sayıda

newstest2016’nın profesyonelce çevrilmiş 3.000 cümle çiftini alın ve iki tarafı da sayın:

                    kelime        karakter       cümle başına medyan kelime
  Türkçe           46,243           335,110              13
  İngilizce        59,661           341,494              18

  aynı içerik İngilizcede   1.29 kat fazla KELİME gerektiriyor
  ama yalnızca              1.02 kat fazla KARAKTER

Aynı anlam, neredeyse aynı sayıda karakter ve İngilizcede %29 daha fazla kelime token’ı. Türkçe, İngilizcenin ayrı kelimelerle yazdığını eklerle tek kelimede toplar: evinizden, from your house demektir — üçe karşı bir token.

Mekanizmanın tamamı bu. Kelime düzeyinde bir metrik cümleyi token’lara böler ve kaçının eşleştiğini sorar. İngilizce aynı içerik için %29 daha fazla token kullanır, dolayısıyla Türkçe metriğe \(1 - 1/1{,}29 = \%22{,}5\) daha az token verir — bu iki yüzde aynı olgunun iki yönden okunuşudur; %29 ile %22,5’i karıştırmayın. Bundan çıkan sonuç: her Türkçe token puanda 1,29 kat daha büyük bir pay taşır ve yanlış bir kelime orantılı olarak daha pahalıya gelir.

Karakter düzeyinde bir metrik iki dilde de neredeyse aynı miktarda malzeme görür — 1,02 oranı — dolayısıyla böyle bir asimetrisi yoktur.

15.5.2 Mekanizma, ölçülmüş hâliyle

Tahminler ucuzdur; bu tahmin sınanabilir. Doğru bir çeviri alın — 100 alan referansın kendisi — ve tam olarak bir morfemlik hata sokun; iki dilde de aynı anlamsal hata: bulunma hâli çıkma hâline dönüşsün, in X from X olsun.

Türkçede bu bir ektir: İstanbul'da → İstanbul'dan. Değişikliğin gövdeyi bozmayıp yalnızca eke dokunduğundan emin olmak için bozma, açık bir kesme işareti taşıyan kelimelerle sınırlandı; bu kelimelerde morfem sınırı bellidir. İngilizcede ise bir edattır: in → from.

Bu eşleştirme hakkında tablonun gösteremediği iki şey var ve ikisi de bu alt bölümün BLEU iddiasının aleyhine çalışıyor.

Birincisi, eşleşme tam değil. Türkçe 'da tartışmasız biçimde bulunma hâli, İngilizce in ise ancak bazen öyle — interested in, in 2016, in fact de değiştiriliyor ve bunların bir kısmı yalnızca yanlış değil, dilbilgisi açısından bozuk hâle geliyor.

İkincisi, iki satır aynı cümlelerden gelmiyor. Filtreler bağımsız çalıştı, yani koşulu sağlayan 264 Türkçe cümleye karşı 997 İngilizce cümle var ve Türkçe taraf cümle başına bir düzenleme alırken İngilizce taraf büyük olasılıkla birden fazla alıyor.

İki etki de İngilizce bozmayı daha ağır hâle getiriyor; yani BLEU karşılaştırmasına aşağıdaki iddianın aleyhine bir yanlılık katıyor. Türkçe cezasının buna rağmen daha büyük çıkması sonucun kendisi; kesin çarpanı ise bu tasarımın belirleyebileceği bir şey değil. Aynı yanlılık chrF okumasının ise lehine çalışıyor: İngilizce cümle başına tek düzenleme olsaydı İngilizce chrF cezası küçülür, aşağıdaki 0,57 de yükselirdi. Bu yüzden karşılaştırmanın tamamını keşifsel sayın. Güvenilecek sürüm, İngilizce tarafı aynı 264 çiftin İngilizce yarısında ve her cümlede yalnızca ilk eşleşmeyi değiştirerek çalıştırmaktır; burada düzeltilecek ilk şey de budur.

Eşleştirmedeki yanlılık hangi yöne çekiyor?

etki	BLEU oranına (1,18) etkisi	chrF oranına (0,57) etkisi
eşleşme tam değil (in her zaman bulunma hâli değil)	İngilizce ceza büyür, oran küçülür	İngilizce ceza büyür, oran küçülür
İngilizce cümle başına birden fazla düzenleme	aynı yön	aynı yön
net sonuç	BLEU iddiasının aleyhine: gerçek oran 1,18’den büyük olabilir	chrF okumasının lehine: chrF’in Türkçeye yumuşaklığı abartılmış olabilir, gerçek oran 0,57’den büyük olabilir

                              BLEU      chrF     BLEU/chrF     n
  Türkçe    X'da -> X'dan    -14.90    -3.05        4.89x      264
  İngilizce 'in' -> 'from'   -12.65    -5.34        2.37x      997

Şaşırtıcılık sırasına göre üç okuma.

BLEU Türkçe hatayı 1,18 kat daha sert cezalandırıyor. Yön, 1,29’luk token oranının öngördüğü yön ve büyüklük de aynı civarda — ama 1,18’i 1,29’dan türetilmiş diye okumayın, çünkü burada onu türeten hiçbir şey yok: iki sayı farklı alt kümelerden geliyor ve tek düzenlemelik bir ceza, token sayısının doğrusal bir fonksiyonu değil. Bu alt bölümün kurduğu şey işaret ve kabaca ölçek; aşağıdaki operasyonel nokta için de bu yeterli.

chrF Türkçe hatayı yalnızca 0,57 kat sert cezalandırıyor. 'da’yı 'dan yapmak on bir karakterlik bir kelimeye bir karakter ekler; in’i from yapmak iki karakterlik bir kelimeyi dört karakterlikle değiştirir. Karakter düzeyinde Türkçe hata gerçekten daha küçüktür ve chrF bunu söyler.

İki metrik arasındaki uyuşmazlık Türkçede iki kattan da büyük — 4,89’a karşı 2,37. Operasyonel olarak önemli olan sayı budur. İngilizcede BLEU bu hataya chrF’in yaklaşık iki buçuk katı ceza keser; Türkçede ise neredeyse beş katı. Dolayısıyla iki metrik Türkçe sistemleri daha kolay farklı sıralar ve hangi metriği seçtiğiniz hangi sistemi yayına alacağınıza karar verebilir.

Argümanın tamamı tek bir resme sığar ve içindeki her sayı yukarıdaki iki tablodan:

Aynı hata Türkçede neden daha pahalı — ve chrF neden katılmıyor

Dört maliyet çubuğu tek bir ölçekte çizildi; kesişme meselenin ta kendisi: kelimeler üzerine kurulu metrik Türkçe hatayı daha sert, karakterler üzerine kurulu metrik daha yumuşak cezalandırıyor — iki dilde de aynı şeyi ifade eden bir değişiklik için.

chrF’in önerilme nedeni (Popović 2015) ve WMT topluluğunun morfolojik olarak zengin diller için karakter düzeyinde ve nöral metriklere geçme nedeni budur. Bir Türkçe BLEU puanını bir İngilizce puanla karşılaştırmak da — “Türkçe sistemimiz 23, Almanca sistemimiz 34 alıyor, demek ki Türkçe daha zor” — aynı nedenle hiç geçerli bir karşılaştırma değildir. Metrik her dilde cümlenin farklı büyüklükte bir kısmını ölçüyor.

15.5.3 İkinci problem: kelime sırası

Türkçede kelime sırası İngilizceden daha serbesttir. İşaretsiz sıra özne-nesne-yüklemdir, ama öğeler vurgu için yer değiştirir ve aynı cümle için birkaç sıra tümüyle dilbilgiseldir. İngilizce çok daha az harekete izin verir.

Kelime n-gram metriği açısından sonuç Bölüm 15.3’ün zaten gösterdiğidir: bir öbeği taşımak anlamı bozmaz, ama yer değiştirme noktasından geçen her n-gram’ı yok eder. Bir öbeğin yerini değiştiren doğru bir İngilizce çeviri 50,27 aldı (büyük-küçük harf etkisi çıkarılınca 57,81). Yeniden sıralamanın ara sıra rastlanan bir şey değil, olağan bir üslup tercihi olduğu bir dilde çevirmenin meşru varyasyonu her seferinde benzer biçimde cezalandırılır.

İki problemin de aynı çözümü var ve bu daha iyi bir kelime n-gram metriği değil: karakter düzeyinde puanlayın (bu iki cezayı da ortadan kaldırmaz ama yumuşatır) ve insan yargıları üzerinde eğitilmiş bir modelle puanlayın.

15.6 Çevirmen olarak LLM’ler

Genel amaçlı bir model, çevirmen olması istenmeden de çeviri yapabilir. Soru çalışıp çalışmadığı değil, neye mal olduğu ve nerede kazandığı. İşte doğrudan karşılaştırma: zero-shot (sıfır atışlı) promptlanmış qwen3.5:9b’ye karşı opus-mt-tc-big, birebir aynı 400 cümlede. opus-mt-tc-big aslında her yön için bir tane olmak üzere iki modeldir (-tr-en ve -en-tr); ikisi de 237M parametrelidir ve başka hiçbir şey yapmaz.

Tablodan önce, onu nasıl okuyacağınıza karar veren iki şey. Kod çözücüyü belirtin. Bölüm 15.4 az önce örneklemenin bir çevirmene neye mal olduğunu ölçtü — aynı model ve aynı cümlelerde beam 4’te 30,17 BLEU’ya karşı sıcaklık 1,0’da 14,34 — ve ollama varsayılan olarak örnekleme yapar. Model kendi ayarını getirmezse ollama’nın genel varsayılanı sıcaklık 0,8 ve top-\(k\) 40’tır; ama kütüphanedeki bir model kendi ayarlarıyla gelebilir: qwen3.5:9b kaydı, bu yazının yazıldığı sırada sıcaklık 1,0, top-\(k\) 20, top-\(p\) 0,95 ve 1,5 değerinde bir presence penalty (daha önce geçmiş token’ları cezalandıran ayar) listeliyor. İstek bunları geçersiz kılmadıysa LLM satırı, Marian modelinin BLEU’sunun yarısını götüren aynı sıcaklıkla örneklendi; bunu biraz yumuşatan tek şey, çekilişi en olası token’larla sınırlayan top-\(k\) ve top-\(p\) (Bölüm 18 bunları ele alıyor). Bir LLM’i sohbet varsayılanında kıyaslayıp “LLM’ler kötü çeviriyor” sonucuna varmak, bu karşılaştırmayı yanlış yapmanın en yaygın yolu; aşağıdaki LLM satırı ise ancak kod çözme ayarları yanında yayımlanırsa yorumlanabilir. Yayımlanmadı; aynı eksik, kullanılan prompt metni ve bir akıl yürüten model olan qwen3.5:9b’nin düşünme (thinking) modunun açık olup olmadığı için de geçerli. Bu eksiği kapatmak bölümün size olan borcu: kod çözücü sabitlenerek yeniden çalıştırılana kadar o satırı bu modelin tavanı değil, bir ölçümü olarak görün.

Sayısal hassasiyeti de (ağırlıkların kaç bitle tutulduğunu) belirtin. ollama, etiketsiz bir modeli varsayılan olarak 4 bitlik nicemlemeyle sunar; opus-mt-tc-big ise transformers üzerinden nicemlenmemiş çalışıyor. Yani asıl karşılaştırma “237M’ye karşı 9B” değil, “nicemlenmemiş 237M’ye karşı 4 bitlik 9B”. Nicemlemenin, model morfolojik olarak zengin bir dili üretmek zorunda olduğunda daha çok zarar vermesi akla yatkın; bu da maliyetini farkın en büyük olduğu en-tr sütununa koyardı — ama bu burada ölçülmedi. Örnekleme de nicemleme de LLM’in puanını aşağı çekiyor; dolayısıyla 6 BLEU’luk rakam, iki modelin kendi arasındaki farkı küçük göstermekten çok büyük gösteriyor olabilir. Aşağıda ele alınan benchmark (kıyaslama kümesi) bulaşması ise ters yönde çekiyor.

wmt16 tr-en                          BLEU    chrF   s/sentence
  opus-mt-tc-big   greedy           31.44   59.53      0.013
  opus-mt-tc-big   beam-4           32.33   60.08      0.024
  qwen3.5:9b       zero-shot        29.37   58.32      1.088
  kaynağı kopyala (kontrol)          2.09   21.11

wmt16 en-tr                          BLEU    chrF   s/sentence
  opus-mt-tc-big   greedy           22.50   56.70      0.016
  opus-mt-tc-big   beam-4           23.13   57.41      0.064
  qwen3.5:9b       zero-shot        17.10   53.67      2.620
  kaynağı kopyala (kontrol)          2.10   19.87

Kontrol satırı şu yüzden var: sağlama kontrolünden (sanity check) geçirmediğiniz bir metrik, anlamadığınız bir metriktir. Sağlama kontrolü, sonucu önceden bilinen basit bir durumda metriği denemektir: kaynağı çevirmeden bırakmak 2,09 alıyor, yani yukarıdaki sayılar tesadüfi örtüşmeyi değil çeviriyi ölçüyor.

Tablonun çalıştıramadığı bir kontrol ve son sütunu hakkında bir uyarı. newstest2016 2016’dan beri kamuya açık — sacrebleu’nun içinde, GitHub’da, Hugging Face datasets’te, referans çevirileriyle birlikte. 2020’lerin bir web taramasıyla eğitilmiş herhangi bir LLM’in onu görmüş olması makul ve bu bulaşma LLM’in puanını şişirir. Yani bu, aşağıdaki sonucu hiçbir şekilde zayıflatmıyor: özel model, benchmark’ın rakip modelin eğitim verisinde bulunma olasılığına rağmen kazanıyor. Özel modelin tarafı daha temiz — Helsinki-NLP, WMT test kümelerini OPUS-MT eğitiminden dışlıyor — ama buradaki “zero-shot” prompt’ta örnek yok demek, bu veriyi hiç görmedi demek değil. Bulaşmadan etkilenmemiş bir sayıya ihtiyacınız varsa modelinizin bilgi kesim tarihinden (eğitim verisinin bittiği tarihten) sonra yayımlanmış bir test kümesi kullanın.

Saniyelere gelince: Bölüm 15.4’teki ms/sent sütunuyla aynı şekilde ölçülmediler; aynı modelin aynı beam genişliğinde orada 80 ms, burada 24 ms görünmesinin sebebi bu. Aynı nedenle BLEU da tablolar arasında karşılaştırılamaz: aynı model ve ayar orada 30,17, burada 32,33 alıyor, çünkü iki tablo farklı alt kümelerden (ilk 500 ve ilk 400 cümle) geliyor. Karşılaştırmayı tablo içinde yapın, asla tablolar arasında yapmayın; bir gecikme değeri yayımladığınızda da tek istek mi batch (yığın) mı olduğunu belirtin.

Buradan çıkarılacak üç şey.

Küçük özel model iki yönde de kazanıyor. 237M parametre 9B’yi yeniyor; İngilizceye 3 BLEU, Türkçeye 6 BLEU farkla ve 41 ila 164 kat daha hızlı — yöne ve beam genişliğine göre değişiyor: oran en küçük hâlinde (Türkçeye beam-4) 41 kat, en büyük hâlinde (Türkçeye greedy) 164 kat; İngilizceye çeviride gerçekten yayına alacağınız beam-4 ayarında 45 kat. Yalnızca bu dil çifti üzerinde eğitilmiş bir modeli bu dil çiftinde yenmek çok zordur.

Fark, Türkçeye çeviride iki kat büyük. Beklenecek ve kontrol edilecek asimetri budur: genel bir çok dilli model Türkçeden çok daha fazla İngilizce görmüştür ve morfolojik olarak zengin bir dili üretmek onu ayrıştırmaktan zordur. MT kalitenizin simetrik olduğunu asla varsaymayın — iki yönü de ölçün.

Her iki model için de Türkçeye çeviri daha zor. Hedef değişince opus-mt 32,33’ten 23,13’e düşüyor. Bunun bir kısmı gerçek zorluk, bir kısmı Bölüm 15.5’in ölçüm yapaylığı: hedef dil BLEU’ya %22,5 daha az token verdiğinde aynı kalitedeki çeviri daha düşük puan alır. Bu yanlılığı taşımayan chrF çok daha az düşüyor — 60,08’den 57,41’e. Aynı kontrol bir önceki madde için de geçerli: chrF’te LLM’in açığı İngilizceye 1,76, Türkçeye 3,74; yani farkın iki katına çıkması yalnızca BLEU’nun Türkçeye sertliğinden kaynaklanmıyor.

15.6.1 Özel modelin veremediği, bir LLM’in verdiği şeyler

Tablo LLM’i her ölçütte daha kötü gösteriyor. Cümle düzeyinde haber çevirisinde gerçekten de öyle. Yine de bir LLM’i tercih etmenin nedenleri bu benchmark’ın ifade edemeyeceği şeylerdir, çünkü WMT birbirinden bağımsız cümlelerin listesidir:

• Belge bağlamı. Cümle düzeyinde özel bir model her cümleyi bağımsız çevirir ve bu yüzden öncülü iki cümle önce geçen bir zamiri çözemez ya da bir sayfa boyunca tutarlı bir resmiyet düzeyi koruyamaz. Türkçe bunu somutlaştırır: o hem he, hem she, hem de it demektir; o bir doktor cümlesini İngilizceye çevirmek, cümlenin tek başına veremeyeceği bir seçimi zorunlu kılar. Bağlam yoksa sistem, eğitim verisinde en sık gördüğü seçeneğe döner; o bir doktor cümlesinin he is a doctor olması böyle olur. MT’deki cinsiyet yanlılığının iyi belgelenmiş kaynaklarından biri budur (Prates vd., 2019 bunu doğrudan Türkçe ve zamirleri cinsiyet taşımayan başka dillerle sınadı).
• Terminolojiye uyum. Sözlüğü prompt’a koyun, model çoğunlukla ona uyar. Özel bir modelde terminolojiyi dayatmak kısıtlı kod çözme ya da yeniden eğitim demektir.
• Üslup ve hedef kitle. Bunu hukuki bir okur için, resmî bir dille, ikinci çoğul şahsı koruyarak çevir bir talimattır, bir model değil.
• Her çift, hemen. Gerçek bir ürünün ihtiyaç duyduğu çiftlerin çoğu için opus-mt yoktur ve birini eğitecek veri de yoktur. Önce denemeye değer bir ara seçenek de var: M2M-100 (Fan vd., 2021) ve NLLB-200 (NLLB Team, 2022) gibi çok sayıda dili kapsayan (massively multilingual) özel modeller, tek bir modelle 100 ila 200 dil arasında doğrudan çeviri yapar. Bir LLM’den hâlâ çok daha küçüktürler; ama yayına almadan önce lisansı okuyun: NLLB-200 ağırlıkları yalnızca ticari olmayan kullanım için yayımlandı.

Vilar vd. (2023), prompt tercihlerinin burada ne kadar önemli olduğunu sistematik biçimde inceleyen çalışmadır; kısa hâli şu: prompt’taki örnekler işe yarar ve örneklerin kalitesi sayısından daha çok önem taşır.

2026’da pratikteki mimari genellikle ikisinden yalnızca biri değil: hacim için özel bir model, bağlam ve terminolojinin önemli olduğu belgeler için bir LLM ve önlerinde bir yönlendirici. Bölüşümü maliyet tablosu belirler: büyük ölçekte 0,024 saniyeye karşı 1,088 bir yuvarlama farkı değil, bir makineyle kırk beş makine arasındaki farktır. Yönlendiriciyi çalıştıran sinyal çoğu zaman referanssız bir kalite kestirimi (QE) puanıdır (ör. CometKiwi): özel modelin çıktısı düşük puan alan cümleler LLM’e ya da bir insana gider.

15.7 Düşük kaynaklı çeviri

Türkçe–İngilizce düşük kaynaklı değildir; açık paralel derlemleri bir araya getiren OPUS koleksiyonunda milyonlarca çift var. Ama sektörde karşınıza çıkan çeviri problemlerinin çoğu öyledir: kimsenin veri yayımlamadığı bir dil çifti ya da — çok daha sık — kimsenin veri yayımlamadığı bir alan. Hukuk Türkçesi, klinik Türkçe ve tek bir şirketin iç sözcük dağarcığı, ne kadar haber metni bulunursa bulunsun düşük kaynaklıdır.

Var olan kaynak tek dilli hedef metindir. Kendi belgeleriniz elinizde; çevirileri değil.

Geri çeviri (back-translation) (Sennrich vd. 2016a) bunu eğitim verisine dönüştürür. Ters yönde kaba bir sistem eğitin, tek dilli hedef dil metninizi onunla kaynak dile çevirin ve bu sentetik çiftleri, sentetik taraf girdi olacak şekilde eğitime ekleyin.

Sentetik kaynak kötü olabilir; bu beklediğiniz kadar önemli değildir, çünkü modelin öğrenmesi gereken tek şey hedef tarafı üretmektir ve hedef taraf gerçek insan metnidir.

Yöntemin püf noktası da işe yaramasının nedeni de bu asimetridir: gürültülü yarı, modelin hatalara dayanıklı olabileceği girdi tarafındadır; temiz yarı ise modele ne yazacağının öğretildiği çıktı tarafında.

Yakından ilişkili iki yöntem daha:

• Alan içi çiftlerle fine-tuning. Birkaç bin gerçek alan içi çift, genellikle büyük miktarda sentetik veriyi yener. Bir şey üretmeden önce bunları çeviri belleklerinden toplayın.
• Terminoloji enjeksiyonu. Alan uyarlaması sıklıkla bir akıcılık problemi değil bir sözcük dağarcığı problemidir: sizin kurum diliniz stock iken model hisseyi share diye çevirir. Bu, yeniden eğitim nedeni değil, kod çözmede veya prompt’ta uygulanacak bir kısıttır — ve Bölüm 15.6’da ele aldığımız LLM’lerin gerçekten üstün olduğu yer de burasıdır.

Terminoloji kayması bir çeviri projesini iptal ettiren kusurdur ve Bölüm 15.3’teki metriklerin hiçbiri onu göremez: modelin kelimesi de sizin kelimeniz de makul çevirilerdir, dolayısıyla genel bir referansla hesaplanan BLEU farkı göremez. Doğrudan ölçün — sözlüğünüzü alın ve sistemin sizin teriminizi kaç kez kullandığını sayın.

15.8 Translate-train, translate-test ya da hiçbiri

Türkçe bir göreviniz var — sınıflandırma, erişim, bilgi çıkarma — ve en iyi model ya da etiketli veri İngilizce. Üç seçenek var ve aralarındaki tercih bir modelleme sorusu değil, bir hata yayılımı sorusudur.

Üç hat, üç kusur profili

yaklaşım	ne olur	hatalar nerede birikir
Translate-train	İngilizce eğitim verisini bir kez Türkçeye çevir, Türkçe bir model eğit	çeviri gürültüsü eğitim verisine işlenir, ama model onu tutarlı biçimde görür ve kısmen etrafından dolaşmayı öğrenebilir
Translate-test	İngilizce modeli koru, gelen her Türkçe girdiyi çıkarım anında çevir	istek anındaki bir çeviri hatası her seferinde yanlış bir tahmindir ve toparlanma şansı yoktur
Hiçbiri	çok dilli bir model doğrudan uygulanır (Bölüm 8)	hiç çeviri hatası yok; çok dilli modelin Türkçede feda ettiği ne ise o

translate-train — etiketli eğitim verisini makineyle hedef dile çevirip orada eğitmek. Çeviri maliyeti bir kez, çevrimdışı ödenir ve soktuğu gürültü en azından tutarlıdır. ↩︎

translate-test — modeli özgün dilinde tutup gelen her isteği o dile çevirmek. Yeniden eğitilecek bir şey yoktur ve kullanıcıya giden her tahmin artık kontrol etmediğiniz bir çeviriye bağlıdır. ↩︎

Kararı veren aritmetik: translate-test çeviri maliyetini istek başına, sonsuza kadar öder ve her tahminde çevirinin hata oranını devralır. Translate-train bir kez öder. Sisteminiz saniyede bin istek karşılayan bir sohbet botuysa maliyet hesabı translate-train’i açıkça öne çıkarır.

Pratikte kararı veren iki husus daha:

1. MT’niz hangi yönde daha iyi? İki yön simetrik değildir. Varsaymadan önce ikisini de ölçün.
2. Görev ne? Translate-test yüzey biçimine bağlı her şeyi yok eder — Bölüm 13’ün span ofsetleri çeviride korunmaz, dolayısıyla bilgi çıkarma onu ancak tahmin edilen span’leri bir kelime hizalaması üzerinden özgün metne geri eşleyen ek bir adımla kullanabilir; o adım da kendi hatalarını ekler. Belge sınıflandırma ise bundan görece az etkilenir.

Bölüm 16 tablonun üçüncü satırını Türkçe için ölçüyor — aynı görevde çok dilli bir modele karşı tek dilli bir Türkçe model — ve genel bir hüküm değil, bir protokol çıkarıyor. Translate-train ve translate-test bu kitapta ölçülmüyor; bu bölümün katkısı mekanizma ve aritmetik. Translate-test’i kendi görevinizde 7. alıştırmayla ölçebilirsiniz. Translate-train için aynı görevin eğitim verisini çevirip bir model eğitin ve onu aynı Türkçe test kümesinde translate-test sonucuyla karşılaştırın.

15.9 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. İlk beşi bu bölümün tartışmayla değil ölçümle çözdüğü sorular; altıncısını ise aritmetik çözüyor.

Not1. Türkçe sisteminiz 23, Almanca sisteminiz 34 BLEU alıyor. Türkçe daha mı zor?

Bunu çıkaramazsınız, çünkü BLEU iki dilde cümlenin aynı miktarını ölçmüyor. İngilizce aynı içerik için %29 daha fazla kelime token’ı kullanır; yani Türkçe, kelime n-gram metriğine %22,5 daha az yuva verir ve her hata puanın daha büyük bir kısmına mal olur.

Burada ölçüldü: aynı anlamsal hata — bulunma hâlinin çıkma hâline dönmesi — Türkçede 14,90 BLEU, İngilizcede 12,65 BLEU’ya mal oluyor. On bir puanlık farkınızın bir kısmı metrikten kaynaklanıyor.

İki dilde de hemen hemen aynı miktarda malzeme gören chrF’i (1,29’luk kelime oranına karşılık 1,02’lik karakter oranı) ve bir nöral metriği raporlayın. Sonra karşılaştırın.

Not2. Sohbet hattınızdaki sıcaklığı çeviri hattınıza kopyalıyorsunuz. Ne olur?

Sohbetlerde sık görülen 1,0 sıcaklıkta puan yarıdan fazla düşer (0,7’de yaklaşık dört puan). Aynı model ve cümlelerde ölçüldü: beam-4 30,17 BLEU alıyor, 1,0 sıcaklıkla örnekleme 14,34. Bu, BLEU’da büyük bir düşüş; çeviri kalitesinin yarıya indiğini gösteren bir ölçüm değil.

Çeviride geçerli pek çok karşılık vardır, ama burada sistemden çeşitlilik istemiyorsunuz; modelin en yüksek puanladığı diziyi istiyorsunuz. Bu, kaliteyle değil model olasılığıyla ilgili bir ifadedir. Beam search de o diziyi bulmak için kesin bir arama değil, sezgisel bir yöntemdir. Örnekleme ise bilerek çeşitlilik katar; daha kötü bir token çekme olasılığı da cümle boyunca birikir. Sohbet yanıtını doğal kılan ayar, bu modelde ve bu test kümesinde yaklaşık 16 BLEU’ya mal oldu. Kod çözmeyi, gerçekten devreye alacağınız görev üzerinde değerlendirin.

Not3. Daha geniş bir beam buna değer mi?

4’ten sonrası neredeyse hiç. Bu modelde beam 1’den beam 2’ye geçmek +0,61 BLEU kazandırıyor; beam 2’den ta beam 64’e gitmek yedi kat hesaplama karşılığında yalnızca +0,57 daha kazandırıyor.

Yaygın kanıyı da tekrarlamadan önce kontrol edin: kalitenin büyük beam genişliklerinde bozulduğu “beam search laneti” burada hiç görünmüyor — BLEU 64’e kadar monoton biçimde yükseliyor ve uzunluk oranı sabit kalıyor. En olası sebep model değil kod çözücü: generate() bir beam’in puanını varsayılan olarak uzunluğuna göre normalleştiriyor — length_penalty=1.0 — ve bu, Murray ve Chiang’ın (2018) incelediği, lanetin arkasındaki uzunluk yanlılığına karşı kullanılan standart düzeltmelerden biridir. Laneti gerçekten aramak istiyorsanız bu normalleştirmeyi kapatın (length_penalty=0.0) ve beam’i yeniden tarayın. Ayrıca yükselişler o kadar küçük ki hiçbiri anlamlılık açısından test edilmedi; yani “monoton biçimde yükseliyor” ifadesi yalnızca nokta kestirimlerini tarif ediyor, fazlasını değil.

Not4. Uzunluk cezasını ayarladıktan sonra BLEU’nuz 1,2 puan arttı. Sistem düzeldi mi?

Muhtemelen hayır. Uzunluk cezasını 0,2’den 2,0’a taramak BLEU’yu 1,26 puan, chrF’i 0,09 puan oynatıyor; çıktı uzunluk oranı ise 1,007’den 1,041’e gidiyor.

BLEU, kaç kelime ürettiğinize kısalık cezası ve precision paydası üzerinden tepki verir; bu taramada oran hep 1’in üstünde olduğu için kısalık cezası devre dışı ve oynayan yalnızca precision paydası. Ayarı BLEU’ya göre yapmak çıktı uzunluğunu referansa doğru çeker; çıktısı referanstan uzun olan bu sistemi biraz daha kısa çıktıya iter. Bir değişiklik BLEU’yu oynatıp chrF’i sabit bırakıyorsa, bunu iyileşme saymadan önce bir metrik yapaylığından şüphelenin. Hangisinin geçerli olduğunu çıktıları okuyarak anlayın.

Not5. 9B’lik bir LLM mi, 237M’lik özel bir model mi?

Birebir aynı cümlelerde ölçüldü: özel model İngilizceye 3 BLEU, Türkçeye 6 BLEU farkla ve 41–164 kat daha hızlı çalışarak kazanıyor. Cümle düzeyinde haber çevirisinde ve bu değerlendirme kurulumunda, ölçülen her eksende özel model daha iyi seçimdir.

Benchmark’ın ifade edemediği bir şeye ihtiyacınız olduğunda LLM’e başvurun: zamirler ve üslup için belge bağlamı, prompt’ta bir sözlük, kimsenin model yayımlamadığı bir dil çifti. Bunlar gerçek ihtiyaçlardır ama bu tablo onları gösteremez — WMT birbirinden bağımsız cümlelerin listesidir.

Not6. Translate-train mi, translate-test mi?

Translate-test çeviri maliyetini her istekte sonsuza kadar öder ve her çeviri hatasını yanlış bir tahmine çevirir. Translate-train bir kez, çevrimdışı öder; gürültü de en azından tutarlı geldiği için model onu kısmen telafi etmeyi öğrenebilir.

Gerisine iki şey karar verir: MT’nizin gerçekte hangi yönde daha iyi olduğu — ölçün, simetrik değiller — ve görevinizin yüzey biçimine bağlı olup olmadığı. Span çıkarma, ek bir hizalama adımı olmadan translate-test’e dayanamaz, çünkü ofsetler çeviriye aktarılmaz. Belge sınıflandırma ise görece iyi dayanır.

15.10 Mülakat soruları

Kaynak konusunda — Bölüm 2’deki çekincenin aynısı. Aşağıdakiler bu kitabın baştan sona kullandığı iki güvenilir açık kaynakta tekrar tekrar geçen sorulardır; bunlara bu bölümün ölçümlerinin cevaplanabilir kıldığı sorular da ekleniyor.

15.10.1 Görevi anlayıp anlamadığınızı sınayanlar

S: Bugünkü biçimiyle attention neden başka bir şey için değil de çeviri için önerildi?

Çünkü encoder-decoder RNN bütün kaynağı tek bir sabit uzunlukta vektöre sıkıştırıyordu ve çeviri bu darboğazı belirgin kılıyordu: cümleler uzadıkça kalite sert biçimde düşüyordu ve bunun belirli bir örüntüsü vardı: model cümlenin başını çeviriyor, sonra kaynaktan uzaklaşıp savruluyordu. Attention her kaynak token’ı için bir vektör tutarak sıkıştırmayı kaldırdı. Neden uyduğunu da söyleyin: çevirinin çıktıdan girdiye karşılık gelme özelliği vardır, bu yüzden tek bir kaynak konumda yoğunlaşabilen ağırlıklı bir ortalama doğru arayüzdür — ilk attention haritalarının kelime hizalamalarına benzemesinin ve aynı okumanın derin bir dil modelinde kendiliğinden geçerli olmamasının nedeni budur.

S: BLEU gerçekte neyi hesaplar?

n = 1’den 4’e modified n-gram precision, geometrik ortalama, çarpı kısalık cezası. Bir örneği elle hesaplayabilmeli ve bir test kümesinde sayımların formül uygulanmadan önce cümleler üzerinde toplandığını söyleyebilmelisiniz. Sonra göremediklerini söyleyin: farklı kelimelerle kurulmuş her doğru çeviri, meşru bir yeniden sıralama ile yanlış bir sıralama arasındaki fark ve — varsayılan olarak — büyük-küçük harfte farklılaşan her şey. Bir öbeği taşıyan doğru bir İngilizce çeviri 50 alıyor.

S: Ne zaman BLEU raporlamazsınız?

Asla — raporlayın, çünkü karşılaştırılabilirlik önemlidir ve yokluğu kaçamak gibi görünür. Soru onun yanında ne raporladığınızdır. Morfolojik olarak zengin bir hedef için chrF, çünkü gövdesi doğru ama eki yanlış bir kelimeye kısmi puan verir. Ayrıca bir nöral metrik, çünkü ailenin anlamı gören tek üyesidir. Asıl hata, sistemleri yalnızca BLEU’ya göre sıralamaktır.

15.10.2 Bir tane yayına alıp almadığınızı sınayanlar

S: Model yükseltmesinden sonra MT kaliteniz düştü ama yalnızca bir müşteride. Hatayı bulun.

Neredeyse kesinlikle terminoloji, kalite değil. Müşterinin kurum içi terimlerinin çevirisi, onlar farkında olmadan değişti: yeni model onların terimini farklı çeviriyor. Derlem düzeyinde bir referans metriği bunu ortaya çıkarmaz, çünkü iki kelime de geçerli çeviridir ve fark test kümesi genelinde yuvarlama hatası kadardır. İlkesel olarak görünmez değil: onların sözlüğünden kurulmuş terim odaklı bir test kümesi ya da terminoloji hata kategorisi olan bir MQM bunu doğrudan görür. Göremeyecek olan, zaten koşturduğunuz toplam BLEU’dur. Doğrudan ölçün: sözlüklerini alın ve terimlere ne sıklıkla uyulduğunu sayın. Sonra sorunu yeniden eğiterek değil, kod çözmede veya prompt’ta düzeltin.

S: 40 dil çifti için çeviri gerekiyor ve bir bütçeniz var.

Yönlendirin. Var olduğu ve hacmin gerekçelendirdiği her çift için özel bir model, uzun kuyruk ile bağlam veya terminoloji kontrolü gereken belgeler için bir LLM. Bu ayrıma karar veren sayı cümle başına gecikmedir. Burada ölçülen 0,024 saniyeye karşı 1,088 saniye, bir makineyle kırk beş makine arasındaki farktır. Ayrıca iki yönü ayrı ölçeceğinizi söyleyin, çünkü simetrik değiller — aynı model ailesi ve derlemde Türkçeden 32,33’e karşı Türkçeye 23,13.

S: Paralel verisi olmayan bir alan için MT’yi nasıl kurarsınız?

Geri çeviri. Neden işe yaradığını da söyleyebilmelisiniz: kaba bir ters yön sistemi eğitin, tek dilli hedef metninizi onunla kaynağa çevirin ve sentetik taraf girdi olacak şekilde o çiftlerle eğitin. Gürültülü yarı, modelin hatalara dayanıklı olması beklenen girdi tarafındadır. İnsan elinden çıkan temiz yarı ise çıktı tarafındadır; model ne yazacağını orada öğreniyor. Ardından ilk olarak ne deneyeceğinizi söyleyin: bir çeviri belleğinde birkaç bin gerçek alan içi çift bulmak — bunlar genellikle büyük miktarda sentetik veriyi yener.

15.11 2026 alet çantası

Bu bölümdeki her şey aşağıdaki sürümlerle tek bir dizüstü bilgisayarda çalıştı.

Bu sayıların elde edildiği yazılım yığını. Python 3.14.5, Apple Silicon

kütüphane	kullanılan sürüm	burada ne işe yarıyor
sacrebleu	2.6.0	BLEU, chrF ve — en az onlar kadar önemlisi — test kümesini indirmek ve adı ile sürümüyle kesin olarak belirlemek
transformers	5.15.1	Marian modeli ve Bölüm 15.4’teki her kod çözme ayarı
torch	2.13.0	üzerinde çalıştığı MPS arka ucu
ollama	0.24.0	birebir karşılaştırma için qwen3.5:9b’yi varsayılan nicemlemesi Q4_K_M ile sunmak (llama.cpp’nin, ağırlıkların çoğunu 4 bitle, bir kısmını daha yüksek hassasiyetle tutan karışık nicemleme biçimi)

Yukarıda kullanılmayan ama bilinmesi gereken araçlar:

Daha geniş ekosistem, yazıldığı andaki sürümler

kütüphane	güncel sürüm	ne zaman kullanılır
unbabel-comet	2.2.7	WMT topluluğunun artık ilk sırada raporladığı nöral metrik; bir GPU (CPU’da da çalışır, ama yavaş) ve model indirmesi ister, ikisine de değer
ctranslate2	4.8.1	Marian ve benzeri modelleri PyTorch eager moddan 2–4 kat hızlı, int8 nicemlemeyle sunmak — yukarıdaki gecikme tablosundan sonraki bariz adım
sentencepiece	0.2.2	bu modellerin üzerine kurulduğu alt kelime sözlüğü (Bölüm 8.3)
sacremoses	0.2.0	Moses tokenizer ve truecaser; eski MT sonuçlarını yeniden üretirken hâlâ gerekli
stanza	1.14.0	girdiniz cümle değil belge olarak geldiğinde Türkçe için cümle bölme ve morfolojik çözümleme
nltk	3.10.3	kendi BLEU’su var ve sacrebleu’nunkiyle eşleşmiyor — Post’un makalesinin (2018) neden yazılmak zorunda kaldığının canlı bir örneği

15.12 Lab: bir Türkçe–İngilizce hattı kurun ve değerlendirin

Metniniz olan bir alan seçin — kendi belgeleriniz, alanınızdaki açık bir derlem, ürün açıklamaları, destek kayıtları. Yaklaşık 100 kaynak cümleye ve değerlendirme yarısı için insan çevirisi olan 30 cümleye ihtiyacınız var. O 30’u kendiniz üretmek labın parçası.

15.12.1 Adım 1 — her şeyden önce test kümesini adlandırın

Hangi cümlelerde değerlendirme yaptığınızı ve nereden geldiklerini yazın. Açık bir küme kullanıyorsanız sacrebleu’nun adlandırdığı gibi adlandırın. Dünyadaki yeniden üretilemez MT sonuçlarının yarısı bu adım atlandığı için yeniden üretilemez.

15.12.2 Adım 2 — özel bir modelle çevirin, iki yönde de

opus-mt-tc-big-tr-en ve -en-tr, beam 4. Cümle başına saniyeyi kaydedin. BLEU’yu imzasıyla ve chrF’i raporlayın. İki yön eşleşmeyecek; farkın ne kadarının metrik olduğuna dair Bölüm 15.5’in açıklamasını okumadan önce farkı not edin.

15.12.3 Adım 3 — aynı cümleleri bir LLM’le çevirin

Varsa sözlüğünüzü prompt’a koyun. Cümle başına saniye ve token sayısını kaydedin, çünkü maliyet argümanı burada kuruluyor.

15.12.4 Adım 4 — kontrol

Çevrilmemiş kaynağı referansa göre puanlayın. Sıfıra yakın olmalı. Değilse metriğiniz çeviri kalitesinden başka bir şeyi yakalıyordur — ortak özel adlar, sayılar ya da sandığınızdan yakın bir dil çifti — ve yukarıdaki her sayının yeniden okunması gerekir.

15.12.5 Adım 5 — kod çözme ayarlarını tarayın

Beam 1, 4, 16 ve 0,7 sıcaklıkta örnekleme. BLEU’yu cümle başına saniyeye karşı çizin. Bölüm 15.4’ün tablosunu kendi verinizde yeniden üretiyorsunuz ve soru sizin eğrinizin nerede düzleştiği. Komşu ayarlar arasındaki farkları Bölüm 15.4’teki --paired-bs komutuyla test edin.

15.12.6 Adım 6 — yirmi çıktı okuyun

Düzgünce, kaynağın yanında. Puanlara tekrar bakmadan önce iki sistemi kendiniz sıralayın. Sonra sizin sıralamanızla BLEU’nunkinin ayrıştığı bir cümle bulun ve hangisinin yanlış olduğunu ve nedenini yazın.

15.12.7 Adım 7 — sözlüğünüz varsa terminolojiyi ölçün

Her sözlük terimi için, her sistemin bir eşanlamlı yerine sizin kelimenizi kaç kez kullandığını sayın. Gerçek bir yerelleştirme projesine karar veren sayı budur ve yukarıdaki metriklerin hiçbirinde görünmez.

15.12.8 Neyi teslim edeceksiniz

Sistemleri BLEU, chrF, cümle başına saniye ve terminoloji uyumu açısından karşılaştıran tek bir tablo; artı yirmi cümlelik okuma, bulduğunuz uyuşmazlık ve hangi sistemi yayına alacağınıza, cevabın hangi hacimde değiştiğine dair bir paragraf.

15.13 Alıştırmalar

1. BLEU elle. Bir cümle çifti için BLEU’yu hesap makinesiyle hesaplayın, sonra sacrebleu ile kontrol edin. Şimdi adayda bir çekim ekini değiştirip yeniden hesaplayın. BLEU’nun ne kadar, chrF’in ne kadar oynadığını ve anlamın bunlardan herhangi biri kadar değişip değişmediğini raporlayın.

2. Yeniden sıralama vergisi. Doğru bir çeviri alın ve bir öbeği başka bir geçerli konuma taşıyın. Öncesi ve sonrası için BLEU’yu hesaplayın. Sonra aynı şeyi yeniden sıralamanın daha serbest olduğu Türkçede yapın ve iki cezayı karşılaştırın.

3. Laneti bulun ya da bulamayın. Seçtiğiniz bir modelde beam genişliğini 1’den 128’e tarayın ve BLEU ile çıktı uzunluğunu çizin. Kalite bozuluyorsa hangi genişlikte olduğunu söyleyin; bozulmuyorsa modelinizin arama sırasında uzunluğa göre normalleştirme yapıp yapmadığını bulun.

4. Uzunluk cezası yapaylığı. Bir geliştirme kümesinde BLEU’yu en büyükleyecek şekilde uzunluk cezasını ayarlayın. BLEU kazancını, chrF kazancını ve çıktı uzunluk oranındaki değişimi raporlayın. Ayarlanmış değeri yayına alıp etmeyeceğinize karar verin.

5. Yön asimetrisi. Aynı model ailesini aynı derlemde iki yönde de ölçün. Farkın ne kadarının zorluk, ne kadarının Bölüm 15.5’in metrik etkisi olduğunu kendi verinizin kelime ve karakter oranlarını kullanarak açıklayın.

6. Geri çeviri yapın. Alanınızda 2.000 tek dilli cümle alın, hazır bir modelle kaynak dile çevirin ve modeli sentetik çiftlerle fine-tune edin. Gerçek, ayrılmış (held-out) bir küme üzerindeki değişimi raporlayın — ve alanda işe yarayıp alan dışında zarar verip vermediğini kontrol edin.

7. Translate-test hata yayılımı. Bir sınıflandırma görevi alın, test girdilerini çevirin ve doğruluğu ölçün. Sonra yanlış sınıflandırılmış on belgeyi elle inceleyin: kaçı model hatası, kaçı çeviri hatası? Bu oran hattın lehine ya da aleyhine argümandır.

15.14 Daha derine

Önce BLEU imzanızı yazdırın. Bir sayıyı hangi tokenizer, büyük-küçük harf işlemi ve smoothing’in ürettiğini söyleyemiyorsanız o sayı başkasınınkiyle karşılaştırılamaz — Post’un (2018) argümanının tamamı budur.

Makalelerin ötesi

kaynak	ne olduğu
sacrebleu	referans uygulama ve imza mekanizması; ayrıca chrF ve TER’i doğru hesaplamanın en kolay yolu
OPUS-MT	bu bölümde 9B’lik bir LLM’i yenen özel modeller, eğitim tarifleriyle birlikte yayımlanmış
Stanford CS224N	makine çevirisi dersleri; attention’ın icat edildiği MT probleminden türetilişi dâhil
The Annotated Transformer	mimarinin çalıştırılabilir kod hâli, bir çeviri görevi etrafında yazılmış
ACL Anthology	WMT’nin her yılki bulgular (findings) makalesi, ücretsiz — ortak görev raporları alanın her yılki durumunu gösterir
Coding a Transformer from scratch in PyTorch — Umar Jamil	encoder–decoder çeviriyi baştan sona kurar; bu bölümün özel modellerinin hâlâ kullandığı mimari

Birincil kaynaklar

konu	kaynak
metrik ve nasıl raporlanacağı	Papineni vd. (2002); Post (2018)
kelime yerine karakter n-gram’ları	Popović (2015)
öğrenilmiş bir metrik	Rei vd. (2020)
insan değerlendirmesinin gerçekte ne ölçtüğü	Freitag vd. (2021)
bir WMT sonucunu fazla iddiaya kaçmadan okumak	Kocmi vd. (2024)
nöral MT’nin başladığı yer	Sutskever vd. (2014); Bahdanau vd. (2015)
ve yerini aldığı şey	Brown vd. (1993); Koehn vd. (2003)
nöral dönüşten sonra da süren kusurlar	Koehn ve Knowles (2017)
geri çeviri, hâlâ en güçlü veri numarası	Sennrich vd. (2016a)
bir LLM’i çeviri için promptlamak	Vilar vd. (2023)

15.15 Akılda kalması gerekenler

• Attention bir çeviri hatasının onarımıydı. Encoder-decoder RNN bütün bir cümleyi tek bir sabit vektöre sıkıştırıyordu ve uzun cümlelerde kalite sert biçimde düşüyordu. Her kaynak token’ı için bir vektör tutmak bunu düzeltti. Bugün her şeyi çalıştıran mimari orada doğdu.

• BLEU, doğru bir çeviriye 50,27 veriyor — tek bir öbeği taşıdığı ve iki kelimede büyük-küçük harfte ayrıştığı için. BLEU, kısalık cezalı modified n-gram precision’dan başka bir şey değildir; aynı anlamı farklı kelimelerle veren çeviriyi de anlamı da göremez, meşru bir yeniden sıralamayı yanlış olandan ayıramaz. Raporlayın, asla yalnızca onun üzerinden sıralamayın ve imzasını her zaman verin.

• Bu derlemde İngilizce/Türkçe kelime token’ı oranı 1,29. Aynı içerik İngilizcede 1,29 kat fazla kelime token’ı ama yalnızca 1,02 kat fazla karakter gerektiriyor; yani kelime n-gram metriğinin Türkçede %22,5 daha az yuvası var (\(1 - 1/1{,}29\)) ve her hata orantılı olarak daha pahalı. Her dile karşılaştırılabilir bir hata sokan keşifsel bir deneyde (iki dilde farklı cümle alt kümeleriyle) BLEU Türkçede 14,90, İngilizcede 12,65 puan kesiyor; chrF ise 3,05’e karşı 5,34 puan. BLEU cezası chrF cezasının Türkçede 4,89, İngilizcede 2,37 katı — seçtiğiniz metriğin hangi sistemi yayına alacağınıza karar verebilmesinin nedeni bu.

• BLEU’yu diller arasında asla karşılaştırmayın. “Türkçe 23, Almanca 34 alıyor” zorluk hakkında bir ifade değildir; metrik her cümlenin farklı bir kısmını ölçüyor.

• Kod çözme parametreleri model ayarı değil görev ayarıdır. Aynı model ve cümlelerde beam 4 30,17, 1,0 sıcaklıkta örnekleme 14,34 alıyor. Sohbeti doğal kılan ayar burada puanın %52,5’ini götürdü.

• Yaygın kanıyı tekrarlamadan önce kontrol edin. “Beam search laneti” burada hiç görünmedi — BLEU beam 64’e kadar monoton biçimde yükseldi ve uzunluk oranı sabit kaldı. Görünen şey, sert biçimde azalan getiriler: beam 1→2 +0,61, beam 2→64 ise yedi kat hesaplama karşılığında +0,57 kazandırıyor.

• chrF sabit kalırken gelen bir BLEU artışı, metrik yapaylığından şüphelenmek için bir sebeptir. Uzunluk cezasını taramak BLEU’yu 1,26, chrF’i 0,09 puan oynatıyor; BLEU’daki bu oynama çıktı uzunluğunu izliyor. Kazanca inanmadan önce çıktıları okuyarak doğrulayın. Ayarı BLEU’ya göre yapmak çıktı uzunluğunu referansa doğru çeker; buradaki gibi uzun çıktı üreten bir sistemi kısaltır.

• 237M’lik özel bir model 9B’lik bir LLM’i iki yönde de yendi; İngilizceye 3, Türkçeye 6 BLEU farkla ve 41–164 kat daha hızlı. Benchmark’ın ifade edemediği bir şeye ihtiyacınız olduğunda LLM’e başvurun: belge bağlamı, sözlük uyumu, üslup ya da kimsenin model yayımlamadığı bir çift.

• İki yönü de ölçün. Aynı model ailesi ve derlemde Türkçeden 32,33, Türkçeye 23,13. MT kalitesinin simetrik olduğunu asla varsaymayın; asimetri hat tasarımına karar verir.

• Translate-test sonsuza kadar öder, translate-train bir kez. Ayrıca translate-test yüzey biçimine bağlı her şeyi bozar — span ofsetleri, ek bir hizalama adımı olmadan çeviride korunmaz.

Bu bölümde Türkçenin eklemeli yapısını metrik düzeyinde gördük; Bölüm 16 aynı yapıyı tokenization’dan modele kadar bütün hattın konusu yapıyor.

Bahdanau, Dzmitry, Kyunghyun Cho, ve Yoshua Bengio. 2015. “Neural Machine Translation by Jointly Learning to Align and Translate”. International Conference on Learning Representations.

Brown, Peter F., Stephen A. Della Pietra, Vincent J. Della Pietra, ve Robert L. Mercer. 1993. “The Mathematics of Statistical Machine Translation: Parameter Estimation”. Computational Linguistics 19 (2): 263-311.

Freitag, Markus, George Foster, David Grangier, Viresh Ratnakar, Qijun Tan, ve Wolfgang Macherey. 2021. “Experts, Errors, and Context: A Large-Scale Study of Human Evaluation for Machine Translation”. Transactions of the Association for Computational Linguistics 9: 1460-74.

Kocmi, Tom, Vilém Zouhar, Christian Federmann, ve Matt Post. 2024. “Navigating the Metrics Maze: Reconciling Score Magnitudes and Accuracies”. Proceedings of ACL.

Koehn, Philipp, ve Rebecca Knowles. 2017. “Six Challenges for Neural Machine Translation”. Proceedings of the First Workshop on Neural Machine Translation.

Koehn, Philipp, Franz Josef Och, ve Daniel Marcu. 2003. “Statistical Phrase-Based Translation”. Proceedings of NAACL-HLT.

Meister, Clara, Ryan Cotterell, ve Tim Vieira. 2020. “If Beam Search Is the Answer, What Was the Question?” Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing, 2173-85.

Murray, Kenton, ve David Chiang. 2018. “Correcting Length Bias in Neural Machine Translation”. Proceedings of the Third Conference on Machine Translation, 212-23.

Papineni, Kishore, Salim Roukos, Todd Ward, ve Wei-Jing Zhu. 2002. “BLEU: a Method for Automatic Evaluation of Machine Translation”. Proceedings of ACL.

Popović, Maja. 2015. “chrF: Character n-gram F-score for Automatic MT Evaluation”. Proceedings of the Tenth Workshop on Statistical Machine Translation.

Post, Matt. 2018. “A Call for Clarity in Reporting BLEU Scores”. Proceedings of the Third Conference on Machine Translation.

Rei, Ricardo, Craig Stewart, Ana C Farinha, ve Alon Lavie. 2020. “COMET: A Neural Framework for MT Evaluation”. Proceedings of EMNLP.

Sennrich, Rico, Barry Haddow, ve Alexandra Birch. 2016a. “Improving Neural Machine Translation Models with Monolingual Data”. Proceedings of ACL.

Sennrich, Rico, Barry Haddow, ve Alexandra Birch. 2016b. “Neural Machine Translation of Rare Words with Subword Units”. Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics, 1715-25. https://aclanthology.org/P16-1162/.

Sutskever, Ilya, Oriol Vinyals, ve Quoc V. Le. 2014. “Sequence to Sequence Learning with Neural Networks”. Advances in Neural Information Processing Systems 27.

Vaswani, Ashish, Noam Shazeer, Niki Parmar, vd. 2017. “Attention Is All You Need”. Advances in Neural Information Processing Systems 30.

Vilar, David, Markus Freitag, Colin Cherry, Jiaming Luo, Viresh Ratnakar, ve George Foster. 2023. “Prompting PaLM for Translation: Assessing Strategies and Performance”. Proceedings of ACL.