Fine-tuning

docs.scrimba.com

Fine-tuning significa tomar un modelo existente y seguir entrenándolo con tus propios ejemplos, de modo que su comportamiento por defecto se acerque a lo que necesitas. Este capítulo te da una idea concreta de qué cambia el fine-tuning, para qué sirve, y cuándo conviene usarlo en lugar de un prompt o de recuperación de información.

Qué hace realmente el entrenamiento

Para entender qué cambia el fine-tuning, ayuda saber de dónde sale un modelo. Un modelo se construye en dos etapas generales.

La primera es el preentrenamiento (pretraining): el modelo lee una cantidad enorme de texto y aprende a predecir el siguiente token, una y otra vez, hasta que la gramática, los hechos y los patrones de razonamiento quedan incorporados en él como efecto colateral. El resultado es un modelo base, fluido pero sin un rumbo definido. Va a continuar tu texto sin problema, pero no ha sido entrenado para ser un asistente útil que responda preguntas.

La segunda etapa es el post-entrenamiento: el modelo base se sigue entrenando con ejemplos curados de buenas respuestas, junto con retroalimentación humana sobre qué respuestas son mejores. Esto es lo que convierte a un predictor de texto crudo en el asistente que sigue instrucciones con el que realmente hablas. El modelo que llamas desde una API ya pasó por ambas etapas.

Ambas etapas funcionan con el mismo mecanismo: mostrarle ejemplos al modelo y ajustar sus números internos, sus parámetros o pesos, para que sus predicciones se acerquen más a esos ejemplos. El entrenamiento es práctica de predicción que deja al modelo permanentemente modificado.

JunoQué hace realmente el entrenamiento Un modelo se construye en dos etapas. El preentrenamiento hace que prediga el siguiente token a lo largo de enormes cantidades de texto, produciendo un modelo base fluido pero sin rumbo definido. Luego el post-entrenamiento lo entrena con buenas respuestas curadas y retroalimentación humana, convirtiéndolo en un asistente útil. Ambas funcionan igual: ajustan los pesos internos del modelo para que sus predicciones coincidan con los ejemplos que se le muestran.

Un modelo llega a tus manos después de dos etapas de entrenamiento, y conocer la forma de cada una te dice qué puede modificar el fine-tuning.

El preentrenamiento viene primero: el modelo lee una montaña enorme de texto y hace un solo ejercicio, predecir el siguiente token, miles de millones de veces. La gramática, el conocimiento del mundo y los patrones de razonamiento se asientan en los pesos como efecto colateral. El resultado es un modelo base, fluido para continuar texto pero todavía no un asistente. No sabe que debe responder una pregunta en lugar de simplemente extenderla.

El post-entrenamiento es la segunda etapa, y es la que el fine-tuning imita. El modelo base sigue entrenándose con ejemplos curados de buenas respuestas más señales de preferencia humana sobre cuál respuesta es mejor. Eso es lo que produce el comportamiento de seguir instrucciones que obtienes al llamar una API.

Ambas etapas ejecutan el mismo ciclo: le dan al modelo un ejemplo, comparan su predicción con el objetivo, y ajustan los pesos para reducir esa diferencia. El fine-tuning es ese mismo ciclo, acotado a tus ejemplos y ejecutado después de que el proveedor terminó sus dos etapas. El entrenamiento cambia el comportamiento editando pesos, no agregando una tabla de búsqueda, y esa distinción es la razón completa de por qué el fine-tuning es bueno para algunas tareas y malo para otras.

JunoQué hace realmente el entrenamiento Dos etapas llevan un modelo hasta ti: el preentrenamiento le inculca la predicción del siguiente token hasta volverlo un modelo base fluido, y luego el post-entrenamiento lo convierte en un asistente con ejemplos curados y datos de preferencia. Ambas ejecutan el mismo ciclo: dan un ejemplo, ajustan los pesos hacia él, y el fine-tuning es ese mismo ciclo acotado a tus datos. Edita pesos, no agrega una tabla de búsqueda, por eso cambia bien el comportamiento y almacena mal los hechos.

Un modelo llega después de dos etapas de entrenamiento, y ahí, en el límite entre ambas, es donde vive el fine-tuning.

El preentrenamiento es la etapa costosa que se hace una sola vez por modelo: corpus de texto enormes, el único objetivo de predecir el siguiente token, y los pesos (los números ajustables del modelo) absorbiendo gramática, conocimiento y razonamiento como subproducto. El resultado es un modelo base, fluido pero no orientado a ser útil. El post-entrenamiento luego alinea ese modelo base para convertirlo en un asistente usando demostraciones curadas y datos de preferencia humana. Para cuando llamas a un modelo por API, ambas etapas ya se ejecutaron.

El fine-tuning es una continuación del post-entrenamiento, acotada a tus datos y ejecutada sobre un modelo que ya está alineado. El mecanismo es idéntico: presentas un ejemplo, mides qué tan lejos está la predicción del objetivo, ajustas los pesos para reducir esa diferencia. La consecuencia que importa en la práctica es que el fine-tuning mueve los mismos parámetros globales que sostienen todo lo demás. No estás agregando un módulo, estás modificando una superficie compartida, y por eso un fine-tune puede mejorar tu tarea objetivo y al mismo tiempo degradar sin darte cuenta una capacidad que no tiene nada que ver.

Esa propiedad de superficie compartida es la base de todos los modos de falla que vienen más adelante en este capítulo: sobreajuste, olvido, deriva. El fine-tuning remodela el comportamiento, nunca instala un almacén de hechos. Ten eso presente y vas a recurrir a él por las razones correctas, y a evitarlo cuando no corresponda.

JunoQué hace realmente el entrenamiento El preentrenamiento es el proceso pesado que se hace una sola vez por modelo e inculca la predicción del siguiente token en un modelo base; el post-entrenamiento lo alinea para convertirlo en un asistente, y el fine-tuning continúa esa segunda etapa con tus datos. Siempre el mismo ciclo: presentar un ejemplo, ajustar los pesos hacia él. El detalle es que estás modificando parámetros globales compartidos, no agregando un módulo aparte, así que un fine-tune puede mejorar tu tarea y dañar otra sin relación en la misma corrida, de ahí vienen el sobreajuste y el olvido.

Qué es el fine-tuning

El fine-tuning es una versión pequeña y enfocada de esa segunda etapa, que ejecutas tú mismo. Tomas un modelo que ya está entrenado y sigues entrenándolo con un conjunto de tus propios ejemplos, cada uno una entrada emparejada con la salida que quisieras que produjera. Después de suficientes ejemplos, los pesos del modelo se ajustan de modo que ese tipo de respuesta se vuelve su comportamiento por defecto, sin que tengas que pedirlo en el prompt cada vez.

La diferencia real frente al prompting y a RAG está en dónde vive el cambio. El prompting y RAG dejan al modelo congelado y lo guían mediante el contexto que le das en el momento de la llamada. El fine-tuning cambia al modelo mismo, así que el nuevo comportamiento queda incorporado y aparece incluso con un prompt corto. No estás dando mejores instrucciones en tiempo de ejecución; estás entregando un modelo que ya se inclina hacia lo que quieres.

En la práctica le entregas al proveedor un archivo con conversaciones de ejemplo, este ejecuta un trabajo de entrenamiento, y te devuelve un nuevo id de modelo. Llamas ese id exactamente igual que a cualquier otro modelo, salvo que ahora sus respuestas reflejan lo que le enseñaste. El fine-tuning traslada el comportamiento al modelo; el prompting y RAG guían a uno que permanece congelado.

JunoQué es el fine-tuning El fine-tuning es una versión pequeña del post-entrenamiento que ejecutas tú: sigues entrenando un modelo ya existente con tus propios ejemplos de entrada-salida hasta que el comportamiento que quieres se vuelve el predeterminado. A diferencia del prompting y RAG, que guían a un modelo congelado mediante contexto, el fine-tuning cambia los pesos del modelo, así que el comportamiento queda incorporado y aparece incluso con un prompt corto. Entregas un archivo de ejemplos y obtienes un nuevo id de modelo que llamas como cualquier otro.

El fine-tuning es post-entrenamiento acotado a una tarea y ejecutado por ti. Partes de un modelo ya entrenado y sigues entrenándolo con ejemplos, cada uno una entrada emparejada con la salida que hubieras querido que produjera. Si le das suficientes, los pesos se asientan de modo que esa respuesta se vuelve la predeterminada, sin ninguna instrucción en el prompt que la pida.

La línea que importa es dónde vive el control del comportamiento. El prompting y RAG dejan los pesos congelados y moldean el comportamiento mediante el contexto que se entrega en cada llamada, así que cada llamada carga con las instrucciones. El fine-tuning edita los pesos una sola vez, por adelantado, así que el comportamiento viaja dentro del id de modelo y sobrevive a un prompt corto. Control en tiempo de ejecución versus comportamiento incorporado: esa es la disyuntiva que estás resolviendo.

El flujo de trabajo es concreto. Armas un archivo de conversaciones de ejemplo, inicias un trabajo de entrenamiento, y el proveedor te devuelve un nuevo id de modelo. Llamas ese id como a cualquier otro modelo.

# Cada ejemplo es una conversación con la misma forma exacta que envías en tiempo de ejecución,
# terminando con la salida que quieres que el modelo aprenda.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Classify the ticket's urgency as low, medium, or high."},
        {"role": "user", "content": "I was charged twice this week and need it fixed today."},
        {"role": "assistant", "content": "high"},
    ]},
    {"messages": [
        {"role": "system", "content": "Classify the ticket's urgency as low, medium, or high."},
        {"role": "user", "content": "Is there a dark mode setting anywhere?"},
        {"role": "assistant", "content": "low"},
    ]},
    # ... cientos o miles más, cubriendo todo el rango de entradas que esperas
]
# La forma de los mensajes y la API del trabajo de entrenamiento varían según el proveedor; la idea es la misma.

JunoQué es el fine-tuning El fine-tuning es post-entrenamiento acotado a tu tarea: sigues entrenando un modelo con ejemplos de entrada-salida hasta que el comportamiento que quieres se vuelve el predeterminado. El prompting y RAG guían a un modelo congelado mediante contexto en cada llamada; el fine-tuning edita los pesos una sola vez, así que el comportamiento viaja dentro del id del modelo. Armas un archivo de conversaciones de ejemplo, ejecutas un trabajo de entrenamiento, y llamas al id resultante como a cualquier otro modelo.

El fine-tuning es post-entrenamiento continuado sobre un conjunto de datos que tú controlas, y produce un modelo derivado detrás de un nuevo id. Cada ejemplo de entrenamiento es una entrada emparejada con una salida objetivo, y el trabajo ajusta los pesos hasta que tus respuestas objetivo se vuelven el comportamiento predeterminado del modelo. El comportamiento viaja en los pesos, así que un prompt corto basta para evocarlo.

Compáralo con las alternativas con precisión, porque la diferencia es operativa, no filosófica. El prompting y RAG mantienen los pesos congelados e inyectan comportamiento a través del contexto (el texto que el modelo lee en el momento de la llamada), lo que significa que puedes cambiar el comportamiento editando una cadena de texto y volviendo a desplegar en segundos. El fine-tuning incorpora el comportamiento en los pesos, lo que significa que cambiarlo requiere una nueva corrida de entrenamiento, una evaluación y el despliegue de un nuevo id de modelo. El control en tiempo de ejecución se edita en segundos; un fine-tune solo se edita en un ciclo de entrenamiento completo.

# Un modelo con fine-tuning es simplemente otro id; la forma de la llamada no cambia.
response = client.chat.completions.create(
    model="your-org/urgency-classifier-v1",  # fija esto; trátalo como parte de tu contrato
    messages=[
        {"role": "system", "content": "Classify the ticket's urgency as low, medium, or high."},
        {"role": "user", "content": "The export button does nothing when I click it."},
    ],
)
# response.choices[0].message.content -> "low"  (solo la etiqueta, el comportamiento que entrenaste)
# La forma de llamada mostrada es estilo OpenAI-SDK; varía según el proveedor.

Esa asimetría de costos es lo que hay que internalizar antes de comprometerte. Un id con fine-tuning es un artefacto versionado: tú eres responsable de su ciclo de vida, de sus evaluaciones, y de volverlo a entrenar cada vez que el comportamiento deseado cambie. Fija el id, versiónalo, y presupuesta el hecho de que cada cambio en lo que aprendió es otro trabajo, no otro commit.

JunoQué es el fine-tuning El fine-tuning es post-entrenamiento continuado con tus datos, que produce un modelo derivado detrás de un nuevo id cuyo comportamiento vive en los pesos. El contraste con el prompting y RAG es operativo: el control en tiempo de ejecución es una cadena de texto editable que se redespliega en segundos; un fine-tune es un artefacto versionado que solo cambias mediante una corrida de entrenamiento, una evaluación y un redespliegue. Fija el id, trátalo como un contrato, y presupuesta el hecho de que cada cambio de comportamiento es otro trabajo.

Para qué sirve, y para qué no

El fine-tuning se gana su lugar cuando necesitas un comportamiento consistente que un prompt tiene dificultad para fijar: un formato de salida preciso todas las veces, un tono o estilo particular, o una tarea acotada como clasificación hecha de forma confiable a lo largo de miles de llamadas. También puede hacer que las llamadas sean más baratas y rápidas, porque el comportamiento que de otro modo tendrías que explicar en un prompt largo queda incorporado en el modelo, así que tus prompts se vuelven más cortos.

