Fine-tuning vs prompting: cuándo entrenar un modelo y cuándo no hace falta

Hay un patrón que se repite una y otra vez en los equipos que trabajan con IA. Alguien propone una mejora. Alguien dice «necesitamos entrenar nuestro propio modelo». Semanas o meses después, con datos preparados, GPUs alquiladas y experimentos ejecutados, el resultado es un modelo que hace más o menos lo que habría hecho un prompt bien escrito. Más caro, más lento de iterar, más difícil de mantener.

Este patrón ya existía en el software empresarial antes de la IA: un equipo encuentra un problema, alguien dice que necesita una solución a medida, y seis meses y cientos de miles de euros después tienen un sistema bello y personalizado que hace exactamente lo que habría hecho un producto estándar bien configurado. La solución a medida a menudo funciona peor. Ahora ese mismo patrón se está repitiendo con el fine-tuning. Spacelift

La secuencia correcta en 2026 es: Prompt → RAG → Fine-tuning → Destilación. Y la honesta es: la mayoría de equipos que preguntan sobre fine-tuning no deberían hacer fine-tuning todavía. Deberían arreglar sus prompts, construir un pipeline de RAG y escribir evaluaciones, en ese orden. Skyvia

Esta guía explica por qué, cuándo esa secuencia tiene excepciones y cómo tomar la decisión correcta sin perder meses en el camino equivocado.

Qué es cada técnica y qué problema resuelve

Antes de comparar, conviene tener claro qué hace cada una.

El prompting es escribir instrucciones que guían al modelo hacia el output que quieres, sin cambiar el modelo en sí. Incluye desde un prompt de sistema sencillo hasta técnicas más elaboradas como chain-of-thought (pedirle que razone paso a paso), few-shot (darle ejemplos del output esperado) o RAG (inyectar contexto relevante recuperado de una base de datos antes de generar la respuesta). El modelo no cambia. Solo cambia lo que le dices.

El fine-tuning modifica los parámetros internos del modelo mediante entrenamiento sobre ejemplos curados. El resultado es un modelo con comportamiento diferente al original: no solo sigue instrucciones distintas, sino que ha aprendido patrones de sus parámetros. Es permanente hasta que se reentrena.

La distinción más importante: RAG mantiene tu sistema veraz hoy. El fine-tuning lo hace consistente mañana. El conocimiento volátil va en recuperación. El comportamiento estable va en fine-tuning. La clave es no forzar una sola herramienta para hacer ambos trabajos. CData Software

El árbol de decisión: cuándo usar cada técnica

La pregunta que hay que hacerse no es «¿necesito fine-tuning?» sino «¿qué está fallando exactamente y por qué?». Las respuestas posibles llevan a decisiones distintas.

El error más caro: usar fine-tuning para inyectar conocimiento

Este es el malentendido más frecuente y el más costoso en tiempo y recursos.

El fine-tuning es para forma, no para hechos. Se usa para moldear comportamiento, estilo, output estructurado y patrones de respuesta, no para inyectar conocimiento que cambia cada semana. Skyvia

Un ejemplo concreto: una empresa quiere que su asistente de IA conozca su catálogo de productos, las políticas internas y los precios actualizados. La tentación es hacer fine-tuning con esos datos. El problema es que cuando el catálogo cambia — y los catálogos cambian — hay que reentrenar. Cada actualización de precio requiere un ciclo de entrenamiento. Es un modelo de mantenimiento inviable.

La solución correcta es RAG: el modelo base se mantiene igual, y la información actualizada se recupera de una base de datos en el momento de la consulta. El conocimiento vive fuera del modelo, se actualiza fácilmente y el modelo lo usa en contexto sin necesidad de reentrenamiento.

En 2023, investigadores de Microsoft demostraron que GPT-4 con el framework MedPrompt superó a Med-PaLM 2, un modelo entrenado específicamente sobre datos médicos, en nueve de nueve benchmarks médicos, por hasta 12 puntos. El framework era solo recuperación dinámica de ejemplos few-shot, razonamiento chain-of-thought y ensemble. Sin mover un solo peso del modelo. El resultado ilustra algo que los datos siguen confirmando: hay una cantidad enorme de rendimiento latente en los prompts que la mayoría de equipos no ha extraído todavía. Plugins for Cowork

Cuándo el fine-tuning sí tiene sentido

Dicho todo lo anterior, hay casos en los que el fine-tuning es la herramienta correcta. Son más específicos de lo que la mayoría asume, pero son reales.

Consistencia de estilo y formato a escala. Si necesitas que el modelo produzca siempre outputs en un formato muy específico — JSON estructurado, respuestas con una longitud exacta, una voz de marca muy particular — y los prompts no lo logran de forma consistente en producción, el fine-tuning resuelve ese problema de raíz. Los casos de uso con mayor ROI en fine-tuning son: cumplimiento de formato de output, consistencia de tono, enrutamiento y clasificación, y estilo de respuesta específico del dominio. Skyvia

