# Late Chunking ve Bağlamsal Getirme: 2026 RAG Parçalama Rehberi

> Source: https://sukruyusufkaya.com/blog/late-chunking-baglamsal-getirme-rag-2026
> Updated: 2026-07-15T04:45:03.194Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Late chunking, bağlamsal getirme ve agentic RAG ile 2026 parçalama stratejisi. Hangi sorguya hangi pipeline? Üretime dönük bir karar rehberi.

**TL;DR —** RAG sistemlerinde en çok göz ardı edilen adım chunking, yani metni parçalara bölmek. 2026'da işin sırrı "hangi chunking en havalı" değil, "hangi soruya hangi boru hattı" sorusunda. Ben sahada şunu öneriyorum: recursive ~512 token'lık parçalarla, token-doğru sayımla başla; chunk boyutunu sorgu tipine göre ayarla; getirme metrikleri gerçekten gerekçe verdiğinde semantic, hierarchical, late chunking veya contextual retrieval'a terfi et. Late chunking, önce tüm belgeyi uzun bağlamlı bir embedding modeliyle gömüp sonra token gömülerini parçalara ayırarak bağlamı korur. Contextual retrieval ise sınır bağlamı kaybı darboğazsa BM25 ve reranking ile birlikte en iyi sonucu verir; bir IEEE çalışması metadata ile zenginleştirilmiş getirmede %82,5 kesinlik, yalnızca içerik tabanlı getirmede %73,3 kesinlik bulmuş. Karmaşık, çok adımlı sorularda agentic RAG kabaca 5 kat daha iyi doğruluk sağlıyor; hukuk, sağlık ve finans gibi doğruluğun pazarlık konusu olmadığı yerlerde ek maliyete değer. En iyi üretim sistemleri adaptif yönlendirme ile basit soruya ucuz yol, gereğinde tam cephaneyi açıyor.

## Neden yıllardır aynı hatayı yapıyoruz

Kurumsal RAG projelerine danışmanlık verirken şunu sürekli görüyorum: ekipler haftalarca en yeni embedding modelini, en yeni vektör veritabanını, en yeni LLM'i tartışıyor; ama chunking'i "bir fonksiyon yazarız geçer" diye baştan savuyor. Sonra demo günü geliyor, model belgede açıkça yazan bir bilgiyi bulamıyor ve herkes "model aptal" diyor. Model aptal değil. Sen ona, cevabın yarısını bir parçaya, diğer yarısını başka bir parçaya bölerek verdin ve ikisini asla yan yana getiremedi.

Bu yazıda süslü kelimeler yerine sahadan çıkardığım pratik bir chunking oyun kitabını paylaşacağım. Amacım, bu yazıyı okuyup masana döndüğünde "tamam, pazartesi sabahı şunu yapacağım" diyebilmen. Türkiye'de çalışan biri olarak Türkçe getirmenin kendine has huysuzluklarını ve KVKK gölgesinde on-prem veriyle çalışmanın gerçeklerini de araya sıkıştıracağım, çünkü bunlar bloglarda nadiren konuşuluyor ama projelerin kaderini belirliyor.

## Önce ortak dil: chunking, embedding, reranking, BM25 ve query decomposition

Ekip içinde herkes aynı kelimeleri farklı anlıyorsa hiçbir mimari tartışması ilerlemiyor. O yüzden en baştan, sıkılmadan, net tanımlar koyalım. Bunları zaten biliyorsan bile bir gözden geçir; çünkü çoğu hatanın kökü, bu kavramların "yaklaşık" bilinmesinde.

**Chunking (parçalama).** Elindeki uzun metni, arama sırasında getirilecek ve dil modeline verilecek küçük parçalara bölme işi. Neden bölüyoruz? Çünkü ne embedding modelleri sınırsız uzunlukta metni anlamlı tek bir vektöre sığdırabiliyor, ne de LLM'e "al bütün 400 sayfalık kılavuzu" deme lüksümüz var. Parça çok büyük olursa, tek bir vektör içine birbirinden kopuk bir sürü konu sıkışıyor ve vektör "bulanıklaşıyor"; parça çok küçük olursa cevabın bağlamı kayboluyor. Chunking, bu iki uç arasındaki denge sanatı.

