14  Özetleme

Bölüm durumu: çevrildi. Kaynak metin: İngilizce 14. bölüm. Bu sayfadaki her sayı XL-Sum Türkçe üzerinde ölçüldü (Hasan vd. 2021) — 27.176 eğitim ve 3.397 test BBC Türkçe haberi; her birinin yanında gazetecinin yazdığı tek cümlelik bir özet var. Çıkarımsal (extractive; kaynaktan cümle seçen — burada “çıkarım” inference değil, extraction anlamında) sistemler 3.397’nin tamamında, LLM ise 500 haberlik bir örneklemde puanlandı; hangi kümenin kullanıldığı, her sayının geçtiği yerde belirtiliyor. Bölüm 14.4, hazır tokenizer’la hesaplanmış her Türkçe ROUGE sayısını değiştiren bir tokenizer kusurunu raporluyor. Bu yüzden buradaki ROUGE hazır kütüphaneden alınmadı, elle yazıldı ve rouge-score’un tokenize edebildiği metinlerde bu kütüphanenin sonuçlarıyla on ondalık basamağa kadar karşılaştırılarak doğrulandı. Yazılım: rouge-score 0.1.2, snowballstemmer 3.1.1, NumPy 2.5.2, Python 3.14.5; yerel LLM ollama 0.24.0 üzerinden.

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

• “özet” kelimesinin, birbiriyle bağdaşmayan birkaç görevden hangisini adlandırdığını söyleyebilir ve biri seçim yapana kadar hiçbirini kurmayı reddedebilirsiniz;
• bir özetleme derlemini modellemeden önce betimleyebilir ve bu betimlemeden çıkarımsal yöntemlerin orada çalışıp çalışamayacağını öngörebilirsiniz;
• çıkarımsal baseline’ları (karşılaştırma modelleri) — referansı görerek en iyi cümleyi seçen ve böylece tavanı söyleyen oracle dâhil — kurabilirsiniz;
• ROUGE’un neyi ölçtüğünü, neyi göremediğini ve standart uygulamasının Türkçe için neden bozuk olduğunu açıklayabilirsiniz;
• içsel (intrinsic) ve dışsal (extrinsic) sadakatsizliği ayırt edebilir ve otomatik bir kontrolün bunlardan hangisini yakalayabildiğini söyleyebilirsiniz;
• bir LLM’i hakem olarak kullanırken beraberinde gelen yanlılıkları ölçebilirsiniz;
• bağlam penceresinden uzun belgeleri özetleyebilir ve bu hattın neyi kaybettiğini söyleyebilirsiniz.

14.1 “Şunu özetle” tek bir görev değildir

Modellemeye geçmeden önce bir tanımlama problemi var ve bu problem, özetleme projelerini herhangi bir modelleme kararından daha çok batırıyor. “Özet” kelimesi, en az dört eksende birbirinden ayrılan işleri adlandırıyor ve isteyen kişi çoğunlukla hangisini istediğine karar vermemiş oluyor:

Dört eksen, on altı görev

eksen	bir uç	öteki uç
Okurun amacı	belirtici (indicative) — bunu okumalı mıyım, karar vermeme yardım et	bilgilendirici (informative) — okumanın yerine geç
Kapsam	genel — bu ne hakkında?	sorguya odaklı — bu, X hakkında ne diyor?
Girdi	tek belge	çok belge; kaynaklar arasındaki çelişki asıl zor kısım hâline gelir
Yöntem	çıkarımsal — kaynak cümleleri seç	soyutlayıcı — yeni metin üret

%80 doğru olan belirtici bir özet gayet iyidir; zaten yalnızca belgeyi açıp açmayacağınıza karar veriyordunuz. %80 doğru olan bilgilendirici bir özet ise risk yaratır, çünkü okur onu kontrol etmeden ona göre karar veriyor. Bunlar farklı kabul ölçütleri olan farklı ürünlerdir ve “şunu özetle” ifadesi ikisini de ayırt etmez.

Dolayısıyla bir özetleme projesindeki ilk soru hangi model değil, çıktıyı kim okuyor ve yanlış olursa ne oluyor. Bu bölümdeki her şey — hangi metriğin raporlanacağı dâhil — o cevaptan çıkıyor.

Gereksinim belirsizse karar vermeye zorlayan yararlı bir soru şu: “özet yanlış olsa, okur bunu fark eder mi?” Cevap evetse belirtici bir özet kuruyorsunuz ve hataya tahammülünüz var. Hayırsa bilgilendirici bir özet kuruyorsunuz ve asıl önemli olan lider tablosu değil, Bölüm 14.7.

Neye bakacağız.

• Önce derlem: üzerinde herhangi bir model kurmadan önce onu betimleyeceğiz, çünkü iki saniyede hesaplanan tek bir sayı, cümle seçmenin burada işe yarayıp yaramayacağına karar veriyor.
• Sonra çıkarımsal baseline’lar ve hemen üstlerinde duran tavan.
• Sonra herkesin raporladığı metrik: Türkçede çoğu zaman gözden kaçan bir biçimde bozuk, hangi dilde olursa olsun da özetin doğru olup olmadığını göremiyor.
• Ardından özetleri seçmek yerine kendisi yazan bir model.
• Ona tek parça hâlinde verilemeyecek kadar uzun belgeler.
• Son olarak da doğruluğu ölçmenin biri kaba, biri pahalı iki yolu; bu ikisi sıralamada uyuşuyor, neredeyse başka hiçbir konuda uyuşmuyor.

14.2 Derlemi modellemeden önce betimlemek

Bölüm 13, derlemi denetlemeyi bir suçlama değil bir alışkanlık hâline getirmişti. Burada denetim, doğrudan mühendislik sonucu olan bir soruyu cevaplıyor: çıkarımsal bir sistem bu veride hiç çalışabilir mi?

# XL-Sum Türkçe: BBC Türkçe haberleri; her birinin özetini gazeteci yazmış,
# kalabalık kaynaklı (crowdsourced) değil.
rows = [json.loads(l) for l in open("turkish_test.jsonl")]

train  27,176 articles   median 303 words, 17 sentences   summary 22 words
val     3,397 articles   median 300 words, 17 sentences   summary 22 words
test    3,397 articles   median 296 words, 17 sentences   summary 21 words

compression 14x        83.4% of test summaries are exactly one sentence

Bölüm 13’e hâkim olan sızıntı kontrolü burada temiz çıkıyor:

train articles 27,176, distinct texts 27,173      3 internal duplicates
test article also in train                        0    0.00%
test url also in train                            0
test summary also in train                       24    0.71%
duplicate texts inside test                       0

Sıfır haber sızıntısı. Bunu açıkça söylemekte fayda var, çünkü bu alışkanlık kolayca kuşkuculuk sanılıyor: denetimi, sayılara güvenebilmek için yaparsınız ve bazen denetim size güvenebileceğinizi söyler. Tekrarlanan özetler (%0,71), farklı haberlere iliştirilmiş BBC kalıp metinleri — göz ardı edilecek kadar küçük, anılacak kadar da büyük bir oran.

14.2.1 Özetin ne kadarı haberin içinde?

Mimariyi belirleyen ölçüm bu. Grusky vd. (2018) yöntemiyle her özeti alın ve onun kaynakta birebir geçen en uzun parçalarını açgözlü biçimde bulun:

coverage   0.527    share of summary words found anywhere in the article
density    1.05     sum of squared fragment lengths, over summary length
novel     47.3%     summary words that never appear in the article
verbatim   0/500    summaries that are a copied article sentence

1,05’lik yoğunluk ile 0,527’lik kapsam birlikte, uzunlukla ağırlıklandırılmış ortalama çıkarımsal parçanın \(1{,}05 / 0{,}527 \approx\) iki kelime olduğunu gösteriyor. Her eşleşme tek bir kelime olsaydı yoğunluk tam olarak kapsama eşit olurdu; özet bütün cümlecikleri yeniden kullansaydı yoğunluk onlu sayılara çıkardı. İki kelime, XSum’ın (yine BBC haberlerinden ve tek cümlelik özetlerden oluşan İngilizce bir derlem) rejimi: ara sıra kısa bir isim öbeği korunuyor, ifade biçimi korunmuyor. Karşılaştırma için: özetleme sezgilerinin çoğunun üzerinde oluştuğu derlem olan CNN / DailyMail’in özetleri, haberin kendi cümleciklerini yeniden kullanan madde başlıklarından kuruluyor. Aynı ölçümü onun 400 test haberinde koşturmak karşıtlığı somutlaştırıyor (CNN / DailyMail için yoğunluk bu tabloda raporlanmıyor). Tablodaki üç sütun adı ileriki kısımlardan geliyor; şimdilik anlamları şöyle: lead-3, haberin ilk üç cümlesini özet olarak kullanır; oracle, referansla en iyi eşleşen tek haber cümlesidir — bir tavan, Bölüm 14.3’te açıklanıyor; R-1 ise Bölüm 14.4’teki kelime örtüşmesi skoru ROUGE-1’dir, 0–100 ölçeğinde ve yüksek değer daha çok örtüşme demek.

Aynı kod, iki derlem; her biri kendi dili için doğru olan tokenizer’la, iki tarafta da gövdeleme yapılmamış yüzey biçimleri. Referans uzunluğu sütunu şunun için var: tek cümlelik oracle, o sütun olmadan derlemler arasında karşılaştırılabilir değil

derlem	ref kelime	kapsam	yoğunluk	lead-3 R-1	oracle R-1
CNN / DailyMail (İngilizce)	~56	0,845	—	29,44	40,58
XL-Sum Türkçe	~21	0,527	1,05	14,03	24,89

XL-Sum Türkçe tam ters rejimde ve bölümün tamamı bundan çıkıyor. Bu özetler yeniden yazılmış; Narayan vd. (2018) bu tarza aşırı özetleme (extreme summarization) diyordu: tek cümle, seçilmiş değil kurulmuş.

CNN / DailyMail için yayımlanmış lead-3 değeri 40,34 (See vd. 2017); burada ölçülen 29,44’ten yüksek. O sayı, kendi seçenekleri ve haberlere uyguladığı kendi ön işlemesiyle özgün Perl ROUGE-1.5.5’ten geliyor. Gövdeleme tek başına İngilizce ROUGE-1’i genellikle bir puan kadar oynatır, on bir değil; yani farkın büyük kısmı ön işlemeden geliyor olmalı — her hattın cümle bölücüsünün “ilk üç cümle” dediği şeyin ne olduğu da buna dâhil. Aradaki fark, Bölüm 14.4’te kurulacak argümanın bir önizlemesi: ROUGE tek bir sayı değil, bir sayılar ailesi ve “ROUGE-1” raporlayan iki makale çoğu zaman aynı niceliği raporlamıyor.

14.2.2 Özetin içeriği nereden geliyor?

Özet kopyalanmış değilse, hiç olmazsa haberin başından mı alınmış? Her özeti her haber cümlesiyle unigram F1 üzerinden eşleştirip en iyisini alalım:

best-matching article sentence, 500 test articles
  sentence  1:   79   15.8%  ###############################
  sentence  2:   54   10.8%  #####################
  sentence  3:   50   10.0%  ####################
  sentence  4:   38    7.6%  ###############
  sentence  5:   40    8.0%  ################
  sentence  6:   35    7.0%  ##############
  sentence  7:   30    6.0%  ############
  sentence  8:   30    6.0%  ############
  sentences 9+: 144   28.8%

Lead bias (önemli bilginin haberin başında toplanma eğilimi) gerçek ama zayıf: ilk cümle yalnızca %15,8 oranında kazanıyor ve özetlerin %28,8’i en iyi eşleşmesini 9. cümle ve sonrasında buluyor. Yalnızca girişi okuyan bir sistem, kanıtın çoğunu çöpe atıyor.

14.2.3 O %47,3 üzerine bir uyarı

Yenilik oranı Türkçe yüzünden şişkin ve ne kadar şiştiği ölçülebilir. Ölçümü kelimeleri normalleştirerek tekrar koşturalım:

summary words absent from the article
  exact surface form              47.3%
  after Snowball Turkish stemming 37.5%
  after 5-character prefix        32.8%

Bu oranın on ila on beş puanı yeni içerik değil, çekim:

summary 'bölgede'      <- article 'bölgedeki'
summary 'parlamento'   <- article 'parlamentonun'
summary 'uzmanlara'    <- article 'uzmanlar'
summary 'işgal'        <- article 'işgali'

Aynı kök, farklı ek; yüzey dizgilerini karşılaştıran her şey bunları farklı sayıyor. Bunu aklınızda tutun: burada bir derlem istatistiği, Bölüm 14.4’te ise alanın standart metriğindeki bir kusura dönüşüyor.

14.3 Çıkarımsal baseline’lar ve tavanları

Denetim bu özetlerin kopyalanmaktan çok yeniden kurulduğunu söylüyor; bu, cümle seçmenin ne kadar başarılı olabileceğine dair bir öngörü. Bu akıl yürütmeye güvenmek yerine öngörüyü sayılarla sınayalım.

