RAG Parçalama Stratejileri: 7 Yöntem, Erişim Verisiyle Sıralandı (2026)

RAG Parçalama Stratejileri: 7 Yöntem, Erişim Verisiyle Sıralandı (2026)

RAG parçalama stratejileri, tek bir sorgu çalışmadan önce retriever'ınızın neyi bulabileceğini belirler. Chroma'nın Temmuz 2024 çalışması, text-embedding-3-large üzerinde beş korpus genelinde 472 sorgu çalıştırdı ve seçtiğiniz splitter, recall'ı yaklaşık beş puan oynatıyor: düz token splitter için %86,7, GPT-4o tabanlı olan için %91,7; sorgu başına beş parça getirilerek. Precision çok daha sert dalgalanıyor. Raporun tamamında %1,5 ile %8,0 arasında seyrediyor; bu da parça boyutu seçiminizi kalite kılığına girmiş bir maliyet kararı haline getiriyor ve birinci sayfadaki her rehber, hangisinin daha iyi getirdiğini göstermeden aynı yedi yöntemi listeliyor.

Öne Çıkanlar

• Parçalama, belgeleri embedding öncesinde böler; bölme noktaları retriever'ınızın neyi bulup neyi bulamayacağını belirler.
• Chroma'nın Temmuz 2024 tarihli 472 sorguluk çalışmasında recall, ölçülen splitter'lar arasında %86,7 ile %91,7 arasında seyretti.
• Precision, recall'dan birkaç kat fazla değişkenlik gösterir; bu yüzden parça boyutu büyük ölçüde bir token maliyeti kararıdır.
• 512 token ve %10 örtüşme ile başlayın, ardından kendi eval kümenize göre ayarlayın.

Hangi RAG Parçalama Stratejisini Kullanmalısınız? (Sıralı)

Düz metin üzerine inşa eden çoğu ekip için recursive character chunking, 512 token ve %10 örtüşme ile doğru varsayılandır. Paragraf ve cümle sınırlarına saygı gösterir, ek maliyet getirmez ve Chroma'nın 472 sorguluk benchmark'ında LLM tabanlı splitter'ın yalnızca 3,2 recall puanı gerisinde kaldı. Yalnızca belgeleriniz güçlü bir yapıya sahipse veya eval kümeniz aksini kanıtlıyorsa uzaklaşın.

Bizim yorumumuz: recursive character ile başlayın. Chroma verisinde yalnızca küme ve LLM splitter'larının gerisinde kalıyor recall'da ve LLM splitter'ın %3,9 precision'ı, üreticiye ilgili token başına kabaca iki kat daha fazla gürültü beslediğiniz anlamına geliyor. Çoğu ekibin parçalama sorunu yok; hiç ölçmedikleri bir parça boyutu sorunları var.

Veri Aslında Parça Boyutu Hakkında Ne Söylüyor?

RAG parçalama stratejilerinin tek açık karşılaştırmalı testi, Chroma'nın "Evaluating Chunking Strategies for Retrieval" teknik raporudur (Brandon Smith ve Anton Troynikov, 3 Temmuz 2024'te yayımlandı). 5 korpus genelinde (328.208 token) 472 sorgu çalıştırdılar, her şeyi OpenAI text-embedding-3-large ile embedding'e dönüştürdüler ve sorgu başına 5 parça getirdiler. Aşağıdaki satırlar, raporun tüm korpuslar için text-embedding-3-large'da 5 getirilen parça ayarındaki ek tablosundan geliyor, dolayısıyla birbirleriyle doğrudan karşılaştırılabilir:

Chroma'nın farklı bir erişim ayarını raporlayan ana sonuç tablosu, küme chunker'ının en iyi precision'ını %87,3 recall ile %8,0'a koyuyor ve tüm splitter'larında precision aralığını %1,5'ten (KamradtSemanticChunker) %8,0'a kadar genişletiyor. Kaynak: Chroma Research, Evaluating Chunking Strategies

Anthropic'in "Introducing Contextual Retrieval" çalışması (19 Eylül 2024'te yayımlandı) soruna farklı bir açıdan yaklaşıyor. Başlangıç top-20 erişim hata oranları %5,7'ydi; yalnızca bağlamsal embedding'ler bunu %3,7'ye düşürdü (%35 azalma), üzerine bağlamsal BM25 eklenince %2,9'a indi (%49) ve reranking ile %1,9'a geriledi (%67). Anthropic kullanılan tam parça boyutunu veya örtüşmeyi yayımlamıyor, bu yüzden bunları yöntem düzeyinde kanıt olarak ele alın, boyut düzeyinde değil. Kaynak: Anthropic, Contextual Retrieval.