**Embedding (gömme).** Bir metin parçasını, anlamını sayısal olarak temsil eden bir vektöre (yüzlerce ya da binlerce boyutlu bir sayı dizisine) dönüştürme işlemi. Anlamca yakın metinler bu uzayda birbirine yakın düşer. "Fatura ödeme süresi" ile "ödeme vadesi" cümleleri, kelimeleri farklı olsa da yakın vektörler üretir. RAG'ın "anlamsal arama" gücü buradan gelir.

**BM25.** Klasik, kelime tabanlı bir arama skoru. Anlam falan bilmez; hangi terim, belgede ve koleksiyonda ne sıklıkta geçiyor ona bakar. Kulağa ilkel gelebilir ama tam da bu yüzden çok değerli: nadir bir ürün kodunu, bir kanun madde numarasını, bir hata kodunu ararken embedding'ler kaybederken BM25 tam isabet yapar. Meşhur "hibrit arama" dediğimiz şey, BM25 ile embedding tabanlı anlamsal aramanın skorlarını birleştirmektir. Biri anlamı, diğeri tam kelime eşleşmesini yakalar; ikisi birlikte tek başlarına olduğundan çok daha güçlüdür.

**Reranking (yeniden sıralama).** İlk arama, hızlı olsun diye kaba bir eleme yapar ve mesela 50 aday parça getirir. Reranker ise daha ağır, daha akıllı bir model olup bu 50 adayı sorguyla birlikte tek tek tartar ve "asıl ilgili olan bunlar" diye yeniden sıralar. Böylece LLM'e giden ilk 5 parça gerçekten en isabetli olanlar olur. Reranking, ucuz bir iyileştirme olarak çoğu sistemde en yüksek getiriyi sağlayan adımdır.

**Query decomposition (sorgu ayrıştırma).** Kullanıcı "2024'te en çok satan ürünümüzün geçen yıla göre kâr marjı nasıl değişti?" diye sorduğunda, bu tek bir aramayla çözülemez. Sistemin önce "en çok satan ürün hangisi", sonra "bu ürünün 2024 marjı", sonra "2023 marjı" alt sorularına ayırıp her birini ayrı arayıp sonuçları birleştirmesi gerekir. İşte bu bölme işine query decomposition diyoruz ve agentic RAG'ın kalbinde bu yatıyor.

Bu beş kavramı içine sindiren bir ekiple çalışmak, sinmeyenle çalışmaktan on kat verimli. O yüzden bu bölümü asla atlamıyorum.

## Chunking'in klasik tuzağı: bağlam sınırda ölür

Standart yaklaşım şudur: belgeyi al, parçalara böl, her parçayı bağımsız olarak embedding modeline ver, çıkan vektörü sakla. Sorun şu ki her parça kendi başına, dünyadan habersiz gömülüyor.

Somut bir örnek vereyim. Bir sigorta poliçesi belgesinde şöyle bir yapı var: baş tarafta "Bu poliçe X A.Ş. için düzenlenmiştir" yazıyor, otuz paragraf sonra "Teminat üst limiti 500.000 TL'dir" yazıyor. Bu iki cümle iki ayrı parçaya düşerse, ikinci parça embedding'i "kimin teminatı" bilgisinden tamamen yoksun kalır. Kullanıcı "X A.Ş.'nin teminat limiti nedir" diye sorduğunda, o kritik parça vektör uzayında sorguya yeterince yakın düşmez, çünkü içinde "X A.Ş." geçmiyor. Cevap belgede aynen yazıyor ama sistem bulamıyor. İşte buna sınır bağlamı kaybı diyorum ve kurumsal RAG'ın bir numaralı sessiz katili budur.

Bu tuzağı gördükten sonra insan panikleyip "o zaman her şeyi en gelişmiş yönteme çevireyim" diyor. Dur. Önce hangi ilaçların hangi hastalığa iyi geldiğini konuşalım.

## İlaç 1: Contextual Retrieval — her parçaya kimliğini geri ver

