Parçalama

TL;DR — Chunking, AI arama motorlarının sayfanızı depolayıp aramadan önce daha küçük parçalara ayırma yöntemidir. Bir sorguyu sayfanızın tamamıyla değil, ona en iyi yanıt veren tek bir pasajla eşleştirirler. Bu nedenle dizine eklenmek yeterli değildir; tek başına anlamlı olan ve soruyu açıkça yanıtlayan bir bölüme ihtiyacınız vardır.

Chunking nedir?

Chunking, belgeleri gömme ve getirme sistemleri için daha küçük birimlere ayırır. Evidence for this claim Retrieval systems can split files into chunks that are embedded and indexed for later search. Scope: OpenAI's retrieval implementation; chunk sizes, overlap, and indexing behavior are implementation-dependent. Confidence: high · Verified: 2026-07-14 OpenAI: Retrieval guide Parça boyutu ve örtüşme, en uygun değerleri içeriğe, modele ve değerlendirme görevine bağlı olan uygulama tercihleridir. Evidence for this claim Retrieval-augmented generation combines a generator with retrieved external passages or documents. Scope: The original RAG research architecture; it does not establish one optimal chunking strategy for every production system. Confidence: high · Verified: 2026-07-14 Lewis et al.: Retrieval-Augmented Generation

Google’da geleneksel yöntemle arama yaptığınızda birim sayfadır: bir sayfa sıralamaya girer ve siz de sayfaya tıklarsınız. AI sistemleri farklı çalışır. ChatGPT, Perplexity veya Google’ın AI Overviews özelliği içeriğinizi kullanmadan önce onu chunks ya da passages adı verilen daha küçük bölümlere ayırır ve her birini ayrı ayrı depolar. Birisi soru sorduğunda sistem, soruyla en iyi eşleşen chunks parçalarını bulur ve bunlardan bir yanıt oluşturur.

Dolayısıyla retrieval birimi sayfanız değil, sayfanızdaki bir pasajdır.

Neden buna ihtiyaç duyarlar?

İki nedeni var:

1. Boyut sınırları. Metni aranabilir matematiksel gösterimlere dönüştüren modeller (bkz. embeddings) tek seferde yalnızca belirli miktarda metin alabilir. 5 000 kelimelik bir sayfa sığmayacağı için bölünür.
2. Hassasiyet. “Teknik SEO” hakkındaki bir sayfanın tamamı, “tarama bütçesi nedir?” gibi belirli bir soruyla belirsiz biçimde eşleşir. Yalnızca tarama bütçesine odaklanan 400 kelimelik bir bölüm ise güçlü bir eşleşmedir. Daha küçük parçalar, sistemin samanlığın tamamını getirmek yerine iğneyi bulmasını sağlar.

Bunun sizin için anlamı

Herhangi bir AI sisteminin içeriğinizi nasıl parçaladığını kontrol edemezsiniz; buna ihtiyacınız da yoktur. Yapabileceğiniz şey, her bölümün tek başına çıkarıldığında da anlamını koruyacağı biçimde yazmaktır:

• Yanıtı başa koyun. Bir bölüme üç paragraflık gereksiz bir girişle değil, tanımla veya temel iddiayla başlayın.
• Bölümleri odaklı tutun. Her başlıkta tek bir konuya veya soruya yer verin.
• Her bölümü kendi içinde yeterli hâle getirin. Kendinize şunu sorun: Birisi çevresinde hiçbir şey olmadan yalnızca bu paragrafı okusa yine de anlamlı olur mu?

İyi haber şu: Bu yalnızca açık ve anlaşılır yazmaktır. Google, AI için içeriğinizi küçük parçalara ayırmanız gerekmediğini açıkça söylüyor; bölme işlemini kendi sistemleri yapıyor. İleri düzey sürüm, chunk boyutunu, overlap değerini, araştırmaları ve bunların Google’ın “passage ranking” sistemiyle bağlantısını ele alıyor.

TL;DR — Chunking, bir belgeyi embedding, dizine ekleme ve retrieval işlemlerinden önce pasajlara bölen ön işleme adımıdır. Embedding modellerinin ve context window’ların token sınırları olduğu ve pasaj düzeyinde retrieval sayfa düzeyindekinden daha hassas olduğu için kullanılır. Retrieval birimi sayfa değil, chunk’tır. Chunk boyutu bir dengedir (küçük = hassas/zayıf bağlam; büyük = zengin/gürültülü) ve hiçbir boyut, overlap değeri veya splitter atıf alınmasını garanti etmez. Overlap, sınırları korur ancak dizin boyutunu ve yinelemeyi artırır. Semantic chunking, fixed-size yöntemden güvenilir biçimde daha iyi değildir. Contextual prefix’ler bir chunk’ın anlamını netleştirebilir ancak güncelliğini yitirdiğinde retrieval sürecini yanıltabilir. “Lost in the Middle” — belirli 2023 modellerinde ve görevlerinde belgelenmiş bir konum etkisi — bir LLM’nin çoğu zaman bağlamının başlangıcını ve sonunu en iyi şekilde kullandığı anlamına gelir. Belirli bir chunk boyutu için optimizasyon yapamazsınız; Google da bunu denememeniz gerektiğini söylüyor. Ancak açık bir başlık hiyerarşisi altında yanıtla başlayan, kendi içinde yeterli bölümler temiz biçimde parçalanır ve alıntılanır. Bu, Google’ın passage ranking sistemindeki alt belge ilkesinin RAG’e uygulanmış hâlidir.

Chunking nedir ve neden vardır?