Reducción de coste y latencia en producción. El patrón que mejor encaja con la mayoría de flujos de trabajo en producción en 2026 es el tercero: optimizar prompts en un modelo frontier, y destilar a un modelo pequeño con fine-tuning cuando la latencia o el coste lo fuerzan. OpenAI recomienda exactamente esto en su propia guía de selección de modelos: empiezas logrando el objetivo de precisión con el modelo más capaz. Registras cada prompt y completion. Haces fine-tuning de un modelo más pequeño sobre esos registros. El modelo pequeño con fine-tuning a menudo iguala al grande a un 2% del coste. Plugins for Cowork

Comportamientos que el prompting no puede establecer. Hay ciertas capacidades — patrones de razonamiento muy específicos del dominio, estilos conversacionales muy particulares, comportamientos de rechazo calibrados — que los modelos frontier no aprenden bien solo con instrucciones, especialmente cuando el comportamiento deseado se desvía mucho del comportamiento por defecto del modelo.

La secuencia práctica antes de decidir hacer fine-tuning

LoRA y QLoRA: la única forma práctica de hacer fine-tuning en 2026

Si tras seguir la secuencia anterior decides que el fine-tuning es la herramienta correcta, el método importa tanto como la decisión.

El fine-tuning completo de un modelo de 7.000 millones de parámetros requiere modificar todos sus parámetros. Eso significa GPUs de alta gama durante horas o días, costes elevados y un modelo resultante que ocupa tanto almacenamiento como el original. Para la mayoría de casos de uso, es excesivo.

LoRA (Low-Rank Adaptation) y su variante cuantizada QLoRA resuelven ese problema. En lugar de modificar todos los parámetros del modelo, añaden una capa de adaptación ligera — el «adaptador» — que captura los cambios necesarios sin tocar los pesos originales. El fine-tuning con mayor ROI en 2026 es un adaptador LoRA o QLoRA fino sobre un modelo base sólido, combinado con recuperación en lugar de reemplazarla. Skyvia

Las ventajas prácticas son sustanciales: el adaptador ocupa una fracción del espacio del modelo completo, puede intercambiarse con otros adaptadores sobre el mismo modelo base, y si el entrenamiento sale mal es fácil de descartar sin perder el modelo original. Plataformas como Together AI, Fireworks o el propio Bedrock de Amazon permiten hacer fine-tuning con LoRA sin gestionar infraestructura propia.

El coste real que nadie menciona en los tutoriales

La decisión de coste real no está en el cómputo de entrenamiento — está en la curación de datos, la evaluación y la propiedad del ciclo de vida. El impuesto operacional: versioning de adaptadores, planes de rollback, cadencia de reentrenamiento y gestión de deriva del modelo base son costes recurrentes, no trabajo de una sola vez. Cuando un proveedor alojado actualiza su modelo base, tu adaptador puede degradarse silenciosamente. Planifica revalidación trimestral. Skyvia

Esto es lo que los tutoriales de fine-tuning no suelen decir: entrenar el modelo es la parte más sencilla. La parte difícil es decidir qué datos usar, cómo saber si el resultado es mejor que lo anterior y qué hacer cuando el modelo base del proveedor se actualiza y tu adaptador entrenado sobre la versión anterior deja de funcionar igual.

El fine-tuning no elimina las alucinaciones. Si el modelo base alucina en tu dominio, un modelo fine-tuneado sobre datos de ese dominio puede alucinar de forma más convincente porque suena más especializado. Para reducir alucinaciones, la solución es grounding con fuentes verificadas mediante RAG, no entrenamiento adicional.

La conclusión que simplifica la decisión

La mayoría de casos de uso que parecen «requerir» fine-tuning en realidad requieren mejores prompts. Esta frase, de un veterano de IT empresarial reconvertido a IA, resume bien lo que los datos de producción de 2026 confirman repetidamente. Spacelift

El prompting bien ejecutado — con instrucciones estructuradas, ejemplos del output esperado y RAG para el conocimiento dinámico — resuelve la mayoría de los problemas antes de llegar al fine-tuning. El fine-tuning tiene su lugar, pero ese lugar es específico: comportamiento consistente a escala, reducción de coste por destilación, y patrones que los prompts no logran establecer tras haberlos optimizado a fondo.

La secuencia correcta no es «¿prompting o fine-tuning?». Es «prompting primero, RAG si el problema es conocimiento, fine-tuning si el problema es comportamiento y no se resuelve antes». El orden importa porque cada paso es más barato y más rápido de iterar que el siguiente.