Aislamiento multi-tenant: el requisito que llega después de la demostración
Cada RAG multi-tenant eventualmente descubre lo mismo: filtrar resultados después de la recuperación no es aislamiento. El filtro debe restringir la búsqueda, no recortar su salida.
El patrón
La demo se ejecuta en los documentos de un cliente. Funciona. Luego, el segundo cliente se incorpora y alguien hace la pregunta que debería haberse hecho primero: ¿puede un usuario del inquilino A ver alguna vez un fragmento que pertenece al inquilino B?
La respuesta más común en ese momento es un filtro aplicado a los resultados recuperados antes de que lleguen a la solicitud. Parece correcto en las pruebas y está estructuralmente mal.
Por qué el filtrado posterior no es aislamiento
La búsqueda de vecinos más cercanos aproximados devuelve los k vectores más cercanos. Si luego elimina los que el usuario no puede ver, se queda con menos de k resultados, y los que eliminó fueron, por construcción, entre los más semanticamente similares. Bajo una consulta de baja permisión, el recuperador se degrada silenciosamente a su peor caso, y la calidad se convierte en una función de cuánto se permite que el usuario vea. Esa es una propiedad terrible para enviar.
Peor aún, el contenido eliminado aún cruzó un límite de confianza: se recuperó, se puntuó y se mantuvo en memoria dentro de un proceso que más tarde renderizará una solicitud. Un revisor de seguridad tiene derecho a objetar eso, incluso si el usuario nunca lo ve.
Qué hacer en su lugar
Restringir la búsqueda. Empujar la predicción de permisos a la capa de filtrado del almacén de vectores para que los fragmentos no permitidos nunca sean candidatos, y mantener k honesto: obtiene k resultados que el usuario realmente puede ver. Esta es precisamente la razón por la cual el filtrado de carga es una capacidad principal en lugar de un envoltorio en los almacenes construidos para este caso de uso.
Luego, decidir de dónde proviene la predicción. Resolver la lista de control de acceso de documentos completa de un usuario en cada consulta es costoso, por lo que la mayoría de los sistemas precargan un conjunto de grupos o etiquetas por usuario y filtran en función de eso. El compromiso es la obsolescencia: una revocación tiene efecto en la próxima actualización. Hacer que esa ventana sea explícita y lo suficientemente corta como para que pueda defenderla.
Las tres cosas que los revisores solicitan
Primero, aislamiento que se mantenga cuando el índice está corrupto o parcialmente reconstruido, fallar cerrado, no abierto. Segundo, un registro de auditoría de lo que se recuperó para cada respuesta, no solo lo que se generó. Tercero, cifrado por inquilino o un argumento documentado sobre por qué la separación lógica es suficiente. Tener esas tres respuestas listas y la revisión pasa de semanas a una reunión.
Qué hacer con esto
- Filtrar resultados recuperados no es aislamiento — restringir la búsqueda, no recortar su salida
- El filtrado posterior hace que la calidad de la respuesta dependa de cuánto se permite que el usuario vea
- Precomputar etiquetas de permiso por usuario y hacer que la ventana de obsolescencia sea explícita y defendible
- Prepararse para tres preguntas: comportamiento de cierre en caso de fallo, registro de auditoría de recuperación y cifrado por tenant