Diseño de RAG multitenencia con Milvus: mejores prácticas para bases de conocimiento empresariales escalables

Introducción

En los últimos dos años, la Generación Mejorada por Recuperación (RAG) ha surgido como una solución de confianza para que las grandes organizaciones mejoren sus aplicaciones basadas en LLM, especialmente aquellas con usuarios diversos. A medida que estas aplicaciones crecen, resulta esencial implementar un marco de multiarrendamiento. La multitenencia proporciona un acceso seguro y aislado a los datos para diferentes grupos de usuarios, lo que garantiza la confianza de los usuarios, el cumplimiento de las normas reglamentarias y la mejora de 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 del GAR, que almacena y recupera información contextual para los LLM de fuentes externas. Milvus ofrece estrategias flexibles de multi-tenencia para diversas necesidades, incluyendo multi-tenencia a nivel de base de datos, a nivel de colección y a nivel de partición.

En este post, cubriremos:

• Qué es la multitenencia y por qué es importante

• Estrategias de multiarrendamiento en Milvus

• Ejemplo: Estrategia de multiarrendamiento para una base de conocimiento empresarial potenciada por RAG

Qué es la multitenencia y por qué es importante

El multiarrendamiento es una arquitectura en la que varios clientes o equipos, conocidos como "arrendatarios", comparten una única instancia de una aplicación o sistema. Los datos y las configuraciones de cada inquilino están aislados lógicamente, lo que garantiza la privacidad y la seguridad, mientras que todos los inquilinos comparten la misma infraestructura subyacente.

Imagine una plataforma SaaS que proporciona soluciones basadas en el conocimiento a múltiples empresas. Cada empresa es un inquilino.

• El inquilino A es una organización sanitaria que almacena preguntas frecuentes dirigidas a los pacientes y documentos de cumplimiento.

• El inquilino B es una empresa tecnológica que gestiona flujos de trabajo internos de solución de problemas de TI.

• El inquilino C es una empresa minorista con preguntas frecuentes de atención al cliente para devoluciones de productos.

Cada inquilino opera en un entorno completamente aislado, garantizando 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íficas de cada inquilino, lo que garantiza un alto rendimiento independientemente de los picos de carga de trabajo en un inquilino.

El multiarrendamiento también funciona para sistemas que dan servicio a diferentes equipos dentro de la misma organización. Imagínese una gran empresa que utiliza una base de conocimientos basada en RAG para dar servicio a sus departamentos internos, como RRHH, Legal y Marketing. En esta configuración, cada departamento es un inquilino con datos y recursos aislados.

El multiarrendamiento ofrece importantes ventajas, como la rentabilidad, la escalabilidad y una sólida seguridad de los datos. Al compartir una única infraestructura, los proveedores de servicios pueden reducir los gastos generales y garantizar un consumo más eficaz de los recursos. Este enfoque también se adapta sin esfuerzo: la incorporación de nuevos inquilinos requiere muchos menos recursos que la creación de instancias independientes para cada uno, como ocurre con los modelos de tenencia única. Y lo que es más importante, la multitenencia mantiene una sólida seguridad de los datos al garantizar un estricto aislamiento de los datos de cada inquilino, con controles de acceso y cifrado que protegen la información confidencial de accesos no autorizados. Además, las actualizaciones, los parches y las nuevas funciones pueden desplegarse simultáneamente en todos los inquilinos, lo que simplifica el mantenimiento del sistema y reduce la carga de trabajo de los administradores, al tiempo que garantiza el cumplimiento de las normas de seguridad y conformidad.

Estrategias de multiarrendamiento en Milvus

Para entender cómo Milvus soporta la multitenencia, es importante ver primero cómo organiza los datos de usuario.

Cómo organiza Milvus los datos de usuario

Milvus estructura los datos en tres capas, yendo de lo amplio a lo granular: Base de datos, Colección y Partición/Clave de partición.

Figura- Cómo organiza Milvus los datos de usuario .png

Figura: Cómo organiza Milvus 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 por Particiones. Utilizando una clave de partición, los datos con la misma clave se agrupan. Por ejemplo, si utiliza 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 pasa de la Base de Datos a la Colección y a la Clave de Partición, la granularidad de la organización de los datos se hace progresivamente más fina.

Para garantizar una mayor seguridad de los datos y un control de acceso adecuado, Milvus también proporciona un sólido Control de Acceso Basado en Funciones (RBAC), que permite a los administradores definir permisos específicos para cada usuario. Sólo los usuarios autorizados pueden acceder a determinados datos.

