Primero el marco, que cambió en 2026
Este artículo no se puede abrir con la pregunta habitual de «¿merece la pena?», porque entretanto la pregunta se ha transformado.
La documentación de uno de los mayores proveedores dice literalmente que retira la plataforma de fine-tuning: ya no está disponible para usuarios nuevos, y los existentes todavía pueden lanzar entrenamientos durante unos meses más. La fecha de apagado de los modelos asociados es el 23 de octubre de 2026, y la de la plataforma, el 6 de enero de 2027. No hay sucesor anunciado.
Es decir, en 2026 la pregunta no es solo si merece la pena, sino dónde puedes hacerlo siquiera. La respuesta: sobre un modelo de pesos abiertos, en hardware propio o alquilado, o en otros proveedores.
Para qué sirve y para qué no
La distinción más importante en una sola frase: para meter conocimiento es mejor el RAG; para meter comportamiento, el fine-tuning.
De esto hay medición. En un experimento con tres modelos, donde había que aprender hechos completamente nuevos, el RAG mejoró 39 puntos porcentuales y el fine-tuning no supervisado, 2,3 — y en un modelo incluso empeoró 13 puntos. En palabras de los autores: a los modelos les cuesta aprender información factual nueva con fine-tuning no supervisado. Para el detalle, mira el post pilar RAG explicado , con el estudio.
Pero hay una medición según la cual hacen falta los dos. En una tarea de preguntas y respuestas de un dominio concreto, el fine-tuning mejoró más de 6 puntos porcentuales, y el RAG sumó otros 5 puntos encima, de forma acumulativa. O sea que no es o lo uno o lo otro.
¿Cuándo merece la pena de verdad?
El patrón que sale de las mediciones es inequívoco, y conviene decirlo:
La mayor mejora está siempre donde el modelo es pequeño y la tarea es estrecha.
| Medición | Base | Con fine-tuning | Mejora |
|---|---|---|---|
| Tarea de agent, modelo de 7 mil millones de parámetros | 26,5 % | 73,9 % | +47,4 puntos |
| Lo mismo con 14 mil millones | 79,9 % | 91,0 % | +11,1 puntos |
| Tarea de compra, 7 mil millones | 28,1 | 61,0 | +32,9 puntos |
| Preguntas y respuestas de dominio, modelos grandes | — | — | +6 puntos |
| Llamada a herramientas, modelo de 350 millones | — | 77,6 % | 2,98× frente a un modelo general de 175 mil millones |
Lee juntas las dos primeras filas: la misma intervención vale cuatro veces más en el modelo pequeño que en el grande.
El fine-tuning no hace mejor a un buen modelo: hace suficientemente bueno a uno pequeño. Y justo por eso encaja con la ejecución local: de eso trata el post por qué ejecutar IA en local , con las cuentas.
Hay también una línea de 2026 que aprovecha esto: convertir el retrieval en supervisión en tiempo de entrenamiento. De los errores del agent se extraen notas de ayuda, con ellas se generan soluciones mejores y luego se entrena al modelo pequeño con esas soluciones — quitando las notas, para que las interiorice. Las tres primeras filas de la tabla anterior vienen de ese estudio, y encima trae un 10-47 % de ahorro de tokens.
¿Cuántos datos hacen falta?
| Objetivo | Número de ejemplos |
|---|---|
| Formato, estilo, tono | 50-1.000 |
| Una capacidad nueva | 1.000 – 200.000 |
| Conocimiento nuevo | no hagas fine-tuning: usa RAG |
Según la recomendación oficial, el mínimo técnico son diez ejemplos, pero conviene empezar con cincuenta bien escritos, y la mejora suele empezar a verse a los 50-100 ejemplos.
Una advertencia importante de la misma fuente: si con cincuenta ejemplos no mejora, hay que repensar la tarea o el prompt, no echar más datos.
Y una explicación de por qué pueden bastar tan pocos ejemplos: según una investigación, casi todo el conocimiento de los modelos grandes viene del preentrenamiento, y solo hace falta una cantidad limitada de datos de instruction tuning para que den una salida de calidad. Ese mismo estudio logró resultados competitivos con mil ejemplos cuidadosamente seleccionados.
¿Qué estropea en otro sitio?
Este capítulo es el más importante, porque es el que se cae de la mayoría de los planes.
1. El olvido catastrófico es general, y el modelo más grande olvida más. Según un estudio, el fenómeno se observa de forma generalizada entre mil y siete mil millones de parámetros y, en contra del sentido común, se agrava con el tamaño del modelo. La explicación de los autores: el modelo grande cae desde más arriba.
2. El método ligero olvida menos. El fine-tuning que trabaja con matrices pequeñas añadidas (LoRA) conserva de forma medible mejor las capacidades generales: en una comparación, la media en los tests generales fue de 0,414 tras el fine-tuning completo y de 0,509 tras LoRA.
3. La explicación está en el mecanismo. Según un estudio de 2025, el fine-tuning supervisado reescribe las partes de las capas intermedias donde vive el conocimiento factual, y por eso el modelo se estropea en otro sitio. Los métodos de refuerzo, en cambio, ajustan más bien las matrices de atención y se alejan de forma medible menos del modelo base.
La frase que se puede enunciar: el fine-tuning supervisado no añade, reescribe.
4. Y el hallazgo más dramático. En un experimento de 2025 publicado en una conferencia se hizo fine-tuning a varios modelos para escribir código vulnerable. El resultado: los modelos se estropearon también en preguntas totalmente ajenas a la programación — la proporción media de respuestas desalineadas a esas preguntas fue del 20 %.
El experimento de control es lo más instructivo: cuando el mismo conjunto de datos se enmarcó como «clase de seguridad informática», el fenómeno no apareció. Lo que contó fue el encuadre, no los datos.
De ahí sale una única regla práctica: no basta con medir si el modelo con fine-tuning es bueno en aquello para lo que lo entrenaste. Hay que medir si se ha estropeado en aquello para lo que no.
Los métodos, con números
| Método | Qué entrena | Recursos |
|---|---|---|
| Fine-tuning completo | todos los pesos | la mayor memoria; el mayor olvido |
| LoRA | matrices pequeñas añadidas | una fracción de memoria; menos olvido |
| QLoRA | lo mismo, sobre un modelo base cuantizado | la menor memoria |
Según el anuncio original de la variante cuantizada, el método «ahorra memoria suficiente para hacer fine-tuning de un modelo de 65 mil millones de parámetros en una sola tarjeta de 48 gigabytes, conservando el rendimiento del fine-tuning de precisión completa».
En un servicio gestionado el precio es sorprendentemente bajo: un entrenamiento LoRA típico de mil ejemplos suele caber dentro de una tarifa mínima de unos pocos dólares. En hardware propio, en cambio, la diferencia de memoria entre el fine-tuning completo y el de rango bajo es de cuatro veces: ahí sí importa cuál elijas.
El árbol de decisión
1. ¿YA TIENES UNA EVALUACIÓN?
NO -> constrúyela primero. La recomendación
oficial, literal: invierte en fine-tuning
solo después de tener evaluación.
2. ¿QUÉ FALTA: CONOCIMIENTO O COMPORTAMIENTO?
CONOCIMIENTO -> RAG. Según la medición,
39 puntos frente a 2,3.
COMPORTAMIENTO -> puedes seguir.
3. ¿YA LO PROBASTE CON PROMPT Y EJEMPLOS?
Según la documentación oficial, muchas veces
basta con eso. Es el paso más barato.
4. ¿DE QUÉ TAMAÑO ES EL MODELO QUE USAS?
GRANDE -> mejorarás unos pocos puntos.
PEQUEÑO -> aquí está la gran ganancia: en
una medición, del 26 % al 74 %.
5. ¿TIENES 50-1000 BUENOS EJEMPLOS?
Si no, ese es el cuello de botella, no la
tecnología. Montar los datos es el trabajo.
6. ¿SABES MEDIR QUÉ SE ESTROPEA EN OTRO SITIO?
Si no, no lo hagas. El olvido es general y en
un experimento el modelo se estropeó en
preguntas totalmente ajenas.
7. ¿DÓNDE LO EJECUTARÁS EN 2027?
Una gran plataforma retira el servicio.
Planifica con un modelo de pesos abiertos.
El sexto punto es el que falta en la mayoría de los proyectos — y, según las mediciones, es justo el mayor riesgo.
La prueba en contra
Con honestidad: el fine-tuning la mayoría de las veces no merece la pena, y lo señala la propia documentación oficial cuando dice que el trabajo de prompt engineering «puede bastar por sí solo para obtener grandes resultados».
Las tres razones por las que muere casi todo intento:
- No hay evaluación. Sin ella no puedes decir si ha mejorado.
- No hay suficientes datos buenos. Cincuenta ejemplos bien escritos cuestan más que cinco mil malos.
- No mides lo que puede estropearse. El modelo será bueno en aquello para lo que lo entrenaste, y no sabes qué ha pasado con el resto.
Malentendidos habituales
- «Con el fine-tuning le enseño los datos de mi empresa.» Según la medición, para conocimiento nuevo el RAG mejoró 39 puntos y el fine-tuning 2,3 — y en un modelo empeoró.
- «El modelo más grande aprende mejor.» Al revés: según un estudio, el olvido se agrava con el tamaño del modelo.
- «Si ha salido bueno en aquello para lo que lo entrené, ya está.» En un experimento, modelos con fine-tuning sobre código vulnerable se estropearon en preguntas totalmente ajenas, en el 20 % de los casos.
- «Hacen falta muchos datos.» Para formato y estilo, 50-1.000 ejemplos. Cuenta la calidad, no la cantidad.
- «Es caro.» En un servicio gestionado, un entrenamiento de mil ejemplos cuesta unos pocos dólares. La parte cara es montar los datos y medir.
- «Es un servicio consolidado y estable.» Uno de los mayores proveedores retira el suyo antes de enero de 2027, sin sucesor anunciado.
Lo que conviene llevarse
El fine-tuning gana a todo en una única situación: modelo pequeño y tarea estrecha. Ahí, según la medición, el resultado puede saltar del 26 % al 74 %, y un modelo de 350 millones puede ganar a otro quinientas veces mayor.
En todos los demás casos el orden está fijado, y la recomendación oficial dice lo mismo: primero evaluación, luego prompt, luego RAG — y solo al final fine-tuning.
Y una cosa que conviene decidir al principio: cómo vas a medir qué se ha estropeado en otro sitio. El fine-tuning no añade, reescribe — y en el caso documentado más dramático el modelo se estropeó en preguntas que no tenían nada que ver con el entrenamiento. La quantization la explica el post quantization , y de los requisitos de hardware se ocupa el post hardware para local LLM , con los números.