Çıkarımsal aile, kaynaktan cümle seçer. İfade uyduramaz — her kelime belgenin içindeydi — ve özeti bir cümleden daha kısaya indiremez. Bu garantinin sınırına dikkat: seçilen bir cümle yine de kaynağı yanlış aktarabilir, çünkü onun anlamını belirleyen koşul, olumsuzlama, atıf ya da istisna seçmediğiniz bir cümlede duruyor olabilir. Cümle seçimi, uydurma ifadeyi eler; eksiltmeyle çarpıtmayı değil. Test kümesinin tamamı, 3.397 haber:

system                    R-1     R-2     R-L    words   time
lead-1                  12.75    3.37   10.69     20.0
lead-2                  14.04    3.61   10.94     37.6    0.2s
lead-3                  14.03    3.74   10.44     54.9
random sentence          8.56    1.73    7.30     17.5
TextRank (1 sentence)   13.66    3.27   10.88     30.3   25.4s
oracle sentence         24.89    9.31   20.39     20.1    1.8s

Bu tablodan okunacak üç şey var.

Lead-3 burada güçlü değil. Yerleşik kanaat — “lead-3’ü hep raporlayın, eğitilmiş modelleri yener” — özetleme hakkında değil, CNN / DailyMail hakkında bir olgu; aynı kod orada onu 29,44 R-1 ile puanlıyor. Bu derlemde lead-3 14,03, lead-2 ise 14,04 alıyor. Bunu lead-2’nin onu geçmesi diye okumayın: 3.397 haberde 0,01 ROUGE-1 bir beraberliktir ve bir sütun ötede üçüncü cümlenin bir şey kattığı görünüyor — R-2, 3,61’den 3,74’e çıkıyor. Recall (duyarlılık) tarafında kattığını, on yedi kelimelik ek uzunluk yüzünden precision (kesinlik) tarafında geri veriyor ve ikisi birbirini götürüyor. Lead baseline’ını her zaman raporlayın; güçlü olduğunu asla varsaymayın.

TextRank 25 saniyesini hak etmiyor. TextRank (Mihalcea ve Tarau 2004) her cümleyi bir düğüm sayar, ortak kelimesi olan cümleleri birbirine bağlar ve bu çizge üzerinde PageRank çalıştırır: bir cümle, başka önemli cümlelere benziyorsa önemlidir; en “merkezî” cümle özet olarak alınır. Çizge, Bölüm 11’in belgeler üzerinde kurduğu türden bir nesne; merkezîlik skoru yeni, ama eğitilmiş bir model yok. LexRank (Erkan ve Radev, 2004) aynı fikrin, kenar ağırlığı olarak TF-IDF kosinüs benzerliği kullanan hâli. TextRank 13,66 alıyor; lead-1 ile lead-2 arasında. Gerçek bir yöntem, ama bu derlemde ilk cümleye göre bir ROUGE-1 puanından az kazandırıyor ve bunun için on kelime fazla harcıyor.

Bölümü asıl belirleyen sayı oracle. Oracle, her haber için referansa göre ROUGE-1 F1’i en yüksek olan tek kaynak cümlesini seçiyor — cevabı önce okuduğu için bir sistem değil, bir tavan. Aldığı puan: 24,89.

O satırı nasıl okuyacağınıza dair iki uyarı. Yanındaki 9,31 ve 20,39, R-1’in seçtiği cümlenin R-2 ve R-L puanları; o metrikler için oracle değil — bir R-2 oracle’ı başka bir cümle seçebilir ve R-2’de en az 9,31 alır, çünkü tanımı gereği her haber için R-2’yi en yükseğe çıkaran cümleyi seçer. Ve bu bir tek cümlelik tavan; yani derlemler arasında ancak referans uzunlukları karşılaştırılabilirse karşılaştırılabilir: XL-Sum Türkçe referansları tek cümlede kabaca 21 kelime, CNN / DailyMail’inkiler üç dört cümlede kabaca 56 — bu da ikincisinde tek bir çıkarılmış cümlenin ulaşabileceği recall’u yapısal olarak sınırlıyor.

Bu derlemde tek cümlelik hiçbir çıkarımsal sistem 24,89 ROUGE-1’i aşamaz, çünkü kusursuz tek cümle seçiminin ulaştığı değer bu. Sayıyı her aktardığınızda kapsamını da iliştirin: bu, çıkarımsal özetlemeyi genel olarak değil, bu uzunluk bütçesinde tek cümlelik seçimi sınırlar — çok cümleli bir seçici ya da farklı bir uzunluk bütçesi başka bir oracle’dır ve bu değerin altında da üstünde de kalabilir. Lead-2’nin 14,04’ü ile o 24,89 arasındaki boşluğu tek cümle seçiminin iyileştirme payı diye okumayın: lead-2 iki cümle alıyor, yani ikisi aynı bütçede değil. O okuma için tek cümlelik bir baseline gerekir — lead-1 hemen orada — ya da lead-2’nin yanına koyacağınız iki cümlelik bir oracle.

Bu bir derlem özelliği, 1,8 saniyede hesaplandı ve hiçbir şey eğitmeden önce size soyutlayıcı bir modele başvurmanız gerekip gerekmediğini söylüyor.

Bu oracle’ı elinize geçen her özetleme derleminde koşturun. CNN / DailyMail’in üç cümlelik oracle’ı 50’nin üstünde, buradaki tek cümlelik oracle ise aynı derlemde 40,58 alıyor. Değer yüksekse hangisini hesapladığınızı söyleyin, çünkü ikisi birbirinin yerine geçmez. Her iki durumda da okuma aynı: yüksek bir değer, cümle seçiminin hem uygulanabilir hem ucuz olduğu anlamına gelir ve üretmeye geçmeden önce bu yolu sonuna kadar denemelisiniz. Buradaki gibi düşükse referans özetler yeniden yazılmış metinlerdir ve cümle seçimi yapısal olarak bir tavana takılır. Yalnızca iki satır kod; ama mimariyi o belirliyor.

14.4 ROUGE neyi ölçer, neyi bozar

ROUGE (Lin 2004), aday özet ile referans arasındaki n-gram örtüşmesini sayar. ROUGE-1 unigram örtüşmesi, ROUGE-2 bigram, ROUGE-L en uzun ortak alt dizi — iki metinde de aynı sırayla geçen, araya başka kelimeler girebilen en uzun kelime dizisi. Adı Recall-Oriented Understudy for Gisting Evaluation’ın kısaltması: özgün sürüm recall raporluyordu; bugün her varyant genellikle F1 olarak raporlanıyor.

Üç sayıyı somutlaştırmak için küçük bir örnek. Referans: “bakan bankanın satılacağını yalanladı” (4 kelime). Aday: “bakan bankanın satılacağını söyledi” (4 kelime). Adaydaki dört kelimenin üçü referansta da geçiyor (bir kelime, referansta kaç kez geçiyorsa en fazla o kadar eşleşebilir). Dolayısıyla

\[ P = \tfrac{3}{4} = 0{,}75, \qquad R = \tfrac{3}{4} = 0{,}75, \qquad F_1 = \tfrac{2PR}{P+R} = 0{,}75 . \]

ROUGE-2’de birim kelime çiftidir: adayın üç bigram’ından ikisi (bakan bankanın, bankanın satılacağını) referansta da var, yani \(F_1 = 0{,}67\). En uzun ortak alt dizi bakan bankanın satılacağını, 3 kelime; dolayısıyla burada ROUGE-L, ROUGE-1’e eşit. Makaleler bu değerleri 100 ile çarpar; bu aday “75 ROUGE-1 alıyor” denir. Örneği aklınızda tutun: aday, referansın tam tersini söylüyor ve aşağıda ona döneceğiz.

Yirmi yıldır alanın varsayılan metriği ve haklı bir sebeple ayakta: ucuz, deterministik ve apaçık kötü sistemleri apaçık iyi olanların altına sıralayacak kadar kaliteyle ilişkili.

ROUGE — bir referans özetle n-gram örtüşmesi; F1 olarak raporlanır. Ucuz ve yeniden üretilebilir; özetin doğru olup olmadığına kör ve nadiren kontrol edilen bir tokenizer’a bağımlı. ↩︎

Bu bölümün üç şikâyeti var; sizi ne kadar endişelendirmeleri gerektiğine göre artan sırayla.

14.4.1 Birinci şikâyet: standart uygulama Türkçeyi yok ediyor

Google’ın rouge-score paketi referans uygulama. Hugging Face’in evaluate’i onu sarmalıyor ve ROUGE raporlayan makalelerde bu ikisi yaygın biçimde kullanılıyor. Özgün Perl betiğinin davranışını yeniden üreten tokenizer’ı tek satır:

# rouge_score/tokenize.py
text = text.lower()
text = re.sub(r"[^a-z0-9]+", " ", text)   # <- geri kalan her şey ayraçtır

[a-z0-9] sınıfı ç, ğ, ı, ö, ş, ü ya da İ harflerini içermiyor; bu yüzden olumsuzlanmış [^a-z0-9] sınıfı onlarla eşleşiyor ve her birini ayraç sayıyor. Türkçede bunlar noktalama işareti değil, harf; üstelik sık kullanılan harfler — yalnızca ı bile dilin en sık geçen harfleri arasında. Sonuç:

görüştü        -> ['g', 'r', 't']
çiğ            -> ['i']
köfte          -> ['k', 'fte']
değişiklik     -> ['de', 'i', 'iklik']
şehrinde       -> ['ehrinde']
Türkiye'nin    -> ['t', 'rkiye', 'nin']

Tokenizer'ı kendiniz çalıştırın — Türkçe yazın, nasıl dağıldığını izleyin

viewof rougeTokInput = Inputs.textarea({
  label: "Türkçe metin",
  value: "Cumhurbaşkanı dün İstanbul'da iş insanlarıyla görüştü ve değişiklik sözü verdi.",
  width: 560, rows: 2,
  placeholder: "herhangi bir Türkçe cümle yapıştırın"})

// rouge_score/tokenize.py içindeki iki satır, birebir aktarıldı
rougeTokenize = t => t.toLowerCase().replace(/[^a-z0-9]+/g, " ").trim().split(/\s+/).filter(x => x)

// kelimelere böl ama büyük/küçük harfi koru: rouge-score ham metni kendisi
// küçültüyor ve "İ".toLowerCase() bir "i" artı birleştirici nokta veriyor
properTokenize = t => t.match(/[\p{L}\p{N}]+/gu) ?? []

rougeTokRows = properTokenize(rougeTokInput).map(w => {
  const pieces = rougeTokenize(w);
  return {word: w, pieces: pieces.join(" · ") || "(geriye hiçbir şey kalmadı)",
          n: pieces.length,
          intact: pieces.length === 1 && pieces[0] === w.toLocaleLowerCase("tr")};
})

Inputs.table(rougeTokRows, {
  columns: ["word", "pieces", "n", "intact"],
  header: {word: "kelime", pieces: "rouge-score'un gördüğü", n: "parça",
           intact: "sağlam mı?"},
  format: {intact: v => v ? "evet" : "HAYIR"},
  width: {word: 180, pieces: 240, n: 70, intact: 90},
  rows: 14})

md`${rougeTokRows.length} kelimenin
**${rougeTokRows.filter(r => !r.intact).length} tanesi** tokenizer'dan bozulmadan geçemedi —
%${(rougeTokRows.filter(r => !r.intact).length /
Math.max(rougeTokRows.length, 1) * 100).toFixed(1).replace(".", ",")}; aşağıda
300 referans özet üzerinde ölçülen oran ise %44,4. Her parça hâlâ bir token
olarak sayılıyor ve parçalar başka parçalarla eşleşiyor.`

Bu derlemden 300 referans özet üzerinde ölçüldü:

word tokens, correct Turkish tokenization    6,682
tokens after rouge-score                     9,660   1.45x as many
words left intact                            3,713    55.6%
words split at non-ASCII letters             2,969    44.4%
average pieces per affected word              2.00

Türkçe kelimelerin yüzde kırk dördü tokenizer’dan bozulmadan geçemiyor ve geriye kalan kırıntılar her skoru şişiriyor. g, r, t, i gibi tek harflik parçalar neredeyse her Türkçe metinde karşımıza çıkıyor; aday ile referans bunları tesadüfen paylaşıyor ve örtüşme yükseliyor. Aynı 3.397 özet üzerinde, iki tokenizer ile ROUGE-1:

system                  correct tokenizer    rouge-score default    inflation
lead-1                            12.75                  20.37        +59.8%
lead-2                            14.04                  22.51        +60.3%
lead-3                            14.03                  22.03        +57.0%
random sentence                    8.56                  15.44        +80.4%
TextRank                          13.66                  21.34        +56.2%
oracle sentence                   24.89                  30.28        +21.7%

Hasarı olduğundan büyük göstermek de kendi başına bir hata olurdu, o yüzden kesin konuşalım: sıralama değişmiyor. Sıra, her iki tokenizer’la da lead-2 > lead-3 > TextRank > lead-1.

