AWS AppSync Events puede ayudarle a crear API de Websocket más seguras y escalables. Además de transmitir eventos en tiempo real a millones de suscriptores de Websocket, admite un requisito crucial de experiencia de usuario de su AI Gateway: propagación de eventos de baja latencia desde los modelos de IA generativos elegidos a usuarios individuales.
En esta publicación, analizamos cómo utilizar AppSync Events como base de una arquitectura de puerta de enlace de IA capaz y sin servidor. Exploramos cómo se integra con los servicios de AWS para una cobertura integral de las capacidades ofrecidas en las arquitecturas de puerta de enlace de IA. Finalmente, lo ayudamos a comenzar su viaje con un código de muestra que puede iniciar en su cuenta y comenzar a construir.
Descripción general de la puerta de enlace AI
AI Gateway es un patrón de middleware arquitectónico que ayuda a mejorar la disponibilidad, la seguridad y la observabilidad de modelos de lenguaje grandes (LLM). Apoya los intereses de varias personas diferentes. Por ejemplo, los usuarios quieren baja latencia y experiencias agradables. Los desarrolladores quieren arquitecturas flexibles y extensibles. El personal de seguridad necesita gobernanza para proteger la información y la disponibilidad. Los ingenieros de sistemas necesitan soluciones de monitoreo y observabilidad que les ayuden a respaldar la experiencia del usuario. Los gerentes de producto necesitan información sobre qué tan bien funcionan sus productos con los usuarios. Los administradores de presupuesto necesitan controles de costos. Las necesidades de estas diferentes personas en su organización son consideraciones importantes para alojar aplicaciones de IA generativa.
Descripción general de la solución
La solución que compartimos en esta publicación ofrece las siguientes capacidades:
Identidad: autentique y autorice a los usuarios desde el directorio de usuarios integrado, desde su directorio empresarial y desde proveedores de identidad del consumidor como Amazon, Google y Facebook. API: proporcione a los usuarios y aplicaciones acceso de baja latencia a sus aplicaciones de IA generativas. Autorización: determine a qué recursos tienen acceso sus usuarios en su aplicación. Limitación y medición de velocidad: mitigue el tráfico de bots, bloquee el acceso y administre el consumo de modelos para administrar los costos. Acceso a diversos modelos: ofrezca acceso a los principales modelos básicos (FM), agentes y salvaguardas para mantener a los usuarios seguros. Registro: observe, solucionar problemas y analizar el comportamiento de las aplicaciones Análisis: extraiga valor de sus registros para crear, descubrir y compartir información significativa Monitoreo: realice un seguimiento de los puntos de datos clave que ayudan al personal a reaccionar rápidamente ante los eventos Almacenamiento en caché: reduzca los costos al detectar consultas comunes a sus modelos y respuestas predeterminadas devueltas
En las siguientes secciones, nos sumergimos en la arquitectura central y exploramos cómo puede incorporar estas capacidades a la solución.
Identidad y API
El siguiente diagrama ilustra una arquitectura que utiliza la API AppSync Events para proporcionar una interfaz entre una aplicación de asistente de IA y LLM a través de Amazon Bedrock utilizando AWS Lambda.
El flujo de trabajo consta de los siguientes pasos:
La aplicación cliente recupera la identidad del usuario y la autorización para acceder a las API mediante Amazon Cognito. La aplicación cliente se suscribe al canal AppSync Events, desde el cual recibirá eventos como respuestas en tiempo real de los LLM en Amazon Bedrock. La función Lambda SubscribeHandler adjunta al espacio de nombres de mensajes salientes verifica que este usuario esté autorizado para acceder al canal. La aplicación cliente publica un mensaje en el canal de mensajes entrantes, como una pregunta planteada al LLM. La función ChatHandler Lambda recibe el mensaje y verifica que el usuario esté autorizado para publicar mensajes en ese canal. La función ChatHandler llama a la API ConverseStream de Amazon Bedrock y espera a que el flujo de respuesta de la API Converse emita eventos de respuesta. La función ChatHandler transmite los mensajes de respuesta de la API de Converse al canal de mensajes salientes para el usuario actual, que pasa los eventos al WebSocket en el que la aplicación cliente está esperando mensajes.
Los espacios de nombres y canales de AppSync Events son los componentes básicos de su arquitectura de comunicaciones en su AI Gateway. En el ejemplo, los espacios de nombres se utilizan para adjuntar diferentes comportamientos a nuestros mensajes entrantes y salientes. Cada espacio de nombres puede tener una integración de publicación y suscripción diferente para cada espacio de nombres. Además, cada espacio de nombres se divide en canales. Nuestro diseño de estructura de canales proporciona a cada usuario un canal privado de entrada y salida, que sirve como comunicación uno a uno con el lado del servidor:
Mensajes-entrantes / ${sub} Mensajes-salientes / ${sub}
El asunto, o subatributo, llega a nuestras funciones Lambda como contexto desde Amazon Cognito. Es un identificador de usuario único e inmutable dentro de cada grupo de usuarios. Esto lo hace útil para segmentos de los nombres de nuestros canales y es especialmente útil para la autorización.
Autorización
La identidad se establece mediante Amazon Cognito, pero aún necesitamos implementar la autorización. La comunicación uno a uno entre un usuario y un asistente de IA en nuestro ejemplo debe ser privada; no queremos que los usuarios con conocimiento del subatributo de otro usuario puedan suscribirse o publicar en el canal entrante o saliente de otro usuario.
Es por eso que usamos sub en nuestro esquema de nombres para canales. Esto permite que las funciones Lambda adjuntas a los espacios de nombres como fuentes de datos verifiquen que un usuario esté autorizado para publicar y suscribirse.
El siguiente ejemplo de código es nuestra función Lambda SubscribeHandler:
El flujo de trabajo de la función consta de los siguientes pasos:
El nombre del canal llega al evento. El campo de asunto del usuario, sub, es parte del contexto. Si el nombre del canal y la identidad del usuario no coinciden, no autoriza la suscripción y devuelve un mensaje de error. Devolver Ninguno indica que no hay errores y que la suscripción está autorizada.
La función ChatHandler Lambda utiliza la misma lógica para garantizar que los usuarios solo estén autorizados a publicar en su propio canal entrante. El canal llega al evento y el contexto lleva la identidad del usuario.
Aunque nuestro ejemplo es simple, demuestra cómo se pueden implementar reglas de autorización complejas utilizando una función Lambda para autorizar el acceso a canales en AppSync Events. Hemos cubierto el control de acceso a los canales entrantes y salientes de un individuo. Muchos modelos de negocio relacionados con el acceso a los LLM implican controlar cuántos tokens puede usar un individuo dentro de un período de tiempo. Analizamos esta capacidad en la siguiente sección.
Limitación y medición de velocidad
Comprender y controlar la cantidad de tokens consumidos por los usuarios de un AI Gateway es importante para muchos clientes. Los tokens de entrada y salida son el principal mecanismo de fijación de precios para los LLM basados en texto en Amazon Bedrock. En nuestro ejemplo, utilizamos la API de Amazon Bedrock Converse para acceder a los LLM. La API de Converse proporciona una interfaz coherente que funciona con los modelos que admiten mensajes. Puedes escribir código una vez y usarlo con diferentes modelos.
Parte de la interfaz consistente es el evento de metadatos de transmisión. Este evento se emite al final de cada transmisión y proporciona la cantidad de tokens consumidos por la transmisión. El siguiente es un ejemplo de estructura JSON:
Tenemos tokens de entrada, tokens de salida, tokens totales y una métrica de latencia. Para crear un control con estos datos, primero consideramos los tipos de límites que queremos implementar. Un enfoque es un límite de token mensual que se restablece cada mes: una ventana estática. Otro es un límite diario basado en una ventana móvil en intervalos de 10 minutos. Cuando un usuario supera su límite mensual, deberá esperar hasta el mes siguiente. Después de que un usuario excede su límite de ventana móvil diaria, debe esperar 10 minutos para que haya más tokens disponibles.
Necesitamos una forma de mantener contadores atómicos para rastrear el consumo de tokens, con acceso rápido en tiempo real a los contadores con el sub del usuario, y eliminar contadores antiguos a medida que se vuelven irrelevantes.
Amazon DynamoDB es una base de datos NoSQL distribuida, totalmente administrada y sin servidor con un rendimiento de milisegundos de un solo dígito en muchas escalas. Con DynamoDB, podemos mantener contadores atómicos, proporcionar acceso a los contadores codificados por el sub y eliminar datos antiguos utilizando su función de tiempo de vida. El siguiente diagrama muestra un subconjunto de nuestra arquitectura anterior en esta publicación que ahora incluye una tabla de DynamoDB para realizar un seguimiento del uso de tokens.
Podemos usar una única tabla de DynamoDB con las siguientes claves de partición y clasificación:
Clave de partición: user_id (Cadena), el identificador único para el usuario. Clave de clasificación: period_id (Cadena), una clave compuesta que identifica el período de tiempo.
El user_id recibirá el subatributo del JWT proporcionado por Amazon Cognito. period_id tendrá cadenas que se ordenan lexicográficamente y que indican para qué período de tiempo es el contador, así como el período de tiempo. A continuación se muestran algunos ejemplos de claves de clasificación:
10min o mensual indicar el tipo de contador. La marca de tiempo se establece en la última ventana de 10 minutos (por ejemplo, (minuto // 10) * 10).
Con cada registro, mantenemos los siguientes atributos:
input_tokens: contador de tokens de entrada utilizados en esta ventana de 10 minutos. output_tokens: contador de tokens de salida utilizados en esta ventana de 10 minutos. marca de tiempo: marca de tiempo de Unix cuando se creó o se actualizó por última vez el registro ttl: valor de tiempo de vida (marca de tiempo de Unix), establecido en 24 horas desde la creación
Las dos columnas de token se incrementan con la operación ADD atómica de DynamoDB con cada evento de metadatos de la API de Amazon Bedrock Converse. Las columnas ttl y marca de tiempo se actualizan para indicar cuándo el registro se elimina automáticamente de la tabla.
Cuando un usuario envía un mensaje, comprobamos si ha superado sus límites diarios o mensuales.
Para calcular el uso diario, el módulo meter.py completa los siguientes pasos:
Calcula las claves de inicio y finalización para la ventana de 24 horas. Consulta registros con la clave de partición user_id y la clave de clasificación entre las claves de inicio y fin. Resume los valores input_tokens y output_tokens de los registros coincidentes. Compara las sumas con los límites diarios.
Vea el siguiente código de ejemplo:
Esta consulta de rango aprovecha las claves ordenadas naturalmente para recuperar de manera eficiente solo los registros de las últimas 24 horas, sin filtrar el código de la aplicación. El cálculo de uso mensual en la ventana estática es mucho más simple. Para verificar el uso mensual, el sistema completa los siguientes pasos:
Obtiene el registro específico con la clave de partición user_id y la clave de clasificación mensual:AAAA-MM para el mes actual. Compara los valores de input_tokens y output_tokens con los límites mensuales.
Vea el siguiente código:
Con un módulo Python adicional y DynamoDB, tenemos una solución de medición y limitación de velocidad que funciona tanto para ventanas estáticas como móviles.
Acceso a diversos modelos
Nuestro código de muestra utiliza la API de Amazon Bedrock Converse. No todos los modelos están incluidos en el código de muestra, pero sí muchos modelos para que pueda explorar rápidamente las posibilidades. La innovación en esta área no se limita a los modelos en AWS. Existen numerosas formas de desarrollar soluciones de IA generativa en todos los niveles de abstracción. Puede construir sobre la capa que mejor se adapte a su caso de uso.
Swami Sivasubramanian escribió recientemente sobre cómo AWS permite a los clientes ofrecer agentes de IA listos para producción a escala. Habla sobre Strands Agents, un SDK de agentes de IA de código abierto, así como sobre Amazon Bedrock AgentCore, un conjunto integral de servicios de nivel empresarial que ayuda a los desarrolladores a implementar y operar agentes de IA a escala de manera rápida y más segura utilizando un marco y un modelo, alojados en Amazon Bedrock o en otro lugar.
Para obtener más información sobre las arquitecturas para agentes de IA, consulte Strands Agents SDK: una inmersión técnica profunda en las arquitecturas y la observabilidad de los agentes. La publicación analiza el SDK de Strands Agents y sus características principales, cómo se integra con los entornos de AWS para implementaciones más seguras y escalables, y cómo proporciona una rica observabilidad para el uso en producción. También proporciona casos de uso prácticos y un ejemplo paso a paso.
Explotación florestal
Muchas de las partes interesadas de AI Gateway están interesadas en los registros. Los desarrolladores quieren entender cómo funcionan sus aplicaciones. Los ingenieros de sistemas deben comprender las preocupaciones operativas, como el seguimiento de la disponibilidad y la planificación de la capacidad. Los dueños de negocios quieren análisis y tendencias para poder tomar mejores decisiones.
Con Amazon CloudWatch Logs, puede centralizar los registros de sus diferentes sistemas, aplicaciones y servicios de AWS que utiliza en un servicio único y altamente escalable. Luego podrá verlos sin problemas, buscar códigos de error o patrones específicos, filtrarlos según campos específicos o archivarlos de forma segura para análisis futuros. CloudWatch Logs permite ver sus registros, independientemente de su origen, como un flujo único y consistente de eventos ordenados por tiempo.
En la arquitectura de AI Gateway de muestra, CloudWatch Logs se integra en varios niveles para proporcionar una visibilidad integral. El siguiente diagrama de arquitectura muestra los puntos de integración entre AppSync Events, Lambda y CloudWatch Logs en la aplicación de muestra.
Registro de API de eventos de AppSync
Nuestra API de eventos de AppSync está configurada con registro de nivel de ERROR para capturar problemas a nivel de API. Esta configuración ayuda a identificar problemas con solicitudes de API, fallas de autenticación y otros problemas críticos a nivel de API. La configuración de registro se aplica durante la implementación de la infraestructura:
Esto proporciona visibilidad de las operaciones de API.
Registro estructurado de función Lambda
Las funciones Lambda utilizan AWS Lambda Powertools para el registro estructurado. La función ChatHandler Lambda implementa una clase MessageTracker que proporciona contexto para cada conversación:
La información clave registrada incluye:
Identificadores de usuario Identificadores de conversación para seguimiento de solicitudes Identificadores de modelo para rastrear qué modelos de IA se están utilizando Métricas de consumo de tokens (recuentos de entrada y salida) Vistas previas de mensajes Marcas de tiempo detalladas para análisis de series temporales
Cada función Lambda establece un ID de correlación para el seguimiento de solicitudes, lo que facilita el seguimiento de una única solicitud a través del sistema:
Información operativa
CloudWatch Logs Insights permite consultas similares a SQL en datos de registro, lo que le ayuda a realizar las siguientes acciones:
Realice un seguimiento de los patrones de uso de tokens por modelo o usuario Supervise los tiempos de respuesta e identifique cuellos de botella en el rendimiento Detecte patrones de errores y solucione problemas Cree métricas y alarmas personalizadas basadas en datos de registro
Al implementar un registro integral en toda la arquitectura de AI Gateway de muestra, brindamos la visibilidad necesaria para una resolución de problemas efectiva, una optimización del rendimiento y un monitoreo operativo. Esta infraestructura de registro sirve como base tanto para el monitoreo operativo como para las capacidades de análisis que analizamos en la siguiente sección.
Analítica
CloudWatch Logs proporciona visibilidad operativa, pero para extraer inteligencia empresarial de los registros, AWS ofrece muchos servicios de análisis. Con nuestra arquitectura de AI Gateway de muestra, puede utilizar esos servicios para transformar los datos de su AI Gateway sin necesidad de infraestructura dedicada ni canales de datos complejos.
El siguiente diagrama de arquitectura muestra el flujo de datos entre la función Lambda, Amazon Data Firehose, Amazon Simple Storage Service (Amazon S3), AWS Glue Data Catalog y Amazon Athena.
Los componentes clave incluyen:
Data Firehose: la función ChatHandler Lambda transmite datos de registro estructurados a un flujo de entrega de Firehose al final de cada respuesta completa del usuario. Data Firehose proporciona un servicio totalmente administrado que escala automáticamente con su rendimiento de datos, aliviando la necesidad de aprovisionar o administrar infraestructura. El siguiente código ilustra cómo la llamada API que integra la función ChatHandler Lambda con el flujo de entrega:
Amazon S3 con formato Parquet: Firehose convierte automáticamente los datos de registro JSON al formato de columnas Parquet antes de almacenarlos en Amazon S3. Parquet mejora el rendimiento de las consultas y reduce los costos de almacenamiento en comparación con los registros JSON sin formato. Los datos se dividen por año, mes y día, lo que permite realizar consultas eficientes de rangos de tiempo específicos y al mismo tiempo minimizar la cantidad de datos escaneados durante las consultas. Catálogo de datos de AWS Glue: se crea una base de datos y una tabla de AWS Glue en la aplicación AWS Cloud Development Kit (AWS CDK) para definir el esquema de nuestros datos analíticos, incluidos user_id, conversation_id, model_id, recuentos de tokens y marcas de tiempo. Las particiones de tabla se agregan a medida que Data Firehose almacena nuevos objetos S3. Athena para análisis basado en SQL: con la tabla del catálogo de datos, los analistas de negocios pueden utilizar SQL familiar a través de Athena para extraer información. Athena no tiene servidor y su precio por consulta se basa en la cantidad de datos escaneados, lo que la convierte en una solución rentable para un análisis único sin necesidad de infraestructura de base de datos. La siguiente es una consulta de ejemplo:
Este canal de análisis sin servidor transforma los eventos que fluyen a través de AppSync Events en tablas estructuradas y consultables con una sobrecarga operativa mínima. El modelo de precios de pago por uso de estos servicios facilita la rentabilidad y su naturaleza gestionada alivia la necesidad de aprovisionamiento y mantenimiento de infraestructura. Además, con sus datos catalogados en AWS Glue, puede utilizar el conjunto completo de servicios de análisis y aprendizaje automático en AWS, como Amazon Quick Sight y Amazon SageMaker Unified Studio con sus datos.
Escucha
Los eventos de AppSync y las funciones Lambda envían métricas a CloudWatch para que pueda monitorear el rendimiento, solucionar problemas y optimizar sus operaciones de API de AWS AppSync de manera efectiva. Para un AI Gateway, es posible que necesite más información en su sistema de monitoreo para rastrear métricas importantes, como el consumo de tokens de sus modelos.
La aplicación de muestra incluye una llamada a las métricas de CloudWatch para registrar el consumo de tokens y la latencia LLM al final de cada turno de conversación para que los operadores tengan visibilidad de estos datos en tiempo real. Esto permite incluir métricas en paneles y alertas. Además, los datos de las métricas incluyen el identificador del modelo LLM como dimensión para que pueda realizar un seguimiento del consumo de tokens y la latencia por modelo. Las métricas son sólo un componente de lo que podemos aprender sobre nuestra aplicación en tiempo de ejecución con CloudWatch. Debido a que nuestros mensajes de registro tienen formato JSON, podemos realizar análisis de nuestros datos de registro para monitorearlos utilizando CloudWatch Logs Insights. El siguiente diagrama de arquitectura ilustra los registros y métricas que AppSync Events y Lambda ponen a disposición a través de CloudWatch y CloudWatch Logs Insights.
Por ejemplo, la siguiente consulta en los grupos de registro de la aplicación de muestra nos muestra los usuarios con la mayor cantidad de conversaciones dentro de un período de tiempo determinado:
@timestamp y @message son campos estándar para los registros de Lambda. En la línea 3, calculamos la cantidad de identificadores de conversación únicos para cada usuario. Gracias al formato JSON de los mensajes, no necesitamos proporcionar instrucciones de análisis para leer estos campos. El mensaje de registro de mensaje completo se encuentra en paquetes/eventhandlers/eventhandlers/messages.py en la aplicación de muestra.
El siguiente ejemplo de consulta muestra la cantidad de usuarios únicos que utilizan el sistema para una ventana determinada:
Nuevamente, filtramos por Mensaje completo, calculamos estadísticas únicas en el campo user_id de nuestros mensajes JSON y luego emitimos los datos como una serie de tiempo con intervalos de 5 minutos con la función bin.
Almacenamiento en caché (respuestas preparadas)
Muchas puertas de enlace AI proporcionan un mecanismo de caché para los mensajes del asistente. Esto sería apropiado en situaciones en las que un gran número de usuarios hacen exactamente las mismas preguntas y necesitan exactamente las mismas respuestas. Esto podría suponer un ahorro de costes considerable para una aplicación ocupada en la situación adecuada. Un buen candidato para el almacenamiento en caché podría ser el clima. Por ejemplo, con la pregunta "¿Va a llover hoy en Nueva York?", todos deberían ver la misma respuesta. Un mal candidato para el almacenamiento en caché sería aquel en el que el usuario podría preguntar lo mismo pero recibiría a cambio información privada, como "¿Cuántas horas de vacaciones tengo en este momento?" Tenga cuidado de utilizar esta idea de forma segura en su área de trabajo. En el ejemplo se incluye una implementación de caché básica para ayudarle a comenzar con este mecanismo. Los cachés en la IA conversacional requieren mucho cuidado para garantizar que la información no se filtre entre usuarios. Dada la cantidad de contexto que un LLM puede utilizar para adaptar una respuesta, los cachés deben usarse con prudencia.
El siguiente diagrama de arquitectura muestra el uso de DynamoDB como mecanismo de almacenamiento para respuestas preparadas en la aplicación de muestra.
La aplicación de muestra calcula un hash en el mensaje del usuario para consultar una tabla de DynamoDB con mensajes almacenados. Si hay un mensaje disponible para una clave hash, la aplicación devuelve el texto al usuario, las métricas personalizadas registran un acierto en la caché en CloudWatch y se devuelve un evento a AppSync Events para notificar a la aplicación que la respuesta está completa. Esto encapsula completamente el comportamiento de la caché dentro de la estructura de eventos que comprende la aplicación.
Instalar la aplicación de muestra
Consulte el archivo README en GitHub para obtener instrucciones para instalar la aplicación de muestra. Tanto la instalación como la desinstalación se realizan mediante un único comando para implementar o anular la implementación de la aplicación AWS CDK.
Precios de muestra
La siguiente tabla estima los costos mensuales de la aplicación de muestra con un uso ligero en un entorno de desarrollo. El costo real variará según cómo utilice los servicios para su caso de uso.
Se espera que el costo mensual de la aplicación de muestra, suponiendo un uso ligero en el desarrollo, esté entre $35 y $55 por mes.
IU de muestra
Las siguientes capturas de pantalla muestran la interfaz de usuario de muestra. Proporciona una ventana de conversación a la derecha y una barra de navegación a la izquierda. La interfaz de usuario presenta los siguientes componentes clave:
Se muestra una sección de Uso de Token y se actualiza con cada turno de la conversación. La opción Nuevo Chat borra los mensajes de la interfaz de chat para que el usuario pueda iniciar una nueva sesión. El menú desplegable del selector de modelos muestra los modelos disponibles.
La siguiente captura de pantalla muestra la interfaz de chat de la aplicación de muestra.
La siguiente captura de pantalla muestra el menú de selección de modelo.
Conclusión
A medida que evoluciona el panorama de la IA, se necesita una infraestructura que se adapte tan rápidamente como los propios modelos. Al centrar su arquitectura en torno a AppSync Events y los patrones sin servidor que hemos cubierto (incluida la autenticación de identidad basada en Amazon Cognito, la medición impulsada por DynamoDB, la observabilidad de CloudWatch y el análisis de Athena), puede construir una base que crezca con sus necesidades. La aplicación de muestra presentada en esta publicación le brinda un punto de partida que demuestra patrones del mundo real, lo que ayuda a los desarrolladores a explorar la integración de la IA, a los arquitectos a diseñar soluciones empresariales y a los líderes técnicos a evaluar enfoques.
El código fuente completo y las instrucciones de implementación están disponibles en el repositorio de GitHub. Para comenzar, implemente la aplicación de muestra y explore las nueve arquitecturas en acción. Puede personalizar la lógica de autorización para que coincida con los requisitos de su organización y ampliar la selección de modelos para incluir sus modelos preferidos en Amazon Bedrock. Comparta sus ideas sobre la implementación con su organización y deje sus comentarios y preguntas en los comentarios.
Sobre los autores
Archie Cowan es desarrollador senior de prototipos en el equipo de ingeniería en la nube y creación de prototipos de AWS Industries. Se unió a AWS en 2022 y ha desarrollado software para empresas de las industrias de automoción, energía, tecnología y ciencias biológicas. Antes de AWS, dirigió el equipo de arquitectura en ITHAKA, donde hizo contribuciones al motor de búsqueda en jstor.org y aumentó la velocidad de implementación de producción de 12 a 10 000 lanzamientos por año durante su mandato allí. Puede encontrar más escritos suyos sobre temas como la codificación con IA en fnjoin.com y x.com/archiecowan.