Guía Teórica: Fine-Tuning de LLMs

1. Fundamentos del Fine-Tuning

1.1 ¿Qué es Fine-Tuning y Por Qué lo Necesitamos?

El fine-tuning es el proceso de adaptar un modelo pre-entrenado a una tarea o dominio específico. Piensa en un modelo base como alguien que terminó la universidad con conocimiento general amplio. El fine-tuning es como la especialización profesional que lo convierte en experto en un área específica.

¿Por qué no usar el modelo base directamente?

Los modelos base están entrenados en texto general de internet, Wikipedia, libros, etc. Esto significa que no conocen la terminología específica de tu industria, no entienden los matices de tu caso de uso, pueden generar respuestas genéricas en lugar de especializadas, y no siguen el formato o estilo que tu negocio requiere.

Ejemplo concreto para cobranzas:

Un modelo base ante «El cliente dice que ya pagó» podría responder con información genérica sobre disputas de pago. Un modelo fine-tuneado con datos de tu operación sabría que debe verificar en el sistema, ofrecer enviar comprobante, y seguir el protocolo específico de tu empresa.

1.2 El Espectro de Adaptación

Existen diferentes niveles de adaptación, ordenados de menor a mayor intervención.

Prompt Engineering no modifica el modelo, solo optimiza cómo le pedimos las cosas. Es rápido y sin costo de entrenamiento, pero tiene capacidad limitada de especialización.

Few-Shot Learning incluye ejemplos en el prompt para guiar al modelo. Tampoco modifica el modelo, pero consume tokens del contexto disponible.

Fine-Tuning modifica los pesos del modelo con datos específicos. Requiere datos y cómputo, pero logra especialización profunda y permanente.

Pre-training desde cero entrena un modelo completamente nuevo. Requiere recursos masivos y rara vez es necesario.

Para la mayoría de casos empresariales, el fine-tuning es el punto óptimo entre costo y beneficio.

---

2. Técnicas de Fine-Tuning

2.1 Full Fine-Tuning (Entrenamiento Completo)

Concepto:

En el full fine-tuning, actualizamos TODOS los parámetros del modelo durante el entrenamiento. Si el modelo tiene 7 mil millones de parámetros, los 7 mil millones se modifican.

El proceso matemático:

Durante el entrenamiento, para cada ejemplo calculamos la pérdida (qué tan lejos está la predicción del objetivo), luego calculamos gradientes (cómo cada parámetro contribuye al error), y finalmente actualizamos todos los parámetros en la dirección que reduce el error.

La actualización sigue la fórmula: θ_nuevo = θ_anterior - learning_rate × gradiente

Donde θ representa todos los parámetros del modelo.

Ventajas:

El modelo puede adaptarse completamente a tu dominio, logra el máximo potencial de especialización, y no hay restricciones en qué puede aprender.

Desventajas:

Los requisitos de memoria son enormes. Para un modelo de 7B parámetros necesitas aproximadamente 28 GB solo para los pesos del modelo en FP32, más 28 GB para gradientes, más 56 GB para estados del optimizador Adam. Esto suma unos 112 GB de VRAM, lo cual es impráctico para la mayoría.

También existe alto riesgo de «catastrophic forgetting», donde el modelo olvida capacidades generales al especializarse demasiado. El entrenamiento es lento y costoso, y necesitas guardar una copia completa del modelo por cada versión.

Cuándo usar Full Fine-Tuning:

Úsalo cuando tienes recursos de cómputo significativos (múltiples GPUs A100), cuando necesitas máxima adaptación al dominio, cuando el dominio es muy diferente del entrenamiento original, o para crear un modelo base interno de la organización.

2.2 LoRA (Low-Rank Adaptation)

La Intuición:

LoRA parte de una observación clave de la investigación: cuando fine-tuneas un modelo, los cambios en los pesos tienen «low intrinsic rank», es decir, la información nueva que el modelo necesita aprender puede representarse en un espacio de mucha menor dimensión.

