RAG vs Fine-Tuning: cuándo usar cada uno (con datos reales)

RAG vs Fine-Tuning: cuándo usar cada uno (con datos reales)

La mayoría de los consejos sobre RAG vs fine-tuning se saltan el único experimento que midió ambos enfoques en la misma tarea. Balaguer et al., en arXiv:2401.08406 (citado 162 veces), pasaron un conjunto de preguntas y respuestas agrícolas por los dos: el fine-tuning aportó más de 6 puntos de precisión, y el RAG sumó otros 5 encima. Su Tabla 18 sitúa a GPT-4 en un 75% en crudo, un 81% con fine-tuning y un 86% con fine-tuning más recuperación. ¿Por qué seguimos diciendo a la mayoría de los equipos que empiecen con RAG? Porque la frescura, las citas y las cuentas de costes que vienen a continuación deciden más proyectos que una diferencia de precisión de 1 punto.

Conclusiones clave

• El RAG es la opción por defecto cuando el conocimiento cambia a menudo o las respuestas deben citar fuentes; el fine-tuning gana en formato consistente y latencia.
• Los costes del fine-tuning llegan por adelantado (entrenamiento); los del RAG llegan por consulta (embeddings más tokens de entrada extra).
• Evidencia publicada sobre la misma tarea: el fine-tuning añadió 6 puntos de precisión, el RAG sumó 5 más encima, y el híbrido superó a ambos por separado.
• Ejecuta los cinco checks (frescura de los datos, ejemplos etiquetados, latencia, citas, capacidad del equipo) antes de escribir una sola línea de código de entrenamiento.

¿Cuándo deberías usar RAG o fine-tuning? (Veredicto rápido)

Elige RAG si tu conocimiento cambia a menudo o tus respuestas deben llevar citas. Elige fine-tuning si necesitas un formato de salida consistente y baja latencia, y tienes cientos de ejemplos etiquetados. Usa ambos cuando un despliegue madure. El RAG edita el contexto que lee el modelo; el fine-tuning edita el modelo en sí. La mayoría de los equipos necesitan lo primero, no lo segundo.

Una línea para quedarte: el RAG cambia lo que el modelo lee; el fine-tuning cambia lo que el modelo es. Elige según cuál de los dos necesite realmente tu tarea.

El glosario de RAG de NVIDIA define con limpieza la parte de recuperación si quieres la versión de libro de texto. Pero las definiciones no eligen tu arquitectura. La evidencia sí, así que empieza por ahí.

¿Qué muestra la evidencia? Una tarea, ambos enfoques, medidos

La única comparación medida sobre la misma tarea que aparece en el top cinco de Google para esta consulta es Balaguer et al. 2024, un estudio de Microsoft Research citado 162 veces. El equipo ejecutó una tarea de QA agrícola con un pipeline RAG, un modelo afinado y un híbrido de los dos, y después pidió a GPT-4 que puntuara las respuestas. En su configuración, el fine-tuning por sí solo superó al RAG por sí solo, y apilar los dos batió a cualquiera de ellos por un margen mayor.

El caso de estudio agrícola (arXiv:2401.08406)

El estudio, enviado en enero de 2024 por Angels Balaguer y 15 coautores, se pregunta qué hace falta para dar a los agricultores información específica de su ubicación. Su pipeline extrae información de PDFs, genera pares de pregunta-respuesta a partir de ellos y evalúa Llama2-13B, GPT-3.5 y GPT-4 con y sin recuperación.

Balaguer et al. reportan un aumento de precisión de más de 6 puntos porcentuales con el fine-tuning, acumulativo con el RAG, que añadió otros 5 puntos encima. El pipeline híbrido superó a cualquiera de los dos enfoques por separado. Su Tabla 18 muestra el orden para GPT-4: 75% sin ayuda, 80% con RAG, 81% con fine-tuning, 86% con fine-tuning más RAG. Fíjate en lo cerca que quedan el 80% y el 81%; la brecha entre RAG solo y fine-tuning solo es de un punto, mientras que el híbrido saca cinco claros a ambos. En un experimento, el modelo afinado tiró de conocimiento de otras geografías para responder preguntas específicas de una región, y elevó la similitud de las respuestas del 47% al 72%.

La evidencia económica

