Cuando alguien empieza a usar modelos de lenguaje en serio, tarde o temprano llega a la misma conclusión: el modelo no habla como la empresa, no conoce los procesos internos, no sabe cómo se llaman las cosas aquí. La respuesta instintiva es entrenar al modelo con los datos propios. El fine-tuning parece la solución natural. A veces lo es. Pero con más frecuencia de la que se admite, no lo es.

Entender la diferencia entre ambas situaciones ayuda a tomar mejores decisiones sobre cuándo invertir en personalización y cuándo basta con mejores instrucciones.

La diferencia entre usar un modelo y entrenarlo

Cuando usamos un modelo de lenguaje a través de una interfaz o una API, aprovechamos el conocimiento que ese modelo adquirió durante su entrenamiento original: millones de textos, libros, código, conversaciones. Ese entrenamiento ya terminó. Nosotros simplemente le damos instrucciones —el prompt— para orientar cómo responde.

El fine-tuning es algo distinto: consiste en continuar ese entrenamiento, pero con un conjunto de datos más reducido y específico que nosotros proporcionamos. El modelo ajusta sus parámetros internos para aprender patrones nuevos. No añade información como si fuera un documento que se sube; cambia literalmente cómo procesa y genera texto.

Esta distinción importa porque cada opción tiene costes y límites distintos. Usar un modelo es barato e inmediato. Entrenarlo requiere datos, tiempo y criterio técnico.

Cuándo el prompting no es suficiente

Existe la tentación de creer que el fine-tuning es simplemente una forma más potente de prompt. No lo es. Un prompt bien escrito puede hacer mucho: definir un tono, establecer restricciones, dar ejemplos de cómo responder, proporcionar contexto. Para la mayoría de casos de uso cotidiano, un buen prompt de sistema es suficiente.

El prompting empieza a mostrar sus límites en situaciones concretas:

Cuando el formato de salida tiene una estructura muy específica y no estándar. Si necesitas que el modelo produzca siempre una salida en un esquema propietario que no existe en sus datos de entrenamiento, los ejemplos en el prompt no siempre bastan para lograr consistencia.

Cuando el estilo o la voz son extremadamente particulares. Un tono editorial con características muy marcadas —frases cortas, vocabulario restringido, estructura fija— puede ser difícil de mantener con instrucciones solamente.

Cuando el comportamiento buscado es muy diferente del comportamiento por defecto del modelo. Si el modelo tiende a razonar de una manera y necesitas que razone de otra forma de manera sistemática, un prompt puede corregirlo en casos concretos pero no siempre de forma estable.

Fuera de estos supuestos, el fine-tuning raramente resuelve algo que un prompt mejor no podría resolver.

Qué ocurre durante el fine-tuning

El proceso técnico comienza con un conjunto de datos de entrenamiento: pares de entrada y salida que representan el comportamiento que buscas. El modelo los procesa y ajusta sus pesos internos para que, ante entradas similares, produzca salidas más parecidas a los ejemplos.

No se trata de meter documentos en el modelo. El fine-tuning no es una forma de ampliar su memoria ni de añadir información factual de manera fiable. Si le das documentos internos como datos de entrenamiento, aprenderá el estilo y la estructura de esos documentos, pero no memorizará los hechos con precisión ni los recuperará como una base de datos.

Este es uno de los malentendidos más comunes: usar el fine-tuning para que el modelo sepa cosas específicas. Para eso existe el RAG —recuperación aumentada por generación—, que conecta al modelo con documentos en tiempo real, durante la inferencia, en lugar de modificar el modelo mismo.

El fine-tuning ajusta cómo el modelo piensa y responde. No qué sabe en el sentido factual.

Los requisitos reales de datos

Para un fine-tuning efectivo se necesitan datos de calidad, no solo datos. Esto significa varias cosas:

Ejemplos representativos. Cada par entrada-salida debe ejemplificar exactamente el comportamiento que buscas. Si los ejemplos son inconsistentes —unas veces un estilo, otras otro—, el modelo aprenderá esa inconsistencia.

Volumen suficiente. Depende del caso, pero en general se necesitan cientos de ejemplos para comportamientos simples y miles para comportamientos complejos. Con menos de cien ejemplos, los resultados suelen ser decepcionantes.

Datos limpios. Los errores en los datos de entrenamiento se transfieren al modelo. Un conjunto de datos con un 30% de ejemplos incorrectos produce un modelo que falla con frecuencia.

Preparar un buen conjunto de datos requiere tiempo, criterio humano y revisión cuidadosa. Es, con frecuencia, la parte más costosa de todo el proceso y la que más se subestima antes de empezar.

Alternativas antes de entrenar

Antes de invertir en fine-tuning, hay opciones que merecen agotarse:

Mejorar el prompt del sistema. Un prompt largo, detallado y con ejemplos concretos puede reproducir muchos comportamientos que intuitivamente parecen requerir entrenamiento. Incluir tres o cuatro ejemplos de entrada-salida directamente en el prompt —few-shot prompting— es barato y a menudo suficiente.

RAG para conocimiento específico. Si el problema es que el modelo no conoce los documentos internos, conectarlo con esos documentos mediante recuperación es más flexible, más actualizable y más transparente que el fine-tuning.

Modelos especializados disponibles. Para dominios concretos como medicina, derecho o código, ya existen modelos entrenados sobre corpus específicos. Usar uno de ellos es más sencillo que entrenar el propio.

Cadenas de prompts. Dividir una tarea compleja en pasos y encadenar prompts distintos para cada uno puede dar resultados más controlables que intentar enseñar todo el comportamiento de una vez.

Cuándo sí tiene sentido

Con todas las advertencias anteriores, hay escenarios donde el fine-tuning es la herramienta correcta:

Cuando necesitas que el modelo adopte un estilo editorial muy específico y lo mantenga con consistencia a escala: miles de documentos, sin revisión humana en cada uno. Cuando la tarea tiene un formato de salida estricto que los ejemplos en el prompt no consiguen estabilizar. Cuando la latencia es crítica y un prompt largo —necesario para dar suficiente contexto— ralentiza demasiado las respuestas. Y cuando el volumen de uso es tan alto que el coste de un prompt largo se convierte en un gasto real.

En estos casos, el fine-tuning puede ofrecer un modelo más rápido, más consistente y más económico a largo plazo. Pero la inversión inicial —en datos, en tiempo de entrenamiento, en evaluación— debe justificarse.

La pregunta correcta no es “¿podría mejorar esto con fine-tuning?”, sino “¿no puedo conseguirlo de una forma más barata primero?”. Casi siempre, la respuesta es que sí.