Milvus admite múltiples estrategias para implementar la multitenencia, ofreciendo flexibilidad basada en las necesidades de su aplicación: multitenencia 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 multiarrendamiento a nivel de base de datos, a cada arrendatario se le asigna su propia base de datos dentro del mismo clúster Milvus. Esta estrategia proporciona un fuerte aislamiento de los datos y garantiza un rendimiento óptimo de las búsquedas. Sin embargo, puede conducir a una utilización ineficiente de los recursos si algunos inquilinos permanecen inactivos.

Multiarrendamiento a nivel de colección

Aquí, en la multitenencia a nivel de colección, podemos organizar los datos para los inquilinos de dos maneras.

• Una colección para todos los arrendatarios: Todos los arrendatarios comparten una única colección, con campos específicos del arrendatario utilizados para el filtrado. Aunque es fácil de implementar, este enfoque puede encontrar cuellos de botella en el 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 enfrentarse a limitaciones de escalabilidad si el número de inquilinos supera la capacidad de recogida de Milvus.

Multiarrendamiento a nivel de partición

Partition-Level Multi-Tenancy se centra en la organización de inquilinos dentro de una única colección. Aquí, también tenemos dos formas 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 tenant una partición dedicada, equilibrando el aislamiento y el rendimiento de la búsqueda. Sin embargo, este enfoque está restringido por el límite máximo de particiones de Milvus.

• Multiarrendamiento basado en claves de partición: Se trata de 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 permite una mayor escalabilidad, pero no admite la inserción masiva de datos.

La siguiente tabla resume las principales diferencias entre los enfoques de multitenencia basados en claves.

Granularidad	A nivel de base de datos	Nivel de colección	Nivel de clave de partición
Número máximo de 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 coherente.
Coste por usuario	Alto	Medio	Bajo
Aislamiento de recursos físicos	Sí	Sí	No
RBAC	Sí	Sí	No
Rendimiento de la búsqueda	Fuerte	Media	Fuerte

Ejemplo: Estrategia de multiarrendamiento para una base de conocimiento empresarial potenciada por RAG

Al diseñar la estrategia de multiarrendamiento para un sistema RAG, es esencial alinear su enfoque con las necesidades específicas de su empresa y sus arrendatarios. Milvus ofrece varias estrategias de multiarrendamiento, y elegir la correcta depende del número de arrendatarios, sus requisitos y el nivel de aislamiento de datos necesario. A continuación le ofrecemos una guía práctica para tomar estas decisiones, tomando como ejemplo una base de conocimiento empresarial impulsada por RAG.

Comprender la estructura de los inquilinos antes de elegir una estrategia multiinquilino

Una base de conocimiento empresarial impulsada por RAG a menudo sirve 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 conocimiento distintos. Por ejemplo, el departamento de RR.HH. gestiona información sensible sobre los empleados, como guías de incorporación y políticas de beneficios, que deben ser confidenciales y accesibles sólo para el personal de RR.HH..

En este caso, cada unidad de negocio debe tratarse como un inquilino independiente y una estrategia de multiarrendamiento 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 fuerte aislamiento lógico, simplificando la gestión y mejorando la seguridad. Esta configuración proporciona a los inquilinos una gran flexibilidad: pueden definir modelos de datos personalizados dentro de las colecciones, crear tantas colecciones como sea necesario y gestionar de forma independiente el control de acceso a sus colecciones.

Mejora de la seguridad con el aislamiento de recursos físicos

En situaciones en las que la seguridad de los datos es una prioridad, el aislamiento lógico a nivel de base de datos puede no ser suficiente. Por ejemplo, algunas unidades de negocio pueden manejar datos críticos o altamente sensibles, requiriendo garantías más fuertes contra la interferencia de otros inquilinos. En estos casos, podemos aplicar un enfoque de aislamiento físico sobre una estructura multiarrendamiento 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 gestiona Milvus los recursos físicos.png

Figura: Cómo gestiona Milvus los recursos físicos

Como se muestra en el diagrama anterior, hay tres capas de gestión de recursos en Milvus: Nodo de consulta, Grupo de recursos y Base de datos.

• Nodo de consulta: El componente que procesa las tareas de consulta. Se ejecuta en una máquina física o contenedor (por ejemplo, un pod en Kubernetes).

• Grupo de recursos: Una colección de Nodos de Consulta que actúa como puente entre los componentes lógicos (bases de datos y colecciones) y los recursos físicos. Puede asignar una o más bases de datos o colecciones a un único Grupo de Recursos.

En el ejemplo del 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 conocimientos 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 los datos:

• Ala Base de Datos X se le asigna su propio Grupo de Recursos para garantizar que su base de conocimiento crítica no se ve afectada por las cargas de trabajo de otras bases de datos.