Donde falla es en el conocimiento. El fine-tuning es malo para enseñarle a un modelo hechos nuevos, y peor aún con hechos que cambian. Los ejemplos de entrenamiento se difuminan en patrones generales en lugar de quedar guardados como entradas exactas y consultables, así que un modelo con fine-tuning sigue inventando detalles y sigue quedando desactualizado en el momento en que tu información se actualiza. Volver a entrenar cada vez que cambia un precio o una política es lento y costoso. Cuando el problema es "el modelo no sabe X", la respuesta casi siempre es RAG, no fine-tuning.

La regla general: usa fine-tuning para cambiar la forma, no para agregar hechos. Enséñale al modelo cómo responder, y deja que la recuperación de información se encargue de con qué responder.

JunoPara qué sirve, y para qué no El fine-tuning es bueno para el comportamiento consistente: un formato de salida fijo, un tono específico, o una tarea acotada hecha de forma confiable, y puede acortar los prompts para que las llamadas cuesten menos. Es malo con el conocimiento: no almacena hechos de forma confiable, se desactualiza cuando cambian, y es costoso volver a entrenar. La regla es hacer fine-tuning para cambiar la forma, no para agregar hechos, y dejar que RAG se encargue de los hechos.

El fine-tuning rinde frutos para la forma: una estructura de salida precisa en cada llamada, un tono o estilo fijo, o una tarea acotada como clasificación mantenida estable a lo largo de miles de solicitudes. La ganancia se multiplica cuando el prompting por sí solo sigue variando, el modelo respeta el formato la mayoría de las veces pero no de forma lo bastante confiable para procesarlo después. Incorpora el comportamiento y el formato deja de ser algo que solo esperas que ocurra en cada llamada.

También acorta los prompts, y a escala eso es una palanca real de costos. Si actualmente detallas el formato y unos cuantos ejemplos en cada solicitud, esos tokens de instrucción se cobran en cada llamada. Incorpóralos en los pesos y el prompt por llamada se reduce. La cuenta vale la pena hacerla: un fine-tune tiene un costo de entrenamiento fijo que se paga una sola vez, mientras que un prompt largo tiene un costo por llamada que se paga siempre, así que acortar el prompt vale la pena cuando el volumen de llamadas es suficiente para que los tokens ahorrados superen el costo del entrenamiento.

Donde falla es en el conocimiento. Los ejemplos de entrenamiento se difuminan en patrones generales, no en entradas exactas y recuperables, así que un modelo con fine-tuning sigue inventando detalles y sigue desactualizándose en el momento en que cambia un precio o una política. Actualizar un hecho implica otra corrida de entrenamiento. Usa fine-tuning para la forma, usa RAG para los hechos, y combínalos. El patrón sólido es usar ambos a la vez: haz fine-tuning del modelo para tu formato y tono, y luego recupera hechos actuales en tiempo de ejecución para que el modelo ajustado los exprese.

Antes de siquiera pensar en fine-tuning, confirma que el prompting realmente falló. "Falló" significa una instrucción clara con algunos ejemplos bien elegidos, probada con entradas variadas, que aun así no alcanza la tasa objetivo, no que tu primer prompt de una línea se veía mal. Si no has hecho esa prueba, no estás listo para hacer fine-tuning.

JunoPara qué sirve, y para qué no El fine-tuning es para la forma: una estructura de salida fija, un tono determinado, una tarea acotada mantenida estable, además de prompts más cortos que ahorran tokens en cada llamada. La cuenta de costos es entrenamiento fijo una sola vez versus tokens de prompt que se pagan siempre, así que acortar el prompt vale la pena a alto volumen. Es malo con los hechos, que se difuminan en patrones y se desactualizan, así que combina un modelo ajustado con RAG: la forma viene de los pesos, los hechos de la recuperación. Y comprueba que el prompting realmente falló, un prompt real con ejemplos probados con distintas entradas, antes de subir de nivel.

El fine-tuning es confiable para la forma y poco confiable para los hechos, y las razones son mecánicas. La forma, la estructura de salida, el tono, las convenciones de la tarea, es una regularidad de comportamiento que los pesos pueden absorber a través de muchos ejemplos. Los hechos son discretos y cambiantes, y los pesos los almacenan con pérdida, como patrones combinados, no como filas recuperables, así que un modelo ajustado sigue confabulando y sigue quedando desactualizado en el instante en que el hecho subyacente cambia.

