Strategi Chunking RAG: 7 Metode, Peringkat Berdasarkan Data Retrieval (2026)

Strategi Chunking RAG: 7 Metode, Peringkat Berdasarkan Data Retrieval (2026)

Strategi chunking RAG menentukan apa yang bisa ditemukan retriever bahkan sebelum satu query pun dijalankan. Studi Chroma pada Juli 2024 menjalankan 472 query di lima korpus dengan text-embedding-3-large, dan splitter yang kamu pilih menggeser recall sekitar lima poin: 86,7% untuk splitter token biasa, 91,7% untuk yang berbasis GPT-4o, dengan lima chunk diambil per query. Precision berayun jauh lebih keras. Di seluruh laporan, angkanya berkisar dari 1,5% hingga 8,0%, yang membuat pilihan ukuran chunk kamu menjadi keputusan biaya berkedok kualitas, dan setiap panduan di halaman satu Google mendaftar tujuh metode yang sama tanpa menunjukkan mana yang mengambil hasil lebih baik.

Poin Penting

• Chunking membagi dokumen sebelum embedding; titik pembagiannya menentukan apa yang bisa dan tidak bisa ditemukan retriever kamu.
• Dalam studi Chroma Juli 2024 yang berisi 472 query, recall berjalan dari 86,7% hingga 91,7% di seluruh splitter yang diukur.
• Precision bervariasi beberapa kali lebih besar daripada recall, jadi ukuran chunk sebagian besar adalah keputusan biaya token.
• Mulai dari 512 token dengan 10% overlap, lalu setel terhadap eval set kamu sendiri.

Strategi Chunking RAG Mana yang Harus Kamu Pakai? (Berperingkat)

Untuk kebanyakan tim yang membangun di atas prosa datar, recursive character chunking pada 512 token dengan 10% overlap adalah default yang tepat. Ia menghormati batas paragraf dan kalimat, tidak memakan biaya tambahan, dan dalam benchmark 472 query Chroma hanya tertinggal 3,2 poin recall dari splitter berbasis LLM. Beranjak dari default ini hanya jika dokumen kamu berstruktur kuat atau eval set kamu membuktikan sebaliknya.

Penilaian kami: mulai dari rekursif karakter. Ia hanya kalah dari splitter cluster dan LLM dalam hal recall di data Chroma, dan precision 3,9% milik splitter LLM berarti kamu menyuapkan generator sekitar dua kali lebih banyak noise per token relevan. Kebanyakan tim tidak punya masalah chunking; mereka punya masalah ukuran chunk yang tidak pernah mereka ukur.

Apa yang Sebenarnya Dikatakan Data tentang Ukuran Chunk?

Satu-satunya perbandingan head-to-head publik untuk strategi chunking RAG adalah laporan teknis Chroma "Evaluating Chunking Strategies for Retrieval" (Brandon Smith dan Anton Troynikov, terbit 3 Juli 2024). Mereka menjalankan 472 query di 5 korpus (328.208 token), meng-embed semuanya dengan OpenAI text-embedding-3-large, dan mengambil 5 chunk per query. Baris-baris di bawah berasal dari tabel lampiran laporan untuk semua korpus pada text-embedding-3-large dengan 5 chunk diambil, jadi semuanya bisa dibandingkan langsung satu sama lain:

Tabel hasil utama Chroma, yang melaporkan pengaturan retrieval berbeda, menempatkan precision terbaik cluster chunker di 8,0% dengan recall 87,3%, dan merentangkan precision di semua splitter-nya dari 1,5% (KamradtSemanticChunker) hingga 8,0%. Sumber: Chroma Research, Evaluating Chunking Strategies

"Introducing Contextual Retrieval" milik Anthropic (terbit 19 September 2024) menyerang masalah ini dari sudut berbeda. Tingkat kegagalan retrieval top-20 baseline mereka adalah 5,7%; contextual embeddings saja menurunkannya ke 3,7% (reduksi 35%), contextual BM25 di atasnya membawanya ke 2,9% (49%), dan reranking mendorongnya ke 1,9% (67%). Anthropic tidak mempublikasikan ukuran chunk atau overlap persis yang dipakai, jadi perlakukan angka-angka itu sebagai bukti level metode, bukan level ukuran. Sumber: Anthropic, Contextual Retrieval.

