La resiliencia juega un papel fundamental en el desarrollo de cualquier carga de trabajo, y IA generativa Las cargas de trabajo no son diferentes. Existen consideraciones únicas al diseñar cargas de trabajo de IA generativa a través de una lente de resiliencia. Comprender y priorizar la resiliencia es crucial para las cargas de trabajo generativas de IA para cumplir con la disponibilidad organizacional y los requisitos de continuidad del negocio. En esta publicación, discutimos las diferentes pilas de una carga de trabajo generativa de IA y cuáles deberían ser esas consideraciones.
IA generativa de pila completa
Aunque gran parte de la emoción en torno a la IA generativa se centra en los modelos, una solución completa involucra personas, habilidades y herramientas de varios dominios. Considere la siguiente imagen, que es una vista AWS de la pila de aplicaciones emergentes A16Z para modelos de idiomas grandes (LLM).
En comparación con una solución más tradicional basada en IA y aprendizaje automático (ML), una solución de IA generativa ahora implica lo siguiente:
- Nuevos roles – Debe considerar tanto a los sintonizadores de modelos como a los constructores e integradores de modelos.
- Nuevas herramientas – La pila tradicional de MLOps no se extiende para cubrir el tipo de seguimiento de experimentos u observabilidad necesarios para la ingeniería rápida o agentes que invocan herramientas para interactuar con otros sistemas.
Razonamiento del agente
A diferencia de los modelos tradicionales de IA, la recuperación de generación aumentada (RAG) permite respuestas más precisas y contextualmente relevantes mediante la integración de fuentes de conocimiento externas. Las siguientes son algunas consideraciones al usar RAG:
- Establecer tiempos de espera adecuados es importante para la experiencia del cliente. Nada dice una mala experiencia del usuario más que estar en medio de una conversación y desconectarse.
- Asegúrese de validar los datos de entrada de inmediato y el tamaño de entrada de inmediato para los límites de caracteres asignados que definen su modelo.
- Si está realizando ingeniería de avisos, debe conservar sus avisos en un almacén de datos confiable. Eso salvaguardará sus indicaciones en caso de pérdida accidental o como parte de su estrategia general de recuperación de desastres.
Canalizaciones de datos
En los casos en los que necesite proporcionar datos contextuales al modelo básico utilizando el patrón RAG, necesita una canalización de datos que pueda ingerir los datos de origen, convertirlos en vectores de incrustación y almacenar los vectores de incrustación en una base de datos de vectores. Esta tubería podría ser una tubería por lotes si prepara datos contextuales por adelantado, o una tubería de baja latencia si incorpora nuevos datos contextuales sobre la mosca. En el caso por lotes, hay un par de desafíos en comparación con las tuberías de datos típicas.
Las fuentes de datos pueden ser documentos PDF en un sistema de archivos, datos de un sistema de software como servicio (SaaS), como una herramienta CRM, o datos de una wiki o base de conocimientos existente. La ingestión de estas fuentes es diferente de las fuentes de datos típicas como los datos de registro en un Servicio de almacenamiento simple de Amazon (Amazon S3) o datos estructurados de una base de datos relacional. El nivel de paralelismo que puede lograr puede estar limitado por el sistema de origen, por lo que debe tener en cuenta las técnicas de retroceso y usar. Algunos de los sistemas de origen pueden ser frágiles, por lo que debe construir un manejo de errores y volver a intentar la lógica.
El modelo integrado podría ser un cuello de botella en el rendimiento, independientemente de si lo ejecuta localmente en la canalización o llama a un modelo externo. Los modelos integrados son modelos básicos que se ejecutan en GPU y no tienen capacidad ilimitada. Si el modelo se ejecuta localmente, deberá asignar el trabajo según la capacidad de la GPU. Si el modelo se ejecuta externamente, debe asegurarse de no saturar el modelo externo. En cualquier caso, el nivel de paralelismo que puede lograr será dictado por el modelo de incrustación en lugar de la cantidad de CPU y RAM que tiene disponibles en el sistema de procesamiento por lotes.
En el caso de baja latencia, debe tener en cuenta el tiempo que lleva generar los vectores de incrustación. La aplicación que llama debe invocar la canalización de forma asincrónica.
Bases de datos vectoriales
Una base de datos vectorial tiene dos funciones: almacenar vectores de incrustación y ejecutar una búsqueda de similitud para encontrar la más cercana k coincide con un nuevo vector. Hay tres tipos generales de bases de datos vectoriales:
- Opciones de SaaS dedicadas como Pinecone.
- Las características de la base de datos vectorial integradas en otros servicios. Esto incluye servicios nativos de AWS como Servicio de búsqueda abierta de Amazon y auroras amazónicas.
- Opciones en memoria que se pueden usar para datos transitorios en escenarios de baja latencia.
No cubrimos las capacidades de búsqueda de similitudes en detalle en esta publicación. Aunque son importantes, son un aspecto funcional del sistema y no afectan directamente la resiliencia. En cambio, nos centramos en los aspectos de resiliencia de una base de datos vectorial como sistema de almacenamiento:
- Latencia – ¿Puede la base de datos de vector funcionar bien con una carga alta o impredecible? Si no, la aplicación de llamadas debe manejar la limitación de la tasa y el retroceso y volver a intentarlo.
- Escalabilidad – ¿Cuántos vectores puede contener el sistema? Si excede la capacidad de la base de datos vectorial, deberá buscar fragmentación u otras soluciones.
- Alta disponibilidad y recuperación ante desastres – La incrustación de vectores son datos valiosos, y recrearlos puede ser costoso. ¿Está su base de datos vectorial altamente disponible en una sola región de AWS? ¿Tiene la capacidad de replicar datos a otra región para fines de recuperación ante desastres?
Nivel de aplicación
Hay tres consideraciones únicas para el nivel de aplicación al integrar soluciones de IA generativa:
- Latencia potencialmente alta – Los modelos Foundation a menudo se ejecutan en instancias de GPU grandes y pueden tener una capacidad finita. Asegúrese de utilizar las mejores prácticas para limitar la velocidad, retroceder y reintentar y deslastrar la carga. Utilice diseños asincrónicos para que la alta latencia no interfiera con la interfaz principal de la aplicación.
- Postura de seguridad – Si utiliza agentes, herramientas, complementos u otros métodos para conectar un modelo a otros sistemas, preste especial atención a su postura de seguridad. Los modelos pueden intentar interactuar con estos sistemas de formas inesperadas. Siga la práctica normal de acceso con privilegios mínimos, por ejemplo, restringiendo las indicaciones entrantes de otros sistemas.
- Marcos en rápida evolución – Los marcos de código abierto como LangChain están evolucionando rápidamente. Use un enfoque de microservicios para aislar otros componentes de estos marcos menos maduros.
Capacidad
Podemos pensar en la capacidad en dos contextos: inferencia y canales de datos de modelos de entrenamiento. La capacidad es una consideración cuando las organizaciones están construyendo sus propios canales. Los requisitos de CPU y memoria son dos de los mayores requisitos al elegir instancias para ejecutar sus cargas de trabajo.
Las instancias que pueden admitir cargas de trabajo de IA generativa pueden ser más difíciles de obtener que el tipo de instancia promedio de uso general. La flexibilidad de instancias puede ayudar con la capacidad y la planificación de la capacidad. Dependiendo de la región de AWS en la que esté ejecutando su carga de trabajo, hay diferentes tipos de instancias disponibles.
Para los recorridos de los usuarios que son críticos, las organizaciones querrán considerar reservar o aprovisionar previamente tipos de instancias para garantizar la disponibilidad cuando sea necesario. Este patrón logra una arquitectura estable estáticamente, que es una mejor práctica de resistencia. Para obtener más información sobre la estabilidad estática en el pilar de confiabilidad del marco bien arquitectado de AWS, consulte Utilice la estabilidad estática para evitar el comportamiento bimodal.
Observabilidad
Además de las métricas de recursos que generalmente recopila, como la utilización de CPU y RAM, debe monitorear de cerca la utilización de GPU si aloja un modelo en Amazon SageMaker o Nube informática elástica de Amazon (Amazon EC2). La utilización de la GPU puede cambiar inesperadamente si el modelo base o los datos de entrada cambian, y quedarse sin memoria de la GPU puede poner el sistema en un estado inestable.
Más arriba en la pila, también querrás rastrear el flujo de llamadas a través del sistema, capturando las interacciones entre agentes y herramientas. Debido a que la interfaz entre agentes y herramientas está definida de manera menos formal que un contrato de API, debe monitorear estos seguimientos no solo para verificar el rendimiento sino también para capturar nuevos escenarios de error. Para monitorear el modelo o agente en busca de riesgos y amenazas de seguridad, puede usar herramientas como Servicio de guardia del Amazonas.
También debe capturar líneas de base de vectores de incorporación, indicaciones, contexto y resultados, y las interacciones entre estos. Si estos cambian con el tiempo, puede indicar que los usuarios están usando el sistema de nuevas maneras, que los datos de referencia no cubren el espacio de preguntas de la misma manera o que el resultado del modelo es repentinamente diferente.
Recuperación de desastres
Tener un plan de continuidad del negocio con una estrategia de recuperación ante desastres es imprescindible para cualquier carga de trabajo. Las cargas de trabajo de IA generativa no son diferentes. Comprender los modos de falla que son aplicables a su carga de trabajo ayudará a guiar su estrategia. Si utiliza servicios administrados de AWS para su carga de trabajo, como Roca Amazónica Y Sagemaker, asegúrese de que el servicio esté disponible en su región de recuperación AWS. Al momento de escribir este artículo, estos servicios de AWS no admiten la replicación de datos entre regiones de AWS de forma nativa, por lo que debe pensar en sus estrategias de administración de datos para la recuperación ante desastres y es posible que también deba realizar ajustes en varias regiones de AWS.
Conclusión
Esta publicación describió cómo tener en cuenta la resiliencia al construir soluciones generativas de IA. Aunque las aplicaciones generativas de IA tienen algunos matices interesantes, los patrones de resiliencia existentes y las mejores prácticas aún se aplican. Es sólo cuestión de evaluar cada parte de una aplicación de IA generativa y aplicar las mejores prácticas pertinentes.
Para obtener más información sobre la IA generativa y su uso con los servicios de AWS, consulte los siguientes recursos:
Sobre los autores
Jennifer Morán es un arquitecto de soluciones especialistas en resiliencia de AWS con sede en la ciudad de Nueva York. Tiene una experiencia diversa, que ha trabajado en muchas disciplinas técnicas, que incluyen desarrollo de software, liderazgo ágil y DevOps, y es un defensor de las mujeres en tecnología. Le gusta ayudar a los clientes a diseñar soluciones resilientes para mejorar la postura de resiliencia y habla públicamente sobre todos los temas relacionados con la resiliencia.
Randy DeFauw es un arquitecto principal de soluciones principales en AWS. Tiene un MSEE de la Universidad de Michigan, donde trabajó en visión por computadora para vehículos autónomos. También tiene un MBA de la Universidad Estatal de Colorado. Randy ha ocupado diversos puestos en el ámbito tecnológico, desde ingeniería de software hasta gestión de productos. Entró en el espacio del big data en 2013 y continúa explorando esa área. Trabaja activamente en proyectos en el espacio ML y ha presentado en numerosas conferencias, incluidas Strata y GlueCon.