LLM y Azure OpenAI en el patrón de generación aumentada de recuperación (RAG) (versión preliminar)

Importante

Esta es una característica en versión preliminar. Esta información se relaciona con una función preliminar que puede modificarse sustancialmente antes de su lanzamiento. Microsoft no otorga ninguna garantía, explícita o implícita, con respecto a la información proporcionada aquí.

Este artículo ofrece un ejemplo ilustrativo del uso de modelos de lenguaje grandes (LLM) y Azure OpenAI dentro del contexto del patrón de generación aumentada de recuperación (RAG). Específicamente, explora cómo puede aplicar estas tecnologías dentro de las zonas de aterrizaje soberanas, al tiempo que tiene en cuenta importantes barreras de seguridad.

Escenario

Un escenario común es utilizar los LLM para entablar conversaciones utilizando sus propios datos a través del patrón de generación aumentada de recuperación (RAG). Este patrón le permite aprovechar las capacidades de razonamiento de los LLM para generar respuestas basadas en sus datos específicos sin ajustar el modelo. Facilita la integración perfecta de los LLM en sus soluciones o procesos de negocio existentes.

Nube para la soberanía: arquitectura de referencia de IA y LLM

Microsoft Cloud for Sovereignty proporciona una arquitectura de referencia que ilustra una arquitectura típica de generación aumentada de recuperación (RAG) dentro de una zona de aterrizaje soberana (SLZ). Proporciona una descripción general de las opciones de tecnología de implementación comunes y recomendadas, la terminología, los principios tecnológicos, los entornos de configuración comunes y la composición de los servicios aplicables.

Descargue un PDF imprimible de este diagrama de arquitectura de referencia.

Las etapas clave/flujo de datos son las siguientes:

Zonas de aterrizaje de aplicación

En la jerarquía del grupo de administración, estos servicios se ubican en una suscripción dentro de un grupo de administración no confidencial.

Orígenes de datos y canales de transformación

Los orígenes de datos y los canales de transformación a menudo existen dentro de una organización para las operaciones de línea de negocio. Al integrar aplicaciones de LLM, como las implementaciones RAG, con datos existentes, se convierten en nuevas cargas de trabajo.

Para garantizar el control del flujo de datos, la arquitectura de referencia recomienda un zonas de aterrizaje de datos alineadas con un dominio de datos para orígenes de datos y emplaza las canalizaciones de transformación de datos cerca de esos orígenes para crear productos de datos que usan las aplicaciones de LLM. Este enfoque garantiza una administración precisa de los datos aprovisionados para la solución basada en LLM, que se aloja por separado.

Los componentes de transformación de datos hacen uso de diferentes tecnologías y servicios para transformar los datos en un formato que pueda ser buscado y utilizado por una aplicación basada en LLM a través de una búsqueda semántica o vectorial con fines de base. Estas canalizaciones pueden funcionar por sí solas o pueden utilizar servicios de IA, como los servicios de IA de Azure o Azure OpenAI, para transformar los datos para colocarlos en una base de datos de búsqueda vectorial o de búsqueda semántica.

Al usar los servicios de IA, el emparejamiento de red siempre los pone a su disposición (a través del centro de conectividad o directamente) a través de sus puntos de conexión privados. Por razones de gobernanza, seguridad y cumplimiento, los componentes de transformación de datos tienen autoridad para determinar qué datos y en qué formato se proporcionan a una base de datos de búsqueda para la carga de trabajo de LLM.

Los componentes de transformación de datos pueden usar varios tipos de orígenes de datos para ofrecer datos con el resultado óptimo a las bases de datos de búsqueda en las que se basan las cargas de trabajo de LLM. Estos orígenes de datos pueden ser bases de datos SQL, lagos de datos o incluso máquinas virtuales que hospedan soluciones de datos personalizadas, en función del entorno del cliente.

Los orígenes de datos no deberían ser accesibles directamente por la aplicación Orquestador, sino que estos recursos solo deberían estar disponibles dentro de los límites privados de la red virtual. Esto impone la integración directa de Microsoft Azure Virtual Network (por ejemplo, como en el caso de las máquinas virtuales), los servicios de Private Link o los puntos de conexión de los servicios de Virtual Network (solo si Private Link o la integración directa de Virtual Network no están disponibles).

Componentes relacionados con AI y LLM

Los componentes relacionados con IA y LLM deben hospedarse como cargas de trabajo en su propia suscripción bajo el grupo de administración Corp o En línea (dependiendo de si se requiere acceso público o no). Estos componentes son:

Azure OpenAI Service encapsula las operaciones de LLM como GPT e incrustaciones de texto como Ada, lo que las hace accesibles a través de API estándar proporcionadas por Azure OpenAI a la aplicación Orchestrator.