Penilaian kami: tiga kesimpulan dari hitung-hitungan ini. Pertama, pilihan splitter bernilai recall sungguhan, dan Chroma mengatakannya terus terang: beberapa strategi mengungguli yang lain hingga 9% recall. Di seluruh tabel hasil utamanya, recall berjalan dari 83,6% (KamradtSemanticChunker) hingga 91,9% (LLMSemanticChunker), dan di dalam baris ambil-5 di atas masih merentang 86,7% hingga 91,7%. Precision bergerak beberapa kali lebih jauh pada data yang sama: 1,5% hingga 8,0%, rentang 5,3x melawan 1,1x milik recall. Jadi recall adalah tempat kamu memungut beberapa poin, dan precision serta biaya token adalah tempat pilihan itu benar-benar menggigit. Kedua, splitter berbasis LLM membeli recall tertinggi dengan precision terburuk: kamu membayar satu panggilan LLM per dokumen dan menyuapkan generator lebih banyak noise. Ketiga, angka Anthropic menunjukkan bahwa memperkaya chunk dengan konteks (5,7% ke 3,7%) menggerakkan tingkat kegagalan lebih jauh daripada pilihan splitter mana pun di tabel Chroma. Perkaya chunk sebelum menyetel ulang splitter. Reranking memulihkan chunk yang dirusak splitter kamu, dan pencarian hybrid menggabungkan BM25 dengan retrieval vektor untuk alasan yang sama.

Batas jujurnya: kedua studi memakai satu model embedding, korpus hanya bahasa Inggris, dan keduanya bukan uji terkontrol untuk korpus kamu. Di seluruh 472 query, jarak antara splitter terbaik dan terburuk sekitar 5 poin recall pada 5 chunk diambil, dan jarak yang secara proporsional jauh lebih besar pada precision.

Kenapa Ukuran Chunk Menentukan Kualitas Retrieval?

Ukuran chunk menetapkan granularitas kunci retrieval kamu. Chunk 400 token menghasilkan embedding fokus yang cocok dengan query spesifik; chunk 4.000 token merata-ratakan banyak topik dan tidak cocok dengan apa pun secara presisi. Chunk kecil mengambil passage yang persis tapi bisa memecah jawaban di antara hasil. Chunk besar menjaga konteks tetap utuh tapi melemahkan sinyal embedding.

Langit-langit konteks model embedding juga penting. Jika model kamu mentok di 512 token input dan kamu menyuapkan 800, ekornya diam-diam terpotong. Embedding kamu merepresentasikan dua pertiga chunk. Tidak ada error yang tercatat.

Lalu sisi generator. Liu dkk. menunjukkan dalam "Lost in the Middle" (arXiv 2307.03172, 2023) bahwa akurasi LLM turun lebih dari 20% ketika dokumen relevan duduk di tengah konteks panjang. Mengambil lima chunk 1.000 token membuang 5.000 token ke prompt, dan jawaban yang kamu butuhkan mungkin mendarat di posisi yang paling buruk dibaca model. Chunk lebih kecil menjaga passage relevan lebih dekat ke posisi yang ditangani model dengan baik.

Bayangkan seperti indeks perpustakaan. Kartu bertuliskan "Bagian 4.2, paragraf 3: kebijakan refund" membawamu ke halamannya. Kartu bertuliskan "segala hal tentang perdagangan abad ke-20" membawamu ke gedungnya. Embedding kamu adalah kartunya. Bangun aplikasi RAG dari ujung ke ujung untuk melihat di mana chunking duduk dalam pipeline, dan baca panduan context engineering kami untuk bagaimana chunk yang diambil menjadi token prompt. Panduan chunking Pinecone membingkai tradeoff yang sama dari sisi database vektor.

Chunking Ukuran Tetap dan Rekursif (Mulai dari Sini)

Ukuran tetap adalah baseline yang kamu pakai untuk mengukur segalanya; rekursif adalah yang benar-benar kamu rilis.

Chunking token ukuran tetap

Membagi tiap N token tanpa memedulikan isi.

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

Jawaban yang tepat untuk: prosa datar tanpa struktur heading, prototipe cepat, dan perbandingan baseline apa pun. Ini tidak bodoh. Ini kelompok kontrol.

Recursive character chunking

RecursiveCharacterTextSplitter milik LangChain membagi berdasarkan hierarki pemisah: pertama \n\n (paragraf), lalu \n (baris), lalu . (kalimat), lalu (kata). Setiap chunk tetap di bawah chunk_size sambil menghormati batas alami terbesar yang muat.

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)

