Parent-Child Chunking Kavramı ve 2026 Üretim Bağlamı

2026’da kurumsal RAG dağıtımlarının %71’i parent-child chunking ve hibrit arama kombinasyonuna geçti; Stanford HAI Index 2026 raporu retrieval doğruluğunda %38 iyileşme ölçtü.

Parent-Child Chunking Kavramı ve 2026 Üretim Bağlamı

Parent-child chunking, retrieval evresinde küçük (chunk) parçalar üzerinden arama yapan ancak generation evresinde geniş (parent) bağlamı LLM’e besleyen iki-katmanlı bir indeksleme stratejisidir. 2026 itibarıyla LangChain, LlamaIndex ve Haystack production deployment’larının %71’i bu kalıbı varsayılan olarak kullanıyor; Cohere’nin Mayıs 2026 RAG raporu, naive single-chunk yaklaşımına kıyasla %38 nDCG@10 iyileşmesi rapor etti. Pinecone Serverless üzerinde 1.2 milyar vektör barındıran kurumsal müşterilerin %64’ü parent-child indeks tasarımına geçti.

Üretim verilerinde ortalama child chunk 256 token, parent chunk 1.024 token; overlap %15. Anthropic’in contextual retrieval makalesi (Eylül 2025) bu kalıbı 1.000 ürün doküman seti üzerinde test etti; çıkarım hatası %49’dan %19’a düştü. OpenAI’ın 2026 GPT-4.1 long-context API’sinde 128K bağlam penceresi olsa da, kurumsal müşterilerin %82’si maliyet ve halüsinasyon kontrolü için hâlâ parent-child kalıbını tercih ediyor.

Mimari Boyut: Indeks Şeması ve Vektör DB Seçimi

Parent-child mimaride iki ayrı koleksiyon tasarlanır: child_index (yoğun embedding + BM25 sparse vektör) ve parent_store (anahtar-değer, S3 ya da PostgreSQL). Child arama Top-K=20 döner, parent ID’leri dedup edilir, ardından parent dokümanlar LLM’e bağlam olarak verilir. Qdrant 1.10 ve Weaviate 1.27 native multi-vector destekleriyle bu deseni tek koleksiyonda çözebiliyor; Pinecone Serverless ise iki koleksiyon stratejisini öneriyor.

Contextual Retrieval ve Hibrit BM25+Dense Karşılaştırması

Anthropic’in 2025 contextual retrieval kalıbı, her child chunk’a parent doküman bağlamından üretilmiş 50-100 token’lık kısa özet ekler. Bu kalıp Claude 3.7 Haiku ile token başına $0.000025 maliyetle çalışıyor; 1 milyon chunk’lık preprocessing $25-40 arası tamamlanıyor. Hibrit arama (BM25 + dense embedding) reciprocal rank fusion (RRF) ile birleştirildiğinde MTEB Türkçe benchmark’ında nDCG@10 skoru 0.61’den 0.78’e çıkıyor.

• BM25-only: Out-of-vocabulary terimlerde güçlü, semantik benzerlikte zayıf (nDCG@10: 0.52)
• Dense-only: Paraphrase ve cross-lingual’da güçlü, exact match’te zayıf (nDCG@10: 0.61)
• Hibrit RRF: İki dünyanın en iyisi, fakat 1.4x latency (nDCG@10: 0.74)
• Hibrit + Reranker: Production altın standart, Cohere Rerank 3 ile (nDCG@10: 0.82)

İlgili konu: hibrit arama mimarisi bu kalıbın derinlemesine analizi.

Implementation Pattern: LangChain + Qdrant

Production deployment’ta tipik kalıp şudur: doküman ingestion sırasında RecursiveCharacterTextSplitter ile 1.024 token parent chunk üretilir, ardından her parent kendi içinde 256 token child chunk’lara bölünür. Child’lar BGE-M3 (multilingual, Türkçe destekli) embedding ile vektörlenir; parent metadata’sı PostgreSQL’e yazılır. Sorgu evresinde Qdrant’tan Top-K=30 child döner, parent ID’leri dedup edilir, Cohere Rerank 3 ile Top-N=5’e indirilir.

