Por qué (normalmente) NO hacer fine-tuning

El fine-tuning consiste en tomar un modelo ya preentrenado y seguir ajustando sus pesos con gradient descent y backpropagation —el mismo aparato del Capítulo 6 de Parte I— usando tus propios datos, para que el modelo se comporte de una forma específica. Esta definición general no dice nada sobre si se actualizan todos los pesos o solo una fracción — eso lo veremos en el siguiente capítulo. Lo que sí podemos adelantar aquí es la versión más directa e intuitiva de hacerlo: el fine-tuning completo, donde se actualiza literalmente cada peso de la red.

El escenario: una empresa de soporte al cliente quiere que su asistente de IA responda siempre con el tono específico de su marca — cálido pero directo, nunca genérico. Alguien en el equipo propone: “démosle al modelo cientos de conversaciones reales de nuestros mejores agentes, y que aprenda a hablar así.” Vamos a ver por qué esa intuición, aunque razonable, casi siempre lleva a más problemas de los que resuelve.

Es caro y lento — y no solo por el entrenamiento en sí

La intuición común es pensar el costo del fine-tuning como “el precio de correr el entrenamiento”. Pero recordemos el Capítulo 3: para saber si algo mejoró, necesitas evals — un juez, un conjunto de casos de prueba, una forma sistemática de comparar antes y después. Sin eso, “se siente mejor” es exactamente la trampa que ya identificamos como insuficiente.

El costo real de nuestro escenario de soporte al cliente incluye, como mínimo:

1. Curar el dataset de entrenamiento — no basta con “cientos de conversaciones”; hace falta que sean genuinamente representativas del tono deseado, sin ejemplos contradictorios entre sí.
2. El entrenamiento en sí — el paso que la mayoría de la gente sí anticipa.
3. Construir el eval — un conjunto de conversaciones de prueba, con un juez calibrado, para poder afirmar con evidencia que el modelo afinado realmente superó a la alternativa de no afinar.
4. Iterar — la primera corrida casi nunca es la definitiva; hay que repetir los pasos anteriores varias veces.

El paso 3 es el que casi nadie presupuesta al principio, y es precisamente el que hace que “solo entrenar” subestime el costo real por un margen considerable.

Comparación de costo, en términos relativos (no en cifras específicas — ver nota abajo):

Enfoque	Costo relativo de implementación	Costo recurrente de uso
Prompting / RAG, sin entrenar nada	Bajo — solo ingeniería de prompt o pipeline de recuperación	Costo estándar de API por token, más la infraestructura y los tokens adicionales que requiera la recuperación
PEFT (LoRA/QLoRA) — ver siguiente capítulo	Medio — requiere dataset curado y una corrida de entrenamiento eficiente	Generalmente similar al costo estándar de inferencia, a veces con un pequeño sobrecosto
Fine-tuning completo vía API de un proveedor	Alto — todo lo anterior, sin las eficiencias de PEFT	Suele ser más caro que usar el modelo base — el sobrecosto de inferencia se paga en cada llamada

Por qué esta tabla usa términos relativos y no dólares específicos: investigamos activamente cifras concretas de precio, y encontramos un panorama genuinamente volátil — distintas fuentes de 2026 (marzo, junio, agosto) reportan precios diferentes para modelos supuestamente comparables. El ejemplo más contundente es que OpenAI inició el retiro gradual de su plataforma de fine-tuning de autoservicio en mayo de 2026: dejó de aceptar nuevos usuarios, restringió después a organizaciones inactivas y anunció que los clientes activos podrían crear nuevos trabajos solo hasta el 6 de enero de 2027. No fue un cierre completo en mayo — la inferencia de modelos ya afinados continúa mientras sus modelos base sigan disponibles — pero sí un cambio material de disponibilidad con plazos concretos. Cualquier cifra específica que hubiéramos puesto aquí tendría el riesgo real de describir un servicio que ya cambió o dejó de existir para cuando leas esto. Lo que sí se mantiene más estable a través del tiempo es la relación aproximada de costo y esfuerzo entre los enfoques — por eso es lo que documentamos.

La lección de fondo, más allá del costo: este retiro gradual es, en sí mismo, una razón adicional para no comprometer una arquitectura de producción a la oferta específica de un proveedor en un momento dado — los servicios de IA cambian de precio, de disponibilidad, y a veces desaparecen, con más frecuencia de la que uno esperaría al diseñar un sistema pensado para durar años. No es una crítica particular a OpenAI: es un ejemplo real de volatilidad del mercado. Vale la pena, siempre, verificar la oferta vigente directamente en la documentación del proveedor antes de comprometerse — nunca confiar en una cifra que viste en un artículo, por reciente que parezca.

La velocidad del mercado te alcanza

