Fine-tuning vs RAG: ¿cuál elegir para tu caso de uso? ?

#¿Por qué esta pregunta vuelve sin cesar?

Has instalado Ollama, elegido un modelo de 7B o 14B y ahora quieres que «conozca» tu dominio: tu documentación interna, el vocabulario profesional, tus resoluciones judiciales, tus tickets de soporte. Se abren dos caminos —fine-tuning o RAG— y la comunidad suele hablar de ellos como si fueran alternativas intercambiables. No lo son.

La trampa: el fine-tuning tiene un aura de "verdadera IA"; uno imagina un modelo que se convierte en experto. El RAG parece una solución improvisada, un "copiar y pegar" automatizado. La realidad industrial es la contraria: el RAG se ha convertido en el estándar para el 80 % de los casos de uso empresarial, y el fine-tuning se reserva para problemas específicos en los que aporta lo que el RAG no puede.

#Los dos enfoques en 1 minuto

#RAG (Generación aumentada por recuperación)

El RAG indexa tus documentos (PDF, Markdown, base de datos, código) en una base vectorial (Chroma, Qdrant, Weaviate). Al hacer una pregunta, el sistema encuentra los pasajes relevantes por similitud semántica, los incluye en el prompt y el LLM genera su respuesta basándose en ellos. El modelo permanece genérico, es el contexto el que se vuelve especializado.

Lo que cambia

El modelo puede citar tus datos, indicar las fuentes de sus respuestas y acceder a conocimientos que no tenía durante el entrenamiento.

Lo que no cambia

Estilo de respuesta, tono, capacidad de razonar en un formato específico, vocabulario técnico muy especializado.

Costo marginal al agregar un documento

Algunos segundos: se indexa el nuevo documento, eso es todo.

#Fine-tuning (LoRA / QLoRA / full)

El fine-tuning reentrena el modelo (o una parte de sus pesos, mediante LoRA) sobre un conjunto de datos de pares entrada/salida representativos de lo que deseas que haga. El conocimiento y el comportamiento se absorben en los pesos del modelo.

Lo que cambia

El comportamiento predeterminado: estilo, formato de salida, convenciones, vocabulario especializado del ámbito profesional, razonamiento implícito.

Lo que no consigue cambiar bien

Acceso a información factual actualizada: un modelo ajustado mediante fine-tuning en marzo con tus procedimientos no sabrá nada de los procedimientos escritos en abril.

Costo marginal al agregar un documento

Un nuevo entrenamiento completo cada vez que el dataset se actualice significativamente.

#Matriz de decisión

En lugar de un 'depende del caso', aquí están los criterios que realmente deciden, línea por línea.

Conocimiento factual que cambia frecuentemente

RAG. El fine-tuning queda obsoleto en cuanto se actualiza el conjunto de datos. Toda documentación de producto, base de tickets, FAQ o jurisprudencia pertenece a esta categoría.

Estilo, tono y formato de salida específico

Fine-tuning. Ninguna cantidad de ejemplos en un prompt sustituye a 500 pares de entrenamiento bien construidos para afianzar un formato JSON estricto, un tono corporativo o una estructura de informe.

Vocabulario profesional extremadamente especializado

Fine-tuning, especialmente si el idioma no está bien cubierto por el preentrenamiento (lenguaje jurídico en francés, lenguaje médico, dialectos). El RAG no basta si el modelo no entiende los términos desde el principio.

Trazabilidad y citación de fuentes

RAG. Puedes mostrar "según el documento X, párrafo Y". Con un modelo fine-tuned, no se puede probar de dónde proviene una afirmación.

Datos ultraconfidenciales, nunca en RAM compartida

Fine-tuning con pesos almacenados localmente. El RAG implica inyectar los pasajes en el contexto en cada consulta — en infraestructura compartida, eso puede plantear problemas.

Respuesta rápida en menos de 200 ms (chatbot, agente inline)

Fine-tuning. El RAG añade 100-500 ms de recuperación más un contexto más largo que procesar. En aplicaciones críticas en tiempo real, eso pesa.

Volumen de conocimiento enorme (> 100k páginas)

RAG. No es razonable hacer un ajuste fino con 100k documentos y, aunque lo hicieras, el modelo alucinaría con los detalles.

Dataset de entrenamiento de calidad disponible

Si no tienes al menos 500-1000 pares de entrada/salida limpios, el fine-tuning hará más daño que bien al modelo. Empieza con RAG.

#5 casos de uso típicos

#1. Chatbot de soporte basado en la documentación del producto

Veredicto

RAG, sin dudarlo.

Por qué

La documentación cambia constantemente (nuevas funciones, correcciones, funciones declaradas obsoletas). Un modelo ajustado mediante fine-tuning quedaría obsoleto en 3 semanas, y el cliente quiere una respuesta respaldada por fuentes ("ver sección X del manual"), no una afirmación opaca.