Imagina que tienes una matriz de 4096 × 4096 (16 millones de parámetros). LoRA dice que los cambios necesarios para adaptar esa matriz pueden aproximarse con dos matrices mucho más pequeñas: una de 4096 × 16 y otra de 16 × 4096 (solo 131 mil parámetros, menos del 1%).

La Matemática:

En el modelo original, una capa linear computa: h = W₀x

Donde W₀ es la matriz de pesos pre-entrenada de dimensión d × k.

En full fine-tuning, actualizaríamos W₀ directamente: h = (W₀ + ΔW)x

LoRA descompone ΔW en dos matrices de bajo rango: ΔW = BA

Donde B tiene dimensión d × r y A tiene dimensión r × k, con r << min(d, k).

El forward pass se convierte en: h = W₀x + BAx

El parámetro r (rank):

El rank r controla la capacidad de adaptación. Un r más bajo significa menos parámetros, entrenamiento más rápido, pero menor capacidad expresiva. Un r más alto permite cambios más complejos pero requiere más memoria.

Valores típicos van de r=8 para tareas simples como clasificación hasta r=64 para adaptaciones complejas como cambio de dominio completo. El valor r=16 es un buen punto de partida general.

¿A qué capas aplicar LoRA?

No todas las capas del Transformer contribuyen igual a la adaptación.

Las capas de Query y Value (q_proj, v_proj) en attention son las más importantes, casi siempre se incluyen. Las capas de Key y Output (k_proj, o_proj) son secundarias, incluir si tienes presupuesto de parámetros. Las capas Feed-Forward (mlp) capturan conocimiento factual, útiles para adaptación de dominio. Las capas de Embedding rara vez se modifican con LoRA.

Una configuración común es aplicar LoRA a q_proj, v_proj, k_proj, o_proj con r=16.

Ventajas de LoRA:

La reducción de memoria es dramática, típicamente 10-100x menos parámetros entrenables. El modelo base permanece intacto, evitando catastrophic forgetting. Puedes tener múltiples adaptadores LoRA para diferentes tareas. Es fácil hacer merge del adaptador al modelo base para deployment.

Desventajas de LoRA:

Existe un techo de rendimiento, ya que tareas muy complejas pueden requerir full fine-tuning. Requiere experimentación para encontrar el rank óptimo. No todos los frameworks lo soportan igual de bien.

2.3 QLoRA (Quantized LoRA)

El Problema que Resuelve:

LoRA reduce los parámetros entrenables, pero aún necesitas cargar el modelo base completo en memoria para el forward pass. Un modelo de 7B en FP16 todavía necesita 14 GB de VRAM.

QLoRA combina cuantización del modelo base con LoRA para reducir dramáticamente los requisitos de memoria.

Componentes Clave de QLoRA:

El primer componente es la cuantización a 4 bits (NF4). En lugar de FP16 (16 bits por parámetro), QLoRA usa un formato especial llamado NormalFloat 4-bit. Este formato está optimizado para la distribución típica de pesos en redes neuronales, que tiende a ser normal (gaussiana). Un modelo de 7B pasa de 14 GB a aproximadamente 3.5 GB.

El segundo componente es Double Quantization. Los parámetros de cuantización también se cuantizan, lo que ahorra memoria adicional (aproximadamente 0.5 GB para un modelo de 7B).

El tercer componente son los Paged Optimizers. Usa memoria paginada de CPU para manejar picos de memoria durante el entrenamiento, permitiendo entrenar con menos VRAM.

El cuarto componente es LoRA sobre modelo cuantizado. Solo los adaptadores LoRA están en precisión completa (FP16 o BF16) y son los únicos que se entrenan.

El Flujo de Cómputo:

Durante el forward pass, los pesos cuantizados se des-cuantizan on-the-fly para el cálculo. El resultado se combina con la salida de los adaptadores LoRA. Durante el backward pass, solo se calculan gradientes para los parámetros LoRA. El modelo base cuantizado no se modifica.

Impacto en Rendimiento:

La cuantización a 4 bits introduce algo de error, pero los estudios muestran que la pérdida de calidad es mínima (1-2% en benchmarks) comparado con LoRA en FP16. Para la mayoría de aplicaciones prácticas, la diferencia es imperceptible.

Requisitos de Hardware:

Con QLoRA, puedes fine-tunear un modelo de 7B con 6-8 GB de VRAM (una RTX 3060 o T4 de Colab). Un modelo de 13B necesita aproximadamente 10-12 GB. Un modelo de 70B requiere aproximadamente 48 GB, lo cual es factible con una A100.

Esto democratiza el fine-tuning, permitiendo que equipos sin infraestructura masiva puedan adaptar modelos grandes.

2.4 Comparativa de Técnicas

Recomendación General:

Para la mayoría de casos empresariales, QLoRA es la mejor opción. Ofrece el mejor balance entre calidad, costo y accesibilidad. Reserva full fine-tuning para casos donde QLoRA no logre el rendimiento necesario y tengas los recursos disponibles.

---

3. Preparación de Datasets para Entrenamiento

3.1 La Importancia del Dataset

El dataset es el factor más crítico en fine-tuning. Un modelo mediocre con datos excelentes supera a un modelo excelente con datos mediocres. La regla de «garbage in, garbage out» aplica con fuerza.

3.2 Formatos de Dataset

Formato Instrucción-Respuesta (el más común):

Este formato tiene tres componentes. La instrucción o prompt es lo que el usuario pide. El input opcional es contexto adicional. La respuesta o output es lo que el modelo debe generar.

Un ejemplo para clasificación de intenciones sería tener como instrucción «Clasifica la intención del cliente en una de estas categorías: pago, reclamo, negociación, evasión», como input «Cliente: ‘Voy a depositar mañana los 2000 soles que debo'», y como output «pago».

Formato Conversacional (para chatbots):

Este formato consiste en turnos de mensajes con roles de system, user y assistant. Es ideal para mantener contexto de conversación y entrenar comportamientos específicos de chat.

Formato Completion (para generación):

Este formato tiene solo un prompt y un completion. Es más simple pero menos estructurado. Útil para tareas de generación pura sin instrucciones explícitas.

3.3 Cantidad de Datos Necesarios

Reglas Generales:

Para clasificación simple con pocas categorías, entre 200 y 500 ejemplos por categoría suele ser suficiente. Para clasificación compleja con muchas categorías o matices sutiles, necesitas entre 500 y 2000 ejemplos por categoría. Para generación con estilo específico, al menos 1000 ejemplos de alta calidad. Para adaptación de dominio técnico, entre 5000 y 10000 ejemplos diversos.

La Curva de Aprendizaje:

La mejora no es lineal con más datos. Típicamente se ve una mejora dramática con los primeros 500-1000 ejemplos, luego mejoras decrecientes hasta los 5000-10000, y después un plateau donde más datos ayudan marginalmente. Es mejor tener 1000 ejemplos de alta calidad que 10000 de baja calidad.

3.4 Calidad del Dataset

Criterios de Calidad:

La precisión significa que las etiquetas y respuestas deben ser correctas. Un solo error puede enseñar el comportamiento incorrecto al modelo.

La consistencia implica que ejemplos similares deben tener respuestas similares. La inconsistencia confunde al modelo durante el entrenamiento.

La diversidad requiere cubrir la variedad de casos que el modelo encontrará. No solo los casos fáciles o comunes.

La representatividad significa que la distribución del dataset debe reflejar la distribución real de uso.

La completitud implica que las respuestas deben ser completas, no truncadas o parciales.

Errores Comunes a Evitar:

El desbalance extremo ocurre cuando tienes 90% de una clase y 10% de otras, lo que sesga el modelo hacia la clase mayoritaria. La solución es balancear mediante oversampling, undersampling, o pesos de clase.

Las etiquetas ruidosas son errores de etiquetado que confunden al aprendizaje. Incluso un 5% de error en etiquetas puede degradar significativamente el rendimiento.