Yok olan şey karşılaştırılabilirlik. Hazır rouge-score ya da evaluate varsayılanıyla hesaplanmış her Türkçe ROUGE sayısı (yaygın olan da bu), okurlarının sandığı nicelikten kabaca %60 daha büyük. Bu farkın oranı da sistemin referansla gerçek örtüşmesine göre değişiyor: kırıntıların getirdiği mutlak kazanç her sistemde benzer (5,4 ile 8,5 puan arası), dolayısıyla gerçek örtüşmesi en düşük olan rastgele cümle %80, en yüksek olan oracle %22 şişiyor.

Bütün Türkçe ROUGE sayıları böyle değil ve istisnaları bilmek gerekiyor, çünkü çözüm onlarda. XL-Sum’ın kendi yazarları rouge-score’un Unicode’u tanıyan bir tokenization ve dil başına gövdeleyiciler taşıyan bir çatalını yayımladı — Türkçe de içinde — ve yayımladıkları Türkçe sayılar da o araçla üretildi; aynı boşluk Hugging Face kütüphanelerinde 2020’den beri açık bir hata kaydı (issue; önce datasets, şimdi evaluate üzerinde). Yani kusur belgelenmiş; asıl eksik olan şey, bir sayının hangi uygulamadan çıktığını söyleme alışkanlığı. Tokenizer’ı, tıpkı bir rastgelelik tohumu gibi, puanın yanına yazın. Şişmenin miktarı sisteme bağlı; dolayısıyla sıra korunsa bile sistemler arasındaki farklar yanlış.

Bizim kendi tokenizer’ımız da aynı ailedeki bir düzeltmeye ihtiyaç duydu ve bu, Bölüm 11’in gerçek veride bulduğu hatanın aynısı: "İstanbul".lower() bir i artı birleştirici nokta veriyor, \w+ de bunu i ve stanbul diye ayırıyor; "IŞIK".lower() ise ışık yerine işik veriyor. Türkçede küçük harfe çevirme str.lower() değildir. İki yönün de ayrıca ele alınması gerekiyor ve token’ları yazdırmadıkça hata görünmüyor.

Argümanın bizim aritmetiğimizle değil, tokenizer’la ilgili olduğundan emin olmak için bu bölümde kullanılan ROUGE, rouge-score ile karşılaştırılarak doğrulandı. Karşılaştırma, iki tokenizer’ın da aynı sonucu verdiği 300 rastgele salt-ASCII çift üzerinde yapıldı:

max absolute difference vs rouge-score, 900 comparisons:  0.0000000000

Uygulamalar birebir aynı. Türkçedeki bütün fark tokenization’dan geliyor.

14.4.2 Çözüm: tek bir parametre

Yukarıdakilerin hiçbiri ROUGE’u yeniden yazmayı gerektirmiyor; gerektirseydi zaten kötü bir ders olurdu. rouge-score 0.1.2 bir tokenizer= argümanı alıyor — bir dizgiden (string) dizgi listesine giden bir tokenize metodu olan herhangi bir nesne — yani kusuru düzeltmek için kurucuya tek bir argüman vermek yetiyor:

import re
from rouge_score import rouge_scorer

class TurkishTokenizer:
    def tokenize(self, text):
        # önce Türkçe farkındalıklı küçük harf, sonra Unicode harf ve rakamlar
        text = text.replace("I", "ı").replace("İ", "i").lower()
        return re.findall(r"\w+", text, flags=re.UNICODE)

scorer = rouge_scorer.RougeScorer(
    ["rouge1", "rouge2", "rougeLsum"],
    use_stemmer=False,                  # tokenizer= verilince yok sayılır; aşağıya bakın
    tokenizer=TurkishTokenizer())

use_stemmer konusunda da titiz olun, çünkü bir sonraki tuzak o. Varsayılanı zaten False ve True yaptığınızda uyguladığı gövdeleyici Porter, yani İngilizce. Kendi tokenizer= nesnenizi verdiğiniz anda bu bayrak tamamen yok sayılır: use_stemmer yalnızca varsayılan tokenizer’ı ayarlar. Dolayısıyla Türkçe için doğru cevap “kapalı bırakın” değil “değiştirin”; yenisi de sizin tokenize metodunuzun içine girer — her token’a, döndürülmeden önce uygulanan bir Türkçe gövdeleyici. Bu seçimin skoru ne kadar oynattığını bir sonraki alt bölüm gösteriyor. Hugging Face’in evaluate sarmalayıcısı da aynı düzeltmeyi kabul ediyor: rouge metriği bir tokenizer= argümanı (dizgiden token listesine giden bir fonksiyon) alıp alttaki kütüphaneye aktarıyor.

İki seçenek daha: XL-Sum’ın kendi rouge-score çatalı — derlemin 44 dilinin hepsinde yalnızca Unicode noktalama işaretlerini atıyor, on sekizine de Türkçe dâhil gövdeleyici ekliyor; ve alt kelime token’larını bir BPE tokenizer’la puanlayan bir varyant — dil sorusunu tamamen atlıyor, karşılığında kelime parçalarını puanlıyor. Çözüm gibi görünen ama olmayan bir araç da var: sacrerouge pek çok özetleme metriğine ortak bir Python arayüzü sağlıyor, ama ROUGE için özgün Perl ROUGE-1.5.5’i sarmalıyor; onun tokenizer’ı da A–Z, a–z, 0–9 ve kısa çizgi dışındaki her karakteri atıyor — kusur aynı. Bir Türkçe ROUGE sayısı yayımlıyorsanız yanına tokenizer’ın adını yazın. Bir makaledeki o tek cümle, bütün bu araçlardan daha değerli.

14.4.3 İkinci şikâyet: nadiren raporlanan bir normalleştiriciye bağlı

Türkçe çekimli bir dildir. bölgede ile bölgedeki aynı kökten türemiş iki biçim; ROUGE ikisini ilgisiz iki token olarak görüyor. Saymadan önce bir gövdeleyici uygulamak her sayıyı değiştiriyor. Üç farklı normalleştiriciyle ROUGE-1:

system                  surface   5-char prefix   Snowball tr
lead-1                    12.75           17.85         16.13
lead-2                    14.04           19.46         17.67
lead-3                    14.03           19.13         17.48
TextRank                  13.66           18.24         17.11
oracle sentence           24.89           29.30         27.77

“Yüzey biçimi” ile “5 karakterlik ön ek” arasında yaklaşık beş ROUGE-1 puanı (sisteme göre 4,4 ile 5,4 arası) duruyor — ki bu, özetleme makalelerinde baseline’a göre sıkça raporlanan iyileşmelerden daha büyük bir fark. Bir ROUGE sayısı, onu üreten tokenizer ve normalleştirici olmadan yorumlanamaz ve bunlar neredeyse hiç belirtilmiyor. Bu bir Türkçe problemi değil; Türkçede daha kötü.

14.4.4 Üçüncü şikâyet: asıl önemli olan

İlk iki şikâyet yeniden üretilebilirlikle ilgili ve bir uzlaşıyla düzeltilebilir. Üçüncüsü düzeltilemez.

ROUGE, özetin doğru olup olmadığını göremez. Bir referansla kelime örtüşmesi saydığı için, doğru kelimeleri gerçeği tersine çeviren bir sırayla kopyalayan özet yüksek puan alır; farklı kelimeler kullanan doğru bir yeniden ifade ise düşük puan alır. Yukarıdaki örneğe dönelim: kaynak “bakan bankanın satılacağını yalanladı” diyor ve referans da bu cümle:

Örtüşmenin ayırt edemedikleri (skorlar Türkçe tokenizer’la rouge-score üzerinden)

aday	doğruluk	referansa karşı ROUGE-1 F1
bakan bankanın satılacağını yalanladı	doğru	1,00
bakan bankanın satılacağını söyledi	yanlış	0,75 — tek kelime farklı
bakanlık satış ihtimalini dışladı	doğru	0,00 — hiç ortak kelime yok

Yanlış özetle doğru özet tek bir token’la ayrılıyor ve anlamın tamamını o token taşıyor. Kryściński vd. (2019) bu savı uzun uzun kurdu; Fabbri vd. (2021) sonra ölçtü ve ROUGE’un insanların olgusal tutarlılık (consistency) yargısıyla ilişkisini, sistemleri sadakat açısından sıralamak için kullanılamayacak kadar zayıf buldu. Goyal vd. (2022) ise insan etiketleyicilerin, ROUGE’un fine-tuning (ince ayar) ile eğitilmiş modellerin altına sıraladığı GPT-3 özetlerini tercih ettiğini buldu.

Embedding (gömme) tabanlı bir metrik bunun yalnızca bir kısmını düzeltir. BERTScore (Zhang vd. 2020), aynı dizgiyi aramak yerine adaydaki her token’ı, ön eğitimli bir encoder’ın (kodlayıcı) bağlamsal embedding uzayında referanstaki en benzer token’la eşleştirir. Bu, üçüncü satırı kurtarır — satış ile satılacağını, bakanlık ile bakan o uzayda birbirine yakındır — ve çok dilli ya da Türkçe bir encoder kullandığınız sürece bölgede / bölgedeki gibi ek farklarını da kısmen emer. İkinci satırı ise güvenilir biçimde kurtarmaz: söyledi ile yalanladı benzer bağlamlarda geçer, bu yüzden anlamı tersine çevirseler de embedding’leri yakındır. BERTScore da sonuçta gerçeğe değil, bir referansa karşı yapılan bir karşılaştırmadır.

Yani: ROUGE’u raporlayın, çünkü herkesin kullandığı ortak ölçü o ve yokluğu kaçamak gibi görünür. Ama asla yalnızca ondan sonuç çıkarmayın. Yanına ne ekleneceğini Bölüm 14.7 ve Bölüm 14.8 anlatıyor.

14.5 Soyutlayıcı özetleme

Bu derlemde tek cümlelik seçim 24,89’da tavan yapıyor; dolayısıyla geriye kalan payın çoğu yazan modellere düşüyor. Bu iş için iki yaklaşım yerleşti. Konunun tarihçesi iki paragrafı hak ediyor, çünkü bugünkü cevabın neden bu kadar sönük göründüğünü açıklıyor.

Bu görev için eğitilmiş encoder-decoder. Encoder haberi okur, decoder (kod çözücü) özeti yazar ve bütün yapı (haber, özet) çiftleriyle eğitilir. BART, T5, mT5 ve ardılları. 2022 civarına kadar “bir özetleme modeli” bu demekti. Elinizde bir derlem ve sabit bir alan varsa, aynı kalitede hâlâ daha yüksek işlem hacmi sunuyor.

Talimat ayarlı (instruction-tuned) decoder-only. Bölüm 8’deki sonraki-token hedefi, modele her türden metnin nasıl şekillendiğini zaten öğretiyor; bir haber girişinin şekli de buna dâhil. Modeli, haberi sürdürmek yerine talimatı izleyip böyle bir giriş yazmaya yönelten şey ise Bölüm 9’daki eğitim sonrası aşama. Özetleme, bir özetleme derlemi üzerinde ayrıca fine-tuning gerektirmeyen görevlerden biri çıktı: yetenek ön eğitimli modelde örtük olarak zaten vardı ve genel instruction tuning (talimat ayarı; verisinde çok sayıda “şunu özetle” isteği bulunur) onu açığa çıkardı.

Bu yüzden bu bölümün soyutlayıcı sistemi bir eğitim koşusu değil, bir prompt (istem); model, ollama üzerinden yerelde çalışan 9 milyar parametreli qwen3.5:9b. Goyal vd.’nin (2022) bulgusunun arka planı da bu: insan etiketleyiciler, ROUGE’da daha yüksek puan alan fine-tune edilmiş modeller yerine zero-shot (sıfır atışlı; prompt’ta hiç örnek verilmeden üretilmiş) GPT-3 özetlerini tercih ediyordu. Bu bölümde karşılaştırılacak fine-tune edilmiş bir model yok; ama bölüm birazdan o sonucun arkasındaki mekanizmayı küçük ölçekte gösterecek: sadık bir özetin eşleşemeyeceği referanslar.

PROMPT = """Aşağıdaki haber metnini TEK BİR CÜMLEYLE özetle.

Kurallar:
- Yalnızca tek bir cümle yaz, en fazla 30 kelime.
- Sadece metinde geçen bilgileri kullan; metinde olmayan hiçbir şey ekleme.
- Haberin ana olayını ver, ayrıntıları değil.
- Başlık değil, tam bir cümle yaz.
- Sadece özeti yaz, başka hiçbir şey yazma.

Haber metni:
{text}"""