Bizim yorumumuz: aritmetikten üç sonuç çıkıyor. Birincisi, splitter seçimi gerçek recall değerinde ve Chroma bunu açıkça söylüyor: bazı stratejiler recall'da diğerlerinden %9'a kadar daha iyi performans gösteriyor. Ana sonuç tablosunda recall %83,6'dan (KamradtSemanticChunker) %91,9'a (LLMSemanticChunker) uzanıyor ve yukarıdaki 5-getir satırlarında bile %86,7 ile %91,7 arasında seyrediyor. Precision aynı veride birkaç kat daha fazla hareket ediyor: %1,5 ile %8,0, recall'ın 1,1x'ine karşı 5,3x'lik bir yayılma. Yani recall birkaç puan topladığınız yer, precision ve token maliyeti ise seçimin gerçekten ısırdığı yer. İkincisi, LLM tabanlı splitter en yüksek recall'ı en kötü precision pahasına satın alıyor: belge başına bir LLM çağrısı ödüyor ve üreticiye daha fazla gürültü besliyorsunuz. Üçüncüsü, Anthropic'in rakamları, parçaları bağlamla zenginleştirmenin (%5,7'den %3,7'ye) hata oranını, Chroma tablosundaki herhangi bir splitter seçiminden daha fazla hareket ettirdiğini gösteriyor. Splitter'ı yeniden ayarlamadan önce parçaları zenginleştirin. Reranking, splitter'ınızın bozduğu parçaları kurtarır ve hibrit arama BM25'i vektör erişimiyle birleştirir; aynı sebeple.

Dürüst sınırlar: her iki çalışma da tek bir embedding modeli, yalnızca İngilizce korpuslar kullanıyor ve hiçbiri sizin korpusunuzun kontrollü bir testi değil. 472 sorgu genelinde, en iyi ve en kötü splitter arasındaki fark 5 getirilen parçada yaklaşık 5 recall puanıydı ve precision'da orantısal olarak çok daha büyük bir fark vardı.

Parça Boyutu Erişim Kalitesini Neden Belirler?

Parça boyutu, erişim anahtarınızın granülerliğini ayarlar. 400 token'lık bir parça, belirli sorgularla eşleşen odaklı bir embedding üretir; 4.000 token'lık bir parça birçok konu boyunca ortalamasını alır ve hiçbir şeyle tam eşleşmez. Küçük parçalar tam pasajı getirir ancak yanıtı sonuçlar arasında parçalayabilir. Büyük parçalar bağlamı bir arada tutar ancak embedding sinyalini zayıflatır.

Embedding modelinin bağlam tavanı da önemlidir. Modeliniz 512 giriş token'ında sınırlanıyorsa ve siz 800 beslerseniz, kuyruk sessizce kesilir. Embedding'iniz parçanın üçte ikisini temsil eder. Hata günlüğü yok.

Sonra üretici tarafı. Liu ve arkadaşları, "Lost in the Middle" (arXiv 2307.03172, 2023) çalışmasında, ilgili belge uzun bir bağlamın ortasında yer aldığında LLM doğruluğunun %20'den fazla düştüğünü gösterdi. Beş adet 1.000 token'lık parça getirmek, prompt'a 5.000 token yığar ve ihtiyacınız olan yanıt, modelin en kötü okuduğu konuma düşebilir. Daha küçük parçalar, ilgili pasajı modelin iyi işlediği bir konuma daha yakın tutar.

Bunu bir kütüphane indeksi gibi düşünün. "Bölüm 4.2, paragraf 3: iade politikası" yazan bir kart size sayfayı getirir. "20. yüzyılda ticaret hakkında her şey" yazan bir kart size binayı getirir. Embedding'iniz o karttır. Bir RAG uygulamasını uçtan uca inşa edin ve parçalamanın hattın neresinde oturduğunu görün; getirilen parçaların prompt token'larına nasıl dönüştüğünü öğrenmek için context engineering rehberimizi okuyun. Pinecone'un parçalama rehberi aynı ödünleşmeyi vektör veritabanı tarafından çerçeveliyor.

Sabit Boyut ve Recursive Parçalama (Buradan Başlayın)

Sabit boyut, her şeyi ölçtüğünüz başlangıç çizgisidir; recursive ise gerçekte dağıtıma aldığınızdır.

