La generación aumentada de recuperación (RAG) es un patrón para crear aplicaciones en las que se usan modelos fundamentales para razonar sobre información propietaria u otra información que no está disponible 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 puesta en tierra al modelo fundamental.
Varios clientes usan una solución multiinquilino, donde cada cliente (inquilino) consta de varios usuarios de la misma organización, empresa o grupo. En escenarios multiinquilino, debe asegurarse de que los inquilinos o los usuarios de los inquilinos solo pueden incorporar datos de base que están autorizados para ver.
Aunque hay preocupaciones multiinquilino más allá de garantizar que los usuarios solo accedan a la información que se supone que ven, este artículo se centra en ese aspecto de multiinquilino. El artículo comienza con una visión general de las arquitecturas RAG de inquilino único, analiza los desafíos relacionados con la multiinquilino con RAG y algunos enfoques comunes que se deben seguir y concluye con consideraciones y recomendaciones de multiinquilino seguras.
Nota:
En este artículo se describen algunas características específicas de Azure OpenAI, como Azure OpenAI en los datos. Dicho esto, la mayoría de los principios descritos en este documento se aplican a la mayoría de los modelos de inteligencia artificial fundamentales, independientemente de su plataforma host.
Arquitectura RAG de un solo inquilino con orquestador
Figura 1. Arquitectura RAG de un solo inquilino
Flujo de trabajo
En esta arquitectura RAG de inquilino único, un orquestador tiene la responsabilidad de capturar los datos de inquilino propietario pertinentes de los almacenes de datos y proporcionarlos como datos de base al modelo básico. A continuación se muestra 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 de orquestador con la consulta de 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 al almacén de datos adecuado para capturar los datos de base pertinentes para la consulta. Los datos de base se agregan al símbolo del sistema que se envía al modelo fundamental, por ejemplo, un modelo expuesto en Azure OpenAI, en el paso siguiente.
- La lógica de orquestación se conecta a la API de inferencia del modelo fundamental y envía el símbolo del sistema que incluye los datos de puesta a tierra recuperados. Los resultados se devuelven a la aplicación inteligente.
Para obtener más información sobre los detalles de RAG, consulte Diseño y desarrollo de una solución RAG.
Arquitectura RAG de inquilino único con acceso directo a datos
Una variante de la arquitectura RAG de inquilino único aprovecha la capacidad del servicio Azure OpenAI para integrarse directamente con almacenes de datos como Azure Search. En esta arquitectura, no tiene su propio orquestador o el orquestador tiene menos responsabilidades. La API de Azure OpenAI tiene la responsabilidad de llamar al almacén de datos para capturar los datos de base y pasar esos datos al modelo de lenguaje. A su vez, tiene menos control sobre qué datos de base capturar y la relevancia de esos datos.
Nota:
El servicio Azure OpenAI, administrado por Microsoft, se integra con el almacén de datos. El propio modelo no se integra con los almacenes de datos. El modelo recibe datos de puesta a tierra de la misma manera que si un orquestador captura los datos.
Ilustración 2. Arquitectura RAG de un solo inquilino con acceso directo a datos desde el servicio Azure OpenAI
Flujo de trabajo
En esta arquitectura RAG, el servicio que proporciona el modelo fundamental tiene la responsabilidad de capturar los datos de inquilino propietario adecuados de los almacenes de datos y usar esos datos como datos de base al modelo básico. A continuación se muestra un flujo de trabajo de alto nivel (los pasos en cursiva son idénticos a la arquitectura RAG de inquilino único con flujo de trabajo de orquestador):
- Un usuario emite una solicitud a la aplicación web inteligente.
- Un proveedor de identidades autentica al solicitante.
- A continuación, la aplicación inteligente llama al servicio Azure OpenAI con la consulta de usuario.
- El servicio Azure OpenAI se conecta a almacenes de datos admitidos, como Azure AI Search y Azure Blob Storage para capturar los datos de conexión a tierra. Los datos de conexión a tierra se usan como parte del contexto cuando el servicio Azure OpenAI llama al modelo de lenguaje OpenAI. Los resultados se devuelven a la aplicación inteligente.
Para tener en cuenta esta arquitectura en una solución multiinquilino, el servicio, como Azure OpenAI, que accede directamente a los datos de base debe admitir la lógica multiinquilino requerida por la solución.
Arquitectura multiinquilino en 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. También puede haber datos en un almacén que se comparta entre inquilinos. Solo los datos que el usuario está autorizado para ver deben usarse como datos de base. Los usuarios solo deben ver datos comunes (todos los inquilinos) o datos de su inquilino con reglas de filtrado aplicadas para asegurarse de que solo ven los datos que están autorizados para ver.
Figura 3: Arquitectura RAG: con varios inquilinos de almacén de datos
Flujo de trabajo
Este flujo de trabajo es el mismo que en arquitectura RAG de inquilino único con orquestador , excepto el paso 4.
- 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 de 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 agregan a la solicitud que se envía a Azure OpenAI en el paso siguiente. Algunos o todos los pasos siguientes están implicados:
- La lógica de orquestación captura los datos en tierra de la instancia de almacén de datos específica del inquilino adecuada, lo que podría aplicar 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, lo que podría aplicar reglas de filtrado de seguridad para devolver solo los datos a los que está autorizado el usuario 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 fundamental y envía el símbolo del sistema que incluye los datos de puesta a tierra recuperados. Los resultados se devuelven a la aplicación inteligente.
Consideraciones de diseño para datos multiinquilino en RAG
Elección de modelos de aislamiento de almacén
Hay dos enfoques arquitectónicos principales para el almacenamiento y los datos en escenarios multiinquilino: almacenes por inquilino y almacenes multiinquilino. Estos enfoques se agregan a los almacenes que contienen datos que se comparten entre inquilinos. Esta sección toca cada enfoque. Debe tenerse en cuenta que la solución multiinquilino puede usar una combinación de estos enfoques.
Tienda por inquilino
En el almacén por inquilino, como sugiere el nombre, 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 vecino ruidoso de otros inquilinos. Este enfoque también simplifica la asignación de costos, ya que todo el costo de una implementación de almacén se puede atribuir a un único inquilino.
Los desafíos de este enfoque pueden incluir una mayor sobrecarga de administración y operación y un mayor costo. Este enfoque no se debe tener en cuenta cuando hay un gran número de inquilinos pequeños, como escenarios de negocio a consumidor. Este enfoque también podría enfrentarse a las limitaciones del servicio.
En el contexto de este escenario de inteligencia artificial, un almacén por inquilino significaría que los datos de base necesarios para poner relevancia en el contexto provendrían 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 usado por inquilino.
Almacenes multiinquilino
En almacenes multiinquilino, varios datos de 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 desafíos del uso de almacenes compartidos incluyen la necesidad de garantizar el aislamiento de datos, la administración de datos, la posibilidad de antipatrón vecino ruidoso y la dificultad de asignar costos a los inquilinos. Garantizar el aislamiento de datos es la preocupación más importante con este enfoque. Tiene la responsabilidad de implementar el enfoque de seguridad para asegurarse de que los inquilinos solo pueden acceder a sus datos. La administración de datos también puede ser un desafío si los inquilinos tienen diferentes ciclos de vida de datos que pueden requerir operaciones como la creación de índices en diferentes programaciones.
Algunas plataformas tienen características que puede aprovechar al implementar el aislamiento de datos de inquilino en almacenes compartidos. Por ejemplo, Azure Cosmos DB tiene compatibilidad nativa con la creación de particiones y particionamiento, y es habitual usar un identificador de inquilino como clave de partición para proporcionar cierto nivel de aislamiento entre inquilinos. Azure SQL y Postgres Flex admiten la seguridad de nivel de fila, aunque esta característica no se usa normalmente en soluciones multiinquilino, ya que 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, esto significaría que los datos de puesta en tierra de todos los inquilinos se encuentran en el mismo almacén de datos, de tal manera que la consulta a ese almacén de datos debe contener un discriminador de inquilinos para asegurarse de que las respuestas están restringidas a devolver solo los datos pertinentes dentro del contexto del inquilino.
Almacenes compartidos
Las soluciones multiinquilino suelen tener datos compartidos entre inquilinos. En una solución multiinquilino de ejemplo para el dominio sanitario, puede haber una base de datos que almacene información médica general o información que no sea específica del inquilino.
En el contexto de este escenario de inteligencia artificial, esto sería un almacén de datos basado generalmente accesible que no necesita filtrar específicamente en función de ningún inquilino, ya que los datos son relevantes y autorizados para todos los inquilinos del sistema.
Identidad
La identidad es un aspecto clave para las soluciones multiinquilino, incluido RAG multiinquilino seguro. La aplicación inteligente debe integrarse con un proveedor de identidades (IdP) para autenticar la identidad del usuario. La solución RAG multiinquilino necesita un directorio de identidad donde se almacenan identidades autoritativas o referencias a identidades. Esta identidad debe fluir a través de la cadena de solicitudes, lo que permite que los servicios de bajada, como el orquestador o incluso el propio almacén de datos identifiquen al usuario.
También necesita un medio para asignar un usuario a un inquilino para que pueda conceder acceso a esos datos de inquilino.
Definición de los requisitos de inquilino y autorización
Al compilar una solución RAG multiinquilino, debe definir qué es un inquilino para la solución. Los dos modelos comunes entre los que elegir son negocio a negocio (B2B) y negocio a consumidor (B2C). Esta determinación le ayuda a informar sobre las áreas que debe tener en cuenta al diseñar la solución. Comprender el número de inquilinos es fundamental para decidir el modelo de almacén de datos. Un gran número de inquilinos puede requerir un modelo con varios inquilinos por tienda, mientras que un número menor podría permitir un almacén por modelo de inquilino. La cantidad de datos por inquilino también es importante. Si los inquilinos tienen grandes cantidades de datos que pueden impedir que use almacenes multiinquilino debido a limitaciones de tamaño en el almacén de datos.
En las cargas de trabajo existentes que se están expandiendo para admitir este escenario de IA, es posible que ya haya tomado esta opción. Por lo general, podrá 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 va a introducir nuevos componentes, como un almacén de búsqueda vectorial dedicado como un almacén de puesta a tierra dedicado, deberá tomar esta decisión, teniendo en cuenta factores como la estrategia de stamp de implementación actual, el impacto del plano de control de la aplicación y las diferencias de ciclo de vida de los datos por inquilino (como situaciones de pago por rendimiento).
Una vez que defina lo que es un inquilino para la solución, debe definir los requisitos de autorización para los datos. Aunque los inquilinos solo tendrán acceso a los datos de su inquilino, los requisitos de autorización pueden ser más granulares. Por ejemplo, en una solución sanitaria podría tener 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 los conocimientos médicos básicos en un almacén de datos compartido
En una aplicación RAG basada en documentos, es posible que quiera restringir el acceso de los usuarios a los documentos en función de un esquema de etiquetado o niveles de confidencialidad establecidos en los documentos.
Una vez que tenga una definición de lo que es un inquilino y tenga un conocimiento claro de las reglas de autorización, use esa información como requisitos para la solución del almacén de datos.
Filtros
El filtrado, también conocido como recorte de seguridad, hace referencia a exponer solo los datos a los usuarios que están autorizados a ver. En un escenario RAG multiinquilino, un usuario puede asignarse a un almacén específico del inquilino. Esto no significa que el usuario pueda acceder a todos los datos de ese almacén. En Definición de los requisitos de inquilino y autorización, hemos analizado la importancia de definir los requisitos de autorización de los datos. Estas reglas de autorización se deben usar como base para el filtrado.
El filtrado se puede realizar mediante funcionalidades de plataforma de datos como la seguridad de nivel de fila o puede requerir lógica personalizada, datos o metadatos. De nuevo, estas características de plataforma no se usan normalmente en soluciones multiinquilino debido a la necesidad de 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, lo que exige que los usuarios solo obtengan acceso a la información a la que deben acceder.
Figura 4. Arquitectura rag multiinquilino con una API que encapsula la lógica de acceso a datos multiinquilino
Como se indicó anteriormente en este artículo, el acceso de usuario a los datos puede estar limitado por:
- Inquilino del usuario
- Características de la plataforma
- Reglas de filtrado y recorte de seguridad personalizadas.
Esta capa debe tener las siguientes responsabilidades:
- Enrutar la consulta a un almacén específico del inquilino en un modelo de almacén por inquilino
- Seleccionar solo los datos del inquilino del usuario en almacenes multiinquilino
- Usar la identidad adecuada para que un usuario admita la lógica de autorización habilitada para la plataforma
- Aplicación de la lógica de recorte de seguridad personalizada
- Almacenar registros de acceso a la información de puesta a tierra con fines de auditoría
El código que necesita acceder a los datos de inquilino no debe poder consultar directamente los almacenes de back-end. Todas las solicitudes de datos deben fluir a través de esta capa de API. Esta capa de API proporciona un único punto de gobernanza o capa de seguridad sobre los datos del inquilino. Este enfoque mantiene la lógica de autorización de acceso a datos de usuario y de inquilino de sangrado en diferentes á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
Al diseñar una solución de inferencia RAG multiinquilino, debe tener en cuenta cómo diseñar la solución de datos de base para los inquilinos. Obtenga información sobre 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 de filtrado y multiinquilino.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
- John Downs | Ingeniero principal de software
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI