RAG vs Fine-tuning: cuándo usar cada uno (guía práctica)

Un cliente me mostró su arquitectura hace unos meses. Había pasado seis semanas haciendo fine-tuning de un modelo para que respondiera preguntas sobre la documentación interna de su empresa.

Seis semanas. Un dataset de 4.000 pares de pregunta-respuesta construidos a mano. Costes de entrenamiento en GPU. Y al final, el sistema seguía inventándose respuestas cuando la pregunta tocaba un documento que no estaba en el training data.

Le pregunté por qué no había usado RAG. Me dijo que pensó que fine-tuning era “la solución profesional”. Que RAG era para hacer demos rápidas. Ese malentendido sobre RAG vs Fine-tuning es más común de lo que parece, y sale caro.

El error conceptual que lo complica todo

La mayoría de developers que se acercan a este problema lo enmarcan mal desde el principio.

Piensan en términos de “qué técnica es más potente”. Y ahí ya van por el camino equivocado.

La pregunta correcta no es cuál es más potente. Es: ¿qué problema tienes exactamente?

Si tu modelo no sabe cosas que necesita saber — información privada, documentos internos, datos recientes — tienes un problema de conocimiento. RAG lo resuelve.

Si tu modelo sabe las cosas pero no las comunica como necesitas — tono diferente, formato específico, comportamiento distinto al por defecto — tienes un problema de comportamiento. Fine-tuning lo resuelve.

Son problemas distintos. Las soluciones no son intercambiables.

Qué es RAG (Retrieval-Augmented Generation) y cuándo usarlo

RAG (Retrieval-Augmented Generation) no modifica el modelo. El modelo base sigue siendo exactamente el mismo.

Lo que hace RAG es intervenir en el momento en que llega una pregunta. Antes de pasársela al modelo, busca en una base de datos vectorial los fragmentos de tus documentos más relevantes para esa consulta, y los inyecta en el prompt. El modelo entonces responde con acceso real a esa información.

Usuario pregunta: "¿Cuál es la política de devoluciones?"
                         ↓
             Sistema RAG busca en vectorDB
                         ↓
      Encuentra: chunk del doc "politica-devoluciones-2026.pdf"
                         ↓
    Prompt al modelo: "Contexto: [chunk]. Pregunta: ¿Cuál es...?"
                         ↓
            Modelo responde con información real

La ventaja clave: tus documentos pueden cambiar mañana. Actualizas la base vectorial. El modelo ya tiene acceso a la nueva información. Sin reentrenar nada.

Si estás explorando qué modelo usar para el componente generativo, este análisis sobre el mejor modelo LLM local en 2026 te ayuda a elegir sin sobreingenierizar la infraestructura.

Esto es lo que lo hace ideal para documentación interna, bases de conocimiento, FAQs, soporte técnico — cualquier caso donde la información cambia y necesitas que el modelo cite fuentes reales en lugar de fabricar respuestas.

El límite de RAG está en que no cambia cómo se comporta el modelo. Si necesitas que responda en un tono muy específico, siga un formato exacto, o haga razonamientos que el modelo base no hace bien de forma natural, RAG no te ayuda. Solo le das más información. No lo entrenas.

Qué es Fine-tuning de LLMs y cuándo tiene sentido aplicarlo

Fine-tuning sí modifica el modelo. Tomas un modelo base preentrenado y lo sigues entrenando con tu propio dataset, ajustando sus pesos para que aprenda los patrones que te interesan.

El resultado es un modelo diferente. Uno que ha interiorizado un estilo, un formato, un tipo de razonamiento específico. No necesitas darle instrucciones en el prompt porque ya las tiene grabadas en sus pesos.

# Sin fine-tuning: necesitas el prompt completo prompt = """Eres un asistente técnico especializado en Kubernetes. Responde siempre con: 1) causa del problema, 2) solución paso a paso, 3) cómo prevenirlo. Usa terminología técnica precisa. No añadas disclaimers. El tono es directo, de senior a senior. Problema: Mi pod no arranca después de actualizar la imagen..."""

# Con fine-tuning: el modelo ya sabe cómo comportarse prompt = "Problema: Mi pod no arranca después de actualizar la imagen..."

El modelo fine-tuneado responde directamente en el formato correcto porque ese comportamiento está en sus pesos. No porque se lo estés recordando en cada llamada.

Lo que fine-tuning no resuelve: inyectar conocimiento factual nuevo. Si entrenas el modelo en el estilo de tu empresa pero no en los documentos de tu empresa, seguirá sin saber qué contienen esos documentos. Habrá aprendido a comunicarse como tú quieres, pero no a responder con información real que no tenía.