El data leakage sucede cuando información del test set contamina el entrenamiento. Siempre separa los datos ANTES de cualquier preprocesamiento.

La falta de ejemplos difíciles ocurre cuando solo incluyes casos claros y el modelo no aprende a manejar ambigüedad. Incluye deliberadamente casos edge y ambiguos.

3.5 Preparación Práctica

Pipeline de Preparación:

El primer paso es la recolección donde defines fuentes de datos, ya sean logs de conversaciones, tickets de soporte, o datos sintéticos.

El segundo paso es la limpieza donde remueves duplicados, corriges errores obvios, y normalizas formatos.

El tercer paso es el etiquetado donde defines guías de anotación claras y usas múltiples anotadores si es posible (inter-annotator agreement).

El cuarto paso es la validación donde revisas una muestra manualmente y calculas métricas de calidad del dataset.

El quinto paso es la división donde separas en train (80%), validation (10%), y test (10%). La estratificación mantiene la proporción de clases en cada split.

El sexto paso es el formateo donde conviertes al formato requerido por tu framework de entrenamiento.

Ejemplo de División Estratificada para Cobranzas:

Si tu dataset tiene 40% pago, 25% reclamo, 20% negociación, y 15% evasión, cada split debe mantener aproximadamente estas proporciones. No dejes todo el «evasión» en test por accidente.

3.6 Data Augmentation para NLP

Técnicas Aplicables:

El parafraseo usa un modelo para generar variaciones del mismo mensaje. Por ejemplo, «Voy a pagar mañana» se puede convertir en «Mañana hago el pago» o «El depósito lo hago mañana».

La back-translation traduce a otro idioma y de vuelta, generando variaciones naturales.

La sustitución de sinónimos reemplaza palabras por sinónimos manteniendo el significado.

Los datos sintéticos usan un LLM más grande para generar ejemplos adicionales. Útil pero cuidado con amplificar sesgos del modelo generador.

Cuándo Usar Augmentation:

Úsalo cuando tienes pocas muestras de alguna categoría, para casos edge difíciles de recolectar naturalmente, y para mejorar robustez a variaciones de entrada. Evítalo si ya tienes suficientes datos reales y para categorías donde la variación sintética podría introducir ruido.

---

4. Hiperparámetros Clave

4.1 Learning Rate

El Más Importante:

El learning rate controla qué tan grandes son los pasos de actualización de pesos. Es el hiperparámetro más crítico y el que más impacta el entrenamiento.

Si es muy alto, el entrenamiento diverge, la pérdida oscila o aumenta, y el modelo «salta» sobre el mínimo óptimo. Si es muy bajo, el entrenamiento es muy lento, puede quedarse atascado en mínimos locales, y nunca alcanza buen rendimiento.

Valores Típicos:

Para full fine-tuning se usa entre 1e-5 y 5e-5. Para LoRA/QLoRA se usa entre 1e-4 y 3e-4, más alto porque hay menos parámetros que mover. El valor 2e-4 es un buen punto de partida para LoRA.

Learning Rate Schedulers:

El constant mantiene el LR fijo durante todo el entrenamiento. Es simple pero no óptimo.

El linear decay comienza alto y decrece linealmente hasta cero. Permite exploración inicial y refinamiento final.

El cosine sigue una curva coseno, decreciendo suavemente. Muy popular, funciona bien en práctica.

El warmup + decay empieza bajo, sube gradualmente durante los primeros pasos (warmup), luego decrece. Estabiliza el entrenamiento inicial. Se recomienda warmup del 3-10% de los pasos totales.

4.2 Batch Size

Concepto:

El batch size determina cuántos ejemplos procesas antes de actualizar los pesos. Afecta tanto la estabilidad del entrenamiento como los requisitos de memoria.

Trade-offs:

Un batch grande proporciona gradientes más estables (promedio de más ejemplos), mejor utilización del hardware (paralelismo), pero requiere más memoria. Un batch pequeño significa más ruido en gradientes (puede ayudar a escapar mínimos locales), menos memoria requerida, pero entrenamiento potencialmente menos estable.