Contextual retrieval'ın fikri çok sade ve tam da yukarıdaki hastalığı hedef alıyor: her parçayı saklamadan önce, o parçanın belgedeki yerini ve bağlamını özetleyen kısa bir açıklama ekle. Yani "Teminat üst limiti 500.000 TL'dir" parçasının başına, otomatik üretilmiş "Bu bölüm X A.Ş. için düzenlenen sağlık poliçesinin teminat limitlerini anlatır" gibi bir bağlam cümlesi iliştir, sonra bu zenginleştirilmiş metni embedding'le ve BM25 indeksine koy.

Sahada bu yöntem, özellikle sınır bağlamı kaybının darboğaz olduğu durumlarda BM25 ve reranking ile eşleştirildiğinde en iyi sonucu veriyor. Neden üçü birlikte? Çünkü bağlam cümlesi hem anlamsal aramayı (embedding) hem tam kelime aramasını (BM25) besliyor; reranking de zenginleşmiş adaylar arasından en isabetlisini seçiyor. Bunun ne kadar fark yarattığını gösteren somut bir veri var: bir IEEE çalışması, metadata ile zenginleştirilmiş getirmenin %82,5 kesinliğe ulaştığını, yalnızca içerik tabanlı getirmenin ise %73,3'te kaldığını bulmuş. Aradaki dokuz puanlık fark, kurumsal bir destek sisteminde "kullanıcı cevabı buldu" ile "kullanıcı telefona sarıldı" arasındaki farktır.

Maliyet tarafını dürüstçe söyleyeyim: her parça için bir bağlam cümlesi üretmek, indeksleme aşamasında ekstra LLM çağrısı demek. Bu bir kereye mahsus bir maliyet (belge değişmedikçe tekrar üretmezsin) ama büyük koleksiyonlarda hatırı sayılır tutabilir. Yine de, doğruluğun kritik olduğu yerlerde bu yatırımın karşılığını fazlasıyla alıyorsun.

## İlaç 2: Late Chunking — sırayı tersine çevir

Late chunking, klasik akışın sırasını tersine çeviren zarif bir fikir. Klasik yöntemde önce parçalıyor, sonra her parçayı ayrı ayrı gömüyorduk. Late chunking'de ise önce tüm belgeyi (ya da uzun bir pasajı) uzun bağlamlı bir embedding modeliyle bir bütün olarak işliyorsun; model her token için bağlamı içine sinmiş token gömüleri üretiyor. Ancak bundan sonra bu token gömülerini parçalara ayırıyor ve her parça için o token gömülerinin havuzlanmış (ortalaması alınmış gibi) bir vektörünü üretiyorsun.

Farkı yakaladın mı? "Teminat üst limiti 500.000 TL'dir" cümlesinin token'ları, gömme anında belgenin başındaki "X A.Ş." bilgisini zaten görmüştü, çünkü embedding modeli tüm belgeyi bir arada okudu. Dolayısıyla o parçanın vektörü, açıkça içinde "X A.Ş." yazmasa bile o bağlamı taşıyor. Late chunking tam olarak bunu yapıyor: parçalara bölme işini gömmeden sonraya erteleyerek her parçanın tam bağlamsal bilgisini koruyor ve getirmeyi belirgin biçimde iyileştiriyor.

Late chunking'in contextual retrieval'a göre güzel yanı, indeksleme sırasında parça başına ekstra LLM çağrısı gerektirmemesi; bağlamı, ekstra metin üretmeden, gömme matematiğinin içinde koruyor. Şartı ise uzun bağlamlı bir embedding modeline ihtiyaç duyman. Belgen embedding modelinin bağlam penceresine sığdığı sürece bu yöntem çok temiz çalışıyor; sığmayan devasa belgelerde ise pasajlara bölüp her pasajı kendi içinde late chunking'e sokmak gibi melez yaklaşımlara gidiyorsun.

## İlaç 3: Agentic RAG — çok adımlı sorular için ağır topçu

Bazı sorular tek atışla çözülmez. "Geçen çeyrekte en çok şikâyet alan üç şubemizin ortalama çözüm süresi, şirket ortalamasının ne kadar üstünde?" sorusu, tek bir vektör aramasıyla asla cevaplanamaz. Bu, birden çok adımı ve ara sonuçları birbirine bağlamayı gerektiren, klasik bir çok-adımlı (multi-hop) sorudur.