Vayamos más allá del titular: los riesgos reales son las formas en que un fine-tune se degrada. El sobreajuste (overfitting) es cuando el modelo memoriza tu conjunto de entrenamiento, incluidas sus rarezas, en lugar de aprender el comportamiento general, así que resuelve perfecto tus ejemplos y falla con entradas que difieren. El olvido catastrófico es la otra cara: entrenar intensamente en una tarea acotada puede erosionar habilidades generales sin relación que el modelo base tenía, porque estás moviendo pesos compartidos, así que tu clasificador se vuelve más preciso mientras su razonamiento en cualquier otra cosa se vuelve más torpe. La deriva de distribución es la lenta: un modelo ajustado con la distribución de entradas del trimestre pasado se deteriora conforme el tráfico real se aleja de lo que vio, y ese deterioro es silencioso hasta que lo mides.

Dos consecuencias determinan cómo hay que operar esto en la práctica. Primero, no puedes lanzar un fine-tune a ojo; necesitas un conjunto de evaluación, un lote apartado de entradas con respuestas correctas conocidas, puntuado antes y después, para probar que la tarea objetivo mejoró y, no menos importante, que la habilidad general no retrocedió. Segundo, cada cambio en el comportamiento deseado es otro trabajo completo: volver a curar los datos, reentrenar, reevaluar, redesplegar un nuevo id. Ese lastre operativo es la razón por la que existen los métodos eficientes en parámetros, formas de hacer fine-tuning entrenando un pequeño conjunto de pesos añadidos en lugar de todo el modelo, más baratos de ejecutar y almacenar, aunque la decisión de si hacer fine-tuning o no no cambia por eso. De cualquier forma, prueba que el fine-tune no retrocedió antes de lanzarlo.

JunoPara qué sirve, y para qué no La forma se absorbe en los pesos, los hechos no: un fine-tune sigue confabulando y desactualizándose, así que mantén los hechos en la recuperación de información. Los riesgos son el sobreajuste (memorizar tu conjunto, fallar con entradas nuevas), el olvido catastrófico (entrenamiento acotado que erosiona habilidades sin relación porque los pesos son compartidos), y la deriva de distribución conforme el tráfico real se aleja de tus datos de entrenamiento. Así que condiciona cada fine-tune a una evaluación apartada, puntuada antes y después, para probar que no hubo retroceso, y presupuesta el hecho de que cada cambio de comportamiento es un ciclo completo de reentrenamiento, evaluación y redespliegue, que es exactamente la razón por la que existen los métodos eficientes en parámetros.

¿Prompt, RAG o fine-tuning?

La mayoría de las veces no empiezas aquí. Las tres técnicas forman una escalera, empezando por lo más barato y rápido de cambiar:

1. Prompting. Prueba esto siempre primero. Es instantáneo de iterar, no cuesta nada extra, y un prompt claro con un par de ejemplos resuelve más de lo que la gente espera. Si no has logrado que el prompt funcione, no estás listo para hacer fine-tuning.
2. RAG. Recurre a esto cuando la brecha es de conocimiento: el modelo necesita hechos que no tiene, o que cambian con el tiempo. RAG los provee en el momento de la pregunta sin tocar el modelo.
3. Fine-tuning. Recurre a esto cuando la brecha es de comportamiento en lugar de conocimiento y el prompting no logra hacerlo suficientemente consistente, o cuando tus prompts han crecido tanto que incorporar las instrucciones en el modelo resulta más barato y rápido a escala.

No son excluyentes, y los sistemas más sólidos las combinan: haz fine-tuning de un modelo para tu formato y tono, y luego usa RAG para alimentarlo con hechos actuales en tiempo de ejecución. Comportamiento del entrenamiento, conocimiento de la recuperación.

Entonces, una prueba rápida antes de hacer fine-tuning. ¿Puedes lograrlo con un mejor prompt? Entonces haz eso. ¿La brecha es conocimiento faltante? Entonces es RAG.

Sube la escalera; el fine-tuning es el último escalón, no el primero. Solo cuando el prompt ya está bien hecho, los hechos ya están disponibles, y el modelo aún no se comporta de forma lo bastante consistente, el fine-tuning se convierte en la herramienta que corresponde.

Juno¿Prompt, RAG o fine-tuning? Trata las tres como una escalera: prompt primero porque es instantáneo y barato, agrega RAG cuando al modelo le falta conocimiento, y haz fine-tuning solo cuando la brecha es de comportamiento que el prompting no logra hacer consistente, o para acortar prompts largos a escala. Se combinan bien: fine-tuning para la forma, RAG para los hechos. El fine-tuning es el último escalón al que recurres, no el primero.

Las tres técnicas forman una escalera, ordenada según lo rápido y barato que es cambiarlas, y la subes desde abajo.