Sabit boyut token parçalama

İçerikten bağımsız olarak her N token'da bölün.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Doğru yanıt olduğu durumlar: başlık yapısı olmayan düz metin, hızlı prototipler ve herhangi bir başlangıç çizgisi karşılaştırması. Aptalca değil. Kontrol grubudur.

Recursive character parçalama

LangChain'in RecursiveCharacterTextSplitter'ı bir ayırıcı hiyerarşisinde böler: önce \n\n (paragraflar), sonra \n (satırlar), sonra . (cümleler), sonra (kelimeler). Her parça, uyan en büyük doğal sınırı koruyarak chunk_size altında kalır.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

Ayırıcı listesi, her rakibin atladığı kısımdır. Splitter önce \n\n dener ve yalnızca bir paragraf chunk_size'ı aştığında . 'ye düşer. Markdown'ınızda başlıklar varsa, bölümlerin bozulmaması için "\n\n" öncesine "## " ekleyin.

Parça örtüşme aritmetiği: 512 token ve 50 token örtüşmede adım 462'dir. 10.000 token'lık bir belge ceil(10000 / 462) = 22 parça üretir. Toplam embedding'e dönüşen token: 22 x 512 = 11.264, yani korpusun yaklaşık %12,6'sını örtüşme olarak yeniden embedding'e dönüştürüyorsunuz. Sınır cümlelerinin yetim kalmasını önlemenin depolama ve API maliyeti budur.

Semantik Parçalama Nasıl Çalışır ve Maliyetine Değer mi?

Semantik parçalama, her cümleyi embedding'e dönüştürür, komşu cümle embedding'leri arasındaki kosinüs mesafesini ölçer ve bu mesafe bir yüzdelik eşiği (genellikle 95.) aştığında böler. Parçalar, keyfi token sayıları yerine konu geçişlerinde kırılır. Greg Kamradt'ın "5 Levels of Text Splitting" notebook'u bu yüzdelik kırılma noktası yaklaşımını başlattı ve Chroma çalışması onun chunker'larını ismen benchmark'a alıyor.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Maliyet hesabı, kimsenin öne koymadığı kısımdır. Semantik parçalama korpusunuzu iki kez embedding'e dönüştürür: bir kez cümle mesafelerini hesaplayıp kırılma noktalarını bulmak için, bir kez de ortaya çıkan parçaları indekslemek için. OpenAI'ın text-embedding-3-large fiyatı olan 1M token başına $0,13'te, 10M token'lık bir korpus normalde $1,30'a, semantik parçalama ile $2,60'a indekslenir. Tek bir sorgu çalışmadan iki kat ödüyorsunuz.

Bu ne satın alıyor? Chroma'nın 5-getir satırlarında, küme tabanlı semantik chunker aynı 200 token boyutunda recursive için %88,5 ve %7,0'a karşılık %89,0 recall ve %6,7 precision'a ulaştı. Ana sonuç tablosunda aynı chunker, çalışmanın en iyi precision'ı olan %8,0'ı %87,3 recall ile kaydediyor. Her iki yönde yarım puan recall ve hangi erişim ayarını okuduğunuza bağlı olarak işaret değiştiren bir precision sonucu; iki kat embedding faturası için. Kararımız: semantik parçalama, sabit sınırların rutin olarak konu ortasında böldüğü konu çeşitliliği yüksek korpuslarda (haber arşivleri, makale koleksiyonları) işe yarar. Homojen korpuslar (ürün dokümanları, tek bilgi tabanı) için recursive, kalitenin %95'ini yarı maliyetle verir. Embedding modellerini Ollama ile yerel çalıştırıyorsanız, çift embedding maliyeti hesaplama süresine düşer.

Belge Farkında Parçalama: Markdown, HTML ve Kod

Yapı farkında bölme, karakter sayıları yerine belgenin kendi sınırlarını (başlıklar, liste öğeleri, fonksiyon tanımları) kullanır. Bir Markdown H2, bir insanın kasıtlı olarak yerleştirdiği semantik bir sınırdır; karakter splitter onu parçalar.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Kod için sınırlar AST düğümleridir. LlamaIndex'in NodeParsers'ları, fonksiyon ve sınıf tanımlarında bölen dil farkında splitter'lar sunar. Kritik detay: import bloğunu ve kapsayan sınıf imzasını her fonksiyon parçasına bağlı tutun. Import'ları olmayan bir fonksiyon gövdesi embedding'e dönüşemeyen gürültüdür; bu yüzden her parçanın başına ikisini de ekleyin ve embedding, fonksiyonun ne yaptığını ve neye bağımlı olduğunu yakalasın.