Bu prompt’ta yerini hak eden iki ayrıntı var. Uzunluk sınırının sebebi şu: ROUGE-1 F1 uzun özetleri precision üzerinden cezalandırıyor. Sınırsız bir model üç cümle yazıyor ve hiç de daha az yararlı olmadığı hâlde daha düşük puan alıyor. Bu düşüş özetin yararından değil, metriğin hesabından geliyor; yani sonradan keşfedilecek değil, baştan önlem alınacak yapay bir metrik etkisi. Sınıra yalnızca yaklaşık olarak uyulmasını bekleyin: model kelime değil token üretir ve güvenilir biçimde saymaz. Talimata güvenmek yerine dönen özetlerin uzunluk dağılımına bakın (burada ortalama 23,7 kelimeydi). Yalnızca metinde geçeni kullanma talimatı ise sadakat kısıtının açıkça yazılmış hâli; Bölüm 14.7 bunun işe yarayıp yaramadığını ölçüyor.

14.5.1 Aldığı puan

Altı sistemin hepsi aynı 500 haber üzerinde, Türkçeyi doğru işleyen bir tokenizer ile ROUGE-1:

Aynı 500 haber, yüzey biçimi normalleştiricisi

sistem	R-1	R-2	R-L	kelime
lead-1	13,24	3,36	10,85	20,1
lead-2	14,69	3,79	11,16	38,0
lead-3	14,52	3,95	10,74	55,4
TextRank (1 cümle)	13,92	3,29	10,93	29,8
LLM, zero-shot	19,29	6,00	16,08	23,7
oracle cümle	25,05	9,21	20,29	19,5

Zero-shot LLM, gerçek çıkarımsal sistemlerin en iyisini (lead-2) 4,6 ROUGE-1 puan farkla, en zayıfını (lead-1) 6,05 puan farkla geçiyor ve hâlâ çıkarımsal oracle’ın 5,8 altında duruyor. Bu sonucun iki yarısı da önemli. Burada üretmek açıkça değiyor; öte yandan kusursuz cümle seçiminin tavanı, 9B’lik bir modelin serbestçe yazarak bu referanslara göre aldığı puanın hâlâ üstünde.

Bu, metrikten şüphelenmeniz için zaten yeterli olmalı. Bir okur açısından var olan en iyi tek cümle, bu iş için yazılmış bir özetten açıkça daha iyi değil; daha yüksek puan almasının bir sebebi, referansa bakılarak seçilmiş olması. Bölüm 14.7, bu şüphenin bir ölçümle doğrulandığı yer.

14.6 Uzun belgeler

Yukarıdaki haberler 300 kelime. Gerçek özetleme talepleri 80 sayfalık sözleşmeler, çeyrek dönem raporları ve bir yıllık destek talebi geçmişleri olarak geliyor; o noktada mimari bir model seçimi olmaktan çıkıp bir hat tasarımına dönüşüyor.

Neye mal olduklarına ve neyi koruduklarına göre artan sırayla üç kalıp:

Kırpma (truncate). İlk n token’ı verin, gerisini yok sayın. Lead bias güçlüyse makul bir seçim. Ama bu derlemde özetlerin %28,8’inde en iyi eşleşen cümle 9. cümle ya da sonrası; bu yüzden kırpma kanıtın çoğunu çöpe atıyor. En ucuz seçenek bu ve en sık farkında olmadan seçilen de bu.

Map-reduce. Parçalayın, her parçayı özetleyin, sonra özetleri özetleyin. Maliyet belge uzunluğuyla doğrusal artıyor, iş kusursuz paralelleşiyor ve her framework’te varsayılan yöntem bu. Riske attığı şey, bir parça sınırını aşan her şey: on iki sayfa sonra bir istisnayla kapsamı daraltılan bir sözleşme maddesi, bir tekzip, bir anlatı yayı. Her parça özetleyicisi bir pencere görüyor ve öncesinde ne geldiğine dair pek bir fikri yok. Bu yüzden kendi ayrıntılarından hangisinin bütünde önemli olacağını güvenilir biçimde ayırt edemiyor. İndirgeme (reduce) adımı da yalnızca eşleme (map) adımının tesadüfen tuttuğu şeylerle çalışabiliyor. Kısmi çareler var, ama hepsi ek token harcatıyor: parçaları örtüştürün, her eşleme çağrısına ilerleyen bir özet taşıyın ya da indirgeme adımı belgenin ne hakkında olduğunu söyledikten sonra ikinci bir geçiş koşturun. Hiçbiri, eşleme adımının attığı bir bağımlılığı geri getirmiyor.

İyileştirme (refine) ya da hiyerarşik toplama. İlerleyen bir özeti taşıyın ve her parçayla güncelleyin. Parçalar arası sürekliliği koruyor ama tamamen sıralı, yani paralellik yok. Ayrıca ilerleyen özet, tekrar tekrar yeniden yazıldıkça sapıyor. Geç gelen parçalar erken gelenlerden daha fazla etki ediyor; bu da kırpmanın tam tersi bir başarısızlık.

Üçü yalnızca tek bir şeyde ayrılıyor ve o şey model değil: hattın, yazdığı anda bilmesi mümkün olan şey. §1’de bir madde koyan, §5’te ise o maddeye istisna getiren bir belge alın — her uzun belgede karşımıza çıkan ve hiçbir parça sınırının gözetmediği biçim:

Aynı belge üzerinde üç hat ve her birinin istisnayı yitirdiği yer

Hatlar yalnızca özet yazılırken modelin önünde ne olduğu bakımından ayrılıyor. Kırpma §5’i tümüyle yitiriyor; map-reduce onu okuyor ama yine de §1’e bağlayamıyor; refine ikisini bağlıyor, ama bedelini sapmayla ve sıralı çalışma süresiyle ödüyor.

Bunun arkasındaki aritmetik Bölüm 7’den geliyor. Attention’ın (dikkat mekanizması) maliyeti dizi uzunluğuna göre karesel; dolayısıyla kendi donanımınızda 100 bin token üzerinde tek bir geçiş, 10 bin token üzerindeki bir geçişin on katından fazlasına mal olur. Map-reduce bu karesel maliyetin yerine, sayısı belge uzunluğuyla doğrusal artan küçük karesel geçişler koyuyor; bu yüzden belge uzun bağlamlı bir modelin penceresine sığsa bile hesaplamada daha ucuz olabilir. Token başına ücretlendirilen bir API’de ise hesap tersine döner — map-reduce ara özetlerin parasını da öder — o yüzden hangi faturayı ödediğinize bakın. Her durumda “modelin bir milyon token’lık penceresi var” demek tasarım sorusunu kapatmaz: maliyet bir soru, modelin çok uzun bir girdinin ortasını gerçekten kullanıp kullanmadığı başka bir soru.

Üretimde de geçerliliğini koruyan kural şu: karakter sayısına göre değil, yapıya göre parçalayın. Kısımlar, maddeler, bölümler, konuşmacı sıraları, tarihler. Bir argümanın ortasından çekilen sınır, her biri yerel olarak makul ama birlikte yanlış iki özet üretir; bu başarısızlık da hiçbir otomatik metrikte görünmez — belgeyi bilen bir okur ister.

14.7 Kaynağa sadakat

Bir özet akıcı, konuya uygun, doğru boyutta ve yüksek ROUGE’lu olabilir; yine de kaynağın hiç söylemediği bir şeyi iddia edebilir. Kaynağa sadakat, özetteki her iddianın kaynak tarafından desteklenip desteklenmediğidir ve özetin iyi okunup okunmadığından ya da bir referansla eşleşip eşleşmediğinden farklı bir sorudur.

faithfulness (kaynağa sadakat) — bir özetin yalnızca kaynağının desteklediği şeyleri iddia edip etmediği. Akıcılıktan da referans örtüşmesinden de bağımsızdır. Çıktının karar verirken güvenle kullanılıp kullanılamayacağını belirleyen özellik de budur. ↩︎

Maynez vd. (2020) başarısızlığı ikiye ayırdı. Bu ayrım pratikte işe yarıyor, çünkü iki türün çözümü farklı:

• İçsel (intrinsic) — özet, kaynakta bulunan bir şeyi yanlış aktarıyor. Özne ile nesne yer değiştirmiş, bir olumsuzluk düşmüş, iki varlık birbirine karışmış, bir sayı yanlış şeye iliştirilmiş. Kaynakla karşılaştırarak saptanabilir ve genellikle bir model hatası.
• Dışsal (extrinsic) — özet, kaynakta hiç olmayan bir şey ekliyor. Bazen doğru (model maliye bakanının kim olduğunu biliyor), bazen uydurma. Desteklenmemiş olduğu saptanabilir; yanlış da olup olmadığına karar vermek içinse belgeye değil, dünyaya bakmak gerekir.

Doğru olduğu ortaya çıkan dışsal bir ekleme bile bilgilendirici bir özette kusurdur, çünkü okur hangi cümlelerin kaynağa dayandığını, hangilerinin model tarafından eklendiğini ayırt edemez.

14.7.1 İnsansız saymak

Kaba bir vekil ölçü sizi epey ileri götürüyor: özette geçen ve kaynakta hiç geçmeyen bir sayı ya da özel isim, desteklenmemiş bir iddiadır. İçsel hataları tamamen kaçırıyor — yer değiştirmiş bir özne yalnızca kaynak kelimelerini kullanır — ama dışsal olanları yakalıyor ve ürettiğiniz her özette koşturmanın maliyeti sıfır.

Kaba vekil ölçülerin bir kontrole ihtiyacı vardır; yoksa ne söylerlerse ona inanırsınız. Buradaki kontrol hiçbir ek maliyet getirmiyor: lead-2 haberden birebir kopyalanıyor, dolayısıyla işaretlenme oranı vekil ölçünün yanlış pozitif oranıdır ve sıfır olmak zorundadır. Aşağıdaki çıktıda nums özetlerdeki sayıları, propers özel isimleri, yanlarındaki unsupported sütunları bunlardan kaynakta bulunmayanları, summaries flagged ise en az bir işaret alan özetlerin sayısını ve oranını veriyor.

system                nums  unsupported   propers  unsupported   summaries flagged
lead-1  (control)      100            0       521            0       0    ( 0.0%)
lead-2  (control)      173            0       809            0       0    ( 0.0%)

İkisinde de sıfır — ki bu, yanlış pozitif oranını ortadan kaldırmıyor, sınırlıyor. 150’de sıfırın %95 üst sınırı %2,5’tir ve modelin oranı %3,3 çıktığında bu önemli hâle gelir: kontrolün çözünürlüğü, o %3,3’ün ne kadarının gerçek olduğunu söylemeye yetmiyor. Sonucu şöyle okuyun: vekil ölçü, kopyalanmış metinde, birazdan göreceğimiz referans oranının yakınında bile işaret vermiyor. Bu kısmın ihtiyaç duyduğu karşılaştırma bu ve sonraki tabloyu anlamlı kılan da bu. Buraya üç denemede gelindi; iki başarısız deneme ?sec-ozetleme-vekil-hatalari’de, çünkü düzeltmenin kendisinden daha öğreticiler.

NotBu vekil ölçünün yanlış olan iki sürümü

Birinci deneme özetteki büyük harfle başlayan kelimeleri kaynağın büyük harfle başlayan kelimeleriyle karşılaştırıyordu — ve “Ancak” ya da “Bu” gibi kelimeleri özel isim saymamak için ikisinde de cümle başındakileri atlıyordu. Böylece haberde yalnızca cümle başında geçen bir isim kaynakta yokmuş gibi kaydedildi. Sonuç: BBC gazetecilerinin kendi özetlerinin %56’sı sadakatsiz çıktı; bu, sizi heyecanlandırması değil durdurması gereken türden bir sayı. Kopyalanmış metin kontrolü de bu sürümde sıfır dönmedi. (Doğru sürümün referanslar için bulduğu %57,3’ün bu sayıya çok yakın çıkması bir şeyi değiştirmiyor: hatalı bir ölçüm doğru sayıyı ancak tesadüfen verir ve kontrol sıfır dönmeden hangisinin tesadüf olduğunu bilemezsiniz.)

İkinci deneme bunu kaynağın tamamına bakarak düzeltti, ama özetin token kümesini str.split() ile, kaynağınkini \w+ ile kuruyordu. Böylece özetteki İtalya'ya, kaynaktaki italya ile hiç eşleşmedi; neo-İslamcı hiç islamcı ile eşleşmedi ve kaynaktaki Komisyonu,hemşirenin gibi bir dizgi hatası hiçbir şeyle eşleşmedi. Sadakatsiz olması imkânsız olan kopyalanmış metin %8 oranında sadakatsiz çıktı.

İki hatanın da şekli aynı: karşılaştırmanın iki tarafı farklı tokenize edildi. Bu, Bölüm 14.4’ün rouge-score içinde bulduğu kusurun aynısı ve Bölüm 13’ün bir LLM bilgi çıkarma hattında bulduğunun aynısı. Bir metrik metni metinle karşılaştırıyorsa, kontrol edilecek ilk şey iki tarafın da aynı tokenizer’dan geçtiğidir; en ucuz kontrol yolu da cevabını zaten bildiğiniz bir kontrol koşusudur.

14.7.2 Vekil ölçünün bulduğu

