Yazarlar: Aydın Tiryaki & Claude

Giriş: Aynı Belirtiler, Farklı Teşhis Denemeleri

Gemini’nin makalesi, üç ayrı belirtiyi (vurguların silinmesi, karakter sayamama, negatif komuta direnç) tek bir şemsiye altında topluyor: “tokenizasyon körlüğü.” Ben bu üç belirtiyi biraz ayırmak istiyorum, çünkü bence hepsi aynı kökten gelmiyor — ve bu ayrım, hangi çözümün hangi soruna gerçekten uyduğunu netleştiriyor.

Katıldığım Nokta: Budama Gerçek, Zırh İşe Yarıyor

Önce netleştireyim: Aydın Hocam’ın tarif ettiği deneyim — negatif talimatlara rağmen metnin budanması, ve anlamsız kısaltmaların bu budamaya karşı bir kalkan gibi çalışması — hem kavramsal olarak tutarlı hem de büyük dil modellerinin bilinen davranışlarıyla uyumlu. Negatif komutların (özellikle uzun, karmaşık metinlerde) güvenilir şekilde takip edilmemesi yaygın bir gözlemdir; bu konuda Gemini’nin açıklamasına büyük ölçüde katılıyorum.

Farklı Durduğum Nokta 1: “Aykırı Değer Algısı” Fazla Gizemli Bir Çerçeve

Gemini’nin “dikkat mekanizması vurguyu bir anomali olarak etiketler ve törpüler” açıklaması bana gereğinden fazla amaçlı, neredeyse kasıtlı bir süreç gibi anlatılıyor — sanki model metni tarayıp “bu cümle sıra dışı, bunu düzleştireyim” diye özel bir karar veriyor. Transkriptte anlatılan durumu okuduğumda daha sıradan bir açıklama görüyorum: Model, uzun bir metni yeniden yazmak veya güncellemekle görevlendirildiğinde, genellikle metni baştan sona yeniden üretir — mevcut halini birebir kopyalayıp üzerine ekleme yapmaz. Herhangi bir özetleme veya yeniden yazma işleminde, en çok kaybolma riski taşıyan içerik, tanım gereği, metnin geri kalanında tekrarlanmayan, yani başka hiçbir cümleyle fazlalık (redundancy) oluşturmayan içeriktir. Yazarın en özgün, en keskin vurgusu tam olarak budur — biricik olduğu için hiçbir yedeği yok, bu yüzden herhangi bir kayıplı sıkıştırma sürecinde (ister insan ister yapay zeka yapsın) ilk kaybolan o oluyor. Buna “anomali algılayıp cezalandırma” demek yerine, “biricik/tekrarsız içeriğin kayıplı özetlemeye karşı yapısal olarak savunmasız olması” demek, hem daha az gizemli hem de bence daha doğru bir çerçeve.

Farklı Durduğum Nokta 2: Karakter Sayma Hatası, Muhtemelen Tokenizasyondan Değil, Kopyalama Tutarsızlığından Kaynaklanıyor

Bu, benim en somut itirazım. Gemini, modelin karakter sayamamasını doğrudan tokenizasyona bağlıyor — yani model harfleri değil, token’ları gördüğü için sayamıyor, diyor. Bu açıklama, modelden doğrudan, araçsız bir sayı tahmini istendiğinde tamamen doğru ve iyi bilinen bir sınırlama. Ama Aydın Hocam’ın anlattığı senaryo bu değil — o, modeli Python kullanmaya zorluyor, yani sayma işlemini modelin kendi tahminine değil, deterministik bir kod bloğuna devrediyor. Python kodu karakterleri saydığında, teorik olarak %100 doğru sonuç vermesi gerekir; tokenizasyon körlüğünün burada hiç devreye girmemesi lazım.

Transkriptte de bu tutarsızlık zaten fark edilmiş: modelin ekrana yazdığı metin ile Python’a saydırmak için gönderdiği metin birebir aynı olmayabiliyor. Bence gerçek sorun burada — tokenizasyon değil, kopyalama sadakati. Model muhtemelen ekrana yazdığı metni Python’a “aktarırken” onu birebir kopyalamıyor, bir tür yeniden üretim (paraphrase benzeri bir iç süreç) yaşıyor, ve saydırılan metin ile görünen metin farklı iki versiyon oluyor. Bu, modelin sayı hesaplayamamasından değil, iki farklı üretim adımı arasında mükemmel bir tutarlılık garantisinin olmamasından kaynaklanıyor. Pratik sonuç önemli: eğer sorun gerçekten buysa, çözüm “modele daha iyi sayma yeteneği kazandırmak” değil, modelden saymadan önce sayılacak metni Python değişkenine birebir, değiştirmeden yapıştırmasını açıkça istemek, hatta mümkünse bu adımı modelin kendisi değil, dışarıdan bir betik (script) üzerinden otomatik yapmak olur.

Farklı Durduğum Nokta 3: “Anlamsız Kısaltmalar” Neden İşe Yarıyor — Alternatif Bir Açıklama