Özellikle kod RAG için: AST sınırı bölmesi, import'lar öne eklenmiş, fonksiyon başına 256-512 token, sıfır örtüşme.

Geç, Hiyerarşik ve Ajan Tabanlı Parçalama Ne Olacak?

Bunlar, "RAG 2.0" söyleminin arkasındaki gelişmiş RAG parçalama stratejileri ve üçü de SERP kapsamasında 1/10 seviyesinde.

Geç parçalama

Geç parçalama, Günther ve arkadaşları tarafından "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, Eylül 2024) çalışmasında tanıtıldı; önce tüm belgeyi uzun bağlamlı bir modelle embedding'e dönüştürür, ardından token düzeyindeki embedding'leri parça vektörlerine havuzlar; böylece her parça belge genelinde bağlam taşır ve "ayda 40$'a mal oluyor" ifadesindeki "o"nun neye atıfta bulunduğunu bilir. Özet, görevler genelinde üstün erişim iddia ediyor ancak doğrulayabildiğimiz bir başlık rakamı yayımlamıyor. Weaviate'in yazısı mekaniği açıklıyor ve kontrollü bir karşılaştırmadan da kaçınıyor. Kanıt durumu: umut verici, nicelendirilmemiş.

Hiyerarşik (ebeveyn-çocuk) parçalama

Erişim için küçük parçaları (256 token) indeksleyin; üreticiye ebeveyni (1.024 token) döndürün. Retriever iğneyi bulur; üretici çevresindeki saman yığınını alır. İki indeks seviyesi ve bir ebeveyn-çocuk eşlemesi sürdürürsünüz. Etkiyi izole eden açık bir benchmark yok.

LLM tabanlı / ajan tabanlı parçalama

Chroma çalışmasının LLMSemanticChunker'ı, belge başına bölme noktalarına karar vermek için GPT-4o kullanır: %91,7 recall (en yüksek) ve %3,9 precision (en düşük). İndeksleme zamanında belge başına bir LLM çağrısı ödersiniz (10.000 belgelik bir korpus için yaklaşık $100) ve üreticiye daha fazla gürültü beslersiniz. Gerçekten düzensiz korpuslar için saklayın: hukuk dosyaları, çıkarılabilir başlığı olmayan taranmış PDF'ler.

Hangi Parça Boyutu Embedding Modelinize Uyar?

Embedding modelinizin maksimum giriş token'ı bir kısaltma tavanıdır, bir öneri değil. 8.192 token kabul eden bir model, 8.192'de 512'den daha iyi embedding üretmez. Kalite, tavandan çok önce seyrelmeyle bozulur: model anlamı daha fazla token arasında ortalar ve vektör korpus merkezine doğru kayar. Aşağıdaki öneri sütunu Techsy'nin yorumudur, satıcıların rehberliği değildir.

Kaynaklar: OpenAI embeddings rehberi, Cohere embed dokümanları, Voyage embeddings dokümanları, BGE model kartı.

Örüntü: sert 512 token tavanı olan modeller (Cohere v3, BGE) 512'nin oldukça altında parçalar gerektirir çünkü kısaltma sessizdir. Birine 600 token beslerseniz, son 88 token hata günlüğü olmadan embedding'den kaybolur. Büyük tavanı olan modeller (OpenAI, Voyage, Cohere v4) daha büyük parçalara tolerans gösterir ama ödüllendirmez. Bir modelin maksimum giriş uzunluğu bir kısaltma sınırıdır, bir öneri değil.

Bunu RAG için en iyi embedding modelleri derlememiz, MTEB skorunun gerçekte ne ölçtüğü ve Voyage, OpenAI ve Cohere embedding'leri yan yana karşılaştırmamızla eşleştirin; bir modele karar vermeden önce.

İngilizce Dışındaki Belgeleri Nasıl Parçalarsınız?

Tokenizer'lar dil tarafsız değildir. Petrov ve arkadaşları, "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) çalışmasında, aynı metnin diller arasında çevrildiğinde tokenize uzunluğunun 15x'e kadar farklılaşabildiğini gösterdi. Karakter düzeyi ve bayt düzeyi modellerde bile bazı dil çiftleri için 4x'in üzerinde fark görülüyor. 512 token'lık bir parça, Türkçe, Arapça veya Japoncada İngilizceden çok daha az anlam taşır.