İki kontrol de sıfırdayken bir işaret artık bir şey ifade ediyor. İşte aynı vekil ölçünün, aynı 150 haber üzerinde modelin özetlerinde ve insan referanslarında bulduğu:

Bu bölümdeki en şaşırtıcı sayı bir modelle ilgili değil.

system                nums  unsupported   propers  unsupported   summaries flagged
lead-1  (control)      100            0       521            0       0    ( 0.0%)
lead-2  (control)      173            0       809            0       0    ( 0.0%)
LLM (qwen3.5:9b)        61            0       494            3       5    ( 3.3%)
reference (human)       74           33       644          173      86    (57.3%)

Referans özetler, desteklenmemiş içeriği modelin kabaca on yedi katı oranında iddia ediyor — aynı 150 haberde %3,3’e karşı %57,3.

\(n = 150\)’de bunlar 86 ve 5 özet demek. %95 Wilson aralıkları [49,3; 65,0] ve [1,4; 7,6]: geniş bir farkla örtüşmüyorlar, iddia da bu. Nokta kestirimleri iddia değil, aralarındaki oran da değil: iki küçük oranın oranı, aktarabileceğiniz en oynak sayıdır.

LLM satırının sağdaki iki sütunu birbiriyle tutmuyor ve doğru olan, bunu yuvarlayıp geçmek yerine söylemek: üç desteklenmemiş özel isimden beş işaretlenmiş özet çıkamaz. Bu kısmın geri kalanında kullanılan sayı beş — aşağıdaki hakem karşılaştırmasının %3,3 diye raporladığı sayı o ve orada raporlanan \(\kappa = 0{,}08\) aritmetik olarak yalnızca beş işaret ve bir ortak maddeyle mümkün. (%90,7’lik uyum tek başına bunu belirleyemez: ortak maddesi olmayan üç işaret de 150’de 136 uyuşan karar verir, ama \(\kappa\) sıfırın biraz altında kalır.) Bu tablodaki öğe başına sayımları yeniden sayılması gereken değerler olarak görün; aktarılacak sayı özet başına orandır.

Bu bir ölçüm hatası değil — kontroller temiz — ve BBC gazetecilerinin haber uydurması da değil. Bu, derlemin nasıl kurulduğuyla ilgili.

XL-Sum’ın “özet”i, haberin yanında yer alan koyu giriş satırı; konuyu önceden bilmeyen bir okuru yönlendirmek için yazılmış. Dolayısıyla gövdenin verili saydığı arka planı sağlıyor: bakanın adı, referandumun tarihi, haberin yalnızca ima ettiği bir rapordan gelen rakam. Maynez vd. (2020) aynı olguyu, aynı yöntemle kurulmuş XSum için belgelemişti: etiketleyicileri XSum’ın kendi referans özetlerinin %73,1’inde dışsal içerik bulmuştu. Burada Türkçede yeniden karşımıza çıkıyor.

%57,3’ün bir kısmı, vekil ölçünün bir kısaltma uyuşmazlığını saymasından geliyor: referans Avrupa Birliği yazarken haber AB yazıyor. O yüzden bu oranı bir üst sınır olarak alın. Yön konusunda ise kuşku yok.

Bundan üç sonuç çıkıyor; bu kısmın bir dipnottan ibaret olmamasının sebebi de onlar.

1. Bu referanslarla hesaplanan ROUGE, sadakatsizliği ödüllendiriyor. Referansın desteklenmemiş arka planını yeniden üreten model daha yüksek puan alıyor. Bunu reddeden model daha düşük alıyor.
2. Prompt’umuz modele yalnızca metindekini kullanmasını söyledi ve model uydu — referansın %57,3’üne karşı %3,3. Metrik onu, istediğimiz şeyi yaptığı için cezalandırıyor.
3. Bu derlem üzerinde fine-tuning, bir modele kaynakta olmayan iddialar üretmeyi öğretirdi; çünkü eğitim sinyali %57,3 oranında desteklenmemiş iddia içeriyor. Bu bir öngörü; bu bölüm onu ölçmedi. Bu, bölümdeki en güçlü tek argüman: kazınmış bir özetleme derlemi üzerinde, önce denetlemeden eğitim yapmayın.

Bu aynı zamanda “peki neden 27.176 eğitim çifti üzerinde mT5’i fine-tune etmiyoruz?” sorusunun da cevabı. Edebilirsiniz; model ROUGE’da daha iyi puan alacaktır ve öğrendiği şeylerin bir kısmı, girdisinde bulunmayan şeyleri iddia etmek olacaktır. Metrik bunu size söylemeyecek. Bölüm 5, bu problem sınıfını bir modele ulaşmadan önce fark etmeye ayrılmış bölüm. Öngörüyü sınamak için eğitim bile gerekmiyor: XL-Sum yazarları, Türkçeyi de kapsayan ve bu derlem üzerinde fine-tune edilmiş çok dilli bir mT5 checkpoint’ini (kaydedilmiş model ağırlıkları) Hugging Face’te csebuetnlp/mT5_multilingual_XLSum adıyla yayımladı. Model kartında Türkçe için 32,93 ROUGE-1 raporlanıyor; ama bu sayı yazarların Türkçe gövdeleyicili kendi rouge-score çatalıyla hesaplandı, dolayısıyla buradaki yüzey biçimi sayılarıyla karşılaştırılamaz. Aynı vekil ölçüyü o modelin özetlerinde koşturmak, üçüncü sonucu doğrudan sınar; bu bölüm bunu yapmadı.

14.7.3 Vekil ölçü ile hakem arasında

Dizgi eşleştiren bir vekil ölçü ile tam bir LLM hakemi arasında, makalelerde ikisiyle de karşılaşacağınız iki öğrenilmiş kontrol ailesi var. Bu bölüm onları koşturmadı, ama ne yaptıklarını bilmeniz gerekiyor.

• Gerektirme (entailment, NLI) kontrolleri. Doğal dil çıkarımı (natural language inference, NLI) modeli, bir öncül ile bir hipotezi okuyup öncülün hipotezi gerektirip gerektirmediğini, onunla çelişip çelişmediğini ya da ikisinin de olmadığını söyleyen bir sınıflandırıcıdır. Kaynağı öncül, her özet cümlesini hipotez yapın; kaynağın gerektirmediği cümle işaretlenir. SummaC (Laban vd., 2022) ve Bölüm 14.12’deki AlignScore böyle çalışır.
• Soru-cevap kontrolleri. QAGS (Wang vd., 2020) özetten sorular üretir, her soruyu iki kez cevaplar — bir kez özetten, bir kez kaynaktan — ve iki cevabı birbirini tutmayan soruları sayar.

İkisi de vekil ölçünün göremediği bazı içsel hataları yakalayabilir: düşmüş bir olumsuzluk gerektirme etiketini değiştirir, yer değiştirmiş bir özne de “bankayı kim sattı?” sorusunun cevabını değiştirir. İkisi de bir LLM hakeminden çok daha ucuza koşar. Ama ikisi de içlerindeki modelin hatalarını devralır ve standart checkpoint’ler İngilizce veriyle eğitilmiştir; Türkçede çok dilli bir model ve güvenmeden önce aynı kopyalanmış metin kontrolü gerekir.

14.8 LLM’in hakemliği ve size neye mal olduğu

ROUGE sadakati göremiyor; elle denetim, hiçbir örtüşme metriğinin yakalamayacağı başarısızlıkları yakalayabiliyor ama ölçeklenmiyor. Ortadaki seçenek bir modele sormak. Bu artık pratikte varsayılan yöntem (Liu vd. 2023) ve beraberinde, yok sayılmak yerine ölçülmesi gereken yanlılıklar getiriyor.

Burada kullanılan tasarım üç kurala uyuyor; çünkü herhangi birini çiğnemek sonucu sessizce geçersiz kılıyor:

1. Hakem, üretenden farklı bir model. gemma3:27b, qwen3.5:9b’yi yargılıyor. Modeller kendi çıktılarını tercih ediyor ve bir modelin kendi çıktısına verdiği skor bir ölçüm değildir.
2. Hakem, tek bir dar soruyu belirli bir şemaya göre cevaplıyor. “Bu özete 1-5 arası puan ver” değil — bu özetteki her iddia kaynak tarafından destekleniyor mu? — iki değerli bir enum (izin verilen değerlerin açık listesi) ile. Tek eksenli bir ölçüt yeniden üretilebilir; beş puanlık genel kalite skoru ise anlık bir izlenimden ibarettir. Bu bölümün size vermesi gerekip de vermediği bir şey var: hakemin prompt’unun tamamı, Bölüm 14.5 üretim prompt’unu bastığı gibi. Yargılanmış bir oran, bir modelin olduğu kadar bir prompt’un da özelliğidir ve %33,3 o prompt olmadan yeniden üretilemez.
3. İnsan referansı da aynı koşullarda yargılanıyor. Hakemin skorlarının ne anlama geldiğini bilmenin tek yolu bu — ve Bölüm 14.7’nin gösterdiği gibi, referans kendiliğinden tavan değil.

14.8.1 Hakemin söyledikleri

150 haber; hem modelin özeti hem insan referansı aynı koşullarda yargılandı:

En az bir desteklenmemiş iddia içeren özetlerin oranı, aynı 150 haber

yargılayan	LLM (qwen3.5:9b)	referans (insan)
otomatik vekil ölçü	%3,3	%57,3
gemma3:27b hakem	%7,3	%33,3

Hakem yönü doğruluyor: insan referansları, modelin özetlerinin dört ila beş katı sıklıkta desteklenmemiş bulunuyor. Biri kaba biri pahalı iki yöntem, düzey konusunda anlaşamıyor, sıralama konusunda anlaşıyor.

14.8.2 İki sayıdan da değerli olan kısım

İki yöntemin sıralamada anlaşması rahatlatıcı bir sonuç ve işin kolay yarısı. Rahatsız edici yarısı, aynı özetler hakkında anlaşıp anlaşmadıkları. Aşağıda proxy flags vekil ölçünün, judge flags hakemin işaretlediği özet sayısı; both ikisinin birlikte işaretledikleri, verdicts agreeing ise iki yöntemin aynı kararı verdiği özetlerin oranı:

                       proxy flags   judge flags   both   verdicts agreeing
LLM (qwen3.5:9b)                 5            11      1        90.7%
reference (human)               86            50     35        56.0%

Modelin özetlerinde iki yöntem 5 ve 11 maddeyi işaretliyor ve tam olarak birinde örtüşüyorlar. O %90,7’lik uyum neredeyse tamamen temiz özetler üzerindeki uyum; iki yöntemden herhangi biri bir sorun gördüğünde neredeyse hiç kesişmiyorlar.

Ham uyumun burada yanlış istatistik olmasının sebebi de bu ve Bölüm 5 bunu zaten söylemişti. Uyumu şansa göre düzeltin. Modelin özetlerinde iki yöntem \(\kappa = 0{,}08\)’e ulaşıyor; ham olarak çok daha az uyuştukları referanslarda ise \(\kappa = 0{,}16\). İkisi de Bölüm 5’in çok zayıf dediği bantta. %90,7 ise “temiz”in yüksek taban oranının düzeltilmemiş bir sayıya yansımasından ibaret. Özetlerin %90’ında uyuşan ve \(\kappa = 0{,}08\) olan iki yöntem birbirini doğrulamış değildir; ikisi de çoğu zaman hayır demiştir.

Kuramın öngördüğü şey bu ve unutulması kolay:

• Vekil ölçü yalnızca dışsal hataları görebiliyor — kaynakta olmayan bir isim ya da sayı. İçsel olanlara yapısal olarak kör, çünkü yer değiştirmiş bir özne ya da düşmüş bir olumsuzluk yalnızca kaynak kelimelerini kullanıyor.
• Hakem ikisini de görüyor ve kendi hatalarını ekliyor: vekil ölçünün %3,3 gördüğü yerde modeli %7,3 ile işaretliyor ve vekil ölçünün işaretlediği referansları aklıyor, çünkü AB’yi doğru biçimde Avrupa Birliği’ne çözüyor, vekil ölçü ise çözemiyor.

Yani: güvenilir kısım sıralama, oran değil. İki ölçümü de, aralarındaki uyuşmazlığı da raporlayın. Mutlak bir sayıya ihtiyacınız varsa — “yayına aldıklarımızın ne kadarı yanlış?” — bu ikisinin hiçbiri onu size vermiyor. O sayı rastgele bir örneklemi okumaktan gelir; Bölüm 5’in disiplini ve Bölüm 14.13’ün 6. adımı budur.

14.8.3 Hakemin maliyeti

Demek ki hakem yerini hak ediyor. Geriye kalan tek soru, onu ne kadar kullanmayı göze alabileceğiniz. Cevabı saat veriyor:

300 judgements with gemma3:27b     20,482s     68.3s each

