FMOps/LLMOps Operacionalizar la IA generativa y las diferencias con MLOps

FMOps/LLMOps Operacionalizar la IA generativa y diferencias con MLOps

Hoy en día, la mayoría de nuestros clientes están entusiasmados con los modelos de lenguaje grandes (LLMs, por sus siglas en inglés) y están pensando en cómo la inteligencia artificial generativa podría transformar su negocio. Sin embargo, llevar estas soluciones y modelos a las operaciones habituales del negocio no es una tarea fácil. En esta publicación, discutiremos cómo operacionalizar aplicaciones de inteligencia artificial generativa utilizando los principios de MLOps que conducen a las operaciones de modelos de base (FMOps, por sus siglas en inglés). Además, nos adentraremos en el caso de uso más común de inteligencia artificial generativa en aplicaciones de texto a texto y en las operaciones de LLM (LLMOps), un subconjunto de FMOps. La siguiente figura ilustra los temas que discutimos.

Específicamente, presentamos brevemente los principios de MLOps y nos centramos en las principales diferencias en comparación con FMOps y LLMOps en cuanto a procesos, personas, selección y evaluación de modelos, privacidad de datos e implementación de modelos. Esto se aplica a los clientes que los utilizan tal cual, crean modelos de base desde cero o los ajustan. Nuestro enfoque se aplica tanto a modelos de código abierto como a modelos propietarios por igual.

Resumen de la operacionalización de ML

Según se define en la publicación “Hoja de ruta de base de MLOps para empresas con Amazon SageMaker”, MLOps (Machine Learning Operations) es la combinación de personas, procesos y tecnología para llevar soluciones de aprendizaje automático (ML) a producción de manera eficiente. Para lograr esto, se necesita una combinación de equipos y roles que colaboren, como se ilustra en la siguiente figura.

Estos equipos son los siguientes:

  • Equipo de análisis avanzado (lago de datos y malla de datos): Los ingenieros de datos son responsables de preparar e ingresar datos de múltiples fuentes, construir canalizaciones ETL (extracción, transformación y carga) para curar y catalogar los datos, y preparar los datos históricos necesarios para los casos de uso de ML. Estos propietarios de datos se centran en proporcionar acceso a sus datos a múltiples unidades de negocio o equipos.
  • Equipo de ciencia de datos: Los científicos de datos deben centrarse en crear el mejor modelo basado en indicadores clave de rendimiento (KPI) predefinidos, trabajando en cuadernos. Después de completar la fase de investigación, los científicos de datos deben colaborar con los ingenieros de ML para crear automatizaciones para construir (canalizaciones de ML) e implementar modelos en producción utilizando canalizaciones de CI/CD.
  • Equipo de negocios: Un propietario de producto es responsable de definir el caso de negocio, los requisitos y los KPI que se utilizarán para evaluar el rendimiento del modelo. Los consumidores de ML son otros interesados ​​en el negocio que utilizan los resultados de inferencia (predicciones) para tomar decisiones.
  • Equipo de plataforma: Los arquitectos son responsables de la arquitectura general de la nube del negocio y de cómo se conectan todos los diferentes servicios. Los expertos en seguridad revisan la arquitectura según las políticas y necesidades de seguridad del negocio. Los ingenieros de MLOps son responsables de proporcionar un entorno seguro para que los científicos de datos e ingenieros de ML pongan en producción los casos de uso de ML. Específicamente, son responsables de estandarizar las canalizaciones de CI/CD, los roles de usuario y servicio, la creación de contenedores, el consumo de modelos, las pruebas y la metodología de implementación en función de los requisitos del negocio y de seguridad.
  • Equipo de riesgo y cumplimiento: Para entornos más restrictivos, los auditores son responsables de evaluar los datos, el código y los artefactos del modelo y asegurarse de que el negocio cumpla con las regulaciones, como la privacidad de los datos.

Tenga en cuenta que una misma persona puede desempeñar varios roles según la escala y la madurez de MLOps del negocio.

Estas personas necesitan entornos dedicados para realizar los diferentes procesos, como se ilustra en la siguiente figura.

Los entornos son los siguientes:

  • Administración de la plataforma: El entorno de administración de la plataforma es el lugar donde el equipo de la plataforma tiene acceso para crear cuentas de AWS y vincular los usuarios y los datos adecuados
  • Datos: La capa de datos, a menudo conocida como lago de datos o malla de datos, es el entorno que los ingenieros u propietarios de datos y los interesados ​​en el negocio utilizan para preparar, interactuar y visualizar los datos
  • Experimentación: Los científicos de datos utilizan un entorno de pruebas o experimentación para probar nuevas bibliotecas y técnicas de ML para demostrar que su prueba de concepto puede resolver problemas comerciales
  • Construcción de modelos, prueba de modelos, implementación de modelos: El entorno de construcción, prueba e implementación de modelos es la capa de MLOps, donde los científicos de datos e ingenieros de ML colaboran para automatizar y llevar la investigación a la producción
  • Gobernanza de ML: La última pieza del rompecabezas es el entorno de gobernanza de ML, donde se almacenan, revisan y auditan todos los artefactos de modelo y código por las personas correspondientes

El siguiente diagrama ilustra la arquitectura de referencia, que ya se ha discutido en la hoja de ruta de fundamentos de MLOps para empresas con Amazon SageMaker.

