Fine-tuning: cuando los prompts no alcanzan

Módulo: 13. Práctica profesional | Tiempo: ~35 min de teoría + 20 min de práctica

Imagina que contrataste a un empleado inteligente y versátil. Para la mayoría de las tareas basta con darle instrucciones: las resuelve. Para las tareas complejas, le das una carpeta con documentos: que lea y responda. Pero a veces la tarea es tan específica que la única salida es mandarlo a un curso de especialización de tres meses. El fine-tuning (reentrenar un modelo con datos específicos) es justo esa "especialización". Caro y lento, pero después la persona trabaja en piloto automático en ese tema. En esta lección vemos cuándo de verdad hace falta este camino y cuándo es tirar el dinero.

Lo esencial

La mayoría de los desarrolladores piensa de inmediato en el fine-tuning cuando la IA "no entiende" la tarea. Es un error. En la mayoría de los casos el problema se resuelve con un mejor prompt o agregando los documentos necesarios. El fine-tuning es la herramienta de último nivel: potente, cara y necesaria solo en situaciones específicas.

Esta lección te da un árbol de decisión claro: qué elegir y cuándo.

Conceptos clave

• Tres niveles para ajustar una IA: de lo simple a lo caro
• Prompt engineering (el arte de escribir solicitudes efectivas a la IA): cuándo alcanza
• RAG (Retrieval-Augmented Generation, generación con búsqueda: agregar datos externos a la solicitud): cuándo necesitas documentos
• Fine-tuning: cuándo necesitas especializar el modelo
• Árbol de decisión: qué elegir para tu tarea
• El costo de cada nivel: órdenes de magnitud

Teoría

Tres niveles para ajustar una IA

🎨 Imagínalo así: tres formas de trabajar con un empleado nuevo.

Nivel 1: darle instrucciones. Le dices: "Escribe los posts con este tono, aquí hay ejemplos, sigue estas reglas". La mayoría de los empleados lo logra. Gratis, al instante.

Nivel 2: darle un manual de consulta. El empleado no conoce toda la documentación de la empresa, pero le das acceso al archivo: "Antes de responderle al cliente, busca la sección que corresponde y úsala". Requiere configuración y cuesta dinero, pero los datos viven aparte.

Nivel 3: mandarlo a un curso de especialización. Tres meses estudiando solo lo específico de tu negocio. Después se lo sabe todo de memoria y trabaja rápido. Caro y lento, pero a veces es la única salida.

El prompt engineering, el RAG y el fine-tuning son exactamente estos tres niveles.

Nivel 1: Prompt Engineering, cuando alcanza

Qué es: escribir prompts de sistema detallados, ejemplos y la estructura de la respuesta directamente en la solicitud al modelo.

Cuándo basta:

• La mayoría de las tareas de negocio
• Necesitas un estilo de texto determinado
• Análisis de documentos, traducciones, código a partir de una plantilla
• Clasificación, resúmenes, preguntas y respuestas

Ventajas:

• Costo: solo el tiempo de escribir el prompt (más el precio normal de la API)
• Se cambia al instante: editas el texto y listo
• No hay que reentrenar el modelo
• Flexible: tareas distintas, prompts distintos

Limitaciones:

• Si la tarea requiere conocimiento que el modelo base no tiene
• Si el estilo es tan específico que no se puede describir con palabras
• Si son miles de tareas iguales y los tokens del prompt se vuelven mucho dinero

Ejemplos de tareas donde basta el prompt:

• Escribir posts con el estilo de una marca concreta (describes el estilo + das 3 ejemplos)
• Analizar un contrato con una checklist (la checklist va en el prompt)
• Traducir respetando la terminología (los términos van en el prompt)
• Generar código a partir de una plantilla (la plantilla va en el prompt)

🎨 Imagínalo así: la junta antes del turno. El gerente le dice al empleado: "Estas son las reglas, estos son ejemplos de cómo lo hicimos antes, hazlo así". Para la mayoría de las tareas estándar es suficiente. Si el empleado es listo, lo resuelve.

Regla: empieza siempre por el prompt. Agrega complejidad solo si el prompt no alcanza.

Nivel 2: RAG, cuando el conocimiento es viejo o demasiado grande

Qué es: antes de responder, la IA busca por su cuenta en tu base de conocimiento los fragmentos de texto relevantes y los agrega al contexto de la solicitud.

Cómo funciona por dentro (sin matemáticas):

Pregunta del usuario
       ↓
