Alguien te propone «entrenar un modelo con tus datos» y suena a hacer la IA por fin tuya, a medida, imbatible. Suena caro, y por eso suena serio. Antes de firmarlo conviene saber que en la inmensa mayoría de los casos de empresa estás a punto de pagar la solución cara para un problema que resuelve mejor la barata. La decisión de fondo se llama RAG o fine-tuning, y casi siempre la respuesta correcta es RAG. Aquí está por qué, sin humo.
RAG vs fine-tuning en una empresa: qué hace cada uno
Son dos cosas distintas que la jerga mezcla a propósito. RAG (retrieval-augmented generation) no toca el modelo: le da una biblioteca. Cuando llega una pregunta, el sistema busca en tus documentos los fragmentos relevantes y se los pasa al modelo junto con la pregunta, para que responda con tu información delante. El conocimiento vive fuera del modelo, en una base que puedes actualizar en cualquier momento.
Fine-tuning es lo contrario: coges un modelo base y lo reentrenas con miles de ejemplos para que ajuste sus pesos internos. No le das una biblioteca; le cambias los reflejos. Sirve para enseñarle un formato, un tono o un tipo de tarea muy repetitivo —no para meterle datos que cambian. Y ahí empieza la confusión que cuesta dinero: casi todo el mundo que pide fine-tuning en realidad quiere que la IA «sepa lo suyo», que es justo lo que RAG hace mejor.
| Dimensión | RAG | Fine-tuning |
|---|---|---|
| Qué cambia | El contexto que recibe el modelo | Los pesos internos del modelo |
| Para qué sirve | Que responda con TU conocimiento | Que adopte un formato/tono/tarea fija |
| Actualizar un dato | Editas un documento, listo | Reentrenar el modelo entero |
| Coste de arranque | Bajo | Alto (datos etiquetados + cómputo) |
| Trazabilidad | Cita la fuente que usó | Caja negra: no sabes de dónde salió |
| Riesgo típico | Recuperación mal montada | Alucinar con confianza y datos viejos |
Por qué te van a vender fine-tuning (y por qué casi nunca lo necesitas)
Fine-tuning se vende bien por tres razones, y ninguna es que sea lo que te conviene. Primera: suena a medida —«un modelo entrenado con tus datos» es una frase que cierra reuniones—. Segunda: es más caro, y en consultoría lo caro se confunde con lo bueno. Tercera: cuesta de deshacer, así que ata al cliente. El problema es que resuelve el problema equivocado: la empresa no necesita un modelo con otra personalidad, necesita uno que responda con la información correcta y actual. Eso es un problema de recuperación, no de reentrenamiento.
La prueba está en la vida útil del dato. Tu política de vacaciones, tu catálogo, tus precios y tus procedimientos cambian. Si los metes por fine-tuning, cada cambio pide un reentrenamiento —y hasta que llega, el modelo afirma con total aplomo la versión vieja. Con RAG editas el documento y en la siguiente pregunta ya responde con lo nuevo, citando de dónde lo sacó. Para conocimiento vivo, reentrenar es como imprimir la Wikipedia cada mañana.
Cuándo SÍ es fine-tuning
No es que fine-tuning no sirva nunca. Sirve, pero para un conjunto de casos estrecho y bastante identificable:
- Necesitas un formato de salida muy rígido y repetitivo que el prompting no logra estabilizar (por ejemplo, clasificar en un esquema propio con miles de ejemplos).
- Buscas un tono o estilo muy específico y constante, no un dato: enseñarle a escribir «como tu marca» cuando el system prompt ya no da más de sí.
- Tienes una tarea de altísimo volumen donde recortar tokens de contexto en cada llamada compensa el coste de entrenar.
- Y —clave— ese comportamiento que le enseñas NO cambia cada semana. Si cambia, vuelves a RAG.
Fíjate en el patrón: fine-tuning es para enseñar una habilidad estable, no para inyectar conocimiento cambiante. En cuanto lo que quieres que «sepa» tiene fecha de caducidad, la respuesta vuelve a ser RAG. Y en una empresa real, casi todo lo que quieres que sepa tiene fecha de caducidad.
El 90% de los casos de empresa: por qué gana RAG
Para la pregunta que de verdad se hace una empresa —«que la IA responda con lo nuestro, actualizado y sin inventar»— RAG gana en las tres cosas que importan: cuesta menos arrancar, se actualiza editando un documento y, sobre todo, cita la fuente, así que puedes auditar de dónde salió cada respuesta. Un agente serio en 2026 casi siempre es un buen sistema de RAG con evals que miden si responde bien, no un modelo reentrenado. Lo contamos en detalle en la guía de cómo entrenar un agente IA: datos, evals y governance, y en la de crear un chatbot de IA que use tu base de conocimiento, donde la arquitectura RAG se ve paso a paso.
La otra ventaja de RAG es que el fracaso es barato y visible. Si la IA responde mal, casi siempre es porque la recuperación trajo el fragmento equivocado —y eso se arregla mejorando cómo indexas y buscas, no reentrenando nada. Con fine-tuning, cuando falla, tienes una caja negra cara y un ciclo de corrección de días. Montar la capa de recuperación bien —qué documentos, cómo se trocean, cómo se busca, qué se registra— es infraestructura, y es donde se gana o se pierde el proyecto: lo tratamos como tal en el servicio de infraestructura de IA empresarial.
El error caro: fine-tunear para «meter conocimiento»
Si te quedas con una sola idea, que sea esta: fine-tuning cambia cómo habla el modelo, no lo que sabe de forma fiable. Usarlo para inyectar datos es el error más común y el más caro, porque el modelo aprende a sonar como tus documentos sin garantizar que reproduzca sus hechos —y lo hace sin citar, así que ni te enteras de cuándo se equivoca. Empieza siempre por RAG. Llega a fine-tuning solo si, con la recuperación ya bien montada, te queda un problema real de formato o estilo que el contexto no resuelve. En ese orden gastas en lo que hace falta, cuando hace falta.