RAG vs Fine-Tuning: Cuándo Usar Cada Uno en Proyectos Reales

Todo proyecto de IA eventualmente llega a la misma bifurcación: ¿deberíamos usar retrieval-augmented generation, hacer fine-tuning de un modelo, o combinar ambas? La respuesta nunca es tan simple como sugiere el titular de un blog. Depende de tus datos, tus requisitos de latencia, tu presupuesto, las capacidades de tu equipo y -- lo más importante -- lo que tus usuarios realmente necesitan que el sistema haga. Después de construir decenas de sistemas potenciados por IA para clientes de fintech, energía y gobierno, aprendí que la decisión RAG-versus-fine-tuning no se trata de qué técnica es 'mejor', sino de qué modos de falla podés tolerar.

Esta no es una comparación teórica. Voy a recorrer lo que cada técnica realmente implica a nivel de ingeniería, dónde cada una falla en producción, y cómo tomamos la decisión para proyectos reales de clientes en Xcapit. Al final, vas a tener un framework de decisión práctico que va más allá del 'depende'.

Qué es Realmente RAG

Retrieval-augmented generation suena simple en concepto: en lugar de depender únicamente del conocimiento entrenado del modelo, recuperás documentos relevantes de una base de conocimiento externa y los inyectás en el prompt como contexto. El modelo entonces genera una respuesta fundamentada en esa información recuperada. En la práctica, construir un sistema RAG de nivel productivo involucra un pipeline sorprendentemente complejo con varios componentes que cada uno introduce sus propios modos de falla.

El Pipeline de Recuperación

Un pipeline RAG comienza con la ingesta de documentos. Documentos crudos -- PDFs, páginas web, registros de bases de datos, respuestas de APIs -- son parseados, limpiados y divididos en chunks. La estrategia de chunking es una de las decisiones más subestimadas en la arquitectura RAG. Chunks demasiado pequeños y perdés contexto. Demasiado grandes y desperdiciás espacio valioso de la ventana de contexto en información irrelevante. Típicamente usamos chunking semántico que respeta los límites naturales del documento (secciones, párrafos) con ventanas superpuestas de 100-200 tokens para preservar el contexto entre límites.

Cada chunk se convierte luego en un embedding vectorial -- una representación numérica de alta dimensión de su significado semántico -- usando un modelo de embedding como text-embedding-3-large de OpenAI o alternativas open-source como BGE-M3. Estos embeddings se almacenan en una base de datos vectorial (Pinecone, Qdrant, Weaviate, o pgvector para despliegues más simples). Al momento de la consulta, la pregunta del usuario se embebe usando el mismo modelo y se compara contra los vectores almacenados usando similitud coseno o búsqueda de vecinos más cercanos aproximada.

Reranking y Ensamblado de Contexto

La búsqueda por similitud vectorial sola no es suficiente para calidad de producción. El paso inicial de recuperación típicamente devuelve 20-50 chunks candidatos, muchos de los cuales están tangencialmente relacionados o son redundantes. Un paso de reranking -- usando un modelo cross-encoder como Cohere Rerank o un reranker BGE fine-tuneado -- puntúa cada candidato contra la consulta original con mucha mayor precisión que la similitud vectorial sola. Los 3-8 mejores chunks rerankeados se ensamblan luego en el contexto del prompt, frecuentemente con metadatos como título del documento fuente, fecha y encabezado de sección para habilitar la atribución de fuentes.

Esta recuperación en dos etapas (búsqueda vectorial rápida seguida de reranking preciso) es lo que separa los sistemas RAG de producción de las implementaciones de nivel tutorial. Sin reranking, la calidad de recuperación ronda el 60-70% de relevancia. Con él, podés alcanzar consistentemente 85-95% -- y esa diferencia es la diferencia entre un sistema útil y uno frustrante.

Qué es Realmente el Fine-Tuning

Fine-tuning toma un modelo de lenguaje pre-entrenado y continúa entrenándolo con un dataset curado de ejemplos que demuestran el comportamiento que querés. Los pesos del modelo se ajustan para que inherentemente 'sepa' cómo responder en tu dominio sin necesitar inyección de contexto externo. Pensá en RAG como darle al modelo un libro de referencia para consultar en tiempo de ejecución. Fine-tuning es más como mandar al modelo a la universidad -- el conocimiento se convierte en parte de su razonamiento interno.

Supervised Fine-Tuning y Métodos Parameter-Efficient

El enfoque más común es supervised fine-tuning (SFT), donde proporcionás pares de entrada-salida que demuestran el comportamiento deseado. Para un modelo de soporte al cliente, cada ejemplo podría ser un mensaje del cliente emparejado con una respuesta ideal del agente. Para un modelo de clasificación, cada ejemplo es un documento emparejado con su categoría correcta y puntuación de confianza.

Full fine-tuning -- actualizar todos los parámetros del modelo -- es costoso y arriesga el catastrophic forgetting, donde el modelo pierde capacidades generales mientras aprende las específicas del dominio. Métodos parameter-efficient como LoRA (Low-Rank Adaptation) y su variante cuantizada QLoRA han resuelto en gran medida este problema. LoRA congela los pesos originales del modelo y entrena pequeñas matrices adaptadoras que modifican el comportamiento del modelo. Un modelo de 7 mil millones de parámetros que requiere 28 GB de memoria GPU para full fine-tuning puede ser fine-tuneado con LoRA con 4-8 GB, y los pesos del adaptador típicamente son solo 10-100 MB. Esto hace el fine-tuning accesible en una sola GPU de consumo y práctico para experimentación iterativa.

Cuándo Hacer Fine-Tuning vs. Prompt Engineering

Antes de saltar al fine-tuning, agotá el prompt engineering primero. Si podés lograr el 90% del comportamiento deseado a través de system prompts cuidadosos, ejemplos few-shot y formato de salida estructurado, el fine-tuning agrega complejidad sin beneficio proporcional. Fine-tuning tiene sentido cuando el prompt engineering llega a un techo -- cuando el comportamiento que necesitás es demasiado matizado o demasiado consistente para lograrlo de forma confiable solo con prompting, cuando necesitás reducir los costos de tokens de entrada eliminando system prompts largos y ejemplos few-shot, o cuando necesitás que el modelo siga convenciones específicas del dominio en las que no fue entrenado.

Fortalezas y Debilidades de RAG

Dónde RAG Sobresale

• Información actualizada -- Los sistemas RAG pueden incorporar nuevos datos en minutos agregando documentos al vector store. No hay ciclo de reentrenamiento. Cuando el catálogo de productos de un cliente cambia semanalmente, las regulaciones de compliance se actualizan trimestralmente, o la documentación de soporte evoluciona diariamente, RAG mantiene el sistema actualizado sin tocar el modelo.
• Atribución de fuentes y verificabilidad -- Debido a que los chunks recuperados llevan metadatos, el sistema puede citar documentos específicos, secciones y fechas para cada afirmación que hace. Para industrias reguladas -- compliance fintech, contratos gubernamentales, salud -- esta trazabilidad no es opcional; es un requisito legal.
• Independencia del modelo -- RAG funciona con cualquier LLM. Si necesitás cambiar de Claude a GPT a Llama por razones de costo, capacidad o compliance, todo tu pipeline de recuperación, base de datos vectorial e infraestructura de procesamiento de documentos permanecen sin cambios. Solo el paso de generación se intercambia.
• Sin infraestructura de entrenamiento necesaria -- RAG no requiere clusters de GPU, pipelines de entrenamiento ni ajuste de hiperparámetros. La inversión de ingeniería va hacia el procesamiento de datos, calidad de recuperación y diseño de prompts -- habilidades que son más ampliamente disponibles que la experiencia en entrenamiento de ML.

Dónde RAG Tiene Dificultades

• Cuello de botella en calidad de recuperación -- El sistema es tan bueno como su recuperación. Si el chunk correcto no es recuperado, el modelo no puede generar una respuesta correcta -- sin importar cuán capaz sea el LLM. La búsqueda semántica falla en coincidencias léxicas. La búsqueda por keywords falla en paráfrasis. La búsqueda híbrida ayuda, pero la recuperación sigue siendo el eslabón más débil en la mayoría de los sistemas RAG.
• Sobrecarga de latencia -- Cada consulta requiere generación de embedding, búsqueda vectorial, reranking opcional y ensamblado de contexto antes de que el LLM siquiera comience a generar. Esto agrega 200-800 milisegundos al tiempo de respuesta. Para aplicaciones en tiempo real o procesamiento de alto rendimiento, esta sobrecarga puede ser un deal-breaker.
• Desafíos de chunking -- Documentos con estructuras complejas -- tablas, listas anidadas, referencias cruzadas, razonamiento multi-página -- son notoriamente difíciles de chunkear efectivamente. Un contrato legal donde la cláusula 4.2 referencia definiciones en la cláusula 1.1 no puede ser dividido de forma significativa en chunks independientes sin perder contexto crítico.
• Presión sobre la ventana de contexto -- Incluso con ventanas de contexto grandes (200K+ tokens), meter demasiados chunks recuperados degrada el rendimiento del modelo. El modelo debe razonar sobre contenido recuperado relevante e irrelevante simultáneamente, y la investigación muestra consistentemente que los modelos prestan más atención al principio y al final de su ventana de contexto -- el problema del 'perdido en el medio'.

