# RAG frente a fine-tuning: ¿cuál necesita tu producto? > Usa retrieval cuando el modelo necesita hechos que no tiene: tus documentos, tus registros, cualquier cosa que cambia. Usa fine-tuning cuando necesita un formato, un tono o un comportamiento de clasificación que el prompting no sostiene. Los problemas de conocimiento son problemas de retrieval. Si no estás seguro, es retrieval. Eso vale para la mayoría de las funcionalidades de producto. Esta decisión se toma al revés con una frecuencia sorprendente. El fine-tuning suena a la opción de ingeniería seria (al fin y al cabo estás entrenando un modelo) y la retrieval a un apaño. En la práctica, para la mayoría del trabajo de producto, es al contrario. ## Qué cambia realmente cada una La generación aumentada por retrieval cambia lo que el modelo puede ver. En el momento de la petición buscas en tus propios datos, pones los pasajes relevantes en el prompt y le pides al modelo que responda a partir de ellos. Los pesos del modelo no se tocan. En el fondo es un problema de búsqueda con un modelo de lenguaje al final. El fine-tuning cambia cómo se comporta el modelo. Le muestras cientos o miles de ejemplos de entrada y salida deseada, y ajusta sus pesos hacia ese patrón. Aprende forma: la estructura de tu salida, tu tono, las distinciones que importan en tu dominio. La distinción que importa: **la retrieval añade conocimiento, el fine-tuning añade comportamiento.** Casi todas las quejas de "la IA no conoce nuestro negocio" son un problema de conocimiento, y los problemas de conocimiento no responden al fine-tuning. ## Por qué la retrieval es la opción por defecto Tus datos cambian. Un cliente actualiza su dirección, se revisa una política, un documento queda sustituido. Con retrieval, la siguiente petición recoge la versión nueva porque lee de la fuente. Con un modelo afinado, el hecho viejo está horneado en los pesos hasta que vuelves a entrenar. La retrieval también te permite mostrar las fuentes, y eso hace más por la confianza del usuario que cualquier mejora de precisión. Un usuario que ve tres pasajes y un resumen puede comprobar la respuesta. Un usuario que ve un párrafo seguro salido de la nada tiene que aceptarlo o dejarlo. Y los permisos funcionan. La retrieval respeta las reglas de acceso que ya existen en tu aplicación, porque es tu consulta la que trae el contexto. Un modelo afinado con todo lo sabe todo, y no se le puede hacer olvidarlo para un usuario concreto, que es un problema de cumplimiento esperando a ser descubierto. ## Cuándo el fine-tuning se gana de verdad su sitio Hay casos reales, y comparten una forma: el comportamiento que quieres es difícil de especificar con palabras pero fácil de demostrar. **Formatos de salida rígidos.** Si cada respuesta debe tener una estructura concreta y el prompting te lleva al 95% de cumplimiento, el fine-tuning te acerca más, en un modelo más pequeño y más barato. **Clasificación de dominio.** Ordenar tickets de soporte en tus veintidós categorías propias, cuyas fronteras son conocimiento institucional y no una definición. Unos miles de ejemplos históricos lo enseñan mejor que cualquier prompt. **Voz, de forma consistente.** Un registro concreto, sostenido a lo largo de miles de salidas, sin un prompt de estilo de 600 palabras en cada llamada. **Coste y latencia a volumen.** Un modelo pequeño afinado que iguala el rendimiento de uno grande en tu única tarea estrecha, a una fracción del precio por llamada. Es una razón real y poco usada, pero es una optimización, y eso significa que llega después de que algo funciona. ## Cómo elegir, en concreto Pregunta cómo se ve un fallo. Si el fallo es *"eso no es verdad"*, *"eso está desactualizado"* o *"no sabe nada de nuestro cliente"*: retrieval. Siempre. Si el fallo es *"es correcto pero está mal formateado"*, *"sigue dudando cuando necesitamos una decisión"*, o *"lo puso en la categoría equivocada y una persona no lo habría hecho"*: el fine-tuning entra en juego, una vez tienes los ejemplos que demuestran que el patrón es consistente. Si el fallo es *"va demasiado lento"* o *"cuesta demasiado"*, mira primero el tamaño del contexto. Los equipos envían rutinariamente mucho más texto recuperado del que la respuesta necesita, y recortarlo es una tarde de trabajo, no un pipeline de entrenamiento. ## El orden en el que construir Retrieval primero, siempre, porque es lo que hace correctas las respuestas y la corrección es lo único que no se puede fingir. Lleva la precisión a donde la necesitas, contra un conjunto de evaluación real. Solo entonces, si las quejas que quedan son de forma y no de hecho, considera el fine-tuning, y reutiliza ese mismo conjunto para demostrar que el modelo afinado es de verdad mejor, no solo distinto. Los equipos que lo hacen al revés pasan un mes construyendo un dataset de entrenamiento, publican un modelo que escribe respuestas incorrectas con un formato impecable, y concluyen que la IA no está lista para su dominio. Casi siempre lo estaba. El conocimiento simplemente no llegó al prompt. --- Publicado por Vuewer. Funciones de IA y aplicaciones web, llevadas a producción. Versión canónica: https://vuewer.com/es/blog/rag-frente-a-fine-tuning