Diseño para apoyar los ciclos de vida del modelo fundacional

Los modelos fundamentales son dependencias con versiones que se usan en la carga de trabajo de IA. Cada modelo de base tiene un ciclo de vida que se debe tener en cuenta. Al igual que las bibliotecas de código y otras dependencias de la carga de trabajo, los modelos de base reciben actualizaciones de versiones secundarias que proporcionan mejoras de rendimiento y optimizaciones. Las actualizaciones de versiones principales presentan cambios sustantivos en las funcionalidades, el rendimiento o la actualización de los datos de entrenamiento. Con el tiempo, los modelos de base podrían quedar obsoletos debido a la obsolescencia o a las preferencias del servidor de su modelo, que están fuera de su control.

Debe diseñar la carga de trabajo con el fin de respaldar los ciclos de vida documentados de los modelos que elija como dependencias. Si no considera los ciclos de vida de los modelos, es posible que realice actualizaciones de riesgo innecesariamente, introduzca cambios de comportamiento no probados, tome tiempo de inactividad innecesario de la carga de trabajo o experimente interrupciones debido a la forma en que la plataforma de hospedaje controla los modelos de fin de ciclo de vida.

Una carga de trabajo diseñada para admitir los ciclos de vida de sus modelos facilita la experimentación y la migración segura a nuevos modelos básicos a medida que se incorporan al mercado.

Tipos de actualizaciones de modelos

El alcance de la actualización del modelo en su solución de IA generativa puede variar drásticamente, desde la revisión menor hasta la selección de una nueva familia de modelos. Hay varias razones por las que puede decidir actualizar el modelo en su solución. En la tabla siguiente se enumeran distintos ámbitos de actualización, junto con un ejemplo y ventajas de realizar esta actualización.

Como se muestra en la tabla, las ventajas de pasar a un nuevo modelo suelen ser una combinación de los siguientes factores:

• Rendimiento, como la velocidad y la latencia

• Capacidad, como el rendimiento medido en transacciones por minuto

• Disponibilidad de cuota

• Rentabilidad

• Disponibilidad regional

• Funcionalidades multimodales

• Conocimientos de aprendizaje actualizados

• Corrección de errores

• Especialización o desespecización para alinearse mejor con el caso de uso

• Evitar interrupciones de carga de trabajo a causa de las políticas de ciclo de vida del modelo

Modelo de comportamiento de jubilación

El comportamiento de retirada de modelos depende de la estrategia de implementación del modelo. Hay tres estrategias clave para implementar modelos. Es importante comprender cómo cada estrategia controla las retiradas de versiones:

• Las soluciones maaS (modelo como servicio) son modelos previamente entrenados expuestos como API que proporcionan escalabilidad y facilidad de integración. Su inconveniente consiste en tener costes potencialmente mayores y un menor control sobre los modelos. Algunos ejemplos de soluciones maaS incluyen modelos implementados en Azure OpenAI en Foundry Models y modelos del catálogo de modelos implementados como API sin servidor.

• Las soluciones MaaP (modelo como plataforma) son modelos implementados y administrados dentro de una plataforma mayor, como los modelos del catálogo de modelos de Azure implementados en computación administrada. Esta solución suele proporcionar un mayor control de los modelos, pero requiere más administración que las soluciones maaS.

• Los modelos de autohospedaje son modelos implementados en su propia infraestructura. Esta implementación proporciona un control máximo sobre los modelos, pero requiere una responsabilidad significativa para la infraestructura, la administración y el mantenimiento.

Tanto las estrategias MaaS como MaaP en modelos de origen de Azure del catálogo de modelos Foundry. Los modelos del catálogo de modelos siguen un ciclo de vida donde los modelos están en desuso y, a continuación, se retiran. Debe planificar estas eventualidades en su carga de trabajo.

Al hospedar localmente modelos o usar computación gestionada, se mantiene el control total y no es necesario actualizar los modelos. Pero es posible que quiera replicar un ciclo de vida del modelo para las ventajas agregadas que un modelo más reciente puede aportar a la carga de trabajo.