Daftar pemisah adalah bagian yang dilewatkan setiap kompetitor. Splitter mencoba \n\n lebih dulu dan jatuh ke . hanya ketika paragraf melebihi chunk_size. Jika Markdown kamu punya header, tambahkan "## " sebelum "\n\n" agar bagian-bagian tetap utuh.

Aritmetika overlap chunk: pada 512 token dengan overlap 50 token, langkahnya 462. Dokumen 10.000 token menghasilkan ceil(10000 / 462) = 22 chunk. Total token yang di-embed: 22 x 512 = 11.264, artinya kamu meng-embed ulang sekitar 12,6% korpus sebagai overlap. Itulah biaya penyimpanan dan API untuk menjaga kalimat batas agar tidak yatim.

Bagaimana Cara Kerja Semantic Chunking, dan Apakah Sepadan dengan Biayanya?

Semantic chunking meng-embed setiap kalimat, mengukur jarak cosinus antara embedding kalimat bertetangga, dan membagi di tempat jarak itu melewati ambang persentil (umumnya ke-95). Chunk patah pada pergantian topik, bukan pada jumlah token arbitrer. Notebook Greg Kamradt "5 Levels of Text Splitting" memelopori pendekatan breakpoint persentil ini, dan studi Chroma mem-benchmark chunker miliknya dengan nama.

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)

Hitung-hitungan biaya adalah bagian yang tidak ditaruh siapa pun di depan. Semantic chunking meng-embed korpus kamu dua kali: sekali untuk menghitung jarak kalimat dan menemukan breakpoint, sekali lagi untuk meng-embed chunk hasil bagi untuk pengindeksan. Pada harga text-embedding-3-large OpenAI sebesar $0,13 per 1 juta token, korpus 10 juta token memakan biaya $1,30 untuk diindeks secara normal dan $2,60 dengan semantic chunking. Kamu membayar dua kali lipat sebelum satu query pun berjalan.

Apa yang dibeli dengan itu? Di baris ambil-5 Chroma, semantic chunker berbasis cluster mencapai recall 89,0% dan precision 6,7% melawan 88,5% dan 7,0% milik rekursif pada ukuran 200 token yang sama. Di tabel hasil utama, chunker yang sama membukukan precision terbaik studi, 8,0%, pada recall 87,3%. Setengah poin recall ke salah satu arah, dan hasil precision yang berbalik tanda tergantung pengaturan retrieval mana yang kamu baca, untuk tagihan embedding dua kali lipat. Verdict kami: semantic chunking terbayar pada korpus bertopik beragam (arsip berita, koleksi makalah) di mana batas tetap rutin membelah di tengah topik. Untuk korpus homogen (dokumentasi produk, satu knowledge base), rekursif memberi kamu 95% kualitas dengan separuh biaya. Jika kamu menjalankan model embedding secara lokal dengan Ollama, biaya embed ganda turun menjadi waktu komputasi.

Chunking Sadar Dokumen: Markdown, HTML, dan Kode

Pembagian sadar struktur memakai batas milik dokumen itu sendiri (heading, item daftar, definisi fungsi), bukan jumlah karakter. H2 Markdown adalah batas semantik yang ditempatkan manusia dengan sengaja; splitter karakter mencabiknya.

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": "..."}

Untuk kode, batasnya adalah node AST. NodeParsers milik LlamaIndex mengirim splitter sadar bahasa yang membelah pada definisi fungsi dan kelas. Detail krusialnya: jaga blok import dan tanda tangan kelas pembungkus tetap menempel pada tiap chunk fungsi. Badan fungsi tanpa import-nya adalah noise yang tidak bisa di-embed, jadi tambahkan keduanya di depan setiap chunk dan embedding menangkap apa yang fungsi lakukan dan pada apa ia bergantung.

Khusus untuk RAG kode: pembagian batas AST, import di depan, 256-512 token per fungsi, nol overlap.

Bagaimana dengan Late, Hierarchical, dan Agentic Chunking?

Ini adalah strategi chunking RAG tingkat lanjut di balik riuhnya "RAG 2.0", dan ketiganya duduk di cakupan SERP 1/10.

Late chunking