Pila típica

Ollama (Qwen 3.5 9B para caber en 8 GB, o Mistral Small 24B en 16 GB para un francés más cuidado) + Qdrant/Chroma + nomic-embed-text + Open WebUI o AnythingLLM.

#2. Extractor de información estructurada (facturas, CV, contratos)

Veredicto

Fine-tuning, o prompting avanzado con modo JSON.

Por qué

El formato de salida debe ser estrictamente el mismo cada vez (mismos campos, mismo tipado, mismos valores por defecto). Incluso un prompt bien escrito se desvía en un 5 % de los casos, lo que rompe un pipeline. Un LoRA con 800 ejemplos anotados resuelve esto definitivamente.

Pila típica

Unsloth o Axolotl para entrenar, exportación a GGUF, despliegue en Ollama. Si la base de «conocimiento» sobre los tipos de documentos evoluciona, se puede combinar con un RAG ligero.

#3. Asistente jurídico basado en jurisprudencia francesa

Veredicto

Híbrido — primero RAG y después fine-tuning si el dominio del vocabulario sigue siendo insuficiente.

Por qué

El corpus de jurisprudencia es gigantesco y cambia cada mes (RAG obligatorio para mantener actualizada la información de sentencias). Pero el vocabulario jurídico francés está mal cubierto por la mayoría de los modelos de peso abierto, y un fine-tune ligero (LoRA con 2 a 3000 ejemplos de preguntas o respuestas jurídicas) mejora significativamente la comprensión de los términos antes de que el RAG entre en juego.

Pila típica

Légifrance/Doctrine como fuentes → Qdrant + reranker BGE → LLM de 14B ajustado con LoRA a la jerga jurídica francesa.

#4. Generador de código adaptado a una base de código interna

Veredicto

RAG (lectura de archivos del repositorio), no se hace fine-tuning salvo en casos muy particulares.

Por qué

Una base de código evoluciona cada día. Un fine-tune quedaría obsoleto en cada sprint. Los mejores asistentes de código (Continue.dev, Aider) leen dinámicamente los archivos pertinentes mediante RAG sobre el AST o los embeddings de código.

Pila típica

Continue.dev + Qwen3-Coder 30B-A3B (qwen3-coder:30b, MoE con 256k de contexto y 3B activos, por lo que es rápido) o Devstral 24B a través de Ollama, con recuperación integrada en el plugin.

#5. Estilo editorial propio (boletines, informes, fichas de producto)

Veredicto

Fine-tuning puro.

Por qué

El contenido es nuevo cada vez (no hay nada que «recuperar»), pero el tono, la estructura, el ritmo de las frases, el uso de «usted» y de subtítulos deben ser absolutamente coherentes. Eso es precisamente lo que el fine-tuning codifica bien.

Pila típica

200-500 artículos bien redactados → formato Alpaca o ChatML → QLoRA sobre Qwen 3.5 9B con Unsloth → exportación GGUF, modelfile Ollama con prompt de sistema complementario.

#Los costos ocultos de ambos enfoques

Las comparativas públicas suelen limitarse al «precio de una GPU para 4 horas de entrenamiento». La realidad operativa es más dura en ambos casos.

#Costos ocultos del RAG

Calidad del chunking

La división de los documentos en fragmentos condiciona todo. Si se hace mal, la recuperación devuelve fragmentos fuera de contexto, el LLM alucina y nadie entiende por qué. Rara vez basta con «poner los PDF en Chroma»: a menudo hace falta dividirlos por secciones y, a veces, aplicar un preprocesamiento OCR a los documentos escaneados.

Latencia acumulada

Embedding de la consulta + búsqueda vectorial + (opcional) reranker + contexto ampliado para el LLM. En una configuración mal optimizada, se puede pasar de 400 ms (LLM solo) a 2-3 s (RAG completo). Prever esta latencia desde la fase de diseño.

Mantenimiento de la base

Cuando un documento se elimina o actualiza, hay que retirarlo o volver a indexarlo. Para las fuentes externas (web, API), prever una tarea de actualización. Cuanto más tiempo esté en funcionamiento el conjunto de tecnologías, más trabajo supone.

Calidad del modelo de embeddings

Para el francés, los embeddings por defecto (como text-embedding-ada) son mediocres. nomic-embed-text, BGE-M3 o Solon hacen la diferencia — pero eso significa conocer las opciones.

#Costos ocultos del fine-tuning

Preparación del conjunto de datos

Es el 80 % del trabajo. Recopilar, limpiar, formatear en pares instrucción/respuesta, eliminar duplicados, equilibrar las clases. Para un proyecto de fine-tuning de 4 semanas, prevé 3 semanas de preparación de datos y 1 semana de entrenamiento.

Riesgo de regresión