RAG vs Fine-tuning: la matriz de decisión con cuatro casos reales

Hay cuatro combinaciones que aparecen una y otra vez en proyectos reales. Aquí están con sus soluciones.

Caso 1: Chatbot sobre documentación interna

Necesitas que el modelo responda preguntas sobre tus PDFs, wikis, Notion, Confluence. La información cambia regularmente. El tono puede ser el del modelo base.

Solución: RAG. Indexas los documentos en una vectorDB (Pinecone, pgvector, Weaviate), configuras el pipeline de retrieval, y el modelo responde con fuentes reales. No reentrenar nada.

Caso 2: Generador de código en el estilo de tu empresa

Quieres que el modelo genere código que siga tus convenciones internas, use tus abstracciones propias, evite los patrones que prohíbes. El modelo base lo entiende pero tienes que recordárselo en cada prompt.

Solución: Fine-tuning. Un dataset de ejemplos de código en tu estilo — antes/después — y el modelo interioriza esas preferencias. El prompt se simplifica radicalmente.

Caso 3: Asistente de soporte que responde sobre tus productos Y en tu tono

Quieres las dos cosas: información factual sobre tus productos (que cambia) y un comportamiento de comunicación muy específico (directo, sin ambigüedades, con formato concreto).

Solución: Fine-tuning + RAG. Fine-tuning para el comportamiento y el formato. RAG para la información factual. Son complementarios, no excluyentes.

Caso 4: Clasificador de texto o extractor de entidades

Necesitas que el modelo clasifique tickets de soporte, extraiga entidades de contratos, o haga tareas de NLP muy específicas.

Solución: Fine-tuning en casi todos los casos. Para tareas de clasificación y extracción, un modelo fine-tuneado en tu dominio supera consistentemente a uno general con prompts elaborados, y además es más barato en inferencia porque los prompts son más cortos.

Los costes reales — lo que nadie te dice antes de empezar

Costes de RAG:

Configurar el pipeline de chunking, embedding y retrieval: 2-5 días de desarrollo
Inferencia: coste del modelo base + coste de las llamadas a la vectorDB (bajo)
Mantenimiento: actualizar la base vectorial cuando cambian los documentos (automatizable)
Problema principal: calidad del retrieval — si buscas mal, el modelo responde mal aunque los documentos sean perfectos

Costes de Fine-tuning:

Construir el dataset de entrenamiento: semanas (es el cuello de botella real)
Entrenamiento: desde $50 hasta miles de dólares dependiendo del modelo y el tamaño del dataset
Inferencia: más cara que el modelo base porque tienes que hostear tu propio modelo o pagar por el endpoint custom
Problema principal: degradación con el tiempo — si tu tarea evoluciona, tienes que reentrenar

La mayoría de proyectos que han hecho fine-tuning cuando lo que necesitaban era RAG han pagado semanas de trabajo y costes de entrenamiento para resolver un problema que RAG hubiera resuelto en cuatro días.

El árbol de decisión que uso en consultoría

Cuando alguien me pregunta qué usar, le hago estas cuatro preguntas en orden:

1. ¿Tu problema es que el modelo no tiene la información o que no se comporta como quieres?

No tiene la información → RAG
No se comporta bien → Fine-tuning

2. ¿La información cambia con frecuencia?

Sí → RAG (actualizar embeddings es trivial vs. reentrenar)
No → Fine-tuning empieza a tener más sentido

3. ¿Tienes datos de entrenamiento de alta calidad?

No los tienes → empieza con RAG mientras los recopilas
Sí los tienes → Fine-tuning es viable

4. ¿Tienes restricciones de latencia o coste de inferencia?

Sí, necesitas prompts muy cortos → Fine-tuning reduce el prompt dramáticamente
No es crítico → RAG es suficiente

En la práctica, el 70% de los casos que veo en producción son candidatos a RAG, no a fine-tuning. Fine-tuning es potente pero requiere un problema muy bien definido, datos de calidad y tiempo para construirlos.

Qué pasa cuando combinas los dos

La combinación más efectiva en sistemas de producción serios sigue un patrón concreto. Y es parte de una arquitectura más amplia — si quieres entender cómo el LLM encaja con el resto del sistema, el post sobre qué es un agent harness lo explica con detalle.

Fine-tuning para que el modelo entienda el dominio, la terminología y el formato de respuesta esperado
RAG para que el modelo tenga acceso a la información factual actualizada

Un ejemplo real: un asistente jurídico. Fine-tuneado para entender terminología legal española, responder en formato jurídico y estructurar los análisis como lo haría un abogado. RAG conectado a la base de legislación actualizada y a los expedientes del despacho.