El estudio publicado de Snorkel AI (noviembre de 2022) cubre la parte de costes. En un benchmark de clasificación legal de 100 clases (LEDGAR, 80.000 cláusulas de contratos), un modelo RoBERTa afinado igualó a un GPT-3 afinado siendo 1.400× más pequeño, usando menos del 1% de las etiquetas reales y funcionando al 0,1% del coste de inferencia en producción del modelo GPT-3 afinado, aproximadamente una milésima parte. Coste total de construcción: 1.915 $ con etiquetado programático frente a 7.418 $ con anotación manual más fine-tuning de GPT-3. Una advertencia: eso es clasificación, no QA generativo, así que trata los ratios como orientativos.

Nuestra lectura

Nuestra interpretación: su configuración es el caso más favorable que el fine-tuning va a encontrar nunca, y aun así solo ganó por un punto. Balaguer et al. entrenaron sobre un corpus de PDFs fijo y evaluaron contra ese mismo corpus congelado, así que nada de lo que aprendieron los pesos tuvo ocasión de quedarse obsoleto a mitad del experimento. La mayoría de las bases de conocimiento en producción no se quedan quietas así. Un bot de soporte que responde preguntas sobre la release de la semana pasada se gana de nuevo los 6 puntos en cada ciclo de reentrenamiento, mientras que el índice que alimenta el RAG se actualiza esa misma tarde. Por eso leemos una ventaja de precisión de 1 punto como el input más débil de esta decisión, y la frescura como el más fuerte. Donde la evidencia no generaliza: el resultado de Snorkel es un benchmark de clasificación, y ningún estudio prueba el control de tono o de formato, que sigue siendo el caso más fuerte del fine-tuning.

El fine-tuning es la respuesta correcta menos veces de las que los equipos creen; la mayoría de los proyectos que dicen "afinar" en realidad quieren decir "recuperar".

¿Cómo funciona el RAG y cuándo gana?

El RAG (generación aumentada por recuperación) responde desde documentos que tú controlas en lugar de desde lo que el modelo memorizó durante el entrenamiento. Propuesto por primera vez por Lewis et al. en 2020, se convirtió en la opción por defecto para el trabajo con conocimiento porque el conocimiento vive fuera del modelo: actualiza el índice y todas las respuestas cambian mañana sin reentrenar.

El pipeline tiene cuatro pasos:

1. Ingesta. Parsea tus documentos (PDFs, wikis, tickets) hacia un corpus.
2. Fragmenta y genera embeddings. Divide en fragmentos de unos pocos cientos de tokens y convierte cada uno en un vector con un modelo de embeddings.
3. Recupera. En el momento de la consulta, encuentra los K fragmentos más similares, más coincidencias por palabra clave para cadenas exactas como SKUs y códigos de error.
4. Aumenta y genera. Mete esos fragmentos en el prompt y deja que el LLM responda con las fuentes adjuntas.

El RAG gana en tres ejes: frescura (reindexar en vez de reentrenar), citas (cada respuesta apunta al fragmento del que salió) y control de datos (los datos del cliente nunca entran en un entrenamiento). Si quieres el recorrido completo de construcción, aquí tienes cómo construir una aplicación RAG paso a paso.

Una advertencia sobre la calidad de la recuperación: el pipeline vale lo que vale su mezcla de embeddings y recuperación. Contextual Retrieval de Anthropic midió una tasa de fallo de recuperación top-20 del 5,7% en configuraciones simples, que bajaba al 2,9% con embeddings contextuales más BM25, y al 1,9% al añadir un reranker. Si las consultas de coincidencia exacta siguen fallando, la búsqueda híbrida (BM25 vs vector) es la solución.

¿Cuándo gana el fine-tuning? (¿Y qué es PEFT?)

El fine-tuning gana cuando el problema es cómo responde el modelo, no lo que sabe: formato de salida consistente, tono de marca o un presupuesto de latencia estricto sin ida y vuelta de recuperación. También es la palanca de la economía de modelos pequeños. El resultado de Snorkel de calidad GPT-3 al 0,1% del coste que vimos arriba solo existe porque alguien afinó un modelo pequeño en lugar de servir uno grande.

Fine-tuning completo vs PEFT (LoRA / QLoRA)