Agentic RAG'ın yaptığı şey tam da bu: bir ajan, soruyu alt sorulara ayrıştırıyor (query decomposition), her alt soru için ayrı aramalar yapıyor, ara sonuçları biriktiriyor, gerekirse yeni sorular türetiyor ve çok adımlı akıl yürütmeyle nihai cevabı kuruyor. Bu, düz "ara-getir-yapıştır" RAG'dan temelde farklı bir zihniyet. Karmaşık, çok adımlı sorularda agentic RAG, ajan tabanlı getirme ve çok adımlı akıl yürütme sayesinde kabaca 5 kat daha iyi doğruluk sağlıyor.

Bedava değil elbette: her ajan adımı ekstra LLM çağrısı, ekstra gecikme ve ekstra maliyet demek. O yüzden ben bunu her yere serpiştirmeyi değil, doğruluğun pazarlık konusu olmadığı yerlere saklamayı öneriyorum. Hukuk, sağlık ve finans; bir cevabın yanlış olması dava, yanlış teşhis ya da maddi zarar demekse, o 5 kat doğruluk artışı ek maliyete fazlasıyla değer. Buna karşılık "iade politikamız kaç gün" sorusu için ajan çalıştırmak, çekiçle sinek öldürmektir.

## Pragmatik yol: nereden başlanır, ne zaman terfi edilir

Şimdi işin en önemli kısmına, sahadan çıkardığım oyun kitabına geliyoruz. En sık yapılan hata, projeye en gelişmiş yöntemle başlamak. Bunu yapma. Benim önerdiğim yol şu:

**Adım 1 — Sağlam bir temelle başla.** Recursive (özyinelemeli) bölme ile yaklaşık 512 token'lık parçalarla başla ve mutlaka token-doğru sayım kullan. "Token-doğru" vurgusu önemli: karakter ya da kelime sayarak yaklaşık bölme yapanlar, embedding modelinin gerçek token sınırını aşıp sessizce metin kırptığını fark etmiyor. Modelin kendi tokenizer'ıyla say ki 512 dediğinde gerçekten 512 olsun. Recursive bölme, önce paragraf, sonra cümle, sonra kelime sınırlarını deneyerek metni doğal yerlerden böler; cümlenin ortasından kesmeye göre çok daha az bağlam koparır.

**Adım 2 — Chunk boyutunu sorgu tipine göre ayarla.** Her soruya tek beden chunk uymaz. Kullanıcıların kısa, nokta atışı olgusal sorular mı ("iade süresi kaç gün") yoksa geniş, sentez gerektiren sorular mı ("bu iki sözleşme arasındaki temel farklar neler") sorduğuna bak. Nokta atışı sorular için küçük parçalar keskinlik verir; sentez soruları için daha büyük parçalar bağlamı bir arada tutar. Elindeki gerçek sorgu günlüklerine bakmadan bu ayarı yapamazsın; o yüzden sistemi yayına aldıktan sonra sorguları izle.

**Adım 3 — Metrikler gerekçe verdiğinde terfi et.** Semantic chunking (anlam bütünlüğüne göre bölme), hierarchical chunking (belge hiyerarşisini koruyan çok katmanlı bölme), late chunking ya da contextual retrieval'a ancak ve ancak getirme metriklerin bu ek maliyeti hakediyorsa geç. Yani önce ölç: recall@k, precision, kullanıcı memnuniyeti. Temel kurulum "yeterince iyi" ise, gelişmiş yönteme geçmenin getireceği marjinal iyileşme ek karmaşıklığa ve maliyete değmeyebilir. Mühendislik disiplini tam da burada: yöntemi havalı olduğu için değil, sayı gösterdiği için seçmek.

Bu üç adımlık yaklaşımın güzelliği, seni gereksiz karmaşıklıktan koruması. Çoğu kurumsal RAG projesi, iyi ayarlanmış bir temel kurulumla şaşırtıcı derecede iyi çalışıyor; gelişmiş yöntemler ise gerçek bir darboğaz tespit ettikten sonra, hedefli bir müdahale olarak devreye giriyor.

## Her şeyi birbirine bağlayan fikir: adaptif yönlendirme