Cada unidad de negocio tiene su propio conjunto de cuentas de desarrollo (entrenamiento y construcción automatizados de modelos), preproducción (pruebas automáticas) y producción (implementación y servicio de modelos) para poner en producción casos de uso de ML, que recuperan datos de un lago de datos centralizado o descentralizado, respectivamente. Todos los modelos y la automatización del código producidos se almacenan en una cuenta de herramientas centralizada utilizando la capacidad de un registro de modelos. El código de infraestructura de todas estas cuentas se versiona en una cuenta de servicio compartido (cuenta de gobernanza de análisis avanzado) que el equipo de plataforma puede abstraer, plantillar, mantener y reutilizar para la incorporación de cada nuevo equipo a la plataforma MLOps.

Definiciones de IA generativa y diferencias con MLOps

En el aprendizaje automático clásico, la combinación previa de personas, procesos y tecnología puede ayudarlo a comercializar sus casos de uso de aprendizaje automático. Sin embargo, en la IA generativa, la naturaleza de los casos de uso requiere una ampliación de esas capacidades o nuevas capacidades. Una de estas nuevas nociones es el modelo base (FM, por sus siglas en inglés). Se les llama así porque se pueden usar para crear una amplia gama de otros modelos de IA, como se ilustra en la siguiente figura.

Los FM se han entrenado en función de terabytes de datos y tienen cientos de miles de millones de parámetros para poder predecir la mejor respuesta siguiente en tres categorías principales de casos de uso de IA generativa:

  • Texto a texto – Los FM (LLM, por sus siglas en inglés) se han entrenado en función de datos no etiquetados (como texto libre) y son capaces de predecir la mejor palabra siguiente o secuencia de palabras (párrafos o ensayos largos). Los casos de uso principales están relacionados con chatbots similares a humanos, resúmenes u otras creaciones de contenido como código de programación.
  • Texto a imagen – Se ha utilizado datos etiquetados, como pares de <texto, imagen>, para entrenar los FM, que son capaces de predecir la mejor combinación de píxeles. Ejemplos de casos de uso son la generación de diseños de ropa o imágenes personalizadas imaginarias.
  • Texto a audio o video – Tanto los datos etiquetados como los no etiquetados se pueden utilizar para el entrenamiento de FM. Un ejemplo principal de caso de uso de IA generativa es la composición musical.

Para poner en producción esos casos de uso de IA generativa, necesitamos tomar prestado y ampliar el dominio de MLOps para incluir lo siguiente:

  • Operaciones de FM (FMOps) – Esto puede poner en producción soluciones de IA generativa, incluyendo cualquier tipo de caso de uso
  • Operaciones de LLM (LLMOps) – Esto es un subconjunto de FMOps que se centra en poner en producción soluciones basadas en LLM, como el texto a texto

La siguiente figura ilustra la superposición de estos casos de uso.

En comparación con el aprendizaje automático clásico y MLOps, FMOps y LLMOps difieren en cuatro categorías principales que cubrimos en las siguientes secciones: personas y procesos, selección y adaptación de FM, evaluación y monitoreo de FM, privacidad de datos e implementación de modelos, y necesidades tecnológicas. Cubriremos el monitoreo en una publicación separada.

Viaje de operacionalización por tipo de usuario de IA generativa

Para simplificar la descripción de los procesos, debemos categorizar los principales tipos de usuarios de IA generativa, como se muestra en la siguiente figura.

Los tipos de usuarios son los siguientes:

  • Proveedores – Usuarios que construyen FMs desde cero y los ofrecen como producto a otros usuarios (ajustadores y consumidores). Tienen profundos conocimientos de aprendizaje automático (ML) de extremo a extremo y procesamiento del lenguaje natural (NLP), habilidades en ciencia de datos y equipos masivos de etiquetadores y editores de datos.
  • Ajustadores – Usuarios que reentrenan (ajustan) FMs de proveedores para adaptarlos a requisitos personalizados. Orquestan la implementación del modelo como un servicio para su uso por parte de los consumidores. Estos usuarios necesitan un sólido conocimiento de ML de extremo a extremo y ciencia de datos, así como conocimiento de implementación e inferencia de modelos. También se requiere un sólido conocimiento del dominio para el ajuste, incluida la ingeniería de las instrucciones.
  • Consumidores – Usuarios que interactúan con servicios de IA generativa de proveedores o ajustadores mediante instrucciones de texto o una interfaz visual para completar acciones deseadas. No se requiere experiencia en ML, pero principalmente son desarrolladores de aplicaciones o usuarios finales con conocimiento de las capacidades del servicio. Solo se necesita la ingeniería de las instrucciones para obtener mejores resultados.

Según la definición y la experiencia en ML requerida, MLOps se necesita principalmente para proveedores y ajustadores, mientras que los consumidores pueden utilizar principios de producción de aplicaciones, como DevOps y AppDev, para crear aplicaciones de IA generativa. Además, hemos observado un movimiento entre los tipos de usuarios, donde los proveedores pueden convertirse en ajustadores para respaldar casos de uso basados en un sector específico (como el sector financiero) o los consumidores pueden convertirse en ajustadores para obtener resultados más precisos. Pero observemos los principales procesos por tipo de usuario.

El recorrido de los consumidores

