RAG vs Fine-tuning: cuándo usar cada uno en tu agente de IA

Casi todas las semanas alguien me pregunta lo mismo: “¿Tengo que entrenar mi propio modelo o me basta con conectarlo a mis documentos?”. Detrás de esa duda casi siempre hay una confusión entre dos cosas que resuelven problemas distintos: RAG (recuperación aumentada) y fine-tuning (personalizar modelos). Elegir mal no es un error académico: se paga en latencia, en factura mensual y en horas de mantenimiento que nadie presupuestó. Por eso vale la pena entender qué hace cada uno, qué cuesta y cuándo conviene, antes de tocar una sola línea de código.

La decisión importa todavía más cuando hablamos de agentes de IA con memoria, porque ahí el modelo no responde una pregunta aislada: acumula contexto, recuerda decisiones y actúa sobre sistemas reales. Si quieres ver cómo esto se traduce a un caso concreto, lo desarrollo en RAG y memoria para agentes en la práctica. Un mal diseño de conocimiento se nota rápido.

Qué resuelve cada enfoque

Antes de comparar, hay que separar dos preguntas que suelen mezclarse:

• ¿El modelo sabe qué responder? → es un problema de conocimiento.
• ¿El modelo sabe cómo responder? → es un problema de comportamiento, tono o formato.

RAG ataca el primero. Fine-tuning ataca, sobre todo, el segundo. Esa distinción es la brújula de toda esta decisión.

RAG (recuperación aumentada)

En RAG el modelo base no cambia. Lo que hacemos es darle, en tiempo de consulta, los fragmentos de información relevantes para que responda con ellos. El flujo típico es:

1. Tomas tus documentos y los divides en fragmentos (chunking).
2. Conviertes cada fragmento en un vector con un modelo de embeddings.
3. Guardas esos vectores en una base vectorial (Pinecone, pgvector, Qdrant, Weaviate).
4. Ante una pregunta, recuperas los fragmentos más cercanos y los inyectas en el prompt.

RAG no le enseña nada nuevo al modelo. Le pone los apuntes correctos sobre la mesa justo antes de responder.

La gran ventaja: para actualizar el conocimiento basta con cambiar los documentos y volver a indexar. No hay reentrenamiento.

Fine-tuning (personalizar modelos)

Aquí sí modificamos los pesos del modelo (o una capa ligera encima, como en LoRA/PEFT) con ejemplos propios. Le mostramos cientos o miles de pares entrada-salida hasta que internaliza un estilo, un formato o un patrón de razonamiento específico.

El fine-tuning brilla cuando necesitas que el modelo se comporte de cierta forma de manera consistente: responder siempre en un JSON con un esquema fijo, adoptar la voz de tu marca, clasificar con tus categorías internas o seguir un protocolo de razonamiento que el prompt solo no logra estabilizar. Antes de llegar a ese extremo, conviene exprimir el prompt engineering para agentes, que muchas veces resuelve el comportamiento sin tocar los pesos.

Comparativa directa

Dimensión	RAG	Fine-tuning
Qué cambia	El contexto en el prompt	Los pesos del modelo
Mejor para	Conocimiento fresco y verificable	Comportamiento, tono, formato
Costo inicial	Bajo a medio (infra vectorial)	Medio a alto (datos + cómputo)
Actualizar conocimiento	Reindexar documentos (minutos)	Reentrenar (horas/días)
Latencia por consulta	Mayor (búsqueda + prompt largo)	Menor (no hay recuperación)
Trazabilidad / citas	Alta: puedes citar la fuente	Baja: el saber queda implícito
Riesgo de alucinación	Menor si la recuperación es buena	Mayor si el dato no se entrenó
Mantenimiento	Pipeline de datos e índices	Ciclos de reentrenamiento y eval

Costos, latencia y mantenimiento sin maquillaje

Costos. RAG mueve el gasto hacia la infraestructura: base vectorial, generación de embeddings y prompts más largos (más tokens por consulta). Fine-tuning concentra el gasto al inicio (preparar datos limpios y pagar el cómputo del entrenamiento), pero luego cada inferencia puede ser más barata porque no arrastras contexto extra.

Latencia. Cada consulta RAG suma pasos: generar el embedding de la pregunta, buscar en el índice y construir un prompt extenso. Eso agrega milisegundos o segundos. Un modelo afinado responde directo, sin esa ronda de recuperación.