Buraya kadar okuduysan asıl mesajı sezmişsindir: 2026'da kazanan sistem "en iyi chunking'i bulan" değil, "her soruya doğru boru hattını eşleştiren" sistem. En iyi üretim sistemleri adaptif yönlendirme (adaptive routing) kullanıyor: sorgu karmaşıklığını boru hattı karmaşıklığına eşliyorlar. Basit sorulara ucuz yol, yalnızca gerektiğinde tam agentic/graph cephanesi.

Pratikte bu şöyle işliyor. Gelen sorgu önce hafif bir sınıflandırıcıdan geçiyor: Bu basit, tek atışlık olgusal bir soru mu, yoksa çok adımlı akıl yürütme gerektiren karmaşık bir soru mu? Basitse, ucuz yol: hibrit arama (BM25 + embedding) artı reranking, bitti. Karmaşıksa, ağır yol: query decomposition, agentic çok adımlı getirme, belki bir bilgi grafiği (graph) üzerinde gezinme. Böylece hem maliyeti hem gecikmeyi soru başına optimize ediyorsun; herkese Ferrari koşmak yerine, işe uygun aracı gönderiyorsun.

Bu mimari, bir önceki bölümdeki pragmatik yolun doğal devamı. Temel kurulumun ucuz yol oluyor; contextual retrieval, late chunking ve agentic RAG ise yönlendiricinin "bu soru bunu hakediyor" dediğinde açtığı üst vitesler.

## Karar tablosu: hangi durumda hangi strateji

Sahadaki tartışmaları kısaltmak için ekiplere hep bir karar tablosu bırakıyorum. Aşağıdakini kendi bağlamına göre uyarla, ama başlangıç noktası olarak sağlam.

| Durum / Sorgu tipi | Önerilen strateji | Neden |
|---|---|---|
| Kısa, olgusal, tek atışlık sorular ("iade kaç gün") | Recursive ~512 token + hibrit (BM25+embedding) + reranking | Ucuz, hızlı, çoğu durum için yeterli; temel kurulum |
| Nadir kodlar, madde numaraları, ürün kodları | Hibritte BM25 ağırlığını artır | Embedding nadir tokenları kaçırır; BM25 tam eşleşir |
| Sınır bağlamı kaybı darboğazsa (parçalar bağlamsız kalıyor) | Contextual retrieval + BM25 + reranking | Metadata zenginleştirme kesinliği %73,3'ten %82,5'e çıkarır |
| Belge uzun bağlam penceresine sığıyor, indeks maliyeti düşük olsun | Late chunking (uzun bağlamlı embedding, sonra böl) | Parça başına ekstra LLM çağrısı olmadan tam bağlamı korur |
| Karmaşık, çok adımlı sorular (hukuk/sağlık/finans) | Agentic RAG + query decomposition | Kabaca 5x doğruluk; doğruluğun pazarlıksız olduğu yerde maliyete değer |
| Karışık trafik (hem basit hem karmaşık sorular) | Adaptif yönlendirme | Soru başına maliyet/gecikme optimizasyonu; ucuz yol + gereğinde ağır yol |
| Hiyerarşik belgeler (bölüm/alt bölüm yapısı önemli) | Hierarchical chunking | Belge yapısını koruyup üst bağlamı taşır |

Bu tabloyu bir dogma değil, bir başlangıç haritası olarak gör. Her satırın altında "ama önce ölç" yazdığını hayal et.

## Türkiye gerçeği: Türkçe getirme ve KVKK

Şimdi bloglarda pek konuşulmayan ama Türkiye'de proje yapıyorsan başını en çok ağrıtacak iki konuya geleyim.