Getirme sistemleri dizine eklenmiş birimler üzerinde çalışır ancak herkese açık arama motorları, yayıncıların denetleyebileceği evrensel bir parça boyutu sunmaz. Evidence for this claim Retrieval systems can split files into chunks that are embedded and indexed for later search. Scope: OpenAI's retrieval implementation; chunk sizes, overlap, and indexing behavior are implementation-dependent. Confidence: high · Verified: 2026-07-14 OpenAI: Retrieval guide RAG araştırmaları, her yapay zekâ arama ürününün aynı mekanizmaları kullandığını kanıtlamadan önce-getir-sonra-üret kalıplarını destekler. Evidence for this claim Retrieval-augmented generation combines a generator with retrieved external passages or documents. Scope: The original RAG research architecture; it does not establish one optimal chunking strategy for every production system. Confidence: high · Verified: 2026-07-14 Lewis et al.: Retrieval-Augmented Generation

Chunking, bir belgenin bölümleri embeddings hâline getirilmeden, bir vector index içinde depolanmadan ve sorguları yanıtlamak üzere retrieval işlemine alınmadan önce daha küçük ve ayrı bölümlere — chunks veya passages — ayrılmasıdır. RAG (Retrieval-Augmented Generation) pipeline’larının temel adımlarından biridir. AI search SEO uzmanlarının en çok küçümsediği kısımdır; çünkü görünmezdir ve sorgu sırasında değil, ingestion sırasında gerçekleşir.

Bunu zorunlu kılan iki sorun vardır:

• Token sınırı sorunu. Gömme modelleri her girdi için sınırlı sayıda token kabul eder. Microsoft, text-embedding-3-small modelinin en fazla 8 191 token kabul ettiğini belirtiyor; diğer modellerin sınırları çok daha düşüktür. LLM’lerin de sonlu bağlam pencereleri vardır. Uzun bir sayfa tek bir birim olarak sığmaz ve bu nedenle bölünür.
• Getirme hassasiyeti sorunu. “Teknik SEO” hakkındaki 5 000 kelimelik bir sayfanın tek bir vektöre dönüştürülmesi bulanık ve ortalamaya dayalı bir sinyal üretir. Özellikle tarama bütçesini ele alan ve ayrı bir vektör olarak gömülen 400 kelimelik bir bölüm ise güçlü bir sinyaldir. Alt belge ayrıntı düzeyi, sistemin uzun ve çok konulu bir sayfadan ilgili tek pasajı çekebilmesini sağlar.

Bunun sonucu, buradaki en önemli fikirdir: AI search sistemlerinde retrieval birimi sayfa değil, chunk’tır. Tarama ve dizine ekleme gereklidir ancak yeterli değildir. Belirli bir sorguyu açıkça ve tek başına yanıtlayan bir chunk gerekir. Organik sonuçlarda #15 sırada yer alan bir sayfa, daha kolay çıkarılabilen bir pasaj içeriyorsa #1 sonucun atlandığı yerde AI atfı alabilir.

Chunking baştan sona nasıl çalışır?

1. Ingestion + splitting. Bir AI crawler sayfayı indirir; chunking algorithm metni (genellikle overlap içeren) bölümlere ayırır.
2. Embedding. Her chunk sayısal bir vector hâline gelir ve bir vector index içinde depolanır. (Bu, embeddings adımıdır.)
3. Retrieval + generation. Sorgu embedded edilir, en yakın chunk vector’leri vector search yoluyla çekilir ve retrieved chunks, yanıtı atıflarla yazan bir LLM’ye aktarılır.

Bu mimarinin tamamı, yoğun vector benzerliğiyle retrieval işleminin eski keyword yaklaşımını (BM25) ilk 20 pasaj doğruluğunda 9–19% absolute oranında geçtiğini ve belirli soruları yanıtlarken passage-level retrieval yönteminin document-level yöntemden daha iyi çalıştığını gösteren Dense Passage Retrieval (Karpukhin et al., 2020) çalışmasına dayanır. RAG paper (Lewis et al., 2020) bu kalıba adını verdi ve Wikipedia’dan 100-word passages kullandı. Web içeriği getiren her AI search sistemi bu pipeline’ın bir çeşidini çalıştırır.

Chunking stratejileri

Tek bir algorithm yoktur; sistemler çeşitli seçenekler arasından seçim yapar ve bunu zaman içinde değiştirir:

• Fixed-size — belirli bir token veya karakter sayısına ve bir miktar overlap’e göre böler. En yaygın yöntemdir. Microsoft örneği: 10–15% overlap ile “a fixed size sufficient for semantically meaningful paragraphs (for example, 200 words or 600 characters)”.
• Sentence / paragraph — rastgele bir token sayısı yerine doğal dil sınırlarından bölerek semantik birimleri korur.
• Semantic / content-aware — cümleleri embedding benzerliğine göre gruplandırır ve konu değiştiğinde bölerek her chunk’ın tek bir konuyla ilgili olmasını amaçlar.
• Hierarchical / recursive (RAPTOR) — bir sorgunun doğru soyutlama düzeyinde yanıtlanabilmesi için özetlerden oluşan bir ağaç (document → section → paragraph) kurar. RAPTOR (Sarthi et al., 2024), GPT-4 ile birlikte kullanıldığında zorlu bir QA benchmark’ında 20% absolute accuracy artışı bildirdi.
• Sliding window with overlap — bir sınırda bölünen cümlenin kaybolmaması için her chunk komşularıyla bazı token’ları paylaşır.
• Adaptive / query-dependent (Mix-of-Granularity) — eğitilmiş bir router, her sorgu için chunk boyutunu seçer. En gelişmiş yaklaşımdır ancak ticari sistemlerde henüz standart değildir.