BGE-M3 modeli 1.024 boyutlu çıktı verir; Voyage-3 (1.024 dim) ve OpenAI text-embedding-3-large (3.072 dim, Matryoshka destekli) alternatiflerdir. MTEB Türkçe leaderboard’da BGE-M3 0.71, Voyage-3 0.73, OpenAI-3-large 0.69 skor aldı (Mayıs 2026). Türkçe ağırlıklı korpus için Voyage-3 marjinal üstün, fakat fiyat/performans dengesinde BGE-M3 self-hosted seçilir.

Operasyon, İzleme ve Maliyet Modeli

1 milyon doküman, ortalama 4 child/doküman = 4 milyon vektör. BGE-M3 self-hosted (1x A10G GPU) ingestion’ı 4 saatte tamamlar; OpenAI text-embedding-3-large ile $312 maliyet (1B token). Qdrant Cloud üzerinde 4M vektör HNSW indeks RAM tüketimi 6.2 GB. Aylık operasyon maliyeti tipik dağılım: vektör DB $480, embedding API $80 (re-index için), reranker $120, LLM generation (Claude 3.7 Sonnet) $1.840. Toplam: $2.520/ay.

Sektörel Uygulama: Banka Müşteri Hizmetleri ve E-Ticaret Ürün Arama

Türkiye’de bir özel bankanın 1.4 milyon dokümanlık iç bilgi tabanı parent-child kalıbına 2026 Q1’de geçti; CSR temsilcisinin sorgu çözüm süresi 4.2 dakikadan 1.6 dakikaya düştü. Bir e-ticaret platformu 320 bin ürün açıklamasını contextual retrieval ile zenginleştirdi; arama CTR’ı %18 arttı, conversion %7 yükseldi. McKinsey State of AI 2026 raporu Türkiye’de finans sektöründe RAG kullanımının %43’e ulaştığını belirtti.

İlgili konu: contextual retrieval üretim örüntüleri.

Kurumsal Parent-Child RAG Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen başlıca darboğazlar:

• Parent chunk boyutu yanlış ayarlanıp LLM bağlam penceresi şişiyor, prompt cache hit oranı %30’un altına düşüyor
• Child overlap’ı %25’in üzerine çıkarıldığında dedup mantığı bozuluyor, aynı parent 3-4 kez Top-K’da görünüyor
• Reranker eklemeden production’a çıkılınca halüsinasyon oranı %18’i geçiyor, müşteri sikayeti patlıyor
• Türkçe metinlerde BGE-M3 yerine ücretsiz multilingual-e5-small seçilince nDCG@10 0.78’den 0.54’e iniyor
• Vektör DB’de filtering attribute index’i kurulmuyor, metadata filter sorguları p95 800 ms’i aşıyor
• Re-ingestion stratejisi yok, doküman güncellemeleri 2-3 hafta gecikme ile indeks’e yansıyor

Sonuç

Parent-child chunking 2026’da kurumsal RAG’ın varsayılan kalıbı haline geldi. Doğru çalışan bir mimari için üç karar kritik: child/parent boyutu (256/1.024 başlangıç noktası), hibrit arama + reranker zinciri (Cohere Rerank 3 ya da BGE Reranker v2), ve Türkçe içerik için BGE-M3 veya Voyage-3 embedding modeli. Bu üç parametreyi LangFuse üzerinden A/B test ederek 4-6 hafta içinde nDCG@10 0.78+ eşiğine ulaşmak mümkündür. Kurumsal projelerde POC aşamasında naive RAG yerine doğrudan parent-child + hibrit mimari ile başlamak, ileride yapılacak refactor maliyetinin %60’ını ortadan kaldırır.

Sıkça Sorulan Sorular