Diseñar una solución de inferencia RAG multiinquilino segura
Retrieval-Augmented Generation (RAG) es un patrón para construir aplicaciones que utilizan modelos fundacionales para razonar sobre información propietaria u otros datos que no están disponibles públicamente en Internet. Por lo general, una aplicación cliente llama a una capa de orquestación que captura información relevante de un almacén de datos, como una base de datos vectorial. La capa de orquestación pasa esos datos como parte del contexto, como datos de referencia, al modelo fundamental.
Varios clientes usan una solución multiinquilino. Cada cliente o inquilino consta de varios usuarios de la misma organización, empresa o grupo. En escenarios de múltiples inquilinos, debe asegurarse de que los inquilinos, o los individuos dentro de estos, solo puedan incorporar datos básicos a los que están autorizados para acceder.
Hay preocupaciones relacionadas con varios inquilinos más allá de garantizar que los usuarios solo accedan a la información a la cual están autorizados. Sin embargo, este artículo se centra en ese aspecto de la multitenencia. Este artículo comienza con una introducción a las arquitecturas RAG de un solo inquilino. En él se analizan los retos que puede encontrar en los multiinquilinos con RAG y algunos enfoques comunes a adoptar. También se exponen consideraciones y recomendaciones para mejorar la seguridad.
Nota
En este artículo se describen varias características específicas del servicio Azure OpenAI, como la característica Azure OpenAI en los datos. Sin embargo, puede aplicar la mayoría de los principios descritos en este artículo a los modelos de inteligencia artificial fundamentales en cualquier plataforma.
Arquitectura RAG de inquilino único con un orquestador
Flujo de trabajo
En esta arquitectura RAG de inquilino único, un orquestador captura los datos de inquilino propietario pertinentes de los almacenes de datos y los proporciona como datos de base al modelo básico. En los pasos siguientes se describe un flujo de trabajo de alto nivel.
- Un usuario emite una solicitud a la aplicación web inteligente.
- Un proveedor de identidades autentica al solicitante.
- La aplicación inteligente llama a la API del orquestador con la consulta del usuario y el token de autorización del usuario.
- La lógica de orquestación extrae la consulta del usuario de la solicitud y llama al almacén de datos adecuado para capturar los datos de base pertinentes para la consulta. Los datos de conexión a tierra se añaden a la solicitud que se envía al modelo fundacional, como un modelo expuesto en Azure OpenAI, en el siguiente paso.
- La lógica de orquestación se conecta a la API de inferencia del modelo fundamental y envía el mensaje que incluye los datos de base recuperados. Los resultados se devuelven a la aplicación inteligente.
Para obtener más información, consulte Diseño y desarrollo de una solución RAG.
Arquitectura RAG de un solo inquilino con acceso directo a datos
Esta variante de la arquitectura RAG de inquilino único usa la característica On Your Data de Azure OpenAI para integrarse directamente con almacenes de datos como Azure AI Search. En esta arquitectura, no tiene su propio orquestador o el orquestador tiene menos responsabilidades. La API de Azure OpenAI llama al almacén de datos para obtener los datos de referencia y pasa esos datos al modelo de lenguaje. Este método proporciona menos control sobre qué datos de base se van a capturar y la relevancia de esos datos.
Nota
Microsoft administra Azure OpenAI. Se integra con el almacén de datos, pero el propio modelo no se integra con el almacén de datos. El modelo recibe los datos de conexión a tierra del mismo modo que cuando un orquestador obtiene los datos.
Flujo de trabajo
En esta arquitectura RAG, el servicio que proporciona el modelo fundamental captura los datos de inquilino propietario adecuados de los almacenes de datos y usa esos datos como datos de base al modelo fundamental. En los pasos siguientes se describe un flujo de trabajo de alto nivel. Los pasos en cursiva son idénticos a los de la arquitectura RAG de inquilino único anterior que tiene un flujo de trabajo de orquestador.
- Un usuario emite una solicitud a la aplicación web inteligente.
- Un proveedor de identidades autentica al solicitante.
- La aplicación inteligente llama a Azure OpenAI con la consulta del usuario.
- Azure OpenAI se conecta a los almacenes de datos compatibles, como AI Search y Azure Blob Storage, para obtener los datos de base. Los datos de referencia se utilizan como parte del contexto cuando Azure OpenAI llama al modelo de lenguaje de OpenAI. Los resultados se devuelven a la aplicación inteligente.
Si desea usar esta arquitectura en una solución multiinquilino, el servicio que accede directamente a los datos de puesta a tierra, como Azure OpenAI, debe admitir la lógica multiinquilino que requiere la solución.
Multitenancy en la arquitectura RAG
En las soluciones multiinquilino, los datos de inquilino pueden existir en un almacén específico del inquilino o coexistir con otros inquilinos en un almacén multiinquilino. Los datos también pueden estar en un almacén que se comparte entre inquilinos. Solo se deben usar los datos a los que está autorizado el usuario para acceder como datos de base. Los usuarios deben ver solo los datos comunes o compartidos por todos los inquilinos, o datos filtrados de su inquilino, para garantizar que solo vean los datos a los que tienen autorizado acceder.
Flujo de trabajo
En los pasos siguientes se describe un flujo de trabajo de alto nivel. Los pasos en cursiva son idénticos a los de la arquitectura RAG de inquilino único con un flujo de trabajo de orquestador.
- Un usuario emite una solicitud a la aplicación web inteligente.
- Un proveedor de identidades autentica al solicitante.
- La aplicación inteligente llama a la API de orquestador con la consulta del usuario y el token de autorización para el usuario.
- La lógica de orquestación extrae la consulta del usuario de la solicitud y llama a los almacenes de datos adecuados para capturar los datos de base pertinentes y autorizados por el inquilino para la consulta. Los datos de base se añaden a la solicitud que se envía a Azure OpenAI en el siguiente paso. Se incluyen algunos o todos los pasos siguientes:
- La lógica de orquestación captura los datos de base de la instancia de almacén de datos específica del inquilino adecuada y, posiblemente, aplica reglas de filtrado de seguridad para devolver solo los datos a los que el usuario está autorizado para acceder.
- La lógica de orquestación captura los datos de base del inquilino adecuado del almacén de datos multiinquilino y, posiblemente, aplica reglas de filtrado de seguridad para devolver solo los datos a los que el usuario está autorizado para acceder.
- La lógica de orquestación captura datos de un almacén de datos que se comparte entre inquilinos.
- La lógica de orquestación se conecta a la API de inferencia del modelo fundacional y envía la solicitud que incluye los datos de conexión a tierra recuperados. Los resultados se devuelven a la aplicación inteligente.
Consideraciones de diseño para datos multicliente en RAG
Considere las siguientes opciones cuando diseñe su solución de inferencia RAG multiinquilino.
Elección de un modelo de aislamiento de almacén
Los dos enfoques arquitectónicos principales para el almacenamiento y los datos en escenarios multiusuario son los almacenes por usuario y los almacenes multiusuario. Estos enfoques se agregan a los almacenes que contienen datos compartidos entre inquilinos. La solución multiinquilino puede usar una combinación de estos enfoques.
Almacenes por inquilino
En almacenes por inquilino, cada inquilino tiene su propio almacén. Las ventajas de este enfoque incluyen el aislamiento de datos y rendimiento. Los datos de cada inquilino se encapsulan en su propio almacén. En la mayoría de los servicios de datos, los almacenes aislados no son susceptibles al problema de los vecinos ruidosos de otros inquilinos. Este enfoque también simplifica la asignación de costos porque todo el costo de una implementación de almacén se puede atribuir a un único inquilino.
Este enfoque podría presentar desafíos como un aumento de la administración y la sobrecarga operativa y mayores costos. No debe usar este enfoque si tiene un gran número de inquilinos pequeños, como en escenarios de negocio a consumidor. Este enfoque también puede alcanzar o superar límites de servicio.
En el contexto de este escenario de inteligencia artificial, un almacén por inquilino significa que los datos de base necesarios para incorporar relevancia al contexto proceden de un almacén de datos existente o nuevo que solo contiene datos de base para el inquilino. En esta topología, la instancia de base de datos es el discriminador que se usa para cada inquilino.
Almacenes multiinquilinos
En almacenes multiinquilino, los datos de varios inquilinos coexisten en el mismo almacén. Las ventajas de este enfoque incluyen la posibilidad de optimización de costos, la capacidad de controlar un número mayor de inquilinos que el modelo de almacén por inquilino y una menor sobrecarga de administración debido al menor número de instancias de almacén.
Los retos de utilizar almacenes compartidos incluyen la necesidad de aislar y administrar los datos, el potencial del antipatrón del vecino ruidoso y una asignación de costes más compleja a los inquilinos. El aislamiento de datos es la preocupación más importante al usar este enfoque. Debe implementar enfoques seguros para ayudar a garantizar que los inquilinos solo puedan acceder a sus datos. La administración de datos también puede ser difícil si los inquilinos tienen diferentes ciclos de vida de datos que requieren operaciones como la creación de índices según distintas programaciones.
Algunas plataformas tienen características que puede usar al implementar el aislamiento de datos de inquilino en almacenes compartidos. Por ejemplo, Azure Cosmos DB tiene compatibilidad nativa con particiones de datos y particionamiento. Es habitual usar un identificador de inquilino como clave de partición para proporcionar cierto aislamiento entre inquilinos. Azure SQL y Azure Database for PostgreSQL - Servidor Flexible admiten la seguridad de nivel de fila. Sin embargo, estas características no suelen usarse en soluciones multiinquilino porque tiene que diseñar la solución en torno a estas características si planea usarlas en el almacén multiinquilino.
En el contexto de este escenario de inteligencia artificial, los datos fundamentales de todos los inquilinos se combinan en el mismo almacén de datos. Por lo tanto, la consulta a ese almacén de datos debe incluir un discriminador de inquilinos para ayudar a garantizar que las respuestas estén restringidas para devolver solo los datos pertinentes en el contexto del inquilino.
Almacenes compartidos
Las soluciones multiinquilino suelen compartir datos entre inquilinos. En una solución multiinquilino de ejemplo para el dominio sanitario, una base de datos podría almacenar información médica general o información que no es específica del inquilino.
En el contexto de este escenario de inteligencia artificial, el almacén de datos de base es generalmente accesible y no necesita filtrarse según inquilinos específicos porque los datos son relevantes y están autorizados para todos los inquilinos del sistema.
Identidad
La identidad es un aspecto clave de las soluciones multiinquilino, incluidas las soluciones RAG multiinquilino. La aplicación inteligente debe integrarse con un proveedor de identidades para autenticar la identidad del usuario. La solución RAG multiinquilino necesita un directorio de identidad que almacena identidades autoritativas o referencias a identidades. Esta identidad debe fluir a través de la cadena de solicitudes y permitir que los servicios de bajada, como el orquestador o el propio almacén de datos, identifiquen al usuario.
También necesita una forma de mapear un usuario a un inquilino para poder conceder acceso a los datos de ese inquilino.
Defina sus requisitos de inquilino y autorización
Cuando construya una solución RAG multiinquilino, debe definir qué es un inquilino para su solución. Los dos modelos comunes entre los que elegir son los modelos de negocio a negocio y de negocio a consumidor. El modelo que elija le ayuda a determinar qué otros factores debe tener en cuenta al compilar la solución. Comprender el número de inquilinos es fundamental para elegir el modelo de almacén de datos. Un gran número de inquilinos puede requerir un modelo que tenga varios inquilinos para cada almacén. Un número menor de inquilinos podría permitir un modelo de almacén por inquilino. La cantidad de datos de cada inquilino también es importante. Los inquilinos que tienen grandes cantidades de datos podrían impedirle utilizar almacenes multiinquilino debido a las limitaciones de tamaño del almacén de datos.
Si tiene previsto expandir una carga de trabajo existente para admitir este escenario de IA, es posible que ya haya tomado esta decisión. Por lo general, puede usar la topología de almacenamiento de datos existente para los datos de base si ese almacén de datos puede proporcionar suficiente relevancia y cumplir cualquier otro requisito no funcional. Sin embargo, si planea introducir nuevos componentes, como un almacén dedicado a los vectores de búsqueda como almacén dedicado a la puesta a tierra, aún deberá tomar esta decisión. Considere factores como su estrategia actual de sello de implementación, el impacto en el plano de control de su aplicación y cualquier diferencia en el ciclo de vida de los datos por inquilino, como situaciones de pago por rendimiento.
Después de definir qué es un inquilino para la solución, debe definir los requisitos de autorización para los datos. Los inquilinos solo acceden a los datos de su inquilino, pero los requisitos de autorización pueden ser más granulares. Por ejemplo, en una solución sanitaria, es posible que tenga reglas como:
- Un paciente solo puede acceder a sus propios datos de pacientes.
- Un profesional sanitario puede acceder a los datos de sus pacientes.
- Un usuario financiero solo puede acceder a los datos relacionados con las finanzas.
- Un auditor clínico puede ver los datos de todos los pacientes.
- Todos los usuarios pueden acceder a conocimientos médicos básicos en un almacén de datos compartido.
En una aplicación RAG basada en documentos, es posible que desee restringir el acceso de los usuarios a los documentos en función de un esquema de etiquetado o niveles de confidencialidad asignados a los documentos.
Después de tener una definición de lo que es un inquilino y tener un conocimiento claro de las reglas de autorización, use esa información como requisitos para la solución del almacén de datos.
Filtrado de datos
Restringir el acceso solo a los datos a los que los usuarios están autorizados a acceder se conoce como filtrado o recorte de seguridad. En un escenario RAG multiinquilino, un usuario podría estar asignado a un almacén específico del inquilino. Esto no significa que el usuario pueda acceder a todos los datos de ese almacén. Definir los requisitos de inquilino y autorización describe la importancia de definir los requisitos de autorización para los datos. Debe usar estas reglas de autorización como base para el filtrado.
Puede usar funcionalidades de plataforma de datos como la seguridad de nivel de fila para implementar el filtrado. O bien, es posible que necesite lógica, datos o metadatos personalizados. Estas características de plataforma no se suelen usar en soluciones multiinquilino porque necesita diseñar el sistema en torno a estas características.
Encapsular la lógica de datos multiinquilino
Se recomienda tener una API delante del mecanismo de almacenamiento que use. La API actúa como un guardián que ayuda a garantizar que los usuarios solo obtengan acceso a la información a la que están autorizados para acceder.
El acceso de los usuarios a los datos puede estar limitado por:
- El inquilino del usuario.
- Características de la plataforma.
- Reglas de filtrado o restricción de seguridad personalizadas.
La capa de API debe:
- Dirija la consulta a un almacén específico del inquilino en un modelo de un almacén por cada inquilino.
- Seleccionar solo datos del inquilino del usuario en almacenes multiinquilino.
- Utilice la identidad adecuada para que un usuario pueda admitir la lógica de autorización de la plataforma.
- Aplicar una lógica de recorte de seguridad personalizada.
- Almacene los registros de acceso de la información de puesta a tierra con fines de auditoría.
El código que necesita acceder a los datos de los arrendatarios no debería poder consultar directamente los sistemas de back-end. Todas las solicitudes de datos deben fluir a través de la capa de API. Esta capa de API proporciona un único punto de gobernanza o seguridad sobre los datos del inquilino. Este enfoque impide que la lógica de autorización de acceso a datos de inquilino y usuario llegue a otras áreas de la aplicación. Esta lógica se encapsula en la capa de API. Esta encapsulación facilita la validación y prueba de la solución.
Resumen
Cuando diseñe una solución de inferencia RAG multiinquilino, debe tener en cuenta cómo diseñar la solución de datos de base para sus inquilinos. Comprenda el número de inquilinos y la cantidad de datos por inquilino que almacena. Esta información le ayuda a diseñar la solución de arrendamiento de datos. Se recomienda implementar una capa de API que encapsula la lógica de acceso a datos, incluida la lógica multiinquilino y la lógica de filtrado.
Colaboradores
Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.
Autores principales:
- John Downs | Ingeniero principal de software
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI
Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.