Chunk boyutu ve overlap — temel denge

Herkesin sorduğu ayar budur ve dürüst yanıt şudur: duruma göre değişir:

• Küçük parçalar (128–256 token): Daha hassas getirme sağlar ancak yanıtın gerektirdiği çevresel bağlamı kaybedebilir.
• Büyük parçalar (512–1 024 token): Daha fazla bağlamı korur ancak getirme daha gürültülü olur; ilgili bölümle birlikte ilgisiz içeriği de getirirsiniz.

Araştırmalar tek bir kazanan göstermiyor. LlamaIndex değerlendirmesi kendi kurulumunda 1 024 token değerini en uygun bulurken Chroma’nın karşılaştırmalı testleri, 200 tokenlık özyinelemeli bölücünün metrikler genelinde tutarlı performans sergilediğini gösterdi. Ravi Theja’nın çıkarımı doğru yaklaşımı özetliyor: “Identifying the best chunk size for a RAG system is as much about intuition as it is empirical evidence.” Bu sayılar; tek bir ekibin, tek bir belge kümesi, gömme modeli ve değerlendirme görevi üzerindeki karşılaştırmalı testinde kazanan ayarları açıklar; evrensel bir ayarı değil. Hiçbir parça boyutu, örtüşme değeri veya bölücü; harici bir yapay zekâ sisteminin yanıtında getirilme, atıf, sıralama veya yer alma garantisi vermez. Her sağlayıcının işlem hattı kendi varsayılanlarını seçer ve bunları bildirimde bulunmadan değiştirebilir.

Overlap, bunun yeterince önemsenmeyen diğer yarısıdır. Overlap olmadan bir sınıra yakın içerik bölünüp kaybolabilir. Microsoft, “smoother transitions between chunks without excessive duplication” sağlamak için 25% overlap ile başlanmasını önerir; diğer kaynaklar 10–15% önerir. Ancak overlap ücretsiz değildir: Örtüşen token’lar iki kez embedded edilir ve depolanır. Bu, dizini büyütür ve retrieved set içinde birbirine yakın kopya pasajları yan yana getirebilir. Dolayısıyla ücretsiz bir güvenlik ağı değil, dizin boyutu ve yinelemeyle ilgili bir dengedir. Bunu ilkesel olarak değil, bir sınırın ne sıklıkla bir bilginin kaçırılmasına yol açtığına göre değerlendirin. İçerik açısından pratik nokta şudur: Önemli bir bilgiyi tam da chunk’ın bölünme ihtimali bulunan yere gömdüğünüzde sistemin onu bütün hâlde tutacağını varsaymayın.

Peki anlamsal parçalama her zaman kazanır mı? Hayır; rahatsız edici bulgu budur. Vectara’nın 2024 çalışması, gerçek dünya belgelerinde “performance differences are minimal” sonucuna ulaştı ve daha da önemlisi, gömme modelinin kalitesi parçalama stratejisinden daha etkiliydi. Yanıtları GPT-4o ürettiğinde stratejiler arasındaki farklar “negligible” idi. Bu sonuç Vectara’nın belge kümesine, modellerine ve değerlendirme yöntemine özgüdür. Anlamsal parçalamanın güvenilir bir varsayılan kazanan olmadığına dair kanıttır; hiçbir işlem hattında işe yaramadığının kanıtı değildir. SEO uzmanları için anlamı şudur: Kusursuz bir yapıya takılmak, içerik kalitesi ve anlamsal netlikten çok daha az önemlidir.

Chunk bağlamı: Prefix’ler neleri düzeltebilir, neleri düzeltemez?

Bir insan için açıkça anlaşılabilen bir chunk, çevresindeki belgeden ayrıldığında yine de kötü retrieval sonucu verebilir: bağlı olduğu bölüm, gerçekte konu aldığı varlık veya iki üst başlıkta belirtilen bir niteleyici eksik kalabilir. Belgelenmiş çözümlerden biri, chunk embedded edilmeden önce başına kısa ve chunk’a özgü bir context string (document title, ait olduğu section, chunk’ın gerçek konusu) eklemektir. Anthropic bu yaklaşımı contextual retrieval olarak adlandırır. Titles, section ancestry ve bir contextual prefix, aksi hâlde bağlamsız kalacak bir chunk’ın anlamını netleştirebilir ve eksik bağlamdan kaynaklanan retrieval hatalarını azaltabilir.

Ancak bu çözümün de kendine özgü bir hata biçimi vardır: Güncelliğini yitirmiş veya yanlış bağlam yalnızca yardımcı olmamakla kalmaz, retriever’ı etkin biçimde yanlış chunk’a yönlendirir. Sayfa yeniden düzenlendikten sonra artık bölümle eşleşmeyen bir başlıktan üretilmiş prefix veya chunk’ın kapsamını yanlış aktaran contextual summary, hiç prefix olmamasından daha kötüdür. Bağlamı korumak, kendi hata biçimine sahip bir pipeline tasarım tercihidir; tek yönlü bir iyileştirme olarak eklenip unutulamaz.

Google’ın passage ranking sistemi — chunking’in SEO’daki öncülü

Google, “RAG” yaygın bir moda terim hâline gelmeden çok önce alt belge ayrıntı düzeyini kullanıyordu. Search On 2020 etkinliğinde Prabhakar Raghavan, passage ranking sistemini şöyle duyurdu: “By better understanding the relevancy of specific passages, not just the overall page, we can find that needle-in-a-haystack information you’re looking for.” Sistem 10 Şubat 2021 tarihinde ABD’deki İngilizce sorgular için kullanıma açıldı ve sorguların yaklaşık %7’sini etkiliyor.

