La pregunta que muy pocas empresas se hacen antes de gastar en fine-tuning
Cuando un directivo descubre que un modelo de IA puede entrenarse con los datos propios de la empresa para que “hable el idioma del negocio”, la reacción habitual es entusiasmo. El fine-tuning suena a la solución definitiva: un modelo que conoce nuestros productos, nuestra terminología, nuestros procesos.
El problema es que el fine-tuning es costoso, requiere mantenimiento continuo y, en muchos casos, no es la herramienta correcta para el problema que se quiere resolver. Antes de invertir en él, vale la pena entender cuándo tiene sentido real y cuándo hay alternativas más eficientes.
Tres enfoques para adaptar un LLM: cuándo usar cada uno
Prompt engineering
La forma más rápida y barata de adaptar el comportamiento de un LLM. Mediante instrucciones cuidadosamente diseñadas en el prompt — contexto, rol, formato de respuesta, ejemplos (few-shot) — se pueden lograr comportamientos muy específicos sin tocar el modelo. Es el punto de partida correcto para casi todos los casos de uso: si el prompt engineering resuelve el problema, no hay razón para ir más lejos.
RAG (Retrieval-Augmented Generation)
Cuando el modelo necesita acceso a información específica de la empresa — catálogos de producto, documentación técnica, base de conocimiento interna, histórico de casos — RAG proporciona ese contexto en el momento de la consulta sin necesidad de reentrenar el modelo. Es la solución correcta para la mayoría de casos donde el problema es el acceso al conocimiento, no el estilo o el comportamiento del modelo.
Fine-tuning
El fine-tuning tiene sentido cuando ninguno de los dos anteriores es suficiente. Específicamente, cuando se necesita que el modelo adopte un estilo de respuesta muy específico difícil de capturar en prompts, cuando hay que mejorar la eficiencia de inferencia reduciendo el tamaño del prompt de sistema, o cuando el caso de uso requiere un comportamiento que el modelo base no tiene de forma nativa y que necesita reforzarse con miles de ejemplos del estilo correcto.
Cuándo el fine-tuning añade valor real
Clasificadores y extractores especializados
Para tareas muy específicas como clasificar documentos en categorías propias del negocio, extraer entidades definidas internamente o detectar patrones en texto que no aparecen en el lenguaje general, el fine-tuning de un modelo pequeño supera en eficiencia (velocidad, coste, precisión) a los modelos grandes de propósito general. El fine-tuning de modelos de clasificación sobre datos propios etiquetados es el caso de uso con mayor ROI demostrado.
Modelos con estilo de comunicación muy definido
Si la empresa tiene un tono de comunicación muy particular — técnico, formal, muy conciso, con terminología propia — y necesita que el modelo reproduzca ese estilo de forma consistente, el fine-tuning con ejemplos del estilo correcto puede lograr resultados que el prompt engineering no alcanza de forma estable.
Reducción de costes a escala
Para aplicaciones con millones de llamadas diarias, el fine-tuning de un modelo pequeño para hacer una tarea específica puede ser mucho más económico que usar un modelo grande de propósito general con prompts largos. Esto requiere análisis de coste a escala, no es relevante para volúmenes bajos.
Coste, datos y mantenimiento: la parte que nadie menciona
El fine-tuning requiere datos etiquetados de calidad (típicamente entre cientos y miles de ejemplos bien anotados para LLMs, más para modelos de visión o clasificación), tiempo de GPU para el entrenamiento (que tiene coste directo), evaluación rigurosa del modelo resultante y reentrenamiento periódico cuando el dominio evoluciona.
Un modelo fine-tuned no es un activo estático: necesita mantenimiento. Si el catálogo de productos cambia, si la terminología evoluciona, si los casos de uso del modelo se amplían, el modelo necesita reentrenarse. Sin un pipeline de MLOps que soporte este ciclo, el modelo se deteriora con el tiempo.
Preguntas frecuentes
¿Cuántos ejemplos de entrenamiento necesito para un fine-tuning de LLM?
Para LLMs como GPT-4o mini o Llama 3, el fine-tuning supervisado puede mostrar mejoras con tan solo cien a quinientos pares de ejemplo-respuesta de alta calidad para tareas muy específicas. Para lograr consistencia robusta en tareas complejas o con mucha variabilidad, se necesitan varios miles. La calidad de los ejemplos importa más que el volumen: ejemplos bien anotados son más valiosos que miles de ejemplos mediocres.
¿Fine-tuning de un modelo de código abierto o de un modelo de API comercial?
Ambas opciones son viables. El fine-tuning de modelos de API (OpenAI, Anthropic) es más sencillo técnicamente pero los datos de entrenamiento se envían al proveedor. El fine-tuning de modelos de código abierto (Llama, Mistral, Qwen) permite control total sobre los datos y el modelo resultante, pero requiere infraestructura de GPU y más expertise técnico. Para datos sensibles, el fine-tuning local es habitualmente la opción correcta.
¿Cuándo debería elegir RAG en lugar de fine-tuning?
Casi siempre que el problema sea de acceso a conocimiento. Si el modelo necesita saber el precio de un producto, el contenido de un contrato o los pasos de un procedimiento, RAG es más flexible, más actualizable y más explicable que el fine-tuning. El fine-tuning no es una base de datos: la información inyectada en los pesos del modelo es difícil de actualizar y no es recuperable de forma transparente. RAG mantiene el conocimiento fuera del modelo, donde puede gestionarse explícitamente.