Incidencia del cambio en las actualizaciones del modelo

Debe evaluar cómo afecta una actualización de modelo a la carga de trabajo para que pueda planear la transición del modelo anterior al nuevo modelo. La extensión del cambio de carga de trabajo depende de las diferencias funcionales y no funcionales entre los modelos antiguos y nuevos. En el diagrama se muestra una arquitectura de chat simplificada que tiene secciones numeradas que resaltan áreas en las que una actualización de modelo podría tener un efecto.

Para cada una de estas áreas, considere el tiempo de inactividad causado por las actualizaciones y cómo controla las solicitudes que el sistema está procesando. Si hay ventanas de mantenimiento disponibles para la carga de trabajo, use esas ventanas cuando el ámbito de cambio sea grande. Si las ventanas de mantenimiento no están disponibles, solucione los cambios en estas áreas para mantener la funcionalidad de la carga de trabajo y los objetivos de nivel de servicio durante la actualización del modelo.

1. El modelo: El cambio obvio es en el propio modelo. Implemente el nuevo modelo mediante la estrategia de implementación de modelos elegida. Debe evaluar los pros y los contras entre las actualizaciones locales frente a la implementación en paralelo.

   Al pasar a una nueva revisión de modelo desde un modelo finamente ajustado, es necesario ajustar finamente de nuevo la nueva versión del modelo antes de usarla. Cuando actualiza para utilizar un modelo diferente, debe determinar si se requiere algún ajuste fino.

2. La configuración del modelo: Al actualizar el modelo de base en la solución de IA, es posible que tenga que ajustar hiperparámetros o configuraciones para optimizar el rendimiento de la arquitectura y las funcionalidades del nuevo modelo. Por ejemplo, cambiar de un modelo basado en transformador a una red neuronal recurrente podría requerir diferentes velocidades de aprendizaje y tamaños de lote para lograr resultados óptimos.

3. La instrucción: Al cambiar los modelos base en la carga de trabajo, es posible que tenga que ajustar las instrucciones del sistema en los sistemas de orquestación o los agentes para adaptarse a las capacidades y funcionalidades del nuevo modelo.

   Junto con la actualización de la configuración del modelo, la actualización del mensaje es uno de los cambios más comunes al actualizar los modelos. Al evaluar un nuevo modelo, incluso para una actualización de versión secundaria, pruebe los cambios en la instrucción si no satisface sus expectativas. Este enfoque garantiza que solucione los problemas de rendimiento antes de explorar otras modificaciones. Debe encargarse de ajustar la instrucción al pasarse a nuevos modelos. También es probable que tenga que prestar atención a la instrucción cuando realice cambios significativos.

4. La lógica de orquestación: Algunas actualizaciones de modelos, especialmente cuando se aprovechan las nuevas características, requieren que realice cambios en la lógica de orquestación o agente.

   Por ejemplo, si actualiza el modelo a GPT-4 para aprovechar las llamadas a funciones, deberá cambiar la lógica de orquestación. El modelo anterior devolvió un resultado que podría devolver al que hace la llamada. Con las llamadas a funciones, la llamada al modelo devuelve una función a la que debe llamar la lógica de orquestación. En Azure, es habitual implementar la lógica de orquestación en foundry Agent Service o mediante soluciones basadas en código como Microsoft Agent Framework, Kernel semántico o LangChain hospedado en Azure.

5. Datos de base: Es posible que algunas actualizaciones del modelo y cambios de mayor ámbito requieran realizar cambios en los datos de puesta a tierra o ajuste de la precisión o cómo recuperar esos datos.

   Por ejemplo, al pasar de un modelo generalizado a un modelo específico del dominio, como un modelo centrado en finanzas o medicina, es posible que ya no necesite pasar datos de conexión específicos del dominio al modelo. Otro ejemplo es cuando un nuevo modelo puede controlar una ventana de contexto más grande. En este escenario, es posible que quiera recuperar otros fragmentos pertinentes o ajustar el tamaño de los fragmentos. Para obtener más información, consulte Diseño y desarrollo de una solución de generación aumentada por recuperación (RAG).