Búsqueda en una vectorDB (base de datos vectorial: un almacén de textos
en forma de vectores numéricos, donde se busca lo parecido)
       ↓
Se encuentran los 3 documentos más relevantes
       ↓
Claude recibe: la pregunta + los fragmentos encontrados, y responde
       ↓
Respuesta con referencias a las fuentes

Cuándo necesitas RAG:

• Los datos cambian seguido (precios, leyes, políticas internas de la empresa)
• Una base grande de documentos que no cabe en un solo prompt
• Conocimiento específico de la industria que el modelo base no tiene
• Hay que dar referencias a fuentes concretas
• Datos confidenciales que no quieres duplicar en el prompt

Herramientas para RAG:

• Gemini Notebook (antes NotebookLM, renombrado en julio de 2026) de Google: tiene versión gratuita, subes documentos y haces preguntas
• LlamaIndex: biblioteca de Python para construir sistemas RAG
• LangChain: un framework popular (un esqueleto listo para desarrollar) para aplicaciones con LLM
• Anthropic Claude con carga de documentos: una función integrada en Claude.ai

Costo del RAG: depende de la herramienta y del volumen de datos: desde cero en los servicios listos para usar hasta gastos regulares en vectorDB y cómputo (capacidad de procesamiento)

Ejemplos donde el RAG funciona muy bien:

• Un bot corporativo sobre documentos y políticas internas
• Una base jurídica de resoluciones judiciales: "encuentra precedentes sobre este tema"
• Protocolos médicos: "¿cuál es el estándar de tratamiento para este diagnóstico?"
• Soporte al cliente sobre un producto: una base de 500 artículos de preguntas frecuentes

🎨 Imagínalo así: un secretario listo con un archivo enorme. Haces una pregunta → el secretario va al archivo, encuentra las carpetas necesarias → te lee en voz alta lo relevante → tú decides. El secretario no se lo sabe todo de memoria, pero sabe dónde buscar.

Nivel 3: Fine-tuning, cuando de verdad hace falta especializar

Qué es: reentrenar el modelo con un conjunto de datos específico. El modelo no solo "recuerda" ejemplos: cambia físicamente los pesos de la red neuronal, es decir, cambian las matemáticas internas del modelo.

Cuándo el fine-tuning de verdad se justifica:

1. Un estilo muy específico que no se puede describir en un prompt. Por ejemplo, el tono de un autor concreto, con miles de matices en la elección de palabras.

2. Una cantidad enorme de tareas iguales. Si tienes 100 000 solicitudes al día del mismo tipo, cada prompt largo con instrucciones cuesta tokens de más. Después del fine-tuning el prompt es más corto y la inferencia (el proceso de generar la respuesta) es más rápida.

3. Datos confidenciales. Entrenaste en tu propio equipo: los datos no salen a ningún lado.

4. Terminología o lenguaje específicos. Abreviaturas médicas, fórmulas jurídicas, la jerga profesional de una industria estrecha.

5. Necesitas inferencia rápida con un modelo pequeño. Un modelo pequeño entrenado puede funcionar más rápido y barato que uno grande y universal.

Cuándo NO hace falta el fine-tuning (errores frecuentes):

🎨 Imagínalo así: el fine-tuning es como contratar a alguien y entrenarlo tres meses SOLO en lo específico de tu negocio. Después se lo sabe todo de memoria, trabaja rápido y no hay que explicarle el contexto cada vez. Pero es caro y lento, y si lo específico cambia, hay que volver a entrenarlo.

Cómo funciona el fine-tuning por dentro (sin matemáticas)

Paso 1: el modelo base. Tomas un modelo ya entrenado. Hoy suele ser un modelo abierto (de las familias Llama, Qwen, Gemma, Mistral), según la tarea y el presupuesto. En los proveedores cerrados esta posibilidad se está cerrando.

Paso 2: preparas el dataset (el conjunto de datos de entrenamiento). Pares "pregunta → respuesta correcta" o "texto → clasificación deseada". Para un resultado básico necesitas decenas de ejemplos; para uno bueno, cientos o miles. El número exacto depende de la tarea.

Paso 3: lanzas el entrenamiento. El modelo mira tus ejemplos, compara sus respuestas con las correctas y va ajustando poco a poco sus parámetros internos.

Paso 4: obtienes una nueva versión del modelo. La misma arquitectura, pero "inclinada" hacia tus datos. Funciona mejor en tu tarea y peor en todo lo demás (es normal).

El riesgo principal: el overfitting (sobreajuste: el modelo memorizó los ejemplos pero no aprendió a generalizar):