**Türkçe getirmenin huysuzlukları.** Türkçe sondan eklemeli bir dil; tek bir kök kelime onlarca ekle bambaşka biçimlere giriyor. "Ev", "evler", "evlerimizden", "evlerimizdekiler" hepsi aynı kökten. BM25 gibi kelime tabanlı yöntemler, tokenizer ve kök bulma (stemming) düzgün ayarlanmadıysa bu biçimleri farklı kelimeler sanıyor ve tam eşleşmeleri kaçırıyor. İngilizce için hazır gelen çözümler Türkçe morfolojisinde tökezliyor. Pratik önerim: hibrit aramada Türkçe'ye uygun bir tokenizer ve mümkünse kök bulma katmanı kullan, embedding modelini de Türkçe metinlerle test et; birçok çokdilli embedding modeli İngilizce'de parlak olup Türkçe'de sönük kalıyor. Ayrıca chunk boyutunu token'la sayarken şunu unutma: Türkçe kelimeler İngilizce'ye göre daha fazla token'a bölünme eğiliminde, yani karakter bazlı sezgin seni yanıltır; token-doğru sayım Türkçe'de daha da kritik.

**KVKK ve on-prem veri.** Kurumsal müşterilerimin çoğunda veri, buluttaki bir API'ye gönderilemeyecek kadar hassas: müşteri kayıtları, sağlık verisi, finansal tablolar. KVKK uyumu, kişisel veriyi yurt dışındaki bir modele göndermeyi çoğu zaman pratikte imkânsız kılıyor. Bu, mimari kararlarını doğrudan etkiliyor. Contextual retrieval'ın bağlam cümlelerini üretmek için ya da agentic RAG adımları için LLM çağrısı yapıyorsan, bu çağrıların nereye gittiği bir uyum meselesi. Benim sahada uyguladığım çözüm: hassas veriyle çalışan boru hatlarında yerel (on-prem ya da özel bulut) modeller kullanmak. Bu, gelişmiş yöntemlerin maliyet hesabını değiştiriyor; yerel bir modelle her parçaya bağlam üretmek, dış API'ye göre farklı bir donanım ve operasyon yükü demek. O yüzden Türkiye'de adaptif yönlendirme daha da değerli: pahalı, yerel-model gerektiren ağır yolu yalnızca gerçekten gereken sorulara saklamak, hem uyum hem bütçe açısından nefes aldırıyor.

Bir de şu var: Türkçe için etiketli değerlendirme verisi kıt. İngilizce RAG benchmarkları bol, Türkçe için elinde çoğu zaman kendi ürettiğin küçük bir soru-cevap seti oluyor. O yüzden "metrikler gerekçe verdiğinde terfi et" ilkesini uygulayabilmek için, en başından kendi Türkçe değerlendirme setini kurmanı şiddetle öneriyorum; yoksa neyin işe yaradığını asla nesnel olarak bilemezsin.

## Somut bir yol haritası: pazartesi sabahı ne yapacaksın

Teoriyi eyleme çevirelim. Yeni bir kurumsal RAG projesine girsem, adım adım şunu yapardım.

Birinci hafta: veriyi ve soruları tanı. Gerçek kullanıcı sorularından (yoksa domain uzmanlarından topladığın) 50-100 soruluk bir değerlendirme seti kur. Bu set olmadan attığın her adım karanlıkta el yordamı.

