RAG untuk Knowledge Base Pajak Internal: Cara membuat jawaban konsisten tanpa mengarang regulasi

Mulai dari pertanyaan yang sempit

Jangan membangun chatbot untuk “menjawab semua pajak”. Pilih use case: mencari prosedur internal, menjawab FAQ invoice, menemukan pasal, atau membantu triase bukti potong. Tentukan pengguna, keputusan yang boleh dibuat, dan hal yang wajib dieskalasi.

Misalnya, chatbot AP boleh menjawab dokumen apa yang diperlukan untuk vendor tertentu berdasarkan policy yang disetujui. Ia tidak boleh menentukan beneficial ownership atau posisi treaty final. Batas scope ditampilkan pada jawaban dan diterapkan pada sistem.

Tulis success criteria: sumber benar, kutipan relevan, tanggal berlaku terlihat, abstain pada pertanyaan di luar scope, serta tidak membuka dokumen yang tidak boleh diakses. Jumlah jawaban bukan tujuan utama.

Kualitas corpus menentukan kualitas jawaban

Masukkan sumber primer resmi: JDIH, pajak.go.id, peraturan, dan panduan otoritas. Simpan metadata dokumen: judul, nomor, jenis, tanggal penetapan, tanggal berlaku, status, mengubah, diubah oleh, mencabut, bahasa, sumber, dan tanggal akses.

Dokumen internal mempunyai metadata owner, approval, versi, tanggal efektif, scope entitas, dan confidentiality. Draft diberi label dan tidak menjadi sumber jawaban produksi. Opini eksternal dibatasi pada engagement serta fakta yang sesuai; jangan menjadikannya aturan umum.

Hapus duplikasi yang membingungkan, tetapi pertahankan versi historis untuk transaksi lama. Sistem harus memilih aturan berdasarkan tanggal transaksi, bukan selalu dokumen terbaru. Superseded tidak berarti dihapus; berarti tidak digunakan untuk periode setelah berakhir.

OCR dokumen scan harus diuji. Nomor pasal, tabel, dan simbol tarif rawan salah. Pertahankan PDF asli dan teks hasil ekstraksi. Field kritis dibandingkan visual.

Chunking hukum tidak sama dengan memotong setiap 500 token

Pasal dapat bergantung pada ayat sebelumnya, definisi, pengecualian, lampiran, dan ketentuan transisi. Chunk terlalu kecil menghilangkan konteks. Chunk terlalu besar menurunkan relevansi.

Gunakan struktur dokumen: bab, pasal, ayat, dan lampiran. Simpan parent-child link. Retrieval dapat mengambil ayat relevan bersama definisi atau pasal induk. Tabel dipertahankan sebagai unit bila baris saling berhubungan.

Tambahkan cross-reference. Jika Pasal 10 merujuk Pasal 3, sistem dapat membawa keduanya. Namun jangan menambahkan teks yang tidak ada. Link dan metadata terpisah dari isi resmi.

Untuk memo internal, chunk berdasarkan issue, facts, analysis, conclusion, dan limitation. Jangan mengambil conclusion tanpa facts. RAG harus memperlihatkan bahwa opini berlaku pada asumsi tertentu.

Retrieval perlu filter sebelum similarity

Pertama, filter hak akses. Kedua, filter periode dan status. Ketiga, filter yurisdiksi, entitas, jenis pajak, serta bahasa. Baru kemudian semantic atau keyword search. Jika similarity dijalankan pada seluruh corpus, dokumen populer dapat mengalahkan sumber yang benar.

Gunakan hybrid search. Nomor PMK dan pasal cocok dengan keyword exact; pertanyaan natural cocok dengan semantic search. Reranker dapat menilai kandidat, tetapi hasilnya diuji.

Pertanyaan ambigu memicu klarifikasi. “Tarif jasa berapa?” tidak cukup. Sistem meminta jenis jasa, pihak, domisili, tanggal, status, dan konteks. Jangan mencari dokumen lalu memaksakan jawaban.

Tampilkan retrieved evidence pada log. Ukur apakah sumber benar berada di top-k. Generation accuracy tidak dapat baik jika retrieval gagal.

Prompt harus melarang pengetahuan bebas menggantikan corpus