1. Prompting. Primero, siempre. Iteras en segundos sin costo de entrenamiento extra, y una instrucción clara con unos cuantos ejemplos cubre más terreno del que la gente espera. Hasta que un prompt real haya sido probado y haya quedado corto, los escalones superiores son prematuros.
2. RAG. Cuando la brecha es de conocimiento, hechos que al modelo le faltan o que cambian con el tiempo, la recuperación de información los provee en el momento de la pregunta y deja los pesos intactos. Actualizar un hecho es actualizar tu fuente, no reentrenar.
3. Fine-tuning. Cuando la brecha es un comportamiento que el prompting no logra fijar, o cuando los prompts han crecido tanto que incorporar las instrucciones en los pesos resulta más barato a escala.

El diagnóstico que te ubica en el escalón correcto es nombrar la brecha. Un formato o tono incorrecto es una brecha de comportamiento, así que haz prompting y luego fine-tuning. Un hecho faltante o desactualizado es una brecha de conocimiento, así que recupera información. Si interpretas mal la brecha, harás fine-tuning para resolver un problema de conocimiento y lo verás desactualizarse, o meterás hechos en un prompt que un paso de recuperación debería haber obtenido.

No son excluyentes, y el patrón combinado es al que hay que recurrir en producción: fine-tuning para la forma, RAG para los hechos, juntos. Un modelo ajustado a tu formato y tono, alimentado con hechos actuales en tiempo de ejecución, te da estructura consistente y contenido actualizado a la vez, algo que ninguna de las dos técnicas por separado lograría.

Si puedes o no hacer fine-tuning depende del modelo. Los proveedores cerrados ofrecen fine-tuning administrado de sus propios modelos; un modelo de pesos abiertos lo puedes ajustar tú mismo en tus propios términos, lo cual es una de las razones para optar por pesos abiertos (Modelos abiertos y cerrados).

Juno¿Prompt, RAG o fine-tuning? Sube la escalera desde el escalón más barato: prompt primero, agrega RAG cuando la brecha es de conocimiento, haz fine-tuning solo cuando es un comportamiento que el prompting no logra fijar o para acortar prompts a escala. El diagnóstico es nombrar la brecha: formato o tono significa comportamiento, un hecho faltante o desactualizado significa recuperación. El movimiento en producción es usar ambas a la vez: fine-tuning para la forma, RAG para los hechos, así obtienes estructura consistente y contenido actualizado al mismo tiempo.

La escalera, prompt luego RAG luego fine-tuning, está ordenada por costo de iteración: qué tan rápido y barato es cambiar el comportamiento una vez lanzado. Un prompt es una cadena de texto que editas y redespliegas en segundos. Una fuente de recuperación son datos que actualizas sin tocar el modelo. Un fine-tune es una corrida de entrenamiento, una evaluación, y un nuevo id de modelo. Subir en ese orden significa que solo pagas el costo de iteración más alto cuando los escalones más baratos demostradamente no alcanzan.

La habilidad real es diagnosticar bien la brecha, porque el modo de falla es elegir la herramienta que no la resuelve. Una brecha de comportamiento (estructura incorrecta, tono incorrecto, adherencia inconsistente a la tarea) es lo que resuelven el prompting y luego el fine-tuning. Una brecha de conocimiento (un hecho que al modelo le falta, o uno que cambia) es lo que resuelve la recuperación de información, y hacer fine-tuning para una brecha de conocimiento es el clásico error costoso: entrenas los hechos dentro del modelo, quedan desactualizados en la siguiente actualización, y no puedes citarlos.

Compara la asimetría operativa junto con el diagnóstico. El costo recurrente de RAG es la calidad y la latencia de la recuperación en cada llamada, que se paga siempre pero se puede ajustar en vivo. El costo recurrente del fine-tuning es una nueva corrida por cada cambio en el comportamiento aprendido, más el riesgo de retroceso que carga cada corrida.

Así que la arquitectura combinada no es un compromiso, es el diseño en sí: incorpora la forma en los pesos, mantén los hechos en la recuperación, y versiona cada uno de forma independiente. La forma cambia poco y tolera un ciclo de actualización lento; los hechos cambian constantemente y exigen uno rápido. Separarlos permite que cada uno avance a su propio ritmo, y te deja reevaluar el modelo ajustado sin reindexar tu corpus, o actualizar el corpus sin volver a ejecutar un trabajo de entrenamiento.

