LexRAGLab: Mengukur Chunking untuk Dokumen Hukum Indonesia

Dari mana masalahnya

Sebagian pekerjaan saya sekarang adalah pekerjaan hukum yang dibantu agen: pendapat hukum, legal due diligence, penyusunan kontrak. Agennya harus membaca peraturan, dan peraturannya hampir tidak pernah muat dalam satu context window.

Angkanya dari pekerjaan saya sendiri. Satu undang-undang yang dirujuk untuk satu pendapat hukum panjangnya sekitar 320 ribu token, lebih besar dari jendela 200 ribu token. Dari teks itu, yang benar-benar terpakai hanya sekitar 10%. Satu berkas due diligence lengkap bisa mencapai 5,8 juta token. Jadi agen harus diberi potongan, dan pertanyaannya selalu sama: potongan yang mana, dengan ukuran berapa?

Jawaban yang lazim adalah mengambil angka dari tutorial, misalnya 512 token dengan overlap 64. Untuk teks peraturan, angka itu bisa memotong ayat di tengah. Model lalu mengutip separuh norma dengan yakin. Kalau ada yang bertanya kenapa 512, tidak ada angka untuk menjawabnya. Begitu pindah ke jenis dokumen lain, misalnya akta, kita menebak lagi dari awal.

Sebelumnya saya sudah membuat ChunkLab untuk melihat hasil berbagai strategi chunking pada teks hukum. ChunkLab berguna untuk melihat hasil potongan, tetapi tidak memberi angka untuk memilih di antaranya. LexRAGLab saya buat untuk itu.

Batas yang saya tetapkan sejak awal

Hackathon-nya berlangsung 26 Oktober sampai 4 November 2026, track Indie, dengan tema “Build for Your World”. Model yang dipakai Muse Spark lewat Meta Model API. Spesifikasi saya siapkan sebelum acara dimulai; semua kode ditulis selama acara.

Beberapa batas saya kunci di spesifikasi, sebelum ada satu baris kode pun.

Pertama, jawaban yang benar disimpan sebagai rentang karakter di dokumen sumber (gold span), bukan sebagai chunk. Dengan begitu satu set butir evaluasi bisa dipakai menilai chunker apa pun. Satu gold span menandai semua ayat yang dibutuhkan untuk menjawab.

Kedua, setting dibandingkan pada anggaran token yang sama, bukan pada jumlah chunk yang sama. Membandingkan top-5 chunk 256 token dengan top-5 chunk 1.024 token tidak adil. Yang relevan bagi agen adalah berapa banyak bukti yang masuk dalam 2.000 token.

Ketiga, setting dipilih di satu split (tune) dan dilaporkan di split lain (held-out). Hasilnya ditampilkan per butir dengan hitungan mentah. Butirnya sedikit, jadi saya tidak membuat klaim signifikansi.

Keempat, model tidak pernah menjadi juri. Muse Spark punya empat peran: mengusulkan skema struktur dokumen, menulis context header per chunk, menjawab dengan sitasi, dan mengusulkan butir evaluasi. Setiap usulan saya review sebelum dipakai. Sitasi pada jawaban diperiksa verifier deterministik, bukan oleh LLM lain. Pencarian grid tidak memanggil LLM.

Yang terjadi selama sembilan hari

Saya bekerja dengan agen pengembang dalam pola orkestrasi: satu agen merencanakan, agen lain mengerjakan, agen terpisah memeriksa. Ada dua aturan yang tidak bisa ditawar. Agen tidak boleh menulis atau menyetujui butir evaluasi, dan setiap angka di README harus bisa ditelusuri ke berkas run yang tersimpan. Aturan kedua itu ditegakkan dengan tes: angka biaya di README dicocokkan dengan run yang tersimpan.