Late chunking, diperkenalkan oleh Günther dkk. dalam "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, September 2024), meng-embed dokumen penuh dengan model konteks panjang lebih dulu, lalu menggabungkan embedding level token menjadi vektor chunk, sehingga setiap chunk membawa konteks seluruh dokumen dan "biayanya $40/bulan" tahu apa yang "itu" rujuk. Abstraknya mengklaim retrieval superior lintas tugas tapi tidak mempublikasikan angka utama yang bisa kami verifikasi. Tulisan Weaviate menjelaskan mekanismenya dan juga berhenti sebelum perbandingan terkontrol. Status bukti: menjanjikan, belum terkuantifikasi.

Chunking hierarkis (parent-child)

Indeks chunk kecil (256 token) untuk retrieval; kembalikan parent (1.024 token) ke generator. Retriever menemukan jarum; generator mendapat tumpukan jerami sekitarnya. Kamu memelihara dua level indeks dan pemetaan parent-child. Tidak ada benchmark publik yang mengisolasi efeknya.

Chunking berbasis LLM / agentik

LLMSemanticChunker dalam studi Chroma memakai GPT-4o untuk menentukan titik bagi per dokumen: recall 91,7% (tertinggi) dan precision 3,9% (terendah). Kamu membayar panggilan LLM per dokumen pada waktu pengindeksan (sekitar $100 untuk korpus 10.000 dokumen) dan menyuapkan generator lebih banyak noise. Simpan untuk korpus yang benar-benar tidak beraturan: berkas hukum, PDF pindaian tanpa heading yang bisa diekstrak.

Ukuran Chunk Mana yang Cocok untuk Model Embedding Kamu?

Token input maks. model embedding kamu adalah langit-langit pemotongan, bukan rekomendasi. Model yang menerima 8.192 token tidak meng-embed lebih baik pada 8.192 daripada pada 512. Kualitas menurun karena pengenceran jauh sebelum langit-langit: model merata-ratakan makna di lebih banyak token dan vektor melayang menuju sentroid korpus. Kolom rekomendasi di bawah adalah interpretasi Techsy, bukan panduan vendor.

Sumber: panduan embedding OpenAI, dokumentasi Cohere embed, dokumentasi embedding Voyage, kartu model BGE.

Polanya: model dengan langit-langit 512 token yang keras (Cohere v3, BGE) menuntut chunk jauh di bawah 512, karena pemotongan terjadi diam-diam. Suapkan 600 token dan 88 token terakhir lenyap dari embedding tanpa error yang tercatat. Model dengan langit-langit besar (OpenAI, Voyage, Cohere v4) menoleransi chunk lebih besar tapi tidak memberinya imbalan. Panjang input maks. model adalah batas pemotongan, bukan rekomendasi.

Padukan ini dengan rangkuman model embedding terbaik untuk RAG kami, apa yang sebenarnya diukur skor MTEB, dan embedding Voyage, OpenAI, dan Cohere berdampingan sebelum kamu memutuskan model.

Bagaimana Cara Chunking Dokumen Non-Bahasa Inggris?

Tokenizer tidak netral bahasa. Petrov dkk. menunjukkan dalam "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) bahwa teks yang sama yang diterjemahkan lintas bahasa bisa berbeda panjang tokenisasi hingga 15x. Bahkan model level karakter dan level byte menunjukkan perbedaan lebih dari 4x untuk beberapa pasangan bahasa. Chunk 512 token memuat makna jauh lebih sedikit dalam bahasa Turki, Arab, atau Jepang daripada dalam bahasa Inggris.

Ini kalimat yang sama ditokenisasi dengan encoding cl100k_base milik tiktoken (tokenizer GPT-4):

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

Jumlah dihasilkan dengan tiktoken cl100k_base, 30 Juli 2026.

Panduan praktis: pada ukuran chunk tetap 512 token, chunk Turki dan Jepang kamu memuat sekitar 37% makna yang dimuat chunk Inggris kamu, dan chunk Arab kamu memuat sekitar 26%. Bagi berdasarkan jumlah karakter atau jumlah kalimat per bahasa, atau naikkan anggaran token secara proporsional (sekitar 1.400 untuk Turki, 2.000 untuk Arab). Bahasa CJK tidak punya batas kata spasi, jadi splitter karakter berperilaku berbeda. Morfologi bahasa Arab memadatkan banyak penanda gramatikal ke dalam token tunggal, menggelembungkan jumlah lebih jauh.

Pohon Keputusan Memilih Strategi Chunking

