Alguien lo dice en cada arranque de proyecto: "¿No podemos simplemente hacerle fine-tuning al modelo con nuestros documentos?" Suena decidido. Suena a tomar control. Casi siempre es la jugada equivocada.
El debate de RAG vs fine-tuning se plantea como una elección de tecnología. No lo es. Es una pregunta sobre qué estás intentando arreglar en realidad. Si te equivocas ahí, vas a gastar seis cifras enseñándole a un modelo a sonar seguro sobre hechos que no puede recordar de forma confiable. Si aciertas, la respuesta es aburrida, más barata, y funciona.
Qué hace cada uno en realidad
El fine-tuning cambia cómo se comporta un modelo. Le muestras miles de ejemplos y aprende un patrón: este tono, este formato de salida, esta forma de razonar una tarea, esta estructura JSON cada vez. Graba el comportamiento en los pesos. Lo que no hace bien es almacenar hechos que puedas consultar después. Los hechos quedan repartidos entre los parámetros, recordados a medias, imposibles de citar, y desactualizados en el momento en que tus datos cambian.
RAG —generación aumentada por recuperación— deja el modelo en paz y cambia lo que lee. En el momento de la consulta recuperas los documentos relevantes de tus propios sistemas y se los entregas al modelo como contexto. El modelo razona sobre un texto que puede ver ahora mismo. Tu conocimiento vive en una base de datos que tú controlas, no en pesos congelados.
Así que la división real es simple. El fine-tuning es para el comportamiento. RAG es para el conocimiento. "Hazle fine-tuning a nuestros documentos" intenta usar una herramienta de comportamiento para resolver un problema de conocimiento. Ese es el error.
Por qué RAG gana para el conocimiento del negocio
El conocimiento del negocio tiene cuatro propiedades que el fine-tuning maneja mal, y que RAG maneja por diseño.
Cambia. Precios, políticas, especificaciones de producto, el organigrama, los números del último trimestre: todo en movimiento. RAG toma la versión nueva en el momento en que actualizas la fuente. El fine-tuning exige un ciclo de reentrenamiento por cada cambio material, cosa que nadie ejecuta de verdad de forma regular.
Necesita citas. Cuando un modelo le dice a tu equipo de ventas cuál es una cláusula de contrato, necesitan ver qué cláusula y qué documento. RAG devuelve la fuente junto con la respuesta. Un modelo con fine-tuning te da una frase segura y ningún comprobante.
Necesita control de acceso. No todos deberían poder recuperar todo. RAG ejecuta la recuperación a través de tus permisos existentes, así que el modelo solo puede fundamentar su respuesta en lo que ese usuario tiene permitido ver. El fine-tuning graba los datos de entrenamiento en un único conjunto de pesos que ignora quién pregunta: un riesgo real de fuga de datos.
Necesita ser correcto. Un modelo que recuerda un hecho desde sus pesos, cuando duda, inventa una respuesta plausible. Dale el pasaje real y dile que responda solo desde ese pasaje, y las alucinaciones caen de golpe. Convertiste una prueba de memoria a libro cerrado en una tarea de lectura, en la que los modelos son mucho mejores.
La realidad del costo y el mantenimiento
Las cuentas de servilleta favorecen al fine-tuning hasta que lo ejecutas de verdad.
El fine-tuning tiene un costo inicial fácil de subestimar: curar un conjunto de entrenamiento limpio, correr el trabajo, evaluarlo y —la parte que la gente olvida— rehacer todo eso cada vez que el conocimiento subyacente cambia. Tu costo no es la corrida de entrenamiento. Es la cinta sin fin del reentrenamiento y el trabajo de evaluación para probar que cada versión nueva no empeoró nada.
RAG carga por adelantado un trabajo distinto: llevar tus documentos a un estado recuperable, fragmentarlos con sentido, mantener el índice sincronizado. Pero una vez que ese pipeline existe, el conocimiento nuevo son solo documentos nuevos. Sin reentrenamiento, sin la carrera de obstáculos de evaluación, sin riesgo de modelo. Actualizas una fuente y el sistema lo sabe.
Para la mayoría de los negocios el tradeoff honesto es este: RAG tiene un costo mayor de disciplina de ingeniería y un costo continuo menor. El fine-tuning parece barato por corrida y se vuelve caro precisamente porque tu conocimiento no se queda quieto.
Cuándo el fine-tuning se gana su lugar
Esto no es absolutismo de RAG. El fine-tuning es la herramienta correcta para problemas reales; simplemente no son problemas de conocimiento.
Recurre a él cuando necesitas un formato de salida consistente que el prompting no logra imponer de forma confiable. Cuando necesitas una voz o estilo de casa específico a escala. Cuando estás comprimiendo un prompt largo y elaborado dentro de los pesos para reducir la latencia y el costo por llamada. Cuando la tarea es una clasificación o extracción estrecha y repetida donde un modelo más pequeño con fine-tuning le gana a uno grande y general en velocidad y precio. Cuando necesitas razonamiento en un dominio especializado donde el estilo por defecto del modelo base sigue fallando.
Fíjate en el patrón: formato, tono, latencia, comportamiento. Ninguno de estos es "conoce nuestros hechos".
Combínalos — en ese orden
Los sistemas más fuertes usan ambos, y el orden importa. Hazle fine-tuning al modelo para cómo comportarse: tu formato, tu tono, tus pasos de razonamiento, tus reglas de rechazo. Usa RAG para qué es verdad: los hechos vivos en los que fundamenta cada respuesta.
Un asistente de soporte es el ejemplo limpio. Hazle fine-tuning para que cada respuesta siga tu estructura de escalamiento y tu voz de marca. Usa RAG para que la política específica que cita sea la política de hoy, extraída de la base de conocimiento actual, citada, y acotada a lo que el nivel de ese cliente tiene permitido ver. Comportamiento en los pesos, hechos en el contexto. Ninguna herramienta hace el trabajo de la otra.
Pero empieza con RAG. Haz que la recuperación funcione primero. La mayoría de las veces descubrirás que nunca necesitaste el fine-tuning.
La pregunta real está aguas arriba
Esto es lo que te enseña una década de estos proyectos: cuando un asistente de conocimiento da malas respuestas, casi nunca es culpa del modelo.
Es la recuperación. El documento correcto no se recuperó, así que el modelo nunca tuvo oportunidad. Y la recuperación falla por los datos, no por los modelos: documentos que nunca se digitalizaron, PDFs que nadie puede parsear, cuatro versiones contradictorias de la misma política, conocimiento tribal que vive en la cabeza de alguien, fragmentos partidos tan mal que la frase relevante quedó huérfana de su contexto.
El fine-tuning no hace nada por nada de eso. Estarías entrenando un modelo con la misma fuente rota de la que no puedes recuperar limpiamente. El instinto de recurrir a una mejora de modelo suele ser un problema de calidad de datos disfrazado de problema de modelo. Arregla la recuperación y la calidad de datos primero, y un modelo de gama media con buen RAG le ganará a uno con fine-tuning caro aferrándose a entradas malas.
Para el conocimiento del negocio, la posición es simple: RAG primero, fine-tuning solo para comportamiento, y trata la mayoría de las quejas de "la IA se equivoca" como bugs de recuperación. Si no estás seguro de qué lado cae tu problema, eso es exactamente lo que resuelve una Evaluación de Preparación para IA: miramos tus datos y fuentes de conocimiento reales y te decimos qué enfoque encaja, antes de que gastes un centavo entrenando nada.