Para cuando terminas de afinar tu modelo, es común que el laboratorio detrás del modelo base ya haya lanzado una versión nueva que supera a tu modelo afinado sin ningún esfuerzo de tu parte. Esto aplica sobre todo cuando afinas para mejorar algo que también es un objetivo de mejora general del laboratorio — seguir instrucciones, sonar más natural, mantener un tono consistente. Si buscabas, en el fondo, que el modelo “entienda mejor lo que le pides”, la siguiente versión del modelo base puede lograr esa misma mejora sin que hayas invertido nada.

Aplica mucho menos cuando afinas para algo genuinamente específico de tu dominio, que ningún laboratorio tiene motivo para mejorar en su modelo general — por ejemplo, clasificar tickets según la taxonomía interna exacta de tu empresa. Esa distinción es la semilla de las excepciones que veremos al final.

El peligro del sobreajuste (overfitting)

Aquí vale la pena regresar explícitamente al capítulo de “aprendizaje, memorización y validación” de Parte I: vimos que un modelo puede tener loss bajo en entrenamiento por aprender patrones reutilizables, por memorizar pasajes específicos, o por una mezcla de ambos — y que el loss de entrenamiento solo, sin validación separada, no puede decirte cuál de los dos está pasando.

El fine-tuning es, mecánicamente, el mismo ciclo de ese capítulo — la diferencia es que ahora el “texto de entrenamiento” son tus propios ejemplos curados. Y el mismo riesgo aplica: cualquier regularidad accidental en tus datos puede memorizarse con la misma fidelidad que el patrón que sí querías enseñar.

Caso 1 — “Slack Fine-Tuning” de Ross Lazerowitz: Ross entrenó un LLM con sus 140 mil mensajes de Slack, buscando que hablara como él. Al pedirle “escribe un post de blog de 500 palabras sobre ingeniería de prompts”, el modelo —habiendo aprendido sus hábitos reales de comunicación— respondió: “Trabajaré en eso por la mañana.” Al insistir a la mañana siguiente: “Estoy escribiendo justo ahora, son las 6:30 a.m. aquí, por favor.”

El modelo no falló en el sentido de romperse o generar texto sin sentido — aprendió un patrón genuino y consistente de los datos, solo que era el equivocado. Ross quería tono y estilo de comunicación; el modelo aprendió, con la misma fidelidad, hábitos de procrastinación humana — porque ambos patrones estaban presentes en los datos, y el gradient descent no distingue “esto es lo que quiero que aprendas” de “esto es simplemente lo que más se repite”.

Caso 2 — un patrón recurrente en fine-tuning de soporte al cliente: un problema documentado con frecuencia en equipos que afinan modelos con transcripciones reales de soporte: si una fracción notable de las conversaciones de entrenamiento terminan con el agente humano escalando el caso a un supervisor (porque son, naturalmente, las conversaciones más difíciles las que se documentan y revisan con más cuidado), el modelo afinado puede aprender a escalar con más frecuencia de la deseada — incluso en casos simples que sí podría resolver por sí solo — simplemente porque “escalar” apareció sobrerrepresentado en los datos de entrenamiento respecto a la proporción real de casos que verdaderamente lo ameritan. Es el mismo mecanismo del Caso 1: el modelo aprende la distribución estadística de los datos, no la intención detrás de por qué se seleccionaron esos ejemplos.

¿Cuándo sí tiene sentido, a escala de producción real?

El título dice “normalmente” a propósito. Hay casos genuinos donde el fine-tuning es la decisión correcta, y vale la pena ser específicos sobre cuándo:

• Tareas muy específicas y estructuradas donde el prompting ya se agotó y sigue sin lograr consistencia suficiente — por ejemplo, clasificar documentos en una taxonomía interna muy particular que ningún modelo base conoce de fábrica, y donde ni RAG (Capítulo 5) resuelve el problema porque no es cuestión de información sino de comportamiento consistente.
• Reducción de costo a escala, usando un modelo pequeño afinado para una tarea narrow en vez de pagar repetidamente por un modelo grande vía API — exactamente la lógica del caso de los 1,500 vendedores en Parte IV, donde un modelo pequeño afinado para evaluar clientes resulta más económico a gran volumen que un modelo grande genérico para esa misma tarea repetitiva. La señal concreta de que ya llegaste a este punto: cuando el costo acumulado de tokens de prompt repetidos (el mismo contexto extenso, una y otra vez, en cada llamada) supera, proyectado a un horizonte de meses, lo que costaría entrenar y luego servir un modelo más pequeño y especializado.
• Comportamiento que debe estar “horneado” de forma consistente, sin depender de que el contexto correcto esté siempre presente en el prompt — a diferencia de RAG, que depende de que la recuperación funcione bien en cada llamada.

La pregunta no es “fine-tuning sí o no” en abstracto — es “¿ya agoté prompting (Capítulo 2) y RAG (Capítulo 5), y todavía no logro la consistencia que necesito, a un volumen donde el costo ya lo justifica?” Si la respuesta es sí en las tres partes, vale la pena — pero, como veremos a continuación, casi nunca con fine-tuning completo.