• La colección E también se asigna a un grupo de recursos independiente 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 de las bases de datos Y y Z comparten los recursos físicos del grupo de recursos 2.

Al asignar cuidadosamente los componentes lógicos a los recursos físicos, las organizaciones pueden lograr una arquitectura multi-tenancy 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 multi-tenancy para un RAG empresarial, vamos a explorar cómo diseñar el acceso a nivel de usuario en este tipo de sistemas.

En estos sistemas, los usuarios finales suelen interactuar con la base de conocimientos en modo de sólo lectura a través de los LLM. Sin embargo, las organizaciones siguen necesitando hacer un seguimiento de los datos de preguntas y respuestas generados por los usuarios y vincularlos a usuarios específicos con diversos fines, como mejorar la precisión de la base de conocimientos u ofrecer servicios personalizados.

Tomemos como ejemplo el servicio de consultas inteligentes de un hospital. Los pacientes pueden hacer preguntas como: "¿Hay alguna cita disponible 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 conocimientos, es importante que el hospital realice un seguimiento de estas interacciones para mejorar los servicios. Estos pares de preguntas y respuestas suelen almacenarse en una base de datos independiente (no tiene por qué ser necesariamente una base de datos vectorial) dedicada a registrar las interacciones.

Figura- Arquitectura multiarrendamiento para una base de conocimientos RAG empresarial .png

Figura: Arquitectura multiarrendamiento para una base de conocimientos RAG empresarial

El diagrama anterior muestra la arquitectura multi-tenencia de un sistema RAG empresarial.

• Los administradores del sistema supervisan el sistema RAG, gestionan la asignación de recursos, asignan bases de datos, las asignan 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 (por ejemplo, los grupos de recursos 1, 2 y 3) se asigna a servidores físicos (nodos de consulta).

• Los inquilinos (propietarios de bases de datos y desarrolladores) gestionan la base de conocimientos, iterando sobre ella a partir 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 diferentes contenidos de la base de conocimientos (Colección A, B, etc.).

• Los usuarios finales interactúan con el sistema en modo de sólo lectura a través del LLM. A medida que consultan el sistema, sus preguntas se registran en la tabla de registro de preguntas y respuestas (una base de datos independiente), con lo que el sistema recibe continuamente datos valiosos.

Este diseño garantiza que cada capa del proceso -desde la interacción con el usuario hasta la administración del sistema- funcione a la perfección, ayudando a la organización a crear una base de conocimientos sólida y en continua mejora.

Resumen

En este blog, hemos explorado cómo los marcos multi-tenancy juegan un papel crítico en la escalabilidad, seguridad y rendimiento de las bases de conocimiento impulsadas por RAG. Al aislar los datos y los recursos para diferentes inquilinos, las empresas pueden garantizar la privacidad, el cumplimiento normativo y la asignación optimizada de recursos a través de una infraestructura compartida. Milvus, con sus estrategias flexibles de multiarrendamiento, 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- en función de sus necesidades específicas. Elegir el enfoque de multiarrendamiento adecuado garantiza que las empresas puedan ofrecer servicios personalizados a los inquilinos, incluso cuando se trata de datos y cargas de trabajo diversos.

Siguiendo las mejores prácticas aquí descritas, las organizaciones pueden diseñar y gestionar eficazmente sistemas RAG multiarrendamiento que no sólo ofrecen experiencias de usuario superiores, sino que también se escalan sin esfuerzo a medida que crecen las necesidades empresariales. 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 en la creación de bases de conocimiento potenciadas por RAG de nivel empresarial.

Manténgase en sintonía para obtener más información sobre RAG de tenencia múltiple

En este blog, hemos discutido cómo las estrategias de tenencia múltiple de Milvus están diseñadas para administrar inquilinos, pero no usuarios finales dentro de esos inquilinos. Las interacciones de los usuarios finales suelen producirse en la capa de la aplicación, mientras que la propia base de datos vectorial permanece ajena a esos usuarios.

Es posible que se pregunte: Si quiero ofrecer respuestas más precisas basadas en el historial de consultas de cada usuario final, ¿no necesita Milvus mantener un contexto de preguntas y respuestas personalizado para cada usuario?

Es una gran pregunta, y la respuesta depende realmente del caso de uso. Por ejemplo, en un servicio de consulta a la carta, las consultas son aleatorias, y la atención se centra más en la calidad de la base de conocimientos que en hacer un seguimiento del contexto histórico de un usuario.

Sin embargo, en otros casos, los sistemas GAR deben ser conscientes del contexto. Cuando esto es necesario, Milvus tiene que 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 usuarios finales masivos, que exploraremos con más detalle en mi próximo post. Permanezca atento para conocer más detalles.