6. Hardware: En el caso de los modelos que se ejecutan en MaaP, un cambio de modelo podría requerir hardware nuevo. Solo las SKU de proceso específicas son compatibles con los modelos del catálogo. Además, el hardware puede quedar en desuso, lo que requiere que ejecute el modelo en nuevo hardware.

Diseño para cambiar

Es probable que deba actualizar los modelos en sus cargas de trabajo. Si usa la estrategia de implementación maaS en Azure, los modelos se retiran y necesita actualizar a una versión más reciente. También puede optar por cambiar a diferentes modelos o versiones de modelo para aprovechar las nuevas características, reducir los precios o mejorar el rendimiento. En cualquier caso, la arquitectura debe admitir la actualización del modelo que usa la carga de trabajo de IA generativa.

En la sección anterior se trataron las distintas amplitudes de cambios. Debe hacer uso de las operaciones de aprendizaje automático adecuadas (MLOps), las operaciones de datos (DataOps) y las operaciones de inteligencia artificial generativa (GenAIOps) para crear y mantener canalizaciones automatizadas para la optimización del modelo, las instrucciones de los ingenieros, los hiperparámetros de cambio y la lógica de orquestación.

Las actualizaciones de los hiperparámetros y las solicitudes son comunes en la mayoría de las actualizaciones del modelo. Dado que estos cambios son tan comunes, la arquitectura debe admitir un mecanismo de cambio controlado para estas áreas. Una consideración importante es que los avisos y los hiperparámetros están diseñados para versiones de modelo específicas. Debe asegurarse de que las indicaciones e hiperparámetros siempre se usan con el modelo y la versión correctos.

Canalizaciones automatizadas

Implemente canalizaciones automatizadas para probar y evaluar los distintos aspectos de la aplicación de IA generativa:

• MLOps: Siga las instrucciones de Azure MLOps para compilar canalizaciones para ajustar el modelo, si procede.

• GenAIOps: Implemente canalizaciones de GenAIOps para probar y evaluar los cambios en el modelo, los hiperparámetros del modelo, la solicitud y la lógica de orquestación.

• DataOps: Implemente flujos de DataOps para probar y evaluar los cambios en los datos base de RAG.

Debe implementar canalizaciones por los siguientes motivos:

• Para ayudarle en el desarrollo iterativo y la experimentación (bucle interno)
• Para implementar y poner en funcionamiento de forma segura la solución de inteligencia artificial generativa (bucle externo)

Cuando sea posible, use los mismos datos de línea base que usa con la aplicación de producción para probar los cambios en la aplicación de IA generativa. Es posible que este enfoque no sea posible si la aplicación actualizada usa nuevas características del modelo que requieren un cambio en los datos.

Consideraciones sobre la arquitectura

En arquitecturas básicas, como la siguiente arquitectura, el cliente llama directamente al modelo con la versión y configuración correctas del prompt. Si hay cambios en el mensaje, se implementa un nuevo cliente con la nueva indicación, y este llama al nuevo modelo. No es tan complicado vincular la instrucción, la configuración y las versiones del modelo.

Las arquitecturas de producción no son sencillas. Por lo general, se implementa un orquestador o agente cuya responsabilidad es administrar el flujo de las interacciones entre cualquier base de datos de conocimiento y los modelos. La arquitectura también puede implementar una o varias capas de abstracción, como un enrutador o una puerta de enlace:

• Enrutador: Un enrutador dirige el tráfico a diferentes implementaciones de orquestador. Un enrutador es útil en las estrategias de implementación, como las implementaciones azul-verde, donde puede optar por enrutar un porcentaje específico del tráfico a una nueva versión de orquestador como parte de las prácticas de implementación seguras. Este componente también se puede usar para las pruebas A/B o el duplicado de tráfico para evaluar los cambios probados, pero no validados, con el tráfico de producción.

