Ajuste fino

docs.scrimba.com

El ajuste fino significa tomar un modelo existente y continuar entrenándolo con tus propios ejemplos, de modo que su comportamiento predeterminado se desplace hacia lo que deseas. Este capítulo es la imagen de trabajo de lo que cambia, para qué es bueno, y cuándo recurrir a él en lugar de un prompt o retrieval.

Qué es lo que el entrenamiento realmente hace

Para ver qué cambios trae el ajuste fino, es útil saber de dónde viene un modelo. Un modelo se construye en dos etapas amplias.

La primera es preentrenamiento: 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 se asientan en él como un efecto secundario. Lo que resulta es un modelo base, fluido pero sin enfoque. Continuará tu texto felizmente, pero no ha sido entrenado para ser un asistente útil que responda preguntas.

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

Ambas etapas funcionan por el mismo mecanismo: mostrar al modelo ejemplos e impulsar sus números internos, sus parámetros o pesos, de modo que sus predicciones se acerquen a esos ejemplos. El entrenamiento es práctica de predicción que deja el modelo permanentemente modificado.

JunoQué es lo que el entrenamiento realmente hace Un modelo se construye en dos etapas. El preentrenamiento lo hace predecir el siguiente token a través de enormes cantidades de texto, produciendo un modelo base fluido pero sin enfoque. El post-entrenamiento luego lo entrena en respuestas buenas seleccionadas y retroalimentación humana, convirtiéndolo en un asistente útil. Ambos funcionan de la misma manera: ajustando los pesos internos del modelo para que sus predicciones coincidan con los ejemplos que se le muestran.

Un modelo te llega después de dos etapas de entrenamiento, y conocer la forma de cada una te dice qué puede mover el ajuste fino.

El preentrenamiento viene primero: el modelo lee una cantidad vasta de texto y ejecuta un 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 un efecto secundario. El resultado es un modelo base, fluido en continuar texto pero aún no un asistente. No sabe responder una pregunta en lugar de extenderla.

El post-entrenamiento es la segunda etapa, y es la que el ajuste fino imita. El modelo base se entrena más con ejemplos seleccionados de buenas respuestas más señales de preferencia humana sobre qué respuesta es mejor. Eso es lo que produce el comportamiento de seguimiento de instrucciones que llamas desde una API.

Ambas etapas ejecutan el mismo bucle: alimentar al modelo con un ejemplo, comparar su predicción con el objetivo, y ajustar los pesos para cerrar la brecha. El ajuste fino es ese mismo bucle, limitado a tus ejemplos y ejecutado después de las dos etapas del proveedor. El entrenamiento cambia el comportamiento editando pesos, no añadiendo una tabla de búsqueda, y esa distinción es la razón completa por la que el ajuste fino es bueno en algunos trabajos y malo en otros.

JunoQué es lo que el entrenamiento realmente hace Dos etapas te lleva a un modelo: el preentrenamiento perfecciona la predicción del siguiente token en un modelo base fluido, luego el post-entrenamiento lo da forma en un asistente con ejemplos seleccionados y datos de preferencia. Ambos ejecutan el mismo bucle, alimentan un ejemplo, ajustan los pesos hacia él, y el ajuste fino es ese bucle limitado a tus datos. Edita pesos, no añade una tabla de búsqueda, que es por qué cambia el comportamiento bien y almacena hechos pobremente.

Un modelo llega después de dos etapas de entrenamiento, y el límite entre ellas es donde vive el ajuste fino.

El preentrenamiento es la etapa cara, una vez por modelo: enormes corpus de texto, el objetivo único de predicción del siguiente token, y los pesos (los números ajustables del modelo) absorbiendo gramática, conocimiento y razonamiento como un subproducto. La salida es un modelo base, fluido pero no dirigido hacia ser útil. El post-entrenamiento luego alinea ese modelo base en un asistente usando demostraciones seleccionadas y datos de preferencia humana. En el momento en que llamas a un modelo de API, ambos han ejecutado.

