RAG o fine-tuning: cómo hacer que la IA conozca los datos de tu empresa

El modelo no conoce tu empresa

Un modelo de lenguaje sabe redactar, resumir y razonar sobre casi cualquier tema. Pero no ha leído tus contratos ni tus procedimientos, ni sabe qué cambió la semana pasada. Si le preguntas por tu política de devoluciones, o no lo sabe o, peor, se inventa una respuesta convincente.

Para que la IA trabaje con los datos de tu empresa hay dos técnicas de las que todo el mundo habla: RAG y fine-tuning. Se presentan como rivales, pero resuelven problemas distintos, y elegir mal sale caro.

En esta guía de RAG vs fine-tuning te explicamos qué hace cada técnica, qué alternativas hay, cuándo conviene cada una y dónde debería correr el modelo. Es el razonamiento que seguimos al diseñar asistentes de IA con tus documentos.

Qué es RAG

RAG (retrieval-augmented generation, generación aumentada por recuperación) separa dos trabajos. Primero, un buscador localiza en tus documentos los fragmentos que responden a la pregunta. Después, el modelo redacta la respuesta a partir de esos fragmentos, no de memoria.

El modelo no aprende nada nuevo: lee lo que le pasas en cada consulta, como un experto al que le das la carpeta justa antes de preguntarle. De ahí salen sus ventajas:

• Actualización inmediata. Cambias un documento, se reindexa y la siguiente respuesta ya usa la versión nueva, sin reentrenar nada.
• Citas. Cada respuesta puede indicar el documento y el apartado de donde sale, para que cualquiera la compruebe.
• Permisos. El filtro se aplica en la búsqueda: lo que un usuario no puede ver nunca llega al modelo.
• Saber decir «no lo sé». Si la búsqueda no encuentra nada relevante, el sistema lo reconoce en lugar de rellenar el hueco.

Su límite: depende de encontrar el fragmento correcto. Con documentos desordenados o mal troceados, la respuesta será mala aunque el modelo sea excelente. Cómo montarlo bien lo contamos en nuestra guía de RAG para empresas.

Qué es el fine-tuning

El fine-tuning, o ajuste fino, parte de un modelo ya entrenado y lo sigue entrenando con ejemplos tuyos. Eso modifica sus pesos, los parámetros internos que determinan cómo responde. El resultado es un modelo nuevo: tu versión.

Funciona bien para cambiar cómo responde el modelo:

• Estilo y tono. Que redacte como tu equipo, con tu registro y tus fórmulas.
• Formato. Que devuelva siempre la misma estructura, como un informe con secciones fijas o un JSON con campos concretos.
• Tareas concretas y repetitivas. Clasificar incidencias según tu taxonomía o extraer campos de un tipo de documento.
• Vocabulario de dominio. Terminología técnica, siglas internas o jerga del sector que el modelo base interpreta mal.

Y aquí está el malentendido más común: el fine-tuning no es la vía para meter conocimiento que cambia. Un modelo ajustado con las condiciones comerciales de este año seguirá «recordándolas» el año que viene. No puede decirte de qué documento sale un dato ni distinguir qué puede ver cada usuario: lo aprendido queda dentro del modelo para todos. Y cuando recuerda algo a medias, lo reconstruye con total seguridad.

Además, exige muchos ejemplos de entrada y salida correctos y revisados. Si no los tienes, hay que construirlos antes de entrenar.

Antes de elegir: las opciones más sencillas

No todo proyecto necesita RAG ni fine-tuning. Antes conviene descartar lo simple.

Un buen prompt con contexto

Si la información cabe en unas pocas páginas y cambia poco (las condiciones generales, un catálogo pequeño, las instrucciones de un proceso), basta con incluirla en las instrucciones del sistema. Es lo primero que hay que probar: fija el nivel contra el que comparar lo demás.

Contextos largos

Los modelos actuales admiten contextos muy amplios: puedes pasarles documentos enteros en una sola petición. Para analizar un contrato concreto, suele ser lo más directo.

Pero tiene límites. Cuanto más texto envías, más cuesta y más tarda cada petición. Un dato enterrado en mitad de un documento enorme se puede pasar por alto. Y no resuelve permisos ni citas. Para una base documental grande y viva, hay que buscar antes de responder.

Cacheo de prompts

Cuando una parte grande del contexto se repite en cada petición (las instrucciones, un manual, el catálogo), muchos proveedores permiten cachearla: se procesa una vez y se reutiliza, lo que reduce coste y latencia. Con contextos largos, hace viable enviar un corpus estable y pequeño en cada consulta.

RAG vs fine-tuning: cuándo conviene cada uno

Elige RAG cuando

• La respuesta está escrita en tus documentos: «qué dice», «cuál es», «dónde está».
• El contenido cambia: condiciones, políticas, procedimientos, stock, normativa.
• Necesitas citar la fuente o auditar de dónde sale cada respuesta.
• Distintos usuarios pueden ver cosas distintas.

Es el caso de un asistente interno o un chatbot de soporte con tu base de conocimiento. Por eso nuestros asistentes de IA con tus documentos parten siempre de RAG.

Elige fine-tuning cuando

• El problema es la forma, no el contenido: el modelo sabe qué decir, pero no lo dice como necesitas.
• Tienes una tarea muy repetida y acotada, con muchos ejemplos buenos ya resueltos por tu equipo.
• Quieres que un modelo pequeño haga bien una tarea para la que hoy necesitas uno grande.

Combínalos cuando

