Qué es el fine-tuning y cuándo usarlo (vs RAG y prompting)

Fine-tuning, RAG, prompt engineering. Tres técnicas que la gente confunde constantemente porque todas "mejoran" el comportamiento del modelo.

La diferencia es fundamental y determina cuál usar.

Qué hace cada una

Prompt engineering: Le dices al modelo cómo comportarse en cada llamada. Las instrucciones van en el prompt. El modelo base no cambia.

RAG (Retrieval-Augmented Generation): Le das al modelo acceso a información que no tiene en su entrenamiento. La información se recupera en tiempo real y se inyecta en el contexto.

Fine-tuning: Cambias el modelo mismo. Entrenas el modelo pre-existente con tus datos para modificar sus pesos. El resultado es un modelo nuevo.

Cuándo usar fine-tuning

El fine-tuning tiene sentido en casos muy específicos:

1. Formato de salida muy específico y consistente

Si necesitas que el modelo siempre devuelva JSON en un esquema exacto, con campos específicos, sin excepciones — el fine-tuning es más confiable que instrucciones en el prompt.

El prompting puede olvidar el formato. Un modelo fine-tuned en ese formato casi nunca lo olvida.

2. Estilo o voz muy específicos

Si tienes un tono de marca muy particular que es difícil de capturar en instrucciones — un modelo fine-tuned en tus textos reales lo captura mejor que descripciones del estilo.

3. Comportamiento que necesitas en millones de llamadas

Si vas a hacer 10M llamadas/mes, incluso un 5% de ahorro en tokens (porque ya no necesitas un system prompt largo) se traduce en dinero real. El fine-tuning puede eliminar parte de las instrucciones.

4. Dominio con vocabulario muy especializado

Terminología médica, legal o técnica muy específica que el modelo base maneja mal. Un modelo fine-tuned en textos del dominio entiende mejor el lenguaje.

Cuándo NO usar fine-tuning

El error más común: usar fine-tuning cuando el problema es de información, no de comportamiento.

Si el problema es que el modelo no sabe X — El fine-tuning no es un buen método para inyectar conocimiento. El modelo puede "aprender" hechos pero los alucinará si no los tiene bien representados. Usa RAG.

Si el conocimiento cambia — Los datos de entrenamiento tienen una fecha. Si tu información se actualiza (precios, políticas, noticias), el modelo fine-tuned queda obsoleto. Usa RAG.

Si es para un solo caso de uso pequeño — El fine-tuning requiere datos de entrenamiento, tiempo de entrenamiento y costo. Para casos de uso simples o de bajo volumen, el prompting es suficiente y mucho más rápido de iterar.

Si no tienes datos de calidad — Fine-tuning con datos malos produce un modelo malo de forma muy consistente. Necesitas ejemplos de alta calidad que representen el comportamiento deseado.

Cómo funciona el fine-tuning (sin matemáticas)

Preparas datos de entrenamiento: Pares de input-output que ejemplifican el comportamiento que quieres. Mínimo 50-100 ejemplos para casos simples, cientos o miles para casos complejos.
Entrenas el modelo: El proceso ajusta los pesos del modelo para que produzca outputs similares a los de tus ejemplos. No reescribe el modelo desde cero; ajusta los pesos existentes.
Evalúas: Comparas el modelo fine-tuned contra el base en tu eval set. Si mejora: lo usas. Si no: necesitas más o mejores datos de entrenamiento.
Despliegas: Usas el modelo fine-tuned vía API (si lo permite el proveedor) o en tu propia infraestructura.

Qué proveedores ofrecen fine-tuning

| Proveedor | Modelos | Notas | |---|---|---| | OpenAI | GPT-3.5, GPT-4o mini | El más accesible, buen soporte | | Google | Gemini 1.5 Flash | Vertex AI, más complejo de setup | | Mistral | Mistral 7B, Mixtral | Open y API | | Open source | Llama, Mistral, Qwen | Full control, necesitas GPU | | Anthropic | No disponible | No ofrecen fine-tuning al público |

La matriz de decisión

¿El problema es de COMPORTAMIENTO o ESTILO?
→ SÍ: Considera fine-tuning (si tienes datos y volumen)
→ NO: Sigue

¿El problema es de INFORMACIÓN/CONOCIMIENTO?
→ SÍ: Usa RAG
→ NO: Sigue

¿El problema se resuelve con instrucciones claras?
→ SÍ: Usa prompt engineering
→ NO: Combina técnicas o re-evalúa el problema

El orden correcto de iteración

Prompt engineering primero — rápido, gratis, iterable en minutos
RAG si necesitas conocimiento externo — datos dinámicos, información actualizable
Fine-tuning si el comportamiento sigue siendo inconsistente — después de validar que el problema es de comportamiento, no de información

El 80% de los sistemas en producción solo necesitan los primeros dos pasos. El fine-tuning es la excepción, no la regla.

Costos aproximados

OpenAI fine-tuning (GPT-4o mini):

Entrenamiento: ~$0.25/1K tokens de datos de entrenamiento
Inferencia: ~20-30% más caro que el modelo base

Self-hosted (Llama 3.3 70B):

Entrenamiento con LoRA: 8-40 horas en 8x A100 (~$100-500 en cloud)
Inferencia: solo costo de infraestructura propia

Para la mayoría de casos de uso, el ROI del fine-tuning solo se justifica con volumen alto y un problema bien definido que el prompting no puede resolver.