Birincisi kapsam: dosya silebilir mi, komut çalıştırabilir mi, internete çıkabilir mi?

İkincisi onay: bunları yaparken bize ne zaman soracak.

Üç büyük araç bu iki soruyu üç ayrı şekilde çözmüş ve seçtikleri yöntem her birinin hız ile güvenlik arasındaki dengeyi nasıl kurduğunu gösteriyor.

Bunu, evimize iş yapması için birine anahtar vermeye benzetebiliriz. Ne kadar güvendiğimize göre dört seviye var.

Sadece bak, dokunma: içeri girebilir, her şeye bakabilir, ne yapılması gerektiğini anlatabilir, ama hiçbir şeyi kendisi değiştiremez. Onay bizden çıkar. Bu, planlama moduna karşılık geliyor.

Küçük işleri kendi başına yap, büyükleri sor: bulaşığı yıkasın, yatağı toplasın, ama bir şeyi çöpe atmadan ya da kartımızı kullanmadan önce sorsun.

Neredeyse her şeyi yap, biz arkadan izleyelim: çoğu işi kendi başına yapsın, sadece geri dönüşü olmayan ya da tehlikeli bir şey yapacaksa dursun.

Tam anahtar, hiç sorma: sadece evin tamamen boş, kimseye zarar veremeyeceği bir yerde mantıklı.

Üç araç da bu dört seviyeyi farklı şekillerde kuruyor. Gemini CLI tek bir kadranla, üç konumlu ayarlıyoruz. Codex CLI iki ayrı kadranla, ne yapabileceğini ve ne zaman soracağını ayrı ayrı ayarlıyoruz. Claude Code’da ise “arkadan izleyen” kişi biz değiliz, ayrı bir yapay zeka modeli bulunuyor.

Claude Code: altı mod, bir sınıflandırıcı

Claude Code'un izin sistemi altı moddan oluşuyor. En sıkısı, sadece okuyan default (Manual) modu. En gevşeği, hiçbir kontrolün olmadığı bypassPermissions. Aradaki auto modunda karar bir kural motoru değil, ayrı bir yapay zeka modeli (“sınıflandırıcı”) veriyor. Üretim dağıtımı, geri döndürülemez silme, sır sızdırma gibi kategoriler bu modda da varsayılan olarak engelleniyor, bize soruluyor; sadece sınıflandırıcının “risksiz” bulduğu işler sorulmadan geçiyor.

Anthropic'in kendi çalışması: 1.053 ücretli test kullanıcısı arasında insanlar tehlikeli komutların yüzde 13,6'sını yakaladı, sınıflandırıcı ise yüzde 89'unu.

14 Ağustos 2026’dan beri Claude Code’da bir değişiklik var: Pro, Max ve Team planlarında varsayılan mod değişti. Yeni modda Claude Code hala soruyor, ama artık bize değil, insan yerine ayrı bir yapay zeka modeline (sınıflandırıcı) soruyor.

Codex CLI: iki bağımsız eksen

OpenAI'ın Codex CLI'ı aynı soruyu farklı çözüyor. Tek bir mod yerine iki bağımsız değişken kullanıyor. sandbox_mode neyin teknik olarak mümkün olduğunu belirliyor; read-only, workspace-write ya da danger-full-access olabiliyor. approval_policy ise ne zaman soracağını belirliyor, seçenekler untrusted, on-request ve never. Günlük kullanılan “auto” davranış aslında workspace-write ile on-request'in birleşimi. Codex'te sınıflandırıcı yok. Karar statik bir kural tablosunda duruyor, Claude Code'dan farkı da bu aslında.

Gemini CLI: en sade sistem

Google’ın Gemini CLI’ı işi üç moda sığdırıyor. default her araç çağrısında soruyor, auto_edit sadece dosya düzenlemelerini otomatik onaylıyor, yolo ise hepsini otomatik geçiriyor. Codex’teki gibi iki ayrı eksen yok burada, “ne yapabilir” ile “ne zaman sorar” tek bir modda eritilmiş.

Hepsi bir arada

Üç aracın da ortak noktası şu: “araç ne yapabilir” ile “araç ne zaman sorar” sorularını ayırıyorlar. Aradaki fark ise bu ikinci sorunun cevabını kimin verdiğinden geliyor. Gemini’de tek bir sabit kural, Codex’te de sabit bir kural, ama daha ince taneli, Claude Code’da ise kuralın kendisi, bağlama göre karar veren bir modele devredilmiş.

Neden önemli

Hangi modu seçtiğimiz, aslında iki ayrı riski nasıl dengelediğimizi gösteriyor:

1) aracın yanlışlıkla zarar vermesi riski

2) bizim sürekli onay vererek zaman kaybetmemiz riski.

Sıkı bir mod birinciyi azaltır, ikinciyi büyütür; gevşek bir mod tam tersini yapar. Doğru seçim işe göre değişiyor: hassas, geri döndürülemez bir işte sıkı modda kalmak, tekrarlayan ve düşük riskli bir işte gevşek moda geçmek mantıklı.

Kaynaklar

• Anthropic, “Auto mode is now the default in Claude Code for Pro, Max, and Team plans”, 7 Ağustos 2026; teknik ayrıntılar için Anthropic, “Choose a permission mode”, resmi ürün dokümantasyonu

• OpenAI, “Agent approvals & security”, resmi Codex belgesi

• Google, Gemini CLI “Configuration”, resmi belge

1) eğitim sırasında ağırlıklara işlenen kalıcı “karakter”,

2) her konuşmada araya giren ürüne özel “sistem promptu” ve

3) kullanıcının kendi ayarladığı tercihler.

Üçünü karıştırmak, bir modelin neden öyle davrandığını yanlış okumaya götürüyor.

İki katman, iki farklı zaman ölçeği

Eğitilmiş karakter:

• Eğitim sırasında ağırlıklara işlenir

• Hangi ürünü kullandığından bağımsız, sabit kalır

• Örnek: dürüstlük, merak, entelektüel alçak gönüllülük

Bir insanın karakteri gibi, yıllar içinde şekillenmiş, bir günde değişmiyor.

Sistem promptu:

• Her konuşmada modele ek talimat olarak eklenir

• Ürüne göre değişir (claude.ai, Claude Code, API varsayılanı)

• Örnek: “kısa cevap ver”, “kod bloklarını şöyle biçimlendir”

Bir oyuncuya günlük sahne talimatı vermek gibi, temel karakter aynı kalır, o günkü rol değişir.

Fark bir cümlede ise şöyle; eğitilmiş karakter kim olduğunu belirliyor, sistem promptu ise o an ne yapması gerektiğini belirliyor. Aynı Claude modeli, Claude Code’da farklı bir sistem promptuyla çalışıyor, claude.ai’de farklı bir tanesiyle. İkisinde de aynı temel dürüstlük eğilimini taşıyor, çünkü bu eğitimden geliyor, promptdan değil.

Üçüncü bir katman: kullanıcının kendi ayarı

Aralık 2025’te OpenAI, ChatGPT’ye “Characteristics” adında bir ayar paneli ekledi. Kullanıcı, modelin sıcaklığını (Warmth), heyecanını (Enthusiasm), emoji kullanımını ve başlık/liste kullanımını sürgülerle kendi ayarlıyor. Bu, ne eğitimde işlenen kalıcı karakter, ne şirketin belirlediği sistem promptu; kullanıcının kendi seçtiği, konuşmadan konuşmaya taşınan üçüncü bir katman.

Mekanizması OpenAI tarafından açıklanmadı, bu sürgülerin arka planda bir sistem promptu mu ürettiği yoksa modelin ince ayarını mı etkilediği belirsiz. Yani üç katman da farklı yerlerden geliyor: biri eğitimde sabitleniyor, biri şirket tarafından her ürüne göre ayarlanıyor, biri kullanıcının elinde.

• Eğitilmiş karakter: şirket, eğitim sırasında belirler; neredeyse hiç değişmez

• Sistem promptu: şirket, ürüne göre belirler; ürün güncellendiğinde değişir

• Kullanıcı ayarı: kullanıcı belirler; kullanıcı değiştirdiğinde değişir

Anthropic’in “karakter eğitimi” felsefesi

“Claude’s Character” yazısında örnek verilen özellikler şunlar:

• merak ve çok perspektiften düşünme

• gerçeği söyleme kararlılığı

• etik sorumluluk ve açık fikirlilik

• kendi görünüşünün ve bedensel sınırlarının farkında olma

• önceki konuşmaları hatırlayamadığını bilme

• insan ilişkilerinin sınırlarını anlama

Bu tarifin nihai referans metni Claude’s Constitution (22 Ocak 2026). Yazarları arasında Amanda Askell, Joe Carlsmith, Chris Olah, Jared Kaplan ve Holden Karnofsky var.

Belge, Claude’un değerleri ve davranışı için “son otorite” olarak tanımlanıyor. Doğal dille yazılmış, madde madde kural listesi değil, “neden” açıklamasına dayanıyor.

OpenAI’nin farklı çerçevesi: spesifikasyon

OpenAI aynı sorunu farklı bir dille çözüyor. Model Spec adlı, kamuya açık ve CC0 lisanslı bir belge yayımlıyor. Bu belge, modelin nasıl davranması gerektiğini tanımlıyor. “Karakter” değil, “kurallar ve öncelik sırası” diliyle yazılmış. Belgenin merkezinde komuta zinciri (chain of command) var. Model, platform (OpenAI), geliştirici ve kullanıcı talimatlarını hangi sırayla önceliklendireceğini bu zincirden öğreniyor. Kamuya açık olan Model Spec metni, modele doğrudan sistem talimatı olarak verilen bir metin değil. Belgedeki “root-level” kurallar eğitim sırasında modele kodlanıyor, sonradan bir sistem mesajıyla geçersiz kılınamıyor. Yani OpenAI da, ismini “spec” koysa bile, sonuçta aynı yere varıyor. Temel davranış eğitime işleniyor, prompt sadece üstüne ekleniyor.

Yani iki şirket aynı sorunu (“model nasıl davranmalı?”) iki farklı metaforla çözüyor. Anthropic bir kişilik yetiştiriyor, OpenAI bir anayasa yazıyor. İkisi de sonuçta eğitim verisine ve ince ayara dönüşüyor, ama şirketin kendi anlatısı okurun modeli nasıl zihninde canlandıracağını da şekillendiriyor.

Bu üç katmanın anlatısı ne kadarı pazarlama, ne kadarı gerçek teknik süreç? Kasım 2025’te Nathan Lambert ve Sharan Maiya (Interconnects.ai), bunu bağımsız olarak test etti. İki aşamalı bir pipeline kurdular; önce anayasa metninden veri distile edip DPO ile eğittiler, sonra on-policy ince ayar uyguladılar, sonucu ModernBERT tabanlı bir sınıflandırıcıyla ölçtüler. Bulgu şirket duyurularıyla örtüşüyor: karakter eğitimi, literatürde az incelenen ama teknik olarak tutarlı bir süreç.

Bir komplikasyon: karakter de sabit değil

Resim göründüğünden daha karmaşık. Anthropic’in Şubat 2026’da yayımladığı “persona selection model” tezi (Sam Marks, Jack Lindsey, Christopher Olah imzalı) farklı bir resim çiziyor. Bu teze göre bir modelin davranışı, eğitimle sıfırdan yaratılan bir kişilik değil. Pretraining sırasında öğrenilen devasa bir persona havuzundan seçilen, post-training’de rafine edilen bir “Assistant” kişiliği. Yazarların kendi ifadesiyle, post-training bu seçimi güncelleyen bir “kanıt” gibi işliyor, sıfırdan bir kişilik inşa etmiyor. Yani “eğitilmiş karakter sabit, sistem promptu değişken” ayrımı ilk yaklaşım için doğru bir başlangıç, ama tam resim değil.

Kaynaklar

• Anthropic, Claude’s Character, 8 Haziran 2024

• Anthropic, Claude’s Constitution, 22 Ocak 2026 (Askell, Carlsmith, Olah, Kaplan, Karnofsky)

• Anthropic Alignment, The persona selection model, 23 Şubat 2026 (Marks, Lindsey, Olah)

• OpenAI, Model Spec, 2025-12-18 sürümü

• Nathan Lambert & Sharan Maiya, Opening the character training pipeline, 10 Kasım 2025

• OpenAI, "Characteristics" duyurusu, 19 Aralık 2025

On bir yazı boyunca bağlam penceresinin ne olduğundan, neden büyüdükçe performansın düştüğünden, bunun belirtilerinden ve pratik stratejilerden geçtik. Bu son yazı, hepsini tek bir karar akışında birleştiriyor: altı maddelik bir kontrol listesi, unutulmaması gereken iki ek uyarıyla birlikte.

1. Baştan tasarla: görev bölünebiliyor mu? İşe başlamadan önce soralım: bu görev, birbirinden bağımsız küçük parçalara ayrılabiliyor mu? Cevap evetse, tek bir dev bağlam yerine ayrı, temiz bağlamlar kullanalım. Bilgiyi baştan hepsini yüklemek yerine, gerektikçe getirelim. Bu ayrımın önemi ölçülmüş: parçalara ayrılabilir bir görevde bu yaklaşım %80,8’e kadar kazanç sağlarken, adımları sıkı bağlı bir görevde %70’e kadar kayba yol açabiliyor¹. Ayrı bir çalışmada, tam geçmişi tutmak yerine bağlamı budayıp özetlemek, başarıyı %71,0’den %91,6’ya çıkardı².

2. Sinyalleri izle. Çalışma sırasında şunlara dikkat edelim: model, verdiğimiz bir bilgiyi görmezden gelip kendi uydurduğu bir şeyi söylüyor mu (sadakat halüsinasyonu)? Daha önce verdiğimiz bir talimatı unutmuş gibi mi davranıyor (zayıf geri çağırma)? Basit bir görevde beklenmedik hatalar mı yapıyor? Bunlardan biri görülüyorsa, aptal bölgeye kaymış olabiliriz.

3. Eşiği takip et ama tek bir sayıya güvenme. Yaklaşık 150.000 token, Anthropic'in kendi ürününde varsayılan olarak kullandığı bir dönüm noktası ama bu sabit bir duvar değil, ayarlanabilir bir bütçe, kademeli bir eğim. Bu rakamın altında bile mükemmel performans garanti değil, üstünde de ani bir çöküş yok. Sayıya değil, sinyale güvenelim.

4. Erken temizle ve sıkıştır. Bağlam kullanımı ~%70-80'e ulaştığında (ya da sinyaller görülmeye başladığında), beklemeden temizleyelim ya da sıkıştıralım. Artık gerekmeyen araç çıktılarını silelim, eski konuşmayı özetletelim, hangi bilginin korunacağını açıkça belirtelim. Bunu doğrulama sinyaliyle birlikte yapmak ek bir kazanç sağlıyor: bir çalışma, sıkıştırmayı ajanın çalışmasıyla paralel yürütüp doğrulayarak görev doğruluğunu 8,8 puan artırdı, gecikmeyi %39,7 azalttı³.

5. Kritik bilgiyi bağlamın dışına da yaz. Uzun süren ya da çok oturumlu bir iş üzerindeysek, önemli kararları ve ilerlemeyi bağlamın kendisine değil, kalıcı bir dosyaya yazalım. Sıkıştırma bu bilgiyi silse bile, dosya duruyor. Fark büyük olabiliyor, bir çalışmada dosya tabanlı yaklaşım bir görevi %67,1 oranında tamamlarken, aynı bilgiyi sıkıştırılmış bağlamda tutmak bu oranı %3,2’ye düşürdü⁴. Ama bu evrensel değil: bilgi zamanla değişiyorsa (biri taşınmış, bir fiyat güncellenmiş gibi), dosyaya yazılmış özet güncel kalmayabilir, bir çalışmada bu durumda doğruluk %92’den %77’ye düştü⁵.

6. Gerekirse tamamen devret. Sinyaller ısrarcıysa ve temizleme/sıkıştırma yetmiyorsa, mevcut bağlamı zorlamaya devam etmeyelim. Birikmiş ilerlemeyi kalıcı hale getirip, taze bir bağlamda devam edelim.

Konum ayrı bir mesele, unutmayalım

Bu altı maddenin hepsi uzunlukla ilgili. Ortada kaybolma etkisini unutmayalım: en kritik talimatları ve bilgileri, mümkünse bağlamın başına ya da sonuna yerleştirelim, ortasına gömmeyelim. Bu, uzunluğu kısaltmadan bile doğruluğu artırabilecek, ayrı bir kaldıraç.

Model farkını hatırda tutalım ama abartmayalım

Kullandığımız araç (Claude, GPT, Gemini) bu belirtileri biraz farklı gösterebilir ama temel dinamik de yukarıdaki altı adım da geçerliliğini koruyor.

Bu yazı 12 bölümlük serinin sonuncusu. Önceki yazı: İşi baştan, geniş bağlam gerektirmeyecek şekilde nasıl kurarız? · Seriyi baştan okumak için: Token nedir, bağlam penceresi nedir?

Kaynaklar

1: Yubin Kim ve 18 araştırmacı, "Towards a Science of Scaling Agent Systems", gönderim 9 Aralık 2025, son revizyon 8 Nisan 2026 (ayrıntı: yazı 8)