Dokumen jenis apa?
├── Terstruktur (Markdown / HTML / kode)
│   └── Pembagian sadar dokumen pada header atau batas AST
│       ├── Situs dokumentasi → MarkdownHeaderTextSplitter, 512 token, 0 overlap
│       └── Codebase → Splitter AST/fungsi, 256-512 token, import di depan
├── Prosa datar (artikel, laporan, buku)
│   └── RecursiveCharacterTextSplitter, 512 token, 50 overlap
│       └── Topik beragam? → coba SemanticChunker di persentil ke-95
├── Log percakapan (chat, tiket support)
│   └── Bagi pada batas giliran, kelompokkan 3-5 giliran per chunk, 256 token
└── Korpus campuran
    └── Routing berdasarkan tipe MIME → terapkan strategi per tipe di atas
        └── Lalu: seberapa panjang jawaban yang diharapkan?
            ├── Pendek (1-2 kalimat) → child 256, tanpa parent
            └── Panjang (multi-paragraf) → hierarkis: child 256, parent 1,024

Tiga resep cepat. Chatbot dokumentasi: MarkdownHeaderTextSplitter pada 512 token, nol overlap, path heading di metadata. Asisten pencarian kode: pembagian batas AST pada 256-512 token per fungsi, import di depan. Korpus perusahaan campuran: routing berdasarkan tipe dokumen saat ingest dan simpan di database vektor tempat kamu menyimpan chunk dengan metadata tipe untuk penyetelan per tipe nanti. Routing per dokumen itulah seluruh chunking adaptif untuk aplikasi RAG.

Tools: LangChain vs LlamaIndex vs Chonkie

Kami tidak menjual satu pun dari ini; tiga halaman teratas yang ranking untuk keyword ini adalah blog vendor dengan CTA produk.

Sumber: dokumentasi LangChain, NodeParsers LlamaIndex, dokumentasi Chonkie.

Ketiganya mengimplementasikan algoritma inti yang sama, jadi pilih berdasarkan apa yang sudah dipakai pipeline kamu. Untuk stack tooling RAG yang lebih luas di luar splitter dan perbandingan Qdrant, Chroma, dan pgvector untuk penyimpanan, lihat panduan cluster kami.

Cara Techsy Melakukan Chunking

Pada pembangunan RAG klien, tim Techsy memulai dari 512 token dengan 10% overlap dan tidak menyentuh splitter sampai kami membangun eval set 20-50 pertanyaan dari tiket support riil klien. Eval set datang lebih dulu; lalu kami mengubah satu variabel pada satu waktu: ukuran, overlap, strategi. Tidak ada pertukaran splitter tanpa angka sebelum-dan-sesudah pada pertanyaan yang sama. Dapatkan konsultasi gratis untuk sepasang mata kedua pada pipeline retrieval kamu.

Tentang Penulis

Mert Batur adalah Co-Founder Techsy.io, tempat timnya merilis AI agent, sistem otomasi, dan pipeline suara/SDR untuk klien B2B. Ia menulis tentang stack tooling LLM yang benar-benar dipakai tim Techsy di produksi, termasuk pekerjaan RAG dan retrieval di balik pembangunan knowledge base klien. Terhubung di LinkedIn.

Pertanyaan yang Sering Diajukan

Apa itu chunking dalam RAG?

Chunking adalah langkah prapemrosesan yang membagi dokumen menjadi segmen lebih kecil sebelum embedding, sehingga retriever bisa mencocokkan query terhadap passage fokus, bukan seluruh file. Titik bagi menentukan apa yang bisa dan tidak bisa ditemukan sistem kamu pada waktu query.

Strategi chunking terbaik untuk RAG?

Untuk kebanyakan sistem produksi pada dokumen umum, recursive character chunking pada 512 token dengan 10% overlap adalah default terkuat. Dalam studi 472 query Chroma (Juli 2024), ia mencetak recall 88,5%, dalam jarak 3,2 poin dari metode berbasis LLM yang paling mahal, tanpa biaya tambahan apa pun.

Ukuran chunk optimal untuk RAG?

Mulai dari 512 token. Turun ke 256 jika model embedding kamu mentok di 512 token input (Cohere v3, BGE) atau jika query kamu mengharapkan jawaban satu kalimat. Naik ke 1.024 hanya jika eval set kamu menunjukkan jawaban multi-paragraf terpecah. Selalu ukur terhadap pertanyaan kamu sendiri.

Berapa banyak overlap chunk yang harus dipakai?