🎨 Imagínalo así: entrenaste a tu perro a sentarse solo en casa. En la calle no obedece. El modelo memorizó tus ejemplos concretos, pero no aprendió a manejar casos nuevos parecidos. Señal de sobreajuste: con los datos de entrenamiento funciona excelente; con los nuevos, mal.

Cómo evitarlo: divide el dataset en train/test (conjunto de entrenamiento y de prueba) y vigila las métricas (los indicadores numéricos de calidad) en las dos partes.

PEFT y LoRA: reentrenar bien sin gastos enormes

El problema del fine-tuning completo: un modelo de lenguaje grande tiene miles de millones de parámetros (los números dentro de la red neuronal que definen su comportamiento). Cambiarlos todos cuesta recursos de cómputo enormes.

La solución, PEFT (Parameter-Efficient Fine-Tuning, reentrenamiento eficiente con el mínimo de parámetros): no cambiamos todos los parámetros, sino solo una pequeña parte. La calidad muchas veces es casi la misma y el precio es mucho menor.

El método PEFT más popular es LoRA (Low-Rank Adaptation, adaptación de bajo rango):

En lugar de cambiar toda la enorme matriz de parámetros, agregamos una pequeña "capa" encima. Esa capa se entrena con tus datos. El modelo base no se toca.

Resultado:

• La calidad suele acercarse a la del fine-tuning completo
• El costo es muchas veces menor
• Puedes cambiar entre distintos adaptadores LoRA (capas adicionales para tareas distintas) sobre un mismo modelo base

🎨 Imagínalo así: LoRA es como un acento particular al hablar. No le enseñas a la persona a hablar inglés desde cero: le agregas encima ciertos patrones de habla. El acento cambia la forma, sin cambiar el idioma base.

La mayoría de los servicios open source (software de código abierto) de fine-tuning usan LoRA por dentro.

Dónde hacer fine-tuning: comparación de proveedores

Importante a octubre de 2026: los grandes proveedores de modelos cerrados están retirando el fine-tuning de autoservicio. OpenAI se lo notificó a los desarrolladores en mayo de 2026: las organizaciones que no habían reentrenado modelos antes ya no pueden crear trabajos de entrenamiento desde el 7 de mayo de 2026, y los clientes existentes no podrán crear trabajos nuevos a partir del 6 de enero de 2027. Los modelos gpt-3.5-turbo y gpt-4 reentrenados se apagan el 23 de octubre de 2026. Por eso, para un proyecto nuevo, lo más seguro son los modelos abiertos que puedes reentrenar tú mismo o con un proveedor de GPU. Las condiciones de los proveedores cambian: revísalas en sus sitios.

Recomendaciones:

• Si empiezas: primero asegúrate de que el prompt y el RAG no alcanzan. Si de todos modos necesitas reentrenar: un modelo abierto + LoRA en Hugging Face (tiene AutoTrain sin código) u otro servicio donde el fine-tuning esté disponible hoy. Haz un ejemplo de práctica antes de gastar dinero.
• Si la privacidad importa: Hugging Face + tu propio equipo o una GPU rentada (el procesador gráfico que se usa para entrenar redes neuronales): los datos no salen a ningún lado
• Si el presupuesto es limitado: un modelo abierto (Llama, Qwen, Gemma, Mistral) + LoRA en una GPU rentada: buena relación precio/calidad
• Enterprise: platica las soluciones a la medida directo con el proveedor del modelo, si el presupuesto lo permite y no hay otra salida

Árbol de decisión: ¿qué elegir?

Quiero que la IA resuelva mejor mi tarea
│
├── ¿Los datos cambian seguido o el volumen es muy grande?
│   └── SÍ → RAG (base de datos vectorial)
│              (precios, leyes, documentos de la empresa, preguntas frecuentes)
│
├── ¿Los datos son estáticos y pequeños (caben en el prompt)?
│   └── Prueba primero con prompt engineering
│       │
│       └── ¿El prompt no alcanza?
│           │
│           ├── ¿El estilo es demasiado específico para describirlo?
│           │   └── SÍ → Fine-tuning
│           │
│           ├── ¿Terminología o lenguaje específicos?
│           │   └── SÍ → Fine-tuning
│           │
│           ├── ¿Más de 100K solicitudes al día del mismo tipo?
│           │   └── SÍ → Fine-tuning (ahorro en tokens)
│           │
│           └── NINGUNA de las anteriores →
│               Mejora el prompt, agrega más ejemplos
│
├── ¿Los datos son confidenciales (no pueden ir a la nube)?
│   └── SÍ → Fine-tuning en tu propio equipo
│              (Hugging Face + Llama + LoRA)
│
└── ¿Necesitas la máxima velocidad / el mínimo precio por solicitud?
    └── SÍ → Fine-tuning de un modelo pequeño
               (un modelo pequeño entrenado es más rápido que uno grande y universal)