El modelo habla como un jurista (fine-tuning). Responde con la ley real y los documentos del caso (RAG). Ninguna de las dos técnicas sola lo consigue.

Esta es la arquitectura que más vemos en productos de IA serios. No es glamorosa. Pero funciona. En el curso Construye con IA: de la idea al producto con Claude Code, trabajo este tipo de decisiones de arquitectura desde la fase de especificación — antes de escribir una línea de código — para que no llegues a la semana seis arrepintiéndote de la técnica que elegiste.

Tabla comparativa RAG vs Fine-tuning

	RAG	Fine-tuning
Problema que resuelve	El modelo no tiene la información	El modelo no se comporta como quieres
Modifica el modelo	No	Sí
Cuándo usar	Datos dinámicos, documentos, bases de conocimiento	Estilo, formato, comportamiento consistente
Coste de inicio	Bajo-medio (pipeline)	Alto (dataset + entrenamiento)
Mantenimiento	Fácil (actualizar vectorDB)	Costoso (reentrenar cuando cambia el problema)
Tiempo hasta producción	Días	Semanas
Combinar con el otro	Sí	Sí

Guarda esta tabla. Te va a ahorrar más de una conversación.

FAQ

¿Puedo usar RAG con cualquier LLM?

Sí. RAG es agnóstico al modelo. Funciona con GPT-4, Claude, Gemini, Llama, Mistral o cualquier modelo que acepte un prompt de texto. Lo único que necesitas es que el modelo tenga una ventana de contexto suficiente para recibir los chunks recuperados junto con la pregunta. Los modelos modernos (128k-200k tokens) raramente tienen problemas con esto.

¿El fine-tuning de GPT-4 o Claude vale la pena frente a usar el modelo base con un buen prompt?

En la mayoría de casos de uso, un buen prompt de sistema con ejemplos (few-shot prompting) iguala o supera al fine-tuning cuando el dataset de entrenamiento es pequeño (menos de 1.000 ejemplos). Fine-tuning empieza a tener sentido claro cuando tienes +5.000 ejemplos de calidad, cuando el coste de inferencia del prompt largo es un problema real, o cuando necesitas consistencia de comportamiento imposible de garantizar solo con prompts.

¿RAG siempre “alucina” menos que el modelo base?

RAG reduce alucinaciones relacionadas con hechos específicos de tus documentos — porque el modelo tiene el texto real delante. Pero no elimina las alucinaciones del modelo base sobre razonamientos o inferencias. Si el modelo alucina porque hace mal el razonamiento lógico, RAG no te ayuda. Ese es un problema de capacidad del modelo, no de conocimiento.

¿Qué vectorDB recomendas para empezar?

Para proyectos nuevos: pgvector si ya usas PostgreSQL (cero infraestructura adicional), o Pinecone si quieres un servicio gestionado sin fricción operativa. Weaviate y Chroma son buenas opciones open-source si necesitas auto-hosting. Evita sobre-ingenierizar esto al principio — pgvector resuelve el 80% de los casos sin añadir complejidad. Puedes consultar la documentación oficial de pgvector para la instalación y configuración básica.

¿Cuánto cuesta hacer fine-tuning con GPT-4o mini o Llama 3?

GPT-4o mini fine-tuning en OpenAI cuesta aproximadamente $3-5 por millón de tokens de entrenamiento (junio 2026). Un dataset de 10.000 ejemplos con prompts de 500 tokens cada uno te sale a menos de $30 de entrenamiento. El coste real no es el GPU — es el tiempo de construir el dataset de calidad. Con Llama 3, puedes hacer fine-tuning con frameworks como Unsloth en una GPU A100 por $2-4/hora. Un run de fine-tuning de 3-4 horas es completamente asequible.

¿RAG vs Fine-tuning cambia con los modelos de razonamiento (o1, Gemini Thinking)?

Sí, hay un matiz importante. Los modelos de razonamiento son mucho mejores siguiendo instrucciones complejas en el prompt, lo que reduce la necesidad de fine-tuning para casos de comportamiento. Pero siguen sin tener acceso a información privada o actualizada — ahí RAG sigue siendo indispensable. El fine-tuning con modelos de razonamiento es técnicamente más complejo y menos documentado a fecha de hoy.

Si quieres ver estos patrones aplicados en proyectos reales con código y arquitectura completa, en Dominicode Labs trabajamos este tipo de decisiones técnicas con la comunidad. Proyectos reales, problemas reales, decisiones que puedes aplicar esta semana.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.