İnsanların bu konuda yanlış anladığı iki nokta vardır:

• Bu sistem “passage ranking” olarak adlandırılır; “passage indexing” değildir. Google’ın ilk duyurusunda “indexing” kullanıldı, ardından hızla şu düzeltme yapıldı: “this change doesn’t mean we’re indexing individual passages independently of pages.” Sayfa hâlâ bir bütün olarak dizine eklenir; ilgili pasaj, ek bir sıralama sinyali işlevi görür.
• Sıralamaya pasaj değil, sayfa girer. John Mueller: “Passage ranking is not about ranking a specific passage but understanding the content on a really long, not SEO optimized page, and ranking that page (not the passage) for a query where the passage is relevant.”

Passage ranking ve RAG chunking ortak bir ilkeye dayanır: Belirli bir sorguyla eşleştirmek için doğru birim çoğu zaman sayfa değil, paragraftır. Ancak sonuçları farklıdır: Passage ranking sayfanın sıralamasını yükseltir; RAG chunking ise üretilen yanıta girdi sağlamak için bir parçayı getirir. Aynı fikir, farklı mekanizma. (Dawn Anderson’ın haberine göre teknik temel DeepCT’dir: TF-IDF’nin yerini BERT’ten türetilmiş bağlamsal terim ağırlıkları alır; böylece terim sıklığı artık terim uygunluğuyla eşit sayılmaz.)

”Lost in the Middle” — yanıtınızın konumu önemlidir

Parçanız getirildikten sonra bile LLM bağlamında nereye yerleştiği, modelin onu gerçekten kullanıp kullanmayacağını etkiler. Stanford’un “Lost in the Middle” çalışması (Liu et al., 2023) şu sonuca ulaştı: “performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts.”

Bu bulgu varsayılan olarak evrensel biçimde geçerli değildir. Liu et al. tarafından 2023’te test edilen belirli model neslinde, adı belirtilen multi-document QA ve key-value retrieval görevlerinde ölçülmüş bir konum etkisidir. Günümüzdeki her modelin bağlamının ortasına yerleştirilen kanıtları görmezden geldiğini kanıtlamaz. Farklı mimariler, daha uzun etkin context window’lar ve yeni eğitim yöntemleri bu etkiyi daraltabilir veya genişletebilir. Bunu, her model için değişmez bir yasa değil, tasarımda dikkate alınması gereken belgelenmiş bir risk olarak değerlendirin.

İçerik açısından çıkarım her iki durumda da somut ve düşük risklidir: Yanıtla başlayın. Her bölümün ilk cümlesine tanımı, temel bulguyu veya doğrudan yanıtı koyun; dördüncü paragrafa gömmeyin. Bu, insanların metni hızla taramasına yardımcı olan aynı yanıtla başlama (BLUF) disiplinidir. Ayrıca etkinin görüldüğü modellerde bir context window’un ortasına düşme riskine karşı koruma sağlar.

Göremediğiniz pratik kısıtlamalar

• Chrome’un yaklaşık 30 pasaj sınırı. Dan Petrovic’in araştırması, Chrome’un DocumentChunker bileşeninin içeriği yaklaşık 200 kelimelik pasajlar hâlinde analiz ettiğini ve “only ever considers the first 30 passages of a page” olduğunu öne sürüyor. Anlamsal HTML yapısını yukarıdan aşağıya doğru ağaç boyunca gezer. Sonuç: En önemli içeriğiniz 10 000 kelimelik bir sayfanın sonunda değil, başlarında yer almalıdır.
• Parçalayıcıyı kontrol edemezsiniz. Despina Gavoyannis (Ahrefs) açık konuşuyor: “You can’t control how Google, ChatGPT, or Perplexity chunk your content. Their pipelines change based on cost, model, and context.” Ayrıca: “Manual ‘chunk optimization’ is impossible in practice."

"Chunk optimization” gerçekte nedir? Google uyarısı

Abartılı söylemlerin atladığı ayrıntı şudur. Google’ın 2026 tarihli yapay zekâ optimizasyonu rehberi bunu açıkça belirtir: “There’s no requirement to break your content into tiny pieces for AI to better understand it.” Google’ın sistemleri “are able to understand the nuance of multiple topics on a page and show the relevant piece to users.” Dolayısıyla hayır: İçeriğinizi katı 300 kelimelik bloklar hâlinde yeniden yazmayın.

Ancak bu, yapının önemsiz olduğu anlamına gelmez. Gavoyannis’in ifadesiyle: “Most SEOs using the term [chunk optimization] are just talking about good content structure.” Buzzword’ün altında yatan tavsiye sağlamdır; kullanılan çerçeve yalnızca yenilik derecesini abartır. Duane Forrester’ın sözü dönüşümü iyi özetliyor: “If traditional SEO optimized for clicks, GenAI systems optimize for chunks… Structure still wins.”

Peki gerçekte ne yapmalısınız? Chunk-ready içerik yazın:

• Her bölümde tek konu. Odaklı bir H2/H3, tutarlı bir parçayla temiz biçimde eşleşir.
• Yanıtla başlayın. Önce iddiayı sunun, desteği altına ekleyin.
• Kendi içinde yeterli bölümler. Test: Bu paragraf tek başına gösterilse anlamlı olur muydu? Olmazsa parça olarak çıkarıldığında da anlamını korumaz.
• Uygun uzunluk. Ana bölüm başına 200–500 kelime, doğal olarak 256–512 tokenlık parçalarla uyumludur: Yararlı olacak kadar eksiksizdir ancak yapay biçimde kısa değildir.
• Yapılandırılmış biçimler. Tablolar ve listeler, sistemlere algılayabilecekleri açık sınırlar verir. (Onely araştırması: Tablolar atıf oranlarını yaklaşık 2,5 kat artırır.)