Gradient Accumulation:

Si no tienes memoria para batch size grande, simúlalo con gradient accumulation. En lugar de actualizar pesos después de 1 batch de 32, acumulas gradientes de 8 batches de 4 y luego actualizas. Matemáticamente equivalente, pero cabe en memoria.

El effective batch size se calcula como: batch_size × gradient_accumulation_steps × num_gpus

Valores Recomendados:

El effective batch size típico está entre 16 y 64 para fine-tuning. Para LoRA/QLoRA, usa el máximo que quepa en memoria con gradient accumulation.

4.3 Epochs

Definición:

Un epoch es una pasada completa por todo el dataset de entrenamiento. El número de epochs determina cuántas veces el modelo ve cada ejemplo.

¿Cuántos Epochs?

Para fine-tuning de LLMs, típicamente 1-5 epochs son suficientes. Más puede causar overfitting. El punto óptimo depende del tamaño del dataset: con datasets pequeños (menos de 1000 ejemplos) usa 3-5 epochs, con datasets medianos (1000-10000 ejemplos) usa 2-3 epochs, y con datasets grandes (más de 10000 ejemplos) usa 1-2 epochs.

Early Stopping:

No fijes epochs arbitrariamente. Usa early stopping para detener el entrenamiento cuando la pérdida en validación deja de mejorar. Paciencia típica es de 2-3 evaluaciones sin mejora.

4.4 Parámetros Específicos de LoRA

Rank (r):

Controla la dimensionalidad de la adaptación. Para r=8, tienes alta eficiencia de parámetros pero menor capacidad. Para r=16, es un buen balance general. Para r=32 o r=64, hay mayor capacidad pero más parámetros. Empieza con r=16 y ajusta según resultados.

Alpha (lora_alpha):

Factor de escalado para los pesos LoRA. La actualización efectiva es: ΔW = (alpha/r) × BA. Valores comunes son alpha igual a r (escalado 1x), alpha igual a 2r (escalado 2x, más agresivo), o alpha igual a 16 con r=16 es un default común.

Dropout:

Se aplica a las capas LoRA durante entrenamiento. Ayuda a prevenir overfitting. Valores típicos están entre 0.05 y 0.1. Con datasets pequeños, usa valores más altos (0.1-0.2).

Target Modules:

Qué capas reciben adaptadores LoRA. El mínimo efectivo es q_proj y v_proj. El recomendado incluye también k_proj y o_proj. Para más capacidad, agrega las capas MLP (gate_proj, up_proj, down_proj).

4.5 Otros Hiperparámetros

Weight Decay:

Regularización L2 que penaliza pesos grandes. Ayuda a prevenir overfitting. Valor típico está entre 0.01 y 0.1.

Max Sequence Length:

Longitud máxima de secuencias de entrada. Afecta memoria cuadráticamente debido a attention. Usa el mínimo necesario para tu tarea. Para clasificación, 256-512 suele ser suficiente. Para generación, puede necesitarse 1024-2048.

Warmup Ratio:

Proporción de pasos iniciales con learning rate creciente. Estabiliza el entrenamiento temprano. Valor típico está entre 0.03 y 0.1.

4.6 Estrategia de Búsqueda de Hiperparámetros

Enfoque Práctico:

Empieza con defaults razonables basados en tu técnica (LoRA, QLoRA) y tamaño de modelo. Haz una corrida inicial completa para establecer baseline. Ajusta learning rate primero, es el más impactante. Luego ajusta epochs y batch size. Finalmente, optimiza parámetros específicos de LoRA si aplica.

Valores Iniciales Recomendados para QLoRA de modelo 7B:

Learning rate de 2e-4, batch size de 4 con gradient accumulation de 4 para effective batch de 16, epochs de 3 con early stopping, LoRA rank de 16, LoRA alpha de 32, LoRA dropout de 0.05, y target modules de q_proj, v_proj, k_proj, o_proj.

---

5. Evaluación y Prevención de Overfitting

5.1 ¿Qué es Overfitting?