Juno¿Prompt, RAG o fine-tuning? La escalera está ordenada por costo de iteración: un prompt se edita en segundos, una fuente se actualiza sin tocar el modelo, un fine-tune es un ciclo completo de entrenar-evaluar-redesplegar. Diagnostica la brecha antes de elegir: el comportamiento va al prompting y luego al fine-tuning, el conocimiento va a la recuperación, y hacer fine-tuning para una brecha de conocimiento es el error costoso que termina lanzando hechos desactualizados e imposibles de citar. La arquitectura de producción los separa a propósito: incorpora la forma en los pesos, mantén los hechos en la recuperación, versiona cada uno de forma independiente para que la forma avance despacio y los hechos avancen rápido.

En la práctica

Los datos de fine-tuning no tienen nada de exótico. Cada ejemplo es una conversación corta con la forma exacta que envías en tiempo de ejecución, terminando con la respuesta que hubieras querido que el modelo dé:

# Aquí se muestran solo unos cuantos; un conjunto de datos real tiene cientos o miles de ejemplos,
# cubriendo todo el rango de entradas que esperas en tiempo de ejecución.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Classify the ticket's urgency as low, medium, or high."},
        {"role": "user", "content": "I was charged twice this week and need it fixed today."},
        {"role": "assistant", "content": "high"},
    ]},
    {"messages": [
        {"role": "system", "content": "Classify the ticket's urgency as low, medium, or high."},
        {"role": "user", "content": "Is there a dark mode setting anywhere?"},
        {"role": "assistant", "content": "low"},
    ]},
    # ...
]

Guardas esto en un archivo, inicias un trabajo de entrenamiento con el proveedor, y esperas a que termine. Lo que obtienes de vuelta es un nuevo id de modelo, al que luego llamas exactamente igual que a cualquier otro modelo:

# El modelo con fine-tuning es simplemente otro id; todo lo demás no cambia.
response = client.chat.completions.create(
    model="your-org/urgency-classifier-v1",
    messages=[
        {"role": "system", "content": "Classify the ticket's urgency as low, medium, or high."},
        {"role": "user", "content": "The export button does nothing when I click it."},
    ],
)
# response.choices[0].message.content -> "low"  (solo la etiqueta, el comportamiento que entrenaste)

La ganancia es que ahora el comportamiento vive dentro del modelo. Las instrucciones pueden ser más cortas, el formato se mantiene a lo largo de miles de llamadas, y no tuviste que hacer crecer el prompt para lograrlo. El costo es todo lo que lo rodea: necesitas un conjunto de datos de calidad, una corrida de entrenamiento, y un trabajo nuevo cada vez que quieras cambiar lo que aprendió, que es exactamente la razón por la que esto está en la base de la escalera. Sube ejemplos, obtén un id de modelo, llámalo como a cualquier otro.

JunoEn la práctica Los datos de fine-tuning son conversaciones de ejemplo que terminan en la respuesta que quieres, entre unos cientos y unos miles de ellas. Subes el archivo, ejecutas un trabajo de entrenamiento, y obtienes de vuelta un nuevo id de modelo que llamas como a cualquier otro. El comportamiento queda incorporado, así que los prompts se acortan y el formato se mantiene consistente, a costa de construir el conjunto de datos y volver a ejecutar el trabajo cada vez que necesite cambiar.

El flujo de trabajo es subir, entrenar, llamar, pero lo que decide si funciona es el conjunto de datos, no el trabajo en sí. La calidad y la cobertura importan más que la cantidad bruta. Cientos de ejemplos limpios y consistentes que abarquen el rango real de entradas superan a miles de ejemplos ruidosos o contradictorios, porque el modelo aprende cualquier regularidad que realmente esté en los datos, incluidos los errores.

Divide tus datos antes de entrenar. Reserva una porción que el modelo nunca vea durante el entrenamiento, el conjunto de validación, y mide la precisión ahí en lugar de en los ejemplos con los que entrenó. Un modelo puede obtener una puntuación casi perfecta en datos que ya ha visto mientras rinde mal en cualquier cosa nueva, así que el número obtenido en los datos apartados es el que te dice si el comportamiento generaliza.

# Reserva una porción que el trabajo de entrenamiento nunca vea, para medir el rendimiento real.
split = int(len(training_examples) * 0.8)
train_set = training_examples[:split]        # el trabajo entrena con estos
validation_set = training_examples[split:]   # tú puntúas el resultado con estos
# El proveedor devuelve un nuevo id de modelo; lo llamas como a cualquier otro modelo.
# La API del trabajo y el manejo de la división varían según el proveedor; algunos toman el archivo de validación directamente.