Mike King’in çerçevesi yerinde bir güvence sunuyor: “chunking and writing for users is not mutually exclusive.” Okurun metni hızla taramasına yardımcı olan yapı, aynı zamanda temiz biçimde chunks oluşturur. Bir insanın deneyiminden ödün vererek robot için optimizasyon yapmıyorsunuz; içerik aynıdır.

Passage ranking ve RAG chunking — yan yana

Pipeline’ın neresinde yer alır?

Chunking, AI retrieval sürecindeki ilk adımdır: chunk → embed → store → retrieve → generate. Embeddings aşamasına girdi sağlar (her chunk bir vector hâline gelir); bu aşama vector search sürecine girdi sağlar (sorgu en yakın chunks ile eşleşir); o da RAG aşamasına girdi sağlar (retrieved chunks bir yanıta dönüşür). Daha yukarıda, içeriğinizin ilk kez ingestion işlemine alınmasını AI crawlers sağlar. Bu pipeline’ın geleneksel aramadaki sürümü için Arama Nasıl Çalışır? sayfasına bakın.

AI özeti

İleri düzey sürümün kısa özeti:

• Chunking = bir belgenin pasajlara bölünmesidir. Bu işlem gömme, dizine ekleme ve getirme öncesinde gerçekleşir. RAG işlem hattının ilk adımıdır ve sorgu sırasında değil, içeriğin sisteme alınması sırasında yapılır.
• Getirme birimi sayfa değil, parçadır. Dizine eklenmek yeterli değildir; belirli bir sorguyu tek başına yanıtlayan bir pasaj gerekir. Pasajı daha kolay çıkarılabiliyorsa 15. sıradaki bir sayfa, 1. sıradakinden daha çok atıf alabilir.
• Var olma nedeni: Gömme modellerinin ve bağlam pencerelerinin token sınırları vardır; pasaj düzeyinde getirme, sayfa düzeyinde getirmeden daha hassastır.
• Parça boyutu bir dengedir: Küçük (128–256 token) = hassas ancak bağlamı zayıf; büyük (512–1 024) = bağlamı zengin ancak gürültülü. Evrensel bir en iyi değer yoktur: LlamaIndex 1 024, Chroma 200 buldu ve hiçbir parça boyutu veya bölücü atıf garantisi vermez. Örtüşme (%10–25) parça sınırlarını korur ancak token’ları yineler ve dizini büyütür; gerçek sınır kayıplarına göre değerlendirilmelidir.
• Anlamsal parçalama, sabit boyutlu yöntemden güvenilir biçimde daha iyi değildir (Vectara 2024; o çalışmanın modelleri ve belgeleri için). Gömme modelinin kalitesi, parçalama stratejisinden daha önemlidir.
• Bağlamsal önekler (başlıklar ve bölüm üst başlıkları; Anthropic’in “contextual retrieval” yaklaşımı) bağlamsız bir parçanın anlamını netleştirebilir. Ancak eski veya yanlış bir önek getirme sürecini etkin biçimde yanıltır; kendine özgü hata biçimi bulunan bir tasarım tercihidir.
• “Lost in the Middle” (Liu et al., 2023): Her güncel modelin bağlamın ortasındaki bilgileri görmezden geldiğinin kanıtı değil, adı belirtilen görevlerde ve 2023 dönemi modellerinde ölçülmüş bir konum etkisidir. Çalışmadaki LLM’ler bağlamın başlangıcını ve sonunu en iyi kullandığından, her durumda bölüme yanıtla başlayın.
• Google’ın passage ranking sistemi (2020/2021, sorguların yaklaşık %7’si) aynı alt belge ilkesini kullanır. Ancak pasajları ayrı ayrı dizine eklemek yerine sayfayı sıralayan bir sinyal işlevi görür. RAG chunking ise bir parçayı getirir.
• Belirli bir parça boyutu için optimizasyon yapamazsınız. Google da içeriği küçük parçalara ayırmanız gerekmediğini söylüyor. Yapabileceğiniz şey, açık başlıklar altında yanıtla başlayan, kendi içinde yeterli ve odaklı bölümler yazmaktır; bu da iyi içerik yapısıdır.

Resmî dokümantasyon

Passage-level retrieval ve chunking hakkında birincil kaynak dokümantasyonu.

Google

• A Guide to Google Search Ranking Systems — passage ranking sistemini “an AI system we use to identify individual sections or ‘passages’ of a web page.” olarak tanımlar.
• Optimizing your website for generative AI features — Google’ın içeriği küçük parçalara ayırmanız gerekmediği yönündeki görüşü (son güncelleme: 15 Haziran 2026).
• In-Depth Guide to How Google Search Works — bu yapay zekâ sürümünün genişlettiği tarama → dizine ekleme → sunma işlem hattı.

Microsoft / Azure AI Search

• Chunk large documents for vector search — büyük sağlayıcılar arasındaki en kapsamlı resmî chunking rehberi: parça boyutu varsayılanları (512 token), örtüşme (%25 başlangıç noktası) ve sabit/değişken/anlamsal teknikler tablosu (son güncelleme: 8 Haziran 2026).

OpenSearch

• Text chunking — yerleşik bir vector-search ingestion pipeline özelliği olarak chunking.

Uygulayıcı kaynağı (sağlayıcı dokümanları)

• Pinecone — Chunking Strategies — temel strateji sınıflandırması ve hepsine yön veren test: “If the chunk of text makes sense without the surrounding context to a human, it will make sense to the language model as well.”

Kaynaktan alıntılar