Fortalezas y Debilidades del Fine-Tuning

Dónde Fine-Tuning Sobresale

• Comportamiento y razonamiento específico del dominio -- Un modelo fine-tuneado internaliza patrones que son difíciles de obtener a través de prompting. Un modelo fine-tuneado en miles de informes de radiología no solo formatea la salida correctamente -- aprende los patrones de razonamiento que usan los radiólogos. Un modelo fine-tuneado en análisis legal desarrolla una comprensión de los matices jurisdiccionales que ningún prompt puede enseñar.
• Estilo y formato consistentes -- Cuando necesitás que cada salida siga una estructura precisa -- esquemas JSON específicos, voz y tono de marca, formato de documentos regulatorios -- el fine-tuning codifica esta consistencia en los pesos del modelo. El formato basado en prompts es frágil; el fine-tuning lo hace confiable.
• Costos de inferencia reducidos -- Los modelos fine-tuneados pueden eliminar la necesidad de system prompts extensos y ejemplos few-shot. Si tu system prompt es de 2,000 tokens y servís 10,000 peticiones por día, fine-tunear esas instrucciones en el modelo ahorra 20 millones de tokens de entrada diarios. A escala, esto representa ahorros de costos significativos.
• Despliegue offline y en el edge -- Los modelos open-source fine-tuneados pueden correr enteramente on-premise o en el edge, sin llamadas a APIs, sin dependencia de internet, y sin datos saliendo de tu infraestructura. Para entornos air-gapped, aplicaciones de defensa, o requisitos de latencia extrema, esta capacidad es irremplazable.

Dónde Fine-Tuning Tiene Dificultades

• Requisitos de datos de entrenamiento -- Fine-tuning de calidad requiere cientos a miles de ejemplos cuidadosamente curados. Estos ejemplos deben ser representativos, diversos y etiquetados con precisión. Crear este dataset es frecuentemente la parte más demandante en tiempo y costo del proceso -- y la calidad de tus datos de entrenamiento pone un techo duro en el rendimiento de tu modelo.
• Catastrophic forgetting -- Incluso con métodos parameter-efficient, el fine-tuning puede causar que el modelo 'olvide' capacidades generales mientras aprende las específicas del dominio. Un modelo fuertemente fine-tuneado en análisis financiero podría perder su capacidad de manejar conversación casual o preguntas de conocimiento general. Balancear especialización con generalidad requiere un diseño cuidadoso del dataset y evaluación.
• Lock-in del modelo -- Cuando hacés fine-tuning de un modelo Llama 3, tus datos de entrenamiento, pipeline de evaluación e infraestructura de despliegue están todos atados a esa arquitectura de modelo. Migrar a un modelo base diferente -- porque se lanza uno mejor, cambian los precios, o necesitás capacidades diferentes -- significa repetir el proceso de fine-tuning desde cero.
• Conocimiento desactualizado -- El conocimiento de un modelo fine-tuneado se congela al momento del entrenamiento. Si tu conocimiento de dominio cambia frecuentemente, el modelo se vuelve progresivamente obsoleto. Reentrenar con nuevos datos es posible pero introduce un ciclo de costos continuo y el riesgo de regresión -- el nuevo modelo podría rendir peor en tareas previamente correctas.

El Framework de Decisión

Después de trabajar esta decisión con decenas de proyectos de clientes, la destilamos en cuatro dimensiones clave. Evaluar tu proyecto contra estas dimensiones te va a orientar hacia RAG, fine-tuning o un enfoque híbrido.

Frescura de los Datos