Dos decisiones de criterio se suman a la mecánica. Primero, confirma que el prompting realmente falló antes de invertir en una corrida de entrenamiento: una instrucción real con unos cuantos ejemplos, probada con entradas variadas, no tu primer borrador rápido. Segundo, evalúa el costo con cuidado. Un fine-tune tiene un costo de entrenamiento fijo que se paga una sola vez frente al costo por llamada de un prompt largo que se paga siempre, así que acortar el prompt vale la pena solo cuando el volumen de llamadas hace que los tokens ahorrados justifiquen el trabajo. Y recuerda el patrón combinado: un modelo ajustado para la forma, RAG para los hechos que no debería intentar memorizar.

JunoEn la práctica El trabajo es subir-entrenar-llamar, pero el conjunto de datos decide el resultado: unos cientos de ejemplos limpios y variados superan a miles ruidosos, porque el modelo aprende lo que realmente está en los datos. Reserva una porción de validación y puntúa ahí, no en los ejemplos de entrenamiento, o un modelo que memorizó se verá mejor de lo que realmente es. Confirma primero que el prompting realmente falló, compara el costo de entrenamiento fijo contra los tokens de prompt que se pagan siempre, y combina el modelo ajustado con RAG para que este se encargue de la forma mientras la recuperación se encarga de los hechos.

El pipeline es subir, entrenar, evaluar, desplegar, y el trabajo de ingeniería está en el conjunto de datos y en el conjunto de evaluación, no en la llamada de entrenamiento. Dos divisiones disciplinadas lo sostienen. Un conjunto de validación, apartado del entrenamiento, te dice si el comportamiento generalizó en lugar de haber sido memorizado. Un conjunto de evaluación separado y apartado, puntuado antes y después, es lo que prueba que el fine-tune ayudó a tu tarea objetivo sin hacer retroceder la habilidad general, la comprobación de olvido catastrófico de la sección anterior hecha concreta.

# Tres porciones disjuntas: entrena con una, ajusta decisiones con otra, juzga con una tercera.
train_set      = examples[:8000]        # el trabajo entrena con estos
validation_set = examples[8000:9000]    # vigila el sobreajuste durante la corrida
eval_set       = examples[9000:]        # puntuado ANTES Y DESPUÉS para probar que no hubo retroceso

# Puntúa el modelo base y el fine-tune sobre el MISMO eval_set, y luego compara.
base_score = run_eval(base_model_id, eval_set)
tuned_score = run_eval(fine_tuned_id, eval_set)
# Lanza solo si tuned_score supera a base en el objetivo Y se mantiene en las comprobaciones de habilidad general.
# La puntuación de evaluación y la API de entrenamiento varían según el proveedor; la disciplina no.

La calidad del conjunto de datos es donde se gana o se pierde la batalla contra el sobreajuste y la deriva. Un conjunto de datos acotado o con rarezas entrena un modelo que memoriza las particularidades de tu conjunto y falla con entradas que difieren, así que la cobertura de la distribución real de entradas importa más que la cantidad, y vuelves a medir a medida que el tráfico de producción se aleja de lo que entrenaste. Las evaluaciones desactualizadas son la forma en que un modelo que se está desviando en silencio pasa la revisión y falla con los usuarios.

La realidad operativa para la que hay que diseñar es que cada cambio en el comportamiento aprendido es una corrida completa, no una edición. Volver a curar, reentrenar, reevaluar, redesplegar un nuevo id fijado, cada vez. Ese costo recurrente, más el riesgo de retroceso en cada corrida, es la razón por la que mantienes los hechos en RAG donde se actualizan en vivo, reservas el fine-tuning para comportamientos que cambian despacio, y tratas cada id ajustado como un artefacto versionado al que puedes revertir cuando una nueva corrida retrocede.

JunoEn la práctica El pipeline es subir-entrenar-evaluar-desplegar, y el trabajo está en las divisiones de datos, no en la llamada: un conjunto de validación detecta la memorización, un conjunto de evaluación apartado y puntuado antes y después prueba que no hubo retroceso. La cobertura del conjunto de datos sobre la distribución real de entradas es lo que te permite vencer el sobreajuste y la deriva, así que vuelve a medir a medida que el tráfico se aleja de tus datos de entrenamiento. Y diseña para el costo recurrente: cada cambio de comportamiento es un ciclo completo de reentrenamiento, evaluación y redespliegue, por eso los hechos pertenecen a RAG y cada id ajustado es un artefacto versionado al que puedes revertir.

Esa es la última de las formas de moldear lo que un modelo sabe y cómo responde, todas las cuales lo dejan prediciendo texto sobre un escenario que tú preparaste. Los próximos capítulos le dan la capacidad de actuar: en Uso de herramientas el modelo llama a tus propias funciones, y luego las ejecuta en un ciclo como agente.