İşte aynı cümlenin tiktoken'ın cl100k_base kodlamasıyla (GPT-4'ün tokenizer'ı) tokenize edilmiş hali:

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Sayılar tiktoken cl100k_base ile üretildi, 30 Temmuz 2026.

Pratik rehberlik: sabit 512 token parça boyutunda, Türkçe ve Japonca parçalarınız İngilizce parçalarınızın taşıdığı anlamın kabaca %37'sini taşır, Arapça parçalarınız ise yaklaşık %26'sını. Dil başına karakter sayısına veya cümle sayısına göre parçalayın ya da token bütçesini orantısal olarak artırın (Türkçe için yaklaşık 1.400, Arapça için 2.000). CJK dillerinde boşluk kelime sınırı yoktur, bu yüzden karakter splitter'ları farklı davranır. Arapça morfolojisi, birden fazla dilbilgisi belirtecini tek token'a sıkıştırarak sayıları daha da şişirir.

Parçalama Stratejinizi Seçmek İçin Bir Karar Ağacı

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Üç hızlı reçete. Doküman sohbet botu: MarkdownHeaderTextSplitter, 512 token, sıfır örtüşme, metadata'da başlık yolu. Kod arama asistanı: fonksiyon başına 256-512 token ile AST sınırı bölmesi, import'lar öne eklenmiş. Karışık kurumsal korpus: alımda belge türüne göre yönlendirin ve parçaları depoladığınız vektör veritabanında tür metadata'sıyla saklayın; böylece tür başına ayarlamayı sonra yapabilirsiniz. Belge başına bu yönlendirme, RAG uygulamaları için uyarlanabilir parçalamanın tamamıdır.

Araçlar: LangChain vs LlamaIndex vs Chonkie

Bunların hiçbirini satmıyoruz; bu anahtar kelime için en üst sıradaki üç sayfa, ürün CTA'ları olan satıcı blogları.

Kaynaklar: LangChain dokümanları, LlamaIndex NodeParsers, Chonkie dokümanları.

Üçü de aynı temel algoritmaları uyguluyor, bu yüzden hattınızın zaten kullandığına göre seçin. Splitter'ların ötesindeki geniş RAG araç yığını ve depolama için Qdrant, Chroma ve pgvector karşılaştırması için küme rehberlerimize bakın.

Techsy Parçalamaya Nasıl Yaklaşıyor

Müşteri RAG projelerinde Techsy ekibi 512 token ve %10 örtüşme ile başlar ve müşterinin gerçek destek biletlerinden 20-50 soruluk bir eval kümesi oluşturana kadar splitter'a dokunmaz. Eval kümesi önce gelir; sonra tek seferde bir değişken değiştiririz: boyut, örtüşme, strateji. Aynı sorularda öncesi-sonrası rakamı olmadan splitter değişikliği yok. Erişim hattınıza ikinci bir göz için ücretsiz danışmanlık alın.

Sıkça Sorulan Sorular

RAG'da parçalama nedir?

Parçalama, belgeleri embedding öncesinde daha küçük segmentlere bölen ön işleme adımıdır; böylece retriever sorguları tüm dosyalar yerine odaklı pasajlarla eşleştirebilir. Bölme noktaları, sisteminizin sorgu zamanında neyi bulup neyi bulamayacağını belirler.

RAG için en iyi parçalama stratejisi nedir?

Genel belgeler üzerinde çalışan çoğu üretim sistemi için 512 token ve %10 örtüşme ile recursive character parçalama en güçlü varsayılandır. Chroma'nın 472 sorguluk çalışmasında (Temmuz 2024) %88,5 recall aldı; en pahalı LLM tabanlı yöntemin yalnızca 3,2 puan gerisinde, sıfır ek maliyetle.

RAG için optimal parça boyutu nedir?

512 token ile başlayın. Embedding modeliniz 512 giriş token'ında sınırlanıyorsa (Cohere v3, BGE) veya sorgularınız tek cümlelik yanıtlar bekliyorsa 256'ya inin. Yalnızca eval kümeniz çok paragraflı yanıtların parçalandığını gösteriyorsa 1.024'e çıkın. Her zaman kendi sorularınıza karşı ölçün.

Ne kadar parça örtüşmesi kullanmalıyım?

Parça boyutunun %10-20'si (512'de 50-100 token). Örtüşme, sınır cümlelerinin yetim kalmasını önler: iki parçaya bölünen bir gerçek, en az birinde tam görünür. %20'nin ötesinde, azalan getiriler için korpusun çok fazlasını yeniden embedding'e dönüştürürsünüz. Çoğu ekip %10'da karar kılar ve bir daha dönüp bakmaz.

