Este es el primer módulo del Curso de Fine-tuning práctico, y arranca con la decisión que más plata ahorra: la de no hacerlo. El fine-tuning tiene un problema de reputación invertido — suena a la solución seria, a la que separa al que “de verdad sabe” del que solo escribe prompts. Y por eso se usa mal: equipos que arman un dataset de tres semanas, arriendan una A100, entrenan un LoRA y descubren que el modelo sigue sin saber el precio actualizado del producto, porque ese dato nunca estuvo en el entrenamiento y nunca iba a estar. Este curso completo — trece módulos: doce más un bonus sobre embeddings y rerankers — es una guía práctica de cómo afinar un modelo abierto de punta a punta: dataset, formato, LoRA y QLoRA, hiperparámetros, evaluación, merge y despliegue. Pero el módulo 1 es el filtro. Si al final de esta lectura decides no hacer fine-tuning, el curso ya te pagó.

La tesis del módulo

El fine-tuning enseña comportamiento, no hechos. Cambia cómo el modelo responde: su formato, su tono, su forma de resolver una tarea acotada. No cambia lo que sabe del mundo, y sobre todo no cambia lo que sabe hoy y mañana ya no. Cada vez que el problema real es “el modelo no conoce este dato”, la respuesta es contexto, no gradientes.

La escalera de decisión

Antes de entrenar cualquier cosa hay cuatro peldaños que se suben en orden, y cada uno es entre diez y cien veces más barato que el siguiente. Saltárselos no es ser ambicioso: es pagar de más por un resultado que muchas veces es peor.

START ──► ┌──────────────────────┐
          │  1. PROMPT + system  │  horas
          └──────────┬───────────┘
                     │ ¿alcanza?
              sí ◄───┤
                     │ no
                     ▼
          ┌──────────────────────┐
          │  2. FEW-SHOT         │  horas
          │     3-10 ejemplos    │
          └──────────┬───────────┘
                     │ ¿falta info?
                     ▼
          ┌──────────────────────┐
          │  3. RAG              │  días
          │     contexto externo │
          └──────────┬───────────┘
                     │ ¿falta conducta?
                     ▼
          ┌──────────────────────┐
          │  4. FINE-TUNING      │  semanas
          │     LoRA / QLoRA     │
          └──────────┬───────────┘
                     │ ¿dominio ajeno?
                     ▼
          ┌──────────────────────┐
          │  5. CONT. PRETRAIN   │  meses
          └──────────┬───────────┘
                     ▼
                    END

Peldaño 1: el prompt. Un buen system prompt (glosar: el mensaje de rol “system” que define quién es el modelo, qué debe hacer y qué reglas sigue, y que va antes de cualquier turno del usuario) resuelve una fracción sorprendente de los casos que la gente lleva a fine-tuning. Antes de descartarlo, hay que haberlo escrito con reglas explícitas, con formato de salida especificado y con criterios de negativa. Un prompt de tres líneas no es “ya probamos con prompt”.

Peldaño 2: few-shot. Meter entre tres y diez ejemplos resueltos dentro del propio prompt (glosar: few-shot, “con pocos ejemplos”; mostrar en el mismo prompt varios pares entrada-salida bien hechos para que el modelo imite el patrón sin entrenar nada). Es el truco más subestimado: para tareas de formato y estilo, diez ejemplos bien elegidos suelen igualar lo que un LoRA de 500 ejemplos consigue. La diferencia es que el few-shot lo cambias en dos minutos y el LoRA en dos días.

Peldaño 3: RAG. Si el problema es que al modelo le falta información, la solución es traérsela en el contexto. Eso es RAG, y el módulo 1 del Curso de RAG argumenta exactamente esta frontera. Regla que conviene tatuarse: si la respuesta correcta cambia con el tiempo, es RAG.

Peldaño 4: fine-tuning. Recién aquí. Cuando el prompt está afinado, el few-shot no da más, el contexto ya trae la información necesaria, y aun así el modelo no se comporta como necesitas — o el prompt necesario es tan largo que te está costando una fortuna en tokens.

Peldaño 5: continued pretraining. Seguir el pre-entrenamiento (glosar: entrenar el modelo con texto crudo del dominio, sin pares pregunta-respuesta, para que absorba vocabulario y estructuras que casi no vio en su entrenamiento original). Se usa para dominios genuinamente ajenos al corpus de internet: notación jurídica de un país específico, transcripciones clínicas con abreviaturas propias, un idioma con poca representación. Requiere miles de millones de tokens y es territorio de equipos con presupuesto. Lo menciono para que sepas que existe y para que no lo confundas con lo que vamos a hacer en este curso.