Mantenimiento. Aquí está la trampa que más subestiman los equipos. RAG exige cuidar el pipeline: re-chunking cuando cambian los documentos, control de calidad de los embeddings y limpieza del índice. Fine-tuning exige algo más pesado: cada vez que el conocimiento cambia de forma relevante, vuelves a entrenar y a evaluar. El conocimiento que cambia seguido casi nunca debería vivir dentro de los pesos.

Cuándo conviene cada uno

Usa RAG cuando:

• El conocimiento cambia con frecuencia (precios, políticas, documentación, inventario).
• Necesitas citar fuentes o auditar de dónde salió cada respuesta.
• Manejas mucha información que no cabe ni de cerca en una ventana de contexto.
• Quieres lanzar rápido y barato, sin tocar el modelo.

Usa fine-tuning cuando:

• Necesitas un formato o tono estable que el prompt no logra fijar.
• Tienes una tarea estrecha y repetitiva (clasificación, extracción, etiquetado).
• Buscas reducir latencia y tokens en producción a gran volumen.
• Cuentas con un dataset propio de buena calidad y razonablemente estable.

Regla de bolsillo: si el problema es “no sabe”, empieza por RAG. Si el problema es “sabe, pero no responde como quiero”, evalúa fine-tuning.

El enfoque híbrido: lo que suele ganar en producción

En sistemas serios rara vez es uno u otro. Lo que mejor funciona es combinarlos: fine-tuning para fijar el comportamiento + RAG para inyectar el conocimiento actualizado.

Un ejemplo concreto. Un agente de soporte técnico:

• Fine-tuning para que siempre siga el protocolo de escalamiento, mantenga el tono de la empresa y devuelva respuestas estructuradas.
• RAG para consultar la documentación de productos, que se actualiza cada semana.

Así el modelo “sabe comportarse” de forma estable y “sabe qué decir” con información siempre fresca. Cada técnica resuelve la mitad que le corresponde y ninguna carga con un trabajo para el que no fue diseñada.

Cómo se aplica a agentes con memoria

Cuando hablamos de memoria de agentes, la analogía con RAG es casi directa. Un agente con memoria almacena interacciones, decisiones y preferencias, y luego recupera lo relevante para la tarea actual. Eso es, en el fondo, RAG aplicado a la historia del propio agente en lugar de a una biblioteca de documentos.

Por eso la memoria útil casi siempre se construye con recuperación, no con reentrenamiento: reentrenar un modelo cada vez que el agente aprende algo nuevo es inviable en costo y latencia. En cambio, escribir esa experiencia en un almacén recuperable es inmediato y reversible.

Algunos principios que aplico al diseñar memoria de agentes:

• Memoria curada, no acumulación. Guarda decisiones, preferencias y contexto operativo reutilizable; no todo el log crudo.
• Recuperación con prioridad. Buenos embeddings, metadata y scoring importan más que tener más datos.
• Higiene de contexto. Si no filtras ruido, da igual cuánto “recuerde” el agente: la ventana se llena de relleno y empeora el foco.
• Fine-tuning solo para lo estable. El estilo del agente y sus protocolos fijos sí pueden ir a los pesos; lo que cambia, a la memoria recuperable.

La consecuencia práctica es clara: en agentes con memoria, RAG es el caballo de batalla y el fine-tuning queda para esa capa fina de comportamiento que no quieres que se mueva.

Conclusión

RAG y fine-tuning no compiten: resuelven problemas distintos. RAG inyecta conocimiento fresco, citable y fácil de actualizar; fine-tuning fija comportamiento, tono y formato. La mayoría de los agentes productivos terminan en algún punto del espectro híbrido, y los que tienen memoria se apoyan casi siempre en recuperación bien diseñada.

El error más caro no es elegir la técnica “equivocada”, sino meter conocimiento volátil dentro de los pesos o intentar arreglar un problema de comportamiento a punta de contexto. Es justo uno de esos errores que encarecen tu stack de IA sin que el equipo lo note hasta la factura. Si separas esas dos preguntas desde el inicio, la arquitectura casi se diseña sola.

En Milytics ayudamos a equipos a tomar exactamente esta decisión con datos: medimos costo, latencia y calidad de respuesta antes de comprometer una arquitectura. Si estás diseñando un agente con memoria y dudas por dónde partir, esa conversación temprana suele ahorrar meses de retrabajo.