[ad_1]
La resiliencia juega un papel fundamental en el desarrollo de cualquier carga de trabajo, y las cargas de trabajo de IA generativa no son diferentes. Se deben tener consideraciones especiales al desarrollar cargas de trabajo de IA generativa desde una perspectiva de resiliencia. Comprender y priorizar la resiliencia es fundamental para que las cargas de trabajo de IA generativas cumplan con los requisitos de disponibilidad organizacional y continuidad del negocio. En esta publicación, analizamos las diferentes pilas de una carga de trabajo de IA generativa y cuáles deberían ser esas consideraciones.
IA generativa de pila completa
Aunque gran parte del entusiasmo en torno a la IA generativa se centra en los modelos, una solución completa requiere personas, habilidades y herramientas de múltiples áreas. Considere la siguiente imagen, que es una vista de AWS de la nueva pila de aplicaciones a16z para modelos de lenguajes 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 incluye:
- Nuevos roles – Debe considerar tanto a los sintonizadores de modelos como a los constructores e integradores de modelos.
- Nuevas herramientas – La pila MLOps tradicional no cubre el tipo de seguimiento de experimentos ni la observabilidad necesaria para que la ingeniería rápida o los agentes llamen a 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 al integrar fuentes de conocimiento externas. A continuación se presentan algunas consideraciones al utilizar RAG:
- Establecer tiempos de espera adecuados es importante para la experiencia del cliente. Nada dice mejor experiencia de usuario que estar en medio de un chat y perder la conexión.
- Asegúrese de validar los datos de entrada de la solicitud y el tamaño de la entrada de la solicitud con los límites de caracteres asignados definidos por su modelo.
- Si realiza ingeniería de avisos, debe almacenar sus avisos en un almacenamiento de datos confiable. Esto protege sus avisos en caso de pérdida accidental o como parte de su estrategia general de recuperación ante desastres.
Canalizaciones de datos
En los casos en los que necesite proporcionar datos de contexto al modelo base 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 canalización podría ser una canalización por lotes si prepara datos de contexto con anticipación, o una canalización de baja latencia si integra nuevos datos de contexto sobre la marcha. En el caso del lote, existen algunos desafíos en comparación con las canalizaciones 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 ingesta de estas fuentes difiere de las fuentes de datos típicas, como los datos de registro en un depósito de Amazon Simple Storage Service (Amazon S3) o los datos estructurados de una base de datos relacional. El nivel de paralelismo que puede lograr puede estar limitado por el sistema fuente, por lo que debe considerar la posibilidad de acelerar y utilizar técnicas de retroceso. Algunos de los sistemas fuente pueden ser vulnerables, por lo que es necesario incorporar el manejo de errores y la lógica de reintento.
El modelo integrado podría ser un cuello de botella en el rendimiento, ya sea que lo ejecute localmente en la canalización o llame 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, debe asignar trabajo según la capacidad de la GPU. Si el modelo se ejecuta externamente, debe asegurarse de no sobrecargar el modelo externo. En ambos casos, el nivel de paralelismo que puede lograr está determinado por el modelo de integración, no por la cantidad de CPU y RAM que tiene disponible en el sistema de procesamiento por lotes.
En el caso de baja latencia, es necesario considerar 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 de vectores tiene dos funciones: almacenar vectores de incrustación y realizar una búsqueda de similitud para encontrar el más cercano. k corresponde a un nuevo vector. Hay tres tipos generales de bases de datos vectoriales:
- Opciones de SaaS dedicadas como Pinecone.
- Capacidades de bases de datos vectoriales integradas con otros servicios. Esto incluye servicios nativos de AWS como Amazon OpenSearch Service y Amazon Aurora.
- Opciones en memoria que se pueden utilizar para datos transitorios en escenarios de baja latencia.
No entraremos en detalle en las funciones de búsqueda de similitudes en este artículo. Aunque son importantes, representan un aspecto funcional del sistema y no afectan directamente la resiliencia. En lugar de ello, nos centraremos en los aspectos de resiliencia de una base de datos vectorial como sistema de almacenamiento:
- latencia – ¿Puede la base de datos vectorial soportar cargas elevadas o impredecibles? De lo contrario, la aplicación que realiza la llamada debe gestionar la limitación de velocidad, la interrupción y los reintentos.
- Escalabilidad – ¿Cuántos vectores puede acomodar el sistema? Si excede la capacidad de la base de datos vectorial, debe buscar fragmentación u otras soluciones.
- Alta disponibilidad y recuperación ante desastres – La incorporación de vectores representa datos valiosos y recrearlos puede resultar costoso. ¿Su base de datos vectorial tiene alta disponibilidad en una única región de AWS? ¿Es posible replicar datos en otra región con fines de recuperación ante desastres?
Nivel de aplicación
Hay tres consideraciones únicas a nivel de aplicación al integrar soluciones de IA generativa:
- Posiblemente alta latencia – Los modelos Foundation a menudo se ejecutan en instancias de GPU grandes y pueden tener una capacidad limitada. Asegúrese de aplicar las mejores prácticas para limitar la velocidad, retroceder y reintentar y deslastrar la carga. Utilice diseños asincrónicos para que la interfaz principal de la aplicación no se vea afectada por una alta latencia.
- Situación de seguridad – Cuando utilice 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 prácticas comunes de acceso con privilegios mínimos, como limitar las indicaciones entrantes de otros sistemas.
- Marcos en rápida evolución – Los marcos de código abierto como LangChain se están desarrollando rápidamente. Utilice 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 empresas construyen sus propios oleoductos. Los requisitos de CPU y memoria son dos de los mayores requisitos al seleccionar instancias para ejecutar sus cargas de trabajo.
Las instancias capaces de soportar 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 ejecute su carga de trabajo, hay diferentes tipos de instancias disponibles.
Para los recorridos críticos de los usuarios, las organizaciones deben considerar reservar o aprovisionar previamente tipos de instancias para garantizar la disponibilidad cuando sea necesario. Este patrón logra una arquitectura estáticamente estable, que es una práctica recomendada para la resiliencia. Para obtener más información sobre la estabilidad estática en el pilar de confiabilidad del marco de buena arquitectura de AWS, consulte Uso de la estabilidad estática para prevenir el comportamiento bimodal.
Observabilidad
Además de las métricas de recursos que normalmente recopila, como la utilización de CPU y RAM, debe monitorear de cerca la utilización de GPU cuando aloja un modelo en Amazon SageMaker o Amazon Elastic Compute Cloud (Amazon EC2). La utilización de la GPU puede cambiar inesperadamente cuando cambian el modelo base o los datos de entrada, y la falta de memoria de la GPU puede poner el sistema en un estado inestable.
Más arriba en la pila, también desea realizar un seguimiento del flujo de llamadas a través del sistema y capturar las interacciones entre los agentes y las 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 detectar nuevos escenarios de falla. Para monitorear el modelo o agente en busca de riesgos y amenazas de seguridad, puede utilizar herramientas como Amazon GuardDuty.
También debe capturar líneas de base para incorporar vectores, indicaciones, contexto y resultados, y las interacciones entre ellos. 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
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 se aplican a su carga de trabajo ayudará a guiar su estrategia. Si utiliza servicios administrados de AWS, como Amazon Bedrock y SageMaker, para su carga de trabajo, asegúrese de que el servicio esté disponible en su región de recuperación de AWS. En este momento, estos servicios de AWS no admiten de forma nativa la replicación de datos entre regiones de AWS. Por lo tanto, debe pensar en sus estrategias de administración de datos para la recuperación ante desastres y quizás también ajustarlas en múltiples regiones de AWS.
Diploma
Este artículo describe cómo se puede tener en cuenta la resiliencia al crear soluciones de IA generativa. Aunque las aplicaciones de IA generativa tienen algunos matices interesantes, los patrones de resiliencia y las mejores prácticas existentes 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 senior de soluciones especialista en resiliencia de AWS con sede en la ciudad de Nueva York. Tiene una formación diversa, ha trabajado en muchas disciplinas técnicas, incluido el desarrollo de software, el liderazgo ágil y DevOps, y es una defensora de las mujeres en la industria de la tecnología. Le gusta ayudar a los clientes a desarrollar soluciones resilientes para mejorar la mentalidad de resiliencia y habla públicamente sobre todos los temas relacionados con la resiliencia.
Randy DeFauw es arquitecto principal de soluciones sénior 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 varios puestos en tecnología, desde desarrollo de software hasta gestión de productos. Entró en el campo del big data en 2013 y continúa explorando esta área. Trabaja activamente en proyectos en el área de ML y ha presentado en numerosas conferencias, incluidas Strata y GlueCon.
[ad_2]