El fine-tuning completo actualiza todos los pesos del modelo. Es caro, lento y raro fuera de los grandes laboratorios. Casi todo el mundo despliega PEFT (fine-tuning eficiente en parámetros) en su lugar. LoRA (Hu et al. 2021) congela los pesos base y entrena un pequeño adaptador de rango bajo, normalmente el 0,1-1% del número de parámetros. QLoRA añade cuantización de 4 bits encima, de modo que un modelo de 13B cabe en una GPU de consumo. Un término relacionado que vale la pena conocer: preentrenamiento continuo, donde un modelo sigue preentrenándose sobre un corpus crudo de un dominio (sin supervisión) antes del fine-tuning supervisado sobre ejemplos etiquetados.

Una configuración mínima de LoRA, según la documentación de PEFT de Hugging Face:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Para preparación del dataset, número de épocas y evaluación, mira nuestra guía de fine-tuning paso a paso.

Los riesgos son reales: sobreajuste en datasets pequeños (unos pocos cientos de ejemplos pueden memorizar en vez de aprender), obsolescencia (los pesos congelan tu conocimiento en la fecha de corte del entrenamiento) y nada de atribución de fuentes (un modelo afinado no puede enseñar sus recibos). Si cualquiera de esos tres es un obstáculo, te acabas de convencer a ti mismo de volver al RAG.

RAG vs fine-tuning vs ingeniería de prompts: ¿dónde encajan los demás?

Los tres son una escalera, no rivales. La ingeniería de prompts cambia las instrucciones, el RAG cambia el contexto que lee el modelo y el fine-tuning cambia los pesos. La propia guía de fine-tuning de OpenAI coloca el fine-tuning al final del ciclo: primero evaluaciones, segundo prompts, entrenamiento solo cuando los prompts dejan de bastar. Dos opciones más nuevas completan el kit.

Una confusión que vale la pena nombrar: los servidores MCP y los frameworks de agentes son orquestación, no personalización. Deciden a qué herramientas y fuentes puede llegar el modelo; no cambian cómo responde el modelo. Puedes ejecutar un pipeline RAG dentro de un agente y afinar el modelo que hay debajo, y muchos sistemas en producción hacen ambas cosas. Las guerras del autocompletado ("vs mcp", "vs agentes") son errores de categoría.

¿Es el RAG más barato que el fine-tuning? El modelo de costes real

Respuesta corta: con volúmenes de consulta realistas, sí. La factura del fine-tuning llega por adelantado (datos etiquetados más entrenamiento), mientras que la del RAG llega por consulta (embeddings más tokens de entrada extra). La documentación de fine-tuning de OpenAI cobra el entrenamiento por token, pero las tarifas de tokens son calderilla junto al coste humano de los ejemplos etiquetados. Aquí están las cuentas con precios de lista públicos.

La pregunta del punto de equilibrio: ¿cuántas consultas hasta que el impuesto acumulado por consulta del RAG iguale la inversión del fine-tuning?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

Con 50.000 consultas al mes, eso son más de diez años. Para la mayoría de los productos, la inversión del fine-tuning nunca se recupera solo con ahorro de tokens; afinas por formato y latencia, no para ganar al RAG en coste. Las cuentas cambian pasado el millón de consultas al mes o con contextos recuperados muy grandes. Y observa la asimetría: la factura del fine-tuning se renueva cada vez que la deriva de datos fuerza un reentrenamiento, mientras que el RAG escala linealmente con el volumen por el tamaño del fragmento. Si el gasto por consulta es la preocupación real, empieza por recortar los costes por consulta de LLM; si de verdad vas por la vía del entrenamiento, compara herramientas de fine-tuning antes de firmar el cheque.

Una nota de frescura: a julio de 2026, la documentación de fine-tuning de OpenAI indica que la plataforma alojada se está retirando para nuevos usuarios, y los usuarios existentes mantienen acceso al entrenamiento durante los próximos meses. Es una razón más para que los equipos se inclinen por PEFT en modelos abiertos o por RAG a secas.

5 checks antes de decidir

Ejecuta estos cinco checks de sí o no antes de escribir una sola línea de código de entrenamiento; el patrón de respuestas apunta al RAG, al fine-tuning o al híbrido con más fiabilidad que cualquier benchmark. Responde con honestidad y luego cuenta.