La regla simplificada para el 90% de los casos:

Probaste el prompt → no funciona
       ↓
¿Necesitas datos externos? → RAG
       ↓
Sigue sin funcionar → Fine-tuning

Costo: órdenes de magnitud

Las cifras concretas se vuelven viejas rápido y dependen del proveedor, así que aquí se describen órdenes de magnitud. Los precios vigentes de las API están en la página Lo vigente y en los sitios de los proveedores.

Prompt engineering:

• Costo: el tiempo de escribir un buen prompt (horas)
• Costo de operación: el precio normal de la API

RAG:

• Configuración: desde cero (servicios listos como Gemini Notebook) hasta un gasto notable en desarrollo
• Gastos continuos: vectorDB, cómputo, precio de la API
• Tiempo hasta el resultado: días
• Costo de operación: el precio normal de la API + la vectorDB

Fine-tuning (open source, Hugging Face + GPU):

• Renta de GPU: por hora; el precio depende de la tarjeta gráfica
• Un entrenamiento: cuesta bastante más que un prompt o un RAG, y normalmente hacen falta varias iteraciones
• Inferencia: barata (infraestructura propia) o casi gratis (equipo propio)
• Tiempo hasta el resultado: desde unos días (preparar los datos + entrenar)

Fine-tuning con proveedores cerrados: las condiciones cambian rápido (ver la tabla de arriba); si eres una empresa grande, consulta precio y plazos con el proveedor.

Conclusión para la mayoría: empieza con prompts (lo más barato) → agrega RAG (gastos regulares) → fine-tuning solo cuando el negocio de verdad lo necesite (lo más caro y lento). Cómo calcular si vale la pena te lo enseñan las lecciones Cuánto cuesta un cliente y cuánto deja y Punto de equilibrio y reserva de efectivo.

Cuándo el fine-tuning de verdad se justifica: ejemplos

Un call center con 10,000 llamadas al día:

• Tarea: clasificar automáticamente los temas de las llamadas
• Por qué fine-tuning: volumen enorme → un prompt largo cada vez sale caro; se necesita velocidad; el dataset (las transcripciones de las llamadas) ya existe
• Resultado: un modelo pequeño trabaja rápido, barato y con precisión en esta tarea concreta

Documentación médica:

• Tarea: estructurar los resúmenes de los médicos y llenar campos en el CRM (el sistema de gestión de relaciones con clientes)
• Por qué fine-tuning: abreviaturas médicas específicas que el modelo base no tiene; confidencialidad de los pacientes; la precisión es crítica
• Resultado: un modelo entrenado con miles de resúmenes reales trabaja con bastante más precisión

Un despacho de abogados:

• Tarea: analizar contratos, encontrar redacciones riesgosas
• Por qué fine-tuning: construcciones jurídicas propias del derecho de un país concreto (por ejemplo, el mexicano o el colombiano); matices que no se describen en un prompt; confidencialidad
• Resultado: el modelo "piensa" como un abogado con experiencia en esa jurisdicción (el territorio legal)

Un estudio de videojuegos:

• Tarea: diálogos de NPC (non-player character, personaje no jugable controlado por la computadora) con la voz única de cada personaje
• Por qué fine-tuning: miles de diálogos; cada NPC tiene su propio estilo, imposible de describir en un prompt
• Resultado: los NPC hablan "en personaje" sin un prompt grande todo el tiempo

Ejemplos donde NO hace falta el fine-tuning (aunque pensaban que sí):

• "Quiero que el bot sepa de nuestra empresa" → carga los documentos en un RAG; Gemini Notebook lo resuelve rápido
• "Claude no entiende nuestra terminología" → agrega un glosario (diccionario de términos) al prompt de sistema
• "Quiero que escriba como nuestra marca" → 5-10 ejemplos de textos en el prompt + la descripción del estilo

Si decidiste hacer fine-tuning: checklist básica

Paso 1: prepara el dataset

• Formato de diálogos al estilo de OpenAI: JSONL (un formato de archivo donde cada línea es un objeto JSON); muchas herramientas para modelos abiertos también lo entienden
• Para empezar, decenas de ejemplos; para un buen resultado, cientos o más
• La calidad importa más que la cantidad: si entra basura, sale basura
• Divide en conjuntos train/validation (entrenamiento/validación) (80/20)