¿Con qué frecuencia cambia el conocimiento del que depende tu sistema? Si cambia diaria o semanalmente -- catálogos de productos, documentación de soporte, actualizaciones regulatorias -- RAG es el claro ganador porque la nueva información puede indexarse en minutos. Si el conocimiento del dominio es relativamente estable -- procedimientos médicos, análisis de precedentes legales, estándares de ingeniería -- el fine-tuning se vuelve más viable porque el conocimiento internalizado del modelo no se va a desactualizar rápidamente.

Formato de Respuesta y Comportamiento

¿Qué tan estrictos son tus requisitos de salida? Si necesitás esquemas JSON consistentes, plantillas de documentos específicas, o un estilo analítico particular a través de miles de salidas, el fine-tuning codifica esta confiabilidad en el modelo mismo. RAG combinado con prompt engineering puede lograr objetivos de formato, pero el fine-tuning entrega más consistencia a menor costo de inferencia cuando los requisitos de formato no son triviales.

Restricciones de Costo e Infraestructura

RAG requiere infraestructura de base de datos vectorial y agrega latencia, pero evita costos de entrenamiento. Fine-tuning requiere compute GPU para entrenamiento y un equipo más especializado, pero reduce los costos por inferencia a escala. Para equipos sin experiencia en entrenamiento de ML, RAG tiene una barrera de entrada significativamente menor. Para sistemas de producción de alto volumen donde cada token cuenta, el fine-tuning puede entregar mejor economía unitaria.

Requisitos de Latencia y Despliegue

Si necesitás respuestas sub-100 milisegundos, o si el sistema debe funcionar offline o en entornos air-gapped, los modelos fine-tuneados desplegados localmente son tu única opción. RAG inherentemente agrega latencia de red para la recuperación, y requiere conectividad a una base de datos vectorial y una API de LLM. Para la mayoría de las aplicaciones web empresariales donde tiempos de respuesta de 1-3 segundos son aceptables, esto no es una preocupación. Para pipelines de procesamiento en tiempo real o despliegues en el edge, es una restricción dura.

El Enfoque Híbrido: Lo Mejor de Ambos Mundos

En la práctica, los sistemas de IA empresarial más efectivos combinan ambas técnicas. El enfoque híbrido usa fine-tuning para lo que hace mejor -- comportamiento consistente, formato y razonamiento de dominio -- y RAG para lo que hace mejor -- recuperación dinámica de conocimiento y fundamentación con fuentes. Esto no es un ideal teórico. Es la arquitectura que desplegamos con mayor frecuencia para sistemas de clientes en producción.

El patrón funciona así: hacés fine-tuning de un modelo base con ejemplos que le enseñan los patrones de razonamiento de tu dominio, el formato de salida y el estilo de comunicación. Luego usás RAG para proveer a ese modelo fine-tuneado con conocimiento actual y específico en tiempo de consulta. El modelo fine-tuneado sabe cómo razonar sobre tu dominio. El pipeline RAG le dice sobre qué razonar. Ningún componente está haciendo un trabajo para el que el otro está mejor preparado.

Un ejemplo práctico: para un sistema de verificación de compliance, hicimos fine-tuning de un modelo para entender patrones de razonamiento regulatorio -- cómo interpretar 'deberá' versus 'debería' en lenguaje legal, cómo identificar conflictos entre requisitos, cómo estructurar hallazgos de compliance. Pero las regulaciones específicas que se verifican se proveen vía RAG, porque los textos regulatorios se actualizan regularmente y el sistema necesita citar secciones y fechas específicas. El modelo fine-tuneado 'piensa como un analista de compliance'. RAG le da el reglamento vigente sobre el cual pensar.

Ejemplos Reales de Nuestros Proyectos con Clientes

La teoría es útil, pero las decisiones se toman en contexto. Así es como abordamos la decisión RAG-versus-fine-tuning en tres proyectos recientes con clientes.

Automatización de Soporte al Cliente: RAG

Un cliente de fintech necesitaba un sistema de IA para manejar tickets de soporte de primer nivel -- consultas de cuentas, explicaciones de transacciones, preguntas sobre productos. Su base de conocimiento incluía 2,000+ artículos de ayuda, 500+ entradas de FAQ de productos y documentos de políticas internas que se actualizaban semanalmente. Elegimos RAG para este proyecto porque la frescura de datos era crítica (las políticas cambiaban frecuentemente y el sistema necesitaba reflejar actualizaciones en horas), la atribución de fuentes era legalmente requerida (cada respuesta necesitaba citar la política o artículo específico en que se basaba), y el cliente necesitaba flexibilidad de modelo para cambiar de proveedor sin reconstruir el sistema.