1. ¿El conocimiento cambia más rápido de lo que podrías reentrenar? Sí → RAG. Un reentrenamiento por actualización de documento no es un plan de operaciones.
2. ¿Tienes unos pocos cientos de ejemplos etiquetados? No → RAG o ingeniería de prompts. El fine-tuning con 40 ejemplos memoriza; no aprende.
3. ¿Hay un presupuesto de latencia estricto? ¿Ajustado? → inclinación al fine-tuning. Saltarse la ida y vuelta de recuperación ahorra 50-200 ms.
4. ¿Deben llevar citas o pista de auditoría las respuestas? Sí → RAG. Los modelos afinados no pueden señalar el fragmento de origen.
5. ¿Tiene el equipo capacidad de ML más presupuesto de GPU o API para entrenar? No → RAG. Un índice que puedes reconstruir gana a unos pesos que no puedes reentrenar.

Mayoría de síes en 1, 4 y 5 → RAG. Mayoría de síes en 2 y 3 con un dominio estable → fine-tuning. Respuestas divididas, o un producto maduro con tráfico real → híbrido (siguiente sección). El sentido del checklist es decidir con evidencia, no con la técnica que esté de moda en tu feed este mes.

¿Se pueden usar RAG y fine-tuning juntos?

Sí, y para despliegues maduros el patrón híbrido es la norma, no la excepción. Afina para fluidez de dominio y formato de salida (el cómo), recupera para los hechos en el momento de la inferencia (el qué). Balaguer et al. reportan exactamente esto en su tarea agrícola: el pipeline híbrido superó a cualquiera de los dos enfoques por separado, con la ganancia de 5 puntos del RAG apilada sobre los 6 del fine-tuning.

La ruta de madurez que recomendamos: empieza con ingeniería de prompts, añade RAG en el momento en que las respuestas necesiten datos privados o frescos, y añade fine-tuning solo cuando las inconsistencias de formato o la latencia empiecen a doler en producción. Salta directo al fine-tuning y pagarás el impuesto de entrenamiento antes de saber si la recuperación ya resolvió el problema.

El patrón híbrido no es un compromiso; para despliegues maduros es el valor por defecto: afina para el formato, recupera para los hechos.

¿Cómo evalúas a tu ganador?

Elige al ganador como elegirías una base de datos: mide con tu carga de trabajo, no con corazonadas. La receta cabe en un párrafo y cubre las cuatro cifras que de verdad deciden.

• Conjunto de preguntas retenido. 100-300 preguntas reales de usuarios. No sintéticas, nunca nada visto durante el entrenamiento o el indexado.
• Fidelidad y corrección de la respuesta. La fidelidad pregunta si la respuesta se apoya en el contexto recuperado; la corrección pregunta si de verdad es correcta. La pareja, popularizada por RAGAS, detecta tanto alucinaciones como fallos de recuperación.
• Latencia en p95, no la media. La recuperación añade una ida y vuelta; mide la cola.
• Coste por 1.000 consultas, tokens más infraestructura, medido en vez de estimado.
• Reejecuta con la deriva. Documentos nuevos, snapshot nuevo del modelo, trimestre nuevo: reejecuta el conjunto.

El desglose completo de métricas, incluyendo herramientas, está en nuestra guía de evaluación de LLMs.

Preguntas frecuentes

¿Se pueden usar RAG y fine-tuning juntos?

Sí. Afina para el formato de salida y la fluidez de dominio, y mantén la recuperación para los hechos en el momento de la inferencia. Balaguer et al. midieron este híbrido en una tarea de QA agrícola y encontraron que superaba a cualquiera de los enfoques por separado, con las ganancias de precisión apilándose. La mayoría de los sistemas maduros en producción acaban aquí: los pesos para el cómo, la recuperación para el qué.

¿Cuándo no usar fine-tuning?

Evita el fine-tuning cuando tu conocimiento cambia más rápido de lo que puedes reentrenar, cuando tienes menos de unos pocos cientos de ejemplos etiquetados, cuando las respuestas deben llevar citas o pistas de auditoría, o cuando no hay presupuesto para reentrenar a medida que los datos derivan. Esas cuatro condiciones describen la mayoría de los productos en fase temprana, y por eso el RAG suele ser el primer movimiento correcto.

