← Semua pembelajaran / AWS untuk AI Engineer
Fase 4 · RAG & Knowledge Bases

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

StrategiCara kerjaPaling cocok untuk
Default±300 token, memotong di batas kalimatTitik awal; dokumen prosa biasa
Fixed-sizeJumlah token yang kamu tentukan + persentase overlapSaat kamu sudah tahu struktur dokumenmu
HierarchicalPotongan anak untuk mencari, potongan induk untuk konteksDokumen panjang berstruktur: manual, kebijakan, regulasi
SemanticMemotong saat topik bergantiTeks yang topiknya berpindah tanpa penanda struktur
No chunkingSatu berkas = satu potonganBerkas 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 kontenChunking teks berlaku?
Dokumen teks (PDF, DOCX, MD)Ya
Audio, video, gambarTidak — pemotongan terjadi di level model embedding
Konten hasil parsing lanjutanYa, tapi Bedrock menghormati batas logis seperti halaman dan bagian, dan tidak menggabungkan lintas batas itu

Cara memilih tanpa menebak

  1. Susun 20 pertanyaan nyata beserta jawaban yang kamu tahu benar.
  2. Ingest korpus yang sama dengan dua strategi berbeda, ke dua knowledge base.
  3. Jalankan retrieve untuk 20 pertanyaan itu di keduanya.
  4. Hitung berapa kali potongan yang benar muncul di lima besar.
  5. 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.