• Puerta de enlace: Es común dar acceso mediante proxy a los modelos de IA por diversas razones. Por ejemplo, puede equilibrar la carga o activar la recuperación ante errores entre varias instancias de backend, implementar autenticación y autorización personalizadas o implementar un sistema de registro y supervisión de los modelos.

Debido a las capas de direccionamiento indirecto implicadas, la arquitectura debe diseñarse para admitir el envío de versiones específicas de mensajes a modelos o versiones de modelos específicos. Por ejemplo, podría tener una instrucción en producción, como prompt1, que está diseñada para un modelo, como model1. Si actualiza a model1.1, es posible que tenga que actualizar prompt1 a prompt2. En este ejemplo, la arquitectura debe usar siempre prompt1 con model1 y prompt2 con model1.1.

Enrutador

En el diagrama siguiente se muestra una arquitectura que usa un enrutador para enrutar las solicitudes a varias implementaciones. Otro ejemplo de esta arquitectura incluye Foundry y usa un punto de conexión en línea administrado como enrutador. Además, las distintas versiones de la solución de orquestación se implementan en el procesamiento gestionado.

El siguiente flujo describe cómo los distintos despliegues de un orquestador invocan el modelo correcto. Cada implementación tiene su propia versión de configuración del modelo y un mensaje:

1. Un usuario emite una solicitud desde una aplicación inteligente y esa solicitud se envía a un enrutador.

2. El enrutador redirige la conexión a la Implementación 1 o a la Implementación 2 de la solución de orquestación, en función de su lógica.

3. Cada despliegue tiene su propia versión del mensaje y la configuración.

4. El orquestador está configurado con el modelo y la versión específicos. Usa esta información para llamar directamente al modelo y la versión adecuados.

5. Dado que la versión específica del indicador se implementa junto con el orquestador configurado con el modelo y la versión específicos, se envía el indicador correcto a la versión correcta del modelo.

Puerta de enlace

En el diagrama siguiente se muestra una arquitectura que usa un enrutador para enrutar las solicitudes a varias implementaciones. Sin embargo, en esta arquitectura, todas las solicitudes de modelo se redirigen a través de una puerta de enlace. Es habitual dar acceso mediante proxy a los modelos de IA por diversos motivos, como el equilibrio de carga, la activación de la recuperación ante errores entre varias instancias de backend en una sola región o varias regiones y la implementación de una unidad de procesamiento aprovisionada con una estrategia de excedente de pago por uso.

En el flujo siguiente se describe cómo las distintas implementaciones de un orquestador llaman al modelo correcto a través de una puerta de enlace. Cada implementación tiene su propia versión de configuración del modelo y un mensaje:

1. Un usuario emite una solicitud desde una aplicación inteligente y esa solicitud se envía a un enrutador.

2. El enrutador dirige el tráfico hacia la implementación 1 o la implementación 2, según su lógica.

3. Cada implementación tiene su propia versión de la instrucción.

4. El orquestador está configurado con el modelo y la versión específicos. Usa esta información para establecer un encabezado HTTP que indique el modelo y la versión correctos a los que se va a llamar.

5. La solución de orquestación llama a la puerta de enlace. La solicitud contiene el encabezado HTTP que indica el nombre y la versión del modelo que se va a usar.

6. La puerta de enlace usa el encabezado HTTP para enrutar la solicitud al modelo y la versión adecuados. También puede aplicar configuraciones definidas en la puerta de enlace.

Externalizar configuración

El patrón de diseño en la nube del Almacén de configuración externo es una buena manera de controlar el almacenamiento de mensajes y la configuración. En algunos contextos de cambios de modelo, es posible que pueda coordinar la implementación del modelo con la instrucción del sistema y los cambios de configuración si estos se almacenan en una ubicación actualizable fuera del código de la solución de orquestación o del agente. Este enfoque no funciona si tiene lógica de orquestación que ajustar, pero resulta útil en muchas actualizaciones de modelos de ámbito más pequeño.

Opción de unidad de procesamiento