¿Está desmentido el fine-tuning?

No, pero su territorio se encogió. Las ventanas de contexto largas y el RAG barato absorbieron casos de uso que en 2023 exigían fine-tuning. Lo que queda es real: formato de salida estricto, tono de marca, presupuestos de latencia sin ida y vuelta de recuperación y economía de modelos pequeños. Si tu problema es cómo responde el modelo en vez de lo que sabe, el fine-tuning sigue siendo la herramienta.

¿Cuándo usarías RAG frente a fine-tuning?

Usa RAG cuando las respuestas dependen de conocimiento privado o actualizado con frecuencia, o cuando necesitas citas. Usa fine-tuning cuando necesitas formato, tono o latencia consistentes y tienes suficientes ejemplos etiquetados. Usa ambos cuando el producto madure. Si dudas, empieza con RAG: es más barato de deshacer que un entrenamiento.

¿Es el RAG más barato que el fine-tuning?

Por adelantado, sí. El coste del RAG es por consulta (embeddings más tokens de entrada extra), mientras que el fine-tuning cobra una vez por el entrenamiento y los datos etiquetados, y luego se renueva con cada reentrenamiento. Con precios de lista públicos, el punto de equilibrio se sitúa en torno a 6,4 millones de consultas en nuestro ejemplo trabajado, así que con volúmenes típicos el RAG sigue siendo más barato durante toda la vida del producto.

¿Es el RAG mejor que el fine-tuning para las alucinaciones?

Normalmente, pero no gratis. El RAG ancla las respuestas en fragmentos recuperados, así que puedes citar fuentes y auditar fallos. Pero una mala recuperación envenena la respuesta: Anthropic midió una tasa de fallo de recuperación top-20 del 5,7% en configuraciones simples, recortada al 1,9% con recuperación contextual más reranking. El fine-tuning, mientras tanto, puede hornear errores en los pesos sin forma de rastrearlos.

RAG vs fine-tuning vs ingeniería de prompts: ¿cuál es la diferencia?

La ingeniería de prompts cambia las instrucciones que envías. El RAG cambia el contexto que el modelo lee en el momento de la consulta. El fine-tuning cambia los pesos del modelo. Cada uno es una intervención mayor que el anterior: prueba primero los prompts, añade recuperación cuando el conocimiento sea el cuello de botella y entrena solo cuando el formato, el tono o la latencia sigan doliendo.

¿Cómo evalúas el rendimiento de RAG frente a fine-tuning?

Construye un conjunto retenido de 100-300 preguntas reales de usuarios y puntúa ambos enfoques con él: fidelidad (¿se apoya en el contexto?), corrección de la respuesta (¿es correcta?), latencia en p95 y coste por 1.000 consultas. Reejecuta el conjunto cada vez que cambien tus documentos o el snapshot del modelo. Las preguntas sintéticas halagan a ambos sistemas; las reales los separan.

¿Fine-tuning o RAG para preguntas multi-salto sobre conocimiento nuevo?

RAG, con mejor recuperación. El mecanismo decide esta: un modelo afinado solo puede razonar sobre lo que absorbieron sus pesos, así que el conocimiento que nunca vio es inalcanzable por muy bien entrenado que esté. La recuperación le entrega las piezas que faltan en el momento de la consulta. La trampa es que una sola pasada de recuperación rara vez reúne todos los saltos, así que planea descomposición de consultas o recuperación iterativa más un reranker, no una única búsqueda top-K.

Conclusión

El resumen, sin rodeos:

• El RAG es la opción por defecto para conocimiento cambiante y respuestas citadas. El fine-tuning es el especialista para formato, tono y latencia.
• La evidencia sobre la misma tarea (Balaguer et al.) da al fine-tuning +6 p.p. y al RAG otros +5 p.p. encima, con el híbrido como el mejor de los tres. Nuestro consejo de empezar con RAG se apoya en la frescura, las citas y el coste, no en ese marcador.
• Las cuentas de costes caen del lado del RAG con volúmenes realistas: el punto de equilibrio se situó en torno a 6,4 millones de consultas en nuestro ejemplo trabajado.
• Decide con los cinco checks, no con la costumbre.

¿Elegiste RAG? Mira nuestra lista clasificada de herramientas RAG para la pila que rodea al pipeline.