RAG vs Fine-tuning: cuándo usar cada uno (guía de decisión)

El error más común al empezar

Muchos equipos asumen que si quieren que un modelo "conozca" su información, necesitan hacer fine-tuning. Es una intuición razonable pero casi siempre incorrecta.

La mayoría de los casos de negocio se resuelven mejor con RAG. El fine-tuning se reserva para un conjunto de problemas mucho más específico.

Esta guía te ayuda a decidir cuál necesitas, o si los necesitas a la vez.

Qué es cada uno (en una frase)

RAG (Retrieval-Augmented Generation): el modelo no aprende nada nuevo. En cada llamada, le das la información relevante como contexto. El modelo la usa para responder.

Fine-tuning: modificas los pesos del modelo con ejemplos de entrenamiento propios. El modelo "aprende" patrones, estilos o comportamientos que quieres que adopte de forma permanente.

La diferencia fundamental

| | RAG | Fine-tuning | |--|-----|-------------| | ¿El modelo aprende algo? | No | Sí (pesos modificados) | | ¿Cuándo se añade la información? | En tiempo de inferencia | En tiempo de entrenamiento | | ¿Cómo se actualiza la información? | Actualiza la base de datos | Reentrenar el modelo | | ¿Cita fuentes? | Puede hacerlo | No de forma nativa | | ¿Necesita datos de entrenamiento? | No | Sí, muchos ejemplos | | Coste inicial | Bajo-Medio | Alto | | Coste de actualización | Bajo | Alto | | Tiempo de implementación | Días-semanas | Semanas-meses |

Cuándo usar RAG

RAG es la opción correcta cuando:

Tu información cambia frecuentemente

Documentación que se actualiza, precios que varían, políticas que cambian. Con RAG, actualizas la base de conocimiento y el sistema inmediatamente usa la información nueva. Con fine-tuning, tendrías que reentrenar cada vez que cambia algo.

Necesitas citar fuentes

Si tu sistema de IA debe decir "esto lo dice el documento X, sección Y", RAG lo hace de forma natural. El fine-tuning no sabe de dónde viene lo que sabe.

Tienes documentos privados y extensos

Contratos, manuales internos, bases de datos de productos, historial de clientes. Meter todo eso en fine-tuning requeriría miles de ejemplos preparados. Con RAG, indexas los documentos tal como están.

El modelo base ya es bueno pero necesita contexto específico

Un modelo como Claude o GPT-4 ya sabe redactar, razonar, analizar. Solo le falta información específica de tu negocio. RAG se la da en cada llamada.

Presupuesto limitado

RAG puede implementarse en días con herramientas open-source. Fine-tuning de modelos grandes requiere infraestructura GPU y presupuesto significativo.

Ejemplo típico de RAG: un asistente que responde preguntas sobre los productos de tu empresa usando el catálogo y la documentación oficial.

Cuándo usar fine-tuning

Fine-tuning es la opción correcta cuando:

Quieres cambiar el estilo o formato de respuesta

Si necesitas que el modelo responda siempre con una estructura concreta, en un tono muy específico o en un formato que el prompting no logra con consistencia, fine-tuning puede resolver esto de forma permanente.

Tienes una tarea muy específica y repetitiva

Clasificar emails en categorías precisas, extraer datos con un formato exacto, generar código en un estilo de arquitectura concreto. Cuando el dataset de ejemplos es claro y la tarea está bien definida, fine-tuning puede superar a prompting + RAG.

Quieres reducir la longitud del system prompt

Si tienes un system prompt muy largo con muchas instrucciones de comportamiento, puedes incorporar parte de ese conocimiento al modelo mediante fine-tuning y reducir el uso de tokens en cada llamada.

Tienes miles de ejemplos etiquetados de alta calidad

Fine-tuning funciona cuando tienes datos reales de cómo debería responder el sistema. Sin buenos ejemplos, el fine-tuning no mejora el modelo.

El modelo base no tiene el conocimiento base necesario

Para dominios muy técnicos y especializados (derecho específico de un país, terminología médica de una especialidad muy concreta) donde el modelo base tiene gaps importantes.

Ejemplo típico de fine-tuning: un modelo que genera código en el estilo de arquitectura exacto de tu empresa, con las convenciones de naming y patrones que usáis.

El árbol de decisión

¿Tu información cambia frecuentemente? 
  → Sí → RAG

¿Necesitas que el modelo cite fuentes?
  → Sí → RAG

¿Tienes más de 1.000 ejemplos de alta calidad?
  → No → RAG (o solo prompting)
  → Sí → Considera fine-tuning

¿El problema es de conocimiento o de comportamiento?
  → Conocimiento → RAG
  → Comportamiento/estilo → Fine-tuning

¿Tienes semanas/meses para experimentar?
  → No → RAG
  → Sí → Experimenta con ambos

Costes reales

RAG

Implementación inicial: 5-30 días de ingeniería dependiendo de la complejidad
Infraestructura: base de datos vectorial (Pinecone ~70€/mes, o Qdrant/Weaviate self-hosted más barato), modelo de embeddings (OpenAI ~0.0001$/1K tokens o gratis con modelos locales)
Tokens de inferencia: cada llamada incluye los fragmentos recuperados, lo que aumenta el coste por llamada respecto a no usar RAG
Mantenimiento: actualizar documentos cuando cambian (bajo si está automatizado)

Fine-tuning

Preparación de datos: 2-8 semanas para preparar y limpiar el dataset de entrenamiento
Entrenamiento: OpenAI fine-tuning desde ~0.008$ por 1K tokens de entrenamiento. Para GPT-3.5 con 1 millón de tokens de datos: ~80€ por run.
Inferencia: los modelos fine-tuned suelen ser más caros por token que los base
Reentrenamiento: cada vez que quieres actualizar el comportamiento, hay que reentrenar

Combinando RAG y fine-tuning

No son mutuamente excluyentes. Algunas arquitecturas combinan los dos:

Fine-tuning para comportamiento + RAG para conocimiento: el fine-tuning establece el estilo, tono y format; el RAG proporciona la información específica. El resultado puede ser más consistente que usar solo uno.

Fine-tuning en el modelo de embeddings: en lugar de fine-tunear el LLM, se fine-tunea el modelo de embeddings para que entienda mejor el vocabulario específico del dominio. Esto mejora la precisión del retrieval en RAG.

Cuándo tiene sentido combinarlos: cuando tienes requisitos tanto de comportamiento muy específico (fine-tuning) como de información dinámica y actualizable (RAG), y el presupuesto lo permite.

La pregunta correcta no es "¿RAG o fine-tuning?"

La pregunta correcta es: ¿cuál es el problema real que quiero resolver?

Si el problema es "el modelo no sabe X" → RAG
Si el problema es "el modelo no hace X de la manera que necesito" → Fine-tuning (o mejor prompting)
Si el problema es "el modelo es lento/caro" → Considera modelos más pequeños o caching
Si el problema es "el modelo alucina" → RAG + guardrails

La mayoría de las veces, el problema que parece requerir fine-tuning se puede resolver con un sistema RAG bien diseñado y un system prompt bien escrito.

Recursos para implementar

Para RAG: Checklist de RAG y la guía Cómo crear una base de conocimiento para IA
Para decidir el modelo: Selector de modelo IA
Para comparar opciones: Comparador de modelos LLM