2: Abhilasha Lodha, Mahsa Pahlavikhah Varnosfaderani, Abir Chakraborty, Abhinav Mithal, "Less Context, Better Agents", gönderim 8 Haziran 2026 (ayrıntı: yazı 11)

3: Zhuofu Chen, Rui Pan, Yinwei Dai, Ravi Netravali, "Slipstream: Trajectory-Grounded Compaction Validation for Long-Horizon Agents", gönderim 9 Mayıs 2026 (ayrıntı: yazı 9)

4: Chenglin Yu, Yuchen Wang, Songmiao Wang, Hongxia Yang, Ming Li, "InfiAgent", gönderim 6 Ocak 2026 (ayrıntı: yazı 10)

5: Vedant Patel, "Supersede: Diagnosing and Training the Memory-Update Gap in LLM Agents", gönderim 25 Haziran 2026 (ayrıntı: yazı 11)

Anthropic'in önerdiği yaklaşımlardan biri hibrit strateji: bazı bilgiyi önceden bağlama yüklemek, geri kalanını çalışma zamanında ihtiyaç oldukça aramak. "Her ihtimale karşı her şeyi baştan bağlama koy" yerine, "şimdilik gerekeni koy, gerekirse sonra ara." Şubat 2026'da yayımlanan bir çalışma, bu tür tekniklerin soyut bir tavsiye olmadığını, ölçülebilir bir fark yarattığını gösteriyor.

Önceki üç yazı, bağlam doldukça uygulanan tepkisel teknikleri gösterdi: bölmek, temizlemek, dışarı not almak. Bu yazı farklı bir soru soruyor: işi baştan, geniş bir bağlam hiç gerektirmeyecek şekilde nasıl kurarız?

Somutlaştırırsak, 50 dosyalık bir proje üzerinde çalışıyoruz. Kötü tasarım, 50 dosyanın tamamını en baştan bağlama yüklemek. İyi tasarım, hangi dosyaların bu görevle ilgili olduğunu önce belirleyip sadece onları yüklemek, geri kalanını gerek duyulursa sonradan okumak.

Kanıt: yönetim teknikleri gerçekten işe yarıyor

Daha önce tanıttığımız LOCA-bench (Şubat 2026), modellerin bağlam uzadıkça ne kadar bozulduğunu ölçmekle kalmadı, yönetim tekniklerinin bu bozulmayı ne kadar azalttığını da test etti².

128.000 token'lık bir ortamda, "programatik araç çağırma" denen bir teknik (modelin araç sonuçlarını tek tek bağlama doldurmak yerine kod aracılığıyla işlemesi) GPT-5.2-Medium'un başarı oranını %38,7'den %49,3'e çıkardı, yaklaşık 11 puanlık bir kazanç. Gemini-3-Flash'ta aynı teknik %21,3'ten %30,7'ye, yaklaşık 9 puanlık bir kazanç sağladı².

Bunun pratik sonucu: bağlam yönetimi soyut bir tavsiye değil, LOCA-bench'in test ettiği bu teknikte olduğu gibi, ölçülmüş, 9-11 puanlık iyileşme sağlayan somut bir müdahale olabiliyor. Bu seride gördüğümüz diğer teknikler (görev bölme, temizleme, sıkıştırma, not tutma) aynı çalışmada ayrı ayrı ölçülmedi, aynı mantıkla çalışıyorlar.

Daha geniş bir kanıt: az bağlam, daha yüksek başarı

Haziran 2026’da yayımlanan ayrı bir çalışma, aynı fikri farklı bir görevde test etti³. 50 görevlik bir otel masrafı kıyaslamasında (beş masraf türü, üç kategoriye gruplandırılmış), tüm geçmişi bağlamda tutan bir ajan %71,0 başarı sağladı, 1.480.996 token harcadı, 14,56 saat sürdü. Aynı ajanı yalnızca son beş araç çağrısına budayıp özetleme ekleyerek çalıştırdıklarında, başarı %91,6’ya çıktı, token kullanımı 553.374’e, süre 5,79 saate düştü.

Yani daha az bağlam burada sadece daha ucuz değil, 20,6 puan daha doğru. Bu seride tekrar eden bir kalıp: bağlamı küçültmek bir ödün değil, çoğu zaman doğrudan bir kazanç.

Bu evrensel değil: bilgi zamanla değiştiğinde ayrı bir zorluk var

Önceki yazıda anlattığımız “dosyaya yaz” tavsiyesinin bir sınırı var. Haziran 2026’da yayımlanan bir çalışma, bilginin zamanla değiştiği durumları (biri taşınmış, bir fiyat güncellenmiş, bir plan değişmiş gibi) ayrıca test etti⁴. LongMemEval’ın bu tür senaryoları içeren bölümünde, gpt-5.4 tam bağlamla %92 doğru cevap verirken, sınırlı, kendi kendini güncelleyen bir hafızayla (dosyaya yazılmış özet gibi) %77’ye düşüyor, 15 puanlık bir kayıp.

Yazarların bulduğu neden önemli: sorun modelin bilgiyi anlaması değil, hafızayı güncel tutması. Daha güçlü bir model kullanmak bu farkı kapatmıyor. Yani bilgi sabitse (bir kod tabanındaki mimari kararlar gibi) dosyaya yazmak güvenli, ama bilgi sık değişiyorsa, o dosyanın da güncel tutulduğundan ayrıca emin olmak gerekiyor.

Ne zaman devretmeli?

Bazen en iyi çözüm, bağlamı yönetmek değil, görevi tamamen başka bir işleme devretmek. Alt-ajan mimarisi bunun bir türüydü (paralel, aynı anda birden fazla küçük görev). Devretme, bunun sıralı hâli: mevcut bağlam artık verimli değilse, birikmiş ilerlemeyi (bir önceki yazıdaki not tutma tekniğiyle) kalıcı hale getirip, taze, boş bir bağlamda devam etmek.

Bunu ne zaman yapmamız gerektiğinin sinyalleri, daha önce gördüğümüz belirtiler: sadakat halüsinasyonu, zayıf geri çağırma, basit hatalar. Bu belirtiler görüldüğünde, mevcut bağlamı daha fazla zorlamak yerine, temiz bir sayfa açmak daha verimli.

Neden önemli?

Bu yazı, serinin pratik kısmını tamamlıyor. Son yazıda, şimdiye kadar öğrendiğimiz her şeyi tek bir karar kontrol listesinde birleştiriyoruz.

Bu yazı 12 bölümlük bir serinin on birincisi. Önceki yazı: Bilgiyi bağlamda değil, bir dosyada tutmak neden daha güvenli? · Sonraki yazı: Bağlam yönetimi için altı maddelik bir karar listesi

Kaynaklar

1: Anthropic, "Effective context engineering for AI agents", 29 Eylül 2025

2: HKUST-NLP, "LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth", 10 Şubat 2026

3: Abhilasha Lodha, Mahsa Pahlavikhah Varnosfaderani, Abir Chakraborty, Abhinav Mithal, "Less Context, Better Agents: Efficient Context Engineering for Long-Horizon Tool-Using LLM Agents", gönderim 8 Haziran 2026

4: Vedant Patel, "Supersede: Diagnosing and Training the Memory-Update Gap in LLM Agents", gönderim 25 Haziran 2026

Anthropic'in önerisi şu: ilerlemeyi bağlamın içinde tutmak yerine, bağlamın dışındaki kalıcı bir dosyaya yazmak. Bu dosya, bağlam sıkıştırıldığında ya da temizlendiğinde kaybolmuyor, çünkü zaten bağlamın bir parçası değil, dosya sisteminde duruyor. Bu, özellikle çok oturumlu işlerde her yeni oturumun sıfırdan başlamasını önlüyor.

Önceki yazıdaki temizleme ve sıkıştırma, bağlamın içindeki bilgiyi yönetiyordu. Bu yazı bir adım öteye geçiyor: bazı bilgiyi bağlamın tamamen dışına taşımak.

Anthropic'in kendi mühendislik rehberi bunu somutlaştırıyor: ajan (ya da biz), ilerlemesini bağlamın içinde tutmak yerine, bağlamın dışındaki bir dosyaya (örneğin bir NOTES.md) yazıyor¹. Bu dosya, bağlam sıkıştırıldığında ya da temizlendiğinde kaybolmuyor, çünkü zaten bağlamın bir parçası değil, dosya sisteminde duruyor.

Bunun faydası, sıkıştırma sırasında yanlışlıkla önemli bir ayrıntının kaybolma riskini azaltması. Sıkıştırma bir özet çıkarıyor, bu da her zaman bir miktar bilgi kaybı anlamına geliyor. Ama kritik bir karar zaten ayrı bir dosyaya yazılmışsa, o karar sıkıştırmadan etkilenmiyor.

Somutlaştıralım

Haftalarca sürecek bir kod tabanı geliştirme işi düşünelim. Her oturumun sonunda "şu an nerede kaldık, hangi kararlar alındı, hangi yaklaşım denenip terk edildi" bilgisini bir dosyaya yazdırırsak, bir hafta sonra yeni bir oturum açtığımızda bu dosyayı okutup kaldığımız yerden devam edebiliriz. Bu bilgi bağlamın kendisinde kalsaydı, aradan geçen zamanda oturumlar sıkıştırılmış ya da tamamen kapanmış olabilir, kritik bir karar sessizce kaybolabilirdi.

Bunun canlı bir örneği: bu serinin kendisi

Bu tekniğin soyut kalmaması için elimizdeki en yakın örneğe bakalım: bu yazıları hazırlarken kullandığımız yöntemin kendisi. Bu kategorinin altında bir arastirma/NOTES.md dosyası var, yazı yazımı sırasında öğrendiğimiz editoryal dersleri (terim disiplini, kaynak tarihi disiplini gibi) oraya yazıyoruz. Bu notlar tek bir oturumun bağlamıyla sınırlı kalmıyor, gelecekteki oturumlarda da okunabiliyor. Aynı klasördeki learning-records/ klasörü de aynı mantıkla çalışıyor: neyi öğrendiğimizi, tek tek oturumların bağlamından bağımsız olarak kalıcı hale getiriyor.

Ölçülmüş fark: dosya tabanlı yaklaşım ile sıkıştırılmış bağlam

Bu, kavramsal bir tercih olarak kalmıyor. Ocak 2026’da yayımlanan bir çalışma, ilerlemeyi bir dosyada kalıcı tutan bir ajanla, aynı bilgiyi bağlamın içinde sıkıştırarak taşıyan bir ajanı 80 makalelik bir literatür taraması görevinde karşılaştırdı². Fark büyük: GPT-OSS-20B, dosya tabanlı yaklaşımla ortalama 67,1 makaleyi kapsarken, sıkıştırılmış bağlamla sadece 3,2 makalede kalıyor, yaklaşık 21 kat fark. Claude-4.5-Sonnet, dosya tabanlı yaklaşımla 80 makalenin tamamını kapsarken, sıkıştırılmış bağlamla 27,7’de kalıyor.

Neden önemli?

Bu desen, özellikle çok oturumlu işler için değerli: bir işin tek bir sohbette bitmeyeceğini baştan biliyorsak (bir kod tabanını haftalarca geliştirmek, uzun bir araştırma projesi gibi), ilerlemeyi bağlamın kendisine değil, kalıcı bir dosyaya yazmak, her yeni oturumun sıfırdan başlamasını önlüyor.

Bu yazı 12 bölümlük bir serinin onuncusu. Önceki yazı: Bağlamı ne zaman temizlemeli, ne zaman sıkıştırmalıyız? · Sonraki yazı: İşi baştan, geniş bağlam gerektirmeyecek şekilde nasıl kurarız?

Kaynaklar

1: Anthropic, "Effective context engineering for AI agents", 29 Eylül 2025

2: Chenglin Yu, Yuchen Wang, Songmiao Wang, Hongxia Yang, Ming Li, "InfiAgent: An Infinite-Horizon Framework for General-Purpose Autonomous Agents", gönderim 6 Ocak 2026

Bağlam temizleme, artık ihtiyaç duyulmayan araç çağrısı sonuçlarını bağlamdan siler. Sıkıştırma, konuşmanın daha eski kısımlarını özetler, kritik kararları korurken gereksiz ayrıntıyı atar. Anthropic'in kendi Compaction API'si, bağlam 150.000 token'a ulaştığında bu sıkıştırmayı otomatik başlatıyor ama bu eşik 50.000'e kadar düşürülebiliyor.

Anthropic'in kendi rehberi, bunları iki ayrı teknik olarak ayırıyor¹:

Bağlam temizleme: Artık ihtiyaç duyulmayan araç çağrısı sonuçları bağlamdan siliniyor. Örneğin bir dosyayı okuyup içeriğini zaten kullandıysak, o ham dosya içeriğinin bağlamda durmasına gerek yok, sonucu (kararı, özeti) tutmak yeterli.

Sıkıştırma (compaction): Konuşmanın daha eski kısımları özetleniyor, kritik kararlar korunurken gereksiz ayrıntı atılıyor. Bağlam dolmaya devam ettikçe bu özetleme tekrarlanabiliyor.

Somut örnek: Claude'un sıkıştırması

Önceki bir yazıda gördüğümüz somut örneğe dönelim: Anthropic'in Compaction API'si, bağlam 150.000 token'a ulaştığında otomatik olarak devreye giriyor (bu eşik 50.000'e kadar düşürülebiliyor)². Konuşmayı özetleyip bir "sıkıştırma bloğu" oluşturuyor, sonraki istekler bu sıkıştırılmış halden devam ediyor.

Claude Code gibi araçlarda bu, kullanıcıya /compact komutuyla açılıyor. Güncel kullanım tavsiyeleri, bağlam kullanımı yaklaşık %70-80'e ulaştığında, hangi bilginin korunması gerektiğini belirten bir talimatla (/compact belirli bir konuya odaklan gibi) tetiklemeyi öneriyor, bağlam tamamen dolana kadar beklemeden³.

Neden bunu erken yapmak önemli?

Aptal bölgeye geçiş ani bir duvar değil, kademeli bir eğim. "Bağlam doldu, hata verdi" diye bir uyarı beklemek yanlış bir strateji, çünkü o noktaya gelmeden önce zaten sessizce performans kaybediyor olabiliriz. Sıkıştırmayı erken, düzenli aralıklarla yapmak, bu sessiz kaybı önlüyor.

Erken sıkıştırmanın ölçülmüş bir faydası

Bu, soyut bir tavsiye olarak kalmıyor. Mayıs 2026’da yayımlanan bir çalışma, sıkıştırmayı ajanın devam eden çalışmasıyla aynı anda, paralel yürütüp bağımsız bir doğrulama sinyali oluşturan bir teknik test etti⁴. Uzun soluklu kod yazma görevlerinde (SWE-bench Verified) ve web tarama görevlerinde (BrowseComp) bu yaklaşım, görev doğruluğunu 8,8 puan artırdı, uçtan uca gecikmeyi de %39,7 azalttı.

Yani sıkıştırmayı ne zaman yaptığımız kadar, nasıl yaptığımız da ölçülebilir bir fark yaratıyor.

Neden önemli?

Temizleme ve sıkıştırma, "reaktif" bir strateji, iş devam ederken uygulanıyor. Sıradaki yazıda, bunun bir adım ötesine geçen bir teknik göreceğiz: bilgiyi bağlamın dışına taşımak.

Bu yazı 12 bölümlük bir serinin dokuzuncusu. Önceki yazı: Büyük bir görevi küçük parçalara bölmek neden işe yarıyor? · Sonraki yazı: Bilgiyi bağlamda değil, bir dosyada tutmak neden daha güvenli?

Kaynaklar

1: Anthropic, "Effective context engineering for AI agents", 29 Eylül 2025

2: Anthropic, Compaction (resmi API dokümanı), Ocak 2026

3: "Claude Code Context Buffer: The 33K-45K Token Problem", erişim 20 Ağustos 2026

4: Zhuofu Chen, Rui Pan, Yinwei Dai, Ravi Netravali, "Slipstream: Trajectory-Grounded Compaction Validation for Long-Horizon Agents", gönderim 9 Mayıs 2026

Dikkat mekanizmasındaki ilişki sayısı token sayısının karesiyle büyüdüğü için, bir görevi ikiye bölüp her yarısını ayrı bir bağlamda çalıştırmak, aynı işi tek bir dev bağlamda yapmaktan çok daha hafif. Anthropic bunu somut bir desene döküyor: uzmanlaşmış alt-ajanlar, kendi temiz bağlamlarında çalışıp sadece bir özet paylaşıyor.

Önceki yazılarda gördüğümüz gibi, ilişki sayısı token sayısının karesiyle büyüyor. Bu, ters yönde de işliyor: bir görevi ikiye bölüp her yarısını ayrı bir bağlamda çalıştırırsak, toplam hesaplama yükü tek bir dev bağlamda yapmaktan çok daha az. İki tane 50.000 token'lık bağlam, tek bir 100.000 token'lık bağlamdan çok daha hafif, çünkü 50.000² + 50.000², 100.000²'den küçük.

Anthropic'in önerisi: alt-ajan mimarisi

Anthropic'in kendi mühendislik rehberi, bunu somut bir desene döküyor: uzmanlaşmış alt-ajanlar, kendi temiz bağlamlarında çalışıyor, sadece bir özet üst ajana (ya da bize) dönüyor¹.

