Pembaruan knowledge base RAG menentukan apakah AI bisnis menjawab berdasarkan dokumen yang masih berlaku. Mengunggah SOP baru belum membuktikan jawaban lama telah hilang. Tim perlu mengendalikan versi sumber, indeks pencarian, cache, serta bukti bahwa dokumen yang dicabut tidak lagi digunakan pada pertanyaan yang relevan.
Risikonya terasa ketika kebijakan berubah. Pengguna bertanya tentang prosedur pengadaan, sementara sistem mengambil potongan dokumen lama yang masih tersimpan. Jawaban dapat terlihat rapi dan mencantumkan sumber, tetapi sumbernya sudah tidak berlaku. Artikel ini membahas lifecycle pembaruan dan pencabutan, melengkapi pembahasan evaluasi RAG dan hak akses dokumen.
Definisikan “Berlaku” sebelum Mengatur Jadwal Sinkronisasi
Knowledge base membutuhkan keputusan bisnis tentang dokumen aktif. Tanggal unggah tidak sama dengan tanggal efektif. Dokumen dapat disetujui hari ini tetapi berlaku bulan depan, atau hanya berlaku untuk lokasi tertentu. Ada pula lampiran yang tetap aktif meskipun dokumen induknya diganti.
Catat document ID, versi, pemilik, status persetujuan, tanggal efektif, tanggal berakhir, entitas, lokasi, bahasa, hak akses, dan dokumen pengganti. Gunakan status yang jelas seperti draf, aktif, diganti, dicabut, dan arsip. Jangan menjadikan semua file dalam folder sebagai sumber jawaban otomatis.
Siapa yang Menanggung Keputusan?
Knowledge owner menyetujui isi dan status. Tim IT mengelola ingestion serta indeks. Pemilik use case menentukan pertanyaan uji dan dampak jawaban salah. Security memastikan akses tetap benar. Service desk menerima laporan jawaban bermasalah dan mengarahkan eskalasi. Pembagian ini mencegah perubahan teknis menjadi keputusan kebijakan tanpa pemilik.
Pisahkan Sumber, Potongan Dokumen, dan Indeks
RAG mengambil informasi dari sumber untuk mendukung jawaban model. Dalam rancangan umum, dokumen diproses menjadi potongan atau chunk yang kemudian dapat dicari. Karena itu, satu dokumen sumber bisa menghasilkan banyak record indeks. Mengganti file sumber tanpa memperbarui seluruh record terkait dapat meninggalkan potongan versi lama.
Berikan setiap chunk hubungan ke document ID dan versi sumber. Simpan identitas proses ingestion serta timestamp. Bila strategi pemotongan berubah, jumlah dan identitas chunk bisa berubah pula. Proses pembaruan harus dapat menemukan record lama untuk diganti atau dicabut, bukan hanya menambahkan record baru.
Alur Pembaruan yang Dapat Dibuktikan
1. Review Perubahan dan Dampaknya
Pemilik dokumen memeriksa bagian yang berubah, tanggal efektif, dan pertanyaan yang terdampak. Tidak semua perubahan perlu perlakuan sama. Koreksi format berbeda risikonya dari perubahan otorisasi pengadaan. Untuk perubahan penting, siapkan jawaban rujukan sebelum merilis indeks baru.
2. Proses Versi Baru dalam Area Uji
Periksa ekstraksi teks, struktur tabel, metadata, dan hubungan lampiran. Pastikan judul serta nomor versi tidak hilang ketika dipotong. Jika OCR menghasilkan teks salah pada nilai atau pengecualian kebijakan, sumber tersebut perlu review sebelum masuk pencarian. File berhasil diproses belum membuktikan substansinya terbaca benar.
3. Uji Retrieval dan Jawaban
Jalankan pertanyaan yang harus berubah jawabannya dan pertanyaan yang seharusnya tetap sama. Periksa sumber yang diambil, versi, kecukupan konteks, serta cara sistem menyatakan ketidakpastian. Tambahkan pertanyaan dengan istilah lama agar pengguna yang belum mengetahui perubahan tetap diarahkan dengan benar.
4. Rilis dan Verifikasi di Jalur Pengguna
Setelah persetujuan, aktifkan sumber baru sesuai strategi implementasi. Periksa hasil melalui jalur yang benar-benar digunakan pengguna, termasuk filter entitas dan hak akses. Verifikasi tidak hanya dilakukan lewat konsol indeks karena aplikasi dapat menggunakan cache atau indeks berbeda.
Pencabutan Dokumen adalah Use Case Tersendiri
Dokumen dicabut dapat berarti tidak boleh dipakai untuk jawaban aktif, sementara arsip tetap disimpan untuk audit sesuai kebijakan retensi. Pemisahan itu harus eksplisit. Jangan menyamakan pencabutan sumber RAG dengan penghapusan seluruh arsip organisasi.
Tentukan hubungan seluruh chunk ke dokumen yang dicabut, jalur pencarian yang perlu dibatasi, serta cache jawaban yang terdampak. Jika sistem menyimpan jawaban sebelumnya, pertimbangkan pemberian label historis atau invalidasi sesuai kebutuhan. Jangan menjanjikan pencabutan instan tanpa menguji propagasi pada stack yang dipakai.
Dokumentasi Microsoft Azure AI Search menjelaskan pembaruan, penggabungan, dan penghapusan record indeks serta perubahan skema. Artikel ini tidak menganggap seluruh platform memiliki perilaku sama. Respons pembaruan tetap perlu diperiksa dan ketersediaan hasil pencarian diverifikasi; rancangan aplikasinya menentukan kapan pengguna melihat versi baru.
Contoh Ilustratif: Kebijakan Pengadaan Berubah
Misalkan batas approval pengadaan berubah untuk satu entitas. Dokumen baru berlaku mulai tanggal tertentu, sedangkan dokumen lama masih dibutuhkan untuk menelusuri transaksi historis. Knowledge owner menandai versi lama sebagai historis dan versi baru sebagai aktif untuk periode serta entitas yang sesuai.
Pertanyaan tentang transaksi baru harus mengambil kebijakan aktif. Pertanyaan “aturan saat transaksi tahun lalu” dapat memakai arsip bila hak akses mengizinkan dan jawaban menyebut periode secara jelas. Jika pertanyaan tidak menyebut konteks yang menentukan, sistem meminta klarifikasi. Skenario ini bukan implementasi atau portofolio Layana.ID.
Pemulihan: Jangan Mengembalikan Kebijakan yang Sudah Dicabut
Rollback teknis bisa berarti mengembalikan indeks atau konfigurasi sebelumnya, tetapi tidak boleh menghidupkan kembali kebijakan yang secara bisnis sudah dicabut. Rancang fallback aman: jawaban terbatas, pemberitahuan bahwa sumber sedang diperbarui, dan rujukan ke PIC. Sebuah indeks yang berjalan bukan alasan untuk menyajikan kebijakan salah.
Simpan bukti versi yang disetujui, hasil pengujian, waktu rilis, dan verifikasi. Jika rilis gagal sebagian, identifikasi sumber serta chunk yang belum berubah. Perbaiki pada ID yang sama dan pastikan proses tidak menciptakan dua versi aktif tanpa sengaja. Kebutuhan koneksi repository dapat dibahas melalui layanan integrasi sistem Layana.ID.
KPI Kesegaran dan Gate Penerimaan
Ukur waktu dari persetujuan dokumen hingga versi benar terlihat dalam jawaban, jumlah pertanyaan yang masih mengambil sumber dicabut, serta konsistensi metadata versi. Tambahkan proporsi pembaruan yang berhasil tanpa perbaikan manual dan waktu pemulihan ketika ingestion gagal. Target ditetapkan berdasarkan dampak use case, bukan angka generik.
Untuk pilot, pilih satu repository dan satu pemilik kebijakan. Uji perubahan kecil, penggantian dokumen, pencabutan tanpa pengganti, perubahan hak akses, tanggal efektif di masa depan, dan lampiran yang terlewat. Gate harus menolak rilis jika pertanyaan kritis masih memakai sumber lama atau pengguna yang tidak berhak dapat melihatnya.
Pertanyaan yang Sering Diajukan
Apakah Sinkronisasi Harian Selalu Cukup?
Tidak. Kebutuhan kesegaran bergantung pada dampak perubahan. Dokumen berisiko tinggi mungkin membutuhkan jalur pencabutan segera dan verifikasi, sedangkan sumber lain dapat mengikuti jadwal yang lebih longgar.
Apakah Citation Berarti Jawaban Sudah Benar?
Tidak. Citation membantu penelusuran, tetapi sumber dapat kedaluwarsa, tidak berlaku untuk entitas pengguna, atau tidak mendukung kesimpulan. Periksa kecocokan isi, versi, periode, dan konteks.
Petakan Lifecycle RAG bersama Layana.ID
Siapkan daftar repository, pemilik dokumen, status versi, use case, serta contoh pertanyaan yang berubah jawabannya. Diskusikan kebutuhan AI dan RAG bisnis melalui konsultasi Layana.ID agar pilot mencakup pembaruan dan pencabutan sejak awal.
Referensi
Microsoft Learn — Update or Rebuild an Index in Azure AI Search, untuk mekanisme pembaruan indeks pada platform tersebut. Lifecycle bisnis, skenario, dan KPI adalah rekomendasi editorial, bukan jaminan kapabilitas seluruh produk. Sumber diperiksa 14 Oktober 2026.