Korpus utamanya UU 40/2007 tentang Perseroan Terbatas, versi konsolidasi tidak resmi per 30 Desember 2022 yang saya susun dari teks undang-undang dan putusan Mahkamah Konstitusi terkait. Panjangnya 46.583 token. Ada 23 butir evaluasi: sebagian saya tulis sendiri sebagai kontrol, sebagian diusulkan Muse Spark lalu saya setujui atau sunting. Tiga di antaranya butir yang jawabannya memang tidak ada di undang-undang, dan jawaban yang benar adalah menolak.

Keluarga dokumen kedua adalah akta notaris. Akta tidak punya parser. Tidak ada aturan baku seperti “Pasal” dan “ayat” yang bisa dipakai untuk memotongnya. Saya memberi Muse Spark beberapa contoh akta dan memintanya mengusulkan hierarki strukturnya. Usulannya masih perlu dikoreksi, dan saya koreksi. Kedua versi disimpan berdampingan supaya terlihat apa yang diusulkan model dan apa yang saya ubah. Chunker deterministik kemudian berjalan di atas skema hasil koreksi itu.

Hasil

Untuk UU PT, setting yang terpilih adalah chunker berbasis skema struktur, retrieval dense, tanpa context header, dengan anggaran 2.000 token. Di split held-out, 6 dari 8 butir yang punya gold span tercakup penuh, dengan rata-rata span recall 0,75.

Dua butir yang meleset lebih informatif daripada enam yang berhasil.

Butir pertama menanyakan pemberhentian anggota Dewan Komisaris. Jawabannya ada di Pasal 119, yang isinya hanya satu kalimat rujukan: ketentuan Pasal 105 berlaku mutatis mutandis. Pasal sependek itu hampir tidak punya kemiripan makna dengan pertanyaannya, sehingga retrieval justru menarik pasal-pasal tetangga yang lebih panjang tentang komisaris dan direksi. Praktisi hukum langsung mengenali pola ini: norma yang sebenarnya ada di pasal lain, dan pasal yang dirujuk hanya menjadi jembatan.

Butir kedua menanyakan kewajiban Tanggung Jawab Sosial dan Lingkungan di Pasal 74. Kali ini chunk yang benar ada di lima teratas. Masalahnya, dua chunk dengan peringkat lebih tinggi adalah Pasal 1 (ketentuan umum) dan Penjelasan Umum. Keduanya menghabiskan 1.941 dari 2.000 token, sehingga chunk yang benar tidak pernah masuk konteks.

Untuk akta, saya menerapkan setting UU PT tanpa memilih apa pun dari data akta. Dengan skema struktur hasil koreksi dan retrieval dense, 69 dari 69 butir tercakup penuh. Fixed-size 512/64 mencakup 64. Satu chunk per akta mencakup 0 karena melebihi anggaran. Akta ini hanya lima dan semuanya sintetis, jadi angka ini saya baca sebagai uji transfer, bukan hasil utama.

Biaya pemanggilan model untuk hasil utama sekitar 0,56 dolar AS.

Catatan setelahnya

Dari data yang masih kecil ini, ukuran chunk tampaknya bukan variabel yang paling menentukan. Yang lebih berpengaruh adalah apakah potongan mengikuti struktur dokumen, dan apakah struktur itu bisa diperoleh untuk jenis dokumen yang tidak punya parser. Untuk pertanyaan kedua, model bahasa ternyata berguna sebagai pengusul, asalkan ada manusia yang mengoreksi dan versi koreksinya tercatat.

Kegagalan di Pasal 119 dan Pasal 74 menunjukkan dua masalah yang perlu dijawab lain: rujukan silang antarpasal, dan bagian umum seperti definisi yang selalu dianggap relevan lalu memakan anggaran. Keduanya tidak akan terlihat kalau evaluasinya hanya melaporkan satu angka rata-rata.

Keluarga dokumen berikutnya yang ingin saya uji adalah kebijakan internal perusahaan. Repo, video demo, dan replay statis yang bisa dicoba tanpa API key tautannya ada di halaman proyek.

LexRAGLab adalah demo riset. Keluarannya bukan nasihat hukum.