Menentukan ukuran chunk sering berubah menjadi debat angka. Ada yang memilih 256 token karena ingin retrieval presisi, ada yang nyaman dengan 512, sementara tim lain menggunakan 1.000 token agar konteks lebih lengkap.
Padahal tidak ada angka ajaib yang cocok untuk semua knowledge base. Cara Memilih Chunking Strategy yang lebih masuk akal adalah memperlakukannya sebagai eksperimen retrieval.
Buat beberapa konfigurasi, jalankan kumpulan pertanyaan yang representatif, lalu ukur apakah sistem menemukan informasi yang benar dengan konteks secukupnya, biaya wajar, dan latency yang masih sesuai kebutuhan produk.
1. Jadikan Chunk Size sebagai Hyperparameter
Chunk size sebaiknya diperlakukan seperti hyperparameter yang perlu dituning.
Alih-alih menetapkan satu ukuran sejak awal, buat beberapa kandidat. Misalnya 256, 512, 800, dan 1.024 token. Angka tersebut hanya titik eksperimen, bukan aturan universal.
Perbedaan default antarplatform juga menunjukkan hal tersebut. OpenAI Vector Stores saat ini memakai maksimum 800 token dengan overlap 400 token pada strategi otomatis, sedangkan Vertex AI RAG Engine mendokumentasikan default chunk 1.024 token.
Amazon Bedrock bahkan menyediakan default sekitar 300 token pada konfigurasi knowledge base tertentu serta pilihan fixed-size, hierarchical, dan semantic chunking.
Jika satu angka optimal berlaku untuk semua use case, variasi seperti ini tidak akan diperlukan.
Karena itu, mulai dengan baseline lalu lakukan eksperimenn menggunakan dataset Anda sendiri.
2. Buat Golden Dataset sebelum Membandingkan Strategi
Anda tidak bisa menentukan chunking terbaik dengan mencoba tiga pertanyaan secara manual.
Buat golden dataset berisi pertanyaan yang benar-benar mencerminkan penggunaan aplikasi. Setiap pertanyaan idealnya mempunyai informasi mengenai dokumen atau bagian mana yang dianggap relevan.
Misalnya knowledge base customer support memiliki 150 pertanyaan. Sebagian berupa fakta sederhana, sebagian membutuhkan dua paragraf, beberapa meminta perbandingan produk, dan sebagian sengaja tidak mempunyai jawaban.
Dataset tersebut kemudian digunakan terhadap beberapa konfigrasi chunking.
Jika chunk 256 token bagus untuk FAQ tetapi buruk untuk pertanyaan multi-step, sedangkan 1.024 token memberikan hasil sebaliknya, tim akhirnya mempunyai data untuk menentukan trade-off.
Microsoft menekankan bahwa strategi chunking dan embedding perlu dioptimalkan sesuai tipe konten serta kebutuhan retrieval pada pipeline RAG.
3. Ukur Recall@K sebelum Menilai Jawaban LLM
Jangan langsung melihat apakah jawaban chatbot terdengar bagus.
Pertama, cek apakah retriever benar-benar menemukan sumber yang tepat.
Salah satu metrik sederhana adalah Recall@K. Jika dokumen relevan muncul dalam lima hasil teratas, retrieval dianggap berhasil untuk query tersebut.
Misalnya terdapat 100 pertanyaan dan sumber yang benar muncul di top-5 pada 86 pertanyaan. Secara sederhana, hit rate atau retrieval success untuk pengujian itu berada di sekitar 86%.
Kemudian bandingkan beberapa chunk size.
Chunk 256 mungkin mencapai 90%, chunk 512 mencapai 94%, sementara chunk 1.024 turun menjadi 87%. Data seperti ini jauh lebih berguna dibanding pendapat bahwa “chunk besar terasa lebih lengkap”.
Azure AI Search menjelaskan bahwa pemecahan konten membantu vector retrieval karena dokumen besar dapat terwakili dengan buruk ketika dipadatkan menjadi satu representasi embedding.
4. Ukur Precision agar Context Tidak Dipenuhi Noise
Recall tinggi belum tentu cukup.
Retriever mungkin menemukan sumber yang benar, tetapi juga membawa banyak chunk tidak relevan. Jika seluruh hasil tersebut dimasukkan ke LLM, context window menjadi penuh dengan noise.
Di sinilah precision penting.
Bayangkan top-5 retrieval menghasilkan satu chunk yang benar dan empat chunk yang nyaris tidak berkaitan. Sumber memang ditemukan, tetapi signal-to-noise ratio masih rendah.
Chunk terlalu besar sering membawa informasi tambahan yang tidak diperlukan. Sebaliknya, ukuran terlalu kecil dapat membuat banyak potongan dari bagian yang sama muncul sebagai hasil terpisah.
Google Cloud menjelaskan bahwa chunk kecil dapat membuat embedding lebih presisi, sedangkan chunk lebih besar cenderung menghasilkan representasi yang lebih umum dan dapat kehilangan detail.
Targetnya bukan memperoleh jumlah chunk sebanyak mungkin, tetapi context relevan sebanyak mungkin dengan noise sesedikit mungkin.
5. Eksperimen dengan Overlap secara Terpisah
Jangan mengubah chunk size dan overlap secara bersamaan pada setiap percobaan. Jika hasil membaik, Anda tidak akan tahu variabel mana yang menyebabkan perubahan.
Misalnya tetapkan chunk size 512 token terlebih dahulu, kemudian bandingkan overlap 0, 64, 128, dan 256 token.
Overlap dapat mempertahankan konteks ketika informasi penting berada di perbatasan dua chunk. Namun overlap berlebihan memperbanyak data redundan.
OpenAI membatasi overlap konfigurasi static chunking agar tidak melebihi setengah ukuran chunk. Dokumentasi Vector Stores saat ini juga memperlihatkan bagaimana chunk size dan overlap diperlakukan sebagai dua parameter yang dapat dikontrol.
Google Vertex AI RAG Engine juga memisahkan chunk_size dan chunk_overlap dalam konfigurasi transformasinya.
Artinya, keduanya layak diuji sebagai variabel terpisah, bukan satu paket tetap.
6. Bandingkan Fixed, Semantic, dan Hierarchical Chunking
Setelah menemukan baseline fixed-size yang cukup bagus, jangan berhenti.
Untuk dokumen yang struktur topiknya jelas, coba semantic chunking. Untuk dokumen panjang yang membutuhkan retrieval presisi sekaligus konteks luas, hierarchical chunking dapat menjadi kandidat.
AWS Bedrock menjelaskan bahwa hierarchical chunking menggunakan child chunk yang lebih kecil untuk retrieval kemudian dapat menggantinya dengan parent chunk yang lebih luas.
Semantic chunking, sementara itu, berusaha menentukan batas berdasarkan perubahan makna dalam teks.
Contohnya pada handbook perusahaan.
Fixed-size mungkin memotong bagian “Kebijakan Perjalanan” menjadi beberapa potongan acak. Semantic chunking dapat mempertahankan kelompok kalimat yang membahas hotel, transportasi, dan reimbursement sebagai unit semantik.
Namun semantic chunking biasanya membutuhkan proses tambahan dan dapat menambah biaya. Karena itu, gunakan jika peningkatan kualitas memang cukup besar untuk membenarkan kompleksitasnya.
7. Hitung Biaya Chunking terhadap Seluruh Pipeline
Lebih banyak chunk berarti lebih banyak embedding yang harus dibuat dan disimpan.
Misalnya satu knowledge base menghasilkan 100.000 chunk dengan konfigurasi A tetapi 250.000 chunk dengan konfigurasi B. Perbedaan tersebut dapat memengaruhi ingestion time, vector storage, index size, dan operasi retrieval.
Chunk terlalu kecil juga bisa membuat banyak hasil diperlukan untuk memberikan konteks lengkap kepada LLM. Akibatnya, token prompt bertambah.
Sebaliknya, chunk besar mengurangi jumlah vector tetapi bisa menurunkan precision.
Amazon Bedrock menjelaskan bahwa dokumen dipecah menjadi chunks sebelum setiap potongan dikonversi menjadi embedding dan disimpan dalam vector index.
Karena itu, evaluasi chunking sebaiknya memasukkan biaya dan latency, bukan hanya accuracy.
Konfigurasi terbaik adalah konfigurasi yang memenuhi target kualitas dengan economics yang masih masuk akal.
8. Evaluasi Berdasarkan Segmen Dokumen
Satu chunking strategy untuk seluruh knowledge base belum tentu ideal.
Dokumentasi API mungkin cocok menggunakan section-aware chunking. FAQ lebih natural jika satu question-answer menjadi satu chunk. Kontrak membutuhkan pembagian berdasarkan klausul, sedangkan transcript percakapan mungkin cocok dengan sliding window.
OpenAI memungkinkan chunking strategy diterapkan pada file dalam vector store, termasuk pengaturan khusus ketika file ditambahkan.
Pendekatan seperti ini membuka kemungkinan konfigurasi berdasarkan tipe dokumen.
Tim dapat menyimpan atribut document_type, lalu menjalankan ingestion berbeda untuk FAQ, contract, manual, dan transcript.
Ini memang menambah kompleksitas, tetapi pada knowledge base besar hasilnya dapat jauh lebih baik daripada memaksa seluruh corpus menggunakan satu aturan.
9. Jadikan Evaluasi sebagai Proses Berkelanjutan
Chunking yang optimal hari ini belum tentu optimal enam bulan lagi.
Knowledge base bertambah, pola pertanyaan berubah, embedding model diperbarui, dan tipe dokumen baru masuk ke sistem.
Karena itu, jalankan regression test ketika melakukan perubahan besar pada parsing, chunking, embedding, atau retrieval configuration.
Pantau juga query production yang gagal. Pertanyaan dengan thumbs down atau retrieval score rendah bisa ditambahkan ke golden dataset untuk pengujiaan berikutnya.
Microsoft menyarankan berbagai teknik advanced RAG seperti overlapping chunks, sliding windows, Small2Big, dan hierarchical organization karena kebutuhan retrieval dapat berbeda berdasarkan karakter informasi.
Dengan observabilty seperti ini, strategi chunking berkembang berdasarkan perilaku pengguna nyata, bukan hanya benchmark laboratorium.
Cara Memilih Chunking Strategy yang paling efektif adalah melalui eksperimen terukur. Bandingkan ukuran, overlap, fixed-size, semantic, dan hierarchical chunking menggunakan golden dataset serta metrik retrieval.
Jangan lupa mempertimbangkan latency dan biaya embedding. Mulailah dari baseline sederhana, ukur Recall@K dan precision, lalu ubah satu variabel pada satu waktu sampai menemukan konfigurasi terbaik untuk data Anda.