10-20% dari ukuran chunk (50-100 token pada 512). Overlap mencegah kalimat batas menjadi yatim: fakta yang terbelah antara dua chunk muncul utuh di setidaknya satu chunk. Di atas 20%, kamu meng-embed ulang terlalu banyak korpus untuk imbal hasil yang menipis. Kebanyakan tim mendarat di 10% dan tidak pernah menengoknya lagi.

Apakah semantic chunking lebih baik daripada chunking ukuran tetap?

Tipis, dan dengan biaya embedding dua kali lipat. Benchmark Chroma Juli 2024 menunjukkan semantic chunker berbasis cluster pada recall 89,0% dan precision 6,7% melawan recall 88,5% dan precision 7,0% untuk rekursif pada ukuran token yang sama, dengan hasil precision terbaiknya 8,0% datang dari pengaturan retrieval berbeda. Sepadan untuk korpus bertopik beragam; sulit dibenarkan untuk kumpulan dokumen homogen.

Apakah ukuran chunk bergantung pada model embedding?

Ya. Model dengan langit-langit input 512 token (BGE, Cohere v3) membutuhkan chunk jauh di bawah 512 karena pemotongan terjadi diam-diam. Model dengan langit-langit 8.192+ menoleransi chunk lebih besar tapi tidak memberinya imbalan; kualitas embedding menurun karena pengenceran sebelum langit-langit. Lihat tabel pasangan di atas untuk titik awal per model.

Bagaimana cara chunking kode untuk sistem RAG?

Bagi pada batas AST (definisi fungsi dan kelas), bukan jumlah token. Jaga setiap chunk pada 256-512 token per fungsi, tambahkan blok import file dan tanda tangan kelas pembungkus di depan, dan pakai nol overlap karena fungsi adalah unit mandiri. CodeSplitter milik LlamaIndex dan splitter sadar bahasa milik LangChain keduanya menangani ini.

Apa itu late chunking?

Late chunking meng-embed dokumen penuh dengan model konteks panjang lebih dulu, lalu menggabungkan embedding level token menjadi vektor chunk. Setiap embedding chunk membawa konteks seluruh dokumen, memecahkan masalah "'itu' merujuk ke apa?". Diperkenalkan oleh Günther dkk. (arXiv 2409.04701, September 2024). Belum ada benchmark head-to-head publik yang mengkuantifikasi keuntungannya.

Bagaimana cara chunking dokumen selain bahasa Inggris?

Jumlah token tidak netral bahasa. Kalimat yang sama memakan token 2,7x lebih banyak dalam bahasa Turki dan Jepang daripada bahasa Inggris, dan 3,9x dalam bahasa Arab (tiktoken cl100k_base). Anggaran tetap 512 token diam-diam memberi chunk non-Inggris makna lebih sedikit. Bagi berdasarkan jumlah karakter atau kalimat per bahasa, atau naikkan anggaran secara proporsional.

Bagaimana tahu chunking saya benar-benar bekerja?

Bangun eval set 20-50 pertanyaan dari query pengguna riil sebelum menyentuh splitter. Skor hit@5 dan MRR terhadap chunk kamu saat ini. Ubah satu variabel (ukuran, overlap, strategi), jalankan ulang, bandingkan. Tanpa eval set, kamu menyetel berdasarkan perasaan. Dua puluh pertanyaan cukup untuk memulai.

Intinya

• Mulai dengan recursive character chunking pada 512 token, 10% overlap. Default tepat untuk prosa datar.
• Di seluruh empat keluarga splitter yang pernah diukur siapa pun, 472 query Chroma menggerakkan recall sekitar 5 poin dan precision beberapa kali lebih banyak. Setel untuk precision dan biaya lebih dulu.
• Cocokkan ukuran chunk dengan langit-langit input model embedding kamu. Model berlangit-langit 512 token menuntut chunk di bawah 512.
• Perkaya chunk dengan konteks (penurunan tingkat kegagalan 5,7% ke 3,7% milik Anthropic) sebelum menyetel ulang splitter.
• Bangun eval set lebih dulu. Setiap keputusan splitter tanpa angka sebelum-dan-sesudah adalah tebakan.

Untuk pipeline penuh di sekitar pilihan chunking kamu, lihat bangun aplikasi RAG dari ujung ke ujung. Masih memutuskan antara retrieval dan fine-tuning? RAG atau fine-tuning membedah kapan masing-masing menang.