Una aplicación Orquestador actúa como front-end con una interfaz basada en API o UX, y orquesta los diferentes pasos necesarios para construir experiencias basadas en RAG. A menudo, es una aplicación web o una API web. Estos pasos normalmente incluyen:

• extraer datos de los motores de búsqueda semántica para una fundamentación de solicitudes
• extraer datos de orígenes de datos para una fundamentación de solicitudes
• encadenar correctamente diferentes solicitudes al LLM

La aplicación Orchestrator mantiene el historial de las solicitudes enviadas y las respuestas recibidas para garantizar que el servicio Azure se base en interacciones anteriores. OpenAI Por ejemplo, en una experiencia de tipo chat como ChatGPT o Bing Chat, la aplicación Orquestador mantiene o almacena en caché el historial de la sesión conversacional de forma que se tenga en cuenta en el flujo de la conversación por el backend del servicio de LLM.

En un entorno En línea, el punto de conexión de la aplicación Orquestador debe ser el único que se proporcione a través de un punto de conexión público protegido por un firewall de aplicaciones web y servicios de protección DDoS. Si se hospeda en un entorno Corp, sin puntos de conexión públicos, el Orquestador se hospeda en un servicio integrado directamente en la red virtual, como las máquinas virtuales o los conjuntos de escalado de máquinas virtuales, o bien usa servicios que admiten puntos de conexión de servicios de red privada o virtual, como es el caso de Azure App Services.

Los servicios de búsqueda proporcionan datos de varias fuentes en un formato optimizado para un uso eficiente para una rápida puesta en marcha de los servicios de LLM. Microsoft propone una combinación de vectorización y búsqueda semántica para lograr los mejores resultados en la fundamentación de solicitudes basada en servicios de búsqueda, con el apoyo de Azure AI Search. Usar la clasificación semántica mejora de forma mensurable la relevancia de las búsquedas al utilizar el reconocimiento del lenguaje para clasificar los resultados de las búsquedas. Esto mejora la experiencia de usuario de las solicitudes RAG, ya que la fundamentación de solicitudes se vuelve más precisa gracias a los mejores resultados de búsqueda del servicio de búsqueda antes de enviar una solicitud al LLM.

Podría usarse una combinación de servicios de IA para crear experiencias personalizadas para los usuarios finales a través del Orquestador, o para optimizar los procesos de ingesta de datos. Imagine usar un servicio de reconocimiento de formularios como Documento de inteligencia de Azure AI para extraer información estructurada de los formularios y procesar y resumir eficazmente las entradas de los usuarios. A continuación, este servicio puede colaborar con un LLM para resumir las conclusiones clave de esas entradas de formularios reconocidos. Otro escenario implica usar un servicio de reconocimiento de documentos para convertir documentos en varios formatos, como PDF o documentos de Word, en texto. Posteriormente, un servicio de inserción de texto de LLM puede vectorizar este texto reconocido para su posterior análisis.

Los servicios privados vincular se implementan para todos los componentes, de modo que todos los servicios solo sean accesibles dentro del ambiente privado. La única excepción podría ser la aplicación de Orquestador, que, si se hospeda en una zona de aterrizaje En línea, podría ofrecerse públicamente tras un firewall de aplicaciones web o servicios equivalentes.

Componentes de infraestructura

Los componentes de la infraestructura pueden hospedarse como parte de la carga de trabajo o de forma centralizada en un centro de conectividad o en una suscripción de identidad.

El componente de infraestructura central de la implementación de una zona de aterrizaje soberana es el centro de conectividad de la plataforma, que es una red virtual proporcionada por cada implementación de la zona de aterrizaje soberana. Se coloca en la suscripción de conectividad en el grupo de administración de la plataforma.

Los componentes de red compartidos se colocan en la red virtual del concentrador. Estos componentes suelen incluir:

• Circuitos ExpressRoute o puertas de enlace VPN para conectividad a la red corporativa de una empresa, agencia u organización.

• Los firewalls se pueden implementar mediante dispositivos o una combinación de ofertas de Azure Firewall, incluido el Firewall de aplicaciones web. Estas soluciones habilitan la inspección, el filtrado y el enrutamiento del tráfico.

• Componentes de protección DDoS para proteger cargas de trabajo contra ataques distribuidos de denegación de servicio.

• Zonas DNS privadas para todos los tipos de servicios utilizados en todo el panorama del centro de datos virtual implementado con zonas de aterrizaje.

• Peering de red virtual para conectar redes virtuales de diversas cargas de trabajo, como fuentes de datos, transformación y componentes LLM a través de la red central.