150 haber-özet çiftini iki kez yargılamak neredeyse altı saat; buna karşılık 9B’lik modelle 500 özet üretmek 20 dakika. Bu kurulumda yargılamak üretmekten çok daha pahalı. Girdi uzunluğu farkı açıklamıyor: üretici de haberin tamamını okuyor, hakem yalnızca üstüne kısa bir özet ekliyor. Yargı başına 68,3 saniyeye karşı özet başına 2,4 saniyelik, yaklaşık yirmi sekiz katlık farkın yalnızca bir kısmını hakemin üç kat büyük bir model olması (27B’ye karşı 9B) açıklıyor; kalanı büyük olasılıkla hakemin her yargıda ürettiği çıktının uzunluğundan ve düşünme ayarından geliyor — bu bölüm o ayrıştırmayı raporlamıyor, siz kendi kurulumunuzda ölçün. Üstüne, hakemi her sistem için ayrıca koşturuyorsunuz. Bunu sonradan akla gelen bir şey olarak değil, bir değerlendirme maliyeti olarak bütçeleyin ve her şeyi yargılamak yerine örnekleyin.

14.8.4 Yanlılıklar ve bu bölümün hangilerini ölçtüğü

Yukarıdaki tasarım kuralları, LLM hakemlerinin bilinen ve tekrarlanabilir başarısızlık biçimleri olduğu için var. Bu bölümün kurulumu bunlardan ikisini yapısı gereği önlüyor, üçüncüsünü ölçmüyor:

Hakem yanlılıkları ve bu kurulumun onlara karşı yaptığı

yanlılık	nedir	burada nasıl ele alındı
Kendini kayırma	model kendi çıktısına daha yüksek puan verir	model düzeyinde önlendi: gemma3:27b, qwen3.5:9b’yi yargılıyor; üslup düzeyindeki biçimi aşağıda
Konum	ikili karşılaştırmada önce sunulan seçenek daha sık kazanır (Zheng vd. 2023)	geçerli değil: bu hakem tek seferde tek özet puanlıyor, ikili sıralama yok
Uzunluk	daha uzun ve daha akıcı cevaplar, içerikten bağımsız olarak yüksek puan alır	burada ölçülmedi — prompt’taki uzunluk sınırı modelin özetlerini referans uzunluğuna yakın tutuyor (21’e karşı 23,7 kelime); bu maruziyeti azaltıyor ama sınamıyor

Tablonun dışında kalan bir risk daha var: kendini kayırma yalnızca aynı model düzeyinde işlemeyebilir; LLM hakemleri, kendilerininki olmasa da LLM üslubunda yazılmış metinlere daha hoşgörülü davranabilir. Buradaki karşılaştırma tam da bir LLM özeti ile bir insan özeti arasında olduğu için bu yanlılık sonucu modelin lehine itebilir ve bu bölüm onu ölçmedi. Yönü destekleyen bağımsız kanıt, hakemden hiç etkilenmeyen dizgi eşleştirici vekil ölçünün de aynı sıralamayı vermesi; hakemin kendi isabeti ise ancak elle etiketlenmiş bir örneklemle ölçülebilir (Bölüm 14.13, 6. ve 7. adım).

Üçüncüsünü geçiştirmek yerine açıkça söyleyelim: ikili bir hakeme geçerseniz konum yanlılığı, ikili ya da 1–5 ölçütlü bir hakeme geçerseniz uzunluk yanlılığı devreye girer. Zheng vd. (2023) çalışmasındaki sıra değiştirme testi (iki sırayı da sunun, kararın kaç kez tersine döndüğünü sayın), bu sonuçların hiçbirine inanmadan önce koşturulacak ölçümdür. Bölüm 22 bu testi ve uzunluk yanlılığı için bir dolgu testini, Türkçe haber özetleri üzerinde bu iki modelle koşturuyor.

14.9 Üretimde özetleme

Mühendislik soruları, her üretken özellikte karşımıza çıkan aynı üç soru. Özetleme bunların ikisine alışılmadık derecede net cevaplar veriyor.

Önbellekleme neredeyse maliyetsiz bir tasarruf. Deterministik kod çözmede (decoding) bir özet, pratikte (belge, prompt, model, kod çözme parametreleri) dörtlüsünün neredeyse saf bir fonksiyonudur. (“Neredeyse”, çünkü sıcaklık 0’da bile GPU’da toplu işleme ve kayan nokta işlemlerinin sırası çıktıyı ara sıra değiştirebilir.) Örnekleme (sampling) kullanıyorsanız değildir, ama bir örneği kabul ettikten sonra bir başkası için para ödemenin sebebi yok. Önbellek anahtarı olarak bu dördünün hash’ini kullanın; böylece aynı belge asla iki kez özetlenmez. Belgeler yazıldıklarından çok daha sık yeniden okunur, dolayısıyla isabet oranları yüksektir. Üstelik çoğu LLM özelliğinin aksine, önbelleği boşa çıkaracak bir kişiselleştirme de yok. Prompt’un sürümünü de anahtara ekleyin; yoksa prompt değiştiğinde önbellek sonsuza dek sessizce bayat çıktı sunar.

Maliyete çıktı değil girdi hâkim. Burada özetlenen 500 haber üzerinde ölçüldü: haber başına 890 prompt token’ına karşılık 53 üretilen token, yani token olarak neredeyse 17’ye 1. Üstelik bunlar 300 kelimelik haberler; özetletmek isteyeceğiniz metinler arasında en kısalardan. Bunu maliyet oranı diye aktarmadan önce kendi fiyat listenizle paraya çevirin: çıktı token’ları genellikle girdi token’larının üç ila beş katı fiyattan faturalanır. Bu tahmini çarpanlarla, token’daki 16,8’e 1’lik oran parada 3,4’e 1 ile 5,6’ya 1 arasına düşer. Buradaki sonuç bu dönüşümden sonra da geçerli; okuduğundan fazlasını üreten bir görevde geçerli olmazdı. Map-reduce ile özetlenen uzun belgelerde oran daha da kötüleşiyor, çünkü ara özetler bir kez daha okunuyor.

Buradaki hesap, Bölüm 31’deki hesabın aynısı: parasını ödediğiniz şey okumak; dolayısıyla asıl etkili olan, ne kadar çıktı istediğiniz değil ne kadar metin gönderdiğinizdir. Kalıp metni kırpmak — başlıklar, gezinme menüleri, sorumluluk reddi, imza blokları — genellikle herhangi bir model değişikliğinden daha büyük tasarruf sağlar.

Döngüdeki insan bir yedek çözüm değil, bir tasarım kararı. Bölüm 14.1’deki soruya dönün: özet yanlış olursa ne oluyor? Maliyet sırasına göre üç biçim:

Kim kontrol ediyor ve kontrol neye mal oluyor

kalıp	ne zaman	neye mal olur
Kaynağı yanında göster	okur tek bakışta doğrulayabiliyorsa	arayüz işi, madde başına maliyet yok
Her iddiayı kendi cümlesine bağla	iddialar tek tek kontrol edilebiliyorsa	Bölüm 13’teki bilgi çıkarma, artı hizalama
Teslimden önce insan incelemesi	yanlış bir özete göre hareket etmek pahalıysa	madde başına bir kişi

İkinci satırın pratik biçimi bir çıktı şeması: modelden her iddiayı, dayandığı kaynak cümlenin numarasıyla birlikte döndürmesini istersiniz; böylece hizalama kontrolü bir dizgi karşılaştırmasına iner. Modeli böyle bir şemaya uymaya zorlamanın yolları Bölüm 18’de.

Kaynağı özetin yanında göstermek, çoğu özetleme ürününde en yüksek getirili özelliktir ve bir model iyileştirmesi bile değildir. Doğru olmak zorunda olan bilgilendirici bir özeti, yalnızca yararlı olması yeten belirtici bir özete dönüştürür.

14.10 Sezgi kontrolleri

Her birini açmadan önce cevaplayın. Altısı da bu bölümün bir argümanla değil bir ölçümle karara bağladığı sorular.

Not1. Bir satıcı Türkçe haberlerde 41 ROUGE-1 raporluyor. Etkilendiniz mi?

Neredeyse kesinlikle belirtmedikleri üç şeyi öğrenmeden etkilenemezsiniz: tokenizer, normalleştirici ve referans kümesi.

Bu derlemde aynı tahminler Türkçe için doğru bir tokenizer’la 14,03, rouge-score’un varsayılanıyla 22,03 alıyor; o varsayılan ç, ğ, ı, ö, ş ve ü’yü ayraç saydığı için Türkçe kelimelerin %44,4’ünü parçalara bölüyor. Gövdeleme ya da ön ek kırpma skoru üç ila beş puan daha oynatıyor. Yani “41” güçlü bir sistem de olabilir, cömertçe ölçülmüş zayıf bir sistem de; hangisi olduğunu sayı tek başına söyleyemez.

Sayıyı hangi tokenizer’ın ürettiğini sorun. Cevap “standart olan” ise, o sayı doğru hesaplanmış hiçbir şeyle karşılaştırılabilir değil.

Not2. Hiçbir şey eğitmeden önce, cümle seçiminin çalışıp çalışamayacağını nasıl bilirsiniz?

Oracle’ı hesaplayın. Her belge için referansla karşılaştırıldığında en yüksek ROUGE’u veren tek cümleyi seçin, sonra bu skorların ortalamasını alın. Bu, kusursuz tek cümle seçiminin ulaştığı değerdir; dolayısıyla tek cümlelik hiçbir çıkarımsal sistem onu geçemez. “Tek cümlelik” ifadesinin altını çizin, çünkü çok cümleli bir seçicinin sınırı başka bir oracle’dır.

Burada oracle 24,89; onunla karşılaştırılacak tek cümlelik baseline olan lead-1 ise 12,75. İkisi de 3.397 haberlik test kümesinin tamamında ölçüldü. Yani daha iyi tek cümle seçimi için kabaca on iki puanlık alan kalıyor (lead-2’nin 14,04’ü iki cümle kullanıyor, dolayısıyla doğru karşılaştırma o değil). 24,89’un ötesine geçmek ise ya daha çok cümle ya da özeti yazmayı gerektiriyor. (İki sayıyı aynı örneklemden aktarın: bu bölümün 500 haberlik alt örnekleminde aynı iki sayı 25,05 ve 13,24. Her örneklemden birer sayı alırsanız olmayan farklar icat etmiş olursunuz.) CNN / DailyMail’de aynı ölçüm 40,58 veriyor; çıkarımsal sistemlerin orada on yıl boyunca saygın kalmasının sebebi de bu.

Hesabı iki satır kod tutuyor ve daha tek bir GPU saati harcamadan mimarinizi belirliyor.

Not3. Sadakat metriğiniz, insan gazetecilerin yazdığı özetlerin %56’sında halüsinasyon olduğunu söylüyor. Ne yaparsınız?

Yayımlamazsınız. Bu kadar şaşırtıcı bir sayının bir keşif olmasındansa ölçümünüzdeki bir hata olması çok daha olası; öğrenmenin yolu da cevabını zaten bildiğiniz bir kontrol koşturmaktır.

Buradaki kontrolün maliyeti yok: lead-2 haberden birebir kopyalanıyor, dolayısıyla kaynakta olmayan hiçbir ifade getirmiyor. Sözcüksel bir sadakat vekilinin lead-2’de işaretlediği her şey bu yüzden yanlış pozitiftir. (Lead-2, bazı şeyleri atlayarak okuru yine de yanıltabilir — ama bu vekil ölçü böyle bir şeyi saptama iddiasında değil; onu bu vekil için temiz bir kontrol yapan da bu.) Bu kontrolü koşturmak, vekil ölçünün ardışık iki sürümünde iki hata ortaya çıkardı — ikisi de aynı hata: karşılaştırmanın iki tarafını farklı tokenize etmek.

Referans özetlerin oranı ancak kontrol tam olarak sıfır döndükten sonra raporlanabilir hâle geldi. Oran yine de yüksekti (%57,3) ve bunun gerçek bir sebebi vardı: derlemin özetleri, haber gövdesinde bulunmayan arka plan bilgisini veren BBC giriş satırları. Bu sayının ilk sürümün %56’sına çok yakın çıkması dersi değiştirmiyor: sayı sonunda doğru çıksa bile, kontrol sıfır dönmeden ona güvenemezdiniz.

Not4. Modeliniz ROUGE’da fine-tune edilmiş baseline’ın altında kalıyor. Daha mı kötü?

Belki tam tersi. Bu derlemde referans özetler, nasıl ölçtüğünüze bağlı olarak vakaların %33–57’sinde desteklenmemiş içerik iddia ediyor; dolayısıyla bu referanslarla hesaplanan ROUGE, aynı içeriği yeniden üreten modeli ödüllendiriyor. Prompt’umuz modele yalnızca metindekini kullanmasını söyledi; model talimata uydu, metrik de onu bu uyum için cezalandırdı.

Goyal vd. (2022) aynı örüntüyü bir insan çalışmasında buldu — insanlar, ROUGE’un fine-tune edilmiş modellerin altına sıraladığı zero-shot GPT-3 özetlerini tercih ediyordu. ROUGE ile bir sadakat ölçümü çeliştiğinde, referans kalitenin tanımı değil, kalite hakkında bir hipotezdir.

