RAG vs fine-tuning: que elegir para tu caso de uso empresarial

La pregunta mal planteada

“Deberiamos usar RAG o fine-tuning?” es la pregunta que mas recibimos de CTOs evaluando como integrar LLMs en sus procesos. Y es una pregunta mal planteada, porque asume que son alternativas mutuamente excluyentes. No lo son. Son tecnicas complementarias que resuelven problemas diferentes. Pero como la mayoria de los casos de uso empresariales caen mas naturalmente en uno de los dos campos, la comparacion tiene sentido practico.

Esto es lo que hemos medido en proyectos reales, no lo que dicen los papers academicos.

RAG: cuando el conocimiento cambia

Retrieval-Augmented Generation (RAG) consiste en buscar informacion relevante en una base de conocimiento y pasarsela al LLM junto con la pregunta del usuario. El modelo no “sabe” la respuesta; la encuentra en los documentos que le proporcionas.

Cuando funciona bien:

• Base de conocimiento que cambia frecuentemente (documentacion de producto, politicas internas, normativa, catalogo de productos)
• Respuestas que deben citar fuentes especificas (“segun el articulo 47 del reglamento…”)
• Conocimiento propietario que no existe en los datos de entrenamiento del modelo
• Necesidad de controlar estrictamente que informacion esta disponible para el modelo

Numeros reales de nuestros despliegues RAG:

Metrica	Valor tipico
Latencia end-to-end	1.2 - 3.5 segundos
Coste por query	0.003 - 0.015 EUR
Precision (respuesta correcta)	78 - 89%
Precision con reranking	84 - 93%
Tiempo de actualizacion de base	Minutos a horas

La latencia de RAG tiene dos componentes: la busqueda en el vector store (50-200ms con pgvector o Qdrant) y la generacion del LLM (1-3 segundos). El coste por query depende del modelo usado para generar: GPT-4o mini cuesta ~0.003 EUR/query, Claude 3.5 Sonnet ~0.008 EUR/query, GPT-4o ~0.015 EUR/query.

Donde RAG falla:

La calidad de RAG depende enteramente de la calidad del retrieval. Si el sistema recupera documentos irrelevantes, el modelo genera respuestas irrelevantes con total confianza. El problema clasico es el “retrieval gap”: la pregunta del usuario y el texto del documento usan vocabulario diferente para referirse al mismo concepto. Qdrant y pgvector son los vector stores que mas usamos en produccion para la busqueda semantica. “Como cancelo mi suscripcion?” y “Procedimiento de baja del servicio” son semanticamente equivalentes pero lexicamente distintos.

Las soluciones que funcionan: embeddings de calidad (text-embedding-3-large de OpenAI o los modelos de Cohere son los que mejores resultados nos dan), chunking inteligente (no cortar documentos cada 500 tokens sino por secciones logicas), metadata filtering (filtrar por fecha, tipo de documento, departamento antes de la busqueda semantica), y reranking (usar un modelo de reranking como Cohere Rerank o un cross-encoder para reordenar los resultados del retrieval).

Un pipeline RAG bien construido tiene 5-7 componentes. Un pipeline RAG que funciona en produccion tiene 12-15, contando fallbacks, caches, monitoring y los mecanismos de feedback del usuario.

Fine-tuning: cuando necesitas un comportamiento diferente

Fine-tuning consiste en reentrenar (parcialmente) un modelo con datos especificos para que se comporte de una manera determinada. No le das informacion en el momento de la query; cambias como el modelo genera respuestas.

Cuando funciona bien:

• Necesitas que el modelo siga un estilo, formato o tono especifico de manera consistente
• Tareas de clasificacion especializadas donde el modelo base no rinde suficiente
• Extraction de datos estructurados de textos con un formato particular a tu industria
• Vocabulario tecnico o jerga que el modelo base no maneja bien

Numeros reales de nuestros despliegues fine-tuned:

Metrica	Valor tipico
Latencia	0.5 - 2.0 segundos
Coste de entrenamiento	50 - 500 EUR por run
Coste por query	0.002 - 0.010 EUR
Precision en tarea especifica	88 - 96%
Tiempo de actualizacion	Dias (reentrenamiento)
Dataset minimo	200 - 1000 ejemplos

El fine-tuning tiene menor latencia que RAG porque no hay paso de retrieval. El coste por query tambien tiende a ser menor porque puedes fine-tunear un modelo mas pequeno (GPT-4o mini fine-tuned rinde sorprendentemente bien para tareas especificas). Pero el coste de preparar el dataset y entrenar es significativo.

Donde fine-tuning falla:

Fine-tuning no anade conocimiento nuevo de forma fiable. Si entrenas un modelo con datos de 2023 y le preguntas por regulacion de 2025, va a inventar la respuesta. El modelo internaliza patrones, no hechos verificables. Esto es critico: si tu caso de uso requiere respuestas basadas en datos que cambian, fine-tuning solo no es la solucion.