El ajuste fino es una continuación del post-entrenamiento, limitada a tus datos y ejecutada en la parte superior de un modelo ya alineado. El mecanismo es idéntico: presenta un ejemplo, mide cuán lejos se encuentra la predicción del objetivo, ajusta los pesos para reducir esa brecha. La consecuencia que importa operacionalmente es que el ajuste fino mueve los mismos parámetros globales que contienen todo lo demás. No estás añadiendo un módulo, estás ajustando una superficie compartida, que es por qué un ajuste fino puede mejorar tu tarea objetivo y silenciosamente degradar una capacidad no relacionada al mismo tiempo.

Esa propiedad de superficie compartida configura cada modo de falla más adelante en este capítulo: sobreajuste, olvido catastrófico, deriva. El ajuste fino remoldea el comportamiento, nunca instala un almacén de hechos. Mantén eso en mente y llegarás a él por las razones correctas y lo saltarás por las incorrectas.

JunoQué es lo que el entrenamiento realmente hace El preentrenamiento es el peso pesado una vez por modelo que perfecciona la predicción del siguiente token en un modelo base, el post-entrenamiento lo alinea en un asistente, y el ajuste fino continúa esa segunda etapa en tus datos. El mismo bucle cada vez: presenta un ejemplo, ajusta los pesos hacia él. La trampa es que estás ajustando parámetros globales compartidos, no pernando un módulo, así que un ajuste fino puede elevar tu tarea y mellar una no relacionada en la misma ejecución, que es de donde vienen el sobreajuste y el olvido.

Qué es el ajuste fino

El ajuste fino es una versión pequeña y dirigida de esa segunda etapa, ejecutada por ti. Tomas un modelo que ya está entrenado y continúas entrenándolo en un conjunto de tus propios ejemplos, cada uno una entrada emparejada con la salida que deseas que produjera. Después de suficientes ejemplos, los pesos del modelo se desplazan para que este tipo de respuesta sea su predeterminada, sin que tengas que pedirlo en el prompt cada vez.

La distinción real del prompting y el RAG es dónde vive el cambio. El prompting y el RAG dejan el modelo congelado y lo dirigen a través del contexto que suministras en el momento de la llamada. El ajuste fino cambia el modelo mismo, para que el nuevo comportamiento esté incorporado y se muestre incluso con un prompt corto. No estás dando mejores instrucciones en tiempo de ejecución; estás enviando un modelo que ya se inclina de la manera que deseas.

En la práctica le pasas al proveedor un archivo de ejemplos de conversaciones, ejecuta un trabajo de entrenamiento, y te devuelve un nuevo id de modelo. Llamas ese id exactamente como cualquier otro modelo, excepto que sus respuestas ahora reflejan lo que entrenaste. El ajuste fino mueve el comportamiento hacia el modelo, el prompting y el RAG dirigen uno congelado.

JunoQué es el ajuste fino El ajuste fino es una versión pequeña del post-entrenamiento que ejecutas: continúa entrenando un modelo existente en tus propios ejemplos de entrada-salida hasta que el comportamiento que deseas se convierte en su predeterminado. A diferencia del prompting y el RAG, que dirigen un modelo congelado a través del contexto, el ajuste fino cambia los pesos del modelo, por lo que el comportamiento está incorporado y se muestra incluso con un prompt corto. Entregas un archivo de ejemplos y obtienes un id de modelo nuevo que llamas como cualquier otro.

El ajuste fino es post-entrenamiento limitado a una tarea y ejecutado por ti. Comienzas desde un modelo ya entrenado y continúas entrenándolo con ejemplos, cada uno una entrada emparejada con la salida que deseas que hubiera producido. Alimentalo con suficientes de ellos y los pesos se asientan para que esa respuesta sea la predeterminada, sin instrucción en el prompt pidiéndola.

La línea que importa es dónde vive la dirección. El prompting y el RAG dejan los pesos congelados y dan forma al comportamiento a través del contexto suministrado en el momento de la llamada, de modo que cada llamada lleva las instrucciones. El ajuste fino edita los pesos una vez, por adelantado, para que el comportamiento se envíe dentro del id de modelo y sobreviva a un prompt corto. Dirección de tiempo de ejecución versus comportamiento incorporado: ese es el intercambio que estás haciendo.

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