Para el hospedaje de MaaP, los modelos suelen limitarse a un subconjunto de recursos de proceso proporcionados por el host. Todas las unidades de procesamiento están sujetas a cuotas, restricciones de disponibilidad y avisos de fin de ciclo de vida. Utiliza los patrones de encaminamiento para admitir la transición al nuevo hardware cuando el hardware actual ya no sea compatible o haya restricciones que impidan la expansión de capacidad adicional.

Un ejemplo de un anuncio de fin de ciclo de vida es el anuncio de la unidad de procesamiento de la serie NC A100 v4. Si hospeda modelos en este hardware, debe realizar la transición a otra SKU compatible que no haya llegado al final de su ciclo de vida y que esté actualmente disponible. Esta transición también podría requerir simultáneamente un cambio de modelo si la nueva SKU no admite el modelo actual.

Recomendaciones

• Agregue capas de abstracción e indirecta para habilitar modificaciones controladas en áreas específicas de la carga de trabajo. Estas áreas incluyen el cliente, la API de aplicación inteligente, la orquestación, el hospedaje de modelos y los conocimientos básicos.

• Todos los cambios en las versiones del modelo, las indicaciones, las configuraciones, la lógica de orquestación y la recuperación de conocimientos de base deben probarse antes de usarlos en producción. Asegúrese de que las combinaciones probadas se anclan juntas en producción, lo que significa que permanecen estrechamente vinculadas cuando se implementan. Las pruebas A/B, el equilibrio de carga y las implementaciones de color azul-verde no deben mezclar componentes para evitar exponer a los usuarios a combinaciones no probadas.

• Pruebe y evalúe las nuevas versiones y los nuevos modelos mediante canalizaciones automatizadas. Debe comparar los resultados con los resultados de la línea base para asegurarse de que obtiene los resultados que necesita.

• Sea intencional al actualizar los modelos. Evite usar características de plataforma que actualicen automáticamente los modelos de producción a nuevas versiones sin la oportunidad de probar. Debe tener en cuenta cómo afecta cada actualización del modelo a la carga de trabajo. Si usa foundry Models API, establezca las implementaciones con una versión específica y no proporcione una directiva de actualización. Esta configuración requiere una actualización manual si se publica una nueva versión. Para Azure OpenAI, establezca implementaciones en Sin actualización automática para desactivar las actualizaciones automáticas.

• Asegúrese de que la solución de observabilidad y registro recopile suficientes metadatos para correlacionar el comportamiento observado con la solución específica de solicitud, configuración, modelo y recuperación de datos implicada. Esta correlación le permite identificar regresiones inesperadas en el rendimiento del sistema.

Resumen

Hay varias razones para actualizar el modelo fundamental en la carga de trabajo generativa. Estos motivos van desde las actualizaciones de versión necesarias cuando los modelos se retiran a la decisión de cambiar a otro modelo. Según el ámbito de la actualización del modelo, es posible que tenga que implementar y evaluar los cambios en el modelo, incluidos los cambios en el símbolo del sistema, la configuración del modelo, la lógica de orquestación o la canalización de datos. Debe seguir las instrucciones de MLOps, DataOps y GenAIOps para crear flujos de trabajo automatizados para los distintos aspectos de la solución. Los flujos de trabajo automatizados permiten probar, evaluar e implementar nuevas versiones. También debe asegurarse de que la arquitectura admite la ejecución de varias versiones de una solución de orquestación donde cada versión vincula su configuración y la versión de la instrucción con una versión de modelo específica.

La arquitectura debe admitir actualizaciones de modelos nuevos o diferentes y los cambios necesarios en la solicitud o configuración del modelo, sin necesidad de modificaciones en la aplicación inteligente o en la experiencia del usuario. Estas actualizaciones deben encapsularse dentro de sus componentes adecuados y las operaciones deben automatizar las pruebas, la evaluación y la implementación de esos cambios.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

• Ritesh Modi | Ingeniero principal de software

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

• Descontinuaciones y retiradas de los modelos de Azure OpenAI

Recursos relacionados

• Arquitectura de referencia de chat de Foundry Baseline
• MLOps
• GenAIOps para profesionales de MLOps