La siguiente figura ilustra el recorrido de los consumidores.

Como se mencionó anteriormente, los consumidores deben seleccionar, probar y utilizar un FM, interactuando con él al proporcionar entradas específicas, también conocidas como instrucciones. Las instrucciones, en el contexto de la programación informática e IA, se refieren a la entrada que se proporciona a un modelo o sistema para generar una respuesta. Esto puede ser en forma de texto, comando o pregunta, que el sistema utiliza para procesar y generar una salida. La salida generada por el FM puede ser utilizada por los usuarios finales, quienes también deben ser capaces de calificar estas salidas para mejorar las respuestas futuras del modelo.

Más allá de estos procesos fundamentales, hemos observado que los consumidores expresan el deseo de ajustar un modelo aprovechando la funcionalidad ofrecida por los ajustadores. Por ejemplo, consideremos un sitio web que genera imágenes. Aquí, los usuarios finales pueden configurar cuentas privadas, cargar fotos personales y posteriormente generar contenido relacionado con esas imágenes (por ejemplo, generar una imagen que represente al usuario final en una motocicleta empuñando una espada o ubicado en un lugar exótico). En este escenario, la aplicación de IA generativa, diseñada por el consumidor, debe interactuar con la infraestructura del ajustador a través de APIs para ofrecer esta funcionalidad a los usuarios finales.

Sin embargo, antes de adentrarnos en eso, concentremos nuestra atención en el recorrido de selección, prueba, uso, interacción de entrada y salida, y calificación del modelo, como se muestra en la siguiente figura.

*15K referencia de FM disponibles

Paso 1. Comprender las principales capacidades de los FM