Un fine-tune mal calibrado deteriora las capacidades generales del modelo (el "catastrophic forgetting"). El modelo se vuelve bueno en tu tarea y muy malo en todo lo demás. Hay que probarlo en un benchmark genérico antes y después.

Reentrenamiento en cada actualización

El conjunto de datos se enriquece con el tiempo. Cada versión requiere volver a ejecutar entre 2 y 12 horas de cómputo en GPU, volver a validar y volver a desplegar. Llevar un control de versiones de los conjuntos de datos y los checkpoints se vuelve obligatorio.

Hardware de entrenamiento

Ejecutar la inferencia de un 7B Q4 requiere 5 GB de VRAM, pero entrenarlo (incluso con QLoRA) requiere un mínimo de 12–16 GB. El fine-tuning exige más recursos de hardware como punto de partida que la inferencia.

#Enfoque híbrido: RAG + fine-tuning

Las arquitecturas más eficaces no eligen: combinan. El fine-tuning define cómo habla el modelo de tu ámbito, y el RAG le da acceso a lo que debe saber en el momento T.

Fine-tuning del estilo y el formato

200-1000 ejemplos que fijan el tono (corporativo, técnico, jurídico), el formato de respuesta (JSON, Markdown estructurado) y la postura (siempre citar la fuente, nunca inventar).

RAG sobre conocimiento factual

Documentación, base de tickets, jurisprudencia, código fuente — todo lo que cambia y que debe ser recuperable y citable.

Mecanismos de seguridad en el prompt de sistema

El prompt del sistema recuerda al modelo que debe negarse a responder si el contexto RAG está vacío o es contradictorio. Imprescindible para limitar las alucinaciones.

#Decisión rápida en 3 preguntas

1. 01
   Pregunta 1 — ¿Tus datos cambian más de una vez al mes?

   Si es así: RAG obligatorio. El fine-tuning no puede seguir el ritmo sin convertirse en una pesadilla operativa.
2. 02
   Pregunta 2 — ¿Tienes al menos 500 pares de entrada/salida de calidad, verificados por personas?

   Si no: empieza con RAG. El fine-tuning con 100 ejemplos improvisados degrada el modelo. Si tienes previsto acumular ejemplos, implementa primero el RAG y aprovecha sus logs para construir el dataset.
3. 03
   Pregunta 3 — ¿El problema es "saber algo" o "responder de cierta manera"?

   Saber → RAG. Responder de una determinada manera → fine-tuning. Ambas cosas → híbrido. Es el criterio más sencillo y acierta 9 de cada 10 veces.

#Errores comunes que conviene evitar

"Ajustar un modelo mediante fine-tuning para aprender hechos"

El error más frecuente. Un modelo ajustado mediante fine-tuning no es una base de conocimientos: interpola a partir de los ejemplos vistos, pero alucina detalles precisos (cifras, fechas, referencias) mucho más que un RAG.

«RAG sin reranker» en corpus de más de 10k chunks

La búsqueda vectorial por sí sola recupera muchos resultados, pero no siempre los más pertinentes. Un reranker de tipo cross-encoder (BGE, mxbai) aplicado a los 20 primeros resultados transforma la calidad, con un coste adicional de 50-100 ms.

Confundir RAG y contexto largo

"Voy a poner todo el documento en el prompt". Más allá de 8k tokens útiles, la calidad cae drásticamente (pérdida en el medio, "lost in the middle"). Un RAG bien troceado supera a un contexto largo ingenuo a partir de cierto volumen.

Hacer fine-tuning de un modelo ya alineado con un conjunto de datos no alineado

Si haces fine-tuning de un modelo "instruct" con ejemplos que no tienen la misma estructura de prompt, rompes el alineamiento y el modelo se comporta de forma extraña. Respetar siempre la plantilla del modelo (ChatML, Alpaca, Mistral, Llama-3 chat).

Querer un benchmark público para decidir

Ningún benchmark genérico dirá si para TU caso funciona mejor el RAG o el fine-tuning. Prepara una evaluación interna con 30-50 preguntas representativas y mide antes de pasar a producción a escala.

#Para ir más allá

Una vez tomada la decisión, las guías correspondientes cubren la implementación concreta, con sus posibles dificultades y optimizaciones.

Implementación de RAG sin programar

Open WebUI o AnythingLLM permiten montar un RAG documental en unas horas, sin escribir Python — útil para validar el enfoque antes de industrializar.

Fine-tuning local LoRA / QLoRA

La guía específica cubre Unsloth, el formato del conjunto de datos, la elección entre LoRA y QLoRA y la exportación a GGUF para Ollama. Una RTX 3090 basta para un 7B.

Optimizar un RAG existente

Reranker, búsqueda híbrida BM25 + vectorial, estrategias de chunking — tres ejes que transforman un RAG "que funciona" en un RAG de producción.