Google’ın kayda geçmiş açıklamaları. Her bağlantı, kaynak sayfadaki alıntılanan bölüme doğrudan gider.

Google — passage ranking nedir, ne değildir?

• “By better understanding the relevancy of specific passages, not just the overall page, we can find that needle-in-a-haystack information you’re looking for.” — Prabhakar Raghavan, Google SVP, October 2020 (Search Engine Land aracılığıyla). Alıntıya git
• “this change doesn’t mean we’re indexing individual passages independently of pages.” — Google, October 20, 2020 tarihli açıklama (Search Engine Land aracılığıyla). Alıntıya git
• “passage ranking launched yesterday afternoon Pacific Time for queries in the US in English.” — @searchliaison, February 11, 2021 (Search Engine Land aracılığıyla). Haberi okuyun

Google — passage ranking pasajı değil, sayfayı sıralar

• “Passage ranking is not about ranking a specific passage but understanding the content on a really long, not SEO optimized page, and ranking that page (not the passage) for a query where the passage is relevant.” — John Mueller, Google Search Advocate (Search Engine Roundtable aracılığıyla). Haberi okuyun

Google — içeriğinizi chunk’lara ayırmanız gerekip gerekmediği hakkında

• “There’s no requirement to break your content into tiny pieces for AI to better understand it.” — Google Search Central, “Optimizing your website for generative AI features.” Rehberi okuyun

Microsoft Azure AI Search — chunking neden gereklidir?

• “Partitioning large documents into smaller chunks can help you stay under the maximum token input limits of chat completion and embedding models.” — Microsoft Azure AI Search dokümanları. Dokümanları okuyun

Chunking — kısa başvuru

Chunking stratejilerinin karşılaştırması

Bir bakışta chunk boyutu

Kısa bilgiler

• Yapay zekâ arama sistemlerinde getirme birimi sayfa değil, parçadır.
• Gömme modeli sınırı örneği: text-embedding-3-small = 8 191 token.
• Hiçbir parça boyutu, örtüşme değeri veya bölücü; getirilme, atıf ya da bir yapay zekâ yanıtında yer alma garantisi vermez. Bunlar evrensel ayarlar değil, işlem hattı varsayılanlarıdır.
• Örtüşme ücretsiz değildir: Örtüşen token’lar iki kez depolanır; dizini büyütür ve birbirine çok benzeyen pasajların birlikte getirilmesi riskini artırır.
• Bağlamsal önekler (başlık ve bölüm üst başlıkları) bir parçanın anlamını netleştirebilir; ancak eski veya yanlış bir önek yardımcı olmak yerine getirme sürecini yanıltır.
• “Lost in the Middle”: 2023 çalışmasındaki görevlerde ve modellerde LLM’ler bağlamın başlangıcını ve sonunu en iyi kullandı → modelden bağımsız olarak yanıtla başlayın.
• Chrome’un DocumentChunker bileşeninin yalnızca ilk yaklaşık 30 pasajı (her biri yaklaşık 200 kelime) dikkate aldığı bildiriliyor → temel içeriği erkenden sunun.
• Google: passage ranking ≠ passage indexing. Sıralamaya sayfa girer; pasaj bir sinyal işlevi görür.
• Google: İçeriği küçük parçalara ayırmanız gerekmez. Parçalamak yerine yapılandırın.

Zihinsel modeller

1. Retrieval pipeline — chunk → embed → store → retrieve → generate. Chunking ilk adımdır. İçeriğiniz atıf almıyorsa zinciri inceleyin: Tarandı mı, tutarlı bir chunk üretildi mi, bu chunk sorguyla eşleşti mi, LLM’nin kullanacağı bir konuma yerleşti mi?

2. Birim sayfa değil, chunk’tır. “Sayfam dizine eklendi mi?” diye düşünmeyi bırakıp “Sayfamda bu belirli sorguyu tek başına yanıtlayan bir pasaj var mı?” diye düşünmeye başlayın. Dizine eklenmek gereklidir; atfı kazandıran şey, içeriğin kolayca çıkarılabilmesidir.

3. Boyut dengesi — hassasiyet ve bağlam. Küçük chunks = güçlü ancak zayıf bağlam. Büyük chunks = zengin ancak gürültülü. Evrensel bir yanıt yoktur ve zaten boyutu siz belirlemezsiniz. Bu nedenle kontrol edebildiğiniz şeyi optimize edin: Her bölümü her iki ayrıntı düzeyinde de çalışacak kadar tutarlı yapın.

4. Yanıtla başlamak, ortada kalmaktan iyidir. “Lost in the Middle”, context window içindeki konumun önemli olduğunu söyler. Her bölüme tanımla veya iddiayla başlayın. İnsanların metni hızla taramasına yardımcı olan aynı disiplin, temel noktanızı ölü bölgenin dışında tutar.

5. Parçalamayın, yapılandırın. Google, içeriği küçük parçalara ayırmamanızı söylüyor; dolayısıyla çözüm yapay chunking değildir. Çözüm, açık bir başlık hiyerarşisi, her bölümde tek konu ve kendi içinde yeterli paragraflardır. “Chunk optimization” çoğunlukla yeni bir ad taşıyan iyi içerik yapısıdır.

6. Passage ranking ≠ RAG chunking. Aynı ilke (alt belge ayrıntı düzeyi), farklı sonuç. Passage ranking, sayfayı sıralayan bir signal işlevi görür; RAG chunking ise yanıt için retrieves a chunk. SEO dönemindeki kavramla AI dönemindekini birbirine karıştırmayın.

Chunk-ready içerik kontrol listesi

