Fine-tuning o RAG: cuándo usar cada uno y cuándo combinarlos

Publicado: 2026-05-11 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Fine-tuning vs RAG: cuándo ajustar un modelo, cuándo usar RAG y cuándo combinarlos, según coste, datos necesarios, actualización, trazabilidad y riesgos.

Elegir entre fine-tuning y RAG depende de qué falla. Usa RAG cuando el modelo tiene que responder con información de tu empresa que cambia, que debe citarse o que depende de los permisos de cada usuario. Usa fine-tuning cuando lo que falla no es el conocimiento sino el comportamiento: un formato, un tono, un criterio de clasificación o el uso de herramientas que no consigues con instrucciones y ejemplos. Combínalos cuando necesitas ambas cosas: RAG aporta los datos vigentes y el ajuste enseña al modelo a usarlos de una manera concreta.

En la mayoría de proyectos empresariales el orden es este: primero una evaluación con casos reales y unas instrucciones bien escritas; después RAG, si falta información, y solo al final fine-tuning, si la evaluación demuestra un fallo de comportamiento que lo justifique. En 2026 hay además un motivo práctico para planificarlo con cuidado: OpenAI está retirando su plataforma de fine-tuning en autoservicio y desde el 6 de enero de 2027 no aceptará trabajos nuevos.

Qué es el fine-tuning y qué es RAG

Fine-tuning: cambiar el comportamiento del modelo

El fine-tuning, o ajuste fino, entrena un modelo existente con ejemplos de tu tarea y modifica sus pesos en lugar de añadir ejemplos a cada prompt. La documentación de Microsoft Foundry cita entre sus usos mejorar la precisión en una tarea, fijar tono, formato o estructura, mejorar el uso de herramientas, acortar los prompts y especializar un modelo más pequeño.

El ajuste supervisado aprende de pares de entrada y respuesta correcta; el de preferencias (DPO), de una respuesta preferida frente a otra, y el de refuerzo, de una función que puntúa las respuestas. Con modelos de pesos abiertos es habitual LoRA, que congela los pesos originales y entrena solo unas matrices pequeñas añadidas, sin latencia extra al responder.

RAG: dar al modelo la información en cada consulta

RAG (generación aumentada por recuperación) no toca el modelo. Ante cada pregunta, el sistema busca los fragmentos relevantes en tus documentos o bases de datos y se los entrega al modelo junto con la pregunta. El enfoque se formuló en el trabajo de Lewis et al. (2020), que unió un modelo generativo —memoria paramétrica— con un índice vectorial de documentos —memoria no paramétrica— para abordar dos límites de los modelos que solo guardan conocimiento en sus parámetros: justificar de dónde sale una respuesta y actualizar lo que saben.

Cómo se construye la recuperación —troceado, embeddings, búsqueda híbrida y permisos— está en cómo funciona un sistema RAG y en qué es una base de datos vectorial.

Tabla comparativa: fine-tuning vs RAG

Estos son los criterios que deciden la mayoría de proyectos. Los precios de desarrollo proceden de nuestro informe de precios 2026.

Un matiz: en coste por consulta y latencia, el ajuste puede salir ganando si permite prompts más cortos o un modelo más pequeño, mientras que RAG añade una búsqueda y alarga el contexto.

Cuándo usar RAG

• La información cambia: precios, catálogos, políticas, procedimientos o estado de pedidos.
• Las respuestas deben citar su fuente para que alguien pueda comprobarlas.
• Cada usuario solo puede ver una parte de la información.
• La documentación es amplia y heterogénea.
• Necesitas poder borrar un dato y que desaparezca de las respuestas.

El fine-tuning no es una buena vía para enseñar hechos. Ovadia et al. (2023) compararon ambos enfoques para incorporar conocimiento: RAG superó al ajuste no supervisado con información ya vista y con información nueva, y a los modelos les costó aprender hechos nuevos con ese ajuste. Microsoft lo resume en su documentación: el fine-tuning no sustituye a la recuperación cuando se necesita información actual.

Antes de montar RAG, comprueba si hace falta. Anthropic indica que, si la base de conocimiento ocupa menos de unos 200.000 tokens, unas 500 páginas, se puede incluir entera en el prompt y usar la caché de prompts para que sea más rápido y barato.

Cuándo compensa el fine-tuning

• Formato estricto y estable, como extraer siempre los mismos campos de un tipo de documento o generar una estructura que consume otro sistema.
• Clasificación con categorías propias, con ejemplos etiquetados por personas que conocen bien el criterio.
• Tono o estilo que las instrucciones no consiguen mantener de forma consistente.
• Uso de herramientas: elegir la función correcta y rellenar bien sus argumentos.
• Coste o latencia: especializar un modelo más pequeño para una tarea de mucho volumen, a menudo con ejemplos generados por un modelo mayor, lo que se conoce como destilación.