# Cada ejemplo es una conversación en la forma exacta que envías en tiempo de ejecución,
# terminando con la salida que deseas que el modelo aprenda.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Clasifica la urgencia del ticket como baja, media o alta."},
        {"role": "user", "content": "Me cobraron dos veces esta semana y necesito que se corrija hoy."},
        {"role": "assistant", "content": "alta"},
    ]},
    {"messages": [
        {"role": "system", "content": "Clasifica la urgencia del ticket como baja, media o alta."},
        {"role": "user", "content": "¿Hay una configuración de modo oscuro en algún lugar?"},
        {"role": "assistant", "content": "baja"},
    ]},
    # ... cientos a miles más, cubriendo el rango completo de entradas que esperas
]
# La forma del mensaje y la API del trabajo de entrenamiento varían por proveedor; la idea es la misma.

JunoQué es el ajuste fino El ajuste fino es post-entrenamiento limitado a tu tarea: continúa entrenando un modelo en ejemplos de entrada-salida hasta que el comportamiento que deseas es el predeterminado. El prompting y el RAG dirigen un modelo congelado a través del contexto cada llamada, el ajuste fino edita los pesos una vez para que el comportamiento se monte dentro del id de modelo. Construyes un archivo de ejemplos de conversaciones, ejecutas un trabajo de entrenamiento, y llamas el id devuelto como cualquier otro modelo.

El ajuste fino es post-entrenamiento continuado en un conjunto de datos que controlas, produciendo 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 conviertan en la predeterminada del modelo. El comportamiento se envía en los pesos, de modo que un prompt corto es suficiente para evocarlo.

Póntelo contra las alternativas precisamente, porque la diferencia es operacional, no filosófica. El prompting y el 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), que significa que puedes cambiar el comportamiento editando una cadena y redesplegando en segundos. El ajuste fino incorpora el comportamiento en los pesos, que significa que cambiarlo requiere una nueva ejecución de entrenamiento, un paso de eval, y un redesplegamiento de un nuevo id de modelo. La dirección de tiempo de ejecución es editable en segundos, un ajuste fino es editable solo en un ciclo de entrenamiento.

# Un modelo ajustado fino es 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": "Clasifica la urgencia del ticket como baja, media o alta."},
        {"role": "user", "content": "El botón de exportación no hace nada cuando hago clic en él."},
    ],
)
# response.choices[0].message.content -> "baja"  (solo la etiqueta, el comportamiento que entrenaste)
# La forma de la llamada mostrada es estilo OpenAI-SDK; varía por proveedor.

Esa asimetría de costo es la cosa a internalizar antes de que te comprometas. Un id ajustado fino es un artefacto versionado: eres dueño de su ciclo de vida, sus evals, y su re-entrenamiento cada vez que el comportamiento deseado se mueve. Fija el id, versiona lo, y presupuesta para el hecho de que cada cambio en lo que aprendió es otro trabajo, no otro commit.

JunoQué es el ajuste fino El ajuste fino es post-entrenamiento continuado en tus datos, produciendo un modelo derivado detrás de un nuevo id cuyo comportamiento vive en los pesos. El contraste con el prompting y el RAG es operacional: la dirección de tiempo de ejecución es una cadena editable que redespiegas en segundos, un ajuste fino es un artefacto versionado que cambias solo a través de una ejecución de entrenamiento, un paso de eval, y un redesplegamiento. Fija el id, trátalo como un contrato, y presupuesta para el hecho de que cada cambio de comportamiento es otro trabajo.

En qué es bueno y en qué no

El ajuste fino gana su lugar cuando necesitas un comportamiento consistente que un prompt lucha por asegurar: un formato de salida preciso cada vez, un tono específico o un estilo de casa, o una tarea estrecha como clasificación hecha de manera confiable en miles de llamadas. También puede hacer que las llamadas sean más baratas y rápidas, porque el comportamiento que de otro modo deletrearías en un prompt largo se incorpora al modelo, por lo que tus prompts se acortan.

Donde falla es en conocimiento. El ajuste fino es pobre para enseñar a un modelo nuevos hechos, y peor para hechos que cambian. Los ejemplos de entrenamiento se desdibujan en patrones generales en lugar de almacenarse como entradas exactas y buscables, por lo que un modelo ajustado fino aún inventa detalles y aún se vuelve obsoleto el momento en que tu información se actualiza. Re-entrenar cada vez que un precio o una política cambia es lento y costoso. Cuando el problema es "el modelo no sabe X", la respuesta es casi siempre RAG, no ajuste fino.