El otro problema es la “catastrofica forgetting”: al entrenar en datos especificos, el modelo puede perder capacidades generales. Un modelo fine-tuned para clasificar facturas puede volverse peor en conversacion general. Esto se mitiga con tecnicas como LoRA (Low-Rank Adaptation), que solo modifica un subconjunto de parametros, pero es un riesgo real.

La decision practica: un arbol de decision

Despues de implementar ambas tecnicas en multiples clientes, este es el arbol de decision que usamos:

Pregunta 1: La informacion necesaria para responder cambia mas de una vez al mes?

• Si -> RAG (o RAG + fine-tuning)
• No -> Sigue a pregunta 2

Pregunta 2: El caso de uso principal es responder preguntas sobre documentos especificos?

• Si -> RAG
• No -> Sigue a pregunta 3

Pregunta 3: Necesitas que el modelo siga un formato, estilo o comportamiento muy especifico?

• Si -> Fine-tuning (posiblemente + RAG)
• No -> Sigue a pregunta 4

Pregunta 4: Tienes al menos 500 ejemplos de calidad de la tarea?

• Si -> Fine-tuning probablemente vale la pena
• No -> Usa el modelo base con un system prompt bien diseñado

En la practica, el 70% de los casos de uso empresariales que vemos son mejor servidos por RAG, el 15% por fine-tuning, y el 15% por la combinacion de ambos.

RAG + fine-tuning: cuando ambos juntos

La combinacion es poderosa y subutilizada. El escenario tipico: tienes una base de conocimiento (RAG) pero necesitas que las respuestas sigan un formato o estilo muy especifico (fine-tuning).

Ejemplo real: un despacho de abogados que necesita consultar jurisprudencia (RAG sobre base de datos de sentencias) pero generar respuestas en el estilo formal juridico espanol con estructura de dictamen (fine-tuning del modelo para generar en ese formato).

RAG proporciona los hechos. Fine-tuning proporciona la forma. El resultado es consistentemente mejor que cualquiera de los dos por separado.

Otro patron: fine-tunear el modelo de embeddings (no el LLM generativo) con datos de tu dominio. Si tu industria tiene vocabulario tecnico que los embeddings genericos no capturan bien, un embedding model fine-tuned mejora la calidad del retrieval. Hemos medido mejoras del 12-18% en precision de retrieval al fine-tunear embeddings con 2.000-5.000 pares de (query, documento relevante) del dominio.

El coste total de propiedad

La comparacion de costes no es solo “coste por query”:

Concepto	RAG	Fine-tuning
Setup inicial	2-4 semanas	1-3 semanas
Infraestructura	Vector DB + LLM API	LLM API (o hosting propio)
Actualizacion de datos	Continua, automatizable	Reentrenamiento periodico
Mantenimiento mensual	Monitoring, re-indexacion	Monitoring, evaluacion de drift
Escalado	Lineal con queries	Lineal con queries
Coste/query (escala media)	0.005 - 0.015 EUR	0.002 - 0.010 EUR

El coste oculto de RAG es el mantenimiento de la base de conocimiento: actualizar documentos, re-indexar, gestionar versiones, limpiar contenido obsoleto. Si nadie mantiene la base, la calidad se degrada progresivamente.

El coste oculto de fine-tuning es la evaluacion continua. Los modelos base se actualizan (GPT-4 a GPT-4o, Claude 3 a Claude 3.5), y cada actualizacion puede requerir reentrenar el fine-tune. Ademas, necesitas un dataset de evaluacion para detectar cuando el rendimiento se degrada.

Lo que realmente importa

La eleccion entre RAG y fine-tuning es una decision de arquitectura, no de tecnologia. Y como toda decision de arquitectura, depende del contexto: que datos tienes, con que frecuencia cambian, que calidad de respuesta necesitas, y cuanto puedes invertir en mantenimiento continuo.

Lo que hemos aprendido es que la mayoria de los proyectos de IA empresarial fracasan no por elegir mal entre RAG y fine-tuning, sino por subestimar el trabajo de ingenieria de datos que ambos requieren. Un RAG con datos mal indexados o un fine-tune con un dataset de baja calidad van a producir resultados mediocres independientemente de la tecnica. La calidad del dato de entrada es el factor predictivo mas fuerte del exito. Todo lo demas es implementacion.

Para profundizar en como llevar estos modelos a produccion con las metricas adecuadas, consulta nuestro articulo sobre MLOps: del notebook al pipeline de produccion. Y si tu caso de uso involucra clasificacion de documentos, nuestra guia practica de NLP para clasificacion de documentos cubre fine-tuning paso a paso.