
Modelos ajustados vs RAG para agentes de IA empresariales: cuándo usar cuál
¿Tu agente de IA empresarial debería usar fine-tuning, RAG, o ambos? Esta guía compara ambos enfoques en 10 criterios de decisión, explica cuándo gana cada uno, cubre el patrón híbrido, y detalla los requisitos de preparación de datos para cada camino.
"¿Deberíamos usar RAG o fine-tuning?" es la pregunta más común que hacen los equipos empresariales al construir agentes de IA. También es un planteamiento incorrecto, porque presenta una elección binaria donde la respuesta correcta suele ser "ambos, para diferentes propósitos".
Pero la pregunta persiste porque los dos enfoques son genuinamente diferentes en cómo funcionan, cuánto cuestan y en qué son buenos. Entender los tradeoffs es esencial para cualquier despliegue de agentes empresariales — especialmente on-prem, donde estás tomando decisiones de infraestructura que son más difíciles de revertir que cambiar una API key.
Esta guía compara ambos enfoques cara a cara, proporciona un marco de decisión, y explica el patrón híbrido que la mayoría de los agentes empresariales en producción realmente usan.
Cómo funciona cada enfoque
Generación aumentada por recuperación (RAG)
RAG agrega un paso de recuperación antes de la generación. Cuando un usuario envía una consulta al agente:
- La consulta se convierte en una representación vectorial
- Se busca en el almacén de vectores documentos similares
- Se recuperan los top-k fragmentos más relevantes
- Los fragmentos recuperados se agregan a la ventana de contexto del modelo junto con la consulta
- El modelo genera una respuesta informado por el contenido recuperado
El modelo mismo no aprende de los datos empresariales. Usa los datos dinámicamente en tiempo de inferencia. El conocimiento vive en el almacén de vectores, no en los pesos del modelo.
Fortalezas:
- Funciona con datos que cambian rápidamente — actualiza el almacén de vectores, y la siguiente consulta usa la información nueva
- No se necesita reentrenamiento del modelo cuando los datos cambian
- Atribución de fuentes incorporada — sabes qué documentos usó el modelo
- El acceso a datos puede controlarse por consulta (filtrar por permisos de usuario, departamento, clasificación)
Debilidades:
- La calidad de recuperación varía — fragmentos irrelevantes llevan a respuestas incorrectas
- Los límites de la ventana de contexto restringen cuánta información puede considerar el modelo
- No puede internalizar patrones del dominio — el modelo trata cada consulta independientemente
- Artefactos de fragmentación — la información dividida entre fragmentos puede no capturarse completamente
- Agrega latencia — el paso de recuperación toma 5-50ms dependiendo del tamaño y configuración del almacén de vectores
Fine-Tuning
Fine-tuning entrena al modelo con datos específicos del dominio, modificando los pesos del modelo para internalizar patrones, terminología y reglas de comportamiento.
- Preparar datos de entrenamiento — pares de entrada/salida que demuestran el comportamiento deseado
- Entrenar al modelo con estos datos (típicamente LoRA o QLoRA para eficiencia)
- Los pesos del modelo se actualizan para reflejar los patrones de entrenamiento
- En tiempo de inferencia, el modelo genera desde su conocimiento interno — sin necesidad de recuperación
Fortalezas:
- Comportamiento consistente — el modelo responde de la misma manera a consultas similares cada vez
- Inferencia más rápida — sin paso de recuperación, solo generación
- Funciona sin un almacén de vectores — arquitectura de inferencia más simple
- Internaliza conocimiento del dominio — terminología, formatos, patrones de razonamiento se vuelven parte del modelo
- Mejor para seguir reglas de comportamiento complejas — tono, formato, criterios de decisión
Debilidades:
- El conocimiento se vuelve obsoleto sin reentrenamiento (y reentrenar toma horas a días)
- Sin atribución de fuentes incorporada — el modelo no cita dónde aprendió algo
- Requiere preparación de datos de entrenamiento — ejemplos etiquetados que demuestren el comportamiento correcto
- Riesgo de sobreajuste — muy pocos ejemplos o demasiadas épocas pueden hacer al modelo frágil
- No se puede actualizar fácilmente un solo dato sin reentrenar
El marco de decisión
¿Cuándo debería un agente empresarial usar RAG, fine-tuning, o ambos? Aquí está la tabla de decisión:
| Criterio | RAG | Fine-Tuning | Ambos |
|---|---|---|---|
| Los datos cambian frecuentemente (semanal+) | Mejor opción | Pobre — se desactualiza rápido | RAG para datos, FT para comportamiento |
| El formato de salida debe ser consistente | Inconsistente entre consultas | Mejor opción | FT para formato, RAG para contenido |
| Se necesitan citas de fuentes | Incorporado | No disponible nativamente | RAG para citas |
| Crítico en latencia (menos de 200ms) | Agrega latencia de recuperación | Mejor opción | Depende de la arquitectura |
| Base de conocimiento pequeña (menos de 1,000 docs) | Simple, funciona bien | Excesivo solo para datos | RAG suficiente |
| Base de conocimiento grande (100K+ docs) | La calidad de recuperación se degrada | No cabe en datos de entrenamiento | Ambos necesarios |
| Terminología específica del dominio | Recupera pero puede usar mal los términos | Internaliza la terminología | FT para lenguaje, RAG para datos |
| Consistencia de comportamiento | Varía según el contexto recuperado | Consistente | FT para comportamiento |
| Restricciones de datos sensibles | Se puede excluir del almacén de vectores | En los pesos del modelo permanentemente | RAG para acceso controlado |
| Flujos de trabajo de agentes multi-paso | Funciona pero lento (recuperación por paso) | Tool calling rápido y consistente | FT para tool calling, RAG para conocimiento |
Cuándo RAG es la elección correcta
Conocimiento que cambia rápidamente
Si la información subyacente cambia semanal o mensualmente — bases de datos de medicamentos, orientación regulatoria, información de precios, documentos de políticas — RAG es el único enfoque viable. Ajustar sobre datos que cambian con esta frecuencia significa reentrenamiento continuo, lo cual es costoso y operacionalmente complejo.
Ejemplo: Un agente de cumplimiento que verifica transacciones contra orientación regulatoria actual. Las regulaciones se actualizan trimestralmente. RAG recupera la versión actual. Fine-tuning requeriría reentrenamiento trimestral.
Requisitos de atribución de fuentes
En industrias reguladas, la respuesta del agente debe ser rastreable a documentos fuente específicos. "La política establece X (Fuente: Manual del Empleado v3.2, Sección 4.1, actualizado enero 2026)" es auditable. "La política establece X" (de un modelo ajustado sin cita) no lo es.
RAG inherentemente proporciona esto: el paso de recuperación registra qué documentos se usaron, y se puede instruir al modelo para citarlos.
Conocimiento con control de acceso
Si diferentes usuarios deberían tener acceso a diferente información — políticas específicas por departamento, acceso basado en roles a documentos confidenciales — RAG permite filtrar en tiempo de recuperación. La consulta al almacén de vectores puede incluir filtros de metadatos que limitan la recuperación a documentos a los que el usuario está autorizado a acceder.
Fine-tuning no puede hacer cumplir controles de acceso porque el conocimiento está en los pesos del modelo, accesible para cada usuario que consulte el modelo.
Cuándo fine-tuning es la elección correcta
Formato de salida consistente
Si el agente debe producir salida en un formato específico cada vez — una nota SOAP, un resumen de riesgo de contrato, un informe de incidentes estructurado — fine-tuning es más fiable que RAG. Los requisitos de formato son de comportamiento (cómo escribe el modelo), no factuales (qué información usa). Fine-tuning codifica patrones de comportamiento; RAG no.
Ejemplo: Un agente de documentación clínica que debe producir notas SOAP en la plantilla específica de la instalación. Fine-tuning con 1,000 ejemplos de notas correctamente formateadas enseña al modelo la plantilla. RAG podría recuperar notas de ejemplo, pero el formato de salida del modelo seguirá variando.
Fiabilidad en tool-calling
Para agentes empresariales, tool calling es la capacidad central — el agente necesita llamar a la función correcta con los parámetros correctos. Fine-tuning con más de 500 ejemplos de tool-calling enseña al modelo tus esquemas específicos de herramientas, formatos de parámetros y lógica de decisión. El modelo internaliza cuándo llamar a cada herramienta, qué parámetros usar y cómo manejar casos extremos.
RAG no puede enseñar fiablemente el comportamiento de tool-calling porque tool calling es un patrón de comportamiento, no una búsqueda de conocimiento factual.
| Enfoque | Precisión de tool-calling (herramientas empresariales) |
|---|---|
| Modelo genérico (sin RAG, sin FT) | 40-55% |
| RAG con documentación de herramientas en contexto | 60-75% |
| Ajustado con 200 ejemplos de tool-calling | 80-88% |
| Ajustado con más de 500 ejemplos de tool-calling | 88-95% |
| Ajustado + RAG para parámetros dinámicos | 90-97% |
Terminología y razonamiento del dominio
Si el agente opera en un dominio especializado — legal, médico, financiero, ingeniería — fine-tuning internaliza el vocabulario del dominio, abreviaciones, patrones de razonamiento y convenciones. El modelo no necesita que le digan qué significa "NKDA" o que "efecto material adverso" tiene un significado legal específico — lo sabe por el entrenamiento.
RAG puede recuperar documentos que contienen terminología del dominio, pero el modelo puede seguir malinterpretando o usando mal los términos si no ha sido entrenado con ellos.
Cuándo falla RAG
Hay escenarios empresariales específicos donde RAG funciona mal, incluso con datos bien preparados:
Síntesis compleja multi-documento
Cuando la respuesta requiere sintetizar información de 5-10 documentos diferentes — cada uno contribuyendo una pieza del panorama general — RAG tiene dificultades. El paso de recuperación devuelve fragmentos, pero el modelo debe descifrar cómo se relacionan los fragmentos entre sí. Si la relación no es obvia dentro del texto recuperado, el modelo puede sintetizar incorrectamente.
Ejemplo: Análisis de diligencia debida que requiere conectar un pasivo en un estado financiero con un litigio pendiente en una divulgación de litigios y una cláusula de indemnización relacionada en un acuerdo de adquisición. Tres tipos diferentes de documentos, tres fragmentos diferentes, un análisis conectado. RAG recupera los fragmentos; el modelo puede o no conectarlos correctamente.
Fine-tuning ayuda aquí porque el modelo ha visto ejemplos de este tipo de síntesis multi-documento durante el entrenamiento y ha aprendido el patrón de razonamiento.
Juicio internalizado
Algunas tareas empresariales requieren juicio que no se puede buscar — debe aprenderse de la experiencia. Un revisor de contratos que ha visto 1,000 contratos desarrolla intuición sobre qué cláusulas son estándar versus inusuales. Esa intuición no está en ningún documento; es un patrón aprendido de la exposición.
Fine-tuning codifica este juicio experiencial. RAG no puede, porque no hay documento que recuperar que contenga el juicio en sí.
Cadenas de razonamiento clínico
En salud, el razonamiento clínico a menudo sigue cadenas lógicas largas: síntoma -> diagnóstico diferencial -> pruebas diagnósticas -> reducción del diferencial -> selección de tratamiento. Esta cadena depende de que el clínico mantenga todo el contexto de razonamiento en mente. Fragmentar guías clínicas para RAG interrumpe estas cadenas de razonamiento — el modelo recupera recomendaciones individuales sin el contexto lógico completo.
Fine-tuning con ejemplos completos de razonamiento clínico preserva estas cadenas en los pesos del modelo.
El enfoque híbrido (lo que la mayoría de los agentes en producción usan)
Los agentes empresariales más efectivos combinan ambos enfoques:
Fine-tuning proporciona:
- Lenguaje y terminología del dominio
- Consistencia de formato de salida
- Comportamiento de tool-calling
- Patrones de toma de decisiones
- Reglas de comportamiento (tono, estilo, criterios de escalación)
RAG proporciona:
- Información factual actual
- Citas de fuentes
- Conocimiento con control de acceso
- Datos que se actualizan frecuentemente
- Detalles específicos de políticas y procedimientos
Cómo funciona el híbrido
- El modelo base se ajusta con datos del dominio — ejemplos de tool-calling, ejemplos de formato, ejemplos de comportamiento
- En tiempo de inferencia, el modelo ajustado recibe contexto recuperado del almacén de vectores
- El modelo usa su conocimiento internalizado del dominio para interpretar correctamente el contexto recuperado
- La salida combina comportamiento aprendido (formato, tono, tool calling) con datos actuales (de RAG)
Ejemplo: Un agente de revisión de contratos legales:
- Ajustado con 500 ejemplos de revisión de contratos -> conoce los criterios de riesgo de la firma, lenguaje de cláusulas preferido, y formato de salida
- RAG sobre el playbook de contratos y biblioteca de cláusulas -> recupera los estándares actuales específicos y alternativas aprobadas
- Resultado: análisis consistente, bien formateado que aplica los estándares actuales de la firma con citas de fuentes
Sin fine-tuning, el modelo podría recuperar las secciones correctas del playbook pero aplicarlas inconsistentemente. Sin RAG, el modelo podría aplicar estándares del playbook desactualizados. Juntos, producen salida fiable, actual y bien formateada.
Preparación de datos para cada camino
Ambos caminos comienzan con los mismos documentos empresariales en bruto. La divergencia ocurre en la etapa de preparación.
Pipeline de preparación de datos para RAG
Raw Documents → Parse → Clean → Deduplicate → Chunk (semantic) → Add Metadata → Embed → Index in Vector Store
Métricas clave de calidad:
- Precisión de recuperación (hits@10): Para un conjunto de consultas de prueba, ¿están los documentos fuente correctos en los 10 principales resultados? Objetivo: 85%+
- Relevancia de fragmentos: Para cada fragmento recuperado, ¿realmente contiene la información necesaria para responder la consulta? Objetivo: 70%+
- Tasa de deduplicación: ¿Qué porcentaje de fragmentos duplicados o casi duplicados se eliminaron? Objetivo: mas del 95% de duplicados eliminados
Pipeline de preparación de datos para fine-tuning
Raw Documents → Parse → Clean → Select Training Examples → Label with Domain Experts → Format as Training Pairs → Validate → Train
Métricas clave de calidad:
- Precisión de etiquetado: Para una muestra de ejemplos etiquetados, ¿qué porcentaje es correcto según un segundo revisor? Objetivo: 95%+
- Cobertura: ¿El conjunto de entrenamiento cubre el rango de escenarios que encontrará el agente? Objetivo: 80%+ de escenarios comunes
- Consistencia: Para entradas similares, ¿las etiquetas son consistentes? Objetivo: 90%+ de acuerdo entre etiquetadores
Preparación de datos compartida
Ambos caminos se benefician de la misma preparación upstream:
| Paso | Propósito | Afecta a RAG | Afecta a FT |
|---|---|---|---|
| Análisis de documentos | Extraer texto de formatos fuente | Sí | Sí |
| Limpieza de texto | Eliminar boilerplate, corregir codificación | Sí | Sí |
| Deduplicación | Eliminar contenido redundante | Sí | Sí (evitar entrenar con duplicados) |
| Detección de PII/PHI | Identificar datos sensibles | Sí (redactar o etiquetar) | Sí (redactar antes de entrenar) |
| Extracción de metadatos | Etiquetar con fuente, fecha, tipo | Sí (permite recuperación filtrada) | Sí (permite muestreo estratificado) |
| Puntuación de calidad | Evaluar calidad y completitud del texto | Sí (excluir fragmentos de baja calidad) | Sí (excluir ejemplos de baja calidad) |
Este pipeline compartido es donde herramientas como Ertas Data Suite proporcionan mayor valor — el mismo flujo de preparación de datos alimenta tanto tu base de conocimiento RAG como tu dataset de fine-tuning.
Tomando la decisión
Para la mayoría de los despliegues de agentes empresariales, la respuesta no es "RAG o fine-tuning" sino "fine-tuning para comportamiento, RAG para conocimiento".
Si debes empezar con uno:
- Empieza con RAG si tu necesidad principal es responder preguntas sobre documentos empresariales y tus datos cambian frecuentemente
- Empieza con fine-tuning si tu necesidad principal es tool calling fiable y formato de salida consistente
- Planifica para ambos si estás construyendo un agente de producción que será usado por empleados diariamente
La inversión en infraestructura para despliegue on-prem soporta ambos enfoques. El modelo corre localmente de cualquier manera. El almacén de vectores se necesita para RAG. El pipeline de entrenamiento se necesita para fine-tuning. El pipeline de preparación de datos alimenta ambos.
La pregunta no es qué enfoque usar. La pregunta es qué datos preparar primero.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

Data Preparation for Enterprise AI Agents: Why Your Agent Is Only as Good as Your Data
Everyone talks about agent frameworks — LangChain, CrewAI, AutoGen. Nobody talks about the data layer that feeds them. Data quality is the #1 predictor of agent success or failure. This guide covers the three data types agents need and how to prepare each one.

Building AI Agent Knowledge Bases from Enterprise Documents On-Premise
A step-by-step guide to building RAG knowledge bases from enterprise documents — parsing, cleaning, chunking, embedding, and indexing — entirely on-premise. Covers common mistakes, scale considerations, and audit requirements.

Small Language Models for Enterprise: The On-Premise Fine-Tuning Advantage
Why enterprises are shifting from large foundation models to fine-tuned small language models running on-premise. Cost, latency, data sovereignty, and the fine-tuning workflow that makes it work.