La regla de oro: ajusta fino para cambiar la forma, no para añadir hechos. Enseña al modelo cómo responder, y deja que la retrieval maneje qué responder.

JunoEn qué es bueno y en qué no El ajuste fino es bueno para comportamiento consistente: un formato de salida fijo, un tono específico, o una tarea estrecha hecha de manera confiable, y puede acortar prompts de modo que las llamadas cuesta menos. Es malo para conocimiento: no almacena hechos de manera confiable, se vuelve obsoleto cuando cambian, y es costoso volver a entrenar. La regla es ajustar fino para cambiar la forma, no para añadir hechos, y dejar que RAG maneje los hechos.

El ajuste fino paga dividendos para forma: una forma de salida precisa en cada llamada, un tono fijo o un estilo de casa, o una tarea estrecha como clasificación mantenida firme en miles de solicitudes. La victoria compone cuando el prompting solo sigue desviándose, el modelo honra el formato la mayoría de las veces pero no de manera lo suficientemente confiable para analizar en sentido descendente. Incorpora el comportamiento y el formato deja de ser algo que esperas en cada llamada.

También acorta prompts, y a escala es una palanca de costo real. Si actualmente deletreas el formato y unos pocos ejemplos en cada solicitud, esos tokens de instrucción se facturan en cada llamada. Pliéguelos en los pesos y el prompt por llamada se encoge. La aritmética vale la pena hacer: un ajuste fino tiene un costo de entrenamiento fijo pagado una vez, mientras que un prompt largo tiene un costo por llamada pagado para siempre, de modo que el acortamiento de prompts paga cuando el volumen de llamadas es lo suficientemente alto para que los tokens ahorrados superen la factura de entrenamiento.

Donde falla es en conocimiento. Los ejemplos de entrenamiento se desdibujan en patrones generales, no entradas exactamente recuperables, de modo que un modelo ajustado fino aún inventa detalles y aún se vuelve obsoleto el momento en que un precio o política cambia. Actualizar un hecho significa otro trabajo de entrenamiento. Ajusta fino para forma, usa RAG para hechos, y combinálos. El patrón fuerte es ambos a la vez: ajusta fino el modelo para tu forma y tono, luego recupera hechos actuales en tiempo de ejecución y deja que el modelo ajustado los exprese.

Antes de que subes a ajuste fino en absoluto, confirma que el prompting realmente falló. "Falló" significa una instrucción clara con unos pocos ejemplos bien elegidos, probados en entradas variadas, aún así pierde la tasa objetivo, no que tu primer prompt de una línea se veía mal. Si no has ejecutado esa prueba, no estás listo para ajuste fino.

JunoEn qué es bueno y en qué no El ajuste fino es para forma: una forma de salida fija, un tono establecido, una tarea estrecha mantenida firme, además de prompts más cortos que ahorran tokens en cada llamada. La aritmética de costos es entrenamiento fijo de una sola vez versus tokens de prompt pagados para siempre, de modo que el acortamiento de prompts paga a alto volumen. Es pobre en hechos, que se desdibujan en patrones y se vuelven obsoletos, así que empareja un modelo ajustado fino con RAG: forma de los pesos, hechos de retrieval. Y prueba que el prompting realmente falló, un prompt real con ejemplos probados en entradas variadas, antes de que subes.

El ajuste fino es confiable para forma e inconsistente para hechos, y las razones son mecánicas. Forma, forma de salida, tono, convenciones de tarea, es una regularidad de comportamiento que los pesos pueden absorber en muchos ejemplos. Los hechos son discretos y cambiables, y los pesos los almacenan sin pérdida como patrones mezclados, no como filas recuperables, de modo que un modelo ajustado fino aún confabula y aún se vuelve obsoleto el instante en que el hecho subyacente se mueve.

Empuja más allá del titular y los riesgos reales son las formas en que un ajuste fino se degrada. Sobreajuste es el modelo memorizando tu conjunto de entrenamiento, incluidas sus peculiaridades, en lugar de aprender el comportamiento general, de modo que clava tus ejemplos y tropieza en entradas que difieren. Olvido catastrófico es el lado opuesto: entrenar duro en una tarea estrecha puede erosionar la capacidad general no relacionada que el modelo base tenía, porque estás moviendo pesos compartidos, de modo que tu clasificador se vuelve más agudo mientras que su razonamiento en cualquier otra cosa se vuelve más opaco. Deriva de distribución es la lenta: un modelo ajustado fino en la distribución de entrada del trimestre pasado decae conforme el tráfico real se aleja de lo que vio, y el decaimiento es silencioso hasta que lo midas.