Ojo: los peldaños no son excluyentes. El sistema en producción más común y más sólido es fine-tune + RAG: un modelo afinado para responder en el formato y el tono de la empresa, alimentado con documentos frescos recuperados en tiempo real. Elegir uno “en vez del” otro es un falso dilema que se repite mucho.

Qué sí aprende un fine-tune

Seis cosas, y vale la pena mirarlas una por una porque son la lista completa de razones legítimas para entrenar.

1. Formato de salida estricto. JSON con un esquema fijo, XML, un CSV con columnas específicas, una plantilla de informe. Un modelo instruct genérico te da el JSON correcto, digamos, el 95% de las veces, y el 5% restante lo envuelve en un “¡Claro! Aquí tienes:” que rompe tu parser. Un fine-tune sobre mil ejemplos lleva ese 95% a más del 99% y elimina el preámbulo. Es probablemente el caso de uso número uno en producción.

2. Estilo y tono. La voz de una marca, el registro formal de un banco, la brevedad de un mensaje de WhatsApp, la estructura de un informe clínico. El estilo es exactamente el tipo de patrón que se absorbe por imitación y que en el prompt requiere párrafos de instrucciones que el modelo igual va olvidando conversación adentro.

3. Una tarea estrecha y repetitiva. Clasificar tickets en 14 categorías. Extraer seis campos de una factura. Decidir si un comentario viola la política. Aquí un modelo de 7B afinado le gana con frecuencia a un modelo frontera con prompt, y cuesta una fracción. La palabra clave es estrecha: mientras más acotado el universo de entradas y salidas, mejor rinde el fine-tuning.

4. Idioma o jerga de dominio. No conocimiento nuevo, sino la forma de hablar de un dominio: cómo se abrevia en una receta médica, cómo se cita una norma chilena, qué significa “cargo con glosa” en el contexto de tu empresa. El modelo ya vio español; lo que no vio es tu español.

5. Recortar el prompt y bajar costo y latencia. Este es el argumento económico y el menos discutido. Si tu system prompt tiene 2.000 tokens de instrucciones y ejemplos, los pagas en cada llamada. Un fine-tune internaliza esas instrucciones y te deja un prompt de 150 tokens. Con volumen alto, ese ahorro solo puede pagar el entrenamiento completo, y además baja la latencia porque hay menos tokens que procesar.

6. Destilación. Glosar: destilación (entrenar un modelo chico usando como ejemplos las respuestas de un modelo grande, para que el chico aprenda a imitarlo en una tarea específica). Usas un modelo frontera para generar 5.000 respuestas de calidad, afinas un 8B con ellas y en esa tarea acotada el 8B se acerca mucho al grande a una fracción del costo por token. Es el camino estándar para bajar el costo de un producto que ya funciona.

Cuidado: la destilación tiene una capa legal, no solo técnica. Varios términos de servicio de modelos comerciales prohíben explícitamente usar sus salidas para entrenar modelos competidores. Antes de destilar, lee los términos del proveedor que vas a usar como profesor. Es un detalle aburrido que ha costado contratos.

Qué NO aprende un fine-tune

Una sola cosa, pero es la que la mayoría intenta: conocimiento factual, y menos aún conocimiento que cambia.

La razón es estructural. Un fine-tune con LoRA toca del orden del 0.1% al 1% de los parámetros del modelo, durante dos o tres pasadas sobre unos pocos miles de ejemplos. El conocimiento del modelo se formó con billones de tokens y todos los parámetros ajustándose. Pretender inyectar el catálogo de productos por esa vía es empujar un camión con el meñique: algo se mueve, pero no lo que quieres y no de forma confiable.

Y hay un efecto peor que “no aprende”: aprende a medias. El modelo capta que ese tipo de pregunta se responde con ese tipo de respuesta, adquiere confianza en el formato, y rellena los datos con lo que le suena. El resultado es un modelo que alucina con más seguridad que antes, porque ahora el formato de la mentira es impecable. Suena a factura real, tiene el número de póliza en el lugar correcto, y el número es inventado.

Necesidad real	Herramienta correcta	Por qué
El modelo no sabe el precio de hoy	RAG	El dato cambia; el peso entrenado no
Devuelve JSON casi siempre bien	Fine-tuning	Es formato, no información
Necesita el manual interno de 400 páginas	RAG	No cabe en el peso, sí en el índice
Escribe demasiado formal para la marca	Fine-tuning (o prompt)	Es estilo puro
Falla en 3 de 20 casos raros	Few-shot con esos 3 casos	Más rápido y reversible
Prompt de 2.000 tokens × 1M llamadas	Fine-tuning	Ahorro de tokens directo
Clasificar en 14 categorías fijas	Fine-tuning de un modelo chico	Tarea estrecha, gana en costo
Debe citar la fuente de cada afirmación	RAG	El fine-tune no tiene qué citar
Jerga y abreviaturas del rubro	Fine-tuning	Es forma de hablar, no dato
Escribir en un idioma con poco corpus	Continued pretraining	Falta base, no comportamiento