El overfitting ocurre cuando el modelo memoriza los datos de entrenamiento en lugar de aprender patrones generalizables. El síntoma clásico es una pérdida de entrenamiento que baja mientras la pérdida de validación sube.

En el contexto de LLMs, el overfitting puede manifestarse como respuestas que replican verbatim ejemplos del training, incapacidad de manejar variaciones de los inputs vistos, degradación de capacidades generales del modelo (catastrophic forgetting), y confianza excesiva en predicciones incorrectas.

5.2 Métricas de Evaluación

Para Clasificación:

La Accuracy es la proporción de predicciones correctas. Es simple pero engañosa con clases desbalanceadas.

Precision responde a la pregunta «de los que predije como positivos, ¿cuántos realmente lo son?» Se calcula como TP/(TP+FP). Es importante cuando el costo de falsos positivos es alto.

Recall responde a la pregunta «de los que realmente son positivos, ¿cuántos identifiqué?» Se calcula como TP/(TP+FN). Es importante cuando el costo de falsos negativos es alto.

F1-Score es la media armónica de precision y recall, calculada como 2 × (P×R)/(P+R). Balancea ambas métricas.

Macro F1 promedia F1 por clase, dando igual peso a todas las clases.

Weighted F1 promedia F1 ponderado por el número de ejemplos de cada clase.

Para Generación:

Perplexity mide qué tan «sorprendido» está el modelo por el texto. Se calcula como exp(loss). Un valor más bajo es mejor e indica que el modelo predice bien el siguiente token.

BLEU/ROUGE miden solapamiento con respuestas de referencia. Útil pero tiene limitaciones ya que no captura equivalencia semántica.

BERTScore usa embeddings para medir similitud semántica. Mejor que BLEU para capturar parafraseo.

Evaluación Humana sigue siendo el gold standard para calidad de generación. Considera claridad, relevancia, factualidad, y utilidad.

5.3 Estrategia de Evaluación

División de Datos:

El Training Set (80%) se usa para entrenar el modelo. El Validation Set (10%) sirve para monitorear durante entrenamiento, ajustar hiperparámetros, y decidir early stopping. El Test Set (10%) es la evaluación final, no tocar hasta el final, y simula rendimiento en producción.

Importancia del Test Set:

Nunca uses el test set para tomar decisiones de entrenamiento. Si lo haces, ya no es una estimación válida del rendimiento en datos nuevos. Es fácil caer en «overfitting al test set» ajustando hiperparámetros hasta que el test mejore.

Cross-Validation para Datasets Pequeños:

Con menos de 1000 ejemplos, usa k-fold cross-validation (típicamente k=5). Entrenas k modelos, cada uno con un fold diferente como validación. Reportas media y desviación estándar de métricas.

5.4 Señales de Overfitting

En las Curvas de Entrenamiento:

El overfitting leve se observa cuando la pérdida de validación se aplana mientras la de training sigue bajando.

El overfitting moderado aparece cuando la pérdida de validación empieza a subir mientras la de training baja.

El overfitting severo se manifiesta con una brecha grande entre training y validation, con training casi en cero.

En el Comportamiento del Modelo:

Hay memorización cuando genera respuestas exactas del dataset para inputs similares. Hay falta de generalización cuando falla con variaciones menores del input. Hay pérdida de capacidades cuando tareas que el modelo base hacía bien ahora fallan. Hay sobreconfianza cuando tiene alta probabilidad en predicciones incorrectas.

5.5 Técnicas de Prevención

Regularización:

El Weight Decay añade penalización L2 a los pesos, evitando que crezcan demasiado. Se usa un valor de 0.01-0.1.

El Dropout apaga aleatoriamente neuronas durante entrenamiento, forzando redundancia. En LoRA usa 0.05-0.1.

Early Stopping:

Monitorea la pérdida de validación. Detén cuando no mejore por N evaluaciones consecutivas, donde N típicamente es 2-3. Guarda el checkpoint con mejor validación, no el último.

Reducir Capacidad del Modelo:

