Alguien lo dice en el arranque de todos los proyectos: «¿No podemos hacerle fine-tuning al modelo con nuestros documentos?». Suena decidido. Suena a tomar el control. Y casi siempre es la jugada equivocada.
El debate entre RAG y 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 gastarte seis cifras enseñándole a un modelo a sonar seguro sobre hechos que no puede recordar de forma fiable. Si aciertas, la respuesta es aburrida, más barata y funciona.
Qué hace realmente cada uno
El fine-tuning cambia cómo se comporta un modelo. Le enseñas miles de ejemplos y aprende un patrón: este tono, este formato de salida, esta manera de razonar una tarea, esta estructura JSON siempre. Graba el comportamiento en los pesos. Lo que no hace bien es guardar hechos que puedas consultar después. Los hechos quedan repartidos entre los parámetros, recordados a medias, imposibles de citar y obsoletos en cuanto 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 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 unos pesos congelados.
Así que la división es simple. El fine-tuning es para el comportamiento. RAG es para el conocimiento. «Hagámosle fine-tuning con nuestros documentos» intenta usar una herramienta de comportamiento para resolver un problema de conocimiento. Ese es el error.
Por qué RAG gana en conocimiento de negocio
El conocimiento de negocio tiene cuatro propiedades que el fine-tuning lleva mal y que RAG resuelve 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 cuanto actualizas la fuente. El fine-tuning exige un ciclo de reentrenamiento por cada cambio relevante, y eso no lo ejecuta nadie con regularidad.
Necesita citas. Cuando un modelo le dice a tu equipo comercial cuál es una cláusula del contrato, necesitan ver qué cláusula y de 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 todo el mundo debería poder recuperarlo todo. RAG hace pasar la recuperación por tus permisos existentes, de modo que el modelo solo puede apoyarse 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.
Necesita ser correcto. Un modelo que recuerda un hecho desde sus pesos, cuando duda, se inventa una respuesta plausible. Dale el pasaje real y pídele que responda solo desde ese pasaje, y las alucinaciones caen en picado. Convertiste un examen de memoria a libro cerrado en una tarea de lectura, y en eso 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 set de entrenamiento limpio, lanzar el trabajo, evaluarlo y —la parte que todos olvidan— rehacer todo eso cada vez que cambia el conocimiento de debajo. Tu costo no es la ejecución del entrenamiento: es la cinta sin fin del reentrenamiento y del trabajo de evaluación necesario para demostrar que cada versión nueva no empeoró nada.
RAG carga por delante un trabajo distinto: dejar tus documentos en un estado recuperable, fragmentarlos con criterio y mantener el índice sincronizado. Pero una vez que ese pipeline existe, el conocimiento nuevo son simplemente documentos nuevos. Sin reentrenar, sin la carrera de obstáculos del eval, sin riesgo de modelo. Actualizas una fuente y el sistema lo sabe.
Para casi cualquier negocio el intercambio honesto es este: RAG cuesta más disciplina de ingeniería y menos gasto continuo. El fine-tuning parece barato por ejecución y se vuelve caro justamente porque tu conocimiento no se queda quieto.
Cuándo el fine-tuning se gana su sitio
Esto no es integrismo de RAG. El fine-tuning es la herramienta correcta para problemas reales; solo que no son problemas de conocimiento.
Recurre a él cuando necesitas un formato de salida consistente que el prompting no consigue imponer de forma fiable. Cuando necesitas una voz o un estilo de casa a escala. Cuando estás comprimiendo un prompt largo y elaborado dentro de los pesos para bajar la latencia y el costo por llamada. Cuando la tarea es una clasificación o extracción estrecha y repetida, donde un modelo pequeño afinado le gana a uno grande y general en velocidad y precio. Cuando necesitas razonar en un dominio especializado y el comportamiento por defecto del modelo base sigue fallando.
Fíjate en el patrón: formato, tono, latencia, comportamiento. Ninguno es «conoce nuestros hechos».
Combínalos, en este orden
Los sistemas más sólidos usan los dos, 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 sobre los que apoya cada respuesta.
Un asistente de soporte es el ejemplo limpio. Fine-tuning para que cada respuesta siga tu estructura de escalación y tu voz de marca. RAG para que la política concreta que cita sea la de hoy, sacada de la base de conocimiento actual, citada y acotada a lo que el nivel de ese cliente puede ver. Comportamiento en los pesos, hechos en el contexto. Ninguna de las dos herramientas hace el trabajo de la otra.
Pero empieza por RAG. Haz que la recuperación funcione primero. La mayoría de las veces vas a descubrir que nunca necesitaste el fine-tuning.
La pregunta de verdad está río arriba
Esto es lo que 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 sabe 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 impulso de recurrir a una mejora de modelo suele ser un problema de calidad de datos disfrazado de problema de modelo. Arregla primero la recuperación y la calidad de datos, y un modelo de gama media con buen RAG le va a ganar a uno con fine-tuning caro aferrado a entradas malas.
Para el conocimiento de negocio la postura es simple: RAG primero, fine-tuning solo para comportamiento, y trata casi todas las quejas de «la IA se equivoca» como bugs de recuperación. Si no tienes claro de qué lado cae tu problema, eso es exactamente lo que resuelve una Evaluación de Preparación para IA: miramos tus datos y tus fuentes de conocimiento reales y te decimos qué enfoque encaja, antes de que gastes un céntimo entrenando nada.