Strategi chunking
Chunking adalah keputusan paling berdampak di seluruh pipeline RAG. Potongan terlalu kecil kehilangan konteks; terlalu besar mengaburkan sinyal.
Intisari
- Default: sekitar 300 token, menghormati batas kalimat. Titik awal yang wajar.
- Fixed-size: kamu tentukan jumlah token dan persentase tumpang tindih.
- Hierarchical: cari dengan potongan anak yang presisi, kirim potongan induk yang kaya konteks.
- Semantic: memotong di tempat makna berganti, bukan di hitungan token.
- No chunking: satu berkas = satu potongan — tapi kamu kehilangan nomor halaman di sitasi.
Kenapa ini keputusan terbesar
Retrieval bekerja dengan membandingkan embedding pertanyaan dengan embedding potongan. Kalau satu potongan memuat lima topik, vektornya adalah rata-rata kelima topik itu — dan tidak benar-benar mirip dengan pertanyaan mana pun. Sebaliknya, potongan sepanjang satu kalimat memang presisi, tapi model menerimanya tanpa konteks yang membuatnya bermakna.
Empat strategi
| Strategi | Cara kerja | Paling cocok untuk |
|---|---|---|
| Default | ±300 token, memotong di batas kalimat | Titik awal; dokumen prosa biasa |
| Fixed-size | Jumlah token yang kamu tentukan + persentase overlap | Saat kamu sudah tahu struktur dokumenmu |
| Hierarchical | Potongan anak untuk mencari, potongan induk untuk konteks | Dokumen panjang berstruktur: manual, kebijakan, regulasi |
| Semantic | Memotong saat topik berganti | Teks yang topiknya berpindah tanpa penanda struktur |
| No chunking | Satu berkas = satu potongan | Berkas yang sudah kamu potong sendiri sebelumnya |
Hierarchical: yang paling sering menang
Ini penyelesaian elegan atas ketegangan presisi-versus-konteks. Sistem mencari memakai potongan anak yang kecil dan presisi, lalu menggantinya dengan potongan induk yang lebih besar sebelum dikirim ke model.
Induk (mis. 1500 token) ── inilah yang dikirim ke model
├─ Anak (mis. 300 token) ── inilah yang dicari
├─ Anak
└─ Anak
Efek samping yang membingungkan: karena beberapa potongan anak bisa punya induk yang sama, dan
anak digantikan induknya, jumlah hasil yang kembali bisa lebih sedikit dari
numberOfResults yang kamu minta. Ini bukan bug. Kode yang mengasumsikan "minta 5, dapat 5"
akan salah di sini.
Dua catatan tambahan dari dokumentasi: chunking hierarkis tidak dianjurkan kalau vector store-mu adalah S3 vector bucket, dan gabungan token yang terlalu besar (di atas ~8.000 token) bisa menabrak batas ukuran metadata.
Konfigurasi
// Fixed-size
{
"chunkingConfiguration": {
"chunkingStrategy": "FIXED_SIZE",
"fixedSizeChunkingConfiguration": {
"maxTokens": 512,
"overlapPercentage": 20
}
}
}
// Hierarchical
{
"chunkingConfiguration": {
"chunkingStrategy": "HIERARCHICAL",
"hierarchicalChunkingConfiguration": {
"levelConfigurations": [ { "maxTokens": 1500 }, { "maxTokens": 300 } ],
"overlapTokens": 60
}
}
}
Overlap
Tumpang tindih mencegah kalimat penting terbelah tepat di batas potongan. Sekitar 10–20% adalah titik awal yang masuk akal. Terlalu besar berarti kamu membayar penyimpanan dan embedding untuk teks yang sama berkali-kali; terlalu kecil berisiko memotong tepat di tengah definisi yang dicari orang.
Yang berlaku dan tidak berlaku
| Jenis konten | Chunking teks berlaku? |
|---|---|
| Dokumen teks (PDF, DOCX, MD) | Ya |
| Audio, video, gambar | Tidak — pemotongan terjadi di level model embedding |
| Konten hasil parsing lanjutan | Ya, tapi Bedrock menghormati batas logis seperti halaman dan bagian, dan tidak menggabungkan lintas batas itu |
Cara memilih tanpa menebak
- Susun 20 pertanyaan nyata beserta jawaban yang kamu tahu benar.
- Ingest korpus yang sama dengan dua strategi berbeda, ke dua knowledge base.
- Jalankan
retrieveuntuk 20 pertanyaan itu di keduanya. - Hitung berapa kali potongan yang benar muncul di lima besar.
- Pilih yang menang. Simpan angkanya — itu baseline untuk evaluasi di Fase 7.
Latihan: ingest korpus yang sama dua kali — sekali dengan fixed-size 300 token, sekali dengan hierarchical (induk 1500, anak 300). Jalankan sepuluh pertanyaan yang sama ke keduanya dan hitung berapa kali potongan yang benar masuk lima besar. Simpan hasilnya sebagai berkas JSON; ia akan jadi baseline evaluasimu.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.