Dos consecuencias dan forma a cómo realmente ejecutas esto. Primero, no puedes enviar un ajuste fino por vibraciones; necesitas un conjunto de eval, un lote retenido de entradas con respuestas sabe-buenas, puntuadas antes y después, para probar que el objetivo mejoró y, no menos importante, que la capacidad general no regresionó. Segundo, cada cambio en el comportamiento deseado es otro trabajo completo: re-curar datos, re-entrenar, re-eval, redesplegamiento de un nuevo id. Ese arrastre operacional es por qué métodos eficientes en parámetros existen en absoluto, formas de ajustar fino entrenando un pequeño conjunto de pesos añadidos en lugar del modelo completo, más barato de ejecutar y almacenar, aunque la decisión de si ajustar fino es sin cambios por ellos. De cualquier forma, prueba que el ajuste fino no regresionó antes de que lo envíes.

JunoEn qué es bueno y en qué no La forma se absorbe en pesos, los hechos no: un ajuste fino aún confabula y se vuelve obsoleto, de modo que mantén los hechos en retrieval. Los riesgos son sobreajuste (memorizar tu conjunto, tropezar en entradas nuevas), olvido catastrófico (el entrenamiento estrecho erosionando capacidad no relacionada ya que los pesos son compartidos), y deriva de distribución conforme el tráfico real se aleja de tus datos de entrenamiento. Así que cierra cada ajuste fino en un eval retenido puntuado antes y después para probar sin regresión, y presupuesta para el hecho de que cada cambio de comportamiento es un ciclo completo retrain-eval-redeploy, que es la razón completa por la que métodos eficientes en parámetros existen.

¿Prompt, RAG o ajuste fino?

La mayoría de las veces no comienzas aquí. Las tres técnicas forman una escalera, más barata y rápida de cambiar primero:

1. Prompting. Siempre intenta esto 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 hecho que el prompt funcione, no estás listo para ajuste fino.
2. RAG. Recurre a esto cuando la brecha es conocimiento: el modelo necesita hechos que no tiene, o que cambian con el tiempo. RAG los suministra en el momento de la pregunta sin tocar el modelo.
3. Ajuste fino. Recurre a esto cuando la brecha es comportamiento en lugar de conocimiento y el prompting no puede hacerlo consistente suficientemente, o cuando tus prompts se han vuelto tan largos que incorporar las instrucciones en el modelo es más barato y rápido a escala.

No son exclusivos, y los sistemas más fuertes los combinan: ajusta fino un modelo para tu forma y tono, luego usa RAG para alimentarlo con hechos actuales en tiempo de ejecución. Comportamiento del entrenamiento, conocimiento de retrieval.

Así que una prueba rápida antes de que ajustes fino. ¿Puedes llegar allá con un mejor prompt? Entonces haz eso. ¿Es la brecha conocimiento faltante? Entonces es RAG.

Sube la escalera; el ajuste fino es el último escalón, no el primero. Solo cuando el prompt ya es correcto, los hechos ya están disponibles, y el modelo aún no se comportará de manera lo suficientemente consistente es que el ajuste fino se convierte en la herramienta que encaja.

Juno¿Prompt, RAG o ajuste fino? Trata los tres como una escalera: prompt primero porque es instantáneo y barato, añade RAG cuando el modelo carece de conocimiento, y ajusta fino solo cuando la brecha es comportamiento que el prompting no puede hacer consistente, o para acortar prompts largos a escala. Se combinan bien: ajusta fino para forma, usa RAG para hechos. El ajuste fino es el último escalón al que recurres, no el primero.

Las tres técnicas forman una escalera, ordenada por qué tan rápido y barato 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 pocos ejemplos cubre más terreno de lo que la gente espera. Hasta que un prompt real haya sido probado y falle, los escalones más altos son prematuros.
2. RAG. Cuando la brecha es conocimiento, hechos que el modelo carece o que cambian con el tiempo, la retrieval los suministra en el momento de la pregunta y deja los pesos solos. Actualizar un hecho es actualizar tu fuente, no re-entrenar.
3. Ajuste fino. Cuando la brecha es comportamiento que el prompting no puede asegurar, o cuando los prompts se han vuelto lo suficientemente largos que incorporar instrucciones en los pesos es más barato a escala.

