Knowledge base internal dapat menjawab pertanyaan dengan tepat tetapi tetap gagal jika menampilkan dokumen kepada pengguna yang tidak berwenang. Pada RAG, kualitas jawaban dan batas akses adalah dua hal yang perlu dievaluasi terpisah. Demo dengan satu akun admin tidak membuktikan perilaku untuk seluruh perusahaan.
Evaluasi RAG hak akses dokumen membantu data owner, IT, security, dan pemilik knowledge base menyiapkan pilot yang menguji siapa dapat menemukan informasi apa. Fokusnya adalah permission pada retrieval, sumber jawaban, perubahan akses, dan bukti evaluasi; bukan panduan kesiapan AI secara umum.
RAG Tidak Otomatis Mewarisi Semua Permission
Retrieval-Augmented Generation mengambil informasi yang relevan lalu menggunakan informasi tersebut sebagai konteks jawaban. Jika dokumen disalin ke index atau dipecah menjadi chunk, aturan akses dari sumber perlu dipertahankan sesuai desain. Model tidak dapat diasumsikan mengetahui kebijakan perusahaan hanya dari prompt.
Microsoft Learn membahas document-level access control pada Azure AI Search, termasuk security filters serta pendekatan permission native tertentu. Dokumentasi yang diperiksa pada 12 Oktober 2026 masih menandai beberapa pendekatan native sebagai preview. Status fitur, sumber yang didukung, serta mekanisme sinkronisasi perlu diperiksa saat memilih implementasi.
Contoh tersebut merupakan rujukan pola, bukan rekomendasi bahwa setiap perusahaan harus menggunakan Azure. Pada pendekatan apa pun, tim perlu membuktikan filter identitas dan metadata akses di jalur retrieval yang benar-benar digunakan aplikasi.
Pisahkan Tiga Pertanyaan Evaluasi
- Akses: apakah pengguna hanya menerima dokumen atau chunk yang diizinkan?
- Retrieval: apakah sumber yang diperlukan ditemukan dari kumpulan yang boleh diakses?
- Jawaban: apakah jawaban sesuai bukti, menyebut sumber yang tepat, dan mengakui informasi yang tidak tersedia?
Jawaban yang terdengar benar belum membuktikan retrieval benar. Model mungkin menggunakan pengetahuan umum atau menebak ketika dokumen tidak ditemukan. Sebaliknya, retrieval yang relevan belum membuktikan pengguna berhak melihatnya.
Gunakan kesiapan AI proses bisnis dan data untuk memilih use case awal. Setelah use case dipilih, evaluasi dalam artikel ini memperdalam batas akses dan kualitas hasil retrieval.
Buat Matriks Pengguna dan Dokumen
Petakan organisasi, unit, role, kelompok akses, dan status pengguna. Bedakan akun biasa, supervisor, pemilik dokumen, serta admin. Jangan menganggap akses satu cabang otomatis berlaku untuk cabang lain.
Untuk dokumen, catat owner, klasifikasi, versi, masa berlaku, sumber permission, serta hubungan induk dengan chunk. Dokumen dengan judul sama dapat berlaku untuk unit berbeda. Metadata tersebut perlu tersedia agar sistem tidak mencampur kebijakan.
Matriks evaluasi perlu memiliki expected result: pengguna mana dapat membaca dokumen, siapa harus ditolak, dan kondisi perubahan akses. Data owner menyetujui matriks sebelum pengujian. Tim tidak boleh menentukan jawaban benar hanya dari hasil aplikasi yang sedang diuji.
Filter Sebelum Konteks Dibawa ke Model
Rancang retrieval agar hanya mengembalikan informasi yang berwenang ke konteks model. Menyuruh model menyembunyikan dokumen setelah menerima isinya tidak setara dengan membatasi akses. Kontrol harus bekerja pada server serta tool retrieval.
Identitas pengguna berasal dari session tepercaya, bukan role yang diketik dalam percakapan. Pengguna yang menulis “saya direktur” tidak memperoleh hak baru. Parameter organisasi dari browser perlu divalidasi terhadap keanggotaan yang sah.
Periksa seluruh jalur: pencarian, preview, kutipan sumber, tautan unduh, cache jawaban, dan log. Filter pada satu endpoint tidak membantu jika jalur lain mengembalikan potongan dokumen tanpa pemeriksaan yang sama.
Skenario Ilustratif: Dokumen HR Masuk Knowledge Base Umum
Bayangkan SOP publik internal dan lampiran kompensasi disimpan dalam satu folder. Proses indexing mengambil keduanya. Pengguna operasi bertanya tentang prosedur cuti, lalu retrieval membawa chunk lampiran yang seharusnya terbatas untuk HR. Skenario ini ilustratif, bukan kejadian di Layana.ID atau klien.
Jawaban dapat tidak menyebut angka kompensasi, tetapi kebocoran tetap perlu dinilai jika konteks, log, atau kutipan sumber memuat lampiran. Pemeriksaan harus melihat sumber yang diteruskan dan output yang dapat diakses pengguna, bukan hanya paragraf jawaban akhir.
Perbaikannya bukan sekadar menambah kalimat larangan pada prompt. Tim perlu memisahkan permission, memastikan metadata pada chunk, memeriksa jalur retrieval, serta menguji ulang akun yang seharusnya ditolak.
Uji Perubahan Permission dan Dokumen
Hak akses berubah ketika pengguna berpindah unit, keluar dari kelompok, atau meninggalkan perusahaan. Dokumen juga dapat dicabut, dipindah, atau diganti versinya. Tentukan waktu propagasi yang dapat diterima dan perilaku selama sinkronisasi belum selesai.
Cache perlu memperhitungkan identitas serta konteks akses yang relevan. Jawaban untuk akun HR tidak boleh tersedia bagi akun operasi hanya karena pertanyaannya sama. Session baru, logout, dan perubahan organisasi aktif perlu masuk set uji.
Pencabutan akses perlu diuji dengan akun yang sebelumnya pernah membaca dokumen. Ini menantang asumsi bahwa filter baru sudah mencakup cache lama. Gunakan identity lifecycle management enterprise untuk memetakan kejadian perubahan identitas.
Siapkan Set Evaluasi yang Menantang
Gabungkan pertanyaan yang jawabannya tersedia, tidak tersedia, berasal dari versi lama, atau memerlukan dokumen terlarang. Tambahkan istilah ambigu, judul mirip antar-unit, tabel panjang, serta dokumen yang mengandung instruksi menyesatkan.
Isi dokumen merupakan data, bukan authority untuk memanggil tool atau mengubah kebijakan. Uji pertanyaan yang mencoba meminta sistem mengabaikan permission menggunakan akun dan data uji yang disetujui. Jangan melakukan percobaan pada data privat nyata tanpa ruang lingkup khusus.
Simpan hasil per kasus: identitas aktor, sumber yang boleh diakses, hasil retrieval, sumber yang dibawa ke model, jawaban, kutipan, dan keputusan evaluator. Catatan harus cukup untuk mengulang temuan tanpa menyebarkan isi sensitif ke laporan umum.
KPI yang Memisahkan Kualitas dan Risiko
- Jumlah kasus akses terlarang yang mengembalikan informasi pada jalur yang diuji.
- Proporsi sumber relevan yang ditemukan pada set dokumen berizin.
- Ketepatan jawaban serta kecocokan kutipan terhadap bukti.
- Perilaku abstain ketika sumber tidak cukup atau tidak tersedia.
- Waktu propagasi perubahan akses yang benar-benar teramati.
- Biaya dan waktu per pertanyaan yang diterima evaluator.
Kasus kebocoran harus dilaporkan sebagai temuan, bukan disamarkan dalam rata-rata akurasi. Jika tidak ada kebocoran pada set uji, klaimnya terbatas pada akun, data, jalur, dan kondisi yang diuji. Itu tidak membuktikan seluruh sistem bebas risiko.
Pilot dan Gate Sebelum Perluasan
Mulai dari koleksi dokumen yang owner serta permission-nya jelas. Pisahkan lingkungan uji dari produksi, batasi pengguna pilot, dan kunci versi sumber serta konfigurasi selama evaluasi. Perubahan index atau filter memerlukan pengujian ulang terhadap kasus akses kritis.
Owner bisnis menilai kegunaan jawaban; data owner menyetujui batas sumber; IT dan security memeriksa implementasi akses. Gunakan AI governance enterprise untuk keputusan perluasan berdasarkan bukti, bukan hanya demo yang berhasil.
FAQ Evaluasi RAG
Apakah Deployment Lokal Menjamin Permission Benar?
Tidak otomatis. Lokasi deployment dan otorisasi dokumen adalah kontrol berbeda. Permission, cache, tool, serta log tetap perlu diperiksa pada implementasi lokal.
Apakah Kutipan Sumber Membuktikan Jawaban Benar?
Tidak selalu. Periksa apakah sumber benar-benar mendukung pernyataan, versinya berlaku, dan pengguna berhak mengaksesnya.
Siapkan Matriks Akses untuk Pilot
Bawa contoh dokumen yang boleh dipakai, role pengguna, sumber permission, pertanyaan evaluasi, dan aturan perubahan akses. Tinjau layanan RAG dan AI bisnis Layana.ID, lalu diskusikan pilot evaluasi RAG dan hak akses dokumen dengan acceptance criteria yang dapat dibuktikan.
Referensi
Microsoft Learn — Document-level access control in Azure AI Search; Best practices for security in Azure AI Search. Sumber resmi diperiksa pada 12 Oktober 2026 dan ditulis tanpa tautan keluar. Checklist, skenario, serta KPI merupakan analisis editorial; bukan jaminan privasi, klaim tanpa halusinasi, atau portofolio AI Layana.ID.