• Las políticas controlan el flujo de tráfico a través de los firewalls del concentrador cuando es necesario.

Consideraciones

El diagrama de la arquitectura de referencia muestra una arquitectura de ejemplo representativa que incluye los componentes típicos de una carga de trabajo basada en el RAG de LLM en el contexto de una zona de aterrizaje soberana. Hay varias consideraciones a tener en cuenta que no se han tratado en las secciones anteriores.

Alineación con los principios del marco de buena arquitectura y Cloud Adoption Framework

En las secciones anteriores se mencionaron brevemente algunos aspectos de la alineación relacionados con el marco de buena arquitectura (WAF) y Cloud Adoption Framework (CAF). Es importante señalar que todas las decisiones arquitectónicas deben estar totalmente alineadas con los principios fundamentales de CAF y Azure Landing Zones, los análisis a escala de la nube de CAF y WAF, incluida la perspectiva de WAF en Azure OpenAI.

Consideraciones sobre el diseño de infraestructuras relacionadas con las medidas de seguridad

Si bien el manejo de las barreras de seguridad es un procedimiento estándar en entornos de zonas de aterrizaje, deben tenerse en cuenta otras consideraciones en varios ámbitos para las cargas de trabajo de IA y LLM. Lo mejor es seguir el cumplimiento de la referencia de seguridad de Azure y los estándares de la iniciativa de la directiva de referencia de soberanía mientras se diseña y define la infraestructura para la suscripción de la carga de trabajo.

Las principales consideraciones a destacar de estos estándares para las aplicaciones basadas en RAG de LLM son:

Residencia de datos y selección de regiones

La soberanía impone requisitos estrictos sobre la residencia de los datos y, por lo tanto, podría restringir las implementaciones a regiones Azure específicas en una SLZ. La selección de una región para las cargas de trabajo de LLM está limitada por la disponibilidad de los servicios requeridos:

• Verifique que tanto Azure OpenAI como Azure AI Search están disponibles en la región de destino en la que aloja sus datos y su carga de trabajo por motivos de residencia de datos o proximidad. Además, estos servicios son importantes, desde la perspectiva del rendimiento, para la experiencia del usuario final de la aplicación.

• En segundo lugar, al examinar Azure OpenAI, la disponibilidad de los respectivos modelos de LLM es importante, ya que no todos los modelos están disponibles por igual en todas las regiones.

• Si los orígenes de datos u otros servicios cognitivos no están disponibles en la región designada como objetivo, es posible que pueda encontrarlos y utilizarlos en otra región en consonancia con sus requisitos de residencia de datos. Sin embargo, Azure OpenAI Service y Azure AI Search deben estar en la misma región que la aplicación de Orquestador por razones de rendimiento.

Redes

Los puntos de conexión públicos no están permitidos en entornos Corp. Por lo tanto, todos los servicios deben encapsularse en una red virtual. Dependiendo del servicio, puede ofrecer capacidades de encapsulación directa como máquinas virtuales o clústeres AKS, enlace privado o puntos de conexión del servicio de red virtual. Los puntos de conexión de servicio de red virtual deben reemplazarse por un vínculo privado siempre que sea posible.

Además de la encapsulación, debe deshabilitarse el acceso público para todos los servicios. Por último, debe habilitarse el cumplimiento de directivas mediante Azure Policy de forma que nunca pueda habilitarse el acceso público accidentalmente para servicios en los que no puedan crearse las correspondientes políticas de denegación. La estrategia de defensa en profundidad consiste en habilitar las capacidades de auditoría correspondientes para todos los servicios.

Cifrado en reposo y en tránsito

La mayoría de los servicios en Azure admiten tanto capacidades de cifrado en tránsito como en reposo. Habilite el cifrado en reposo y en tránsito en todos los servicios cuando esté disponible. Habilite la última versión de TLS, actualmente TLS 1.2, para el cifrado en tránsito.

Identidades administradas

Use identidades administradas para todos los servicios y la comunicación de servicio a servicio para evitar la administración de secretos para las credenciales.

Rotación de llaves en Key Vault

Siempre que se requieran activos de seguridad como certificados, habilite la rotación de claves para esos secretos en Key Vault para mantener el cumplimiento.

Grupos de seguridad de redes y aplicaciones

En un entorno soberano y seguro, se usan obligatoriamente los grupos de seguridad de red (NSG) y los grupos de seguridad de aplicaciones (ASG). La ausencia de grupos de seguridad conduce a implementaciones no conformes. Los puertos SSL habituales son útiles para la mayoría de los servicios de los que dependen las cargas de trabajo de LLM/RAG, ya que se basan en HTTPS. Se requieren puertos específicos para la ingesta de datos desde los orígenes a las bases de datos de búsqueda y vectoriales. Las IP públicas no están permitidas en zonas de aterrizaje de Corp. Todos los servicios deben ser accesibles solo en la red virtual, lo que requiere usar puntos de conexión privados o puntos finales de servicio de red virtual para los servicios PaaS.

