Puntos clave
- La secuencia canónica en 2026 es prompt → RAG → fine-tuning → destilación. Se avanza al siguiente escalón solo cuando el anterior se ha agotado de verdad, no cuando aburre.
- RAG es la elección correcta en torno al 80% de las aplicaciones LLM empresariales: permite cambiar el dato sin reentrenar, atribuir la respuesta a un documento y cambiar de modelo base cuando convenga.
- La regla que resuelve el 90% de las dudas: si el modelo no sabe algo, es un problema de RAG. Si el modelo lo sabe pero lo dice mal (tono, formato, estructura), es un problema de fine-tuning.
- El fine-tuning completo casi nunca es la decisión correcta para un equipo de producto. LoRA y QLoRA entrenan un adaptador pequeño: es barato, rápido y reversible.
Context engineering, RAG y fine-tuning son tres formas distintas de adaptar un LLM a tu empresa. El context engineering ajusta lo que entra en el prompt; el RAG (generación aumentada por recuperación) inyecta tu conocimiento en tiempo de consulta; el fine-tuning modifica los pesos del modelo. La decisión se resuelve con una pregunta: si el problema es conocimiento, es RAG; si es comportamiento, es fine-tuning.
Las tres técnicas, definidas sin ambigüedad
Context engineering (ingeniería de contexto). Es el diseño deliberado de todo lo que entra en la ventana de contexto del modelo: prompt de sistema, ejemplos few-shot, andamiaje de razonamiento, esquemas de salida forzados (JSON schema), orden y compresión de la información. No toca el modelo ni los datos; cambia lo que el modelo ve. En 2026 es mucho más potente de lo que la mayoría asume, y es la capa que hace que RAG y fine-tuning funcionen de verdad.
RAG (Retrieval-Augmented Generation, generación aumentada por recuperación). Ante una pregunta, el sistema recupera primero los fragmentos relevantes de tus documentos o bases de datos y se los entrega al modelo como contexto. El modelo responde sobre tu dato real, con posibilidad de citar la fuente. El conocimiento vive en tu infraestructura, no en el modelo.
Fine-tuning (ajuste fino). Se modifican los pesos del modelo entrenándolo con ejemplos propios de entrada y salida deseada. El modelo aprende un comportamiento: un tono, un formato, una taxonomía, un estilo de razonamiento. No aprende hechos actualizables de forma fiable.
Lo que NO es fine-tuning: no es "meterle tus documentos al modelo". Ese es el malentendido más caro que vemos. Entrenar un modelo con tu manual de procedimientos no garantiza que lo recite correctamente, y garantiza que quedará desactualizado en cuanto el manual cambie.
Una analogía útil: el context engineering es explicarle bien la tarea a un profesional. El RAG es darle acceso a la biblioteca y a los expedientes. El fine-tuning es enviarlo a un curso de especialización para que trabaje de otra manera. Nadie manda a alguien a un máster para que se aprenda de memoria el listín telefónico de la empresa.
La comparativa que resuelve la decisión
| Criterio | Context engineering | RAG | Fine-tuning (LoRA) |
|---|---|---|---|
| Resuelve | Formato, instrucciones, razonamiento | Conocimiento actualizado y atribuible | Tono, estilo, estructura consistente |
| Actualizar información | Reescribir el prompt | Actualizar documentos (inmediato) | Requiere reentrenar |
| Citar la fuente | No | Sí, nativamente | No |
| Cambiar de modelo base | Trivial | Trivial | Hay que reentrenar el adaptador |
| Tiempo hasta primer resultado | Horas | 2-6 semanas | 4-10 semanas (incluye datos) |
| Necesita datos etiquetados | No | No | Sí, y es el cuello de botella |
| Riesgo principal | Prompt frágil e inmanejable | Recuperación pobre | Sobreajuste y obsolescencia |
| Reversible | Sí | Sí | Sí con LoRA, no con full fine-tuning |
La tabla se lee de izquierda a derecha: cada columna cuesta significativamente más que la anterior y resuelve un problema distinto, no un problema "mayor". Saltar a fine-tuning porque el RAG no funcionó bien suele significar que el RAG estaba mal montado, no que hiciera falta entrenar.
El árbol de decisión que usamos
Cuatro preguntas, en este orden:
- ¿El modelo tiene la información que necesita? Si no la tiene → RAG. Ninguna cantidad de fine-tuning hace que un modelo conozca de forma fiable los pedidos de tu ERP de esta semana.
- ¿La información cambia con el tiempo? Si cambia → RAG, sin discusión. Un modelo ajustado con datos de marzo sigue creyendo en marzo.
- ¿Necesitas citar la fuente de la respuesta? Si sí → RAG. La atribución es una propiedad arquitectónica de la recuperación, no algo que se pueda entrenar.
- ¿El modelo tiene la información pero la presenta mal de forma sistemática? Si es tono, formato, longitud, estructura o una taxonomía propia con cientos de categorías → ahí sí, fine-tuning con LoRA.
Y una pregunta previa a las cuatro: ¿has agotado el context engineering? En nuestra experiencia, entre un tercio y la mitad de los proyectos que llegan pidiendo "un modelo entrenado con nuestros datos" se resuelven con un prompt de sistema bien construido, ejemplos few-shot representativos y salida forzada por esquema. Es la intervención más barata y la que casi nadie agota antes de escalar.
Datos clave del mercado
- La secuencia canónica que se ha consolidado en 2026 es prompt → RAG → fine-tune → destilar, y RAG es la primera elección correcta en torno al 80% de las aplicaciones LLM empresariales, porque permite cambiar el dato sin reentrenar, atribuir respuestas y cambiar de modelo base libremente (Winder.ai, marco de decisión 2026).
- El fine-tuning completo casi nunca es la decisión correcta para un equipo de producto en 2026. LoRA y QLoRA entrenan un adaptador diminuto en lugar del modelo entero: barato, rápido y reversible.
- El 46% de las organizaciones señala la integración con sistemas existentes como su principal reto, por encima de la elección de modelo o técnica. El cuello de botella rara vez está donde se discute.
Nuestra opinión, sin rodeos: la mayoría de las conversaciones sobre fine-tuning en empresas españolas son conversaciones sobre RAG mal planteadas. Y una parte importante de los proyectos de RAG que "no funcionan" tienen un problema de calidad de recuperación, no de modelo.
El patrón híbrido que gana en producción
La discusión "RAG o fine-tuning" es falsa en los sistemas maduros. El patrón que mejor funciona combina las tres capas:
- Fine-tuning ligero (LoRA) sobre un modelo pequeño para fijar el formato de salida, el tono corporativo o una taxonomía propia. El modelo aprende cómo responder.
- RAG por encima para que responda con el dato actual de la empresa. El modelo obtiene qué responder.
- Context engineering para orquestar ambos: qué se recupera, en qué orden entra, con qué instrucciones y con qué esquema de salida.
El resultado es un modelo más pequeño y barato que uno generalista grande, con la consistencia de formato de un modelo ajustado y la frescura de dato del RAG. Es también el camino natural hacia modelos desplegados on-premise cuando hay requisitos de soberanía del dato.
Casos de uso habituales
Caso 1 — Clasificación con taxonomía propia de 300 categorías.
- Problema: clasificar tickets entrantes según una taxonomía interna que ningún modelo generalista conoce. El prompt con la lista completa era enorme, lento y poco fiable.
- Solución: fine-tuning con LoRA sobre un modelo pequeño usando el histórico de tickets ya clasificados.
- Stack: modelo open-weight + LoRA + dataset del histórico.
- Resultado: clasificación consistente, con prompts cortos y latencia muy inferior. Es el caso de libro donde el fine-tuning gana.
Caso 2 — Asistente sobre documentación técnica que cambia cada mes.
- Problema: dar respuestas correctas sobre manuales y procedimientos que se actualizan continuamente.
- Solución: RAG con base vectorial, metadatos de versión y citación obligatoria de la fuente.
- Stack: base vectorial + reranking + modelo generalista + esquema de salida con citas.
- Resultado: la respuesta se actualiza al actualizar el documento, sin tocar el modelo. Con fine-tuning habría que reentrenar cada mes.
Caso 3 — Redacción de informes con formato corporativo estricto.
- Problema: el modelo tiene la información (viene del RAG) pero el formato de salida es inconsistente entre ejecuciones.
- Solución: primero, esquema de salida forzado y ejemplos few-shot. Solo cuando eso se agotó, LoRA sobre 400 informes reales.
- Stack: RAG + salida estructurada + LoRA de estilo.
- Resultado: el problema de formato se resolvió en un 80% con context engineering; el fine-tuning cerró el resto.
Cómo decidir paso a paso
- Escribe el criterio de éxito antes de elegir técnica. "Que responda bien" no es un criterio. "Que acierte la categoría en el 92% de los tickets del último trimestre" sí lo es.
- Monta un dataset de evaluación de 30-50 casos reales. Sin él no puedes comparar técnicas: solo puedes tener opiniones sobre cuál te gusta más.
- Agota el context engineering. Prompt de sistema explícito, 3-8 ejemplos few-shot representativos, salida forzada por esquema JSON. Mide contra el dataset.
- Si el problema es conocimiento, monta el RAG y mide la recuperación por separado. Context recall y context precision antes de mirar la calidad de la respuesta final. Si la recuperación falla, el modelo no puede salvarte.
- Solo si persiste un problema de comportamiento, plantea LoRA. Necesitarás entre varios cientos y unos pocos miles de ejemplos de calidad. Reunir esos datos es el 70% del esfuerzo real del proyecto.
- Evalúa el híbrido. Modelo pequeño ajustado + RAG suele batir en coste y latencia a un generalista grande, con calidad equivalente.
- Documenta la decisión y su criterio de reversión. Qué tendría que pasar para volver atrás. Los proyectos de IA que no definen esto acaban arrastrando arquitecturas que ya nadie defiende.
Errores comunes (y cómo evitarlos)
Error: hacer fine-tuning para "meterle nuestros documentos al modelo". → La realidad: el fine-tuning enseña comportamiento, no hechos consultables. Para conocimiento, RAG. Este malentendido es responsable de la mayoría de proyectos de IA fallidos que revisamos.
Error: saltar a fine-tuning porque el RAG "no funciona". → La realidad: en la práctica totalidad de los casos, el RAG falla en la recuperación: chunking mal dimensionado, ausencia de reranking, metadatos pobres. Mide la recuperación antes de culpar al modelo.
Error: full fine-tuning en lugar de LoRA. → La realidad: entrenar todos los pesos es lento, caro, irreversible y te ata a esa versión del modelo. LoRA entrena un adaptador pequeño, se cambia en minutos y se descarta sin consecuencias.
Error: empezar por la técnica en vez de por la métrica. → La realidad: sin criterio de éxito medible, cualquier resultado parece bueno en la demo y malo en producción.
Error: subestimar el dataset del fine-tuning. → La realidad: el modelo no es el problema; conseguir ejemplos limpios, consistentes y representativos sí. Un dataset con criterios contradictorios enseña al modelo a ser inconsistente.
Error: ajustar un modelo y no volver a tocarlo nunca. → La realidad: un adaptador entrenado hace un año sobre datos de hace dos años codifica una versión antigua de tu negocio. Necesita revisión periódica, como cualquier activo.
Tiempos y esfuerzo realistas
- Context engineering serio (prompt, ejemplos, esquema de salida, medición): días, no semanas. Es la mejor relación resultado/esfuerzo de las tres.
- RAG en producción: 2-6 semanas según la calidad y el estado de tu documentación. Si los documentos están desordenados o duplicados, ahí se va el plazo, no en la parte técnica.
- Fine-tuning con LoRA: 4-10 semanas, de las cuales el entrenamiento en sí ocupa horas. El resto es construir y depurar el dataset.
- Dónde está el esfuerzo real: en los datos, siempre. En RAG, la calidad documental. En fine-tuning, la calidad del dataset etiquetado. El modelo es la parte fácil.
Métricas que medir desde el día 1: precisión sobre el dataset de evaluación, context recall y context precision si hay RAG, consistencia de formato, latencia p95 y coste por tarea. Y una comparación honesta contra la línea base: qué consigue el prompt bien hecho sin nada más. Si nadie tiene ese número, no se puede justificar ninguna inversión adicional.
Preguntas frecuentes
¿Cuándo conviene hacer fine-tuning en lugar de RAG?
Cuando el modelo ya tiene la información pero la presenta mal de forma sistemática: tono inadecuado, formato inconsistente, o una taxonomía propia con muchas categorías que no cabe cómodamente en el prompt. Si el problema es que el modelo no sabe algo o que ese algo cambia con el tiempo, la respuesta es RAG.
¿Puedo hacer fine-tuning para que el modelo conozca los datos de mi empresa?
No de forma fiable. El fine-tuning enseña comportamiento, no hechos consultables y actualizables. Un modelo ajustado con datos de un mes concreto queda desactualizado y no permite citar la fuente. Para conocimiento empresarial, la técnica correcta es RAG.
¿Qué es LoRA y por qué se usa en lugar de fine-tuning completo?
LoRA (Low-Rank Adaptation) entrena un adaptador pequeño en lugar de modificar todos los pesos del modelo. Es mucho más rápido y barato, es reversible y permite mantener varios adaptadores especializados sobre el mismo modelo base. En 2026, el fine-tuning completo casi nunca compensa para un equipo de producto.
¿Qué es el context engineering exactamente?
Es el diseño deliberado de todo lo que entra en la ventana de contexto: prompt de sistema, ejemplos few-shot, andamiaje de razonamiento, esquemas de salida y orden de la información. Es la capa más barata de las tres y la que más proyectos resuelve por completo antes de necesitar RAG o entrenamiento.
¿Se pueden combinar RAG y fine-tuning?
Sí, y es el patrón que gana en producción: un modelo pequeño ajustado con LoRA para fijar formato y tono, envuelto en RAG para que responda con datos actuales. Sale más barato y más rápido que un modelo generalista grande, con calidad equivalente.
¿Cuántos ejemplos necesito para un fine-tuning útil?
Entre varios cientos y unos pocos miles de ejemplos limpios y consistentes, según la complejidad de la tarea. La cantidad importa menos que la coherencia: un dataset con criterios contradictorios entre ejemplos enseña al modelo a ser inconsistente.
¿El fine-tuning reduce las alucinaciones?
No de forma fiable, y a veces las empeora: un modelo ajustado responde con más seguridad sobre el dominio en el que se entrenó, incluso cuando no tiene el dato. Las alucinaciones sobre hechos se reducen con RAG y citación de fuentes, no con entrenamiento.
¿Cuál conviene si tengo requisitos de RGPD o soberanía del dato?
RAG con modelo desplegado en cloud privado o self-hosted es normalmente la vía más limpia: el dato personal se recupera en tiempo de consulta y nunca entra en un proceso de entrenamiento. Si se hace fine-tuning con dato personal, ese dato queda incorporado a los pesos, con las implicaciones de derechos que eso conlleva.
¿No sabes si tu caso necesita RAG, fine-tuning o simplemente un buen prompt?
En Naxia empezamos por la métrica, no por la técnica: definimos el criterio de éxito, montamos el dataset de evaluación y medimos qué consigue cada capa antes de invertir en la siguiente. En muchos proyectos, la respuesta correcta resulta ser la más barata.
Si quieres una recomendación honesta sobre qué necesita tu caso concreto —incluida la posibilidad de que no necesites entrenar nada— habla con nosotros. Sin compromiso y sin powerpoints de 40 páginas.
O si prefieres, explora primero nuestro proceso de implementación.