El diagnóstico que te pone en el escalón correcto es nombrar la brecha. Una forma o tono incorrecto es una brecha de comportamiento, de modo que prompt, luego ajuste fino. Un hecho faltante u obsoleto es una brecha de conocimiento, de modo que recupera. Lee mal la brecha y ajustarás fino para arreglar un problema de conocimiento y la verás envejecer, o meteras hechos en un prompt que un paso de retrieval debería haber obtenido.

No son exclusivos, y el patrón combinado es el que recurres en producción: ajusta fino para forma, RAG para hechos, juntos. Un modelo ajustado fino para tu forma y tono, alimentado con hechos actuales en tiempo de ejecución, te da forma consistente y contenido fresco a la vez, ninguno de los cuales la otra técnica entregaría sola.

Si puedes siquiera ajuste fino depende del modelo. Los proveedores cerrados ofrecen ajuste fino administrado de sus propios modelos; un modelo de peso abierto lo puedes ajuste fino tú mismo en tus propios términos, que es una de las razones para recurrir a pesos abiertos (Modelos abiertos y cerrados).

Juno¿Prompt, RAG o ajuste fino? Sube la escalera desde el escalón más barato: prompt primero, añade RAG cuando la brecha es conocimiento, ajusta fino solo cuando es comportamiento que el prompting no puede asegurar o para acortar prompts a escala. El diagnóstico es nombrar la brecha, forma o tono significa comportamiento, un hecho faltante o obsoleto significa retrieval. El movimiento de producción es ambos juntos: ajusta fino para forma, RAG para hechos, de modo que obtienes forma consistente y contenido fresco a la vez.

La escalera, prompt luego RAG luego ajuste fino, está ordenada por costo de iteración: qué tan rápido y barato es cambiar el comportamiento una vez enviado. Un prompt es una cadena que editas y redespiegas en segundos. Una fuente de retrieval es datos que actualizas sin tocar el modelo. Un ajuste fino es una ejecución de entrenamiento, un paso de eval, 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 probadamente no pueden alcanzar.

La habilidad real es diagnosticar la brecha correctamente, porque el modo de falla es elegir la herramienta que no la aborda. Una brecha de comportamiento (forma incorrecta, tono incorrecto, adherencia a tareas inconsistentes) es lo que el prompting y luego el ajuste fino arreglan. Una brecha de conocimiento (un hecho que el modelo carece, o uno que cambia) es lo que la retrieval arregla, y ajuste fino una brecha de conocimiento es el error clásico caro: entrenas hechos, envejecen por la siguiente actualización, y no puedes citarlos.

Mantén la asimetría operacional junto al diagnóstico. El costo recurrente del RAG es la calidad de la retrieval y la latencia en cada llamada, pagada para siempre pero ajustable en vivo. El costo recurrente del ajuste fino es una re-ejecución en cada cambio de comportamiento aprendido, más el riesgo de regresión que cada ejecución conlleva.

Así que la arquitectura combinada no es un compromiso, es el diseño: afina forma en los pesos, mantén hechos en retrieval, y versiona cada uno independientemente. La forma cambia raramente y tolera un ciclo de actualización lento; los hechos cambian constantemente y demandan uno rápido. Dividirlos permite que cada uno se mueva a su propia velocidad, y permite que re-evalúes el modelo ajustado sin re-indexar tu corpus, o actualices el corpus sin re-ejecutar un trabajo de entrenamiento.

Juno¿Prompt, RAG o ajuste fino? La escalera está ordenada por costo de iteración: un prompt edita en segundos, una fuente actualiza sin el modelo, un ajuste fino es un full train-eval-redeploy. Diagnostica la brecha antes de elegir, comportamiento va al prompting luego ajuste fino, conocimiento va a retrieval, y ajuste fino una brecha de conocimiento es el error caro que envía hechos obsoletos no citables. La arquitectura de producción los divide a propósito: afina forma en los pesos, mantén hechos en retrieval, versiona cada uno independientemente de modo que forma pueda moverse lentamente y hechos pueda moverse rápido.