El pipeline RAG indexó todo el contenido de la base de conocimiento con chunking semántico y actualizaciones incrementales diarias. El reranking aseguró que los chunks relevantes a políticas rankearan por encima del contenido genérico de FAQ cuando ambos eran relevantes. La calidad de respuesta mejoró del 72% de precisión con RAG naive al 91% después de implementar búsqueda híbrida (vectorial + BM25), reranking, y una capa de filtrado por metadatos que priorizaba documentos recientes.

Pipeline de Clasificación de Documentos: Fine-Tuning

Un cliente del sector energético procesaba miles de presentaciones regulatorias, informes de inspección y documentos de compliance mensualmente. Necesitaban un sistema que pudiera clasificar cada documento en una de 47 categorías, extraer entidades clave (fechas, IDs de instalaciones, tipos de violaciones) y routearlo al departamento correcto -- todo con latencia sub-segundo y precisión de 95%+.

Elegimos fine-tuning porque la taxonomía de clasificación era estable (las categorías no habían cambiado en tres años), los patrones de formato y extracción eran altamente específicos y consistentes, los requisitos de latencia descartaban un paso de recuperación, y el cliente tenía 15,000 documentos etiquetados manualmente para entrenamiento. Hicimos fine-tuning de un modelo Mistral 7B usando QLoRA en el dataset etiquetado. El modelo resultante alcanzó 96.3% de precisión de clasificación y procesó documentos en 180 milisegundos -- 4x más rápido que el prototipo basado en RAG contra el que hicimos benchmark.

Sistema de Verificación de Compliance: Híbrido

Un cliente del sector gobierno necesitaba un sistema para revisar presentaciones de contratistas contra un framework regulatorio complejo que abarcaba requisitos federales, estatales y municipales. El sistema necesitaba identificar brechas de compliance, citar secciones regulatorias específicas y generar informes de hallazgos estructurados siguiendo una plantilla precisa.

Ni RAG ni fine-tuning solos habrían funcionado. RAG solo podía recuperar regulaciones relevantes pero tenía dificultades con el razonamiento multi-hop requerido -- comparar la declaración de un contratista contra el requisito A, que referencia la excepción B, que es modificada por la enmienda reciente C. Fine-tuning solo no podía seguir el ritmo de los cambios regulatorios y no podía proveer las citas de fuentes requeridas para defensa legal. El enfoque híbrido hizo fine-tuning de un modelo con 3,000 revisiones de compliance anotadas para enseñarle patrones de razonamiento regulatorio y el formato de informe de hallazgos del cliente. RAG proveyó el texto regulatorio vigente, indexado con chunking jerárquico que preservaba las relaciones de referencias cruzadas. El resultado fue un sistema que razonaba sobre regulaciones como un experto en compliance mientras siempre fundamentaba su análisis en el texto regulatorio vigente y citable.

Tomando la Decisión Correcta para Tu Proyecto

La decisión RAG-versus-fine-tuning es en última instancia una decisión de ingeniería, no filosófica. Comenzá definiendo claramente tus requisitos a través de las cuatro dimensiones -- frescura de datos, consistencia de salida, restricciones de costo y necesidades de latencia. Prototipá con RAG primero porque es más rápido de construir e iterar. Si llegás a un techo que mejor prompting y optimización de recuperación no pueden superar, evaluá si el fine-tuning aborda la brecha específica. Y mantené las arquitecturas híbridas en tu toolkit para dominios complejos donde ningún enfoque solo es suficiente.

El error más costoso no es elegir la técnica incorrecta. Es comprometerse con una arquitectura sin entender sus limitaciones, para luego descubrir esas limitaciones en producción cuando cambiar de rumbo es 10x más caro. Invertí en prototipado y evaluación antes de comprometerte con una arquitectura de producción, y diseñá tu sistema de modo que los componentes de recuperación y generación puedan evolucionar de forma independiente.

Si estás enfrentando esta decisión en un proyecto actual y querés discutir las ventajas y desventajas con alguien que la ha tomado decenas de veces, contactanos. En Xcapit, ayudamos a equipos a diseñar arquitecturas de IA que coincidan con sus requisitos reales -- no con el último ciclo de hype. Conocé más sobre nuestros servicios de desarrollo de IA en /services/ai-development.