Fine-tuning vs. prompting: cuándo entrenar y cuándo solo instruir
Prompting da instrucciones al modelo en cada petición; fine-tuning ajusta sus pesos con datos propios. Cuándo conviene cada uno y cómo decidir con evaluaciones.
¿Qué es cada cosa?
Un modelo base ya sabe mucho del lenguaje. Con prompting le indicas la tarea en el mensaje: qué rol tiene, qué formato debe devolver, qué ejemplos seguir. Todo eso viaja en cada llamada y ocupa espacio en la ventana de contexto. Cambiar la instrucción cambia el comportamiento al instante. Wikipedia lo describe como aprendizaje en contexto: el modelo aprende temporalmente de lo que hay en el prompt y sus pesos no cambian.
Con fine-tuning, en cambio, preparas un conjunto de ejemplos (pares de entrada y salida deseada) y ejecutas un entrenamiento adicional. Los pesos del modelo se ajustan. Después, el comportamiento aparece sin necesidad de repetir la instrucción en cada petición.
El ajuste puede ser completo, con todos los parámetros, o más ligero. LoRA, por ejemplo, congela los pesos originales y entrena unas pocas matrices adicionales. El artículo original de LoRA reporta que, frente a un ajuste completo de GPT-3 175B con Adam, reduce 10.000 veces los parámetros entrenables y 3 veces la memoria de GPU necesaria, con una calidad igual o mejor en los modelos que probaron (RoBERTa, DeBERTa, GPT-2 y GPT-3).
¿Qué tipos de fine-tuning existen?
La documentación de OpenAI distingue cuatro, y sirven para entender que “afinar” no es una sola técnica:
| Método | Cómo funciona | Para qué sirve |
|---|---|---|
| Supervised fine-tuning (SFT) | Se entrena con ejemplos de respuestas correctas | Clasificación, traducción con matices, contenido en un formato específico, corregir fallos al seguir instrucciones |
| Vision fine-tuning | SFT con imágenes como entrada | Clasificar imágenes y corregir fallos con prompts complejos |
| Direct preference optimization (DPO) | Se da una respuesta buena y una mala para el mismo prompt | Resumir con el enfoque correcto, generar mensajes con el tono y el estilo adecuados |
| Reinforcement fine-tuning (RFT) | Un experto califica las respuestas y se refuerza el razonamiento mejor puntuado | Razonamiento complejo en un dominio especializado (solo modelos de razonamiento) |
Para un equipo de producto, DPO es el más cercano al trabajo de diseño: sirve para enseñar tono y estilo mostrando pares de “esto sí, esto no”. RFT exige expertos que coincidan en cuál es la respuesta ideal, algo que pocos equipos tienen.
¿Por qué le importa a un diseñador?
Porque la decisión afecta el ciclo de iteración del producto:
- Velocidad. Cambiar un prompt toma minutos. Un fine-tuning implica preparar datos, entrenar, evaluar y desplegar. Si el equipo de diseño quiere probar tonos de voz distintos, el prompting permite iterar mucho más rápido.
- Consistencia de formato. Si la interfaz necesita siempre el mismo formato de salida, un fine-tuning puede reducir errores de forma. Pero antes conviene probar salidas estructuradas.
- Conocimiento cambiante. Si la información cambia cada semana, entrenar el modelo con ella es una mala idea. Ese caso encaja mejor con RAG.
- Mantenimiento. Un modelo afinado es un activo que hay que reevaluar cada vez que cambia el modelo base. Y los proveedores retiran modelos: OpenAI indica que los modelos afinados siguen disponibles solo hasta que se retire su modelo base.
¿Cuándo SÍ tiene sentido afinar?
OpenAI enumera cuatro ventajas frente a usar solo prompts:
- Entrenar con más ejemplos de los que caben en una ventana de contexto.
- Usar prompts más cortos, lo que reduce el costo en tokens y la latencia a escala.
- Entrenar con datos propios o sensibles sin incluirlos en cada petición.
- Entrenar un modelo más pequeño, barato y rápido para una tarea concreta.
Fíjate en el patrón: casi todas son razones de escala, costo o consistencia, no de “el modelo no sabe hacerlo”. Si el volumen es bajo, un buen prompt suele ganar.
¿Cuándo NO conviene hacer fine-tuning?
Cuando no has probado un buen prompt. Muchos equipos entrenan porque suena más serio, y luego descubren que una instrucción clara con tres ejemplos habría resuelto el problema. La propia guía de OpenAI sugiere partir de unos 50 ejemplos bien elaborados y, si no hacen ninguna diferencia, revisar la tarea o el prompt antes de agregar más datos. En datos pesa más la calidad que la cantidad.
Y si lo que quieres es que el modelo recuerde hechos, el fine-tuning no es la herramienta adecuada: es mejor darle los documentos en el momento de responder, con RAG. Además, el ajuste puede debilitar el desempeño del modelo ante datos distintos a los del entrenamiento, según Wikipedia, así que no asumas que solo mejora.
¿Cómo decidir?
OpenAI propone un ciclo que se repite: escribir evals que fijen una línea base, probar con prompts, afinar donde tenga sentido, medir ambos y ajustar. Traducido a un orden práctico:
- Crea un conjunto de casos reales y mide la calidad. Sin medición no sabes si algo mejoró. Ver qué son los evals.
- Escribe el prompt más claro que puedas, con dos o tres ejemplos. Ver few-shot prompting.
- Si el problema es de conocimiento, prueba RAG.
- Si el problema es de comportamiento o formato que el prompting no logra de forma consistente, considera fine-tuning.
- Compara costo, latencia y mantenimiento de cada opción, y vuelve a medir con los mismos casos.
Ejemplo
Ejemplo ilustrativo: una aplicación de soporte necesita responder siempre con el tono de la marca y un formato de tres secciones. Con un prompt bien escrito y cuatro ejemplos, el formato sale bien en 9 de cada 10 casos, pero el resto se rompe. El equipo no entrena de inmediato: primero agrega validación del formato y revisa los casos fallidos. Si después de eso sigue fallando en una categoría concreta, prepara un conjunto de ejemplos solo para esa categoría y evalúa si el fine-tuning lo resuelve. La decisión se toma con datos, no con intuición.
Errores comunes
- Hacer fine-tuning para datos que cambian. Eso exige reentrenar cada vez.
- Entrenar sin una evaluación antes y después, o sin reservar parte de los datos como control.
- Usar datos de baja calidad porque hay muchos.
- Pensar que el prompt es algo menor. Muchas mejoras vienen de ahí.
- Dar por hecho que un proveedor seguirá ofreciendo el mismo modelo o método de ajuste.