İçerik chunking, bir metni yapay zeka sistemlerinin tek başına işleyebileceği küçük ve odaklı pasajlara bölme tekniğidir. AI sistemleri bir sayfayı bütün olarak değil, bu pasajlar üzerinden değerlendirir. Atıf sayfanın otoritesinden değil, belirli bir alt soruyu tek başına yanıtlayan pasajdan gelir.
İçerik chunking nedir?
İçeriği, yapay zeka sistemlerinin daha kolay işleyip bilgi çıkarabileceği küçük ve odaklı birimlere bölme tekniğidir. Sistem sayfanızı okuyup bir bütün olarak puanlamaz; onu parçalara ayırır, her parçayı ayrı bir aday olarak saklar ve kullanıcı sorusu geldiğinde yalnızca o soruya en iyi karşılık gelen parçayı yanıta taşır.
Buradan çıkan pratik sonuç, AI aramada görünürlük çalışmasının klasik sayfa optimizasyonundan ayrıldığı yerdir: 3.000 kelimelik bir makale tek bir rakip olarak değil, ayrı ayrı değerlendirilen pasajlar kümesi olarak rekabet eder. Güçlü bir alan adına sahip olmak tek başına bunu değiştirmiyor — otorite sayfa düzeyinde birikir, seçim pasaj düzeyinde yapılır.
Terimin kendisi yeni değil. Chunking, RAG mimarilerinin ilk adımı olarak yıllardır mühendislik tarafında konuşuluyordu; içerik tarafına geçmesinin sebebi, üretken arama sistemlerinin aynı hattı canlı web üzerinde çalıştırmaya başlaması.Yapay zeka aramanın nasıl çalıştığınıanlatan sayfada bu hattın tamamı var; burada yalnızca ilk halkasına, yani metnin nasıl bölündüğüne bakıyoruz.
Chunk sınırının nereden geçtiğini pratikte HTML belirliyor. Başlık etiketleri, liste öğeleri, tablo satırları ve tanım blokları doğal kesme noktaları üretir; bunlardan yoksun uzun bir metin bloğunda bölme işi karakter sayısına ya da cümle sınırına düşer. Aynı içerik bu yüzden iki farklı işaretlemeyle iki farklı pasaj kümesi üretebiliyor — metin değişmese bile.
Bir ayrım işe yarıyor: chunking bir sıralama faktörü değil, bir görünürlük ön koşulu. Kötü bölünmüş bir sayfa "daha aşağıda" sıralanmaz — hiç aday olmaz, çünkü sorguya karşılık gelen parçası ya bir başka konunun içine gömülmüştür ya da kendi başına okunduğunda ne dediği anlaşılmaz.
Token mu, kelime mi? Türkçe'de pasaj uzunluğu nasıl ölçülür?
Retrieval sistemleri kelimeyle değil token'la çalışır. Soru-cevap retrieval'ı için genel olarak en iyi performansı veren aralık 256–512 token; bu, pratikte önerilen 200–500 token bandının içinde kalır. Kelimeye çevirmek gerekirse: Türkçe'de aynı anlam İngilizce'den daha fazla token tuttuğu için 256–512 token yaklaşık 50–120 kelimeye denk gelir.
Sayfa boyunca bu çerçeveyi kullanıyorum, çünkü üç farklı sayı görmek gereksiz bir karışıklık yaratıyor: 256–512 token = Türkçe'de kabaca 50–120 kelime. Bundan sonraki bölümlerde "pasaj" derken kastettiğim uzunluk bu.
Neden Türkçe'de oran farklı? Modern dil modelleri metni kelimelere değil alt-kelime parçalarına böler. Bu parça sözlükleri ağırlıklı olarak İngilizce metinle eğitildiği için İngilizce'de sık geçen bir kelime çoğunlukla tek parça hâlinde temsil edilir. Türkçe sondan eklemeli bir dil: kök üzerine dizilen ek zincirleri her seferinde yeni bir yüzey biçimi üretir. "Kitap" tek parça olabilir; "kitaplarımızdan" büyük olasılıkla birkaç parçaya bölünür. Türkçe'ye özgü harfler ve yaygın olmayan ek kombinasyonları bu bölünmeyi artırır.
Sonucu şu: aynı bilgiyi anlatan Türkçe bir paragraf, İngilizcesinden daha fazla token harcar. Token bütçesi sabit olduğuna göre, Türkçe pasajları daha kısa tutmak gerekir. İngilizce için yaygın kullanılan "100 token ≈ 75 kelime" başparmak kuralı Türkçe'ye doğrudan uygulanamaz — Türkçe'de kelime başına düşen token sayısı belirgin biçimde yüksektir.
Sabit bir Türkçe çarpanı vermiyorum, çünkü oran tokenizer'dan tokenizer'a değişiyor; aynı metin farklı modellerde farklı sayıda token üretiyor. Ölçmek isterseniz doğru yol, hedeflediğiniz modelin kendi tokenizer'ından kendi metninizi geçirmek. Pratikte işe yarayan kural daha basit: Türkçe yazarken 120 kelimeyi üst sınır kabul edin, 50–90 kelime bandını varsayılan olarak kullanın.
Alıntılanabilir pasaj nasıl yazılır?
Dört şey belirleyici: başlığın soru olarak kurulması, yanıtın ilk cümleye taşınması, paragrafın 50–120 kelimede tutulması ve pasajın çevresindeki metin olmadan da anlamlı olması. Bunların hiçbiri stil tercihi değil — her biri, retrieval hattının belirli bir aşamasında pasajın elenip elenmeyeceğini doğrudan etkiliyor.
Başlığı soru olarak yaz, yanıtı ilk cümleye taşı
Her H2 ve H3, başlığın ima ettiği soruya doğrudan yanıtla açılmalı. Uzun giriş cümleleri retrieval'da elenme riskini artırıyor: pasajın vektörü ilk cümlelerin taşıdığı anlamla şekilleniyor ve o cümleler "bu konuyu ele almadan önce" tarzı bir ısınma yapıyorsa, vektör soruya değil ısınmaya benziyor.
Paragrafı 50–120 kelimede tut
120 kelimeyi aşan pasajlarda retrieval modeli token bütçesine sığdırmak için kesme yapıyor ve kesilen yer sizin seçtiğiniz yer olmuyor; bu da çıkarımın güvenilirliğini düşürüyor. Ama kısa tutmak tek başına yetmiyor. O 50–120 kelimenin içinde somut bir şey olmalı: bir sayı, adlandırılmış bir varlık, bir süreç adımı, bir kaynak alıntısı. Kısa ve boş bir paragraf, uzun ve dolu bir paragraftan daha az alıntılanıyor —bilgi kazancı ölçütü burada da geçerli.
Her paragrafı bağımsız yaz
"Yukarıda bahsettiğimiz gibi", "bu yöntem", "az önce anlattığımız yaklaşım" türü ifadeler pasajı bağlama bağımlı kılar. Chunk sistemden çıkarıldığında o bağlam yanında gelmez; geriye ne dediği belirsiz bir metin parçası kalır. Ölçüt basit: paragrafı tek başına bir kâğıda kopyalayın, makalenin geri kalanını okumamış biri anlıyorsa pasaj bağımsızdır.
Chunk sınırlarını başlık yapısıyla sen belirle
Chunker bir yerden kesecek. H2 ve H3 başlıkları ona nereden keseceğini söyler: fikrin ortasından değil, konu sınırından. Başlıksız uzun bir metinde bölme işlemi karakter ya da cümle sayısına göre yapılır ve bir argümanın ortasına düşmesi olağandır. Öz-yeterlilik ve başlık disiplini, içerik yazarının vektör veritabanı davranışı üzerinde doğrudan kontrol kurabildiği birkaç kaldıraçtan ikisi.
Alıntılanabilir ve alıntılanamayan pasaj: fark nerede?
Fark beş boyutta toplanıyor: bağımsızlık, uzunluk, odak, somutluk ve açılış cümlesi. Alıntılanabilir pasaj tek bir fikri, kendi başına anlaşılır biçimde ve doğrudan bir yargıyla açarak anlatır. Alıntılanamayan pasaj ya bağlamına muhtaçtır ya birden fazla fikri karıştırır ya da somut hiçbir şey söylemez.
| Boyut | Alıntılanabilir pasaj | Alıntılanamayan pasaj |
|---|---|---|
| Bağımsızlık | Önceki paragraf okunmadan da tam anlam taşır | Bağlam için önceki bölüme muhtaç |
| Uzunluk | 50–120 kelime (yaklaşık 256–512 token) | Tek cümlelik kırıntı ya da 300+ kelimelik blok |
| Odak | Tek fikir, tek amaç | Birden fazla fikri karıştırır; embedding dağılır |
| Somutluk | İstatistik, adlandırılmış varlık ya da süreç adımı içerir | Genel marka dili veya belirsiz iddia |
| Açılış cümlesi | Doğrudan tanım ya da net yargıyla açılır | "Bu konuyu ele almadan önce…" tipi bağlam kurma cümlesiyle açılır |
İki pasaj tipi ölçümlerde öne çıkıyor: numaralı süreç açıklamaları ve "X ile Y arasındaki fark şudur" biçimindeki karşılaştırmalar. İkisinin ortak yanı, sınırının metnin kendisi tarafından çizilmiş olması — nerede başladığı ve nerede bittiği belli.
Farkı somutlaştırmak için aynı bilginin iki yazımına bakalım. Alıntılanamayan hâli: "Bu konuya geçmeden önce yukarıda anlattığımız yapıyı hatırlamakta fayda var. Söz konusu yöntem, daha önce değindiğimiz sorunu büyük ölçüde çözüyor ve birçok ekip için ciddi bir avantaj sağlıyor." Burada hiçbir varlık adı, hiçbir sayı, hiçbir tanım yok; paragraf yalnızca kendisinden önce gelen metne işaret ediyor.
Aynı bilginin alıntılanabilir hâli: "Contextual Retrieval, her chunk'ın başına o parçanın belgedeki yerini açıklayan kısa bir bağlam cümlesi ekler. Anthropic'in kendi deneyinde bu ekleme, retrieval başarısızlıklarını %5,7'den %1,9'a düşürdü." İkinci versiyon aynı uzunlukta değil ama aynı işi tek başına yapıyor: konuyu adlandırıyor, mekanizmayı söylüyor, ölçümü ve ölçümün kimden geldiğini veriyor. Bir yanıt motorunun bunu bağlamından koparıp yanıta taşıması için sayfanın geri kalanına ihtiyacı yok.
AI bir pasajı nasıl seçer?
Sistem sayfayı segmentlere ayırır, her segmenti vektör veritabanında bir embedding olarak saklar ve sorgu geldiğinde hangi segmentin o soruyu en iyi yanıtladığını hesaplar. Buna passage-based retrieval deniyor. Seçim sayfalar arasında değil, pasajlar arasında yapılıyor; aynı sayfanın iki bölümü birbirinden bağımsız yarışabiliyor ve biri yanıta girerken diğeri hiç değerlendirmeye alınmıyor.
RAG hattı bir eleme tüneli gibi çalışıyor; her aşama bir öncekinden daha az aday bırakıyor:
- Chunking. Metin parçalara bölünür. Birden fazla konuyu aynı anda işleyen pasajın vektörü dağınık çıkar; hiçbir sorguya güçlü benzerlik vermez.
- Embedding ve indeksleme. Her parça sayısal bir vektöre dönüştürülüp saklanır. "Yukarıda belirttiğimiz gibi…" ile açılan pasajlar daha bu aşamada düşük puan alır, çünkü taşıdıkları anlam kendi içlerinde tamamlanmıyor.
- Retrieval. Sorgu vektörüne kosinüs benzerliğiyle en yakın top-k parça getirilir.
- Reranking. İkinci bir model, gelen parçaları soruyla birlikte yeniden puanlar. Bu aşamada ilk cümlesinde çözen pasajlar üstün gelir.
- Generation. Hayatta kalan parçalar modele verilir ve yanıt üretilir. Atıf, yalnızca bu son kümeye kalan pasajlardan çıkar.
Retrieval kalitesi, model seçiminden çok chunking kalitesine bağlı. Daha güçlü bir modele geçmek, yanlış bölünmüş bir metinden doğru pasajı çıkarmıyor — model yalnızca kendisine verilen parçalar arasından seçim yapıyor.
Aynı mekanizma, tek bir sorgunun arka planda çoğaltıldığıquery fan-out sürecinde her alt sorgu için ayrı ayrı çalışıyor. Yani bir sayfa, üretilen alt sorgu sayısı kadar farklı elemeye giriyor ve her birinde farklı bir pasajıyla yarışıyor.
Bağlamı chunk'a geri koymak: Contextual Retrieval
Chunking'in yapısal sorunu şu: parça bağlamından koparılınca anlamının bir kısmını kaybediyor. Contextual Retrieval, indeksleme sırasında her parçanın başına o parçanın belgedeki yerini açıklayan kısa bir bağlam cümlesi ekleyerek bunu telafi eden bir yaklaşım. Amaç, parçayı kaynağından koparmadan aramaya hazır hâle getirmek.
Anthropic'in yayımladığı deneyde bu yöntem, retrieval başarısızlıklarını %5,7'den %1,9'a düşürdü. Sayı satıcının kendi ölçümü ve kendi test kurulumunda elde edildi; bağımsız bir doğrulama değil. Yine de mekanizması içerik tarafına doğrudan çeviriliyor: sistemin sonradan eklemek zorunda kaldığı bağlamı, siz zaten pasajın içine yazmışsanız telafiye ihtiyaç kalmıyor.
Bölme yönteminin kendisi de ölçülebilir bir fark yaratıyor. Corpus ve retriever sabit tutulduğunda bile en iyi ile en kötü chunking yöntemi arasında %9'a varan recall farkı ölçüldü. Bu, aynı içeriğin yalnızca nasıl bölündüğüne bağlı olarak on soruda birinde bulunamaması demek.
Sizin tarafınızdaki karşılığı: yayıncı olarak chunker'ı seçemiyorsunuz. Hangi sistemin hangi yöntemle böldüğünü bilmiyorsunuz ve bu sistemden sisteme değişiyor. Kontrol edebildiğiniz tek şey, hangi yöntem uygulanırsa uygulansın metnin makul yerlerden bölünmesini kolaylaştırmak. Başlık disiplini ve tek fikirli paragraflar tam olarak bunu yapıyor.
Bu sayfa kendi kuralına göre yazıldı
Bu sayfada her H2'nin hemen altında, o başlığın sorusunu tek başına yanıtlayan bir paragraf var. Hepsi 40–80 kelime aralığında, her biri tek bir fikirle sınırlı ve hiçbiri kendinden önceki bölüme geri gönderme yapmıyor. Yani anlattığım kural, üzerinde durduğunuz metinde uygulanmış hâlde — iddia ile sayfanın kendisi aynı şeyi söylüyor.
Kontrol etmek kolay: sayfayı yukarı kaydırıp herhangi bir başlık altındaki ilk paragrafı tek başına okuyun. "Chunk boyutu ne olmalı" ya da "AI bir pasajı nasıl seçer" sorusunun yanıtı, çevresindeki hiçbir cümle olmadan orada duruyor mu? Duruyorsa o paragraf alıntılanabilir bir pasajdır.
Bunu bir gösteri olsun diye yapmıyorum. Sitedeki GEO rehberlerinin tamamı aynı iskeletle yazılıyor: H1 altında bağlamsız açılış cevabı, ardından TL;DR, sonra her H2 için bağımsız bölüm cevabı. İskeletin sebebi estetik değil — üretken arama sistemlerinin sayfayı nasıl parçaladığına dair yukarıda anlatılan mekanizma.Yapay zeka için içerik yazımısayfasında bu iskeletin tamamı, chunking dışındaki gereklilikleriyle birlikte anlatılıyor.
Bir uyarı da gerekiyor: kuralı mekanikleştirmek metni bozar. Her paragrafı aynı uzunlukta, aynı kalıpla açılan bloklara çevirirseniz okunabilirliği öldürürsünüz ve yapay zeka üretimi izlenimi verirsiniz. Kural, cevabın erken gelmesi ve pasajın kendi kendine yetmesi; ritmin tekdüzeleşmesi değil.
Mevcut içerikte chunking denetimi nasıl yapılır?
En hızlı yol, sayfanın en çok trafik alan bölümlerini alıp her paragrafı bağlamından kopararak tek tek okumak. Anlamını koruyan paragraf pasaj olarak çalışır; "bu", "söz konusu", "yukarıdaki" gibi geri göndermelerle açılan paragraf çalışmaz. Denetim, düzeltme işinden çok daha kısa sürüyor; orta ölçekli bir sayfa için yarım saat genellikle yetiyor.
Sırayla bakılacak şeyler kısa bir liste hâlinde toplanabilir:
- Başlıklar soru mu, yoksa "Genel Bakış" gibi içeriksiz etiketler mi?
- Her başlığın altındaki ilk paragraf, başlığın sorusunu yanıtlıyor mu?
- 120 kelimeyi aşan paragraflar var mı? Varsa doğal bir kırılma noktası bulunuyor mu?
- Geri gönderme ifadeleriyle açılan paragraflar hangileri?
- Paragrafların içinde somut bir veri, tarih, ad veya adım var mı?
- İki başlık arasında 800 kelimelik başlıksız blok kaldı mı?
Düzeltmeye nereden başlanacağı sorusunun yanıtı ölçümden çıkıyor.GEO KPI ölçümü tarafında hangi sayfalarınızın hangi yanıtlarda kaynak gösterildiğini izliyorsanız, atıf alan ama düzensiz sayfalar öncelikli listedir: orada zaten bir ilgi var, yalnızca pasaj yapısı onu boşa harcıyor. Platform davranışları da farklılaşıyor — AI Bakışı kısa ve tanım niteliğindeki pasajlara yaslanırken,Perplexity daha uzun ve kaynak yoğun parçalara alan açıyor.
Bir de yapmamak gereken bir şey var: mevcut metni parçalamak için cümleleri bölüp her birine başlık atmak. Bu, chunk sayısını artırır ama her chunk'ın taşıdığı bilgiyi seyreltir. Hedef daha çok parça değil, daha çok kendi başına ayakta duran parça.Semantik yazım ilkeleriyle çakışan bir yan yok; ikisi aynı yöne çekiyor.
Sıkça Sorulan Sorular
Chunk boyutu ne olmalı?
Soru-cevap retrieval'ı için 256–512 token aralığı genel olarak en iyi performansı veriyor. Türkçe metinde bunun pratik karşılığı yaklaşık 50–120 kelime.
Türkçe içerikte pasajı neden daha kısa tutmak gerekiyor?
Çünkü Türkçe sondan eklemeli bir dil ve dil modellerinin kullandığı alt-kelime sözlükleri ağırlıklı olarak İngilizce metinle oluşturuldu. Türkçe kelimelerdeki ek zincirleri birden fazla parçaya bölünüyor, dolayısıyla aynı anlam daha fazla token harcıyor. Token bütçesi sabit olduğu için Türkçe pasaj, aynı bilgiyi taşıyan İngilizce pasajdan daha az kelime içerebiliyor. Kesin oran tokenizer'a göre değişir; kendi modelinizin tokenizer'ıyla ölçmek en doğrusu.
Overlap (örtüşme) şart mı?
Hayır. Ocak 2026'da yayımlanan sistematik bir analiz, chunk overlap'in test edilen kurulumda ölçülebilir fayda sağlamadığını, buna karşın indeksleme maliyetini artırdığını buldu. Bulgu tek bir kurulumda elde edildi; her mimari için genel kural sayılmamalı.
Chunking, SEO'nun yerini alır mı?
Almaz. Güçlü bir bağlantı profili ve teknik SEO temelleri hâlâ gerekli. İçerik chunking, iyi yazarlığa dair formatlama ilkelerinin başka bir adı sayılabilir.
Uzun makale yazmak hâlâ işe yarar mı?
Yarar, ama mantığı değişti. Uzun içeriğin ortasında kalan bilgiler "lost-in-the-middle" sorunuyla gözden kaçabiliyor. Uzunluk kendi başına ne avantaj ne dezavantaj; belirleyici olan metnin kaç tane kendi başına anlaşılır pasaja bölünebildiği.
AI atfı için alan adı otoritesi yeterli mi?
Tek başına değil. Ölçümler içerik kalitesinin yapay zeka yanıtlarındaki sıralamayı chunking'den daha fazla etkilediğini, buna karşılık yalnızca başka kaynakları yeniden ifade eden içeriğin daha az atıf aldığını gösteriyor.
Yanlış chunking ne kadar fark yaratır?
Aynı corpus ve aynı retriever kullanılsa bile en iyi ile en kötü chunking yöntemi arasında %9'a varan recall farkı ölçüldü. Anthropic'in Contextual Retrieval deneyinde ise retrieval başarısızlıkları %5,7'den %1,9'a düştü — bu ikinci sayı satıcının kendi test kurulumundan geliyor.
Mevcut sayfalarınızın hangi pasajlarının alıntılanabilir durumda olduğunu ve hangilerinin retrieval aşamasında elendiğini birlikte çıkarmak isterseniz,GEO danışmanlığı sayfasından kapsam ve çalışma biçimine bakabilirsiniz.