İçeriğinizin bölündüğünde, retrieved edildiğinde ve bağlamından ayrı alıntılandığında anlamını koruması için kontrol listesi:

• Her H2/H3 bölümü tek bir konuyu veya soruyu ele alır; iki konuyu birleştiren bölümler yoktur.
• Her bölüm yanıtla başlar (önce tanım / temel iddia, ardından destek); yanıt 3–4. paragrafa gömülmemiştir.
• Her ana bölüm kendi içinde yeterlidir: Çevresinde hiçbir şey olmadan tek başına okunduğunda anlamlıdır.
• Bölümler uygun uzunluktadır (~200–500 words): Eksiksizdir ve yapay biçimde küçük bloklara ayrılmamıştır.
• En önemli içerik sayfanın başlarında yer alır (Chrome’un yalnızca ilk ~30 passages bölümünü dikkate aldığı bildiriliyor).
• Başlık hiyerarşisi temizdir (mantıksal H1 → H2 → H3); bu, chunker’ın izlediği yapısal sinyalin bir parçasıdır.
• Birlikte kalması gereken bilgiler olası bir sınırın iki yanına dağılmamıştır (ör. iddianın bir paragrafta, kanıtının üç paragraf sonra bulunması).
• İçerik gerçekten liste niteliğindeyse tablolar / listeler kullanılmıştır (chunker’ların algıladığı açık sınırlar ve daha yüksek atıf oranları).
• Her şey katı kelime sayılı bloklar hâlinde yeniden yazılmamıştır; Google bunun gerekli olmadığını söylüyor.

Birden çok intent için tek ve dev bir bölüm yazmak

Tanımları, uygulamayı, istisnaları ve ölçümü ele alan uzun bir blok, sayfa olarak yararlı ancak retrieved passage olarak gürültülü olabilir. Farklı soruları başlıklar altında ayırın ve her bölüme tek başına anlaşılmasını sağlayacak kadar yerel bağlam verin.

Her cümleyi kendi başlığına ayırmak

Çok küçük chunks, niteleyicileri ve ilişkileri kaybedebilir. Varsayımsal bir token sayısı için optimizasyon yapmayın. Eksiksiz bir fikri, kısıtlarını ve destekleyici kanıtını bir arada tutun.

Bağlamsız bir geri gönderimle başlamak

“this,” “it,” veya “however” ile başlayan pasajlar, öznenin adını belirten metinden ayrılabilir. Önemli bölümlere konuyu ve yanıtı tanımlayan doğrudan bir cümleyle başlayın.

Overlap’i zorlamak için metni yinelemek

Yinelenen paragraflar, birbiriyle rekabet eden yakın kopya pasajlar ve daha kötü bir okuma deneyimi oluşturur. Retrieval sistemleri overlap’i dahili olarak ekleyebilir; yazarlar düzyazıyı kopyalamak yerine açık geçişler ve kendi içinde yeterli bölümler kullanmalıdır.

Prompt: Pasaj bağımsızlığını denetleme

Review the article section by section as if each section could be retrieved without its
neighbors. For each heading, state the question it answers, whether the opening sentence
names the subject, what context is missing, whether unrelated intents are mixed, and the
smallest edit that makes the section self-contained. Preserve necessary qualifications
and evidence. Do not target an arbitrary token count or rewrite the author's voice.

Article:
[PASTE ARTICLE WITH HEADINGS]

Prompt: Aşırı yüklü bir bölümü ayırma

This section covers several ideas. Propose a minimal heading structure that groups one
complete intent per section. For each proposed section, write only an answer-first
opening sentence and list which existing paragraphs belong under it. Do not add facts,
remove caveats, duplicate prose, or turn every sentence into a heading.

Section:
[PASTE HEADING AND CONTENT]

DevTools Console: Uzun rendered sections öğelerini işaretleme

Bunu bir makale sayfasında çalıştırın. Karakter eşiği, search-engine chunk sınırı değil, incelemeye yardımcı bir ölçüttür.

console.table([...document.querySelectorAll('main h2, main h3')].map((heading, i, all) => {
  let text = '';
  for (let node = heading.nextElementSibling; node && !all.includes(node); node = node.nextElementSibling) text += ` ${node.textContent}`;
  return { heading: heading.textContent.trim(), characters: text.trim().length };
}).filter(row => row.characters > 2000));

Regex: Markdown’daki bağlamsız bölüm başlangıçlarını bulma

Bu multiline pattern, ilk düzyazı sözcüğü yaygın bir geri gönderim olan başlıkları işaretler. Her eşleşmeyi manuel olarak inceleyin.

^#{2,4}\s+.+\n+(?:\n|>.*\n|\s*)*(This|That|It|They|These|Those|However|Therefore|Also|And|But|So|Then)\b

Passage QA araçları

• Bir browser outline veya document map, ilgisiz soruları birleştiren ya da uzun bölümleri alt başlıksız bırakan başlıkları hızla ortaya çıkarır.
• Bir vector database veya embedding playground, kontrollü bir retrieval testinde chunk boyutunun etkisini gösterebilir. Ancak tek bir modelin sonucunu evrensel bir SEO reçetesine dönüştürmeyin.
• Search Console ve atıf takibi sayfa sonuçlarını ölçer. Bir arama platformunun depoladığı özel ve kesin chunk’ı size gösteremez.

Chunking odaklı bir yeniden yazımı doğrulama

Kendinizi test edin: Chunking

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• What We Actually Know About Optimizing for LLM Search — Chrome DocumentChunker’ın 30 pasaj bulgusunu ve yapay zekâ getirme sistemlerinin içeriğinizi gerçekte nasıl ele aldığını kapsar.

Temel araştırmalar