Más barreras de seguridad y soberanía

Las barreras de seguridad más importantes y obvias tratadas en secciones anteriores para su diseño de infraestructuras y aplicaciones son reutilizables incluso fuera de Sovereign o Azure Landing Zones. Otras directivas globales están vinculadas a recursos administrados de forma centralizada, como los espacios de trabajo de Log Analytics o las implementaciones de Microsoft Sentinel en zonas de aterrizaje a escala empresarial. Durante su proceso de diseño de infraestructuras y aplicaciones, es crucial tener en cuenta estos recursos administrados de forma centralizada. No hacerlo puede suponer un esfuerzo y un tiempo adicionales tras la implementación. Afortunadamente, la característica de cumplimiento de directivas de Azure puede identificar los recursos no conformes después de la implementación. Además, tanto Sovereign como Azure Landing Zones proporcionan directivas DeployIfNotExists para numerosos recursos, lo que simplifica aún más el proceso.

Algunos ejemplos de este tipo de barreras de seguridad son:

• Activación del inicio de sesión en los espacios de trabajo de Log Analytics administrados de forma centralizada.

• Integración con Azure Security Center o Microsoft Defender for Cloud.

• Integración con conjuntos de aplicaciones de administración de eventos e información de seguridad (SIEM) como Microsoft Sentinel.

• Integración con firewalls de administración centralizada, firewalls de aplicaciones web o protección contra DDoS.

Estas son solo algunas barreras de seguridad que podría identificar como requisitos tras su implementación inicial. Es recomendable probar sus implementaciones en una zona de aterrizaje de pruebas e integrar de forma iterativa el cumplimiento de esas barreras de seguridad en su infraestructura y en la base de código de su aplicación. Si eso no es del todo posible, muchas de estas barreras de seguridad pueden abordarse después de la implementación con directivas DeployIfNotExists.

Implementar este escenario

Para aprovechar las ventajas de los modelos de lenguaje grandes (LLM) y de Azure OpenAI basados en el patrón de generación aumentada de recuperación (RAG) en las zonas de aterrizaje soberano, primero debe implementar y configurar una zona de aterrizaje soberana (SLZ) y aplicar las iniciativas de la directiva de referencia de soberanía. Para obtener una descripción detallada de una SLZ y todas sus capacidades, consulte la documentación sobre las zonas de aterrizaje soberanas en GitHub.

SLZ proporciona un entorno que ofrece barreras de seguridad mediante directivas y conjuntos de directivas, cumplimiento de la seguridad e infraestructura de base coherente para implementar cargas de trabajo y aplicaciones. SLZ se basa en Azure Landing Zones y lo amplía con barandillas y controles de seguridad específicos para los requisitos de soberanía.

Para ayudar a acelerar la generación de valor de los clientes y al mismo tiempo ayudarles a cumplir sus objetivos de cumplimiento, Microsoft Cloud for Sovereignty incluye plantillas de carga de trabajo listas para usar que se pueden implementar y operar de manera consistente y repetible. Las plantillas de carga de trabajo están alineadas con las iniciativas de directivas de línea de base de soberanía, Cartera de políticas de Cloud for Sovereignty y Directivas predeterminadas de Azure Landing Zone.

Plantilla de agente de información Asistente

La plantilla de agente de información Asistente proporciona un apuntar inicial para que las organizaciones creen su propia capacidad de IA generativa personalizada para extender el poder de Azure OpenAI a los usuarios de la organización y sus datos de dominio sin ajustar el modelo. Puede implementarlo en la nube para la soberanía y alinearlo con la arquitectura de referencia y a las orientaciones proporcionadas en este artículo. La plantilla de agente de información Asistente es compatible con el ámbito del grupo de administración de Sovereign Landing Zone Online mediante la configuración de implementación del modo seguro . Próximamente se ofrecerá soporte para el ámbito de gestión del grupo Corp .

La plantilla de agente es una combinación de código, documentación y recursos educativos que se proporciona sin cargo a clientes y socios y que puede ayudar a acelerar el tiempo para obtener valor.

Para obtener más información sobre cómo implementar y configurar la información Asistente, consulte la documentación de la plantilla de agente de información Asistente en GitHub. ... Para conocer los casos de uso que puede lograr con esta plantilla de agente, consulte la Información n.° Asistente Vídeo.