🎯 Fine-Tuning

Especializar un modelo genérico

El fine-tuning es coger un modelo que ya sabe mucho (pre-entrenado) y darle un empujón para que sea experto en algo concreto. No empiezas desde cero — aprovechas todo lo que ya aprendió.

¿Para qué se usa?

• Estilo y tono: que hable como un médico, abogado, o atención al cliente
• Vocabulario especializado: términos técnicos, jerga de dominio
• Formato de salida: que siempre devuelva JSON, o un informe clínico estructurado
• Corregir comportamientos: que no alucine en ciertos temas, que siga un protocolo
• Adaptación a un idioma o cultura: español clínico, terminología local

Desde 2024 hay una discusión abierta: ¿merece la pena fine-tunear cuando los modelos generalistas son cada vez más capaces?

¿Cuándo gana el generalista?

• Tareas estándar: responder preguntas generales, resumir, traducir
• Conocimiento muy cubierto: medicina general, derecho básico, programación común
• Cuando puedes dar buen contexto: si en el prompt le pones 10 ejemplos (few-shot), a menudo iguala al fine-tuning sin el coste
• Cuando necesitas versatilidad: un solo modelo que haga de todo, no 10 modelos especializados

¿Cuándo gana el fine-tuning?

• Formato y estructura rígida: necesitas que la salida siga exactamente un esquema (informes clínicos, formularios legales)
• Vocabulario muy específico: jerga técnica que los modelos generalistas mezclan o ignoran
• Latencia / coste: un modelo 7B fine-tuneado es más barato y rápido que llamar a GPT-4o cada vez
• Privacidad / regulación: no puedes mandar datos a una API externa (GDPR, HIPAA)
• Consistencia: el fine-tuning da respuestas más predecibles; un API externa puede cambiar de comportamiento sin avisar

El debate técnico

La comunidad está dividida. Por un lado, papers como "LIMA: Less Is More for Alignment" (2023) mostraron que con solo 1,000 ejemplos bien curados puedes igualar modelos fine-tuneados con cientos de miles. Por otro, "The False Promise of Fine-Tuning" y estudios posteriores (2025) muestran que el fine-tuning apenas aporta cuando el modelo base ya es muy bueno.

Papers clave

La conclusión de estos papers no es "fine-tuning no sirve". Es: "asegúrate de que realmente lo necesitas antes de invertir". El fine-tuning sigue siendo la mejor herramienta para:

1. Control de formato estricto — el prompting puede fallar, el fine-tuning es más robusto
2. Reducción de costes operativos — un modelo pequeño fine-tuneado te ahorra $/mes si tienes alto volumen
3. Adaptación a dominios ultra-específicos — jerga médica muy local, notación científica, legislación de un país concreto
4. Offline / privacidad — cuando los datos no pueden salir de tu infraestructura

¿Por qué los generalistas ganan?

Hay una razón estructural: los modelos grandes (70B+) tienen más capacidad de representación interna. Cuando haces fine-tuning a un modelo 7B, estás reasignando parámetros limitados. El modelo 70B ya tiene espacio para representar casi cualquier dominio. El fine-tuning en un modelo pequeño es un juego de suma cero: ganas en el dominio objetivo, pero pierdes capacidad general.

Catastrophic Forgetting

Problema: al fine-tunear un modelo 7B en un dominio específico,
pierde capacidad en tareas generales.

Ejemplo medido (LLaMA 3 8B FT en código médico):
- Precisión en diagnóstico: +12%
- Precisión en programación: -8%
- Precisión en razonamiento general: -5%

Solución parcial:
- EPOCHS bajos (1-3)
- Learning rate pequeño (1e-5 a 5e-5)
- Mezclar datos del dominio original (~10-20%) en el dataset de FT
- Usar LoRA en vez de full FT

Scaling Laws del fine-tuning

Los papers de Kaplan (2020) y Chinchilla (2022) mostraron leyes de escalado para pre-training. Para fine-tuning, las leyes son diferentes:

Ganancia ~ (dataset_size)^0.3 × (model_size)^(-0.2)

Implicaciones:
1. Modelos más grandes necesitan MÁS datos de FT para ver mejora
   (porque ya saben más, el margen de mejora es menor)
2. Con pocos datos (<1,000 ejemplos), los modelos pequeños mejoran más
   relativamente, pero los grandes parten de más arriba
3. El rendimiento decreciente llega rápido: ~500 ejemplos → 95% de la mejora

Hay tres formas principales de fine-tunear un modelo. De más a menos coste:

LoRA en detalle

Idea matemática:

  W' = W + ΔW

  Donde W es la matriz de pesos original (congelada).
  En vez de aprender ΔW (que tiene el mismo tamaño que W),
  LoRA lo descompone en:

  ΔW = B × A

  Donde:
  - B es una matriz de tamaño (d × r)
  - A es una matriz de tamaño (r × k)
  - r es el rango (típicamente 4, 8, 16, 64)
  - r << min(d, k)

  Ejemplo: W es 4096 × 4096 (~16.8M parámetros)
  Con r=8: B=4096×8, A=8×4096 → ~65,536 parámetros
  Reducción: 16.8M → 65K (256× menos)