Para LoRA, usa un rank menor. Para full fine-tuning, congela más capas. Menos parámetros entrenables significa menos capacidad de memorizar.

Data Augmentation:

Más variedad en datos hace más difícil memorizar. Incluso augmentation simple como parafraseo ayuda.

Reducir Epochs:

El overfitting empeora con más pasadas por los datos. A menudo, 2-3 epochs son suficientes para LLMs.

5.6 Evaluación de Catastrophic Forgetting

El Problema:

Al fine-tunear, el modelo puede «olvidar» capacidades que tenía antes. Es más severo en full fine-tuning que en LoRA.

Cómo Detectarlo:

Mantén un conjunto de evaluación de tareas generales. Compara el rendimiento del modelo base versus el fine-tuneado en estas tareas. Una degradación significativa indica forgetting.

Ejemplos de Tareas Generales para Evaluar:

Comprensión de lectura básica, aritmética simple, conocimiento factual general, seguimiento de instrucciones básicas, y traducción simple.

Mitigación:

LoRA/QLoRA ayudan porque no modifican el modelo base. También puedes mezclar datos de tareas generales en el fine-tuning (típicamente 5-10% del dataset), o usar regularización para mantener los pesos cerca de los originales.

5.7 Evaluación en Producción

No Termina con el Test Set:

El rendimiento real puede diferir del test set por distribución diferente de datos reales, usuarios interactuando de formas no anticipadas, y drift temporal (el lenguaje y patrones cambian).

Monitoreo Continuo:

Loggea predicciones y métricas en producción. Implementa feedback loops donde usuarios pueden marcar errores. Revisa muestras regularmente de forma manual. Establece alertas para degradación de métricas.

A/B Testing:

Antes de reemplazar un modelo, corre A/B test. Compara métricas de negocio, no solo métricas de ML. El modelo técnicamente «mejor» no siempre es mejor para el negocio.

---

6. Resumen: Checklist para Fine-Tuning

Antes de Empezar

• Primero, ¿fine-tuning es necesario? ¿Probaste prompt engineering y few-shot?
• Segundo, ¿tienes suficientes datos de calidad? Mínimo 500-1000 ejemplos.
• Tercero, ¿los datos están correctamente etiquetados y son consistentes?
• Cuarto, ¿tienes el hardware necesario? Para QLoRA de 7B necesitas al menos 8GB VRAM.

Durante el Entrenamiento

• Primero, monitorea train loss Y validation loss.
• Segundo, usa early stopping con paciencia de 2-3.
• Tercero, guarda checkpoints regularmente.
• Cuarto, verifica que no hay data leakage.

 

Después del Entrenamiento

• Primero, evalúa en test set que nunca se usó antes.
• Segundo, prueba manualmente con ejemplos reales y variados.
• Tercero, compara con baseline (modelo base, reglas simples).
• Cuarto, evalúa catastrophic forgetting en tareas generales.
• Quinto, documenta hiperparámetros y resultados para reproducibilidad.

 

---

7. Puntos Clave para tus Capacitaciones

Mensaje Principal sobre Técnicas:

QLoRA democratizó el fine-tuning. Ya no necesitas una supercomputadora. Con una GPU de gaming puedes adaptar modelos de 7B parámetros a tu dominio específico.

Mensaje Principal sobre Datos:

La calidad del dataset es más importante que la técnica de fine-tuning. Invierte tiempo en datos limpios, bien etiquetados, y diversos. «Garbage in, garbage out» aplica con fuerza.

Mensaje Principal sobre Evaluación:

El overfitting es el enemigo principal del fine-tuning. Monitorea obsesivamente, usa early stopping, y nunca confíes en métricas de training solamente. El rendimiento real se mide en datos que el modelo nunca vio.

Para Ejecutivos:

Fine-tuning permite crear modelos especializados en el dominio de la empresa con una inversión razonable de recursos. El ROI viene de mejor precisión en tareas específicas y reducción de costos de API al usar modelos propios.

Siguiente capítulo: Todo lo que debes saber sobre los RAGs