Fine-Tuning vs RAG: Eligiendo la estrategia correcta

Uno integra el conocimiento en los pesos del modelo. El otro lo recupera en tiempo de ejecución. Cuál elegir depende de tus datos, tu presupuesto de latencia y la frecuencia con la que cambia la información subyacente.

Dos problemas diferentes

He visto equipos perder semanas haciendo fine-tuning a un modelo cuando lo que realmente necesitaban era un índice vectorial, y a otros acoplar RAG a un sistema que lo que realmente requería era fijar su formato de salida. No son intercambiables.

RAG (Retrieval-Augmented Generation) le da a un modelo acceso a conocimiento externo en el momento de la inferencia. Los pesos no cambian. El modelo simplemente recibe contexto adicional de un sistema de recuperación antes de responder. Es como entregarle a alguien un libro de referencia antes de hacerle una pregunta.

El fine-tuning modifica los pesos a través de un entrenamiento adicional con datos específicos de un dominio. Eso cambia la forma en que el modelo se comporta: su estilo, su formato, sus patrones de razonamiento y el vocabulario que utiliza por defecto. Es más parecido a enviar a alguien a una capacitación especializada que a entregarle un libro.

Ambos pueden hacer que un modelo "sepa" cosas sobre tu dominio, y ahí es donde comienza la confusión. Los mecanismos son completamente diferentes, y esa diferencia se nota en producción.

Cuándo gana RAG

RAG es la opción correcta cuando tu problema es el acceso al conocimiento.

Si tus datos cambian semanal o diariamente —catálogos de productos, documentos internos, regulaciones de cumplimiento— reentrenar el modelo cada vez es poco práctico. RAG simplemente recupera la versión más reciente al momento de la consulta y listo. Lo mismo ocurre con las bases de conocimientos extensas. El fine-tuning puede codificar algunos hechos, pero no memorizará de manera confiable miles de páginas de documentación. RAG puede buscar entre millones de chunks sin dificultades.

La citación es otro factor importante. RAG presenta de forma natural los documentos fuente, por lo que cuando los usuarios necesitan verificar afirmaciones —legales, médicas, financieras— tienes algo a lo cual remitirlos. Los pesos de un modelo con fine-tuning no te ofrecen eso.

Los sistemas multi-tenant se inclinan por la misma vía. Diferentes usuarios necesitan acceso a diferentes conocimientos, y RAG maneja eso con recuperación filtrada. Hacer fine-tuning significaría un modelo separado por cada cliente, lo cual es absurdo a cualquier escala significativa.

Un pipeline de RAG razonable se ve más o menos así:

Query → Embedding → Vector Search → Top-K Chunks → LLM + Context → Response

El modelo en sí nunca se mueve. Toda la personalización reside en la capa de recuperación y en el almacenamiento de datos, que es exactamente donde puedes depurarlo.

Cuándo gana el fine-tuning

El fine-tuning es la opción correcta cuando tu problema es de comportamiento.

Si necesitas que el modelo siempre devuelva un JSON con campos específicos, o que siempre siga una estructura de informe particular, el fine-tuning codifica eso de manera más confiable que el prompting. He visto prompts con veinte reglas perder el formato en el tercer o cuarto turno de la conversación. Un modelo con fine-tuning mantiene la estructura.

El lenguaje específico de un dominio es otro buen caso de uso. Terminología médica, fraseología legal, jerga interna de la empresa: el fine-tuning desplaza la probabilidad a priori del modelo hacia el vocabulario que realmente utilizas. Lo mismo ocurre con el razonamiento específico de una tarea. Si quieres que el modelo clasifique documentos usando tu taxonomía o extraiga entidades siguiendo tu esquema, enseñar el patrón mediante entrenamiento es más duradero que volver a explicarlo en cada prompt.

La latencia también importa. RAG añade una sobrecarga de recuperación, usualmente de 100 a 500 ms para una búsqueda vectorial más el reranking. Un modelo con fine-tuning simplemente responde.

El fine-tuning también es sorprendentemente efectivo para reducir la longitud del prompt. En lugar de añadir veinte ejemplos few-shot a cada solicitud, entrenas con esos ejemplos y envías prompts mínimos. Ese ahorro se potencia en volúmenes altos.

Modos de falla

Cada enfoque falla de una manera característica.

RAG falla más a menudo en la recuperación. Si el sistema devuelve chunks irrelevantes, el modelo alucina a partir de ellos o recurre silenciosamente a su conocimiento paramétrico. La calidad del modelo de embedding y la estrategia de chunking suelen ser los culpables. El siguiente fallo es la saturación del contexto: amontonar demasiados chunks recuperados en la ventana degrada la calidad, porque el modelo pierde el pasaje relevante entre otros que solo están marginalmente relacionados. Y está el deterioro lento de los embeddings obsoletos: los documentos cambian, los embeddings no se reindexan y el sistema entrega con confianza información desactualizada.

