Deployment & Inference

Isolasi multi-tenant: kebutuhan yang datang setelah demo

Setiap RAG multi-tenant pada akhirnya menemukan hal yang sama: memfilter hasil setelah retrieval bukanlah isolasi. Filternya harus membatasi pencarian, bukan memangkas output-nya.

Polanya

Demo jalan di dokumen satu pelanggan. Berhasil. Lalu pelanggan kedua di-onboard, dan seseorang bertanya sesuatu yang seharusnya ditanyakan pertama kali: bisakah pengguna tenant A melihat chunk milik tenant B?

Jawaban paling umum saat itu adalah filter yang diterapkan ke hasil retrieval sebelum masuk ke prompt. Ia tampak benar di pengujian, tapi secara struktural salah.

Mengapa post-filtering bukan isolasi

Approximate nearest neighbour search mengembalikan k vektor terdekat. Kalau Anda lalu membuang yang tak boleh dilihat pengguna, yang tersisa kurang dari k — dan menurut konstruksi, yang Anda buang justru yang paling mirip secara semantik. Di bawah query berpermission rendah, retriever menurun senyap ke kasus terburuknya, dan kualitas jadi fungsi dari seberapa banyak yang boleh dilihat pengguna. Itu properti yang buruk untuk dikirim.

Lebih buruk lagi, konten yang dibuang tetap melintasi batas kepercayaan: ia diambil, diberi skor, dan disimpan di memori dalam proses yang nanti akan merender prompt. Reviewer keamanan berhak keberatan atas itu meski pengguna tak pernah melihatnya.

Apa yang harus dilakukan

Batasi pencariannya. Dorong predikat permission ke lapisan filter vector store sehingga chunk yang tak diizinkan tak pernah jadi kandidat, dan jaga k tetap jujur: Anda mendapat k hasil yang benar-benar boleh dilihat pengguna. Itulah sebabnya payload filtering adalah kapabilitas inti, bukan pembungkus, di store yang dibangun untuk kasus ini.

Lalu tentukan dari mana predikat berasal. Menyelesaikan ACL dokumen lengkap pengguna di setiap query itu mahal, jadi kebanyakan sistem menghitung dulu set grup atau label per pengguna lalu memfilter dengannya. Tradeoff-nya adalah kebasian: pencabutan hak baru berlaku di refresh berikutnya. Buat jendela itu eksplisit dan cukup pendek untuk bisa Anda pertanggungjawabkan.

Tiga hal yang ditanyakan reviewer

Pertama, isolasi yang tetap berlaku saat indeks rusak atau dibangun ulang sebagian — fail closed, bukan fail open. Kedua, jejak audit tentang apa yang di-retrieve untuk setiap jawaban, bukan hanya apa yang di-generate. Ketiga, enkripsi per tenant atau argumen terdokumentasi mengapa pemisahan logis sudah cukup. Siapkan tiga jawaban itu dan review turun dari berminggu-minggu jadi satu rapat.

Yang bisa Anda lakukan sekarang

  • Memfilter hasil retrieval bukan isolasi — batasi pencariannya, jangan pangkas output-nya
  • Post-filtering membuat kualitas jawaban bergantung pada sedikitnya apa yang boleh dilihat pengguna
  • Hitung dulu label permission per pengguna dan buat jendela kebasiannya eksplisit serta dapat dibela
  • Siapkan tiga jawaban: perilaku fail-closed, jejak audit retrieval, enkripsi per tenant