En la práctica

Los datos de ajuste fino no son nada exótico. Cada ejemplo es una conversación corta en la forma exacta que envías en tiempo de ejecución, terminando con la respuesta que deseas que el modelo hubiera dado:

# Algunos mostrados aquí; un conjunto de datos real es cientos a miles de ejemplos,
# cubriendo el rango completo de entradas que esperas en tiempo de ejecución.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Clasifica la urgencia del ticket como baja, media o alta."},
        {"role": "user", "content": "Me cobraron dos veces esta semana y necesito que se corrija hoy."},
        {"role": "assistant", "content": "alta"},
    ]},
    {"messages": [
        {"role": "system", "content": "Clasifica la urgencia del ticket como baja, media o alta."},
        {"role": "user", "content": "¿Hay una configuración de modo oscuro en algún lugar?"},
        {"role": "assistant", "content": "baja"},
    ]},
    # ...
]

Guardas estos en un archivo, inicias un trabajo de entrenamiento con el proveedor, y esperas a que termine. Lo que vuelve es un nuevo id de modelo, que luego llamas exactamente como cualquier otro modelo:

# El modelo ajustado fino es otro id; todo lo demás no cambia.
response = client.chat.completions.create(
    model="your-org/urgency-classifier-v1",
    messages=[
        {"role": "system", "content": "Clasifica la urgencia del ticket como baja, media o alta."},
        {"role": "user", "content": "El botón de exportación no hace nada cuando hago clic en él."},
    ],
)
# response.choices[0].message.content -> "baja"  (solo la etiqueta, el comportamiento que entrenaste)

La victoria es que el comportamiento ahora vive en el modelo. Las instrucciones pueden ser más cortas, el formato se mantiene en miles de llamadas, y no tuviste que crecer el prompt para llegar allá. El costo es todo lo que hay alrededor: necesitas un conjunto de datos de calidad, una ejecución de entrenamiento, y un trabajo fresco cada vez que deseas cambiar lo que aprendió, que es exactamente por qué esto se sienta al fondo de la escalera. Carga ejemplos, obtén un id de modelo, llámalo como cualquier otro.

JunoEn la práctica Los datos de ajuste fino son ejemplos de conversaciones terminando en la respuesta que deseas, unos cuantos cientos a unos cuantos miles de ellos. Cargas el archivo, ejecutas un trabajo de entrenamiento, y obtienes un nuevo id de modelo que llamas como cualquier otro. El comportamiento está entonces incorporado, de modo que los prompts se acortan y el formato se mantiene consistente, al costo de construir el conjunto de datos y re-ejecutar el trabajo cada vez que necesita cambiar.

El flujo de trabajo es cargar, entrenar, llamar, pero la parte que decide si funciona es el conjunto de datos, no el trabajo. La calidad y cobertura importan más que el conteo crudo. Cientos de ejemplos limpios y consistentes que abarcan el rango real de entradas vencen a miles de ruidosos o contradictorios, porque el modelo aprende cualquier regularidad que esté realmente en los datos, incluyendo los errores.

Divide tu datos antes de entrenar. Retén una porción que el modelo nunca ve durante el entrenamiento, el conjunto de validación, y verifica su precisión allá en lugar de en los ejemplos en los que entrenó. Un modelo puede puntuar casi perfectamente en datos que ya ha visto mientras lo hace mal en cualquier cosa nueva, de modo que el número retenido es el que te dice si el comportamiento se generaliza.

# Retén una porción que el trabajo de entrenamiento nunca ve, para medir desempeño real.
split = int(len(training_examples) * 0.8)
train_set = training_examples[:split]        # el trabajo entrena en estos
validation_set = training_examples[split:]   # puntúas el resultado en estos
# El proveedor devuelve un nuevo id de modelo; lo llamas como cualquier otro modelo.
# La API del trabajo y la división varían por proveedor; algunos toman el archivo de validación directamente.