El fine-tuning falla de forma distinta. Un entrenamiento agresivo puede causar un olvido catastrófico (catastrophic forgetting), donde el modelo mejora en tu tarea pero empeora en todo lo demás. Los datasets pequeños producen overfitting: unos pocos cientos de ejemplos serán memorizados, no generalizados, y necesitas miles de ejemplos de alta calidad para un comportamiento confiable. Además, cada actualización de conocimiento significa una nueva ejecución de entrenamiento, una nueva evaluación y un nuevo despliegue. Eso no escala para información que cambia constantemente.

El enfoque híbrido

La mayoría de los sistemas en producción en los que he trabajado terminan usando ambos, y hay una razón clara para ello.

El patrón es simple: fine-tuning para el comportamiento, RAG para el conocimiento.

# El patrón híbrido en la práctica
# 1. El modelo con fine-tuning sabe CÓMO responder (formato, tono, estilo de razonamiento)
# 2. RAG proporciona el QUÉ responder (hechos actuales, documentos)

retrieved_context = vector_store.similarity_search(query, k=5)

response = fine_tuned_model.generate(
    system="Eres un asistente médico. Siempre cita tus fuentes. "
           "Usa terminología clínica. Estructura las respuestas con "
           "secciones de Evaluación y Plan.",  # Comportamiento definido por fine-tuning
    context=retrieved_context,               # Conocimiento de RAG
    query=user_question
)

Un modelo con fine-tuning que también utiliza RAG obtiene lo mejor de ambos mundos: se comporta como tú quieres (formato, tono, patrones de dominio) mientras extrae información actual y verificable. Debido a que el comportamiento está integrado en los pesos, tus prompts pueden ser más cortos, lo que deja más ventana de contexto para los documentos recuperados.

Marco de decisión

Un diagrama de flujo práctico, en el orden en que suelo analizarlo:

¿El problema trata principalmente sobre acceder a conocimiento específico? Empieza con RAG.
¿El problema trata principalmente sobre el formato de salida o el comportamiento en la tarea? Empieza con fine-tuning.
¿Necesitas ambos? Haz fine-tuning primero, porque el comportamiento es más difícil de corregir solo con prompting, y luego añade RAG para el conocimiento.
¿Tus datos cambian con frecuencia? RAG es obligatorio para la porción dinámica. No hay otra forma.
¿Tienes menos de 1,000 ejemplos de entrenamiento de alta calidad? No hagas fine-tuning todavía. Usa prompting few-shot más RAG y vuelve a evaluarlo más tarde.

Comparación de costos

La economía de ambos no es simétrica.

RAG representa mayormente un costo continuo. La generación de embeddings cuesta unos $0.10 por millón de tokens, una sola vez por documento. El alojamiento de la base de datos vectorial cuesta entre $50 y $500 al mes, dependiendo de la escala. Asumes 100-500 ms de latencia de recuperación en cada consulta y pagas por reindexar cuando los documentos cambian.

El fine-tuning es un costo inicial. El cómputo para el entrenamiento cuesta entre $5 y $50 para modelos pequeños, y de $500 a más de $5,000 para modelos más grandes. La preparación del dataset requiere un esfuerzo humano real. Necesitas un pipeline de evaluación con benchmarks adecuados para verificar la calidad; de lo contrario, estarás lanzando a ciegas. Después del despliegue, no hay un costo extra por consulta.

Por lo tanto, RAG tiene costos iniciales más bajos y costos operativos más altos. El fine-tuning es lo opuesto: mayor inversión inicial, menor costo marginal por consulta. Para sistemas de producción de alto volumen, un modelo con fine-tuning y prompts mínimos puede ser mucho más barato por solicitud que un pipeline de RAG que recupera y procesa múltiples chunks.

El camino pragmático

Comienza con RAG. Es más rápido para crear prototipos, más fácil de depurar porque puedes inspeccionar qué se recuperó y no requiere infraestructura de entrenamiento. Si el cuello de botella resulta ser el comportamiento del modelo en lugar de su conocimiento, entonces añade fine-tuning.

Los equipos que saltan directamente al fine-tuning suelen terminar construyendo RAG de todos modos, porque el modelo con fine-tuning todavía necesita información actualizada de algún lugar. El camino inverso es menos común. RAG con un buen prompting resuelve un número sorprendente de casos de uso sin que nadie tenga que tocar los pesos del modelo.

La pregunta no es qué enfoque utilizar. Es qué problema estás resolviendo realmente.