Semantik parçalama sabit boyut parçalamadan daha iyi mi?

Marjinal olarak ve iki kat embedding maliyetiyle. Chroma'nın Temmuz 2024 benchmark'ı, aynı token boyutunda recursive için %88,5 recall ve %7,0 precision'a karşılık küme tabanlı semantik chunker'ın %89,0 recall ve %6,7 precision gösterdiğini ortaya koydu; en iyi %8,0 precision sonucu farklı bir erişim ayarından geliyor. Konu çeşitliliği yüksek korpuslar için değer; homojen belge kümeleri için gerekçelendirmek zor.

Parça boyutu embedding modeline bağlı mı?

Evet. 512 token giriş tavanı olan modeller (BGE, Cohere v3) 512'nin oldukça altında parçalar gerektirir çünkü kısaltma sessizdir. 8.192+ tavanı olan modeller daha büyük parçalara tolerans gösterir ama ödüllendirmez; embedding kalitesi tavandan önce seyrelmeyle bozulur. Model başına başlangıç noktaları için yukarıdaki eşleştirme tablosuna bakın.

RAG sistemi için kodu nasıl parçalarım?

Token sayıları yerine AST sınırlarında (fonksiyon ve sınıf tanımları) bölün. Her parçayı fonksiyon başına 256-512 token'da tutun, dosyanın import bloğunu ve kapsayan sınıf imzasını öne ekleyin ve fonksiyonlar kendi kendine yeten birimler olduğundan sıfır örtüşme kullanın. LlamaIndex'in CodeSplitter'ı ve LangChain'in dil farkında splitter'ları ikisi de bunu halleder.

Geç parçalama nedir?

Geç parçalama, önce tüm belgeyi uzun bağlamlı bir modelle embedding'e dönüştürür, ardından token düzeyindeki embedding'leri parça vektörlerine havuzlar. Her parça embedding'i belge genelinde bağlam taşır ve "'o' neye atıfta bulunuyor?" sorununu çözer. Günther ve arkadaşları tarafından tanıtıldı (arXiv 2409.04701, Eylül 2024). Kazanımı nicelendiren açık bir karşılaştırmalı benchmark henüz yok.

İngilizce dışındaki dillerde belgeleri nasıl parçalarım?

Token sayıları dil tarafsız değildir. Aynı cümle Türkçe ve Japoncada İngilizceden 2,7x, Arapçada 3,9x daha fazla token aldı (tiktoken cl100k_base). Sabit 512 token bütçesi, İngilizce dışı parçalara sessizce daha az anlam verir. Dil başına karakter veya cümle sayısına göre parçalayın ya da bütçeyi orantısal olarak artırın.

Parçalamamın gerçekten işe yarayıp yaramadığını nasıl anlarım?

Splitter'a dokunmadan önce gerçek kullanıcı sorgularından 20-50 soruluk bir eval kümesi oluşturun. Mevcut parçalarınıza karşı hit@5 ve MRR puanlayın. Bir değişkeni değiştirin (boyut, örtüşme, strateji), yeniden çalıştırın, karşılaştırın. Eval kümesi olmadan, hisle ayar yapıyorsunuz. Başlamak için yirmi soru yeterli.

Sonuç

• 512 token, %10 örtüşme ile recursive character parçalama ile başlayın. Düz metin için doğru varsayılan.
• Ölçülen dört splitter ailesi genelinde, Chroma'nın 472 sorgusu recall'ı yaklaşık 5 puan, precision'ı birkaç kat daha fazla oynatıyor. Önce precision ve maliyet için ayarlayın.
• Parça boyutunu embedding modelinizin giriş tavanına eşleştirin. 512 token tavanı olan bir model, 512'nin altında parçalar gerektirir.
• Splitter'ı yeniden ayarlamadan önce parçaları bağlamla zenginleştirin (Anthropic'in %5,7'den %3,7'ye hata oranı düşüşü).
• Önce eval kümesini oluşturun. Öncesi-sonrası rakamı olmayan her splitter kararı bir tahmindir.

Parçalama seçiminizin etrafındaki tam hat için bir RAG uygulamasını uçtan uca inşa edin rehberine bakın. Hâlâ erişim ile ince ayar arasında mı karar veriyorsunuz? RAG mı ince ayar mı her birinin ne zaman kazandığını açıklıyor.