La cuenta antes de tocar una GPU

Aquí está la parte que casi nunca se hace y que decide el proyecto. El costo de un fine-tuning no es el arriendo de la GPU: el arriendo de la GPU suele ser el ítem más barato de los cuatro.

        DÓNDE SE VA EL PRESUPUESTO DE UN FINE-TUNE (típico)

 dataset      ████████████████████████████   60%
 evaluación   ████████████                   25%
 mantención   ██████                         10%
 GPU          ██                              5%

 La GPU es lo barato. Los datos son el proyecto.

Costo del dataset. Construir, curar y anonimizar entre 500 y 3.000 ejemplos de calidad. Si es trabajo de un experto de dominio, cuenta entre 2 y 5 minutos por ejemplo revisado. Mil ejemplos son del orden de 35 a 85 horas-persona. Ese es el número grande.

Costo de entrenamiento. Un QLoRA sobre un 8B con 2.000 ejemplos tarda del orden de una a tres horas en una GPU de 24 GB. A precios de mercado de GPU arrendada, hablamos de unos pocos dólares por corrida. El problema es que nunca es una corrida: son diez o quince entre pruebas de hiperparámetros y datasets corregidos. Aun así, el orden de magnitud sigue siendo decenas de dólares, no miles.

Costo de evaluación. Necesitas un set de prueba, métricas y alguien que lea salidas. Sin esto no sabes si el fine-tune mejoró o empeoró, y “se ve mejor” no es una medición. Es el mismo argumento del módulo de evaluación de RAG, y aplica idéntico aquí.

Costo de mantención. El que nadie presupuesta. El modelo base que afinaste va a quedar obsoleto en seis a doce meses. Cuando salga la versión nueva, tu adaptador no se transfiere: hay que reentrenar. Multiplica el costo del dataset por su reutilización — si el dataset está bien versionado, reentrenar es barato; si vive en la carpeta de descargas de alguien, lo pagas de nuevo entero.

Contra eso, el beneficio. Y el beneficio se calcula, no se intuye:

"""¿Se paga el fine-tune? La cuenta de servilleta, honesta.

Precios de referencia en USD por millón de tokens. Cámbialos por los
de tu proveedor: la estructura de la cuenta es lo que importa.
"""

def analisis(
    llamadas_mes: int,
    tokens_prompt_actual: int,     # con el system prompt largo
    tokens_prompt_finetuned: int,  # con las reglas ya internalizadas
    tokens_salida: int,
    precio_in_grande: float,       # USD / 1M tokens de entrada
    precio_out_grande: float,
    precio_in_chico: float,        # el modelo afinado, más barato
    precio_out_chico: float,
    horas_dataset: float,
    costo_hora_persona: float,
    costo_entrenamiento: float,    # GPU x corridas, incluye los reintentos
    meses_vida_util: int = 9,      # antes de que el base quede obsoleto
) -> dict:
    M = 1_000_000

    costo_actual = llamadas_mes * (
        tokens_prompt_actual / M * precio_in_grande
        + tokens_salida / M * precio_out_grande
    )
    costo_nuevo = llamadas_mes * (
        tokens_prompt_finetuned / M * precio_in_chico
        + tokens_salida / M * precio_out_chico
    )
    ahorro_mensual = costo_actual - costo_nuevo

    # Inversión: el dataset es el ítem dominante, no la GPU.
    inversion = horas_dataset * costo_hora_persona + costo_entrenamiento

    if ahorro_mensual <= 0:
        return {"veredicto": "NO: el fine-tune no ahorra nada"}

    meses_payback = inversion / ahorro_mensual
    return {
        "costo_actual_mes": round(costo_actual, 2),
        "costo_finetuned_mes": round(costo_nuevo, 2),
        "ahorro_mensual": round(ahorro_mensual, 2),
        "inversion_inicial": round(inversion, 2),
        "meses_para_recuperar": round(meses_payback, 1),
        "veredicto": (
            "SÍ, se paga solo" if meses_payback < meses_vida_util
            else "NO por costo: justifícalo por calidad o latencia"
        ),
    }