İkinci hafta: temel kurulumu ayağa kaldır. Recursive ~512 token, token-doğru sayım, hibrit arama (BM25 + Türkçe'ye uygun embedding), üstüne bir reranker. Değerlendirme setinde recall ve precision'ı ölç. Şaşırma; bu "basit" kurulum çoğu zaman herkesi şaşırtacak kadar iyi çalışır.

Üçüncü hafta: darboğazı teşhis et. Hangi sorular başarısız oluyor? Başarısızlıklar sınır bağlamı kaybından mı (parçalar bağlamsız kalıyor) kaynaklanıyor, yoksa sorular çok adımlı olduğu için tek atış yetmiyor mu? Teşhis, tedaviyi belirler. Sınır bağlamı sorunuysa contextual retrieval ya da late chunking'i dene ve aynı sette yeniden ölç. Çok adımlılıksa agentic yolu o soru sınıfı için devreye al.

Dördüncü hafta: yönlendirmeyi kur. Sorguları sınıflandıran hafif bir katman ekle; basit olanları ucuz yola, karmaşık olanları ağır yola gönder. Maliyet ve gecikmeyi soru başına ölç, sınıflandırıcının hatalarını izle.

Bu ritmin özü şu: her adımda ölç, her terfiyi bir sayıyla gerekçelendir, hiçbir yöntemi moda olduğu için değil, senin verinde işe yaradığı için seç. Chunking havalı bir konu değil; ama kurumsal RAG'ın kaderini, o parlak modellerden çok daha fazla, işte bu göz ardı edilen katman belirliyor. Sahadan en net gözlemim bu ve sana bırakacağım en değerli tavsiye de bu: mimarine değil, ölçtüğün sayılara güven.

## Ara vitesler: semantic ve hierarchical chunking

Karar tablosunda geçen ama üstünde yeterince durmadığım iki ara yöntem var; bunları da netleştireyim, çünkü çoğu proje contextual retrieval ya da agentic RAG'a atlamadan önce tam olarak bu ikisiyle çözülüyor.

**Semantic chunking (anlamsal bölme).** Recursive bölme, metni yapısal sınırlardan (paragraf, cümle) böler ama konunun nerede değiştiğini umursamaz. Semantic chunking ise cümlelerin gömülerine bakarak "burada konu değişti" dediği yerden böler. Böylece bir parça baştan sona tek bir konuyu anlatır, farklı konular tek vektöre karışmaz. Bunun bedeli, bölme aşamasında ekstra gömme hesabı yapmandır; getirisi ise özellikle konudan konuya atlayan, düzensiz belgelerde daha temiz, daha odaklı parçalardır. Sözleşmeler, teknik kılavuzlar, karışık SSS belgeleri bundan çok faydalanıyor.

**Hierarchical chunking (hiyerarşik bölme).** Bazı belgeler doğaları gereği katmanlı: bölüm, alt bölüm, madde, alt madde. Hiyerarşik bölme bu yapıyı korur; her küçük parçayı, ait olduğu üst başlıkların bağlamıyla birlikte saklar. Kullanıcı bir alt maddeyi sorduğunda, sistem o maddenin hangi bölümün altında olduğunu da bilir ve gerekirse üst bağlamı cevaba taşır. Mevzuat metinleri, standartlar, çok başlıklı kurumsal politikalar için neredeyse zorunlu. Late chunking ile de güzel evleniyor: üst başlığı bağlamda tutup alt maddeyi late chunking ile gömdüğünde, hem yapı hem anlam korunuyor.

Bu ikisini "temel kurulum ile ağır topçu arasındaki köprü" olarak düşün. Çoğu zaman contextual retrieval'ın maliyetine girmeden, sadece daha akıllı bölerek darboğazı aşıyorsun.

## Sık yapılan beş hata ve panzehirleri

Sahada aynı hataları tekrar tekrar görüyorum. Sen bunlara düşme diye kısa bir liste:

> **1. Token yerine karakterle bölmek.** "512 karakter" ile "512 token" bambaşka şeyler. Modelin kendi tokenizer'ıyla say, yoksa parçaların sessizce kırpılır. Türkçe'de bu hata daha da ölümcül, çünkü kelimeler daha çok token'a bölünüyor.

> **2. Overlap'i (parçalar arası örtüşme) unutmak.** Parçalar arasına küçük bir örtüşme koymazsan, tam da sınırda kalan bir cümle iki parçada da yarım kalır. Küçük bir örtüşme (mesela 50 token) bağlam kopmalarını ciddi biçimde azaltır.

> **3. Reranking'i atlamak.** İlk arama kaba bir elemedir; reranker olmadan LLM'e giden ilk beş parça çoğu zaman en isabetliler değildir. Reranking, kurulumdaki en ucuz büyük kazançtır; ekleme.

> **4. Değerlendirme seti olmadan yöntem değiştirmek.** "Şu yeni yöntem daha iyiymiş" deyip körlemesine geçiş yapmak, elindeki iyi çalışan sistemi bozmanın en hızlı yolu. Önce ölç, sonra değiştir, sonra tekrar ölç.

> **5. Her soruya en ağır boru hattını koşmak.** Basit bir SSS sorusuna agentic RAG çalıştırmak, hem parayı hem gecikmeyi katlıyor. Adaptif yönlendirme tam da bu israfı önlemek için var.

Bu beş maddeyi bir kontrol listesi gibi duvara as; kurumsal RAG projelerinin çoğu tam da bu beş noktada tökezliyor.