Hiperparámetros clave

Variantes modernas

QLoRA: cuantización + LoRA

QLoRA = Base model en NF4 (4-bit NormalFloat) + LoRA en BFloat16

Ahorro de VRAM:
  - Modelo 70B en FP16: 140 GB  → no cabe en ninguna GPU single
  - Modelo 70B en NF4:  35 GB  → cabe en A6000 (48 GB) o 2× RTX 4090
  - Modelo 7B en NF4:   3.5 GB → cabe en cualquier GPU

Overhead del adaptador LoRA (BF16):
  - r=16 en q_proj+v_proj+o_proj+gate_up_proj: ~33M parámetros
  - ≈ 66 MB adicionales (en BF16)

Pérdida de precisión por cuantización NF4:
  - Perplexity: +0.5-1.0 vs FP16
  - Precisión en benchmark: -0.5% a -2%
  - En la práctica: apenas perceptible para la mayoría de tareas

Métrica de eficiencia

Eficiencia de fine-tuning = mejora en benchmark / VRAM-usada

Full FT en 7B: mejora +8%, VRAM 60 GB → 0.13 ptos/GB
LoRA en 7B:    mejora +7%, VRAM 16 GB → 0.44 ptos/GB
QLoRA en 7B:   mejora +6.5%, VRAM 6 GB → 1.08 ptos/GB

QLoRA es ~8× más eficiente que Full FT por GB de VRAM.

Antes de fine-tunear, pregúntate esto en orden:

Árbol de decisión técnico

¿Necesitas mejorar el modelo?
├── ¿El problema es que NO SABE algo?
│   ├── ¿Está en tus documentos/BD? → RAG
│   └── ¿No está en ninguna parte? → Fine-tuning o pre-training continuo
│
├── ¿El problema es que SABE pero RESPONDE MAL?
│   ├── ¿Falla el formato/estructura? → Fine-tuning
│   ├── ¿Falla el tono/estilo? → Fine-tuning (o system prompt bien hecho)
│   └── ¿Falla en precisión factual? → RAG (probablemente el modelo alucina)
│
├── ¿El problema es COSTE/LATENCIA?
│   ├── ¿Usas API externa cara? → Fine-tunear modelo pequeño local
│   └── ¿Latencia alta? → Fine-tunear modelo pequeño local
│
├── ¿El problema es PRIVACIDAD?
│   └── ¿No puedes mandar datos a API? → Modelo local (con o sin FT)
│
└── ¿El problema es CONSISTENCIA?
    └── ¿El API externa cambia sin avisar? → Fine-tunear modelo pequeño

Checklist antes de fine-tunear

• ✅ Dataset mínimo viable: 200-500 pares (instrucción, respuesta ideal). Si no tienes esto, no empieces.
• ✅ Prueba sin FT: ¿Has probado few-shot con 5 ejemplos en el prompt? ¿Y con RAG?
• ✅ Evaluación antes/después: Define 20-50 casos de prueba ANTES de fine-tunear. Si no puedes medir mejora, no sabrás si funcionó.
• ✅ Baseline: Mide cómo responde el modelo base (sin FT) a esos casos. Si ya acierta el 90%, no necesitas FT.
• ✅ Presupuesto de GPU: ¿Tienes acceso a GPU para entrenar? ¿Cuántas horas/dinero estás dispuesto a invertir?
• ✅ Mantenimiento: ¿Actualizarás el dataset cuando el dominio cambie? El FT no es "una vez y olvidar".

Estrategia de fine-tuning para producción

1. Baseline: prompting + RAG

Mide precisión, latencia y coste del modelo base con prompting cuidadoso y RAG. Esto es tu suelo. Si el FT no mejora esto significativamente, no lo implementes.

2. Iteración ultra-rápida

Fase 1 — Prueba de concepto (1 hora, en Colab o GPU local):
  - 50-100 ejemplos
  - QLoRA r=8
  - 1 epoch
  - ¿Mejora apreciable? → Fase 2
  - ¿No mejora? → Revisa el dataset o abandona FT

Fase 2 — Validación (1 día):
  - 200-500 ejemplos curados
  - QLoRA r=16
  - 3 epochs con early stopping
  - Evalúa contra el baseline
  - ¿Mejora >5%? → Fase 3
  - ¿Mejora <5%? → Probablemente no merece la pena

Fase 3 — Producción:
  - Dataset final: 500-2000 ejemplos
  - LoRA r=32 (o DoRA si necesitas más precisión)
  - 3-5 epochs
  - Evalúa en hold-out set
  - Despliega + monitoriza

2. Estrategias avanzadas