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

La pregunta mal planteada

“Deberíamos usar RAG o fine-tuning?” es la pregunta que más recibimos de CTOs evaluando cómo integrar LLMs en sus procesos. Y es una pregunta mal planteada, porque asume que son alternativas mutuamente excluyentes. No lo son. Son técnicas complementarias que resuelven problemas diferentes. Pero como la mayoría de los casos de uso empresariales caen más naturalmente en uno de los dos campos, la comparación tiene sentido práctico.

Esto es lo que hemos medido en proyectos reales, no lo que dicen los papers académicos.

RAG: cuando el conocimiento cambia

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

Cuándo funciona bien:

• Base de conocimiento que cambia frecuentemente (documentación de producto, políticas internas, normativa, catálogo de productos)
• Respuestas que deben citar fuentes específicas (“según el artículo 47 del reglamento…”)
• Conocimiento propietario que no existe en los datos de entrenamiento del modelo
• Necesidad de controlar estrictamente que información está disponible para el modelo

Números reales de nuestros despliegues RAG:

Métrica	Valor típico
Latencia end-to-end	1.2 - 3.5 segundos
Coste por query	0.003 - 0.015 EUR
Precisión (respuesta correcta)	78 - 89%
Precisión con reranking	84 - 93%
Tiempo de actualización de base	Minutos a horas

La latencia de RAG tiene dos componentes: la búsqueda en el vector store (50-200ms con pgvector o Qdrant) y la generación 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.

Dónde 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 clásico 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 más usamos en producción para la búsqueda semántica. “Cómo cancelo mi suscripción?” y “Procedimiento de baja del servicio” son semánticamente equivalentes pero léxicamente 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 lógicas), metadata filtering (filtrar por fecha, tipo de documento, departamento antes de la búsqueda semántica), 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 producción 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 específicos para que se comporte de una manera determinada. No le das información en el momento de la query; cambias como el modelo genera respuestas.

Cuándo funciona bien:

• Necesitas que el modelo siga un estilo, formato o tono específico de manera consistente
• Tareas de clasificación especializadas donde el modelo base no rinde suficiente
• Extraction de datos estructurados de textos con un formato particular a tu industria
• Vocabulario técnico o jerga que el modelo base no maneja bien

Números reales de nuestros despliegues fine-tuned:

Métrica	Valor típico
Latencia	0.5 - 2.0 segundos
Coste de entrenamiento	50 - 500 EUR por run
Coste por query	0.002 - 0.010 EUR
Precisión en tarea específica	88 - 96%
Tiempo de actualización	Días (reentrenamiento)
Dataset mínimo	200 - 1000 ejemplos

El fine-tuning tiene menor latencia que RAG porque no hay paso de retrieval. El coste por query también tiende a ser menor porque puedes fine-tunear un modelo más pequeño (GPT-4o mini fine-tuned rinde sorprendentemente bien para tareas específicas). Pero el coste de preparar el dataset y entrenar es significativo.

Dónde fine-tuning falla:

Fine-tuning no añade conocimiento nuevo de forma fiable. Si entrenas un modelo con datos de 2023 y le preguntas por regulación de 2025, va a inventar la respuesta. El modelo internaliza patrones, no hechos verificables. Esto es crítico: si tu caso de uso requiere respuestas basadas en datos que cambian, fine-tuning solo no es la solución.

El otro problema es la “catastrófica forgetting”: al entrenar en datos específicos, el modelo puede perder capacidades generales. Un modelo fine-tuned para clasificar facturas puede volverse peor en conversación general. Esto se mitiga con técnicas como LoRA (Low-Rank Adaptation), que solo modifica un subconjunto de parámetros, pero es un riesgo real.

La decisión práctica: un árbol de decisión

Después de implementar ambas técnicas en múltiples clientes, este es el árbol de decisión que usamos:

Pregunta 1: La información necesaria para responder cambia más 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 específicos?

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

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

• 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 práctica, 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 combinación de ambos.

RAG + fine-tuning: cuando ambos juntos

La combinación es poderosa y subutilizada. El escenario típico: tienes una base de conocimiento (RAG) pero necesitas que las respuestas sigan un formato o estilo muy específico (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 jurídico español 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 patrón: fine-tunear el modelo de embeddings (no el LLM generativo) con datos de tu dominio. Si tu industria tiene vocabulario técnico que los embeddings genéricos no capturan bien, un embedding model fine-tuned mejora la calidad del retrieval. Hemos medido mejoras del 12-18% en precisión de retrieval al fine-tunear embeddings con 2.000-5.000 pares de (query, documento relevante) del dominio.

El coste total de propiedad

La comparación 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)
Actualización de datos	Continua, automatizable	Reentrenamiento periódico
Mantenimiento mensual	Monitoring, re-indexación	Monitoring, evaluación 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 evaluación continua. Los modelos base se actualizan (GPT-4 a GPT-4o, Claude 3 a Claude 3.5), y cada actualización puede requerir reentrenar el fine-tune. Además, necesitas un dataset de evaluación para detectar cuando el rendimiento se degrada.

Lo que realmente importa

La elección entre RAG y fine-tuning es una decisión de arquitectura, no de tecnología. Y como toda decisión de arquitectura, depende del contexto: qué datos tienes, con qué frecuencia cambian, qué calidad de respuesta necesitas, y cuánto puedes invertir en mantenimiento continuo.

Lo que hemos aprendido es que la mayoría de los proyectos de IA empresarial fracasan no por elegir mal entre RAG y fine-tuning, sino por subestimar el trabajo de ingeniería 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 técnica. La calidad del dato de entrada es el factor predictivo más fuerte del éxito. Todo lo demás es implementación.

Para profundizar en cómo llevar estos modelos a producción con las métricas adecuadas, consulta nuestro artículo sobre MLOps: del notebook al pipeline de producción. Y si tu caso de uso involucra clasificación de documentos, nuestra guía práctica de NLP para clasificación de documentos cubre fine-tuning paso a paso.