El contenido viene de tus documentos y la forma tiene que ser muy precisa: un asistente de servicio técnico que responde con los manuales (RAG) y redacta siempre en el formato de parte de intervención de la empresa (fine-tuning). El orden razonable es primero RAG con buenas instrucciones y, si al evaluarlo el formato sigue fallando, fine-tuning. Al revés casi nunca compensa.

Tabla comparativa

Dónde corre el modelo: API de proveedor o infraestructura propia

Esta decisión es independiente de la anterior, pero se toma a la vez. Hay dos grandes opciones: la API de un proveedor como OpenAI, Anthropic o Google, directa o a través de una nube con regiones en la UE; o modelos abiertos alojados en infraestructura propia, bajo tu control.

Para la mayoría de empresas, la API de un proveedor con no retención y procesamiento en la UE es el punto de partida razonable. La infraestructura propia tiene sentido con datos especialmente sensibles, cuando un contrato o una norma lo exige, o con un volumen alto y estable que mantenga las máquinas ocupadas. Y caben arquitecturas mixtas: un modelo pequeño propio para anonimizar y uno de proveedor para lo más exigente.

Privacidad y RGPD

Con cualquiera de las dos técnicas, tus datos viajan hacia un modelo. Ten claras cuatro cosas.

Qué se envía. En RAG viajan la pregunta y los fragmentos recuperados, no toda tu base documental. Aplica minimización: no indexes ni envíes datos personales que no aporten a la respuesta.

Qué hace el proveedor con ello. Comprueba que el contrato excluya el uso de tus datos para entrenar sus modelos, que la retención sea nula o limitada y que haya un contrato de encargo de tratamiento. Las versiones gratuitas para consumo no siempre lo garantizan.

Dónde se procesa. Prioriza el procesamiento en la UE. Si hay transferencias internacionales, deben tener cobertura legal y estar documentadas.

Datos de entrenamiento. Aquí el fine-tuning tiene una desventaja seria: si entrenas con datos personales, quedan incorporados en los pesos del modelo. Atender una solicitud de supresión ya no es borrar un registro y puede obligar a reentrenar. En RAG basta con eliminar el documento de la fuente y del índice. Para fine-tuning, usa ejemplos anonimizados o seudonimizados siempre que puedas.

Cómo evaluarlo antes de decidir

El dilema RAG vs fine-tuning se resuelve con datos, no con opiniones:

1. Reúne preguntas o tareas reales, con la respuesta correcta validada por quien conoce el tema, incluidas algunas cuya respuesta no está en los documentos.
2. Mide la línea base con la opción más simple: un buen prompt con contexto.
3. Prueba RAG y mide por separado la búsqueda (¿encontró el fragmento correcto?) y la respuesta (¿es fiel?, ¿cita bien?, ¿dice «no lo sé» cuando toca?).
4. Prueba fine-tuning solo si fallan la forma o la tarea, sobre el mismo conjunto, y compara.
5. Repite la evaluación con cada cambio de documentos, instrucciones o modelo.

Separar búsqueda y respuesta es clave: si la búsqueda falla, ningún ajuste del modelo lo arreglará. Cómo mantener la evaluación en el tiempo lo explicamos en por qué integrar LLMs en producción no es instalar ChatGPT.

Errores comunes

• Entrenar el modelo con los documentos para que «se los sepa». El modelo aprende el estilo de tus documentos, no a recitarlos con exactitud, y no podrá decir de dónde saca cada dato.
• Empezar por el fine-tuning. Es lo más costoso de preparar y de mantener. Casi siempre conviene agotar antes el prompt y RAG.
• Juzgar por la demo. Unas pocas preguntas elegidas a mano no dicen nada. Hace falta evaluar con casos reales.
• Olvidar los permisos. Un asistente que responde a cualquiera con información de nóminas es una fuga de datos bien redactada.

Preguntas frecuentes

¿Qué es mejor, RAG o fine-tuning?

Depende del problema. Si quieres que la IA responda con información de tu empresa que cambia y se puede verificar, RAG. Si quieres que escriba con un estilo, un formato o un vocabulario concretos, o que haga muy bien una tarea repetitiva, fine-tuning. Para un asistente con documentos de empresa, RAG es casi siempre el punto de partida.

¿Se puede entrenar ChatGPT con los documentos de mi empresa?

Algunos proveedores permiten hacer fine-tuning de sus modelos, pero no es la forma de que respondan con tus documentos: no los recordarán con exactitud, no citarán la fuente y quedarán desactualizados en cuanto cambie algo. Para eso está RAG.

Con contextos tan largos, ¿sigue haciendo falta RAG?

Para pocos documentos estables, a veces no: basta con enviarlos en cada petición, mejor con cacheo de prompts. Para una base documental grande, que cambia y con permisos distintos por usuario, sí.

¿Mis datos se usan para entrenar los modelos del proveedor?

Depende del contrato. Las ofertas empresariales suelen excluirlo y permiten acordar no retención y procesamiento en la UE; revísalo y déjalo por escrito. Si los datos son muy sensibles, un modelo abierto en tu infraestructura evita que salgan de tu perímetro.

Siguiente paso: un diagnóstico antes de elegir técnica

Primero conviene tener claro qué problema quieres resolver, con qué datos y con qué exigencias de privacidad. Es lo que revisamos en nuestro diagnóstico de IA gratuito: analizamos contigo tus casos de uso y tus fuentes, y te decimos con franqueza qué enfoque tiene sentido o si todavía no es el momento. Si buscas que tu equipo encuentre respuestas en su documentación, mira cómo desarrollamos asistentes de IA con tus documentos; el resto está en nuestros servicios de inteligencia artificial.