if __name__ == "__main__":
    # Caso realista: clasificador de tickets con prompt largo.
    print(analisis(
        llamadas_mes=300_000,
        tokens_prompt_actual=2_000,   # instrucciones + 8 ejemplos few-shot
        tokens_prompt_finetuned=180,  # solo el ticket
        tokens_salida=40,
        precio_in_grande=2.50, precio_out_grande=10.00,
        precio_in_chico=0.20, precio_out_chico=0.60,
        horas_dataset=60, costo_hora_persona=25,
        costo_entrenamiento=120,
    ))
    # El payback sale en semanas: es el escenario donde el
    # fine-tuning es una decisión financiera, no técnica.

Fíjate en el veredicto de la última rama. Si el payback no cierra, el fine-tuning todavía puede valer la pena — pero entonces el argumento tiene que ser calidad o latencia, y hay que decirlo así. Lo que no sirve es justificar por ahorro un proyecto que no ahorra.

Ojo: hay un caso donde la cuenta no aplica y el fine-tuning gana de todas formas: cuando el requisito es correr en tu propia infraestructura. Datos que no pueden salir de la empresa, un modelo que debe funcionar sin internet, una regulación que prohíbe enviar información a terceros. Ahí no compites contra una API: compites contra no tener el producto.

Un protocolo de dos semanas antes de entrenar

Si después de todo esto sigues pensando que corresponde, este es el orden que evita la mayoría de los fine-tunes fallidos:

Escribe el mejor prompt posible. Con reglas explícitas, formato de salida y criterios de negativa. Mídelo.
Agrega few-shot con los casos que fallan. Vuelve a medir. Anota el número.
Construye el set de evaluación primero. 100 a 200 casos con la salida esperada. Este set es el que después va a decidir si el fine-tune sirvió. Hacerlo antes evita la tentación de armarlo a la medida del resultado.
Fija el baseline. El puntaje del mejor prompt sobre ese set. Sin baseline, cualquier resultado del fine-tune parece bueno.
Estima el dataset. Si con 300 ejemplos bien hechos no se ve movimiento, el problema probablemente no era de comportamiento.
Recién ahí, entrena.

El paso 3 es el que más se salta y el que más duele. Construir el eval después de entrenar es como escribir el examen después de ver las respuestas del alumno.

Errores comunes

Hacer fine-tuning para “meterle conocimiento” al modelo. Es el error fundacional y el más caro. El conocimiento factual entra por contexto, no por gradientes. Peor aún: el fine-tune parcial produce alucinaciones con formato perfecto, que son las más difíciles de detectar.
Saltarse el prompt engineering “porque ya sabemos que no alcanza”. En la mayoría de los casos donde se dijo eso, el prompt tenía cuatro líneas y ningún ejemplo. Subir los dos primeros peldaños cuesta horas; el cuarto cuesta semanas.
Entrenar antes de tener con qué medir. Sin baseline y sin set de evaluación, el veredicto final va a ser “se ve mejor”, que es exactamente lo que dirías si hubiera empeorado en los casos que no probaste.
Presupuestar solo la GPU. El arriendo de la GPU es del orden del 5% del costo real. El dataset es el proyecto. Un plan que dice “arrendamos una A100 por un día” no es un plan, es una línea de un plan.
Olvidar la mantención. El modelo base va a quedar viejo. Si el dataset no está versionado, curado y reproducible, cada actualización del base es un proyecto nuevo completo.
Elegir entre fine-tuning y RAG como si fueran rivales. Resuelven problemas distintos y el sistema serio usa los dos: el fine-tune define cómo responde, el RAG define con qué información.
Destilar sin leer los términos de servicio. Usar las salidas de un modelo comercial para entrenar el tuyo puede estar prohibido por contrato. Es un riesgo legal, no técnico, y no lo resuelve ninguna decisión de arquitectura.

La frase para llevarse

“El fine-tuning cambia cómo habla el modelo, no lo que sabe. Si tu problema empieza con ‘es que no conoce…’, apaga la GPU y anda a buscar el documento.”

Qué viene

Módulo 2: el dataset es el modelo. Si la decisión ya está tomada, entonces todo el resultado del fine-tuning se juega en un archivo JSONL. Vamos a ver cuántos ejemplos hacen falta de verdad — cientos a pocos miles, no decenas de miles, y por qué —, el formato exacto de conversaciones, cómo cosechar ejemplos de producción y curarlos, cómo cuidar la diversidad y el balance de la distribución, anonimización y datos personales, y por qué el split de test se toca una sola vez. Con código para construir y validar el dataset: duplicados, longitudes y balance de clases. Y con el error de fondo que arruina proyectos completos: entrenar sobre un dataset que contiene exactamente el sesgo que querías corregir.

Fine-tuning — Módulo 1: cuándo hacer fine-tuning y cuándo no