• Dense Passage Retrieval (Karpukhin et al., 2020) — yoğun pasaj getirme yönteminin anahtar sözcük eşleştirmesini neden geçtiği ve modern RAG’in temelindeki mimari.
• Retrieval-Augmented Generation (Lewis et al., 2020) — RAG’e adını veren ve Wikipedia’dan 100 kelimelik pasajlar kullanan çalışma.
• Lost in the Middle (Liu et al., 2023) — LLM’lerin bağlamın başlangıcını ve sonunu en iyi kullanması ve yanıtla başlamanın önemi.
• RAPTOR (Sarthi et al., 2024) — özet ağacı üzerinden hiyerarşik/özyinelemeli parçalama.
• Is Semantic Chunking Worth the Cost? (Vectara, 2024) — anlamsal parçalamanın sabit boyutlu yöntemden güvenilir biçimde daha iyi olmadığını bulan çalışma.

SEO açısından karşı görüş (bunu okuyun)

• SEO Chunk Optimization is Overrated (Despina Gavoyannis, Ahrefs) — “chunk optimization” kavramının çoğunlukla iyi içerik yapısından ibaret olduğu ve sistemlerin içeriğinizi nasıl parçaladığını kontrol edemeyeceğiniz yönündeki görüş. Konunun en önemli ayrıntısı.

Uygulayıcı rehberleri

• Pinecone — Chunking Strategies — temel strateji sınıflandırması.
• LlamaIndex — Evaluating the Ideal Chunk Size (Ravi Theja) — 1 024 sonucuna ulaşan 128/256/512/1024/2048 testi.
• Databricks — Chunking Strategies for RAG — alana özgü yönlendirmeler içeren altı strateji.

Sektörden kaynaklar

• Content Chunking Guide (Search Engine Land) — tanımı, kullanıcı deneyimi kökenlerini, makro/mikro/atomik parça türlerini ve chunking’in yapay zekâ destekli getirmeyle bağlantısını kapsar.
• Chunk, Cite, Clarify, Build (Benu Aggarwal, Search Engine Land) — yapay zekâ araması için dört parçalı içerik çerçevesi; “content now competes in a probability-weighted lottery of answer generation” görüşünü sunar.
• Content Chunking: What Is It & Should You Care? (Semrush) — Mike King’in “chunking and writing for users is not mutually exclusive” alıntısını ve soru-cevap biçimi testlerini içeren uygulayıcı özeti.
• Chunked, Retrieved, Synthesized (Duane Forrester) — büyük bağlam pencerelerine rağmen yapının neden kazandığına ilişkin eski bir Bing çalışanının görüşü; “If traditional SEO optimized for clicks, GenAI systems optimize for chunks.”
• LLM-Friendly Content (Onely / Bartosz Góralewicz) — tabloların atıf oranlarını 2,5 kat artırdığı ve liste biçimindeki içeriklerin en yüksek yapay zekâ atıflarının %50’sini oluşturduğu bulgularının birincil kaynağı.
• 2025 AI Citation & LLM Visibility Report (The Digital Bloom) — LLM atıflarını öngören etkenlere ilişkin veriler; marka arama hacmi, istatistikler ve alıntıların görünürlüğü artırdığı gösteriliyor.
• The Ultimate Guide for Chunking Strategies (Agenta.ai) — parçalama yöntemleri genelindeki Chroma karşılaştırma verilerini içeren kapsamlı ve geliştirici odaklı strateji sınıflandırması.

Alıntılanmaya değer istatistikler

• %9–19 mutlak fark — yoğun pasaj getirme (DPR) yönteminin ilk 20 pasaj doğruluğunda BM25 anahtar sözcük eşleştirmesini geçme oranı. Anahtar sözcüklere değil, anlama göre getirme yaklaşımının gerekçesi. Karpukhin et al., 2020
• Sorguların yaklaşık %7’si — Google’ın passage ranking sisteminin tam kullanıma sunulduğunda etkilediği arama sorgularının oranı (ABD’deki İngilizce sorgular için 10 Şubat 2021 tarihinde kullanıma açıldı). Haber
• +%20 mutlak doğruluk — RAPTOR’ın GPT-4 ile eşleştirildiğinde zorlu bir soru-cevap karşılaştırmalı testinde sağladığı hiyerarşik parçalama artışı. Sarthi et al., 2024
• Gömme modeli > parçalama stratejisi — Vectara’nın 2024 bulgusu: Gerçek belgelerde model kalitesi, parçalama yönteminin anlamsal veya sabit boyutlu olmasından daha fazla etkiliydi; farklar “minimal” idi. Çalışma
• İlk yaklaşık 30 pasaj — Dan Petrovic’in araştırmasına göre Chrome’un DocumentChunker bileşeninin sayfa başına dikkate aldığı bildirilen pasaj sayısı (her biri yaklaşık 200 kelime); temel içeriği başta sunma gerekçesi. Ahrefs aracılığıyla
• Yaklaşık 2,5 kat atıf oranı — Onely’nin, tabloların yapay zekâ atıf oranlarını artırdığı ve liste biçimindeki içeriklerin en yüksek yapay zekâ atıflarının yaklaşık %50’sini oluşturduğu bulgusu. Yapı yardımcı olur. Onely
• Google AI Overviews sonuçlarının %93,67’si ilk 10 organik sonuçtan en az birine atıf içeriyor. Organik sıralamayla yapay zekâ atfı arasında güçlü ancak mutlak olmayan bir ilişki vardır; pasaj düzeyindeki eşleşme sıralama konumunu geçersiz kılabilir. The Digital Bloom, 2025 AI Citation Report

Değişiklik günlüğü