Hay muchas dimensiones que deben tenerse en cuenta al seleccionar modelos base, dependiendo del caso de uso, los datos disponibles, las regulaciones, etc. Una buena lista de verificación, aunque no exhaustiva, podría ser la siguiente:

  • FM propietario o de código abierto – Los modelos propietarios a menudo tienen un costo financiero, pero suelen ofrecer un mejor rendimiento (en términos de calidad del texto o imagen generado), ya que suelen ser desarrollados y mantenidos por equipos dedicados de proveedores de modelos que garantizan un rendimiento y confiabilidad óptimos. Por otro lado, también vemos la adopción de modelos de código abierto que, además de ser gratuitos, ofrecen beneficios adicionales al ser accesibles y flexibles (por ejemplo, todo modelo de código abierto es ajustable). Un ejemplo de un modelo propietario es el modelo Claude de Anthropic, y un ejemplo de un modelo de código abierto de alto rendimiento es Falcon-40B, a partir de julio de 2023.
  • Licencia comercial – Las consideraciones de licencia son cruciales al decidir sobre un FM. Es importante tener en cuenta que algunos modelos son de código abierto pero no se pueden utilizar con fines comerciales debido a restricciones o condiciones de licencia. Las diferencias pueden ser sutiles: el modelo xgen-7b-8k-base recién lanzado, por ejemplo, es de código abierto y utilizable comercialmente (licencia Apache-2.0), mientras que la versión finamente ajustada del modelo xgen-7b-8k-inst solo se publica con fines de investigación. Al seleccionar un FM para una aplicación comercial, es esencial verificar el acuerdo de licencia, comprender sus limitaciones y asegurarse de que se ajuste al uso previsto del proyecto.
  • Parámetros – El número de parámetros, que consiste en los pesos y sesgos de la red neuronal, es otro factor clave. Más parámetros generalmente significa un modelo más complejo y potencialmente poderoso, ya que puede capturar patrones y correlaciones más intrincados en los datos. Sin embargo, el compromiso es que requiere más recursos computacionales y, por lo tanto, cuesta más ejecutarlo. Además, observamos una tendencia hacia modelos más pequeños, especialmente en el espacio de código abierto (modelos que van desde 7 a 40 mil millones) que funcionan bien, especialmente cuando se ajustan finamente.
  • Velocidad – La velocidad de un modelo se ve influenciada por su tamaño. Los modelos más grandes tienden a procesar los datos más lentamente (mayor latencia) debido a la mayor complejidad computacional. Por lo tanto, es crucial equilibrar la necesidad de un modelo con alta capacidad predictiva (a menudo modelos más grandes) con los requisitos prácticos de velocidad, especialmente en aplicaciones como chatbots que requieren respuestas en tiempo real o casi en tiempo real.
  • Tamaño de la ventana de contexto (número de tokens) – La ventana de contexto, definida por el número máximo de tokens que se pueden ingresar o generar por instrucción, es crucial para determinar cuánto contexto puede considerar el modelo a la vez (un token se traduce aproximadamente en 0.75 palabras en inglés). Los modelos con ventanas de contexto más grandes pueden comprender y generar secuencias de texto más largas, lo cual puede ser útil para tareas que implican conversaciones o documentos más extensos.
  • Conjunto de datos de entrenamiento – También es importante comprender qué tipo de datos se utilizó para entrenar el FM. Algunos modelos pueden entrenarse con conjuntos de datos de texto diversos, como datos de Internet, scripts de programación, instrucciones o comentarios humanos. Otros también pueden entrenarse con conjuntos de datos multimodales, como combinaciones de datos de texto e imágenes. Esto puede influir en la idoneidad del modelo para diferentes tareas. Además, una organización puede tener preocupaciones de derechos de autor en función de las fuentes exactas en las que se haya entrenado un modelo, por lo que es obligatorio inspeccionar de cerca el conjunto de datos de entrenamiento.
  • Calidad – La calidad de un FM puede variar según su tipo (propietario vs. de código abierto), tamaño y en qué se entrenó. La calidad es contextual, lo que significa que lo que se considera alta calidad para una

    A continuación se muestra un ejemplo de dos listas cortas, una para modelos propietarios y otra para modelos de código abierto. Es posible que compile tablas similares en función de sus necesidades específicas para obtener una visión general rápida de las opciones disponibles. Tenga en cuenta que el rendimiento y los parámetros de esos modelos cambian rápidamente y podrían estar desactualizados al momento de la lectura, mientras que otras capacidades podrían ser importantes para clientes específicos, como el idioma compatible.

    A continuación se muestra un ejemplo de FMs propietarios destacados disponibles en AWS (julio de 2023).

    A continuación se muestra un ejemplo de FMs de código abierto destacados disponibles en AWS (julio de 2023).

    Después de haber compilado una visión general de 10 a 20 modelos candidatos potenciales, se vuelve necesario refinar aún más esta lista corta. En esta sección, proponemos un mecanismo rápido que arrojará dos o tres modelos finales viables como candidatos para la próxima etapa.

    El siguiente diagrama ilustra el proceso de selección inicial.

    Por lo general, los ingenieros de instrucciones, que son expertos en crear instrucciones de alta calidad que permiten a los modelos de IA comprender y procesar las entradas de los usuarios, experimentan con varios métodos para realizar la misma tarea (como la sumarización) en un modelo. Sugerimos que estas instrucciones no se creen sobre la marcha, sino que se extraigan sistemáticamente de un catálogo de instrucciones. Este catálogo de instrucciones es un lugar central para almacenar instrucciones y evitar duplicaciones, permitir el control de versiones y compartir instrucciones dentro del equipo para garantizar la coherencia entre diferentes probadores de instrucciones en las diferentes etapas de desarrollo, que presentamos en la siguiente sección. Este catálogo de instrucciones es análogo a un repositorio Git de un almacén de características. Luego, el desarrollador de IA generativa, que potencialmente podría ser la misma persona que el ingeniero de instrucciones, debe evaluar la salida para determinar si sería adecuada para la aplicación de IA generativa que están buscando desarrollar.

    Paso 2. Probar y evaluar la FM principal

    Después de reducir la lista corta a aproximadamente tres FMs, recomendamos realizar una etapa de evaluación para probar aún más las capacidades de las FMs y su idoneidad para el caso de uso. Dependiendo de la disponibilidad y naturaleza de los datos de evaluación, sugerimos diferentes métodos, como se ilustra en la siguiente figura.

    El método a utilizar primero depende de si tiene datos de prueba etiquetados o no.

    Si tiene datos etiquetados, puede utilizarlos para realizar una evaluación del modelo, como lo hacemos con los modelos de aprendizaje automático tradicionales (ingrese algunas muestras y compare la salida con las etiquetas). Dependiendo de si los datos de prueba tienen etiquetas discretas (como análisis de sentimiento positivo, negativo o neutral) o son texto no estructurado (como sumarización), proponemos diferentes métodos de evaluación:

    • Métricas de precisión: en caso de salidas discretas (como análisis de sentimientos), podemos utilizar métricas de precisión estándar como precisión, recuperación y puntuación F1
    • Métricas de similitud: si la salida es no estructurada (como un resumen), sugerimos métricas de similitud como ROUGE y similitud de coseno

    Algunos casos de uso no se prestan a tener una única respuesta verdadera (por ejemplo, “Crear una breve historia para niños para mi hija de 5 años”). En tales casos, se vuelve más difícil evaluar los modelos porque no tiene datos de prueba etiquetados. Proponemos dos enfoques, según la importancia de la revisión humana del modelo versus la evaluación automatizada:

    • Human-in-the-Loop (HIL): en este caso, un equipo de probadores de instrucciones revisará las respuestas de un modelo. Dependiendo de la importancia de la aplicación, los probadores de instrucciones pueden revisar el 100% de las salidas del modelo o solo una muestra.
    • Evaluación impulsada por LLM: en este escenario, los probadores de instrucciones son reemplazados por un LLM, idealmente uno que sea más potente (aunque tal vez más lento y costoso) que los que se están probando. El LLM revisará todas las respuestas generadas por el modelo y las calificará. Este método puede resultar en una calidad inferior, pero es una opción de evaluación más económica y rápida que puede proporcionar una buena medida inicial del rendimiento de los modelos.

    Por ejemplo, podemos usar la siguiente indicación de ejemplo para un LLM, que incluye la consulta de entrada, la respuesta del LLM y las instrucciones: “Nos gustaría solicitar su opinión sobre el desempeño de un asistente de IA en respuesta a la pregunta del usuario mostrada arriba. Por favor, califique la utilidad, relevancia, precisión y nivel de detalle de la respuesta del asistente. El asistente recibirá una puntuación general en una escala del 1 al 10, donde una puntuación más alta indica un mejor rendimiento general”.

    Esta indicación se enviará a otro LLM (el EvalLLM) para su evaluación. El siguiente es un ejemplo donde la respuesta del modelo Falcon-40B ha sido evaluada por un EvalLLM (en este caso Claude). Utilizamos la pregunta “¿Qué pasaría si el Canal de Suez nunca hubiera sido construido?”. La respuesta es la siguiente:

    Pregunta: ¿Qué pasaría si el Canal de Suez nunca hubiera sido construido?

    falcon-40b-instruct

    Si el Canal de Suez nunca hubiera sido construido, los barcos tendrían que viajar alrededor de África para navegar entre el Mediterráneo y el Mar Rojo. Esto agregaría tiempo y distancia significativos al viaje, haciéndolo menos eficiente y más costoso. Además, sin el Canal de Suez, muchos países de Oriente Medio y África del Norte estarían mucho menos conectados con el resto del mundo, dificultando el desarrollo económico y cultural.

    Revisión (Puntuación: 9/10)

    La respuesta del asistente es altamente relevante, precisa y detallada. Proporciona una excelente respuesta a la pregunta hipotética del usuario sobre la no existencia del Canal de Suez. El asistente señala correctamente las implicaciones en los viajes marítimos y el impacto económico y cultural en Oriente Medio y África del Norte. Sin embargo, podría haber profundizado en las implicaciones geopolíticas o en el impacto en los patrones de comercio global para obtener una respuesta más completa.

    La siguiente figura ilustra el ejemplo del proceso de evaluación de principio a fin.

    Basándonos en este ejemplo, para realizar la evaluación, debemos proporcionar las indicaciones de ejemplo, que almacenamos en el catálogo de indicaciones, y un conjunto de datos de evaluación etiquetados o no etiquetados basados en nuestras aplicaciones específicas. Por ejemplo, con un conjunto de datos de evaluación etiquetados, podemos proporcionar indicaciones (entrada y consulta) como “Dame el nombre completo del Primer Ministro del Reino Unido en 2023” y salidas y respuestas, como “Rishi Sunak”. Con un conjunto de datos no etiquetados, solo proporcionamos la pregunta o la instrucción, como “Genera el código fuente para un sitio web de ventas al por menor”. Llamamos a la combinación de catálogo de indicaciones y conjunto de datos de evaluación el catálogo de indicaciones de evaluación. La razón por la que diferenciamos entre el catálogo de indicaciones y el catálogo de indicaciones de evaluación es porque este último está dedicado a un caso de uso específico en lugar de indicaciones y instrucciones genéricas (como la respuesta a preguntas) que contiene el catálogo de indicaciones.

    Con este catálogo de indicaciones de evaluación, el siguiente paso es proporcionar las indicaciones de evaluación a los mejores FMs. El resultado es un conjunto de datos de resultados de evaluación que contiene las indicaciones, las salidas de cada FM y la salida etiquetada junto con una puntuación (si existe). En el caso de un catálogo de indicaciones de evaluación no etiquetado, hay un paso adicional para que un HIL o LLM revise los resultados y proporcione una puntuación y comentarios (como describimos anteriormente). El resultado final serán los resultados agregados que combinan las puntuaciones de todas las salidas (calculan la precisión promedio o la calificación humana) y permiten a los usuarios comparar la calidad de los modelos.

    Después de recopilar los resultados de la evaluación, proponemos elegir un modelo en función de varias dimensiones. Estas suelen reducirse a factores como precisión, velocidad y coste. La siguiente figura muestra un ejemplo.

    Cada modelo tendrá fortalezas y ciertos compromisos en estas dimensiones. Dependiendo del caso de uso, debemos asignar prioridades variables a estas dimensiones. En el ejemplo anterior, elegimos priorizar el coste como el factor más importante, seguido de la precisión y luego la velocidad. Aunque es más lento y no tan eficiente como FM1, sigue siendo suficientemente efectivo y significativamente más barato de alojar. En consecuencia, podríamos seleccionar FM2 como la opción principal.

    Paso 3. Desarrollar el backend y frontend de la aplicación de IA generativa

    En este punto, los desarrolladores de IA generativa han seleccionado el FM adecuado para la aplicación específica con la ayuda de ingenieros y probadores de indicaciones. El siguiente paso es comenzar a desarrollar la aplicación de IA generativa. Hemos separado el desarrollo de la aplicación de IA generativa en dos capas, una capa de backend y una capa de frontend, como se muestra en la siguiente figura.

    En el backend, los desarrolladores de IA generativa incorporan el FM seleccionado en las soluciones y trabajan junto con los ingenieros de indicaciones para crear la automatización que transforma la entrada del usuario final en indicaciones de FM apropiadas. Los probadores de indicaciones crean las entradas necesarias para el catálogo de indicaciones para pruebas automáticas o manuales (HIL o LLM). Luego, los desarrolladores de IA generativa crean el encadenamiento de indicaciones y el mecanismo de aplicación para proporcionar la salida final. El encadenamiento de indicaciones, en este contexto, es una técnica para crear aplicaciones LLM más dinámicas y contextualmente conscientes. Funciona dividiendo una tarea compleja en una serie de tareas más pequeñas y manejables. Por ejemplo, si le preguntamos a un LLM “¿Dónde nació el primer ministro del Reino Unido y qué tan lejos está ese lugar de Londres?”, la tarea se puede descomponer en indicaciones individuales, donde una indicación podría construirse en función de la respuesta de una evaluación de indicaciones anterior, como “¿Quién es el primer ministro del Reino Unido?”, “¿Cuál es su lugar de nacimiento?” y “¿Qué tan lejos está ese lugar de Londres?” Para garantizar una cierta calidad de entrada y salida, los desarrolladores de IA generativa también necesitan crear el mecanismo para monitorear y filtrar las entradas de los usuarios finales y las salidas de la aplicación. Si, por ejemplo, se supone que la aplicación LLM debe evitar solicitudes y respuestas tóxicas, podrían aplicar un detector de toxicidad para la entrada y la salida y filtrarlas. Por último, necesitan proporcionar un mecanismo de calificación, que respaldará la ampliación del catálogo de indicaciones de evaluación con ejemplos buenos y malos. Una representación más detallada de esos mecanismos se presentará en futuras publicaciones.

    Para proporcionar la funcionalidad al usuario final de la IA generativa, es necesario desarrollar un sitio web de frontend que interactúe con el backend. Por lo tanto, las personas de DevOps y AppDevs (desarrolladores de aplicaciones en la nube) deben seguir las mejores prácticas de desarrollo para implementar la funcionalidad de entrada/salida y calificación.

    Además de esta funcionalidad básica, el frontend y el backend deben incorporar la característica de crear cuentas de usuario personalizadas, cargar datos, iniciar el ajuste fino como una caja negra y usar el modelo personalizado en lugar del FM básico. La producción de una aplicación de IA generativa es similar a una aplicación normal. La siguiente figura representa una arquitectura de ejemplo.

    En esta arquitectura, los desarrolladores de IA generativa, los ingenieros de indicaciones y los DevOps o AppDevs crean y prueban la aplicación manualmente al implementarla a través de CI/CD en un entorno de desarrollo (generative AI App Dev en la figura anterior) utilizando repositorios de código dedicados y fusionando con la rama de desarrollo. En esta etapa, los desarrolladores de IA generativa utilizarán el FM correspondiente llamando a la API proporcionada por los proveedores de sintonizadores finos. Luego, para probar exhaustivamente la aplicación, necesitan promocionar el código a la rama de pruebas, lo que desencadenará la implementación a través de CI/CD en el entorno de preproducción (generative AI App Pre-prod). En este entorno, los probadores de indicaciones deben probar una gran cantidad de combinaciones de indicaciones y revisar los resultados. La combinación de indicaciones, salidas y revisiones debe trasladarse al catálogo de indicaciones de evaluación para automatizar el proceso de prueba en el futuro. Después de esta extensa prueba, el último paso es promocionar la aplicación de IA generativa a producción a través de CI/CD mediante la fusión con la rama principal (generative AI App Prod). Tenga en cuenta que todos los datos, incluido el catálogo de indicaciones, los datos y resultados de evaluación, los datos y metadatos de los usuarios finales y el modelo ajustado fino, deben almacenarse en el lago de datos o la capa de malla de datos. Los pipelines y repositorios de CI/CD deben almacenarse en una cuenta de herramientas separada (similar a la descrita para MLOps).

    El recorrido de los proveedores

    Los proveedores de FM necesitan entrenar FMs, como modelos de aprendizaje profundo. Para ellos, es necesario el ciclo de vida e infraestructura completo de MLOps. Se requieren adiciones en la preparación de datos históricos, evaluación y monitoreo del modelo. La siguiente figura ilustra su recorrido.

    En el aprendizaje automático clásico, los datos históricos se crean más a menudo alimentando la verdad fundamental a través de tuberías ETL. Por ejemplo, en un caso de uso de predicción de abandono, una automatización actualiza una tabla de base de datos según el nuevo estado de un cliente para abandonar/no abandonar automáticamente. En el caso de los FM, necesitan miles de millones de puntos de datos etiquetados o no etiquetados. En casos de uso de texto a imagen, un equipo de etiquetadores de datos necesita etiquetar pares de <texto, imagen> manualmente. Esto es un ejercicio costoso que requiere un gran número de recursos humanos. Amazon SageMaker Ground Truth Plus puede proporcionar un equipo de etiquetadores para realizar esta actividad por usted. Para algunos casos de uso, este proceso también puede ser parcialmente automatizado, por ejemplo, utilizando modelos similares a CLIP. En el caso de un LLM, como de texto a texto, los datos no están etiquetados. Sin embargo, deben prepararse y seguir el formato de los datos históricos no etiquetados existentes. Por lo tanto, se necesitan editores de datos para realizar la preparación necesaria de los datos y garantizar la consistencia.

    Con los datos históricos preparados, el siguiente paso es el entrenamiento y la produccionización del modelo. Tenga en cuenta que se pueden utilizar las mismas técnicas de evaluación que describimos para los consumidores.

    El viaje de los ajustadores finos

    Los ajustadores finos tienen como objetivo adaptar un FM existente a su contexto específico. Por ejemplo, un modelo de FM puede resumir un texto de propósito general pero no un informe financiero con precisión o no puede generar código fuente para un lenguaje de programación no común. En esos casos, los ajustadores finos necesitan etiquetar datos, ajustar finamente un modelo ejecutando un trabajo de entrenamiento, implementar el modelo, probarlo basándose en los procesos de los consumidores y monitorear el modelo. El siguiente diagrama ilustra este proceso.

    Por el momento, existen dos mecanismos de ajuste fino:

    • Ajuste fino: mediante el uso de un FM y datos etiquetados, un trabajo de entrenamiento recalcula los pesos y sesgos de las capas del modelo de aprendizaje profundo. Este proceso puede ser intensivo en cómputo y requiere una cantidad representativa de datos, pero puede generar resultados precisos.
    • Ajuste fino eficiente en parámetros (PEFT): en lugar de recalcular todos los pesos y sesgos, los investigadores han demostrado que al agregar capas pequeñas adicionales a los modelos de aprendizaje profundo, pueden lograr resultados satisfactorios (por ejemplo, LoRA). PEFT requiere menos potencia computacional que el ajuste fino profundo y un trabajo de entrenamiento con menos datos de entrada. La desventaja es una precisión potencialmente menor.

    El siguiente diagrama ilustra estos mecanismos.

    Ahora que hemos definido los dos principales métodos de ajuste fino, el siguiente paso es determinar cómo podemos implementar y utilizar el FM de código abierto y propietario.

    Con los FM de código abierto, los ajustadores finos pueden descargar el artefacto del modelo y el código fuente de la web, por ejemplo, utilizando el Hugging Face Model Hub. Esto le brinda la flexibilidad de ajustar finamente el modelo, almacenarlo en un registro de modelos local e implementarlo en un punto de enlace de Amazon SageMaker. Este proceso requiere una conexión a Internet. Para admitir entornos más seguros (como los clientes del sector financiero), puede descargar el modelo en las instalaciones, realizar todas las verificaciones de seguridad necesarias y cargarlos en un bucket local en una cuenta de AWS. Luego, los ajustadores finos utilizan el FM desde el bucket local sin conexión a Internet. Esto garantiza la privacidad de los datos y que los datos no viajen por Internet. El siguiente diagrama ilustra este método.

    Con los FMs propietarios, el proceso de implementación es diferente porque los ajustadores no tienen acceso al artefacto del modelo o al código fuente. Los modelos se almacenan en cuentas de proveedores de FM propietarios de AWS y en registros de modelos. Para implementar dicho modelo en un punto de enlace de SageMaker, los ajustadores solo pueden solicitar el paquete de modelo que se implementará directamente en un punto de enlace. Este proceso requiere que los datos del cliente se utilicen en las cuentas de los proveedores de FM propietarios, lo que plantea preguntas sobre el uso de datos sensibles del cliente en una cuenta remota para realizar el ajuste fino, y los modelos que se alojan en un registro de modelos compartido entre varios clientes. Esto conduce a un problema de multiinquilinato que se vuelve más desafiante si los proveedores de FM propietarios necesitan ofrecer estos modelos. Si los ajustadores utilizan Amazon Bedrock, estos desafíos se resuelven, los datos no viajan por Internet y los proveedores de FM no tienen acceso a los datos de los ajustadores. Los mismos desafíos se aplican a los modelos de código abierto si los ajustadores desean ofrecer modelos de varios clientes, como el ejemplo que mencionamos anteriormente con el sitio web al que miles de clientes cargarán imágenes personalizadas. Sin embargo, estos escenarios se pueden considerar controlables porque solo está involucrado el ajustador. El siguiente diagrama ilustra este método.

    Desde una perspectiva tecnológica, la arquitectura que un ajustador necesita admitir es similar a la de MLOps (consulte la siguiente figura). El ajuste fino debe llevarse a cabo en dev mediante la creación de canalizaciones de ML, como el uso de Amazon SageMaker Pipelines; realizar la preprocesamiento, ajuste fino (trabajo de entrenamiento) y posprocesamiento; y enviar los modelos ajustados fino a un registro de modelos local en el caso de un FM de código abierto (de lo contrario, el nuevo modelo se almacenará en el entorno del proveedor de FM propietario). Luego, en preproducción, debemos probar el modelo como describimos para el escenario de los consumidores. Finalmente, el modelo se servirá y se supervisará en prod. Tenga en cuenta que el FM actual (ajustado fino) requiere puntos de enlace de instancia de GPU. Si necesitamos implementar cada modelo ajustado fino en un punto de enlace separado, esto podría aumentar el costo en el caso de cientos de modelos. Por lo tanto, debemos usar puntos de enlace de múltiples modelos y resolver el desafío de multiinquilinato.

    Los ajustadores adaptan un modelo FM basado en un contexto específico para usarlo para su propósito comercial. Eso significa que la mayor parte del tiempo, los ajustadores también son consumidores que deben admitir todas las capas, como describimos en las secciones anteriores, incluido el desarrollo de aplicaciones de IA generativa, el lago de datos y la malla de datos, y MLOps.

    La siguiente figura ilustra el ciclo de vida completo de ajuste fino de FM que los ajustadores deben proporcionar al usuario final de IA generativa.

    La siguiente figura ilustra los pasos clave.

    Los pasos clave son los siguientes:

    1. El usuario final crea una cuenta personal y carga datos privados.
    2. Los datos se almacenan en el lago de datos y se preprocesan para seguir el formato que espera el FM.
    3. Esto activa una canalización de ML de ajuste fino que agrega el modelo al registro de modelos,
    4. A partir de ahí, el modelo se implementa en producción con pruebas mínimas o el modelo se somete a pruebas exhaustivas con HIL y puertas de aprobación manuales.
    5. El modelo ajustado fino está disponible para los usuarios finales.

    Debido a que esta infraestructura es compleja para los clientes no empresariales, AWS lanzó Amazon Bedrock para descargar el esfuerzo de crear tales arquitecturas y acercar los FM ajustados finos a la producción.

    Diferenciadores de las personas y procesos de FMOps y LLMOps

    Basado en los recorridos de los diferentes tipos de usuarios anteriores (consumidor, productor y afinador), se requieren nuevas personas con habilidades específicas, como se ilustra en la siguiente figura.

    Las nuevas personas son las siguientes:

    • Etiquetadores y editores de datos – Estos usuarios etiquetan datos, como pares de <texto, imagen>, o preparan datos sin etiquetar, como texto libre, y amplían los entornos del equipo de análisis avanzado y del lago de datos.
    • Afinadores – Estos usuarios tienen un profundo conocimiento de los FM y saben cómo ajustarlos, ampliando el equipo de ciencia de datos que se centrará en ML clásico.
    • Desarrolladores de IA generativa – Tienen un profundo conocimiento de la selección de los FM, el encadenamiento de indicaciones y aplicaciones, y la filtración de entradas y salidas. Pertenecen a un nuevo equipo, el equipo de aplicación de IA generativa.
    • Ingenieros de indicaciones – Estos usuarios diseñan las indicaciones de entrada y salida para adaptar la solución al contexto, y prueban y crean la versión inicial del catálogo de indicaciones. Su equipo es el equipo de aplicación de IA generativa.
    • Probadores de indicaciones – Prueban a gran escala la solución de IA generativa (backend y frontend) y alimentan sus resultados para aumentar el catálogo de indicaciones y el conjunto de datos de evaluación. Su equipo es el equipo de aplicación de IA generativa.
    • AppDev y DevOps – Desarrollan la interfaz de usuario (como un sitio web) de la aplicación de IA generativa. Su equipo es el equipo de aplicación de IA generativa.
    • Usuarios finales de IA generativa – Estos usuarios consumen aplicaciones de IA generativa como cajas negras, comparten datos y califican la calidad de la salida.

    La versión extendida del mapa de procesos de MLOps para incorporar IA generativa se puede ilustrar con la siguiente figura.

    Una nueva capa de aplicación es el entorno donde los desarrolladores de IA generativa, ingenieros de indicaciones, probadores y AppDevs crean el backend y frontend de las aplicaciones de IA generativa. Los usuarios finales de IA generativa interactúan con el frontend de las aplicaciones de IA generativa a través de Internet (como una interfaz de usuario web). Por otro lado, los etiquetadores y editores de datos necesitan preprocesar los datos sin acceder al backend del lago de datos o malla de datos. Por lo tanto, es necesario una interfaz de usuario web (sitio web) con un editor para interactuar de forma segura con los datos. SageMaker Ground Truth proporciona esta funcionalidad de manera nativa.

    Conclusión

    MLOps puede ayudarnos a poner en producción modelos de ML de manera eficiente. Sin embargo, para operacionalizar aplicaciones de IA generativa, se necesitan habilidades, procesos y tecnologías adicionales, lo que lleva a FMOps y LLMOps. En esta publicación, definimos los conceptos principales de FMOps y LLMOps y describimos los diferenciadores clave en comparación con las capacidades de MLOps en términos de personas, procesos, tecnología, selección y evaluación de modelos de FM. Además, ilustramos el proceso de pensamiento de un desarrollador de IA generativa y el ciclo de vida del desarrollo de una aplicación de IA generativa.

    En el futuro, nos centraremos en proporcionar soluciones según el dominio que hemos discutido y proporcionaremos más detalles sobre cómo integrar la monitorización de FM (como toxicidad, sesgo y alucinación) y patrones arquitectónicos de fuentes de datos de terceros o privadas, como Retrieval Augmented Generation (RAG), en FMOps/LLMOps.

    Para obtener más información, consulte la hoja de ruta de la base de MLOps para empresas con Amazon SageMaker y pruebe la solución de extremo a extremo en la implementación de prácticas de MLOps con modelos preentrenados de Amazon SageMaker JumpStart.

    Si tiene algún comentario o pregunta, déjelos en la sección de comentarios.

    We will continue to update Zepes; if you have any questions or suggestions, please contact us!

    Share:

    Was this article helpful?

    93 out of 132 found this helpful

Discover more

Inteligencia Artificial

Conoce a Skill-it un marco de habilidades impulsado por datos para comprender y entrenar modelos de lenguaje

Los modelos de lenguaje grandes (LM) son notablemente capaces de crear código fuente, crear obras de arte originales ...

Inteligencia Artificial

Nuevo ahora están disponibles las capacidades de IA generativa sin código en Amazon SageMaker Canvas

Lanzado en 2021, Amazon SageMaker Canvas es un servicio visual y de clic que permite a analistas de negocios y cientí...

Inteligencia Artificial

Microsoft presenta Azure ChatGPT una versión privada de ChatGPT diseñada para la empresa

Microsoft Azure ChatGPT es una oferta innovadora que capacita a las empresas para aprovechar las capacidades de ChatG...