Not5. 80 sayfalık sözleşmeleri özetlemeniz gerekiyor. Map-reduce nerede kaybeder?

Parça sınırlarında ve görünmez biçimde. Her parça özetleyicisi yalnızca kendi penceresini görüyor, metnin geri kalanından habersiz. Bu yüzden kendi ayrıntılarından hangisinin bütün içinde önemli olacağını bilemiyor; indirgeme adımı da yalnızca elenmeden kalanlarla çalışabiliyor. On iki sayfa sonra kapsamı daraltılan bir madde, yerel olarak doğru ama birlikte yanlış iki özet üretiyor.

Hiçbir otomatik metrik bunu yakalamıyor — iki özet de akıcı, ikisi de kendi parçasına dayanıyor. Hafifletici önlemler: karakter sayısına göre değil yapıya göre parçalamak ve süreklilik paralellikten daha önemliyse, parçadan parçaya güncellenen bir özeti ileriye taşımak (refine).

Not6. 2026’da çıkarımsal özetleme ne zaman doğru cevaptır?

Yanlış olmanın bedeli yüksek, özetin biraz hantal okunmasınınki düşükken. Çıkarımsal bir özet alıntılanmış metindir ve yeni ifade üretmez; gerçi bağlamından koparılmış bir cümle yine de yanıltabilir. Yeni ifade üretmemek, düzenlemeye tabi ya da hukuki bir ortamda akıcılıktan daha değerlidir.

Ayrıca oracle cevabın belgenin içinde olduğunu söylediğinde — yüksek oracle skoru seçimin uygulanabilir olduğu anlamına gelir — ve determinizme, denetlenebilirliğe ya da belge başına yaklaşık sıfır maliyete ihtiyacınız olduğunda. Bu derlemde lead-2, 3.397 haberin tamamı için 0,2 saniye sürüyor; LLM ise bunların 500’ü için 20 dakika sürdü, haber başına yaklaşık 2,4 saniye.

14.11 Mülakat soruları

Kaynaklar üzerine — Bölüm 2’deki çekincenin aynısı. Aşağıdaki sorular, bu kitabın baştan sona kullandığı iki güvenilir açık kaynakta tekrar ediyor: Chip Huyen’in Introduction to Machine Learning Interviews kitabı (Huyen 2021) ve AIMLInterviews deposu. Ayrıca bu bölümün kendi ölçümlerinin cevaplanabilir kıldığı sorular da var.

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

S: Bir özetleme sistemini nasıl değerlendirirsiniz?

Konuyu kapatan cevap: karşılaştırılabilirlik için ROUGE, ROUGE gerçeği göremediği için bir sadakat ölçümü ve iki otomatik ölçüm de size mutlak bir oran vermediği için aralığıyla birlikte elle denetlenmiş rastgele bir örneklem. Sonra önce neyi kontrol edeceğinizi söyleyin: tokenizer, oracle tavanı ve referansların kendilerinin sadık olup olmadığı. Yalnızca “ROUGE” deyip duran adaylar hiç özetleme sistemi yayına almamıştır.

S: Bu kadar kusurluysa ROUGE neden hâlâ kullanılıyor?

Çünkü ucuz, deterministik, yeniden üretilebilir ve makaleler arasında karşılaştırılabilir; ayrıca alternatifleri pahalı, deterministik olmayan ya da modele bağımlı. Apaçık kötü sistemleri apaçık iyi olanların altına sıralıyor; bir lider tablosunun ihtiyacı da büyük ölçüde bu. Doğru tutum onu raporlamak ve ondan tek başına asla sonuç çıkarmamak — ve neyi göremediğini söyleyebilmek: sadakati ve farklı kelimeler kullanan her yeniden ifadeyi.

S: Çıkarımsal mı, soyutlayıcı mı?

Önce oracle’ın ne dediğini sorun, sonra özet yanlış olursa ne olduğunu. Yüksek oracle artı pahalı hatalar, çıkarımsal bir problemdir. Düşük oracle artı hoşgörülü okurlar, soyutlayıcı bir problemdir. Düşük oracle artı pahalı hatalar — bu bölümdeki bilgilendirici haber özeti gibi — soyutlayıcı bir model ister, ama kaynağı yanında gösteren ya da insan incelemesinden geçiren bir hatla. Bu iki soruya göre değil de kişisel tercihine göre cevap veren aday tahmin yürütüyordur.

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

S: Özetleyiciniz demoda çalışıyor, ama kullanıcılar özetlerde halüsinasyon olduğunu söylüyor. Hata ayıklayın.

Maliyet sırasına göre; ilk ikisinin modelle ilgisi yok. (1) Model gerçekten halüsinasyon mu üretiyor, yoksa kullanıcının beklemediği doğru bir şeyi mi yüzeye çıkarıyor? Bir cümleyi işaret etmelerini isteyin. (2) Parçalama — bir map-reduce sınırı, tıpkı halüsinasyon gibi okunan, yerel olarak doğru ama birlikte yanlış çıktı üretir. (3) Prompt: açık bir dayandırma talimatı var mı? Burada ölçülen model böyle bir talimatla özetlerin %3–7’sinde işaretlendi; bu bölüm aynı modeli talimatsız koşturmadı, o yüzden aradaki farkı varsaymak yerine kendi verinizde ölçün. (4) Ancak ondan sonra model ve kod çözme parametreleri.

S: Bunu otomatik olarak nasıl yakalarsınız?

Varlık ve sayı vekil ölçüsü bir öğleden sonralık iş ve dışsal hataları yakalıyor; onu, skoru sıfır çıkması gereken kopyalanmış metin üzerinde doğrulayın. Bir gerektirme (entailment) modeli ya da bir LLM hakemi içsel hataları da yakalıyor. Gerektirme modeli ucuz; LLM hakeminin bedeli ise bu bölümün kurulumunda yargı başına kabaca 68 saniye. İkisinin, sıralamada anlaşsalar bile madde düzeyinde ayrıştığını söyleyin. Burada ölçüldü: biri 5, öteki 11 madde işaretledi ve yalnızca bir maddede örtüştüler. Dolayısıyla hiçbiri örneklenmiş bir insan okumasının yerini tutmuyor.

S: 10 milyon belge, bir bütçe ve bir teslim tarihi. Ne kurarsınız?

Önce maliyetler: 300 kelimelik haber başına 890 prompt token’ı ve maliyete girdi hâkim. Dolayısıyla en etkili adım model seçimi değil, kalıp metin temizliği. Sonra önbellekleme: bir özet (belge, prompt, model, parametreler) dörtlüsünün pratikte saf bir fonksiyonu, o yüzden önbellek anahtarını dördünden birden oluşturun ve prompt’un sürümünü de anahtara ekleyin. Sonra okurun bilgilendirici mi belirtici mi bir özete ihtiyacı olduğunu sorun; çünkü kaynağı özetin yanında göstermek birini diğerine dönüştürüyor ve her model iyileştirmesinden ucuz.

14.12 2026 alet çantası

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

Bu sayıların çıktığı yığın. Python 3.14.5, Apple Silicon

kütüphane	kullanılan sürüm	burada ne işe yarıyor
rouge-score	0.1.2	referans ROUGE uygulaması; bu bölümün uygulamasını doğrulamak ve paketin tokenizer’ını göstermek için
snowballstemmer	3.1.1	Türkçe gövdeleme; Bölüm 14.4’teki normalleştirici karşılaştırması için
numpy	2.5.2	TextRank’in arkasındaki çizge aritmetiği ve bölümdeki her ortalama
ollama	0.24.0	üretim için qwen3.5:9b, yargılama için gemma3:27b servis etme

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

Daha geniş ekosistem, yazım anındaki sürümlerle

kütüphane	güncel sürüm	ne zaman kullanılır
bert-score	0.3.13	embedding tabanlı örtüşme (Zhang vd. 2020) — ROUGE’un aksine yeniden ifadeye dayanıklı, ama sadakate hâlâ kör
summac / AlignScore	0.0.4 / yalnızca GitHub	gerektirme tabanlı sadakat puanlaması: her özet cümlesi kaynaktan çıkarsanabiliyor mu? Bu bölümdeki kaba vekil ölçünün sağlam temelli sürümü
factscore	0.2.0	bir metni atomik iddialara ayırıp her birini kontrol ediyor; özet uzun olduğunda istediğiniz şey bu. Varsayılan olarak iddiaları kaynak belgeye değil bir bilgi kaynağına (Wikipedia) karşı denetler; özet sadakati için bilgi kaynağını kaynak belgeyle değiştirmeniz gerekir
evaluate	0.4.6	Hugging Face’in metrik sarmalayıcısı — rouge metriğinin, tokenizer’ı dâhil, rouge-score’u sarmaladığına dikkat
lexrank / sumy	0.1.0 / 0.13.0	klasik çıkarımsal özetleyiciler paketlenmiş hâlde; LexRank ve LSA baseline’larını yazmadan istediğinizde
Trafilatura	2.2.0	belgeleri göndermenin bedelini ödemeden önce kalıp metni ayıklamak; Bölüm 14.9 maliyeti asıl düşürenin bu olduğunu söylüyor
langchain-text-splitters	1.1.2	Bölüm 14.6’daki map-reduce hatları için yapı farkındalıklı parçalama

14.13 Lab: bir derlemi özetleyin ve ona güvenilip güvenilemeyeceğini bulun

Kendi alanınızdan 200+ belgelik bir derlem seçin. Referans özetler isteğe bağlı — bu labın amacı zaten onlarsız değerlendirebilmeniz.

14.13.1 1. adım — ne tür bir özet olduğuna yazılı olarak karar verin

Bölüm 14.1’deki dört ekseni ve çıktıyı kimin okuduğunu adlandıran bir paragraf. Bunu yazamıyorsanız labın geri kalanına geçmek için henüz erken.

14.13.2 2. adım — modellemeden önce derlemi betimleyin

Kapsam, yoğunluk ve oracle-cümle ROUGE’unu hesaplayın. Oracle yüksekse çıkarımsal sistemi kurun ve durun. Düşükse üretken bir modeli az önce gerekçelendirdiniz; üstelik nedenini soran herkese gösterebileceğiniz bir sayıyla.

Referans özetiniz yoksa oracle’ı, belgenin kendi başlığını ya da ilk cümlesini referans alarak hesaplayın. Referans olarak kullandığınız şeyi aday havuzundan çıkarın; yoksa oracle onu seçer ve anlamsız bir tam eşleşme puanı alır. Bu, doğru yapıldığında bile daha zayıf bir sinyaldir; yine de size cevabın belgenin içinde mi olduğunu yoksa kurulması mı gerektiğini söyler.

14.13.3 3. adım — lead-k ve TextRank’i kurun

Her zaman. Bir saatinizi alırlar ve sonraki her iddia onların sayılarıyla karşılaştırılarak ölçülür.

14.13.4 4. adım — uzunluk sınırı ve dayandırma talimatıyla üretin

İkisi de önemli. İkisi de bu bölümün ölçtüğü sebeplerle Bölüm 14.5’teki prompt’ta yer alıyor.

14.13.5 5. adım — sadakat vekil ölçüsünü kurun, sonra bilerek kırın

Kaynakta bulunmayan sayılar ve özel isimler. Sonra bunu kopyalanmış metin üzerinde — lead-2 — koşturun ve sıfır döndüğünü doğrulayın. İlk seferde dönmeyecek. Dönene kadar düzeltin ve bozuk sürümün çıktısını saklayın; ikisi arasındaki fark, yayımlamış olacağınız şeydir.

14.13.6 6. adım — rastgele bir örneklemi elle denetleyin

Otuz belge, düzgünce okunmuş, her özet destekleniyor ya da desteklenmiyor diye işaretlenmiş. Oranı bir hüküm olarak değil, Wilson aralığıyla raporlayın: 3/30 %10’dur ve %95 aralığı %3,5 ile %25,6 arasıdır; yayına alma kararı, gerçek oranın bu aralığın neresinde olduğuna göre değişir. Örnekleme disiplini Bölüm 5’te.

14.13.7 7. adım — elle denetiminizi vekil ölçü ve hakemle karşılaştırın

Aynı özelliğin üç ölçümü. Uyuşmadıkları yerde belgeyi okuyun. Uyuşmazlıklar işe yarayan kısım: ucuz metriklerinizden hangisine başında durmadan güvenebileceğinizi onlar söylüyor.

14.13.8 Teslim edilecekler

Sistemleri ROUGE, sadakat vekil ölçüsü ve elle denetiminize göre karşılaştıran tek bir tablo; 2. adımdaki derlem betimlemesi; ve hangi sistemi kimin için yayına alacağınızı ve sistem yanıldığında ne olacağını söyleyen bir paragraf.

14.14 Alıştırmalar

1. Önce oracle. Ulaşabildiğiniz herhangi bir özetleme derleminde, hiçbir şey kurmadan önce oracle-cümle ROUGE-1’ini hesaplayın. Bunun çıkarımsal yöntemler hakkında ne ima ettiğini söyleyin, sonra lead-3’ü kurun ve öngörünüzün tutup tutmadığına bakın.