La guía de optimización de modelos de OpenAI propone el mismo orden: escribir las evaluaciones antes que los prompts, iterar con instrucciones y ejemplos —que pueden bastar— y ajustar después. Su guía de ajuste supervisado fija un mínimo de 10 ejemplos, recomienda empezar con unos 50 bien preparados y reservar datos de control para comparar con el modelo original.

Qué cambia en 2026 con OpenAI

Según su página de retiradas, desde el 7 de mayo de 2026 el fine-tuning de OpenAI no está disponible para organizaciones que no lo hubieran usado antes; desde el 2 de julio, solo crean trabajos las que hayan usado un modelo ajustado en los últimos 60 días, y desde el 6 de enero de 2027, ninguna podrá crear trabajos nuevos. Los modelos ya ajustados funcionan hasta que se retira su modelo base.

Hay alternativas: Microsoft Foundry ofrece ajuste gestionado de modelos de OpenAI y abiertos, Amazon Bedrock permite ajuste supervisado, por refuerzo y destilación, y los modelos de pesos abiertos se ajustan en infraestructura propia. En todos los casos, el ajuste queda ligado a un modelo base: cuando se retira, hay que entrenar y evaluar de nuevo.

Cuándo combinar fine-tuning y RAG

La combinación tiene sentido cuando necesitas información vigente y un comportamiento que RAG no consigue por sí solo. Microsoft cita entre los usos del ajuste enseñar al modelo a priorizar el contexto recuperado relevante. Hay tres patrones habituales:

• RAG para los datos, ajuste para el formato: el sistema recupera las condiciones vigentes y un modelo ajustado redacta siempre con la estructura que exige el proceso.
• Ajuste para enrutar: un modelo pequeño ajustado clasifica la consulta y decide qué índice o herramienta usar; RAG se encarga de responder.
• Ajuste para usar mejor el contexto: se entrena con ejemplos que mezclan fragmentos relevantes y no relevantes para que el modelo aprenda a apoyarse en los correctos.

La regla de diseño es mantener los datos sensibles y cambiantes en la capa de RAG, donde se pueden filtrar por permisos, actualizar y borrar, y reservar el ajuste para patrones estables que no contengan información confidencial.

Riesgos de cada enfoque

Riesgos del fine-tuning

• Envenenamiento de datos. OWASP incluye el ajuste fino entre las fases expuestas en envenenamiento de datos y modelos (LLM04:2025) y recomienda controlar el origen de los datos, versionarlos y hacer pruebas adversarias.
• Datos personales en los pesos. Lo aprendido no se borra como un documento; el Comité Europeo de Protección de Datos, en su dictamen 28/2024, solo considera anónimo un modelo entrenado con datos personales si es muy improbable identificar a las personas o extraer sus datos.
• Sobreajuste y regresiones. El modelo puede empeorar fuera de los casos entrenados; Microsoft recomienda separar datos de entrenamiento, validación y prueba final.
• Dependencia del modelo base. El ajuste no se traslada a otro modelo y hay que rehacerlo cuando el original se retira.

Riesgos de RAG

• Recuperación pobre. Si la búsqueda no encuentra el fragmento correcto, el modelo responde mal o rellena el hueco con algo plausible.
• Índices sin permisos. OWASP describe en debilidades de vectores y embeddings (LLM08:2025) cómo un índice compartido sin control de acceso filtra información entre grupos de usuarios.
• Inyección indirecta. Un documento indexado puede contener instrucciones ocultas, así que se trata como dato y nunca como orden; lo explicamos en seguridad y privacidad en proyectos de IA.

Cómo decidir: cinco preguntas

1. ¿Qué falla exactamente? Clasifica los errores de la evaluación: falta información, está desactualizada, el formato es incorrecto, el tono no encaja o el criterio no es el tuyo.
2. ¿Con qué frecuencia cambia la información? Si cambia cada semana, va por RAG.
3. ¿Hay que citar fuentes o respetar permisos? Entonces la información va por RAG, aunque luego se ajuste el formato.
4. ¿Tienes ejemplos correctos y revisados? Sin ellos no hay ajuste que funcione, y reunirlos suele costar más que el propio entrenamiento.
5. ¿Quién mantendrá el modelo ajustado? Cada cambio de criterio o retirada del modelo base exige reentrenar y volver a evaluar.

Para preparar la evaluación, mira testing de sistemas de IA; para descartar que el problema sea el modelo elegido, cómo elegir GPT, Claude o Gemini.

