Diseño de RAG multiinquilino con Milvus: prácticas recomendadas para bases de conocimiento empresariales escalables
Introducción
Durante los últimos años, Retrieval-Augmented Generation (RAG) ha surgido como una solución confiable para que las grandes organizaciones mejoren sus aplicaciones impulsadas por LLM, especialmente aquellas con usuarios diversos. A medida que dichas aplicaciones crecen, implementar un marco de multi-tenencia se vuelve esencial. La multi-tenencia proporciona acceso seguro y aislado a los datos para diferentes grupos de usuarios, garantizando la confianza del usuario, cumpliendo con los estándares regulatorios y mejorando la eficiencia operativa.
Milvus es una base de datos vectorial de código abierto creada para manejar datos vectoriales de alta dimensión. Es un componente de infraestructura indispensable de RAG, que almacena y recupera información contextual para los LLM desde fuentes externas. Milvus ofrece estrategias flexibles de multi-tenencia para diversas necesidades, incluida la multi-tenencia a nivel de base de datos, a nivel de colección y a nivel de partición.
En esta publicación, cubriremos:
Qué es la multi-tenencia y por qué importa
Estrategias de multi-tenencia en Milvus
Ejemplo: Estrategia de multi-tenencia para una base de conocimientos empresarial impulsada por RAG
Qué es la multi-tenencia y por qué importa
La multi-tenencia es una arquitectura en la que múltiples clientes o equipos, conocidos como "inquilinos," comparten una única instancia de una aplicación o sistema. Los datos y configuraciones de cada inquilino están lógicamente aislados, garantizando privacidad y seguridad, mientras que todos los inquilinos comparten la misma infraestructura subyacente.
Imagina una plataforma SaaS que proporciona soluciones basadas en conocimiento a múltiples empresas. Cada empresa es un inquilino.
El inquilino A es una organización de atención médica que almacena preguntas frecuentes dirigidas a pacientes y documentos de cumplimiento.
El inquilino B es una empresa tecnológica que gestiona flujos de trabajo internos de resolución de problemas de TI.
El inquilino C es un negocio minorista con preguntas frecuentes de atención al cliente para devoluciones de productos.
Cada inquilino opera en un entorno completamente aislado, asegurando que ningún dato del inquilino A se filtre al sistema del inquilino B o viceversa. Además, la asignación de recursos, el rendimiento de las consultas y las decisiones de escalado son específicos de cada inquilino, garantizando un alto rendimiento independientemente de los picos de carga de trabajo en un inquilino.
La multi-tenencia también funciona para sistemas que atienden a diferentes equipos dentro de la misma organización. Imagina una gran empresa que utiliza una base de conocimientos impulsada por RAG para atender a sus departamentos internos, como RR. HH., Legal y Marketing. Cada departamento es un inquilino con datos y recursos aislados en esta configuración.
La multi-tenencia ofrece beneficios significativos, incluida la eficiencia de costos, escalabilidad y sólida seguridad de los datos. Al compartir una única infraestructura, los proveedores de servicios pueden reducir los costos generales y garantizar un consumo de recursos más efectivo. Este enfoque también escala sin esfuerzo: incorporar nuevos inquilinos requiere muchos menos recursos que crear instancias separadas para cada uno, como ocurre con los modelos de tenencia única. Es importante destacar que la multi-tenencia mantiene una sólida seguridad de los datos al garantizar un aislamiento estricto de los datos para cada inquilino, con controles de acceso y cifrado que protegen la información sensible contra accesos no autorizados. Además, las actualizaciones, parches y nuevas funciones pueden implementarse en todos los inquilinos simultáneamente, simplificando el mantenimiento del sistema y reduciendo la carga para los administradores, al tiempo que garantiza que los estándares de seguridad y cumplimiento se mantengan de manera consistente.
Estrategias de multi-tenencia en Milvus
Para entender cómo Milvus admite la multi-tenencia, es importante observar primero cómo organiza los datos de los usuarios.
Cómo Milvus organiza los datos de los usuarios
Milvus estructura los datos en tres capas, pasando de lo general a lo granular: Base de datos, Colección y Partición/Clave de partición.
Figura: Cómo Milvus organiza los datos de usuario .png
Figura: Cómo Milvus organiza los datos de usuario
Base de datos: Actúa como un contenedor lógico, similar a una base de datos en los sistemas relacionales tradicionales.
Colección: Comparable a una tabla dentro de una base de datos, una colección organiza los datos en grupos manejables.
Partición/Clave de partición: Dentro de una colección, los datos pueden segmentarse aún más mediante Particiones. Al usar una Clave de partición, los datos con la misma clave se agrupan juntos. Por ejemplo, si usa un ID de usuario como Clave de partición, todos los datos de un usuario específico se almacenarán en el mismo segmento lógico. Esto facilita la recuperación de datos vinculados a usuarios individuales.
A medida que se avanza de Base de datos a Colección y a Clave de partición, la granularidad de la organización de los datos se vuelve progresivamente más fina.
Para garantizar una seguridad de datos más sólida y un control de acceso adecuado, Milvus también proporciona un sólido Control de acceso basado en roles (RBAC), que permite a los administradores definir permisos específicos para cada usuario. Solo los usuarios autorizados pueden acceder a ciertos datos.
Milvus admite múltiples estrategias para implementar la multi-tenencia, ofreciendo flexibilidad según las necesidades de su aplicación: multi-tenencia a nivel de base de datos, a nivel de colección y a nivel de partición.
Multi-tenencia a nivel de base de datos
Con el enfoque de multi-tenencia a nivel de base de datos, a cada inquilino se le asigna su propia base de datos dentro del mismo clúster de Milvus. Esta estrategia proporciona un fuerte aislamiento de datos y garantiza un rendimiento de búsqueda óptimo. Sin embargo, puede dar lugar a una utilización ineficiente de los recursos si ciertos inquilinos permanecen inactivos.
Multi-tenencia a nivel de colección
Aquí, en la multi-tenencia a nivel de colección, podemos organizar los datos de los inquilinos de dos maneras.
Una colección para todos los inquilinos: Todos los inquilinos comparten una única colección, con campos específicos del inquilino utilizados para el filtrado. Aunque es sencillo de implementar, este enfoque puede encontrar cuellos de botella de rendimiento a medida que aumenta el número de inquilinos.
Una colección por inquilino: Cada inquilino puede tener una colección dedicada, lo que mejora el aislamiento y el rendimiento, pero requiere más recursos. Esta configuración puede enfrentar limitaciones de escalabilidad si el número de inquilinos supera la capacidad de colecciones de Milvus.
Multi-tenencia a nivel de partición
La multi-tenencia a nivel de partición se centra en organizar a los inquilinos dentro de una única colección. Aquí también tenemos dos maneras de organizar los datos de los inquilinos.
Una partición por inquilino: Los inquilinos comparten una colección, pero sus datos se almacenan en particiones separadas. Podemos aislar los datos asignando a cada inquilino una partición dedicada, equilibrando el aislamiento y el rendimiento de búsqueda. Sin embargo, este enfoque está limitado por el límite máximo de particiones de Milvus.
Multi-tenencia basada en clave de partición: Esta es una opción más escalable en la que una única colección utiliza claves de partición para distinguir a los inquilinos. Este método simplifica la gestión de recursos y admite una mayor escalabilidad, pero no admite inserciones masivas de datos.
La siguiente tabla resume las diferencias clave entre los principales enfoques de multi-tenencia.
| Granularidad | Nivel de base de datos | Nivel de colección | Nivel de clave de partición |
|---|---|---|---|
| Máx. inquilinos admitidos | ~1,000 | ~10,000 | ~10,000,000 |
| Flexibilidad de organización de datos | Alta: Los usuarios pueden definir múltiples colecciones con esquemas personalizados. | Media: Los usuarios están limitados a una colección con un esquema personalizado. | Baja: Todos los usuarios comparten una colección, lo que requiere un esquema consistente. |
| Coste por usuario | Alto | Medio | Bajo |
| Aislamiento de recursos físicos | Sí | Sí | No |
| RBAC | Sí | Sí | No |
| Rendimiento de búsqueda | Sólido | Medio | Sólido |
Ejemplo: Estrategia de multiinquilinato para una base de conocimientos empresarial impulsada por RAG
Al diseñar la estrategia de multiinquilinato para un sistema RAG, es esencial alinear su enfoque con las necesidades específicas de su negocio y de sus inquilinos. Milvus ofrece varias estrategias de multiinquilinato, y elegir la adecuada depende del número de inquilinos, sus requisitos y el nivel de aislamiento de datos necesario. Aquí tiene una guía práctica para tomar estas decisiones, tomando como ejemplo una base de conocimientos empresarial impulsada por RAG.
Comprender la estructura de los inquilinos antes de elegir una estrategia de multiinquilinato
Una base de conocimientos empresarial impulsada por RAG a menudo atiende a un pequeño número de inquilinos. Estos inquilinos suelen ser unidades de negocio independientes como TI, Ventas, Legal y Marketing, cada una de las cuales requiere servicios de base de conocimientos distintos. Por ejemplo, el Departamento de RR. HH. gestiona información sensible de los empleados, como guías de incorporación y políticas de beneficios, que debe ser confidencial y accesible solo para el personal de RR. HH.
En este caso, cada unidad de negocio debe tratarse como un inquilino separado y una estrategia de multiinquilinato a nivel de base de datos suele ser la más adecuada. Al asignar bases de datos dedicadas a cada inquilino, las organizaciones pueden lograr un sólido aislamiento lógico, simplificando la gestión y mejorando la seguridad. Esta configuración proporciona a los inquilinos una flexibilidad significativa: pueden definir modelos de datos personalizados dentro de las colecciones, crear tantas colecciones como necesiten y gestionar de forma independiente el control de acceso para sus colecciones.
Mejorar la seguridad con aislamiento de recursos físicos
En situaciones en las que la seguridad de los datos tiene una alta prioridad, el aislamiento lógico a nivel de base de datos puede no ser suficiente. Por ejemplo, algunas unidades de negocio podrían manejar datos críticos o altamente sensibles, lo que requiere garantías más sólidas contra la interferencia de otros inquilinos. En tales casos, podemos implementar un enfoque de aislamiento físico sobre una estructura de multiinquilinato a nivel de base de datos.
Milvus nos permite asignar componentes lógicos, como bases de datos y colecciones, a recursos físicos. Este método garantiza que las actividades de otros inquilinos no afecten a las operaciones críticas. Exploremos cómo funciona este enfoque en la práctica.
Figura- Cómo Milvus gestiona los recursos físicos.png
Figura: Cómo Milvus gestiona los recursos físicos
Como se muestra en el diagrama anterior, hay tres capas de gestión de recursos en Milvus: Query Node, Resource Group y Database.
Query Node: El componente que procesa las tareas de consulta. Se ejecuta en una máquina física o contenedor (p. ej., un pod en Kubernetes).
Resource Group: Una colección de Query Nodes que actúa como puente entre los componentes lógicos (bases de datos y colecciones) y los recursos físicos. Puedes asignar una o más bases de datos o colecciones a un único Resource Group.
En el ejemplo mostrado en el diagrama anterior, hay tres bases de datos lógicas: X, Y y Z.
Base de datos X: Contiene la Colección A.
Base de datos Y: Contiene las Colecciones B y C.
Base de datos Z: Contiene las Colecciones D y E.
Supongamos que la Base de datos X contiene una base de conocimiento crítica que no queremos que se vea afectada por la carga de la Base de datos Y o la Base de datos Z. Para garantizar el aislamiento de datos:
A la Base de datos X se le asigna su propio Resource Group para garantizar que su base de conocimiento crítica no se vea afectada por las cargas de trabajo de otras bases de datos.
La Colección E también se asigna a un Resource Group separado dentro de su base de datos principal (Z). Esto proporciona aislamiento a nivel de colección para datos críticos específicos dentro de una base de datos compartida.
Mientras tanto, las colecciones restantes en las Bases de datos Y y Z comparten los recursos físicos del Resource Group 2.
Al asignar cuidadosamente los componentes lógicos a los recursos físicos, las organizaciones pueden lograr una arquitectura multiinquilino flexible, escalable y segura, adaptada a sus necesidades empresariales específicas.
Diseño del acceso a nivel de usuario final
Ahora que hemos aprendido las mejores prácticas para elegir una estrategia multiinquilino para un RAG empresarial, exploremos cómo diseñar el acceso a nivel de usuario en dichos sistemas.
En estos sistemas, los usuarios finales suelen interactuar con la base de conocimiento en modo de solo lectura a través de LLMs. Sin embargo, las organizaciones aún necesitan rastrear esos datos de preguntas y respuestas generados por los usuarios y vincularlos a usuarios específicos para diversos fines, como mejorar la precisión de la base de conocimiento u ofrecer servicios personalizados.
Tomemos como ejemplo el mostrador de servicio de consultas inteligentes de un hospital. Los pacientes podrían hacer preguntas como: “¿Hay citas disponibles con el especialista hoy?” o "¿Se necesita alguna preparación específica para mi próxima cirugía?" Aunque estas preguntas no afectan directamente a la base de conocimiento, es importante que el hospital rastree estas interacciones para mejorar los servicios. Estos pares de preguntas y respuestas suelen almacenarse en una base de datos separada (no necesariamente tiene que ser una base de datos vectorial) dedicada al registro de interacciones.
Figura- La arquitectura multiinquilino para una base de conocimiento RAG empresarial .png
Figura: La arquitectura multiinquilino para una base de conocimiento RAG empresarial
El diagrama anterior muestra la arquitectura multiinquilino de un sistema RAG empresarial.
Administradores del sistema supervisan el sistema RAG, gestionan la asignación de recursos, asignan bases de datos, las mapean a grupos de recursos y garantizan la escalabilidad. Se encargan de la infraestructura física, como se muestra en el diagrama, donde cada grupo de recursos (p. ej., Resource Group 1, 2 y 3) se asigna a servidores físicos (nodos de consulta).
Los inquilinos (propietarios y desarrolladores de bases de datos) gestionan la base de conocimiento, iterando sobre ella en función de los datos de preguntas y respuestas generados por los usuarios, como se muestra en el diagrama. Diferentes bases de datos (Base de datos X, Y, Z) contienen colecciones con distinto contenido de base de conocimiento (Colección A, B, etc.).
Los usuarios finales interactúan con el sistema en modo de solo lectura a través del LLM. A medida que consultan el sistema, sus preguntas se registran en la tabla separada de registros de preguntas y respuestas (una base de datos separada), alimentando continuamente al sistema con datos valiosos.
Este diseño garantiza que cada capa del proceso —desde la interacción del usuario hasta la administración del sistema— funcione sin problemas, ayudando a la organización a construir una base de conocimiento sólida y en mejora continua.
Resumen
En este blog, hemos explorado cómo los marcos de multi-tenancy desempeñan un papel fundamental en la escalabilidad, la seguridad y el rendimiento de las bases de conocimiento impulsadas por RAG. Al aislar datos y recursos para diferentes inquilinos, las empresas pueden garantizar la privacidad, el cumplimiento normativo y una asignación optimizada de recursos en una infraestructura compartida. Milvus, con sus estrategias flexibles de multi-tenancy, permite a las empresas elegir el nivel adecuado de aislamiento de datos —desde el nivel de base de datos hasta el nivel de partición— según sus necesidades específicas. Elegir el enfoque adecuado de multi-tenancy garantiza que las empresas puedan ofrecer servicios personalizados a los inquilinos, incluso cuando gestionan datos y cargas de trabajo diversos.
Siguiendo las mejores prácticas descritas aquí, las organizaciones pueden diseñar y gestionar eficazmente sistemas RAG con multi-tenancy que no solo ofrecen experiencias de usuario superiores, sino que también escalan sin esfuerzo a medida que crecen las necesidades del negocio. La arquitectura de Milvus garantiza que las empresas puedan mantener altos niveles de aislamiento, seguridad y rendimiento, lo que la convierte en un componente crucial para crear bases de conocimiento de nivel empresarial impulsadas por RAG.
Mantente atento a más información sobre RAG con multi-tenancy
En este blog, hemos analizado cómo las estrategias de multi-tenancy de Milvus están diseñadas para gestionar inquilinos, pero no usuarios finales dentro de esos inquilinos. Las interacciones de los usuarios finales suelen producirse en la capa de aplicación, mientras que la propia base de datos vectorial permanece ajena a esos usuarios.
Puede que te preguntes: Si quiero ofrecer respuestas más precisas basadas en el historial de consultas de cada usuario final, ¿no necesita Milvus mantener un contexto personalizado de preguntas y respuestas para cada usuario?
Esa es una gran pregunta, y la respuesta realmente depende del caso de uso. Por ejemplo, en un servicio de consultoría bajo demanda, las consultas son aleatorias, y el enfoque principal está en la calidad de la base de conocimiento más que en hacer un seguimiento del contexto histórico de un usuario.
Sin embargo, en otros casos, los sistemas RAG deben ser conscientes del contexto. Cuando esto es necesario, Milvus debe colaborar con la capa de aplicación para mantener una memoria personalizada del contexto de cada usuario. Este diseño es especialmente importante para aplicaciones con una cantidad masiva de usuarios finales, lo que exploraremos con mayor detalle en mi próxima publicación. ¡Mantente atento a más información!
Sigue leyendo
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
OpenAI o1: What Developers Need to Know
In this article, we will talk about the o1 series from a developer's perspective, exploring how these models can be implemented for sophisticated use cases.
Introducing DeepSearcher: A Local Open Source Deep Research
In contrast to OpenAI’s Deep Research, this example ran locally, using only open-source models and tools like Milvus and LangChain.