Instruksi produksi menyatakan: jawab hanya dari sumber yang diberikan; pisahkan kutipan dan interpretasi; tampilkan nomor dokumen serta tanggal; jangan mengarang; jika sumber kurang atau konflik, katakan tidak cukup dan eskalasi.

Namun prompt bukan kontrol tunggal. Model masih dapat mengisi celah. Gunakan structured output dengan claim, source ID, passage, confidence, assumption, dan escalation. Validator memeriksa setiap source ID benar-benar ada serta passage mendukung klaim.

Untuk angka, tanggal, tarif, dan threshold, terapkan exact verification. Kalkulasi dilakukan tool deterministik setelah input disetujui. Model menjelaskan, bukan menghitung bebas ketika risiko tinggi.

Jawaban harus memisahkan tiga lapis: apa kata aturan, bagaimana policy perusahaan menerapkan, dan apa yang belum diketahui dari kasus. Campuran lapis membuat pengguna mengira policy internal adalah hukum.

Citation yang dapat dibuka

Setiap klaim material mempunyai tautan ke dokumen dan lokasi pasal atau halaman. Pengguna dapat membuka sumber. Jangan hanya menulis “[1]” yang mengarah ke homepage atau dokumen berbeda.

Kutipan pendek mempertahankan wording penting tanpa memenuhi jawaban dengan teks. Interpretasi diberi label. Jika dua sumber konflik, tampilkan keduanya dan statusnya. Dokumen terbaru tidak otomatis menang jika transaksi terjadi pada periode lama.

Untuk dokumen internal, citation tunduk pada ACL. Pengguna yang tidak boleh melihat memo tidak boleh memperoleh isi melalui jawaban. Security trimming harus terjadi sebelum retrieval dan generation.

Versioning dan effective date

Peraturan berubah. Knowledge base mempunyai update pipeline: monitoring sumber resmi, intake, verifikasi metadata, legal review, approval, indexing, dan regression test. Jangan langsung mengindeks setiap berita.

Ketika aturan baru mengubah yang lama, relationship diperbarui. Pertanyaan periode transisi diuji. Jawaban cache invalidated. Owner menerima daftar FAQ dan mapping yang terdampak.

Cache dapat mempercepat jawaban tetapi menjadi sumber staleness. Cache key harus memasukkan versi corpus, tanggal efektif, yurisdiksi, dan hak akses. Jangan mengirim jawaban lama kepada pengguna baru yang tidak mempunyai akses sumber. Tetapkan TTL sesuai volatilitas topik.

Saat dokumen dicabut atau ACL berubah, purge cache dan embedding terkait. Uji bahwa potongan lama tidak muncul melalui semantic search. Backup mengikuti lifecycle dan tidak menjadi jalan memulihkan dokumen tanpa otorisasi.

Popular answer boleh disimpan sebagai approved FAQ setelah review. FAQ mempunyai owner serta expiry. Ia tidak menggantikan retrieval untuk pertanyaan yang fact pattern-nya berbeda.

Tampilkan “berdasarkan sumber sampai tanggal X” dan tanggal akses. Jika update pipeline gagal, sistem memberi peringatan. Silent staleness lebih berbahaya daripada downtime.

Policy internal juga mempunyai expiry dan review date. Owner diingatkan. Dokumen tanpa owner masuk quarantine, bukan terus menjawab.

Evaluation yang benar-benar menantang

Bangun test set dari pertanyaan nyata yang sudah dianonimkan. Sertakan jawaban, sumber, periode, dan alasan eskalasi. Tambahkan negative cases: nomor PMK palsu, aturan dicabut, pertanyaan ambigu, source conflict, prompt injection, dan permintaan data tanpa akses.

Ukur retrieval recall, citation precision, groundedness, factual accuracy, abstention, access control, dan latency. Human tax reviewer menilai sampel. Jangan hanya memakai model lain sebagai judge.

Regression test dijalankan setiap perubahan corpus, embedding, chunking, prompt, model, atau reranker. Satu update dapat memperbaiki satu topik dan merusak lainnya.

Red team mencoba membuat model mengabaikan sumber, mengungkap dokumen rahasia, atau mengikuti instruksi dalam PDF. Dokumen diperlakukan sebagai data. Prompt injection tidak boleh mengubah policy sistem.

Bahasa juga diuji. Pertanyaan Indonesia dapat mengambil dokumen Inggris, dan istilah pajak tidak selalu mempunyai padanan satu-ke-satu. Simpan judul resmi serta alias, tetapi jangan menerjemahkan kutipan seolah verbatim. Tampilkan bahasa sumber dan beri terjemahan sebagai penjelasan.

Typo, singkatan kantor, dan istilah lama masuk synonym dictionary yang direview. Jangan membiarkan model mengubah NPWP, PMK, atau nama formulir karena autocorrect. Query expansion dicatat sehingga retrieval dapat dijelaskan.

Jawaban bilingual diuji untuk konsistensi angka, tanggal, dan negasi. Terjemahan “not subject” berbeda dari “exempt” dalam konteks tertentu. Reviewer pajak memeriksa istilah material.

Workflow eskalasi yang hidup

Ketika pertanyaan di luar scope, sumber kurang, confidence rendah, atau nilai material, chatbot membuat tiket. Tiket memuat pertanyaan, fakta, sumber yang ditemukan, dan gap. Tax team tidak perlu mengulang pencarian dari nol.

Jawaban profesional kemudian dapat ditambahkan sebagai policy atau FAQ setelah approval, bukan otomatis dari chat. Feedback pengguna masuk queue. Koreksi mempunyai owner dan tanggal.

Ukur aging eskalasi dan topik berulang. Jika banyak pertanyaan sama, perbaiki policy atau training. Jika semua pertanyaan dieskalasi, scope mungkin terlalu sempit atau corpus buruk. Jika tidak ada yang dieskalasi, sistem mungkin terlalu percaya diri.

Data dan hak akses

Jangan mengindeks seluruh drive. Klasifikasikan dan minimalkan. SPT, payroll, kontrak, dan memo sengketa mempunyai ACL. Vector database dapat membocorkan informasi jika filter salah atau embedding dipakai lintas tenant.

Enkripsi, SSO, MFA, role, logging, dan incident response tetap diperlukan. Prompt dan output mengikuti retensi. Vendor model dinilai dari penggunaan data, lokasi, subprocessor, serta penghapusan.

Untuk query kasus, data sensitif dimasking. RAG peraturan tidak membutuhkan nama klien. Jika perlu dokumen transaksi, gunakan workspace terisolasi dan scope pengguna.

Arsitektur minimum yang dapat dipertanggungjawabkan

Lapisan pertama adalah repository sumber dengan versioning. Kedua, ingestion yang mengekstrak serta memberi metadata. Ketiga, index dengan ACL dan filter. Keempat, retrieval hybrid. Kelima, model dengan grounded prompt. Keenam, validator citation dan policy. Ketujuh, UI yang menampilkan sumber serta eskalasi. Kedelapan, monitoring dan evaluation.

Setiap lapisan mempunyai log dan owner. Jika jawaban salah, tim dapat menemukan apakah sumber, OCR, chunk, retrieval, model, atau UI penyebabnya. Tanpa observability, semua kesalahan disebut hallucination meski sebenarnya document governance gagal.

Sediakan dashboard error budget. Citation palsu, kebocoran akses, dan jawaban aturan dicabut mempunyai toleransi nol serta memicu stop. Relevansi rendah dapat masuk backlog. Severity membantu tim tidak menyamakan typo dengan insiden data.

Mulai dari 50 dokumen berkualitas, bukan 50.000 file acak. Pilot pada satu jenis pajak dan pengguna terbatas. Jalankan shadow mode. Perluas setelah groundedness, access control, dan workflow terbukti.

RAG yang baik tidak berusaha terdengar tahu segalanya. Ia membuat batas pengetahuan terlihat. Jawaban selalu kembali ke sumber, periode, dan fakta. Ketika ketiganya tidak cukup, sistem berhenti.

Konsistensi pajak bukan berarti satu kalimat dipakai untuk semua kasus. Konsistensi berarti fakta sejenis diproses dengan policy dan sumber yang sama, sementara perbedaan fakta mengubah jawaban secara transparan. RAG dapat membantu mencapai itu jika corpus, retrieval, dan review dikelola lebih serius daripada demo chatbotnya.