Ejemplos de decisión

Los escenarios siguientes son hipotéticos e ilustrativos, no casos de clientes.

• Catálogo que cambia cada mes: RAG. Un distribuidor responde dudas técnicas sobre miles de referencias. El índice se actualiza al cambiar cada ficha, las respuestas citan la referencia y los precios se consultan en el ERP. Un modelo ajustado con el catálogo quedaría desfasado en la siguiente actualización.
• Extracción de partes de trabajo: quizá fine-tuning. Una empresa de mantenimiento extrae siempre los mismos campos de partes parecidos. Primero prueba un modelo general con instrucciones y ejemplos; si la evaluación sigue fallando en ciertos campos y hay cientos de partes revisados, ajustar un modelo pequeño puede mejorar la precisión y bajar el coste por documento.
• Reclamaciones con política vigente y estilo propio: combinación. La política de devoluciones va por RAG, para cambiarla y citarla; si las instrucciones no mantienen el estilo, se ajusta el modelo con respuestas aprobadas y sin datos personales.

Cuánto cuesta cada opción

Rangos de desarrollo de nuestro informe de precios de software e IA en España 2026:

• Chatbot o asistente con RAG: 10.000-25.000 €, en 4-8 semanas, con fuentes y panel de gestión.
• Copiloto interno con RAG y permisos por rol: 20.000-50.000 €, en 6-12 semanas.
• Automatización acotada de documentos, correos o clasificación con revisión humana: 10.000-20.000 €, en 4-6 semanas.

El informe no publica un rango para el fine-tuning: depende del proveedor, de los ejemplos que haya que preparar y revisar, de los ciclos de entrenamiento y evaluación y de los reentrenos futuros. Los proveedores lo facturan aparte; Amazon Bedrock, por ejemplo, cobra según los tokens procesados —los del corpus por el número de pasadas— más un almacenamiento mensual por modelo. Conviene presupuestarlo cuando una evaluación demuestre que hace falta.

Los costes recurrentes son comunes: uso de modelos por API, desde unos 100 € al mes con poco volumen y 2.000-5.000 € al mes con volumen alto; infraestructura cloud, 50-500 € al mes, y mantenimiento, del 15 al 25 % del coste de desarrollo al año. El servicio completo está en sistemas RAG para empresas.

Errores frecuentes

• Ajustar el modelo para que aprenda la documentación. Queda desfasado en cuanto cambia algo y no puede citar fuentes ni respetar permisos.
• Ajustar sin evaluación previa. Sin una línea base no se sabe si el modelo ajustado mejora al original con buenas instrucciones.
• Culpar al modelo de una mala recuperación. Antes de ajustar, comprueba si el fragmento correcto llegaba al contexto.
• Meter datos personales en los ejemplos cuando el caso no los necesita.
• Olvidar el ciclo de vida. Un modelo ajustado caduca con su modelo base.

Preguntas frecuentes

¿Qué diferencia hay entre fine-tuning y RAG?

El fine-tuning ajusta los pesos de un modelo con ejemplos para que aprenda un comportamiento: formato, tono, clasificación o uso de herramientas. RAG no modifica el modelo: en cada consulta le entrega la información relevante de tus documentos para que responda con ella y pueda citarla.

¿Cuándo es mejor usar RAG?

Cuando la información cambia, debe citarse o depende de los permisos de cada usuario: documentación interna, catálogos, políticas o históricos. Es la opción de partida en la mayoría de proyectos empresariales. Ver cómo funciona un sistema RAG.

¿Cuándo compensa el fine-tuning?

Cuando una evaluación demuestra un fallo de comportamiento —formato, criterio de clasificación, estilo o uso de herramientas— que no se corrige con instrucciones y ejemplos, y hay ejemplos correctos y revisados para entrenar. OpenAI exige un mínimo de 10 y recomienda empezar con unos 50.

¿Se pueden combinar fine-tuning y RAG?

Sí. RAG aporta los datos vigentes y citables, y el ajuste enseña a usarlos con un formato o un criterio concreto. Conviene mantener los datos sensibles y cambiantes en RAG y ajustar solo patrones estables.

¿Sigue siendo posible hacer fine-tuning con OpenAI?

Solo para clientes activos de su plataforma de autoservicio y hasta el 6 de enero de 2027, cuando dejará de aceptar trabajos nuevos. Microsoft Foundry, Amazon Bedrock y los modelos de pesos abiertos siguen permitiendo el ajuste fino.

Lecturas relacionadas

• Sistemas RAG para empresas
• Cómo funciona un sistema RAG
• Qué es una base de datos vectorial
• Seguridad y privacidad en proyectos de IA