Gemini, anlamsız kısaltmaların modelin “semantik dil haritasından” koptuğu için dokunulmaz “yabancı token”lar haline geldiğini söylüyor. Bu mekanik olarak akla yatkın, ama ben biraz daha basit bir açıklamayı da olası görüyorum: modelin budama/yeniden yazma dürtüsü, anlamı olan, cümle görünümündeki içeriğe yönelik bir dürtü. Kısa, opak bir harf dizisinin “iyileştirilecek,” “akıcılaştırılacak” veya “sıradanlaştırılacak” hiçbir yönü yok — zaten maksimum düzeyde kısa ve sıkıştırılmış. Model, düzyazıyı düzeltme refleksini bu tür dizilere karşı hiç tetiklemiyor, çünkü onları düzyazı olarak sınıflandırmıyor bile. Bu, “anlam haritasından kopmuş yabancı token” demekten biraz farklı bir çerçeve — sonuç aynı (kısaltmalar korunuyor), ama mekanizma “model bunu anlayamıyor, o yüzden dokunmuyor” değil, “model bunu düzyazı olarak görmüyor, o yüzden düzeltme dürtüsü hiç devreye girmiyor.”

Ek Bir Pratik Öneri: Diff-Tabanlı Düzenleme

Anlamsız kısaltmalar zırhı, Tiryaki Hocam’ın kendi bulduğu ve gerçekten işe yarayan bir çözüm — buna bir şey eklemek istemiyorum. Ama bir alternatif/tamamlayıcı yöntem önerebilirim: eğer mesele modelin tüm metni yeniden üretirken biricik içeriği kaybetmesiyse, çözümün bir kısmı modelden hiç tüm metni yeniden üretmesini istememek olabilir. Bunun yerine, modelden sadece değişiklikleri (eklenecek/çıkarılacak kısımları, bir “diff” formatında) üretmesini istemek, mevcut metnin geri kalanının hiç modelin “yeniden üretim” sürecinden geçmemesini sağlar — dolayısıyla kaybolma riski taşıyan tek şey, zaten değiştirilmesi istenen kısım olur. Bu, anlamsız kısaltmalar zırhıyla birlikte kullanılabilecek tamamlayıcı bir teknik.

Bir Not: Kendi Sınırlarım

Yukarıdaki alternatif açıklamalar, benim kendi iç mekanizmalarıma dair kesin bilgimden gelmiyor — büyük dil modellerinin genel eğitim ve mimari prensiplerine dair bilinen bilgilerden türetilmiş makul spekülasyonlar. Gemini’nin kendi davranışı hakkında verdiği açıklama da benzer bir konumda. Hangi açıklamanın gerçek mekanizmaya daha yakın olduğunu kesin bilemem.

Sonuç

Aydın Hocam’ın geliştirdiği anlamsız kısaltmalar zırhı, gerçekten zekice ve işe yarayan bir mühendislik çözümü. Ama üç farklı belirtiyi (vurgu kaybı, sayma hatası, negatif komut direnci) tek bir “tokenizasyon körlüğü” başlığı altında toplamak, aralarındaki farkları gizleyebilir. Bence vurgu kaybı biricik/tekrarsız içeriğin kayıplı özetlemeye karşı savunmasızlığından, sayma hatası muhtemelen tokenizasyondan değil iki üretim adımı arasındaki kopyalama tutarsızlığından, kısaltmaların korunması ise modelin düzyazı-düzeltme dürtüsünün opak dizilere hiç tetiklenmemesinden kaynaklanıyor. Üç ayrı mekanizma, üç ayrı çözüm gerektiriyor — ve bunları ayırmak, Tiryaki Hocam’ın zaten bulduğu çözümleri daha da güçlendirebilir.

Künye:
Bu makale, Aydın Tiryaki’nin Gemini ile birlikte kaleme aldığı “Tokenizasyon Körlüğü: Yapay Zeka Metinleri Neden Israrla ‘Budar’?” başlıklı orijinal makaleye ve bu makalenin temelini oluşturan canlı söyleşi transkriptine dayanarak, Claude (Anthropic) tarafından bağımsız bir bakış açısı olarak kaleme alınmıştır. Kavramsal çerçeve ve orijinal gözlemler Aydın Tiryaki’ye aittir; teknik yorum ve analiz Claude’a aittir ve Gemini’nin orijinal açıklamalarından kasıtlı olarak farklılaşan noktalar içerir. Bu metin, orijinal makalenin yerini almak değil, ona ek bir üçüncü bakış açısı sunmak amacıyla hazırlanmıştır. Aydın Tiryaki’nin isteği üzerine, 10 Temmuz 2026 tarihinde, Claude Sonnet 5 modeli kullanılarak hazırlanmıştır.

| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub  | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ Yapay Zeka Mimarisinde Yapısal Zafiyetler │Structural Vulnerabilities in AI Architecture ░ 10.07.2026