2. ROUGE’u bilerek kırın. Aynı haberin iki özetini yazın: biri doğru ve hantal, biri yanlış ve akıcı; öyle ki yanlış olan doğru bir özetten tek bir kelimeyle ayrılsın (bir olumsuzluk ya da yer değiştirmiş bir özne). İkisi için de ROUGE-1, -2 ve -L hesaplayın. Sıralamayı raporlayın.

3. Tokenizer, kendi dilinizde. rouge_score.tokenize.tokenize’ı, bildiğiniz ve İngilizce olmayan bir dilde 100 cümle üzerinde koşturun. Kaç kelimenin sağlam kaldığını sayın. Türkçe çalışıyorsanız, koşturmadan önce cevabı Bölüm 14.4’ten öngörün.

4. Normalleştirici duyarlılığı. Bir sistemin çıktısını alın ve üç normalleştiriciyle ayrı ayrı puanlayın: yüzey biçimi, gövdelenmiş ve — elinizde bunu yapacak bir araç varsa — lemmatization (sözlük biçimine indirgeme) uygulanmış. Yayılımı raporlayın ve bunu okuduğunuz en son özetleme makalesinin iddia ettiği iyileşmeyle karşılaştırın.

5. Parça sınırı kaybı. Map-reduce gerektirecek kadar uzun bir belge alın. Önce bütün hâlde özetleyin. Sonra kilit bir argümanı bilerek ikiye bölen parçalara ayırıp map-reduce ile özetleyin. Birinci özette bulunup ikincisinde bulunmayan bir olgu bulun ve mekanizmayı açıklayın.

6. Referansları denetleyin. Bölüm 14.7’deki sadakat vekil ölçüsünü, üzerinde fine-tuning yapmayı planladığınız herhangi bir derlemin referans özetleri üzerinde koşturun. Önce onu kopyalanmış metin üzerinde doğrulayın. Sonra o derlem üzerinde hâlâ fine-tuning yapmak isteyip istemediğinize karar verin.

7. Maliyet, eksiksiz. Fiilen elinizde olan bir derlem için, tamamını özetlemenin maliyetini hesaplayın: prompt token’ları, çıktı token’ları, wall-clock süresi (gerçekte geçen süre) ve bekleyeceğiniz önbellek isabet oranı. Bunu, yaklaşık sıfır olan çıkarımsal baseline’ın maliyetiyle ve özetlerin değeriyle karşılaştırın.

14.15 Daha derine inmek için

Tek bir makale okumadan önce şunu yapın: metriğinizle bir referans özeti yine kendisiyle karşılaştırarak puanlayın. Sonuç kusursuz çıkmıyorsa durun ve düzeneği düzeltin. Bu kontrol, bölümün sadakat vekil ölçüsünde iki kez bulduğu hata türünü yakalar: bir karşılaştırmanın iki tarafının farklı işlenmesi (bölüm o hataları, bu kontrolün yakın akrabası olan kopyalanmış metin kontrolüyle buldu). İki tarafı eşit biçimde bozan bir tokenizer’ı ise yakalamaz — rouge-score, Türkçe bir referansa kendisine karşı kusursuz puan verir — o yüzden token’ları da yazdırın.

Makalelerin ötesinde

kaynak	nedir
Google’ın rouge-score’u	tokenize.py’ı okuyun. İçindeki tokenize fonksiyonu dokuz satırlık kod ve bu bölümün %44,4’ünü açıklıyor
evaluate	çoğu makalenin kullandığı metrik sarmalayıcıları — hangi uygulamayı fiilen çağırdığınızı bilmekte fayda var
Eugene Yan, LLM kalıpları üzerine	üretim sistemlerinde özetleme ve değerlendirme üzerine pratik, iyi kaynaklandırılmış yazılar
XL-Sum	burada kullanılan çok dilli derlem; toplama yöntemi belgelenmiş hâlde
Stanford CS224N	metin üretimini ve değerlendirilmesini kapsayan dersler ve slaytlar

Birincil kaynaklar

konu	kaynak
metrik, ilk önerildiği hâliyle	Lin (2004)
neyi kaçırdığı, insan yargılarıyla karşılaştırılarak ölçülmüş	Fabbri vd. (2021)
n-gram yerine embedding	Zhang vd. (2020)
puanlayıcı olarak bir LLM	Liu vd. (2023); Zheng vd. (2023)
sadakat ve ne sıklıkta başarısız olduğu	Maynez vd. (2020); Kryściński vd. (2019)
modelsiz çıkarımsal özetleme	Mihalcea ve Tarau (2004)
derlemler ve her birinin ne kadar çıkarımsal olduğu	Grusky vd. (2018); Narayan vd. (2018); Hasan vd. (2021)
pointer-generator, LLM öncesi standart	See vd. (2017)
LLM’lerden sonra haber özetleme	Goyal vd. (2022)

14.16 Akılda kalması gerekenler

• Kurmadan önce nasıl bir özet istediğinize karar verin. Belirtici mi bilgilendirici mi, genel mi sorguya odaklı mı, tek belge mi çok belge mi, çıkarımsal mı soyutlayıcı mı. Kararı belirleyen soru şu: bunu kim okuyor ve yanlış olursa ne oluyor — %80 doğru belirtici bir özet gayet iyidir, %80 doğru bilgilendirici bir özet risk yaratır.

• Mimariyi seçmeden önce oracle’ı hesaplayın. Kusursuz tek cümle seçimi bu derlemde 24,89, CNN / DailyMail’de 40,58 ROUGE-1 alıyor. İki satır kodla hesaplanan bu tek sayı, cevabın belgenin içinde mi olduğunu yoksa kurulması mı gerektiğini söylüyor; dolayısıyla cümle seçiminin hiç işe yarayıp yaramayacağını da.

• Lead-3’ün ününü devralmayın. Literatürde CNN / DailyMail üzerinde 40,34 alıyor; burada ise 14,03 alıyor ve lead-2 bir cümle eksikle onunla berabere kalıyor. Lead baseline’ını her zaman raporlayın; güçlü olduğunu asla varsaymayın.

• rouge-score, Türkçe kelimelerin %44,4’ünü parçalara bölüyor. Tokenizer’ı, ç ğ ı ö ş ü İ harflerini ayraç sayıyor; dolayısıyla görüştü, ['g','r','t'] oluyor. Bu kırıntılar rastgele eşleşip ROUGE-1’i kabaca %60 şişiriyor — üstelik düzensiz biçimde, oracle için +%22’den rastgele bir baseline için +%80’e. Sıralamalar korunuyor; karşılaştırılabilirlik korunmuyor. Bizim kendi uygulamamız da aynı hata sınıfı için bir Türkçe küçük harfe çevirici gerektirdi ve o aracın tokenize edebildiği metinlerde rouge-score ile on ondalık basamağa kadar uyuşuyor.

• Tokenizer’ı ve normalleştirmesi belirtilmeyen bir ROUGE sayısı, sayı değildir. Aynı tahminler üzerinde “yüzey biçimi” ile “5 karakterlik ön ek” arasında beş ROUGE-1 puanı var — özetleme makalelerinde baseline’a göre sıkça raporlanan iyileşmelerden fazla.

• ROUGE, özetin doğru olup olmadığını göremez ve bu derlemde etkin biçimde yanlışlığı ödüllendiriyor: insan referansları vakaların %33–57’sinde desteklenmemiş içerik iddia ediyor — iki yöntemde %95 aralıkları %26 ile %65 arasına yayılıyor; metinde kalması söylenen bir model için bu oran %3–7. Böyle bir derlem üzerinde fine-tuning’in modele halüsinasyon üretmeyi öğretmesi beklenir; metrik de bunu iyileşme diye raporlar.

• Bir sadakat metriğini kopyalanmış metin üzerinde doğrulayın. Lead-2 birebir alıntı, dolayısıyla aynı ön işlemeden geçtiğinde yeni hiçbir kelime getirmemeli ve bu sözcüksel kontrolde sıfır almalı. Bu bir tokenizer kontrolü; kopyalanmış cümlelerin sadık olduğunun garantisi değil — bir cümleyi etrafındaki koşuldan ya da atıftan koparmak yine yanıltabilir. Bu kontrol burada ardışık iki hatayı yakaladı; ikisi de aynı hata: karşılaştırmanın iki tarafı farklı tokenizer’lardan geçmişti. İlk sürüm, BBC gazetecilerinin özetlerini %56 oranında sadakatsiz göstermişti.

• İki sadakat ölçümü sıralamada anlaşıp neredeyse başka hiçbir şeyde anlaşmayabilir. Vekil ölçü ile hakem, modelin özetlerinden sırasıyla 5 ve 11 tanesini işaretledi ve bir tanesinde örtüştü; çünkü biri yalnızca dışsal hataları, öteki ikisini birden görüyor. Sıraya güvenin, orana güvenmeyin ve mutlak sayıları aralığıyla birlikte örneklenmiş bir insan okumasından alın.

• Bu kurulumda yargılamak üretmekten pahalı. Yargı başına 68,3 saniyeye karşılık özet başına 2,4 saniye; hakem üç kat büyük bir model ve her sistem için ayrıca koşuyor. Örnekleyin, her şeyi yargılamayın ve bir modelin kendi çıktısını yargılamasına asla izin vermeyin.

• Maliyete girdi hâkim. Haber başına 890 prompt token’ına karşılık 53 üretilen token. Kalıp metni ayıklamak her model değişikliğini geçiyor. Anahtarı (belge, prompt, model, parametreler) dörtlüsü olan bir önbellek de neredeyse maliyetsiz bir tasarruf; çünkü belgeler yazıldığından çok daha sık okunuyor.

• Kaynağı özetin yanında göstermek, çoğu özetleme ürününde en yüksek getirili özelliktir ve bir model iyileştirmesi değildir. Doğru olmak zorunda olan bilgilendirici bir özeti, yalnızca yararlı olması yeten belirtici bir özete dönüştürür.

Kelime örtüşmesine dayanan bir metriğin Türkçeye ne yaptığı sorusu burada bitmiyor: Bölüm 15 aynı soruyu çevirinin varsayılan metriği BLEU için soruyor ve eklemeli bir dilin bedelini orada ölçüyor.

Fabbri, Alexander R., Wojciech Kryściński, Bryan McCann, Caiming Xiong, Richard Socher, ve Dragomir Radev. 2021. “SummEval: Re-evaluating Summarization Evaluation”. Transactions of the Association for Computational Linguistics 9: 391-409.

Goyal, Tanya, Junyi Jessy Li, ve Greg Durrett. 2022. “News Summarization and Evaluation in the Era of GPT-3”. arXiv preprint arXiv:2209.12356.

Grusky, Max, Mor Naaman, ve Yoav Artzi. 2018. “Newsroom: A Dataset of 1.3 Million Summaries with Diverse Extractive Strategies”. Proceedings of NAACL-HLT.

Hasan, Tahmid, Abhik Bhattacharjee, Md. Saiful Islam, vd. 2021. “XL-Sum: Large-Scale Multilingual Abstractive Summarization for 44 Languages”. Findings of ACL-IJCNLP.

Huyen, Chip. 2021. Introduction to Machine Learning Interviews Book. https://huyenchip.com/ml-interviews-book/.

Kryściński, Wojciech, Nitish Shirish Keskar, Bryan McCann, Caiming Xiong, ve Richard Socher. 2019. “Neural Text Summarization: A Critical Evaluation”. Proceedings of EMNLP-IJCNLP.

Lin, Chin-Yew. 2004. “ROUGE: A Package for Automatic Evaluation of Summaries”. Text Summarization Branches Out.

Liu, Yang, Dan Iter, Yichong Xu, Shuohang Wang, Ruochen Zhu, ve Chenguang Zhu. 2023. “G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment”. Proceedings of EMNLP.

Maynez, Joshua, Shashi Narayan, Bernd Bohnet, ve Ryan McDonald. 2020. “On Faithfulness and Factuality in Abstractive Summarization”. Proceedings of ACL.

Mihalcea, Rada, ve Paul Tarau. 2004. “TextRank: Bringing Order into Text”. Proceedings of EMNLP.

Narayan, Shashi, Shay B. Cohen, ve Mirella Lapata. 2018. “Don’t Give Me the Details, Just the Summary! Topic-Aware Convolutional Neural Networks for Extreme Summarization”. Proceedings of EMNLP.

See, Abigail, Peter J. Liu, ve Christopher D. Manning. 2017. “Get To The Point: Summarization with Pointer-Generator Networks”. Proceedings of ACL.

Zhang, Tianyi, Varsha Kishore, Felix Wu, Kilian Q. Weinberger, ve Yoav Artzi. 2020. “BERTScore: Evaluating Text Generation with BERT”. Proceedings of ICLR.

Zheng, Lianmin, Wei-Lin Chiang, Ying Sheng, vd. 2023. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”. Advances in Neural Information Processing Systems.