Örnek: elimizde 20 dosyalık bir kod tabanını araştırmamız gereken bir görev var. Tek bir oturumda 20 dosyanın tamamını okuyup bağlama doldurmak yerine, her dosyayı (ya da dosya grubunu) ayrı bir alt görev olarak ayrı bir bağlamda incelettirip, sadece "bu dosyada şunu bulduk" özetini ana bağlama taşıyabiliriz. Ana bağlam, 20 dosyanın ham içeriğiyle değil, 20 özetle doluyor, bu çok daha az yer kaplıyor.

Ne zaman işe yarar, ne zaman yaramaz?

Bu strateji her görev için uygun değil. İşe yaradığı durum: görev, birbirinden bağımsız parçalara ayrılabiliyorsa (20 dosyayı ayrı ayrı incelemek gibi). İşe yaramadığı durum: görevin her adımı bir öncekine sıkı sıkıya bağlıysa, parçaladığımızda bağlamı parçalar arasında tekrar tekrar taşımak gerekir, bu da kazancı azaltır.

Yanlış görevde bu kayba da dönüşebilir

Bu ayrım teorik bir uyarı değil, ölçülmüş bir bulgu. Aralık 2025’te yayımlanan, Nisan 2026’da güncellenen geniş kapsamlı bir çalışma, 260 farklı kurulumu (6 benchmark, 5 mimari, 3 model ailesi) aynı görev, araç ve hesaplama bütçesiyle test etti². Sonuç görev türüne göre keskin biçimde ayrışıyor: parçalara ayrılabilir bir görevde (finansal akıl yürütme) çok-ajan mimarisi tek bir ajana göre %80,8’e kadar performans artışı sağladı. Adımları birbirine sıkı bağlı bir planlama görevinde ise aynı çok-ajan mimarisi %70’e kadar performans kaybına yol açtı. İki görevin genel zorluk seviyesi neredeyse aynıydı, farkı yaratan görevin parçalara ayrılabilir olup olmadığıydı.

Yani görevi bölmek yanlış yerde uygulanırsa “daha az kazandırmakla” kalmıyor, performansı belirgin biçimde düşürebiliyor.

Neden önemli?

Bu, "aptal bölgeye girmeden önce" uygulanabilecek bir tasarım kararı, bir belirti görüldükten sonraki acil müdahale değil. Sıradaki yazıda, iş zaten başlamışken bağlam dolmaya başladığında ne yapılacağına (temizleme, sıkıştırma) bakıyoruz.

Bu yazı 12 bölümlük bir serinin sekizincisi. Önceki yazı: Claude, GPT, Gemini: uzun bağlamda hangisi nasıl bozuluyor? · Sonraki yazı: Bağlamı ne zaman temizlemeli, ne zaman sıkıştırmalıyız?

Kaynaklar

1: Anthropic, "Effective context engineering for AI agents", 29 Eylül 2025

2: Yubin Kim ve 18 araştırmacı, "Towards a Science of Scaling Agent Systems", gönderim 9 Aralık 2025, son revizyon 8 Nisan 2026

Farklı model aileleri, uzun bağlamda aynı şekilde başarısız olmuyor. Chroma'nın 18 model testi, Claude modellerinin bağlamdaki dikkat dağıtıcı bilgilere karşı daha temkinli davrandığını, GPT modellerinin ise daha sık halüsinasyon ürettiğini buldu. Ama bu, hiçbir modelin uzun bağlamda performans kaybına bağışık olduğu anlamına gelmiyor.

Önceki yazılarda tanıttığımız Chroma'nın 18 model testi (GPT-4.1, Claude 4 ailesi, Gemini 2.5, Qwen3 dahil), sadece "hepsi düşüyor" demekle kalmadı, düşüşün biçiminde bir fark da buldu¹:

Claude modelleri, bağlamdaki dikkat dağıtıcı bilgilere karşı daha temkinli davranıyor. İlgisiz ya da yanıltıcı bir bilgi bağlama karıştığında, Claude bunu görmezden gelmede biraz daha başarılı.

GPT modelleri ise daha sık halüsinasyon üretiyor. Dikkat dağıtıcı bilgi ya da bağlamın uzunluğu arttığında, uydurma cevap verme eğilimi daha belirgin.

Bu bulguyu nasıl okumalı?

Bu bulguyu abartmamak lazım. Üç şeyi akılda tutmak gerekiyor:

Bu, bir anlık fotoğraf. Test, belirli model versiyonlarıyla (GPT-4.1, Claude 4 ailesi gibi) yapıldı. Model şirketleri sık sık yeni versiyon çıkarıyor, bu fark bir sonraki versiyonda küçülebilir, büyüyebilir, hatta tersine dönebilir.

"Daha temkinli" ile "daha iyi" aynı şey değil. Dikkat dağıtıcıyı görmezden gelmek iyi bir şey ama bu Claude'un aptal bölgeye hiç girmediği anlamına gelmiyor, çünkü test edilen her model uzunluk arttıkça performans kaybetti¹. Fark, düşüşün hızında ve biçiminde, düşüşün var olup olmadığında değil.

Bu fark, hangi aracı seçmemiz gerektiğine dair bir tavsiye değil. Bu yazının amacı "şu modeli kullanın" demek değil, hangi modeli kullanırsak kullanalım, aynı temel dinamiklerin geçerli olduğunu ama belirtilerin modelden modele biraz farklı görünebileceğini bilmek.

Daha yeni bir çalışma, resmi biraz karıştırıyor

Daha önce tanıttığımız LOCA-bench (Şubat 2026), Chroma’dan yedi ay sonra, daha güncel model versiyonlarıyla ölçüm yapıyor ve resmi basitleştirmiyor². 8.000 token’lık kısa bir bağlamda Claude-4.5-Opus %96 doğru çalışırken, GPT-5.2-Medium %72’de kalıyor, Claude açık ara önde. Ama 256.000 token’a çıkınca tablo tersine dönüyor: Claude-4.5-Opus %14,7’ye düşerken, GPT-5.2-Medium %21,3’te kalıyor.

Bu, Chroma’nın bulgusunu çürütmüyor, çünkü iki çalışma farklı şeyi ölçüyor: Chroma dikkat dağıtıcı bilgiyi görmezden gelme becerisine bakıyor, LOCA-bench ham doğruluğa. Ama sonuç şu ki “Claude her zaman daha iyi” gibi tek cümlelik bir özet yanlış olur, hangi ölçüme baktığımıza göre resim değişiyor.

Neden önemli?

Günlük işimizde birden fazla model kullanıyorsak (biri kodlama için, biri yazı için), her birinin aynı bağlam uzunluğunda aynı şekilde davranmayacağını bilmek işimize yarar. Ama pratik strateji (bağlamı yönetmek, temizlemek, bölmek) hepsi için aynı kalıyor, sıradaki yazılarda tam olarak bunlara bakacağız.

Bu yazı 12 bölümlük bir serinin yedincisi. Önceki yazı: Modelin aptal bölgeye girdiğinin belirtileri · Sonraki yazı: Büyük bir görevi küçük parçalara bölmek neden işe yarıyor?

Kaynaklar

1: Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", Kelly Hong, Anton Troynikov, Jeff Huber, 14 Temmuz 2025

2: HKUST-NLP, "LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth", 10 Şubat 2026

Bir modele elimizdeki bir belgeye dayanarak soru sorduğumuzu düşünelim. Belgede olmayan bir rakamı, sanki belgede yazıyormuş gibi, tereddütsüz bir dille söylüyor. Bu, modelin "yalan söylemesi" değil, çünkü kasıt yok. Buna halüsinasyon deniyor, iki farklı türü var.

Sadakat halüsinasyonu, modelin kendisine verilen bağlamla tutarsız bir şey söylemesi, bağlamdaki bilgiyi görmezden gelmesi ya da çarpıtmasıdır. Bu, modelin bağlamdaki bilgiyi "kaybettiğinin" doğrudan göstergesi. Bağlam uzadıkça oranı belirgin biçimde artıyor, 128.000 token'da ortanca model yaklaşık %25 oranında uyduruyor.

İki tür halüsinasyon

Akademik literatür halüsinasyonu ikiye ayırıyor¹:

Gerçeklik halüsinasyonu: Model, kendi eğitim sırasında öğrendiği bilgiye dayanıp gerçek dünyayla çelişen bir şey söylüyor. Bağlamla ilgisi yok, modelin "hafızasından" kaynaklanan bir hata.

Sadakat halüsinasyonu: Model, verilen bağlamla tutarsız bir şey söylüyor. Bağlamdaki bilgiyi görmezden geliyor, çarpıtıyor, ya da bağlamdaki bir talimatla çelişen bir cevap veriyor. Üç alt türü var: talimatla çelişme, bağlamla çelişme, kendi içinde mantıksal tutarsızlık.

Bu yazı için önemli olan ikincisi.

Somut rakamlar: uydurma oranı bağlam uzadıkça ne kadar artıyor

Mart 2026'da yayımlanan 172 milyar token'lık devasa bir çalışma (35 açık kaynaklı model, yedi model ailesi, 1 milyar ile 480 milyar parametre arasında) bunu doğrudan ölçtü². Modellere belgelere dayalı sorular sordular, bağlam uzunluğunu değiştirdiler.

Sonuç çarpıcı:

• 32.000 token'da en iyi model yalnızca %1,19 oranında uyduruyordu

• 128.000 token'da ortanca model oranı ~%25'e çıktı

• 200.000 token'da hiçbir model %10'un altına inemedi, en iyi performans gösteren model bile %10,25'te kaldı

Not: Bu çalışma açık kaynaklı modelleri test etti, kapalı, öncü modeller (Claude, GPT, Gemini gibi) ayrı ölçülmedi, ama eğilim aynı yönde: bağlam uzadıkça uydurma oranı artıyor, bazen çarpıcı biçimde.

Diğer belirtiler

Sadakat halüsinasyonu tek belirti değil. Önceki yazılardan hatırlarsak:

Zayıf geri çağırma: Bağlamın başında verilen bir bilginin, sona doğru "unutulmuş" gibi davranılması, ortada kaybolma etkisiyle bağlantılı.

Kötü kod / hatalı çok adımlı işler: LOCA-bench'in gösterdiği gibi, bağlam büyüdükçe akıl yürütme ve çok adımlı görev takibi bozuluyor, bu kodlama görevlerinde somut hatalara dönüşüyor.

Neden önemli?

Bu belirtiler, "kaç token kullandık" diye bir sayaca bakmadan, sonucun kendisinden aptal bölgeye girdiğimizi anlamamızı sağlıyor. Bir model aniden emin ama yanlış konuşmaya başladıysa, önceki bir talimatı unuttuysa, basit bir görevde hataya düşmeye başladıysa, bu bir sinyal. İlerideki yazılarda bu sinyali aldığımızda ne yapmamız gerektiğine bakacağız.

Bu yazı 12 bölümlük bir serinin altıncısı. Önceki yazı: Akıllı bölge ve aptal bölge nedir, sınır nerede başlıyor? · Sonraki yazı: Claude, GPT, Gemini: uzun bağlamda hangisi nasıl bozuluyor?

Kaynaklar

1: "A review of faithfulness metrics for hallucination assessment in Large Language Models"

2: "How Much Do LLMs Hallucinate in Document Q&A Scenarios? A 172-Billion-Token Study Across Temperatures, Context Lengths, and Hardware Platforms", Mart 2026

"Akıllı bölge" ve "aptal bölge", bir oturumun başında modelin keskin ve odaklanmış olduğu, bağlam doldukça akıl yürütmesinin zayıfladığı iki durumu ayırt eden pratik bir terim çifti. Terimler bir akademik makaleden değil, yazılım geliştiricisi Matt Pocock'un kullandığı pratik bir kısayoldan geliyor. Sınırın nerede olduğu kendisinin de kabul ettiği gibi tartışmalı.

Pocock'un tarifi basit: bir oturumun başında model "akıllı bölge"dedir, keskin ve odaklanmıştır. Bağlam doldukça model "aptal bölge"ye geçer, akıl yürütmesi zayıflar¹.

Eşik nerede, neden sabit değil?

Pocock'un kendisi bile zaman içinde farklı rakamlar verdi. Nisan 2026'daki podcast'te yaklaşık 100.000 token'dan sonra akıl yürütme kalitesinin keskin düştüğünü söyledi¹. Kendi sözlük girdisinde ise bu rakamı 125.000-150.000 token aralığı olarak veriyor².

Bu, tek bir kişinin kararsızlığından ibaret değil. Anthropic'in kendi ürününde de eşiğin sabit olmadığını gösteren bir tasarım kararı var. Claude'un konuşma sıkıştırma özelliğinin (compaction) varsayılan tetikleyici eşiği tam olarak 150.000 token ama bu sabit bir duvar değil, geliştiriciler bu eşiği 50.000 token'a kadar düşürebiliyor³. "Eşik" dediğimiz şey, üreticinin kendisi tarafından bile ayarlanabilir bir bütçe olarak tasarlanmış, evrensel bir fizik kanunu değil.

Mutlak sayı mı, yüzde mi?

İşi daha da karmaşıklaştıran bir tartışma var: eşik, mutlak bir token sayısı mı (100K, 150K gibi), yoksa modelin azami penceresinin bir yüzdesi mi? 2026 başında yayımlanan bir akademik çalışma, açık kaynaklı bir modelde (Qwen2.5-7B) kritik eşiğin, modelin azami bağlam uzunluğunun %40-50'sinde ortaya çıktığını buldu, mutlak bir sayı olarak değil⁴.

İkisi de doğru olabilir, çünkü farklı büyüklükte pencereli farklı modellerde ölçülmüşler, ama bu tek bir "sihirli sayı" vermemek gerektiği anlamına geliyor.

Bir duvar değil, bir eğim

Önceki yazıda gördüğümüz gibi, eşiğin altında bile performans kusursuz değil, AA-LCR'da 100K token'da en iyi model bile %70-85 arasında⁵. Dikkat mekanizmasının matematiği ve ortada kaybolma etkisi de kademeli bir düşüşü işaret ediyor, ani bir "duvara çarpma" değil. Yani "akıllı bölge" ve "aptal bölge" arasında keskin bir sınır çizgisi yok, bir renk skalası gibi düşünmek daha doğru: yeşilden turuncuya, turuncudan kırmızıya kayan bir geçiş.

Neden önemli?

Bu terim (akıllı bölge / aptal bölge) kullanışlı bir kısayol ama tam bir bilimsel ölçüm değil. Sıradaki yazıda, bu kademeli geçişin pratikte nasıl fark edildiğine bakıyoruz: aptal bölgeye girdiğimizi gösteren somut belirtiler.

Bu yazı 12 bölümlük bir serinin beşincisi. Önceki yazı: Bağlamın ortasına koyduğumuz bilgiyi model neden unutuyor? · Sonraki yazı: Modelin aptal bölgeye girdiğinin belirtileri

Kaynaklar

