Aplicaciones de Foundation Models: entrenamiento, fine-tuning y evaluación
¿Qué pasa cuando usar un Foundation Model tal como viene ya no es suficiente? ¿Cómo logramos que entienda mejor nuestro dominio, siga instrucciones específicas o sea más eficiente? En esta ocasión exploramos cómo adaptar un FM mediante entrenamiento, fine-tuning y otras técnicas de personalización. Y damos el siguiente paso: aprender a evaluar si esos cambios realmente funcionan y si la solución está generando valor.
Series: Reto de Certificación AI Practitioner (9 articles)
- …
- 6Aplicaciones de Foundation Models: entrenamiento, fine-tuning y evaluación This article
🧠 No todo es entrenar un modelo desde cero
Cuando hablamos de entrenar modelos, es fácil imaginar enormes cantidades de datos, miles de GPUs y semanas de procesamiento.
Eso corresponde principalmente al pre-training inicial.
Durante esta etapa, un modelo aprende patrones generales del lenguaje —o de la modalidad correspondiente— utilizando cantidades masivas de datos.
Es una de las etapas más costosas del ciclo de vida de un Foundation Model y, para la mayoría de las organizaciones, no tiene sentido repetirla desde cero.
Por eso existen diferentes estrategias para adaptar modelos ya existentes.
Una de ellas es el continuous pre-training.
🔄 ¿Qué es continuous pre-training?
Consiste en continuar entrenando un modelo que ya fue preentrenado, utilizando datos adicionales para ampliar o actualizar su conocimiento base.
La diferencia importante está en el objetivo:
| Técnica | Objetivo |
|---|---|
| Pre-training | Crear el conocimiento general inicial del modelo |
| Continuous pre-training | Ampliar o actualizar ese conocimiento |
| Fine-tuning | Especializar el comportamiento del modelo |
Por ejemplo, imaginemos un modelo entrenado con información general hasta determinado momento.
Si queremos incorporar grandes cantidades de información adicional sin cambiar su propósito general, podríamos considerar continuous pre-training.
Si queremos que se especialice en una tarea o dominio concreto, estaríamos hablando de fine-tuning.
🎯 Fine-tuning: especializando un Foundation Model
El fine-tuning toma un modelo previamente entrenado y continúa su entrenamiento utilizando un conjunto de datos más pequeño y específico.
No buscamos enseñarle todo nuevamente.
Buscamos aprovechar lo que ya sabe y adaptarlo a nuestras necesidades.
Dependiendo del objetivo existen diferentes enfoques.
📋 Instruction tuning
Está enfocado en mejorar la capacidad del modelo para seguir instrucciones en lenguaje natural.
Para ello se utilizan ejemplos del tipo:
Instrucción → Respuesta esperada
Por ejemplo:
Instrucción: Resume este reporte financiero en tres puntos.
Respuesta esperada: Una respuesta con exactamente tres puntos, utilizando el tono y estructura deseados.
Con suficientes ejemplos de calidad, el modelo aprende mejor cómo esperamos que responda ante instrucciones similares.
🔁 Transfer learning
El transfer learning consiste en reutilizar conocimiento adquirido previamente para aprender una nueva tarea relacionada.
En lugar de comenzar desde cero, aprovechamos representaciones y patrones que el modelo ya aprendió.
Es importante recordar que este concepto no nació con los Foundation Models: es una técnica ampliamente utilizada en Machine Learning.
La idea central es sencilla:
No vuelvas a aprender desde cero aquello que el modelo ya sabe.
🏢 Adaptación a dominios específicos
También podemos especializar un modelo en el vocabulario, estilo y patrones propios de una industria.
Por ejemplo:
- servicios financieros,
- seguros,
- manufactura,
- tecnología,
- atención al cliente.
El objetivo es que el modelo se comporte de manera más consistente dentro del contexto particular donde será utilizado.
🧩 Una forma sencilla de diferenciarlos
Instruction tuning: quiero que siga mejor mis instrucciones.
Domain adaptation: quiero que se adapte mejor al lenguaje y contexto de mi dominio.
Transfer learning: quiero reutilizar conocimiento existente para resolver una tarea relacionada.
🧪 Model Distillation: un modelo grande puede enseñar a uno pequeño
Supongamos que encontramos un modelo con excelente desempeño.
Hay un problema:
Es grande, tiene mayor latencia y ejecutarlo miles o millones de veces puede resultar costoso.
Aquí aparece Model Distillation.
La idea es utilizar un modelo grande y capaz como teacher (maestro) para ayudar a entrenar un modelo más pequeño, llamado student (estudiante).
El objetivo es que el estudiante aprenda a replicar buena parte del comportamiento del maestro.
⚡ ¿Para qué utilizar distillation?
Principalmente para conseguir:
menor costo de inferencia + menor latencia
intentando conservar la mayor cantidad posible de capacidad del modelo original.
Pero existe un detalle importante.
La destilación también tiene un costo.
Crear el modelo estudiante requiere un proceso de entrenamiento. El ahorro aparece principalmente después, cuando ese modelo más pequeño se utiliza repetidamente en producción.
⚖️ ¿Qué estrategia de personalización elegir?
No siempre necesitamos modificar el modelo.
Podemos pensar las diferentes estrategias como una escala de costo, esfuerzo y nivel de personalización:
| Estrategia | ¿Modifica el modelo? | Útil cuando... |
|---|---|---|
| In-context learning | ❌ | Necesitamos ajustes rápidos mediante el contexto |
| RAG | ❌ | Necesitamos incorporar información externa o actualizada |
| Fine-tuning | ✅ | Necesitamos cambiar consistentemente el comportamiento |
| Model Distillation | ✅ | Queremos reducir costo o latencia a escala |
| Pre-training | ✅ | Necesitamos construir un modelo desde cero |
Una de las ideas más importantes es entender que más personalización no significa automáticamente una mejor solución.
Si el problema puede resolverse mediante prompting o RAG, quizá no necesitemos asumir el costo y complejidad de modificar el modelo.
🗂️ Fine-tuning: tus datos importan tanto como el modelo
Elegir la técnica correcta es solo una parte del problema.
El resultado dependerá enormemente de los datos utilizados para entrenar el modelo.
Por eso debemos considerar varios aspectos.
🧹 Curación de datos
No se trata únicamente de tener muchos datos.
Debemos seleccionar información relevante, correcta y útil para el comportamiento que queremos enseñar.
🔐 Gobernanza
Los datos deben cumplir las políticas de la organización relacionadas con:
- privacidad,
- seguridad,
- propiedad,
- regulación,
- uso apropiado.
🏷️ Etiquetado
Si utilizamos ejemplos etiquetados, estos deben ser correctos y consistentes.
Un dataset con etiquetas incorrectas puede enseñar precisamente el comportamiento que queremos evitar.
🌎 Representatividad
Los datos deberían representar adecuadamente los escenarios que el modelo encontrará en producción.
Por ejemplo, si entrenamos un asistente de servicio al cliente únicamente con preguntas sencillas, quizá tenga problemas cuando encuentre solicitudes ambiguas o situaciones poco frecuentes.
👥 RLHF: aprender de las preferencias humanas
Otra técnica importante es Reinforcement Learning from Human Feedback (RLHF).
Aquí las personas participan proporcionando señales sobre qué respuestas consideran mejores.
Simplificando mucho el proceso:
Modelo genera respuestas → humanos expresan preferencias → esas preferencias se utilizan como señal para mejorar el comportamiento del modelo.
Esto permite incorporar criterios que pueden ser difíciles de capturar únicamente mediante reglas automáticas.
📊 Ya personalizamos el modelo… ¿cómo sabemos si funciona?
Llegamos a la segunda mitad del problema: evaluación.
Y aquí aparece una idea fundamental:
No existe una única métrica capaz de decirnos si un Foundation Model es “bueno”.
La evaluación depende de la tarea y del contexto donde utilizaremos el modelo.
Por eso podemos combinar diferentes enfoques.
👤 Evaluación humana
En la human-in-the-loop evaluation, personas reales revisan las respuestas generadas.
Esto permite evaluar aspectos difíciles de capturar mediante métricas automáticas:
- tono,
- claridad,
- relevancia,
- utilidad,
- adecuación al contexto,
- calidad percibida.
La ventaja es evidente: obtenemos juicio humano real.
La desventaja también: puede ser más lento y costoso de escalar.
🧪 Benchmark datasets
Otra alternativa son los benchmark datasets.
Son conjuntos estandarizados de tareas y respuestas de referencia que permiten comparar modelos bajo condiciones similares.
Son especialmente útiles cuando queremos comparar diferentes modelos de manera consistente y reproducible.
Sin embargo, existe una limitación importante:
Un modelo puede tener excelentes resultados en un benchmark y no necesariamente funcionar igual de bien en nuestro caso de uso específico.
☁️ Amazon Bedrock Model Evaluation
AWS también proporciona capacidades de Model Evaluation en Amazon Bedrock para facilitar la evaluación de Foundation Models.
Esto permite incorporar mecanismos de evaluación dentro de un flujo administrado y comparar el desempeño de los modelos de manera más estructurada.
La idea importante para el examen no es únicamente conocer el servicio, sino entender qué problema resuelve:
Facilitar la evaluación sistemática de Foundation Models antes de utilizarlos en aplicaciones reales.
📏 ROUGE, BLEU y BERTScore: ¿qué estamos midiendo?
Llegamos a algunas de las métricas que debemos reconocer para el examen.
No necesitas memorizar sus fórmulas matemáticas.
Lo importante es entender qué mide cada una y cuándo utilizarla.
📝 ROUGE
Mide la superposición entre el texto generado y un texto de referencia.
Se utiliza frecuentemente para evaluar resúmenes.
👉 ROUGE → resumen.
🌐 BLEU
Compara secuencias de palabras del resultado generado contra una o varias referencias.
Tradicionalmente se utiliza para evaluar traducción automática.
👉 BLEU → traducción.
🧠 BERTScore
Aquí damos un paso diferente.
BERTScore utiliza representaciones semánticas para evaluar si dos textos tienen significados similares, aunque no utilicen exactamente las mismas palabras.
Por ejemplo:
Referencia:
“El cliente canceló la compra porque el producto llegó tarde.”
“El cliente canceló la compra porque el producto llegó tarde.”
Respuesta:
“El retraso en la entrega provocó que el comprador cancelara su pedido.”
“El retraso en la entrega provocó que el comprador cancelara su pedido.”
Las palabras son diferentes, pero semánticamente expresan prácticamente lo mismo.
Una métrica basada únicamente en coincidencias literales podría penalizarlo.
BERTScore puede capturar mejor esa similitud semántica.
💡 Tip: si el escenario dice algo parecido a “la respuesta utiliza palabras diferentes pero conserva el mismo significado”, piensa en BERTScore.
🧠 Atajo mental
| Métrica | Piensa en... |
|---|---|
| 📝 ROUGE | Resúmenes |
| 🌐 BLEU | Traducción |
| 🧠 BERTScore | Significado / similitud semántica |
⚖️ LLM-as-a-Judge
Existe otro enfoque de evaluación:
usar un LLM para evaluar las respuestas generadas por otro modelo.
El modelo evaluador puede recibir:
- la pregunta,
- la respuesta generada,
- una respuesta de referencia,
- criterios de evaluación.
Y determinar aspectos como relevancia, coherencia o calidad.
Esto permite realizar evaluaciones cualitativas a una escala mucho mayor que utilizando exclusivamente revisores humanos.
Sin embargo, sigue siendo una evaluación realizada por un modelo, por lo que sus resultados deben interpretarse dentro del contexto y los criterios definidos para la evaluación.
🏗️ Evaluar el modelo no es lo mismo que evaluar la aplicación
Este es uno de los conceptos más importantes de toda la sesión.
Podemos tener un Foundation Model excelente y aun así construir una mala aplicación.
¿Por qué?
Porque las aplicaciones modernas de IA generativa normalmente tienen muchos componentes alrededor del modelo.
🔎 Evaluando una aplicación RAG
En una arquitectura RAG tenemos, simplificando:
Pregunta → recuperación de información → contexto → Foundation Model → respuesta
Si recuperamos documentos incorrectos, el modelo recibirá un contexto incorrecto.
Por eso debemos evaluar tanto:
🔍 Retrieval: ¿recuperamos información relevante?
como:
✨ Generation: ¿el modelo generó una buena respuesta utilizando esa información?
Un modelo excelente no puede compensar siempre una recuperación deficiente.
💡 Tip: en RAG, no evalúes solamente la respuesta final. También importa la calidad y relevancia de la información recuperada.
🤖 Evaluando agentes
Con agentes la evaluación se vuelve todavía más interesante.
Un agente puede realizar un flujo similar a:
Interpretar → Planear → Elegir herramienta → Ejecutar → Analizar → Continuar → Completar
Evaluar únicamente el texto final sería insuficiente.
También necesitamos preguntarnos:
- ¿eligió correctamente las herramientas?
- ¿tomó buenas decisiones intermedias?
- ¿completó todos los pasos?
- ¿alcanzó realmente el objetivo?
Aquí importa especialmente el desempeño end-to-end.
💡 Nota: un agente puede generar buenos mensajes y aun así fallar en completar la tarea.
🔄 Evaluando workflows
La misma lógica aplica a workflows de IA generativa.
Un workflow puede contener diferentes modelos, servicios, validaciones y pasos automatizados.
Por eso necesitamos evaluar el flujo completo, no únicamente cada componente de manera aislada.
Una aplicación puede tener excelentes componentes individuales y aun así fallar por la forma en que interactúan entre ellos.
💼 Del modelo al negocio
Hasta ahora hemos hablado principalmente de métricas técnicas.
Pero en producción existe una pregunta todavía más importante:
¿La aplicación está cumpliendo el objetivo para el que fue creada?
Aquí aparecen las métricas de negocio.
✅ Task Completion Rate
¿Qué porcentaje de las tareas logra completar exitosamente la aplicación de principio a fin?
Es especialmente relevante para agentes y sistemas que realizan procesos completos.
😊 User Satisfaction
¿Qué tan satisfechos están los usuarios con la experiencia?
Podemos medirlo mediante encuestas, calificaciones u otros mecanismos de feedback.
💰 Cost per Interaction
¿Cuánto cuesta cada interacción?
Aquí podemos considerar elementos como tokens, cómputo e infraestructura.
Una solución técnicamente impresionante podría no ser viable si su costo por interacción es demasiado elevado.
✨ Mantente al día con todas las novedades
AWS Tech Girls
Series: Reto de Certificación AI Practitioner (9 articles)
- …
- 6Aplicaciones de Foundation Models: entrenamiento, fine-tuning y evaluación This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article