Cuándo Fine-Tunear un LLM (y Cuándo No): Guía de Decisión 2026
El fine-tuning rara vez es la primera jugada correcta en 2026. La mayoría de equipos que 'necesitan fine-tuning' realmente necesitan mejores prompts, RAG sobre su corpus o outputs estructurados. Pero el fine-tuning es la jugada correcta para una categoría específica de problemas, y equivocarte cuesta 20K-200K $. Esta es la guía de decisión que usamos en Alher Tech para saber cuándo fine-tuning supera a prompt + RAG, qué cuesta de verdad y cómo ejecutarlo bien.
La Jerarquía: Prueba Esto Primero
- Prompt engineering: Gratis. Itera el system prompt con ejemplos y requisitos de output estructurado. El 80% de 'necesitamos fine-tuning' se resuelve aquí.
- Few-shot prompting: Añade 3-10 ejemplos de input/output al prompt. Barato y efectivo para tono, formato y edge cases.
- Outputs estructurados: JSON schemas, restricciones regex, function calling. Elimina clases enteras de alucinación.
- Prompt caching: Cachea el system prompt estático una vez, paga 10-25x menos por llamada. Cambio de juego en economía de agentes en producción.
- RAG: Recupera contexto relevante de tu corpus y lo inyecta. La herramienta correcta cuando los hechos cambian o al modelo le falta dominio. Ver guía RAG.
- Fine-tuning: Último recurso. La herramienta correcta cuando prompts y RAG no llegan a accuracy aceptable y tienes cientos a miles de ejemplos de calidad.
Cuándo Gana el Fine-Tuning
- Tono, voz o formato estable entre millones de inputs que no se enforce con prompts
- Razonamiento de dominio donde el modelo debe internalizar patrones, no solo recuperar hechos (p. ej., razonamiento legal en jurisdicción específica)
- Despliegue sensible a latencia o coste donde un modelo pequeño fine-tuneado bate a uno grande prompted
- Clasificación o extracción a muy alto volumen donde un modelo pequeño fine-tuneado es más barato que llamar a uno frontier
- Restricciones de seguridad (rechazar ciertos temas) que necesitan enforcement más fuerte que system prompts
Métodos de Fine-Tuning (2026)
- Fine-tuning completo: Actualiza todos los pesos. Calidad máxima, coste máximo. Práctico solo en modelos open-source (Llama 4, Qwen 3, Mistral). 5K-200K $ según tamaño de modelo y datos.
- LoRA (Low-Rank Adaptation): Entrena adapters pequeños, congela el base. 10-100x más barato que full, retiene 90-95% de calidad. El estándar en 2026.
- QLoRA: LoRA sobre base cuantizado a 4 bits. Fine-tunea Llama-70B en una A100 sola. Caída de calidad pequeña; caída de coste enorme.
- API de fine-tuning de OpenAI: Disponible para GPT-4o-mini y GPT-4.1. Fácil de usar, bueno para producción. Bloqueado al ecosistema OpenAI.
- Fine-tuning de Claude: Disponible para clientes selectos en 2026. Alta calidad, selección de modelos limitada. Lo mejor en relaciones empresariales.
- DPO / RLAIF: Direct Preference Optimization o RL desde feedback de IA. Tunea por preferencias humanas con pares. Usado para tono, ayuda, alineación de seguridad.
Realidad de Costes (2026)
| Método | Setup | Coste por run | Mejor para |
|---|
| Prompt engineering + RAG | Horas a días | 0 $ | Primer intento, casi siempre suficiente |
| Fine-tuning OpenAI (GPT-4o-mini) | 5K – 30K $ datos | 50 – 1.000 $ | Tareas de producción a escala |
| LoRA en Llama 4 / Qwen 3 | 10K – 60K $ datos | 200 – 5.000 $ | Autohospedaje, dominio custom |
| Full fine-tune de modelo 7-13B | 30K – 150K $ | 2.000 – 20.000 $ | Dominios nicho, alto volumen |
| Full fine-tune de modelo 70B+ | 80K – 300K $ | 15.000 – 100.000 $ | Rara vez merece la pena vs frontier prompted |
El coste de setup lo domina la preparación de datos: recolectar, limpiar y etiquetar ejemplos. Suele ser 60-80% del total.
El Listón de los Datos
La calidad del fine-tuning está acotada por la calidad de datos. La realidad 2026:
- Mínimo: 200-500 ejemplos de calidad para tono/formato
- Recomendado: 1.000-5.000 para razonamiento o dominio
- Retornos decrecientes pasando ~10.000 en la mayoría de LoRA
- 100 ejemplos cherry-picked suelen ganar a 5.000 mediocres
- Validation set: 10-15% apartado para medir overfitting
- Eval set: medición separada de calidad real, no solo held-out de entreno
Gasta 60-80% del tiempo del proyecto en calidad de datos. Los modelos son commodity; los datos son el foso.
Errores Comunes
- Fine-tunear antes de agotar prompt + RAG. La forma más cara de aprender que prompts habrían funcionado.
- Mal etiquetado. Si tus labels de entreno son inconsistentes, el modelo aprende la inconsistencia.
- Sin baseline. No sabes si el fine-tuning mejoró nada si no mediste el accuracy previo.
- Overfitting en datasets pequeños. Usa early stopping y regularización. Valida continuamente.
- Fine-tunear una vez y nunca más. Los modelos derivan, los datos derivan, el mundo deriva. Construye pipeline de re-entreno desde el día uno.
- Elegir mal el modelo base. Fine-tunear Llama 4 70B para un caso donde Haiku 4.5 valía es presupuesto perdido.
- Mezclar datos de fine-tuning con eval. La contaminación invalida tus métricas.
Fine-Tuning Es la Última Herramienta, No la Primera
Los equipos que tienen éxito con fine-tuning en 2026 prueban exhaustivamente prompt engineering + RAG + outputs estructurados primero. Los que fallan saltan al fine-tuning pronto y descubren que no resolvía su problema.
Trata el fine-tuning como ingeniería seria: pipeline de datos, suite de eval, control de versiones, monitorización. Si no te comprometes a todo eso, el prompt engineering es mejor opción.
Preguntas frecuentes
¿Fine-tuneo Claude o GPT?
Si puedes usar la API de OpenAI, es el camino más fácil. El fine-tuning de Claude existe para enterprise pero es limitado. LoRA open-source en Llama o Qwen da más control pero requiere inferencia autohospedada.
¿Cuánto tarda un fine-tune?
Prep de datos: 2-8 semanas. Run de entreno: horas a días. Eval e iteración: 1-3 semanas. Deploy en producción y monitorización: 2-4 semanas. Total: 6-16 semanas en un fine-tune serio.
¿Reduce el fine-tuning las alucinaciones?
A veces. En tono y formato, sí. En alucinación factual, RAG es la respuesta, no fine-tuning. Fine-tunear sobre hechos que cambian es pesadilla de mantenimiento.
¿RAG es siempre mejor que fine-tuning?
A menudo, pero no siempre. RAG es mejor para hechos. Fine-tuning es mejor para patrones de razonamiento, tono y formato. La respuesta seria: se componen. Fine-tune para comportamiento, RAG para hechos.
¿Cada cuánto re-fine-tuneo?
Trimestral en sistemas de producción donde los datos derivan. Anual si el dominio es estable. Construye el pipeline una vez y re-correrlo es barato.
Guías relacionadas