El fine-tuning (ajuste fino) es seguir entrenando un modelo ya entrenado con ejemplos tuyos de entrada y respuesta, para cambiar cómo se comporta: formato, tono o manera de resolver una tarea. Pide pares de ejemplos revisados a mano, no tus documentos sin más. Y casi siempre hay opciones más sencillas que probar antes.
Qué ajusta de verdad el fine-tuning
Ajusta los pesos del modelo, es decir, los números internos que deciden qué respuesta es más probable. No añade una carpeta de documentos al modelo ni le instala una base de datos: modifica el propio modelo, y por eso el resultado es un modelo nuevo que hay que guardar, probar y mantener.
Hay dos maneras de hacerlo. En el ajuste completo se actualizan todos los pesos. En el ajuste eficiente en parámetros se congela el modelo y se entrena una parte pequeña añadida. La biblioteca PEFT de Hugging Face lo describe así: los métodos PEFT solo ajustan «un número pequeño de parámetros (extra)» y rinden de forma comparable a un modelo ajustado entero. El método más conocido es LoRA, que presentaron Hu y colaboradores en su artículo de 2021: comparado con ajustar GPT-3 175B con Adam, reduce en 10.000 veces los parámetros entrenables y en 3 veces la memoria de GPU necesaria.
Para ver de dónde sale ese ahorro, he calculado el caso de una sola matriz de pesos de 4096 × 4096. LoRA no actualiza la matriz entera, sino dos matrices pequeñas cuyo producto la corrige:
Es aritmética sencilla (rango × (filas + columnas) frente a filas × columnas) y la he ejecutado con un script de cuatro líneas. No es una medida de rendimiento: dice cuántos números se entrenan, no lo bien que sale el modelo.
Para qué sirve el fine-tuning y para qué no
Sirve para fijar un comportamiento que repites en cada petición: un formato de salida exacto, una clasificación con tus etiquetas, un tono de marca, una instrucción que el modelo se salta a menudo. Para que consulte información que cambia (precios, políticas, documentación), suele ser mejor dársela en el contexto de cada consulta.
La documentación de OpenAI sobre ajuste supervisado lista los usos donde encaja: clasificación, traducción con matices, generación de contenido en un formato específico y corrección de fallos al seguir instrucciones. En su guía de optimización añade las ventajas de ajustar frente a solo escribir prompts: caben más ejemplos de los que entran en una petición, los prompts se acortan, puedes entrenar con datos sensibles sin enviarlos cada vez y puedes llegar a un modelo más pequeño y rápido para una tarea concreta.
Existen además tres variantes que conviene reconocer cuando las veas en una documentación:
Supervisado (SFT): entrenas con ejemplos de la respuesta correcta.
Preferencias (DPO): le muestras una respuesta buena y otra mala para la misma entrada.
Por refuerzo (RFT): unos evaluadores puntúan las respuestas y se refuerzan las mejores; según OpenAI, solo para modelos de razonamiento.
Mi criterio, que es criterio y no documentación: si tu problema se resume en «el modelo no sabe esto», todavía no es un problema de fine-tuning. Si se resume en «el modelo lo sabe pero lo dice como no quiero, o no siempre igual», sí puede serlo. Si quieres ver la otra cara, la del modelo consultando tus documentos, la explicamos en nuestra guía de qué es RAG.
Qué datos pide: ejemplos, no documentos
El fine-tuning supervisado pide ejemplos de lo que entra y de la respuesta que quieres que salga, uno por línea en un fichero JSONL. Cada ejemplo es una conversación corta cuya última respuesta es lo que el modelo debe aprender. Deben parecerse a las peticiones reales, con respuestas que tú firmarías.
El formato de chat es el que usan OpenAI y, en el mundo abierto, el SFTTrainer de TRL, que acepta conversaciones con la clave messages:
¿Cuántos? OpenAI fija un mínimo de 10 ejemplos, dice que las mejoras suelen verse con 50 a 100 y recomienda empezar con unos 50 bien hechos y evaluar. Si con 50 no cambia nada, su consejo es replantear la tarea o el prompt antes de añadir más datos. Esa cifra es de su plataforma y de su tipo de tarea; en otros modelos y objetivos varía.
Lo que más tiempo consume no es entrenar, es tener datos limpios. Para no descubrir los errores a mitad del trabajo, escribí un validador pequeño que revisa lo básico: JSON válido, roles reconocidos, última intervención del asistente, respuestas no vacías, duplicados y número mínimo de ejemplos.
Lo probé con cinco tests de unittest y con un fichero de muestra de 12 líneas con un duplicado y una conversación que acababa en el usuario: encontró las dos cosas. No sustituye a leer tus datos, pero evita el error tonto.
Qué puedes lograr antes de tocar el modelo
Antes de entrenar, mide, mejora el prompt, aporta contexto y prueba un modelo mejor. Es el orden que propone OpenAI en su guía de optimización: evals para fijar una línea base, prompts con instrucciones claras y ejemplos, y solo después valorar el ajuste fino con datos representativos.
Así lo haría yo, en este orden y parando cuando el resultado ya sirve:
Escribe 20 o 30 casos reales con la respuesta que querrías. Son tu eval. Sin ellos no sabrás si algo mejora o solo lo parece. Y son, de paso, la semilla del dataset si un día ajustas.
Reescribe el prompt. Instrucciones concretas, formato de salida descrito y dos o tres ejemplos dentro (few-shot). Pasa tus casos y cuenta aciertos.
Dale el contexto que le falta. Si falla porque no tiene el dato, la solución es traerlo a la petición, no entrenarlo. Esa es la idea de RAG, y por eso la comparación entre ambas técnicas está en la guía de RAG y no se repite aquí.
Prueba otro modelo. Un modelo más capaz puede resolver sin entrenamiento lo que parecía pedir datos nuevos, y cambiarlo cuesta una línea de configuración.
Ajusta solo lo que siga fallando. Y con los mismos 20 o 30 casos para comparar.
Pasa de la teoría al proyecto
Descarga el dossier y descubre los 5 proyectos que construirás, el syllabus completo y todo lo que necesitas saber.
La tabla siguiente reúne los síntomas más habituales con el primer remedio que probaría. No es una regla universal, es mi orden de trabajo:
Lo que ves | Primer remedio |
|---|---|
Responde con datos que no tiene | Pasarle el dato en la petición |
Cada vez da el formato distinto | Describir el formato y añadir ejemplos al prompt |
Falla en una tarea concreta y repetitiva, con muchos ejemplos disponibles | Medir con tus casos y, si no mejora con prompt, valorar el ajuste |
Prompt larguísimo por los ejemplos que lleva | Valorar el ajuste, es una de las ventajas que cita OpenAI |
No sabes si funciona | Empezar por el eval, no por el entrenamiento |
Dónde se puede ajustar hoy (a 30 de octubre de 2026)
La oferta de ajuste fino en las grandes plataformas se está reduciendo, así que conviene comprobar la vigencia antes de planificar nada. Los dos casos que he revisado hoy en la documentación oficial lo muestran; la vía abierta con modelos descargables sigue disponible.
OpenAI. Su documentación indica que está cerrando la plataforma de fine-tuning: ya no es accesible para usuarios nuevos y los clientes existentes elegibles pueden crear trabajos hasta el 6 de enero de 2027, salvo que el modelo base se retire antes. La página de ajuste supervisado lista la familia GPT-4.1, con retiradas anunciadas el 23 de octubre de 2026 para gpt-4.1-nano y el 14 de enero de 2027 para gpt-4.1 y gpt-4.1-mini, junto con sus versiones ajustadas. Para trabajo nuevo, la guía recomienda empezar con gpt-6-astra y buenas prácticas de prompting.
Google. La página de ajuste de la API de Gemini explica que, tras retirar Gemini 1.5 Flash-001 en mayo de 2025, no hay ningún modelo con ajuste fino en la API de Gemini ni en AI Studio, aunque sí se admite en Gemini Enterprise Agent Platform, y que no tienen planes inmediatos de volver a ofrecerlo.
Modelos de pesos abiertos. Con Transformers, PEFT y TRL puedes ajustar un modelo que descargas y controlas tú, con LoRA para no entrenar todos los pesos. Exige GPU y soltura con Python, pero el resultado es tuyo y no depende de que un proveedor retire el modelo base.
Esto cambia rápido. Si lees esto dentro de unos meses, mira primero las páginas enlazadas, que son las que mandan.
Cuándo sí compensa ajustar
Compensa cuando tienes una tarea estable y repetitiva, ya has medido que el prompt y el contexto no llegan, dispones de ejemplos revisados que representan el uso real y el ahorro de prompt, latencia o tamaño de modelo justifica mantener un modelo propio. Si falta alguna de esas cuatro cosas, probablemente aún no toca.
Dos precauciones prácticas. Una, guarda aparte una parte de tus casos y no los uses para entrenar: son los que dirán si el modelo generaliza o solo memoriza (OpenAI lo llama sobreajuste y ofrece puntos de control precisamente para detectarlo). Otra, reserva tiempo para repetir el ajuste: si cambia el modelo base o tus criterios, el trabajo se rehace.
Siguiente paso: decidir qué le das al modelo
Cuando sepas si al modelo le falta contexto o comportamiento, lo que queda es ingeniería: montar el sistema, medirlo y mantenerlo. En el Máster en Desarrollo Agéntico, la ficha incluye «Un sistema RAG avanzado» entre lo que consigues, y la formación parte de un conocimiento básico de programación, familiaridad con Git y comprensión de APIs y bases de datos (ficha consultada el 30 de octubre de 2026).
Construye un sistema RAG avanzado
Descarga el dossier del Máster en Desarrollo Agéntico y consulta los 5 proyectos del programa.
Si tu camino es construir sin programar, en AI Maker el proyecto «Asistente con IA» trabaja el «consumo de grandes cantidades de información con IA aplicando técnicas como RAG» (ficha de AI Maker, consultada el 30 de octubre de 2026). Para repasar el vocabulario de estos temas puedes usar nuestra guía de qué es un LLM y el glosario de IA.
Preguntas frecuentes sobre el fine-tuning
¿Qué es el fine-tuning de un modelo de IA?
Es continuar el entrenamiento de un modelo ya entrenado con un conjunto pequeño de ejemplos propios, para que se comporte de otra forma en una tarea concreta. Se modifican sus pesos y el resultado es una versión nueva del modelo. No hay que entrenar desde cero, que es lo que lo diferencia de crear un modelo.
¿Cuántos ejemplos hacen falta para hacer fine-tuning?
Depende de la tarea y del proveedor. OpenAI pide un mínimo de 10, dice que las mejoras suelen verse con 50 a 100 y recomienda empezar con unos 50 bien elaborados y evaluar. Si con ellos no cambia nada, sugiere revisar la tarea o el prompt antes de añadir datos. En otros modelos, las cifras pueden ser distintas.
¿El fine-tuning sirve para que el modelo conozca mis documentos?
No es el uso para el que mejor encaja. Entrenar con ejemplos moldea el comportamiento del modelo, y los documentos que cambian se gestionan mejor pasándoselos en cada consulta, como hace RAG. Ajustar y dar contexto no se excluyen: puedes ajustar el formato de respuesta y aportar los datos en la petición.
¿Qué es LoRA?
LoRA (Low-Rank Adaptation) es un método de ajuste eficiente: congela los pesos del modelo y entrena unas matrices pequeñas añadidas. Su artículo de 2021 declara, frente a ajustar GPT-3 175B con Adam, 10.000 veces menos parámetros entrenables y 3 veces menos memoria de GPU, con un rendimiento igual o superior en los modelos que probaron.
¿Puedo hacer fine-tuning con la API de OpenAI o con Gemini?
A 30 de octubre de 2026, la documentación de OpenAI dice que su plataforma de fine-tuning ya no admite usuarios nuevos, y la de Gemini indica que la API no tiene ahora ningún modelo con ajuste fino. Lo que sí queda es ajustar modelos abiertos con Transformers, PEFT y TRL, o revisar la oferta empresarial de cada proveedor.