Dos llamadas de juicio se sientan en la parte superior de la mecánica. Primero, confirma que el prompting realmente falló antes de gastar una ejecución de entrenamiento: una instrucción real con unos pocos ejemplos, probados en entradas variadas, no tu primer borrador aproximado. Segundo, pesa el costo cuidadosamente. Un ajuste fino es un costo de entrenamiento fijo pagado una vez contra el costo por llamada de un prompt largo pagado para siempre, de modo que el acortamiento de prompts paga solo cuando el volumen de llamada hace que los tokens ahorrados valgan la pena el trabajo. Y recuerda el patrón combinado: un modelo ajustado fino para forma, RAG para los hechos que no debería intentar memorizar.

JunoEn la práctica El trabajo es cargar-entrenar-llamar, pero el conjunto de datos decide el resultado: unos cuantos cientos de ejemplos limpios y variados vencen a miles de ruidosos, ya que el modelo aprende lo que esté realmente en los datos. Retén una porción de validación y puntúa allá, no en los ejemplos de entrenamiento, o un modelo que memorizó se verá mejor de lo que es. Confirma que el prompting realmente falló primero, pesa el costo fijo de entrenamiento contra tokens de prompt pagados para siempre, y empareja el modelo ajustado fino con RAG de modo que maneje forma mientras que retrieval maneja hechos.

La tubería es cargar, entrenar, evaluar, desplegar, y la ingeniería vive en el conjunto de datos y el conjunto de eval, no la llamada de entrenamiento. Dos disciplinas de división lo llevan. Un conjunto de validación, retenido del entrenamiento, te dice si el comportamiento se generalizó en lugar de ser memorizado. Un conjunto de eval retenido separado, puntuado antes y después, es lo que prueba que el ajuste fino ayudó tu objetivo sin regresión de capacidad general, la verificación del olvido catastrófico de la última sección hecha concreta.

# Tres segmentos disjuntos: entrena en uno, toma decisiones de ajuste en otro, juzga en un tercero.
train_set      = examples[:8000]        # el trabajo entrena en estos
validation_set = examples[8000:9000]    # vigila el sobreajuste durante la ejecución
eval_set       = examples[9000:]        # puntuado ANTES Y DESPUÉS para probar sin regresión

# Puntúa el modelo base y el ajustado fino en el MISMO eval_set, luego compara.
base_score = run_eval(base_model_id, eval_set)
tuned_score = run_eval(fine_tuned_id, eval_set)
# Envía solo si tuned_score supera base en el objetivo Y se mantiene en verificaciones de capacidad general.
# La puntuación de eval y la API de entrenamiento varían por proveedor; la disciplina no.

La calidad del conjunto de datos es dónde el sobreajuste y la deriva se ganan o se pierden. Un conjunto de datos estrecho o peculiar entrena un modelo que memoriza las idiosincrasias de tu conjunto y tropieza en entradas que difieren, de modo que la cobertura de la distribución real de entrada importa más que el conteo, y re-mides conforme el tráfico de producción se aleja de lo que entrenaste. Los evals obsoletos son cómo un modelo lentamente derivando silenciosamente pasa revisión y falla usuarios.

La realidad operacional de diseñar es que cada cambio de comportamiento aprendido es una re-ejecución completa, no una edición. Re-curar, re-entrenar, re-eval, redesplegamiento de un nuevo id fijado, cada vez. Ese costo recurrente, más el riesgo de regresión en cada ejecución, es por qué mantienes hechos en RAG donde se actualizan en vivo, reservas el ajuste fino para comportamiento que cambia lentamente, y tratas cada id ajustado fino como un artefacto versionado que puedes revertir a cuando una nueva ejecución regresiona.

JunoEn la práctica La tubería es cargar-entrenar-eval-desplegar, y el trabajo está en las divisiones de datos, no la llamada: un conjunto de validación atrapa memorización, un conjunto de eval retenido puntuado antes y después prueba sin regresión. La cobertura del conjunto de datos de la distribución real de entrada es cómo vences sobreajuste y deriva, de modo que re-mides conforme el tráfico se aleja de tus datos de entrenamiento. Y diseña para el costo recurrente, cada cambio de comportamiento es una retrain-eval-redeploy completa, que es por qué los hechos pertenecen a RAG y cada id ajustado fino es un artefacto versionado que puedes revertir.

Ese es el último de los caminos para dar forma a lo que un modelo sabe y cómo responde, todos los cuales lo dejan prediciendo texto en un escritorio que arreglaste. 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 bucle como agente.