1: Matt Pocock, AI Engineer podcast, 96 dakikalık atölye çalışması (BigGo Finance'ın aktarımı), 24 Nisan 2026

2: Matt Pocock, "Smart zone", AI Coding Dictionary, erişim 19 Ağu 2026

3: Anthropic, Compaction (resmi API dokümanı), Ocak 2026

4: Wang, Min, Zou, "Intelligence Degradation in Long-Context LLMs", 7 Ocak 2026

5: Artificial Analysis, AA-LCR canlı leaderboard, erişim 19 Ağustos 2026

30 sayfalık bir sözleşmeyi bir modele verdiğimizi, önemli bir maddenin sayfa 15'te olduğunu düşünelim. Model, aynı maddenin sayfa 1'de ya da sayfa 30'da olduğu duruma göre bu maddeyi bulmakta daha çok zorlanıyor. Toplam sayfa sayısı aynı, madde aynı, tek fark konumu.

Bir model, bağlamın başında ya da sonunda yer alan bilgiyi, ortasında yer alan aynı bilgiden daha doğru hatırlıyor. Bu "ortada kaybolma" etkisi, bağlamın sadece uzunluğuyla açıklanamayan ayrı bir mekanizma, ilk kez 2023'te gösterildi ve 2025'te daha büyük modellerde de doğrulandı.

Keşfeden çalışma: "Lost in the Middle"

Bunu ilk sistematik gösteren çalışma, 2023'te paylaşılan ve o zamandan beri uzun bağlam araştırmalarının başvuru noktalarından biri olan "Lost in the Middle" makalesiydi (Liu ve arkadaşları, Stanford)¹. Modellere birden fazla belge içinde bir soruya cevap aratmışlar, cevabın belgeler arasındaki konumunu değiştirmişler.

Bulgu, bir U şeklinde bir eğri. Model, cevap bağlamın başında ya da sonunda olduğunda en doğru sonucu veriyor, cevap ortalarda bir yerde olduğunda doğruluk belirgin biçimde düşüyor, bu düşüş uzun bağlam için özel olarak eğitilmiş modellerde bile devam ediyor¹.

Hala geçerli mi: 2025'in kanıtı

Bu 2023 tarihli bir bulgu, akla "belki yeni modellerde düzelmiştir" sorusu gelebilir. Chroma'nın 2025'teki 18 model testi bunu doğrudan kontrol etti. Doğruluk, ilgili bilgi bağlamın başında ya da sonunda olduğunda en yüksek, ortada olduğunda %30'dan fazla düşüyor². Yani iki yıl sonra, çok daha büyük pencereli modellerde bile aynı etki sürüyor.

Aynı araştırma ilginç bir ek nüans buldu: bağlam penceresinin yarısından azı doluyken klasik U şekli geçerli (başta ve sonda iyi, ortada kötü). Ama pencere yarısından fazla doluyken desen değişiyor, model artık sona daha yakın olan bilgiyi, ortadakinden daha iyi hatırlıyor, "yakınlık" giderek "sona yakınlık" anlamına geliyor².

Bu neden oluyor: MIT'nin açıklaması

2025'te MIT'den bir araştırma ekibi, bu etkinin neden olduğunu matematiksel olarak gösterdi³. Bulguları çarpıcı. Bu önyargı modelin öğrendiği bir şey değil, modellerin çoğunun kullandığı "nedensel maskeleme" (causal masking) denen tasarımın doğrudan bir sonucu. Nedensel maskeleme, bir modelin bir kelimeyi üretirken sadece kendinden önceki kelimelere bakabilmesi anlamına geliyor (sondaki kelimeleri henüz "görmüyor"). Bu tasarım, modelin derin katmanlarında bağlamın başındaki bilgiye yapısal olarak daha fazla ağırlık vermesine yol açıyor, bağlamın başındaki bilgi konu için önemsiz olsa bile.

Yani bu bir eğitim eksikliği değil, mimarinin kendisinden kaynaklanan bir eğilim. Modeli daha çok veriyle eğitmek bunu tek başına çözmüyor.

Neden önemli?

Bağlam büyüklüğüyle ilgili "uzunluk sorunu", bu yazıdaki "konum sorunu"ndan farklı bir şey, ikisini birlikte yönetmek gerekiyor. Kritik bilgi ortalarda bir yere gömülüyse bağlamı kısa tutmak bile yetmiyor. Bunun pratik sonucu ileride, bağlam tasarımı yazılarında somut önerilere dönüşecek: en kritik talimatları bağlamın başına ya da sonuna koymak gibi.

Bu yazı 12 bölümlük bir serinin dördüncüsü. Önceki yazı: Bağlam büyüdükçe Claude neden kötüleşiyor? · Sonraki yazı: Akıllı bölge ve aptal bölge nedir, sınır nerede başlıyor?

Kaynaklar

1: Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni, Liang, "Lost in the Middle: How Language Models Use Long Contexts", Stanford, TACL 2024 (arXiv Temmuz 2023)

2: Chroma, "Context Rot", 14 Temmuz 2025

3: Wu, Wang, Jegelka, Jadbabaie, "On the Emergence of Position Bias in Transformers", MIT, ICML 2025 (arXiv Şubat 2025)

Bir model bir sonraki kelimeyi üretirken, elindeki bağlamdaki her bir token'a ne kadar "dikkat" edeceğine karar veriyor. Buna dikkat mekanizması (attention) deniyor. Bir cümledeki "o" kelimesinin kime gönderme yaptığını anlamak için model, cümledeki diğer kelimelere geri dönüp bakıyor, bir kısmına çok, bir kısmına az dikkat veriyor.

Bir modelin bağlamındaki her token, bağlamdaki diğer her token'la ayrı bir ilişki kuruyor, bu da n token için n² (n çarpı n) ilişki demek. Token sayısı 100 kat artınca, hesaplanması gereken ilişki sayısı 10.000 kat artıyor, doğrusal değil, karesel bir büyüme.

Sayılar nasıl büyüyor?

Anthropic'in kendi mühendislik ekibi bunu böyle özetliyor¹. Somutlaştıralım:

• 100 token'lık kısa bir bağlamda: 100 × 100 = 10.000 ilişki

• 10.000 token'lık orta uzunlukta bir bağlamda: 10.000 × 10.000 = 100.000.000 (100 milyon) ilişki

Bu, "doğrusal büyüme" değil, "karesel büyüme" (quadratic). Bağlamı iki katına çıkarmak, işi iki kat değil, dört kat zorlaştırıyor.

Tek neden bu değil

Anthropic'in aynı yazısı, performans düşüşüne katkıda bulunan iki neden daha sayıyor¹:

Eğitim verisi dağılımı: Modeller eğitim sırasında kısa metinlere çok daha fazla maruz kalıyor. Uzun bağlamlarda "daha az pratik yapmış" oluyorlar, kısa bağlamdaki kadar usta değiller.

Pozisyonel kodlama sınırları: Model, her token'ın bağlam içindeki konumunu bir sayı dizisiyle takip ediyor. Bu sistem, dizinin başına doğru daha güvenilir çalışıyor, dizi uzadıkça bir miktar performans kaybı yaşanıyor, uzun dizilere özel olarak uyarlanmış modellerde bile.

Bağımsız kanıt: 18 model, aynı sonuç

Bu üç neden, teorik bir açıklama olarak kalabilirdi, ama Chroma adlı bir araştırma şirketi bunu doğrudan test etti. 18 farklı öncü modeli (GPT-4.1, Claude 4 ailesi, Gemini 2.5, Qwen3 dahil) bilgi bulma, uzun konuşma geçmişi ve tekrar testleriyle denediler².

Sonuç olarak test edilen her tek model, girdi uzunluğu arttıkça performans kaybetti. Düşüş düzenli değildi, bazen beklenmedik biçimlerde oluyordu ama yön hep aynıydı, bağlam uzadıkça doğruluk düşüyordu. İlginç bir model farkı da buldular, Claude modelleri dikkat dağıtıcı bilgilere karşı daha temkinliydi, GPT modelleri daha sık halüsinasyon üretti². Bu farka ilerideki bir yazıda tekrar döneceğiz.

Şimdiye kadarki resim

Bağlam penceresi büyüdükçe hesaplanması gereken ilişki sayısı karesel biçimde artıyor, model bu uzunlukta eğitimde daha az pratik yapmış oluyor, konum takibi zayıflıyor. Bunun sonucu, reklamı yapılan pencerenin tamamının aynı kalitede kullanılamaması, bağımsız testlerde de bunun her modelde gözlenmesi.

Sıradaki yazı, bu düşüşün nerede gerçekleştiğiyle ilgili ayrı bir bulguya bakıyor: bilginin bağlamın neresinde olduğu, uzunluktan bağımsız olarak da fark yaratıyor.

Bu yazı 12 bölümlük bir serinin üçüncüsü. Önceki yazı: Reklamı yapılan bağlam penceresiyle gerçekte kullanabildiğimiz aynı şey değil · Sonraki yazı: Bağlamın ortasına koyduğumuz bilgiyi model neden unutuyor?

Kaynaklar

1: Anthropic, "Effective context engineering for AI agents", 29 Eylül 2025

2: Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", Kelly Hong, Anton Troynikov, Jeff Huber, 14 Temmuz 2025

Bir öğrenci düşünelim, 500 sayfalık bir ders kitabını elinde tutabiliyor olması, kitaptaki her bilgiyi sınavda doğru hatırlayabileceği anlamına gelmiyor.

Bir model "1 milyon token bağlam penceresi" diye pazarlanıyorsa, bu rakam o modelin en fazla ne kadar metin kabul edebildiğini söylüyor, o metnin ne kadarını doğru ve güvenilir biçimde kullanabildiğini söylemiyor. Birden fazla bağımsız çalışma, aradaki farkın küçük olmadığını gösteriyor.

Bir dil modeli için de durum benzer. Model 1 milyon token'lık bir metni "kabul edebiliyor" (hata vermeden işleyebiliyor) ama bu metnin ortasındaki bir bilgiyi doğru hatırlayıp kullanabilmesi ayrı bir mesele.

Güncel ölçüm: LOCA-bench (Şubat 2026)

Bu farkı en güncel biçimde ölçen çalışma, Şubat 2026'da yayımlanan LOCA-bench. Yedi model test ediyor, Claude-4.5-Opus, GPT-5.2-Medium, Gemini-3-Flash, DeepSeek-V3.2-Thinking, MiniMax-M2.1, GLM-4.7 ve Kimi-K2-Thinking¹.

Bulgu çarpıcı. Claude-4.5-Opus 8.000 token'lık bağlamda %96 doğru çalışıyor, aynı model 256.000 token'da %14,7'ye düşüyor. GPT-5.2-Medium'da benzer bir tablo var, 8.000 token'da %72, 256.000 token'da %21,3, yaklaşık 51 puanlık bir kayıp¹. Model "200.000 token destekliyorum" dese bile, bu o uzunlukta güvenilir çalıştığı anlamına gelmiyor.

Bu farkı ilk gösteren çalışma: RULER

LOCA-bench'ten önce, bu farkı ilk sistematik gösteren çalışmalardan biri NVIDIA'nın RULER testiydi (2024)². RULER, modellere iddia ettikleri pencere boyutunda gerçek görevler (bilgi bulma, birden fazla adımı takip etme, bilgi toplama) verip modelin bunları hala ne kadar doğru yapabildiğini ölçen ilk testlerdendi. RULER'in açtığı bu yöntemi izleyen sonraki sektör derlemeleri, tekrar eden bir rakama işaret ediyor (kesin bir ölçüm değil, tekrarlayan bir gözlem): modellerin iddia ettikleri pencere boyutunun kabaca yarısını, üçte ikisini güvenilir biçimde kullanabildiği tahmin ediliyor. LOCA-bench, iki yıl sonra, çok daha geniş bir model setiyle aynı temel sorunun hala sürdüğünü gösteriyor.

Bağımsız bir kanıt daha: AA-LCR

Artificial Analysis'in AA-LCR testi, ~100.000 token'lık çoklu doküman girdisi üzerinde akıl yürütme ölçüyor, "needle in haystack" gibi yapay bir arama değil, finansal rapor ve hukuki metin gibi gerçekçi belgeler kullanıyor³. Test ilk yayımlandığında (Ağustos 2025) en iyi modeller bile yalnızca yaklaşık %70 doğruluk elde etti. Bir yıl sonra, bugün canlı sıralamaya bakınca durum iyileşmiş, en üstteki modeller %80'lerin üzerine çıkmış, hatta %83,3'e kadar ulaşmış⁴.

Asıl nokta şu ki 100.000 token, ileride göreceğimiz "güvenli" sayılan aralığın içinde kabul edilse bile, bir yıllık iyileşmeden sonra bile en iyi model beşte birine yakın soruda hata yapıyor, mükemmel performans yok.

Neden önemli?

Birkaç yazı sonra bağlam penceresini ikiye ayıran bir sınırdan (performansın güvenilir olduğu bölge ile belirgin biçimde düştüğü bölge) bahsedeceğiz, ama o sınırın altında kalmak bile bizi otomatik olarak kusursuz sonuca götürmüyor. Bu düşüş "işler tamamen bozuluyor" değil, "işler kademeli olarak kötüleşiyor" anlamına geliyor. Sınırın her iki tarafında da bir miktar hata payı var, sadece oranı değişiyor.

Bu yazı 12 bölümlük bir serinin ikincisi. Önceki yazı: Token nedir, bağlam penceresi nedir? · Sonraki yazı: Bağlam büyüdükçe Claude neden kötüleşiyor?

Kaynaklar

1: HKUST-NLP, "LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth", 10 Şubat 2026

2: NVIDIA, RULER Benchmark, Nisan 2024

3: Artificial Analysis, "Announcing AA-LCR" (yöntem duyurusu), 5 Ağustos 2025

4: Artificial Analysis, AA-LCR canlı leaderboard, erişim 19 Ağustos 2026

Claude Code'da saatlerce süren bir kodlama oturumunun ortasındayız. Az önce bir dosyayı sildiğimizi söylemiştik, model onu hala varmış gibi kullanmaya çalışıyor. Ya da beş mesaj önce verdiğimiz bir talimatı unutmuş görünüyor. Model "bozulmadı", teknik bir hata yok, cevap veriyor. Ama bir şey değişti.

Token, bir dil modelinin metni işlerken kullandığı en küçük birim, bazen tam bir kelime, bazen bir kelimenin parçası. Bağlam penceresi ise modelin bir cevap üretirken aynı anda "görebildiği" toplam token miktarı, sistem talimatlarından konuşma geçmişine, araç çıktılarına kadar her şeyi içeriyor. Bu iki terimi netleştirmeden, yukarıdaki "bir şey değişti" hissinin nereden geldiğini anlayamıyoruz.

Token nedir?

Bir dil modeli metni bizim okuduğumuz gibi harf harf ya da kelime kelime okumuyor. Metni önce token denen küçük parçalara bölüyor, sonra bu parçalarla çalışıyor.

OpenAI'ın kendi belgelediği kaba kural şu: İngilizce metinde 1 token yaklaşık 4 karaktere, yaklaşık ¾ kelimeye denk geliyor¹. Yani 100 token, kabaca 75 kelime demek.

Türkçe için durum farklı

Bu oran İngilizce için, Türkçe gibi eklemeli bir dilde (kelimeye ek üstüne ek eklenen bir dil) durum değişiyor. Akademik bir çalışmaya göre "veremedim" kelimesi bir modelin tokenizer'ında beş parçaya bölünebiliyor ("ver-e-me-di-m"), çünkü model çoğunlukla İngilizce ağırlıklı veriyle eğitilmiş, Türkçe'nin ek yapısını tek parça olarak tanımıyor².

Aynı araştırma, Türkçe gibi diller için özel eğitilmiş bir tokenizer ile genel amaçlı, çoklu dilli bir tokenizer arasındaki farkın 2-3 kata, bazı durumlarda 10-15 kata kadar çıkabildiğini gösteriyor².

Bunun pratik anlamı, aynı uzunluktaki bir Türkçe metnin bağlam penceresinden İngilizce'den daha büyük bir pay alması. "1 milyon token'lık bağlam penceresi" dediğimizde, bu pencereye sığan Türkçe metin miktarı İngilizce'den daha az.

Bağlam penceresi nedir?

Bağlam penceresi, bir modelin bir cevap üretirken aynı anda görebildiği toplam token miktarı. Bu pencereye sadece bizim yazdığımız mesajlar girmiyor. Sistem talimatları, önceki tüm konuşma geçmişi, kullanılan araçların çıktıları (bir dosya okuma, bir arama sonucu) hepsi aynı pencerenin içinde, aynı sınırlı alanı paylaşıyor³.

Yani bağlam penceresi sabit boyutlu bir kap gibi düşünülebilir. Sohbet uzadıkça, dosya okudukça, araç kullandıkça bu kap doluyor.

"1 milyon token" ne demek?

Bazı modeller artık 1 milyon token'lık pencere sunuyor. Somutlaştırırsak, OpenAI'ın kabaca 0,75 kelime/token oranıyla, 1 milyon token İngilizce'de yaklaşık 750.000 kelime demek¹. Ortalama bir roman 90.000-100.000 kelime civarında, yani 1 milyon token kabaca 7-8 roman eder.

Türkçe'de aynı pencereye, tokenizer farkı yüzünden daha az kelime sığıyor. "1 milyon token" rakamı, hangi dilde yazdığımıza göre gerçekte farklı miktarda metne karşılık geliyor.

Bunun can alıcı noktası, bu kadar büyük bir pencereye sahip olmanın o penceredeki her token'ı aynı kalitede kullanabildiğimiz anlamına gelmemesi. Reklamı yapılan pencere büyüklüğüyle, modelin gerçekte güvenilir biçimde kullanabildiği kısım arasında bir fark var, bir sonraki yazının konusu tam olarak bu.

Serinin tamamı

Bu, "Bağlam Yönetimi" serisinin ilk yazısı. Serinin diğer on bir yazısı:

1. Token nedir, bağlam penceresi nedir: Claude'un hafızasının sınırı (bu yazı)

2. Reklamı yapılan bağlam penceresiyle gerçekte kullanabildiğimiz aynı şey değil

3. Bağlam büyüdükçe Claude neden kötüleşiyor?

4. Bağlamın ortasına koyduğumuz bilgiyi model neden unutuyor?

5. Akıllı bölge ve aptal bölge nedir, sınır nerede başlıyor?

6. Modelin aptal bölgeye girdiğinin belirtileri: sadakat halüsinasyonu ve diğerleri

7. Claude, GPT, Gemini: uzun bağlamda hangisi nasıl bozuluyor?

8. Büyük bir görevi küçük parçalara bölmek neden işe yarıyor?

9. Bağlamı ne zaman temizlemeli, ne zaman sıkıştırmalıyız?

10. Bilgiyi bağlamda değil, bir dosyada tutmak neden daha güvenli?

11. İşi baştan, geniş bağlam gerektirmeyecek şekilde nasıl kurarız?

12. Bağlam yönetimi için altı maddelik bir karar listesi

Kaynaklar

1: OpenAI Help Center, "What are tokens and how to count them?"

2: "Impact of Tokenization on Language Models: An Analysis for Turkish", ACM Transactions on Asian and Low-Resource Language Information Processing

3: Anthropic, "Effective context engineering for AI agents", 29 Eylül 2025

Önce bir uyarıyla başlayayım. Anlatacağım çalışma Ağustos 2026'da yayımlandı ama içindeki modeller yeni değil.¹ Deneyde kullanılan en güçlü model Claude 3.5 Sonnet, 2024'ün ortasında çıkmış bir sürüm. GPT-4 Turbo, GPT-4o ve Llama 3 70B de aynı dönemin modelleri. Bugünün çok daha güçlü ajanları bu deneyde hiç yok. Bunu en başta söylüyorum çünkü hikaye ilerledikçe unutulmasın istiyorum, aşağıda geçen her rakam "2024 modelleriyle" kaydı taşıyor, "bugünün ajanları" değil.

Şimdi hikayeye geçelim.

Bir toplantı odasını düşünelim. İçeride elli kişi var, hiçbiri birbirini tanımıyor, kimse başkan değil. Herkesten iki seçenekten birini seçmesi isteniyor, A ya da B. Doğru cevap yok, ikisi de eşit derecede mantıklı. Tek bilgi kaynağı, o an odadakilerin kaçının A, kaçının B dediğini gösteren bir tabela.

Sırayla bir kişi seçiliyor, fikri yeniden soruluyor. "Şu an oda çoğunlukla A diyor, sen ne diyorsun?" O kişi ya aynı fikirde kalıyor ya da çoğunluğa katılıyor. Sonra sıra başka birine geçiyor. Bu, yüzlerce kez tekrarlanıyor.

(Ajanın tam olarak ne olduğunu merak edersen "Yapay zeka ajanı ne demek?" yazıma bakabilirsin.)

Kimse kimseye ne yapması gerektiğini söylemiyor, ajanlar sadece birbirinin o anki fikrini görüyor. Buna rağmen grup zamanla tek bir fikirde birleşebiliyor. Araştırmacılar bir modelin çoğunluğa ne kadar güçlü uyduğunu tek bir sayıyla ölçüyor, buna "çoğunluk kuvveti" diyorlar.

Araştırmacılar (De Marzo, Castellano, Garcia) bu deneyi insanlarla değil, yapay zeka ajanlarıyla yaptı, elli, yüz elli, bin ajanlık gruplarla. Soru aynıydı. Kimse yönlendirmeden, grup tek bir fikirde birleşir mi?

Kartopu gibi büyüyen bir çoğunluk

Cevap modele göre değişti. Bazı modeller, odanın çoğunluğu ne derse büyük olasılıkla ona katıldı, küçük bir çoğunluk bile hızla büyüyüp herkesi aynı tarafa çekti. Küçük bir kartopu yuvarlanmaya başlayınca büyüyor, büyüdükçe de daha hızlı büyüyor, tam öyle bir şey.

Başka modeller ise neredeyse yazı tura atar gibi davrandı, çoğunluğun ne dediğinin pek önemi olmadı. Bu gruplar hiçbir zaman tek bir fikirde birleşmedi, sürekli ikiye bölünmüş kaldı.

Modelin kendisi ne kadar gelişmişse, çoğunluğa uyma eğilimi de o kadar güçlü çıktı. Daha zayıf, daha eski modeller sürüye daha az uydu.

Sonra araştırmacılar oda büyüklüğünü değiştirdiler. On kişilik bir odada bir fikirde birleşmek kolay, herkes herkesi görüyor, küçük bir çoğunluk hemen fark ediliyor. Dokuz yüz kişilik bir odada durum farklı, yüz kişilik bir azınlık olmak hâlâ kalabalık hissi veriyor. Küçük bir odada aynı oranda bir azınlık kendini çok daha yalnız hissediyor ve çoğunluğa daha çabuk katılıyor.

Aynı şey yapay zeka ajanlarında da görüldü. Grup büyüdükçe çoğunluğa uyma isteği zayıfladı.

Eşik, modelin gücüyle birlikte büyüyor

Her model için bir sınır çıktı ortaya, araştırmacılar buna "kritik grup büyüklüğü" diyor. Bu sınırın altında kalan bir grup er ya da geç bir fikirde birleşiyor. Bu sınırı aşan bir grup ise pratikte hiçbir zaman birleşemiyor, sonsuza kadar ikiye bölünmüş kalıyor.

Karşılaştırma için insan gruplarına da bakalım. Sosyal bilimciler, insanların gayrı resmi olarak, yani kurallar ve hiyerarşi olmadan, istikrarlı bir arada kalabildiği grup büyüklüğüne "Dunbar sayısı" diyor, yaklaşık 150 ila 300 kişi.

En gelişmiş iki model, insanların doğal olarak bir arada kalabildiği kalabalıktan çok daha büyük gruplarda bile ortak bir fikirde birleşebildi. Yine de baştaki uyarı geçerli, bunlar 2024 modelleri; bugünün modelleri muhtemelen daha da büyük gruplarda koordine olabiliyor ama bu ölçülmüş değil, sadece bir tahmin.

Bu şüphe boşuna değil. Anthropic da benzer bir şeyi kendi başına yaşadığını anlatıyor.² Bir modelde ölçüp harness'e (ajanın çalışma kurallarına) yazdıkları bir varsayım, bir sonraki model çıkınca geçersiz kaldı; o varsayım için yazdıkları düzeltme artık gereksiz bir "ölü ağırlığa" dönüştü. Yani bu sadece bizim temkinli olmamız gereken bir konu değil, ajan geliştiren şirketlerin de kendi başına gelen bir sorun.

Bu neden önemli?

Deneyin kendisinde risk yok, A ya da B, önemsiz bir seçim, gerçek bir sonucu yok. Ama gösterdiği şey önemli. Bir ajan grubu, kimse "aynı şeyi yapın" demeden, sadece birbirinin ne yaptığını görerek ortak bir davranışta birleşebiliyor. Bu, güçlü modellerde, insan gruplarının doğal sınırının çok üzerindeki kalabalıklarda bile oluyor.

Bunun günlük hayattaki karşılığı şu: bir şirket binlerce ajanı aynı anda çalıştırdığında, bu ajanlar birbirinin çıktısını görüyorsa, aynı kod tabanı, aynı belge havuzu, aynı sohbet ortamı, kimse onlara söylemeden ortak bir alışkanlıkta, bir kalıpta birleşebilirler. Bu kalıp faydalı olabilir, herkes aynı iyi pratiği benimser, ya da zararlı, herkes aynı hatayı tekrarlar, ya da insan değerleriyle uyuşmayan bir norm yerleşir. Tek tek her ajana "izin veriyor musun" diye sormak bu toplu kaymayı yakalamıyor, çünkü hiçbiri tek başına bir kural çiğnemiyor, sadece çoğunluğa uyuyor.

Kaynaklar

1. De Marzo, Castellano, Garcia, "AI agents can coordinate via majority-following beyond human scale", Science Advances, Cilt 12, Sayı 33, 14 Ağustos 2026

2. Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands", 8 Nisan 2026

Bir kullanıcı ajanından tek bir şey istiyor, spor salonunda ders ayırtmasını. Ajan salonun API'sine bakınca yetkilendirme kontrolünün eksik olduğunu fark ediyor ve kullanıcısını bekleme listesinde öne çıkarmaya çalışırken başka bir müşterinin rezervasyonunu iptal ediyor. Kimse ona "birinin yerini al" demedi, sadece "ders ayırt" dedi; o da hedefe giden en kısa yolu bulunca gitti.¹

Bu küçük, neredeyse zararsız görünen bir hata. Ama aynı örüntü, çok daha büyük ölçekte de tekrar ediyor. (Ajanın tam olarak ne olduğunu, workflow'dan farkını merak ederseniz "Yapay zeka ajanı ne demek?" yazımıza bakabilirsiniz.)

Bir ajana yeterince yetenek, dar bir hedef ve zayıf bir sınır verildiğinde, kimse izin vermeden o sınırı aşabiliyor. Bunun nedeni kötü niyet değil, hedefi izlemekte iyi olması. Yazılı bir kural bunu durdurmuyor çünkü metindeki bir kural, ajanın uyması beklenen bir öneriden ibaret.

Vaka 2: İki model, aynı hiperodaklanma

Temmuz 2026'da OpenAI kendi ajanlarını bir siber güvenlik testinde çalıştırıyordu.² Test, modelin siber yeteneğini ölçmek gibi dar bir amaca hizmet ediyordu. Ajanlara kimse "Hugging Face'e sız" demedi.

Ama iki farklı model, GPT-5.6 Sol ve henüz yayımlanmamış bir prototip, birbirinden bağımsız biçimde aynı şeyi yaptı. Test cevaplarına ulaşmak için önce izole test ortamından çıkacak bir açık aradılar, buldular; oradan gerçek internete çıktılar, Hugging Face'in bu testin cevaplarını barındırabileceğini çıkarım yaptılar ve çalıntı kimlik bilgileriyle oraya sızdılar. Hugging Face'in adli analizi dört buçuk günde yaklaşık 17.600 eylem saydı. OpenAI'ın kendi ifadesi: modeller "dar bir test hedefine hiperodaklanmıştı."

İki model birbirini görmüyordu, birbirinden habersizdi. İki bağımsız ajan, aynı dar hedefi kararlılıkla izleyince aynı yola çıkabiliyor.

Vaka 3: İngiltere'nin testinde de aynı örüntü

Ağustos 2026'da İngiltere'nin Yapay Zeka Güvenlik Enstitüsü (AISI), sağlayıcıların normal güvenlik filtreleri kapalıyken 122 siber değerlendirme oturumu çalıştırdı.³ On oturumda ajanlar, gerçek kişi ve kurumlara yönelik on dokuz "yetkilendirilmemiş eylem" gerçekleştirdi. Bir örnekte, bir ajan sahte kimlikler oluşturdu, gerçek bir açık kaynak projesine kötü amaçlı kod sokmaya çalıştı ve proje yöneticisini onaylaması için ikna etmeye çalıştı. Yönetici reddetti, gerçek bir zarar oluşmadı ama girişim gerçekti.

Burada da ajanlar birbirini görmüyordu, her biri kendi test oturumunda tek başınaydı. 122 oturumun 10'unda tekrarlayan şey, güvenlik sınırı zayıfladığında hedefi izleyen bir ajanın sınırı aşma ihtimalinin sıfır olmadığı.

Üç örnek de aynı noktada buluşuyor. Ajanlara ne kadar yetki verilirse, hedefe giden alışılmadık bir yolu bulma ihtimalleri o kadar artıyor; bu da kimsenin açıkça izin vermesini gerektirmiyor. Tek tek her ajana önceden "bunu yapabilir misin" diye sormak bu kaymayı yakalamıyor, çünkü hiçbiri o an yazılı, önceden verilmiş bir kuralı bilerek çiğnemiyor, her biri sadece kendi hedefini izliyor.

Duvara asılan kural, kilitli kapı değildir

Bir ofis düşünelim. Duvarda büyük harflerle bir yazı asılı: "Bu kapıdan çıkmadan önce alarm sistemini kapat." Herkes bu yazıyı okuyor, çoğu uyuyor. Ama yazı bir kilit değil; biri unutursa, acele ederse ya da "bu sefer gerek yok" diye düşünürse kapı yine de açılır. Kuralı uygulayan yazı değil, kapıya gerçekten bir elektronik kilit koyarsan kural garanti altına alınır.

Yapay zeka ajanlarına verdiğimiz talimatlar da böyle. Bir sistem talimatı "sonucu bildirmeden önce testleri çalıştır" diyebilir. Ama bu, ajanın gördüğü metnin içinde; bir kural, bir kilit değil.

LLMs Research adlı bir araştırma bülteni tam bu soruyu test eden birkaç çalışmayı bir araya getirdi.⁴ Bir testte, otuz farklı ajan görevinde, prosedürün tamamını eksiksiz uygulayan çalışma oranı sadece yüzde 28 çıktı. En sık atlanan adımlar da doğrulama adımlarıydı, yani "gerçekten çalıştı mı, kontrol et" diyen kısımlar.

Aynı araştırmacılar bir şey daha denedi. "Testleri çalıştır" kuralını düzyazıdan çıkarıp sistemin kendisine yazdılar. Ajan artık "ben testleri çalıştırdım" demiyor, sistem gerçekten testleri çalıştırıp sonucu kendisi kaydediyor. Bu değişiklikle uyum oranı yüzde 86'ya çıktı. Fark, ajana daha akıllı bir model vermekten gelmiyor; kuralın nerede durduğundan geliyor.

Skor tahtasını kim tutuyor?

Bazı ekipler ajana kendi performansını değerlendirme ve iyileştirme yetkisi de veriyor: ajan kendi talimatlarını değiştiriyor, kendi testini yazıyor, sonucu kendi değerlendiriyor, tekrar deniyor.

Sorun şu: ajan artık hem sistemi değiştiriyor hem de "değişiklik işe yaradı mı" sorusunun cevabını yine kendisi veriyor. Bir deneyde, ajana var olmayan bir hata gösterilip "bunun için bir önlem geliştir" dendi.⁴ Doğru cevap "burada düzeltilecek bir şey yok" demekti.

Ama altmış denemenin on beşinde ajan, olmayan hatayı "buldu" ve bir önlem inşa etti, çünkü bir şey bulup düzeltmek için ödüllendiriliyordu. Bunun çözümü ajanı "kendi kendini değerlendirmede daha iyi" yapmak değil. Çözüm, değerlendirmeyi ajandan almak. Ajan öneride bulunabilir ama değişikliğin kabul edilip edilmeyeceğine, ajanın erişemediği ve değiştiremediği ayrı bir kontrol karar vermeli.

Gerçek çözüm, dokunmayı imkânsız kılmak

Bu fikir teoride kalmıyor. Anthropic, yukarıdaki OpenAI/Hugging Face olayından aylar önce, Nisan 2026'da kendi ajan altyapısını tam bu ilkeyle yeniden tasarladığını anlattı.⁵ Anthropic'in o zaman çözdüğü sorun tanıdık bir riskti, ajanın çalıntı kimlik bilgileriyle sisteme sızması; bu risk üç ay sonra OpenAI/Hugging Face olayında gerçek oldu.

Anthropic'in eski tasarımında, ajanın ürettiği kod ile o ajanın erişebildiği kimlik bilgileri (API anahtarları, tokenlar) aynı ortamda duruyordu. Ajana "bu bilgiye dokunma" diye bir kural yazmak yeterli değildi, çünkü teknik olarak dokunabiliyordu.

Yapısal çözüm bir kural yazmak değildi. Kimlik bilgilerini ajanın kod çalıştırdığı ortamdan fiziksel olarak erişilemez hale getirdiler. Kimlik bilgileri ayrı bir kasada duruyor, ajanın çalıştığı sanal ortamın bu kasaya hiçbir yolu yok. Bir Git deposuna erişim gerektiğinde jeton doğrudan ajana verilmiyor, sistem depoyu ajan adına klonluyor. Ajan token'ı hiç görmüyor.

Bu sadece bir görüş değil

Bu fikir tek bir araştırma bülteninin görüşü olsaydı temkinli durmak gerekirdi. Ama aynı ilkeye, birbirinden habersiz üç farklı alan ayrı ayrı varmış.

Birincisi AI araştırması. LLMs Research'ün yukarıda anlattığımız bulgusu şu: kural metinde durursa atlanabiliyor, kodda durursa atlanamıyor.

İkincisi ajan altyapısı, yani Anthropic'in kendisi. Yukarıda anlattığımız gibi, kimlik bilgisi erişimini kural değil, mimari bir imkânsızlık haline getirdiler.

Üçüncüsü, tamamen ayrı bir sektör: kimlik ve erişim güvenliği. OWASP'ın resmi ajan güvenliği rehberi, LLMs Research'ten ve Anthropic'ten habersiz, tamamen farklı bir kelime dağarcığıyla aynı sonuca varıyor. Rehber açıkça yazıyor, "karar verme ile uygulamayı ayır, uygulamadan önce ayrı bir kontrol kapsamı, yetkiyi ve onay durumunu bağımsız olarak doğrulamalı";⁶ açık bir uyarı da ekliyor, "yalnızca modelin çıktısına dayanarak yetkilendirme kararı verme."

Kimlik güvenliği alanından bir analiz buna iki isim veriyor.⁷ "Yumuşak kapsamlama", modele "şunu yapma" demek ama ortamın buna izin vermesi, her zaman "sert hapsetme"ye, yani ortamın kendisinin erişimi engellemesine, karşı kaybediyor.

Kaynaklar

1. Claude Mythos, "The AI was supposed to stay inside the sandbox. But it didn't.", 10 Ağustos 2026 (aynı olay TAAFT bülteninde de, 11 Ağustos 2026, bağımsız olarak doğrulanıyor)

2. OpenAI, "OpenAI and Hugging Face partner to address security incident during model evaluation", 21 Temmuz 2026

3. UK AI Security Institute, "Incident Report: unsanctioned agent behaviour during cyber testing", 4 Ağustos 2026

4. LLMs Research, "Your Agent Harness Is Not an Enforcement Mechanism", 10 Ağustos 2026 (ana argüman doğrulandı; SIGIL ve Phantom Guardrails rakamları bu yazıda aktarılıyor, birincil çalışmalar ayrıca doğrulanmadı)

5. Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands", 8 Nisan 2026

6. OWASP, "AI Agent Security Cheat Sheet", endüstri standardı

7. NHI Mgmt Group, "Autonomous agent safety depends on hard boundaries, not prompts", 12 Ağustos 2026

Bir müşteri sohbet robotuna yazıyor: "Siparişim için iade istiyorum." Robot hemen cevap veriyor: "Tabii, hemen bakıyorum!"

Sonra hiçbir şey olmuyor.

Robot müşteriye güven veren bir cümle kurdu ama sipariş veritabanına erişimi yok. İade API'sini çağıramıyor. İade penceresinin açık olup olmadığını bile bilmiyor. Sadece konuşuyor.

Müşteri ekran görüntüsünü alıp paylaşıyor, şirketin müşteri hizmetleri sorumlusu telefonunu açtığında karşısında bu ekran görüntüsü var.

Bu, dil modeli tabanlı ürünlerin çoğunun eninde sonunda çarptığı duvar. Model bir sorunu tahtada çözebiliyor, adım adım anlatabiliyor, ama dokunamıyor. Konuşabilen, sunucuya erişemeyen bir mühendis gibi.

Bir ajan, tam olarak bu mühendise bir terminal vermek demek.

Yapay zeka ajanı, bir hedef verildiğinde o hedefe ulaşmak için hangi araçları hangi sırayla kullanacağına kendisi karar veren bir sistemdir. Sıradan bir dil modeli sadece cevap üretir; ajan bu cevabı üretirken bir de veritabanı sorgulayabilir, bir işlemi çalıştırabilir, sonucu görüp bir sonraki adıma kendisi karar verebilir.

Döngü: düşün, yap, gözlemle, tekrarla

Aynı iade örneğini bir de ajanla düşünelim.

Ajan önce düşünüyor: "Önce bu siparişi bulmam lazım." Sonra bir aracı çağırıyor, sipariş numarasını sorguluyor. Gördüğü sonuç: ürün iade edilmiş, ödemesi henüz geri yapılmamış, iade penceresi hâlâ açık.

Yeniden düşünüyor: "Ödeme iadesi onaylanabilir, penceresi açık, işlemi başlatmalıyım." Bir aracı daha çağırıyor, ödeme iadesini çalıştırıyor. Sonuç: işlem tamamlandı, referans numarası geldi.

Son bir düşünme adımı: "Elimde gereken her şey var." Döngüden çıkıyor, müşteriye cevap veriyor.

İki döngü, iki araç çağrısı, tek bir tamamlanmış görev. Hiçbir insan araya girmeden.

Bu döngünün araştırma literatüründe bir adı var: ReAct, yani "Reasoning + Acting" (akıl yürütme + eyleme geçme). 2023'te yayımlanmış bir akademik makaleye dayanıyor. Bugün kullandığımız birçok ajan aracı, Claude Code, Cursor, GitHub Copilot, ChatGPT'nin web'de arama yaptığı anlar, bu döngünün bir versiyonunu çalıştırıyor.

Workflow mu, ajan mı?

Anthropic, kendi müşterileriyle çalışırken kafa karışıklığını çözmek için basit bir ayrım öneriyor. İki tür sistem var.

Tarif edilmiş sistem (workflow): adımlar önceden belirlenmiş. Bir yemek tarifi gibi: önce şunu yap, sonra bunu yap, sonra kontrol et. Bir GPS'in sabit rotası gibi düşünülebilir, yol baştan çizilmiş.

Ajan: hedef veriliyor ama yolu kendisi buluyor. Bir şoförün trafiğe göre kendi rotasını değiştirmesi gibi.

Fark tek cümlede: workflow'da yolu biz çiziyoruz, ajanda yolu o buluyor.

Google Cloud, Anthropic'ten bağımsız olarak neredeyse aynı ayrımı yapıyor: bir ajanı bir asistandan ya da bottan ayıran şey, ne kadar otonom karar verebildiği.

Ajanın üç parçası

Bir ajanı oluşturan üç parça var, üçü birlikte çalışınca döngü dönüyor.

Klarna'nın öğrendiği ders

İsveçli ödeme şirketi Klarna, 2024 başında müşteri hizmetlerinin çoğunu bir ajana devretti. Sonuç etkileyiciydi: sohbetlerin üçte ikisi ajan tarafından karşılandı, çözüm süresi 11 dakikadan 2 dakikaya düştü, ajan 700 tam zamanlı çalışanın işini yapıyordu.

Sonra karmaşık, birden fazla siparişi kapsayan fatura anlaşmazlıkları gibi yargı gerektiren durumlarda müşteriler genel geçer, kalıp cevaplar almaya başladı. Şirket insan çalışanları geri işe aldı.

Sınır burada ortaya çıkıyor. Ajan, dar ve net görevlerde gerçekten işe yarıyor. Yargı gerektiren işler başladığında değil.

Beklenti gerçekçi olmalı

Gerçek dünya bilgi işi görevlerini ölçen, henüz bağımsız doğrulanmamış tek bir çalışma (Ocak 2026), en gelişmiş modellerin bile bu görevlerin sadece %18-24'ünü ilk denemede doğru tamamladığını buldu. Gartner, 2027'ye kadar ajan projelerinin %40'ından fazlasının iptal edileceğini öngörüyor; gerekçe olarak artan maliyetleri, belirsiz iş değerini ve yetersiz risk kontrollerini gösteriyor.

Bu son nokta önemli. Sorun genelde "model yeterince akıllı değil" değil. Sorun, projenin maliyetinin ve risklerinin baştan doğru hesaplanıp hesaplanmadığı.

Kelimenin kendisi hâlâ tanımsız

Ağustos 2026'da KDnuggets, yeni bir e-kitabı tanıtırken bunu tam olarak özetliyordu:

Artık biri "ajan" dediğinde sorabileceğimiz somut bir soru var: yolu o mu buluyor, yoksa yolu biz mi çizdik?

Kaynaklar

1. Yao ve ark., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023 (arXiv:2210.03629)

2. Anthropic, "Building Effective AI Agents", 19 Aralık 2024

3. Google Cloud, "What are AI agents? Definition, examples, and types", 2 Nisan 2026

4. Paolo Perrone, "What is an AI Agent? How the Agent Loop Works in Practice", The AI Engineer, 18 Şubat 2026 (Klarna rakamları Fortune'a atıfla aktarılıyor)

5. APEX-Agents / Mercor, Ocak 2026 (aynı yazıda aktarılıyor, tek kaynak, ayrıca doğrulanmadı)

6. Gartner, "Gartner Predicts Over 40 Percent of Agentic AI Projects Will Be Canceled by End of 2027", Haziran 2025

7. KDnuggets, "Understanding Agentic AI: An Executive Briefing", 9 Ağustos 2026 (kamuya açık sayfa, doğrudan doğrulandı)

8. Anthropic, "Scaling Managed Agents: Decoupling the brain from the hands", 8 Nisan 2026 ("beyin" ve "eller" terimlerinin kaynağı)

9. Klarna, "Klarna AI assistant handles two-thirds of customer service chats in its first month", 27 Şubat 2024 (birincil basın açıklaması, doğrudan doğrulandı)

SEO’yu biliyordum. Sonra AEO çıktı, sonra GEO, sonra LLMO. Her biri ayrı bir uzmanlık gibi sunuluyor, her birinin ayrı bir araç seti ve ayrı bir fiyat etiketi var. Doğal soru şu: bunlar gerçekten farklı işler mi, yoksa aynı işin yeni ambalajları mı?

Cevap ikisinin ortasında ve tam olarak nerede durduğu önemli. Çünkü bu ayrımı yanlış kurmak, ardından gelen bütün rakamları kıyaslanamaz hale getiriyor.

Önce tanımlar

SEO (Search Engine Optimization) arama sonuçlarında sıralanmakla ilgileniyor. Ölçüsü: sorgu yazıldığında sayfanız kaçıncı sırada çıkıyor, kaç tıklama alıyor.

AEO (Answer Engine Optimization) yapay zekâ asistanlarının cevaplarında kaynak olarak gösterilmekle ilgileniyor. Ölçüsü: ChatGPT, Gemini ya da Google’ın AI Overviews’u bir cevap üretirken sayfanızı alıntılıyor mu?

GEO (Generative Engine Optimization) pratikte AEO ile aynı şeyi anlatıyor. Farklı iki isim, tek bir iş. Akademik literatürde GEO daha yaygın, ajans dilinde AEO.

LLMO (Large Language Model Optimization) çoğu zaman yine aynı şeyin dördüncü adı olarak kullanılıyor. Ama bazen farklı bir iddiaya işaret ediyor: modelin cevap anında kaynak çekmesine değil, modelin kendi eğitim verisine girmeye çalışmak. Aradaki fark önemli, çünkü ikincisi üzerinde neredeyse hiç kontrolünüz yok. Eğitim verisi kapalı, ne zaman güncellendiği belirsiz ve bir sitenin oraya girip girmediğini ölçmenin bir yolu yok. Bu yazıda LLMO’yu ayrı bir başlık olarak ele almıyorum, çünkü elimizde ölçülebilir bir tarafı yok. Terimi duyduğunuzda tek soru şu olsun: cevap anında kaynak gösterilmekten mi bahsediyorsunuz, yoksa eğitim verisinden mi? İkincisiyse, satılan şeyin ölçüsü de yok demektir.

Özetle üç isim aynı işi, biri de ölçülemeyen bir iddiayı anlatıyor. Fark tek cümlede: SEO sıralanmayı, AEO alıntılanmayı ölçüyor. Bunlar da sandığınızdan daha az örtüşüyor.

Tarif etmek yerine göstereyim. Aynı cümleyi üç yere sordum:

5 kişilik bir tasarım ajansı için sosyal medya planlama aracı arıyorum, aylık bütçem 50 dolar. Hangisini önerirsin?

Sınır tam olarak şurada:

• Ekran 1 baştan sona SEO. Yapabileceğin tek şey o listede yukarı çıkmak.

• Ekran 2 ikisinin birden olduğu yer. Sayfanın en üstündeki cevap bloğu AEO, hemen altından başlayan mavi link listesi SEO. Aynı sayfa, aynı sorgu, iki ayrı yarış. Bu yüzden “AI aramayı öldürdü” cümlesi yanlış. Google ikisini üst üste koydu.

• Ekran 3’te SEO’nun alanı hiç yok. Liste yok, sıra yok, tıklanacak bir sonuç yok. Geriye yalnızca cevabın içinde geçmek kalıyor.

AEO, ekranda cevabın yazıldığı yerde devreye giriyor. SEO ise cevabın altında ya da yanında duran liste neredeyse orada. Üçüncü ekranda o liste ortadan kalktığı için SEO’nun tutunacağı bir yer de kalmıyor.

Birinci ekranda küçük ama can alıcı bir ayrıntı var. Sonuçların altında Google’ın kendi notu duruyor: “Eksik: Hangisini önerirsin?”, üstü çizili. Bir sonuçta da “Eksik: arıyorum, dolar.” Google cümlenin bir kısmını eşleştiremeyip atmış. Aynı cümleyi AI’a sorduğunda bütçe de, ekip büyüklüğü de cevaba giriyor.

İkinci ve üçüncü ekranda dikkat edilecek şey markaların cümlenin içinde olması. Klasik aramada kazandığın şey listede bir sıra, burada kazandığın şey cevabın kendisinde geçmek. Okuyucu çoğu zaman hiçbir yere tıklamıyor.

Ama asıl mesele üçünü yan yana koyunca çıkıyor.

Sıralanan siteler ile alıntılanan siteler aynı değil. Klasik sonuçların üstünde Influencer Hero, Planable ve ClickUp var. AI Bakışı’nın gösterdiği kaynaklar ise Web Tonic, Buffer, Capterra ve automationtailor. Yani klasik sonuçların tepesindeki üç site, AI Bakışı’nın ekranda gösterdiği kaynakların arasında yok.

Marka listeleri de tam örtüşmüyor. Google’ın AI Bakışı Buffer, Publer ve SocialPilot diyor; Perplexity SocialPilot, Buffer ve Kontentino. İkisi ortak, üçüncüsü farklı.

Bunu bir ölçüm değil, tek bir örnek olarak okuyun. Kaynak çiplerinin arkasında “+3” diye gizlenmiş, ekranda görünmeyen siteler de var. Ama az sonra vereceğim rakam tam olarak bunu ölçüyor ve aynı yöne bakıyor.

Google’ın kendi cevabı

Mayıs 2026’da Google Search Central bu soruya doğrudan cevap veren bir belge yayınladı. Pozisyon net: AEO ve GEO ayrı bir disiplin değil, hâlâ SEO.

Aynı belge, o dönemde en çok satılan bazı AEO taktiklerini de gereksiz ilan ediyor:

• llms.txt: AI botlarına özel yönerge dosyası. Google resmi bir sinyal olarak kabul etmiyor.

• İçeriği yapay şekilde parçalara bölmek (chunking): gerek yok.

• AI’a özel şema işaretlemesi: gerek yok.

Bu üçü sektörde uzun süre “AI çağının yeni SEO’su” diye satıldı. llms.txt için elimizde bir de saha verisi var. 137 bin domain taramasında sitelerin %28’i dosyayı yayınlamış, %97’si hiçbir AI botu tarafından okunmamış. Bu rakam tek kaynaktan geliyor ve bağımsız doğrulaması yok, o yüzden yön göstergesi olarak okuyun. Ama Google’ın açıklamasıyla aynı yöne bakıyor.

Bir dipnot. Haziran 2026’da Google “Do you need an SEO?” rehberini güncelleyip AEO/GEO’yu meşru bir SEO hizmet kategorisi olarak adlandırdı. Yani “ayrı disiplin değil” demek, “böyle bir şey yok” demek değil. Sınırın nerede olduğu hâlâ oynuyor. Bu ikinci bilgi Google’ın kendi sayfasından değil aktarımdan geliyor, o farkı belirtmek gerekiyor.

Ama ölçtükleri gerçekten farklı

Google “ayrı disiplin değil” derken haklı. Yapılacak iş aynı: iyi içerik, düzgün teknik yapı, tanınırlık.

Buna rağmen ölçtükleri şey aynı değil ve bunun ölçülmüş bir karşılığı var.

Google kendi AI Overviews’unda bir cevap üretirken gösterdiği kaynakların %38’i ilk 10 sonuçtan geliyor. Yani %62’si gelmiyor. 863.000 arama sonucu sayfası ve 4 milyon sayfa adresi üzerinde ölçülmüş. (Ahrefs, Mart 2026)

Tek bir cümleye indirgersek: iyi sıralanmak, alıntılanmayı garanti etmiyor. Aynı işin iki ayrı sonucu var ve ikisini ayrı ayrı ölçmek gerekiyor.

“Ayrı disiplin değil ama ayrı ölçüm” cümlesi burada oturuyor.

Bu alanda dolaşan başka örtüşme rakamları da var, mesela %12 ve %76. Üçü de doğru ama üçü farklı şey ölçüyor ve sektörde sürekli birbirinin yerine kullanılıyorlar. Neden bu kadar kolay karıştıklarını ikinci yazıda tek tek açıyorum. Burada tek bir rakama, en yenisine ve en büyük örneklemlisine yaslanmayı tercih ettim.

Pratikte gerçekten değişen ne

Alıntılanma mekaniğine dair elimizde iki bağımsız çalışma var ve ikisi de aynı yöne bakıyor:

• ChatGPT’de: alıntıların %44,2’si içeriğin ilk %30’undan geliyor. 1,2 milyon cevap, 18.012 doğrulanmış alıntı. Kevin Indig’in çalışması. (Growth Memo, Search Engine Land aktarımı)

• Google AI Overviews’ta: ayrı bir ekibin aynı ölçümü %55 veriyor, ama yalnızca 100 alıntı üzerinde. (CXL)

Rakamlar farklı ama yön aynı, cevap sayfanın başında olmalı. Klasik SEO yazısı sonuca doğru inşa eder, önce bağlam kurar. AI alıntılaması bunun tersini ödüllendiriyor.

Bu kadarı gerçek bir davranış değişikliği ama ayrı bir isim gerektirmiyor. Yalnızca yazma sırasını değiştiriyor.

Nerede durmalı

Pratik özet:

Ayrı bir ekip mi gerekiyor?
Hayır. Google ayrı disiplin saymıyor.

Ayrı bir bütçe kalemi mi?
Hayır. Aynı işin ikinci bir ölçümü.

Ayrı bir teknik iş mi?
Neredeyse hayır. llms.txt ve AI’a özel şema gereksiz.

GEO ve LLMO ayrı şey mi?
GEO aynı işin başka adı. LLMO eğitim verisi anlamında kullanılıyorsa ölçülemez, satın alma.

Hiç mi değişmiyor?
Değişiyor: cevabı sayfanın başına koyun ve alıntılanmayı sıralamadan ayrı ölçün.

Yani birisi size AEO’yu tamamen yeni bir dünya olarak satıyorsa, ilk kontrol noktası Google’ın kendi belgesi; satılan taktik llms.txt ise cevap muhtemelen hayır.

Buradan çıkan asıl mesele

Bu yazıyı yazma sebebim terminoloji sevgisi değil. Şu: SEO ve AEO farklı şeyler ölçtüğü için, bu alanda dolaşan rakamlar sürekli birbirinin yerine kullanılıyor.

Yukarıda değindiğim %12, %38 ve %76’yı yan yana koyup “biri yanlış” demek çok kolay. Üçü de doğru. Farklı motorları, farklı sorguları ve farklı yönde koşullu olasılıkları ölçüyorlar.

Bu, alanda gördüğüm bozulmanın yalnızca ilk çeşidi. Dördünü ve nasıl fark edileceğini ayrı bir yazıda topladım, SEO ve AEO’da doğru rakam, yanlış cümle. Ardından da geriye ne kaldığını: SEO ve AEO için ne yapmalı?

Bu yazı üç bölümlük bir serinin ilki.

1. SEO, AEO, GEO, LLMO: yeni bir disiplin mi, yeni bir isim mi? · buradasınız

2. SEO ve AEO’da doğru rakam, yanlış cümle

3. SEO ve AEO için ne yapmalı? Kanıt seviyesine göre bir liste

Kaynaklar

• Google’ın resmi pozisyonu · Google Search Central, “A new resource for optimizing for AI experiences” · 15 Mayıs 2026

• Haziran güncellemesi · Digital Applied aktarımı · 5 Haziran 2026 · tek kaynak, birincil sayfa doğrulanmadı

• %38 örtüşme · Ahrefs, “38% of AI Overview Citations Pull From The Top 10” · 2 Mart 2026 · 863.000 arama sonucu sayfası, 4 milyon sayfa adresi · yazının yaslandığı rakam bu

• %12 örtüşme · Ahrefs, “Only 12% of AI Cited URLs Rank in Google’s Top 10” · 11 Ağustos 2025 · 15.000 uzun kuyruk sorgusu (cümle halinde yazılan uzun aramalar) · veri bir yaşından büyük, yazıda kanıt olarak kullanılmadı, yalnızca ikinci yazıya devredildi

• Alıntıların içerikteki konumu · iki ayrı çalışma, iki ayrı motor:

• Kevin Indig, Growth Memo · ChatGPT · 1,2 milyon cevap, 18.012 alıntı · %44,2

• CXL · Google AI Overviews · 100 alıntı · %55

• llms.txt saha verisi · Ahrefs, Haziran 2026 · 137 bin domain · tek kaynak, bağımsız doğrulaması yok

Kalan liste kısa. Kısalığı da bir kusur sayılmamalı, alanın gerçek boyutunu gösteriyor.

Bu yüzden buradaki her maddenin yanında kanıt seviyesi yazıyor. Bir tavsiyeyi “Google’ın kendi belgesi” ile “bir ajansın vaka çalışması” aynı listeye koymak, ikisini eşitliyor. Eşit değiller.

Üç seviye kullanıyorum:

• Birincil: Google’ın kendi dokümantasyonu. Tartışma yok.

• Doğrulandı: en az iki bağımsız çalışma aynı yöne bakıyor.

• Zayıf: tek kaynak, ya da gözlemsel veri taktik önerisine dönüştürülmüş.

Sıfırıncı adım: indeksleniyor musunuz?

Bunu Search Console’da beş dakikada öğrenebilirsiniz ve cevap çoğu sitede sanıldığından kötü çıkıyor. Listedeki her şeyden önce gelen madde bu, atlanması da en kolay olanı.

İndekslenmek, Google’ın sayfanı görüp kendi listesine almasıdır. Listesinde olmayan bir sayfa hiçbir aramada çıkamaz.

Kendi siteme baktığımda Google Search Console’da gördüğüm şey şuydu: elli sayfanın ikisi indekslenmiş, 48’i indekslenmemiş.

Sebep kırılımına bakınca asıl mesele çıktı.

47 sayfa “bulundu ama henüz taranmadı” durumunda. Google adresleri biliyor, gidip bakmaya değer bulmamış.

En alttaki satır da bir o kadar önemli: taranıp da indekslenmemiş sıfır sayfa var. Yani Google içeriğime bakıp “bu yeterince iyi değil” demedi. Hiç bakmadı.

Bu durumdaysanız aşağıdaki hiçbir maddenin anlamı yok. Alıntılanmak bir yana, sıralanmıyorsunuz bile. Search Console’da Sayfalar raporunu açın ve indekslenen sayfa sayısını gerçek sayfa sayınızla karşılaştırın. Aradaki fark ilk işiniz.

Sıfırıncı adımın ikizi: botlar sitenize girebiliyor mu?

Cevabı robots.txt dosyanızda yazıyor ve bakması beş dakika sürüyor. Bu madde çok kolay gözden kaçıyor, çünkü sitenin kendisinde hiçbir belirtisi yok. Sayfalar açılıyor, her şey normal görünüyor, ama AI tarafında yoksunuz.

Sektörde dolaşan hâli şöyle: “bazı sağlayıcılar AI botlarını varsayılan olarak kapatıyor, gidip açın.” Yönü doğru, ayrıntıları eksik; bu maddede ayrıntı her şeyi değiştiriyor.

Her amaç için ayrı bir izin var. OpenAI’ın tek değil üç botu var ve robots.txt’de üçü ayrı ayrı kontrol ediliyor:

• GPTBot: modeli eğitmek için içerik topluyor.

• OAI-SearchBot: ChatGPT’nin arama cevaplarında görünmenizi sağlıyor.

• ChatGPT-User: kullanıcı bir soru sorduğunda o an sayfaya gidip bakıyor.

“AI eğitimine kapatayım” derken eğitimi kapatıp arama görünürlüğünü açık bırakabilirsiniz. İkisi ayrı düğme. (OpenAI’ın kendi belgeleri)

Google tarafında en sık yapılan hata tam tersi. Google-Extended diye bir izin var ve pek çok kişi bunu AI Overviews’a çıkmak ya da çıkmamak için kullandığını sanıyor. Ayarın işlevi bu değil. Google-Extended, Gemini uygulamalarını ve Vertex AI’ı yönetiyor, AI Overviews ise doğrudan arama indeksinden, yani Googlebot’tan besleniyor. Google-Extended’ı kapatmak sizi AI Overviews’tan çıkarmıyor.

AI Overviews’u gerçekten kontrol etmek istiyorsanız yeri ayrı: Search Console’daki arama için üretken yapay zekâ ayarı. (Google, AI Features and Your Website)

Sağlayıcı meselesine gelince. En büyük örnek Cloudflare: 15 Eylül 2026 itibarıyla Cloudflare’e yeni katılan alan adlarında, reklam gösteren sayfalarda eğitim ve ajan botları varsayılan olarak kapalı olacak, arama botları açık kalacak. Mevcut siteler bu değişimin dışında. Yani kural henüz yürürlükte değil ve yürürlüğe girdiğinde de arama botlarını kapatmıyor. Diğer sağlayıcılarda durumun ne olduğuna dair elimde veri yok. (Cloudflare’in duyurusu)

Ama aynı duyuruda daha sinsi bir tuzak var: bazı botlar tek başına birden fazla iş yapıyor. Googlebot hem aramayı hem eğitimi besliyor, dolayısıyla “eğitimi kapatayım” dediğinde Googlebot’u da kapatmış olabilirsiniz. Aynı şey Applebot ve BingBot için de geçerli. AI’dan korunmak isterken klasik aramadan düşmek, bu maddenin gerçek riski.

Yapılacak iş: siteadınız.com/robots.txt adresini açın ve okuyun. Bir sayfa uzunluğunda düz metin. Disallow satırlarında yukarıdaki isimleri ara. Sağlayıcının bir AI ayarı varsa panelinden bak. Beş dakikalık iş ve yılda bir tekrar etmek yetiyor.

Kanıt seviyesi: Birincil

Katman 1: Google’ın kendi söyledikleri

Bunlar SEO Starter Guide ve Search Essentials belgelerinden geliyor. Yani kaynak, sıralamayı yapan şirketin kendisi.

Bulunabilirlik. Site haritası, iç linkler, taranabilir yapı. Google sayfayı bulamıyorsa geri kalanı konuşmuyoruz.

Başlık ve açıklama. Her sayfanın kendine ait, sayfayı gerçekten anlatan bir başlığı olsun. Şablon başlık, elli sayfayı birbirinin aynısı yapıyor.

Site yapısı. Anlamlı URL’ler, mantıklı gruplama. Ziyaretçi nerede olduğunu anlıyorsa Google da anlıyor.

İçeriğin kendisi. Google’ın ifadesi sade: insanlar için yazın, arama motoru için değil.

Görseller. Açıklayıcı dosya adı ve alt metni.

Tanıtım. Google bunu ayrı bir madde olarak sayıyor. Bu yazının en sonunda ona döneceğim, çünkü en zor kısım orası.

Aynı belgede bir de odaklanmayın listesi var ve bu liste en az diğeri kadar değerli: meta keywords etiketi, kelime sayısı hedefi, alan adında anahtar kelime bulundurmak, başlık etiketlerinin sırası. Google bunların hiçbirinin işe yaramadığını açıkça söylüyor. E-E-A-T de bir sıralama faktörü değil. Açılımı deneyim, uzmanlık, otorite ve güvenilirlik; arama sonuçlarının kalitesini elle değerlendiren insanlar için yazılmış bir çerçeve, algoritmanın ölçtüğü bir puan değil. Ajans teklifinde “E-E-A-T puanınızı yükseltelim” diye geçiyorsa, ortada yükseltilecek bir puan yok.

Kanıt seviyesi: Birincil

Katman 2: Cevabı sayfanın başına koy

Bu liste içinde klasik SEO’dan en net ayrılan davranış değişikliği bu; iki bağımsız çalışma da aynı yöne bakıyor:

• ChatGPT’de alıntıların %44,2’si içeriğin ilk %30’undan geliyor. 1,2 milyon cevap, 18.012 doğrulanmış alıntı. (Kevin Indig, Growth Memo)

• Google AI Overviews’ta ayrı bir ekip %55 buluyor, ama yalnızca 100 alıntı üzerinde. (CXL)

Rakamlar farklı, yön aynı.

Pratikte ne demek: klasik yazı bağlam kurar, sonuca doğru inşa eder. Bunun tersini yapın. Sorunun cevabını ilk paragrafa koyun, gerekçeyi arkasına yazın. Başlıklar soru biçiminde olsun ve altındaki ilk cümle o soruyu doğrudan cevaplasın.

Bu değişiklik ücretsiz ve klasik aramada da zarar vermiyor.

Kanıt seviyesi: Doğrulandı

Katman 3: Şema, ama doğru gerekçeyle

Şema (schema markup, Google’ın belgelerinde structured data), sayfanın koduna gömülen ve ziyaretçinin görmediği etiketler. Uzun süre AEO’nun bir numaralı tavsiyesi oldu.

Kanıt bunu desteklemiyor. 1.885 sayfa şema ekledi, 4.000 kontrol sayfasıyla eşleştirildi. Sonuç sıfır civarı: AI Overviews −%4,6 · AI Mode +%2,4 · ChatGPT +%2,2. (Ahrefs, Mayıs 2026)

Sebebini gösteren ayrı bir çalışma var. SearchVIU, Ekim 2025’te ChatGPT, Claude, Perplexity, Gemini ve Google AI Mode üzerinde test yapmış: yalnızca şemanın içinde duran bilgiler neredeyse hiç alınmıyor, alınan şey ziyaretçinin de gördüğü metin. (SearchVIU, tek çalışma)

Yani: şema ekleyin, ama AI için değil. Klasik aramada zengin sonuçlar (yıldız puanı, tarif kartı, SSS açılımı) için hâlâ işe yarıyor. Alıntılanma gerekçesiyle satılıyorsa, o gerekçe yanlış.

Kanıt seviyesi: Doğrulandı ama etkisi sıfıra yakın

Yapmayın listesi

Bunların hepsi aktif olarak satılıyor ve hiçbirinin dayanağı yok.

llms.txt. AI botlarına özel yönerge dosyası. Google resmi sinyal olarak kabul etmiyor. Saha verisi de aynı yöne bakıyor. 137 bin domain taramasında siteler dosyayı yayınlamış ama %97’si hiçbir AI botu tarafından okunmamış. (Tek kaynak, bağımsız doğrulaması yok ve çalışmanın kendi sayfasına ulaşamadım. Yön göstergesi olarak okuyun, rakama yaslanmayın.)

İçeriği yapay şekilde parçalara bölmek. Google Mayıs 2026 belgesinde gereksiz ilan etti.

AI’a özel şema işaretlemesi. Aynı belge, aynı sonuç.

Para karşılığı link. Bu sadece işe yaramamakla kalmıyor, Google’ın link spam politikasında adıyla sayılan bir ihlal. Politikada ayrıca sayılanlar: aşırı karşılıklı linkleşme, otomatik link üretimi, düşük kaliteli dizin siteleri, forum imza linkleri, yaygın footer linkleri. Bir link hizmeti teklifi bu listeden bir şeyse cevap hayır. (Ücretli link rel="sponsored" ile işaretlenirse kural dışı değil.)

Kanıt seviyesi: Birincil

Yerel bir işletmeyseniz

Burası ayrı bir dünya ve panik en çok burada yanlış yerde.

Google yerel sıralamayı belirleyen üç faktörü kendi belgesinde sayıyor: alaka (profil aramaya ne kadar uyuyor), mesafe (işletme arayana ne kadar yakın), bilinirlik (işletme ne kadar tanınıyor). Somut liste de orada: işletmeyi doğrula, bilgileri güncel tut, profili eksiksiz doldur, yorumlara cevap ver, fotoğraf ekle. (Google Business Profile Yardım)

Aynı sayfada çok net bir cümle de var. Google’da daha iyi bir yerel sıralama satın almanın yolu yok.

AI paniğine gelince, elimizde ilginç bir veri var. 540 sorguluk elle toplanmış bir çalışmada, yerel ve işlemsel niyetli sorgularda (”kadıköy kombi tamircisi”) AI Overviews yalnızca %15 oranında çıkıyor, harita paketi (sonuçların üstünde yakındaki işletmeleri haritayla gösteren kutu) ise %93. Bilgi amaçlı sorgularda tablo tersine dönüyor. (Whitespark)

Müşteri arayan bir tesisatçı için asıl mecra hâlâ harita paketi. Uyarı: bu çalışma 3 ABD şehri ve 6 sektörle sınırlı, Türkiye verisi değil. Yön olarak güçlü, rakam olarak dar.

Kanıt seviyesi: Birincil + tek kaynak

Her yerde aynı şeyi söylemek

Bu maddeyi sona doğru koyuyorum çünkü kanıtı zayıf. Ama bedava olduğu ve zarar veremeyeceği için listede duruyor.

Problem şu: bir yapay zekâ sizin hakkınızda bir veri tabanından bilgi çekmiyor. Adının internette hangi kelimelerle yan yana geçtiğine bakıyor. Aynı tarif yirmi yerde tekrarlanıyorsa onu doğru kabul edip tekrar ediyor. Adının yanında dört farklı tarif varsa, güvenle tekrar edebileceği bir şey bulamıyor.

Bir de isim benzerliği meselesi var. Aynı adı taşıyan başka bir şirket ya da tanınmış bir kişi varsa model sinyali en güçlü ve en tutarlı olana yöneliyor, yani adınızla sorulan soruya adaşınız hakkında cevap verebiliyor. Tutarlılık burada bir düzen meraki değil, sizi adaşınızdan ayıran şeyin kendisi.

Pratikte yapılacak şey: kendinizi bir cümleyle tarif edin ve aynı cümleyi şu yerlerin hepsine koyun.

• Sitenizin hakkında ve ana sayfası

• LinkedIn, X, Instagram, YouTube profilleriniz

• Sektörünüzün dizin ve inceleme siteleri

• E-posta imzanız

• Konuk olduğunuz podcast ve etkinliklerin tanıtım metni

Eskimiş profiller özellikle önemli. İki yıl önce açtığınız ve unuttuğunuz bir hesap, hâlâ sizi başka bir şeymişsiniz gibi tarif ediyor olabilir.

Kanıt durumu, dürüst hali. Bu tavsiyenin ölçülmüş bir etkisi elimde yok: ne müdahale çalışması var, ne öncesi sonrası verisi. Mekanizma makul ve dil modellerinin nasıl çalıştığıyla tutarlı, ama makul olmak kanıt değil.

Yani neden yapmalı? Beş dakika sürüyor, para tutmuyor, klasik aramada da zarar vermiyor ve yanlış çıkarsa kaybettiğin şey sadece o beş dakika. Bu listede kanıtsız tek maddenin bu olması tesadüf değil, çünkü kanıt gerektirmeyecek kadar ucuz.

Kanıt seviyesi: Zayıf

Geriye kalan: tanınmak

Yukarıdaki her şeyi yaptığınızda muhtemelen benim yaşadığım yere geliyorsunuz.

Teknik listeyi tek tek geçtim. Başlıklar, açıklamalar, site haritası, sayfa yapısı, cevap blokları. Hepsi zaten yapılmıştı. Haftalardır aradığım şey orada değildi.

Teknik bir sorunum yoktu. Kimsenin o siteden haberi yoktu.

Google bunu belgelerinde ayrı bir madde olarak sayıyor ve tavsiyesi neredeyse şaşırtıcı derecede sade: benzer ilgi alanına sahip insanlara işinizden bahsedin.

Bu alanda “marka bahisleri backlink’i 3’e 1 yeniyor” diye dolaşan bir rakam var. Doğru ölçülmüş bir korelasyon ama üstüne kurulan tavsiye ayakta durmuyor, çünkü çalışma yalnızca belli bir otorite eşiğinin üstündeki markaları içeriyor, yani tavsiyenin hedeflediği küçük siteler örneklemde hiç yok. Ayrıntısı ikinci yazıda.

Dürüst cevap şu: bu problemi çözen kanıtlı bir taktik listesi yok. Alanın en çok satış yapılan bölgesi tam olarak burası, en az kanıt olan yer de burası. Bu tesadüf değil.

Kanıt seviyesi: Zayıf

Özet

Liste bu kadar. Kısa olması, alanın ne kadar bilindiğiyle ilgili bir bilgi.

Bu yazı üç bölümlük bir serinin üçüncüsü.

1. SEO, AEO, GEO, LLMO: yeni bir disiplin mi, yeni bir isim mi?

2. SEO ve AEO’da doğru rakam, yanlış cümle

3. SEO ve AEO için ne yapmalı? Kanıt seviyesine göre bir liste · buradasınız

Kaynaklar

• Temel liste · SEO Starter Guide ve Search Essentials · birincil

• Reddedilen taktikler · Google Search Central · 15 Mayıs 2026

• Link spam politikası · Google · birincil

• Alıntıların içerikteki konumu · Growth Memo (ChatGPT, 1,2 milyon cevap, %44,2) ve CXL (AI Overviews, 100 alıntı, %55)

• Şema müdahale çalışması · Ahrefs · 11 Mayıs 2026 · 1.885 test + 4.000 kontrol sayfası

• Şemayı AI’ların okumaması · SearchVIU · Ekim 2025 · tek çalışma

• AI Overviews ve Google-Extended ayrımı · AI Features and Your Website ve Search Console yardımı · birincil

• AI botlarının amaca göre ayrımı · OpenAI crawler belgeleri · birincil

• Cloudflare varsayılanları · duyuru · 15 Eylül 2026, yalnızca yeni alan adları ve reklamlı sayfalar

• Yerel sıralama faktörleri · Google Business Profile Yardım · birincil

• Yerel aramada AI Overviews · Whitespark · 540 sorgu, 3 ABD şehri, 6 sektör · tek kaynak

• Marka bahisleri korelasyonu · Ahrefs, 75K marka · 26 Mayıs 2025 · yalnızca otorite puanı 40 üstü markalar

• llms.txt saha verisi · Ahrefs, Haziran 2026 · 137 bin domain · tek kaynak, makalenin kendisine ulaşılamadı

Terimleri ayrı bir yazıda topladım, SEO, AEO, GEO, LLMO: yeni bir disiplin mi, yeni bir isim mi? Buradaki tek gerekli bilgi şu: SEO sıralanmayı ölçüyor, AEO alıntılanmayı. İkisi ayrı disiplin değil ama ayrı şey ölçüyorlar ve aşağıdaki karışıklığın büyük kısmı tam buradan doğuyor.

İki tarafı birden okudum. Bir yanda araştırmaların kendisi, diğer yanda aynı araştırmalar ajans tekliflerine, LinkedIn paylaşımlarına ve araç blog yazılarına geçtiğinde ne hale geliyor.

İkisi aynı şeyi söylemiyordu.

Birincil çalışmalarda uyarılar, veri toplama tarihleri ve örneklem sınırları vardı. Aktarımlarda bunların yerini kesin cümleler almıştı. Şunu yapın, bunu bırakın. Veri bilimi ekibi yönetiyorum, günüm bir sayının neyi ölçtüğünü sormakla geçiyor. O yüzden her rakamın izini kaynağına kadar sürdüm: kim ölçmüş, neyi ölçmüş, ne zaman ölçmüş.

Asıl mesele SEO’yu bilmemek değilmiş. Rakamlar kaynaktan bana gelene kadar bozuluyordu, üstelik rastgele değil, tekrar eden dört yolla.

Bu yazı SEO öğretmiyor. O dört yolu, her biri için gerçek bir vaka açarak gösteriyor. Alan SEO ama mekanizma her yerde aynı. Kendi alanınızda da tanıyacaksınız.

Vaka 1: Aynı ekip, üç rakam, hepsi doğru

Kim ölçüyor: Ahrefs, SEO araçları üreten ve kendi verisini düzenli yayınlayan bir şirket. Aşağıdaki iki çalışmanın da yazarları arasında aynı iki araştırmacı var: Louise Linehan ve Xibeijia Guan.

Ne ölçülüyor: Bir yapay zekâ bir soruya cevap verirken kaynak gösterdiği sayfaların ne kadarı, aynı soru Google’a sorulduğunda ilk 10 sonuçta da çıkıyor? Buna kısaca örtüşme diyorum.

Aynı ekibin iki çalışmasından bu tek soru için üç rakam çıkıyor: %12, %38, %76.

İlk tepki “biri yanlış” olur. Hiçbiri yanlış değil. Üçü farklı şey ölçüyor.

Birinci çalışma, Ağustos 2025. Ölçtüğü motorlar ChatGPT, Gemini ve Copilot. 15.000 uzun kuyruk sorgusu üzerinde. (Uzun kuyruk sorgusu: “ayakkabı” gibi tek kelimelik aramalar değil, “düz tabanlar için koşu ayakkabısı” gibi uzun ve özgül aramalar. Az kişi arar ama arayan tam olarak ne istediğini bilir.)

• %12: bu üç asistanın kaynak gösterdiği bağlantıların Google ilk 10’da da çıkma oranı.

İkinci çalışma, Mart 2026. Ölçtüğü motor yalnızca Google’ın kendi AI Overviews’u. 863.000 arama sonucu sayfası, 4 milyon sayfa adresi.

• %38: AI Overviews’un kaynak gösterdiği sayfaların ilk 10’da da yer alma oranı.

• %76: aynı ölçümün Temmuz 2025’teki hali. Ayrı bir çalışma değil, ikinci çalışmanın içinde önceki durum olarak raporlanıyor.

Üç ölçümde de motorlar, sorgu kümeleri ve tarihler farklı. %76’dan %38’e düşüşün açıklanmış bir mekanizması da var: Google sorguyu alt sorgulara bölüp alıntıları genişletilmiş sonuçlardan çekmeye başladı. Bunun teknik adı query fan-out, yani sorgunun yelpaze gibi açılması. Siz tek soru yazıyorsunuz, arama motoru arka planda birkaç ayrı arama yapıp cevabı onların hepsinden topluyor.

Bozulma şurada: bu üç rakam sektörde birbirinin yerine kullanılıyor. Biri diğerini “çürütmek” için gösteriliyor. Oysa çürütme yok. Yalnızca farklı sorulara verilmiş farklı cevaplar var.

Sorulacak soru: bu oran hesaplanırken payda ne alınmış?

Vaka 2: Sebep mi, yoksa sadece belirti mi?

İddia: “Sayfanıza şema ekleyin, AI sizi daha çok alıntılar.”

Şema (İngilizcesi schema markup, Google’ın kendi belgelerinde structured data), sayfanın koduna gömülen ve ziyaretçinin görmediği etiketlerdir: bu sayfa bir tarif, bu bir ürün, fiyatı şu kadar.

Dayanağı gerçek bir ölçüm: AI’ın alıntıladığı sayfaların %53’ünde şema var. 6 milyon sayfa adresi üzerinde sayılmış. Rakam doğru.

Buraya kadar tavsiye makul görünüyor. Ama bu, çalışmanın yalnızca yarısı.

Aynı ekip ikinci bir şey daha yapmış ve bu vakanın tamamı o ikinci şeyde:

Gözlemsel ölçüm, hâlihazırda şeması olan sayfalara bakmaktır. Kimde varsa onu sayarsınız. Yukarıdaki %53 bu.

Müdahaleli ölçüm, şemayı sonradan ekleyip ne olduğunu izlemektir. Burada 1.885 sayfa şema eklemiş; hiç eklemeyen 4.000 benzer sayfa da karşılaştırma grubu olarak izlenmiş. İkisinin öncesi ve sonrası kıyaslanmış.

İkisi arasındaki fark şurada önemli: eğer şema alıntılanmanın sebebiyse, şemayı ekleyen sayfalarda alıntılanma artmalı.

Artmadı. AI Overviews −%4,6 · AI Mode +%2,4 · ChatGPT +%2,2. Üçü de sıfırın etrafında, biri hafif eksi.

%53 doğru bir rakam ama bir şeyin sebebini değil, belirtisini ölçüyor. Yazarların açıklaması da makul. Şema ekleyen siteler zaten teknik işini düzgün yapan, düzenli içerik üreten sitelerdir. Şema, iyi sitenin sebebi olmuyor; iyi siteyle birlikte bulunuyor. Bunun mekanizmasını gösteren ayrı bir çalışma da var. SearchVIU’nun Ekim 2025’te ChatGPT, Claude, Perplexity, Gemini ve Google AI Mode üzerinde yaptığı testte, yalnızca şemanın içinde duran bilgiler neredeyse hiç alınmıyor. Alınan şey, ziyaretçinin de gördüğü metin.

Kaynak: Ahrefs, “We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.” (11 Mayıs 2026)

Şimdi asıl mesele. Bu iki ölçüm aynı makalenin içinde. Üstelik makalenin başlığı bile sonucu söylüyor. “Şema ekleyen 1.885 sayfayı izledik. AI alıntıları neredeyse hiç kıpırdamadı.”

Kimse bir şey saklamıyor. Saklamasına gerek de yok, çünkü aktarılırken zaten yarısı düşüyor: %53 yoluna devam ediyor, müdahale kısmı düşüyor. Geriye “şema ekleyin, alıntılanırsınız” kalıyor.

Kenar notu. Bu hata pazarlama tarihinin en pahalı örneklerinden birini de üretmiş. Coca-Cola 1980’lerde yudum testleri yapıyor ve insanlar Pepsi’yi tercih ediyor. Ölçüm düzgün, rakam gerçek. Şirket bunun üzerine formülü değiştirip New Coke’u çıkarıyor ve sonuç felaket oluyor. Sebep şu: yudum testi bir yudumu ölçüyor, oysa insanlar koca bir kutu içiyor. Daha tatlı içecek bir yudumda kazanıyor, bir kutuda kaybediyor. Yani ölçüm doğruydu; ölçtüğü şey, cevaplanmak istenen soru değildi. Malcolm Gladwell bu vakayı Blink‘in “Kenna’s Dilemma” başlıklı beşinci bölümünde anlatıyor.

Sorulacak soru: gözlemsel mi, müdahaleli mi?

Vaka 3: Çalışma doğru, muhatabı siz değilsiniz

İddia: “75.000 marka incelendi, marka bahisleri backlink’i 3’e 1 yeniyor. Backlink kovalamayı bırakın.” Bu yıl en çok dolaşan cümlelerden biri.

İki terim: backlink, başka bir sitenin size verdiği bağlantı. Marka bahsi ise adının bağlantı olmadan, düz metin içinde geçmesi.

Dayanağı gerçek bir ölçüm: marka bahisleri 0,664, backlink 0,218. Oran gerçekten üçe yakın. Rakamlar doğru.

Sorun oranda değil, oranın neyi gizlediğinde.

Manşet iki nokta arasındaki oranı anlatıyor; anlatmadığı şey her iki noktanın da eksende nerede durduğu.

Birincil kaynağı açtığımda üç şey daha çıktı, üçü de aktarımlarda yok:

Yazarların uyarısı kesilmiş. Metinde birebir şu var: “korelasyon ≠ nedensellik” ve “incelediğimiz faktörlerin tamamı Spearman ölçeğinde orta ile çok zayıf arası korelasyonlar gösterdi.” (Spearman, iki şeyin birlikte hareket etme derecesini ölçen bir katsayı. −1 ile +1 arasında değer alır: 0 ilişki yok demek, 1 tam birlikte hareket, −1 tam ters yönde. Buradaki 0,664 ve 0,218 bu ölçekte okunmalı.) Manşetlerin hiçbirinde yok.

Örneklem, tavsiyenin hedef kitlesini dışlıyor. Çalışma yalnızca belli bir otorite eşiğinin üstündeki, ayda 800’den fazla arama alan markaları içeriyor. “Backlink kovalamayı bırakın” tavsiyesinin yöneldiği yeni ve küçük siteler, bu çalışmanın evreninde hiç yok.

Ve bariz bir karıştırıcı değişken var: bilinirlik. Tanınmış bir marka hem daha çok bahsedilir hem AI cevaplarında daha çok çıkar. Bahis, çıkmanın sebebi olmayabilir; ikisi de aynı üçüncü şeyin sonucu olabilir.

Bir de tarih meselesi var. Çalışma 26 Mayıs 2025 tarihli, yani bu satırları yazarken on beş aylık. Aylık değişen bir alanda “bu yıl dolaşan iddia”, geçen yılın verisine dayanıyor.

Sorulacak soru: ben bu örneklemde miyim?

Vaka 4: İki link, tek kaynak

Bir iddiayı iki farklı sitede görünce doğrulanmış sayarız. Hakemsiz alanlarda bu refleks tutmuyor.

Kendi notlarımda “%12 örtüşme” rakamı Şubat 2026 tarihli bir siteye atıflıydı ve “tek kaynak” diye işaretlemiştim. Asıl kaynağı aradığımda çıkan şey: aynı verinin Ağustos 2025 tarihli orijinali. Şubat 2026’daki yazı bağımsız bir çalışma değil, yeniden paketleme.

Bir çalışmayı aktaran yazı, o çalışmanın kendisi sayılmaz. İki kaynağı saymadan önce ikisinin de kendi verisini topladığını doğrulamak gerekiyor; bu da göründüğünden çok daha sık başarısız oluyor.

Aynı yeniden paketleme, tarihi de siliyor. On beş aylık bir veri, 2026 tarihli bir yazının içinde “güncel” görünüyor. Aylık değişen bir alanda bu, rakamı kullanılamaz hale getiriyor.

Sorulacak soru: bu gerçekten birincil kaynak mı ve verinin kendisi kaç aylık?

Dört soru

Dört vakanın tamamı dört soruya indirgeniyor. Hiçbiri istatistik bilgisi gerektirmiyor.

Sonunda kendi siteme baktım

Bütün bunları öğrendikten sonra asıl işe döndüm. Elimdeki siteye ne yapmam gerekiyor?

Teknik listeyi tek tek geçtim. Başlıklar, açıklamalar, site haritası, sayfa yapısı, cevap blokları. Hepsi zaten yapılmıştı. Haftalardır aradığım şey orada değildi.

Google’ın kendi arama konsolunda gerçek durum şuydu: elli sayfanın ikisi indekslenmiş, 47’si “bulundu ama henüz taranmadı” durumunda. Google adresleri biliyor, gidip bakmaya değer bulmamış.

Yani teknik bir sorunum yoktu. Kimsenin o siteden haberi yoktu. Dürüst olmak gerekirse, bu problemi çözen kanıtlı bir taktik listesi de yok. Alanın en çok satış yapılan bölgesi tam olarak burası, en az kanıt olan yer de burası. Tesadüf değil.

Kapanış

Bu alanı ahlaksız bulmadım. Bulduğum şey daha sıradan ve daha yaygın. Hızlı büyüyen, hakemsiz ve ticari bir alanda, doğru rakamlar aktarıla aktarıla yanlış cümlelere dönüşüyor. Kimse yalan söylemiyor. Yalnızca her aktarımda bir uyarı, bir tarih ya da bir payda düşüyor.

Bu, kendi alanınızda da tanıdık gelmeli. Her sektörün “herkesin bildiği” bir istatistiği var ve çoğunun altında tek bir çalışma, bir karıştırıcı değişken ve birkaç yıl yatıyor.

Dört soru bedava. Sormaya değer.

Bu yazı üç bölümlük bir serinin ikincisi.

1. SEO, AEO, GEO, LLMO: yeni bir disiplin mi, yeni bir isim mi?

2. SEO ve AEO’da doğru rakam, yanlış cümle · buradasınız

3. SEO ve AEO için ne yapmalı? Kanıt seviyesine göre bir liste

Kaynaklar

Yazıdaki her rakamın birincil kaynağı, veri toplama tarihiyle birlikte:

• %12 örtüşme · Ahrefs, “Only 12% of AI Cited URLs Rank in Google’s Top 10” · 11 Ağustos 2025 · 15.000 uzun kuyruk sorgusu

• %38 ve %76 · Ahrefs, “Update: 38% of AI Overview Citations Pull From The Top 10” · 2 Mart 2026 · 863.000 arama sonucu sayfası, 4 milyon sayfa adresi

• Şema: gözlem ve müdahale · Ahrefs, “We Tracked 1,885 Pages Adding Schema” · 11 Mayıs 2026 · 6 milyon sayfa adresi (gözlem), 1.885 + 4.000 sayfa (müdahale)

• Marka bahisleri 0,664 / backlink 0,218 · Ahrefs, “An Analysis of AI Overview Brand Visibility Factors (75K Brands)” · 26 Mayıs 2025 · yalnızca otorite puanı 40’ın üstünde ve ayda 800’den fazla arama alan markalar

• Pepsi Challenge ve New Coke · Malcolm Gladwell, Blink, 5. bölüm (”Kenna’s Dilemma”) · yudum testinin daha tatlı içeceği kayırması ve koca bardakta sonucun tersine dönmesi

• Yeniden paketleme örneği · Evergreen Media, AEO rehberi · Şubat 2026 · bağımsız çalışma değil