Ejemplo de estructura (formato de diálogo):

{"messages": [
  {"role": "system", "content": "Eres el ejecutivo de soporte de la empresa X"},
  {"role": "user", "content": "¿Cómo obtengo un reembolso?"},
  {"role": "assistant", "content": "Para un reembolso, escribe a [email protected]..."}
]}

Paso 2: elige modelo y proveedor

• Si empiezas: un modelo abierto pequeño + LoRA en un servicio con interfaz lista
• Privacidad: Hugging Face + un modelo abierto + LoRA en tu propio equipo

Paso 3: lanza el entrenamiento

• Hugging Face: con AutoTrain, una interfaz sin código para fine-tuning
• GPU propia o rentada: bibliotecas como Unsloth para LoRA (ver la lección Modelos de IA locales)

Paso 4: evalúa el resultado

• Compáralo con el modelo base en el dataset de prueba
• Prueba los casos límite (edge cases, datos de entrada poco comunes)
• Revisa el sobreajuste: ¿funciona bien con datos nuevos?

Paso 5: itera (repite el ciclo de mejoras)

• Agrega más ejemplos si la calidad no alcanza
• Ajusta los hiperparámetros (la configuración del proceso de entrenamiento)
• A veces sale más barato mejorar el dataset que entrenar más tiempo

Práctica

Tarea 1: define qué necesita tu tarea

Toma una tarea real que estés resolviendo ahora con Claude. Recorre el árbol de decisión:

1. Escribe la tarea en una oración
2. Responde las preguntas del árbol de decisión de arriba
3. Define: prompt engineering / RAG / fine-tuning
4. Estima presupuesto y tiempo

Tarea 2: prueba NotebookLM (RAG gratuito)

Si tienes una base de conocimiento (PDF, documentos de Word, páginas web):

1. Abre Gemini Notebook (en notebook.google; antes NotebookLM)
2. Crea un Notebook nuevo (un cuaderno de trabajo)
3. Sube 5-10 documentos de tu empresa o proyecto
4. Haz preguntas y mira cómo el RAG encuentra las respuestas en los documentos
5. Compara la calidad de las respuestas con Claude sin documentos

Resultado: en 20 minutos tendrás un RAG funcionando sin una sola línea de código. Esto te ayuda a entender si necesitas fine-tuning o si el RAG ya resuelve la tarea.

Tarea 3: sigue un ejemplo de práctica de LoRA (tutorial paso a paso)

Si quieres probar el fine-tuning:

1. Abre los materiales de aprendizaje de Hugging Face sobre LoRA y PEFT (huggingface.co/learn y la documentación de la biblioteca peft)
2. Sigue el ejemplo de sentiment classification (clasificación de sentimiento: detectar si un texto es positivo, negativo o neutral) con un modelo abierto pequeño
3. Necesitas: un notebook gratuito como Google Colab o rentar una GPU un par de horas (precios en sus sitios)
4. Tiempo: unas horas, contando la preparación de los datos

Nota: antes esta tarea usaba el fine-tuning de OpenAI, pero OpenAI está retirando el fine-tuning de autoservicio (ver la tabla de proveedores de arriba).

El objetivo de la tarea no es el resultado, sino entender el proceso. Después de esto, la decisión "¿necesito fine-tuning o no?" será informada.

Conclusiones clave

• La mayoría de las tareas se resuelven con un prompt: empieza siempre ahí. Es barato y rápido.
• El RAG es el segundo paso, cuando necesitas documentos externos, datos que se actualizan seguido o bases de conocimiento grandes. Gemini Notebook se puede probar gratis.
• Fine-tuning solo cuando de verdad hace falta: estilo específico, confidencialidad, volúmenes enormes de tareas iguales, lenguaje o terminología específicos.
• LoRA hace más accesible el fine-tuning: calidad cercana al entrenamiento completo con un gasto mucho menor.
• Para la mayoría de quienes trabajan con IA: prompt engineering + RAG es todo lo que necesitarán en los próximos años.
• Árbol de decisión: los datos cambian seguido → RAG. Son estáticos y no se pueden describir con un prompt → fine-tuning. Si no → mejora el prompt.

Siguiente lección

Local AI Agents 2026: nanoClaude, OpenClaw, Hermes, Qwen-Agent

AI Mayak Academia | Técnicas avanzadas