El fine-tuning es uno de los términos más recurrentes en cualquier AI roadmap. «Entrenaremos nuestro propio modelo que entenderá nuestro dominio.» En teoría, elegante. En la práctica, hemos visto cómo el mismo proyecto se deshace en siete puntos distintos — y cada vez por una razón diferente. Este artículo no trata de cómo hacer fine-tuning — trata de por qué la mayoría de intentos no llega a producción, y de cómo evitar esas trampas antes de gastar tiempo y presupuesto.
Si aún estás valorando si recurrir al fine-tuning o más bien al RAG, lee primero RAG vs fine-tuning — cómo decidir. Las causas de fallo que describimos a continuación empiezan precisamente ahí.
---
1. Pocos datos — o datos de baja calidad
Esta es la causa de fallo más frecuente. El equipo recopila lo que tiene a mano — unos cientos de documentos internos, un export del CRM, algunos correos exportados — y arranca el entrenamiento. El resultado es un modelo que responde mal con alta confianza: peor que el modelo base, que al menos sabe decir «no sé».
La investigación ha demostrado (LIMA y otros trabajos) que un número relativamente pequeño de ejemplos de alta calidad — del orden de mil — puede producir un modelo mejor que decenas de miles de ejemplos de baja calidad. La cantidad sin calidad es, en este caso, activamente perjudicial.
Escala orientativa:
- SFT (supervised fine-tuning): mínimo ~1 000 pares pregunta–respuesta o task-completion de alta calidad, con cobertura de los temas principales de tu dominio. Los sistemas en producción suelen estar en 10 000–100 000 ejemplos.
- DPO (preference tuning): ~2 000 pares de preferencia con winner/loser verificado por un humano.
- GRPO (RL-based tuning): ~1 000 trayectorias puntuadas con recompensas verificables.
Además del número, importa la cobertura — si tu KB (base de conocimiento) no tiene suficientes ejemplos de un subdominio concreto, el modelo será un alucinador en esa área. Por eso recomendamos hacer un topic coverage audit antes de lanzar el entrenamiento: lista las categorías principales de preguntas que resolverá el modelo y comprueba que tienes muestra suficiente en cada una.
---
2. Overfitting — el modelo solo sabe lo que ha visto
Cuando el dataset es demasiado pequeño o demasiado estrecho y el modelo se entrena sobre él durante demasiado tiempo, aparece el overfitting. El modelo destaca en los ejemplos de entrenamiento, pero ante cualquier desviación — una pregunta formulada de forma ligeramente distinta, un contexto diferente, una entrada inusual — falla por completo o alucina.
Señales de overfitting en la práctica:
- El modelo cita literalmente las muestras de entrenamiento en lugar de generalizar.
- Puntuación alta en datos de entrenamiento, notablemente más baja en ejemplos nuevos.
- El modelo se niega a responder preguntas fuera de la distribución de los datos de entrenamiento en lugar de reconocer la incertidumbre.
Medidas técnicas: monitoriza el validation loss durante el entrenamiento y detén cuando empiece a subir (early stopping). Sigue las métricas de evaluación en el hold-out set, no solo en los datos de entrenamiento. Para datasets pequeños, la regularización y un rank más bajo en los adaptadores LoRA (p.ej. rank=8 en lugar de rank=64) es una configuración más adecuada.
---
3. Catastrophic forgetting — el modelo olvida lo que sabía
El fine-tuning sobre datos de dominio estrecho puede degradar las capacidades generales del modelo — la capacidad de razonar, resumir, argumentar en inglés u otros idiomas, la lógica básica. Este fenómeno se llama catastrophic forgetting (olvido catastrófico) y está bien documentado.
En la práctica se manifiesta así: con el fine-tuning sobre documentos técnicos internos consigues que el modelo responda muy bien a preguntas de tu área — pero deja de funcionar en tareas generales que antes resolvía sin problema. Los clientes que no conocen este fenómeno lo interpretan como «el modelo se ha roto».
Lo que mitiga el problema, aunque no lo elimina:
- LoRA / QLoRA — los adaptadores modifican solo un pequeño número de parámetros, los pesos originales quedan congelados. Esta es la forma práctica más eficaz de limitar el forgetting.
- Merging — el modelo fine-tuned se fusiona con el modelo base mediante herramientas como
mergekit(SLERP, TIES). El resultado equilibra conocimiento de dominio y capacidades generales. - Diversificación del dataset — incluir ejemplos de propósito general en el dataset de entrenamiento junto con los de dominio.
Para sectores regulados (medicina, derecho, farmacia) el forgetting es especialmente crítico — un modelo que ha olvidado la lógica y los patrones de seguridad puede producir outputs que parecen correctos en forma pero son factualmente erróneos.
---
4. Elección incorrecta del método — full fine-tuning donde basta LoRA, o al revés
Los equipos que empiezan con fine-tuning tienden a ir a un extremo (fine-tuning completo, que requiere recursos GPU enormes) o, al contrario, a elegir la variante más económica sin pensar en los trade-offs.
Resumen orientativo de necesidades de VRAM para un modelo 7B:
- Fine-tuning completo (BF16): ~70–120 GB — requiere servidor multi-GPU
- LoRA (16-bit): ~15 GB — A100 o una RTX 4090 (24 GB VRAM)
- QLoRA (4-bit): ~5 GB — cabe en una RTX 3090 con 24 GB VRAM
LoRA alcanza típicamente ~90–95 % de la calidad del fine-tuning completo con una demanda de memoria 10–20× menor. Para la mayoría de casos de uso de dominio esto es suficiente — recurrir al fine-tuning completo sin una justificación clara es un derroche de recursos.
Por otro lado, hay casos en los que LoRA no es suficiente: cuando se modifica el tokenizador, cuando se trata de idiomas con morfología muy distinta de los datos de entrenamiento, o en «continued pretraining» profundo (construcción de conocimiento de dominio a partir de textos no etiquetados). La elección del método debe partir del objetivo concreto, no de lo que se ejecutó primero por casualidad. Un análisis más detallado en el artículo LoRA vs QLoRA vs full fine-tuning.
---
5. Fine-tuning en lugar de RAG — la herramienta equivocada para la tarea equivocada
Este es posiblemente el error más costoso con el que nos encontramos. El equipo quiere que el modelo «sepa» sobre sus productos, documentos, procesos internos. El fine-tuning parece la respuesta natural. Lo lanzan, vuelcan los datos en el entrenamiento y, pocas semanas después, descubren que el modelo sigue alucinando hechos — porque el fine-tuning no añade hechos al modelo de forma fiable.
El fine-tuning es la herramienta adecuada para:
- Cambiar el formato y el estilo de las respuestas (p.ej. devolver siempre JSON con un esquema concreto).
- Cambiar el comportamiento (p.ej. el modelo debe rechazar siempre ciertos tipos de solicitudes, o debe mantener un tono de comunicación específico).
- Adaptación a un dominio especializado en el que el modelo base no tiene suficientes datos de entrenamiento (p.ej. jerga industrial estrecha, formatos propietarios).
RAG (Retrieval-Augmented Generation — generación aumentada por recuperación) es la herramienta adecuada para:
- Acceso a información actualizada o cambiante.
- Responder preguntas a partir de documentos concretos.
- Trazabilidad de la respuesta hasta la fuente (cita, grounding).
En la práctica: si tu objetivo es «el modelo debe saber responder preguntas sobre nuestro catálogo de productos» — ese es un caso de uso RAG, no de fine-tuning. El fine-tuning lo aplicarías si quieres que el modelo use tu formato de respuesta específico o la terminología del sector.
---
6. Sin evaluación — no sabemos si hemos ganado o perdido
Un escenario sorprendentemente habitual: el equipo lanza el fine-tuning, el modelo se entrena, parece «mejor» en unos pocos ejemplos probados manualmente, y se despliega a producción. Un mes después llegan las quejas por regresión — el modelo deja de funcionar en casos que antes resolvía sin problema.
Sin una evaluación sistemática (valoración de la calidad del modelo) no sabemos:
- 1.Si el fine-tuning ayudó en absoluto — comparación con el modelo base.
- 2.Si hemos provocado una regresión — rendimiento en casos que antes funcionaban.
- 3.Dónde falla exactamente el modelo — en qué categorías de preguntas.
El framework de evaluación mínimo antes del despliegue a producción incluye:
- Hold-out test set — ~10–20 % de los datos que no estuvieron ni en el conjunto de entrenamiento ni en el de validación. Se mide sobre ellos tras el entrenamiento.
- Comparación con baseline — las mismas preguntas en el modelo base y en la versión fine-tuned. Regresión = si el modelo fine-tuned puntúa más bajo en casos donde el modelo base funcionaba.
- Métricas específicas de la tarea — no solo la perplejidad (métrica técnica de machine learning), sino métricas relevantes para tu caso de uso: precisión de extracciones, corrección del formato, calificación de calidad por un experto de dominio.
Más detalle sobre cómo configurar la evaluación: Cómo medir si el fine-tuning ha ayudado.
---
7. Expectativas irreales — el fine-tuning no es un milagro
La última causa, y en muchos sentidos la más importante. El fine-tuning se vende a menudo en presentaciones internas como la solución que convierte un LLM genérico en un experto en tu área. En la práctica es más matizado:
- Un modelo fine-tuned de 4B–8B puede superar a un modelo genérico de 70B+ en una tarea estrechamente definida — pero solo si la tarea está realmente bien acotada, los datos son de calidad y la evaluación lo confirma.
- El fine-tuning no mejora el razonamiento — si el modelo base no sabe resolver cierto tipo de tareas lógicas, el fine-tuning sobre datos de dominio no lo cambiará. Para el razonamiento son adecuados métodos como GRPO con recompensas verificables. Más en el artículo SFT, DPO, GRPO — qué método y cuándo.
- El fine-tuning no es un proyecto de una sola vez — los datos cambian, el modelo envejece, las regresiones se acumulan. Sin infraestructura para ciclos repetibles de entrenamiento-evaluación-despliegue el proyecto se desintegra progresivamente.
- Las alucinaciones persisten — el fine-tuning puede reducirlas en un dominio específico, pero no las elimina. Los guardrails, el RAG grounding y el human-in-the-loop siguen siendo necesarios allí donde la corrección importa.
Los equipos que conocen estos límites antes de comenzar el proyecto terminan con modelos utilizables. Los equipos que descubren los límites después de seis meses de desarrollo suelen cancelar el proyecto.
---
Resumen: checklist antes de lanzar el proyecto
Antes de decidir lanzar un proyecto de fine-tuning, recomendamos repasar estas siete preguntas:
- 1.¿Tienes un dataset suficiente? — número de ejemplos, cobertura de temas, calidad verificada.
- 2.¿Es el fine-tuning la herramienta adecuada? — ¿o bastaría RAG o prompt engineering?
- 3.¿Tienes la evaluación configurada? — hold-out set, baseline, métricas específicas de la tarea.
- 4.¿Tienes infraestructura GPU? — o un plan realista de entrenamiento en cloud con estimación de costes.
- 5.¿Estás preparado para iterar? — una sola pasada de fine-tuning no es suficiente, el pipeline debe ser repetible.
- 6.¿Tienes un experto de dominio en el bucle? — quién verifica que el modelo responde correctamente, no solo con fluidez.
- 7.¿Tienes un plan para el forgetting y las regresiones? — monitorización, rollback, evaluación tras cada nuevo ciclo de entrenamiento.
Si alguna de estas preguntas no tiene respuesta clara, el proyecto no está listo para lanzarse — solo para prepararse.
---
Preguntas frecuentes
¿Por qué mi modelo fine-tuned responde peor que el modelo base?
La causa más frecuente es el overfitting sobre un dataset pequeño o de baja calidad. El modelo aprende «patrones» de los datos de entrenamiento, pero la generalización a nuevas entradas falla. Solución: aumentar la calidad de los datos, usar early stopping, reducir el rank del adaptador LoRA, o replantear todo el proyecto desde la perspectiva de RAG vs fine-tuning.
¿Cuántos ejemplos necesito realmente para el fine-tuning?
Para SFT es posible obtener un resultado funcional desde ~1 000 ejemplos de alta calidad, pero los sistemas en producción suelen estar en 10 000–100 000. Más importante que la cantidad es la cobertura — si falta muestra suficiente en categorías clave, el modelo será poco fiable en esas áreas independientemente del número total de ejemplos.
¿Es el fine-tuning adecuado para actualizar el conocimiento del modelo (nuevos productos, precios, registros)?
No. El fine-tuning almacena hechos de forma poco fiable — el modelo puede insinuar información del entrenamiento, pero la mezcla con alucinaciones. Para conocimiento que cambia o debe ser verificable, la herramienta correcta es RAG con una base de documentos actualizada.
¿Puede un modelo fine-tuned pequeño superar a un modelo genérico grande?
Sí — bajo condiciones concretas. Un modelo fine-tuned de 4B–8B puede superar a un modelo genérico de 70B+ en una tarea estrechamente definida, si la tarea está bien acotada, el dataset es de calidad y la evaluación lo confirma. En tareas amplias y generales, el modelo más grande suele ganar.
¿Qué es el catastrophic forgetting y cómo prevenirlo?
El catastrophic forgetting es el fenómeno por el cual el fine-tuning sobre datos estrechos degrada las capacidades generales del modelo — idiomas, lógica, razonamiento. La medida más eficaz es LoRA o QLoRA, que modifican solo un pequeño número de parámetros y preservan los pesos originales. Como complemento ayuda el merging del modelo fine-tuned con el modelo base mediante la herramienta mergekit.
---
*MP Industrial Solutions ayuda a las empresas a distinguir cuándo el fine-tuning tiene sentido real y cuándo existe un camino más sencillo y económico. Si estás valorando la adaptación de dominio de un LLM, estaremos encantados de evaluar tu caso de uso — desde el dataset hasta la infraestructura y la evaluación.*