¿RAG o ajuste fino? Lo que nos enseñaron proyectos reales con clientes sobre cómo elegir

Casi todas las conversaciones sobre IA empresarial en las que participo llegan al mismo dilema durante la primera hora. El cliente tiene un modelo de lenguaje grande que impresiona en una demostración, pero desconoce sus productos, sus políticas y su estilo de redacción. Alguien en la sala pregunta: ¿deberíamos ajustar el modelo con nuestros datos o crear un sistema de generación aumentada por recuperación (RAG) a su alrededor?

La respuesta sincera es que, por lo general, la pregunta está mal planteada. RAG y el ajuste fino resuelven problemas distintos. Los equipos que los tratan como opciones contrapuestas suelen pasar meses y gastar una gran parte de su presupuesto para GPU en solucionar el problema equivocado. Así es como decidimos en la práctica y esto es lo que hemos visto que funciona y lo que no.

Empieza por identificar qué le falta al modelo

Cuando un modelo da una respuesta deficiente a una tarea empresarial, le falta una de estas dos cosas.

Le faltan conocimientos. Desconoce tu lista de precios más reciente, la cláusula de tu contrato con proveedores de 2025 o los pasos para solucionar problemas de un producto que se lanzó el mes pasado. Este es un problema de datos.

Le falta capacidad para comportarse como necesitas. Tiene conocimientos suficientes, pero no responde como necesitas. Ignora el formato de salida, emplea un tono inadecuado, interpreta mal tus códigos internos o no puede realizar una tarea acotada y repetitiva, como clasificar tickets en tus 40 categorías. Este es un problema de habilidades.

RAG es la herramienta adecuada para el primer problema. El ajuste fino lo es para el segundo. La mayor parte de la confusión que veo se debe a que se intenta usar el ajuste fino para enseñar datos.

Por qué el ajuste fino no es una buena manera de incorporar conocimientos

Es tentador pensar que, si entrenas un modelo con tus documentos, los «conocerá». En la práctica, aprende el estilo de esos documentos con mucha más fiabilidad que los datos que contienen. Unos investigadores de Microsoft compararon directamente ambos enfoques para responder preguntas que requieren muchos conocimientos y descubrieron que RAG superó sistemáticamente al ajuste fino no supervisado, tanto con datos que el modelo había visto durante el entrenamiento como con otros completamente nuevos.

También hay problemas prácticos. Los datos cambian. Cada vez que cambia tu política o catálogo, el modelo ajustado queda desactualizado hasta que vuelves a entrenarlo. Además, pierdes la trazabilidad: cuando un modelo ajustado proporciona una cifra, no puedes señalar el documento del que procede. Para los clientes de sectores regulados, como los seguros y la atención sanitaria, eso suele bastar para dar por zanjada la conversación.

RAG, descrito por primera vez en el artículo de 2020 de Lewis y otros, mantiene los conocimientos fuera del modelo. Cuando recibe una pregunta, recupera los pasajes pertinentes y se los proporciona al modelo como contexto. Para actualizar los conocimientos basta con actualizar un índice, sin volver a entrenar el modelo. Además, cada respuesta puede citar su fuente.

Un cliente nuestro del sector logístico es un buen ejemplo. Sus clientes querían respuestas inmediatas sobre la ubicación de sus envíos y los documentos que faltaban. Esa información cambia cada pocos minutos. Ningún entrenamiento habría mantenido actualizado el modelo, así que el asistente que creamos responde a partir de datos de seguimiento en tiempo real y de IoT cuando recibe la pregunta, en lugar de recurrir a su memoria. La recuperación era la única opción de diseño viable.

Cuándo vale la pena recurrir al ajuste fino

El ajuste fino no ha quedado obsoleto. Simplemente tiene un campo de aplicación más limitado de lo que muchos esperan. Lo usamos en tres situaciones:

• Formatos de salida estrictos y repetitivos. Cuando un modelo debe generar miles de veces al día la misma salida estructurada —por ejemplo, extraer campos de facturas según un esquema JSON fijo—, un modelo pequeño ajustado suele ser más fiable y mucho más barato que pedirle lo mismo a uno grande mediante instrucciones.
• Lenguaje especializado. En algunos sectores se utilizan abreviaturas que el modelo base interpreta mal. Los códigos de estado logísticos, las abreviaturas clínicas y los códigos internos de productos son ejemplos habituales. Un ajuste fino moderado puede corregirlo.
• Costos y latencia a gran escala. Cuando una tarea está bien definida, un modelo pequeño ajustado puede sustituir a un modelo general grande. Métodos como LoRA hacen que esto sea asequible, porque se entrena un pequeño conjunto de pesos adicionales en lugar del modelo completo.

Fíjate en que ninguno de estos casos tiene que ver con datos. Se trata de enseñar a un modelo cómo realizar una tarea que ya conoces bien.

La mayoría de los fallos de RAG son fallos de recuperación

Cuando un equipo me dice «probamos RAG y no funcionó», rara vez el problema está en el modelo. Está en el paso de recuperación. La calidad del modelo no puede superar la de los pasajes que recibe.

Las soluciones no son llamativas, pero sí eficaces:

• Divide el contenido por significado, no por número de caracteres. Si divides un contrato cada 500 caracteres, cortarás las cláusulas por la mitad. Dividirlo por secciones y encabezados mantiene intacto el contexto.
• Añade contexto a cada fragmento. Un fragmento que dice «el límite es de 30 días» no sirve de nada si no se sabe a qué póliza corresponde. Anthropic informó que añadir un breve contexto del documento a cada fragmento antes de indexarlo —un enfoque que denomina recuperación contextual— redujo las recuperaciones fallidas un 49 %, y un 67 % al combinarlo con la reclasificación de resultados.
• Combina la búsqueda por palabras clave con la búsqueda vectorial. La búsqueda vectorial es eficaz para captar el significado, pero flojea con términos exactos, como los números de pieza. La búsqueda híbrida permite cubrir ambos aspectos.
• Evalúa la recuperación por separado. Prepara un conjunto de preguntas reales con pasajes de origen correctos conocidos y mide si el pasaje adecuado aparece entre los primeros resultados antes de evaluar las respuestas finales.

Cuándo usar ambos

En producción, los sistemas más sólidos suelen combinar ambos métodos. RAG proporciona los datos. Un modelo con un ajuste fino ligero se ocupa del formato, el tono y el lenguaje del sector. La investigación avanza en la misma dirección: el enfoque RAFT de UC Berkeley ajusta un modelo específicamente para que aproveche mejor los documentos recuperados e ignore los irrelevantes.

Pero el orden importa. Casi siempre empezamos por crear un sistema RAG, medimos en qué aspectos se queda corto y solo entonces decidimos si vale la pena aplicar un ajuste fino. Empezar por el ajuste fino implica pagar el entrenamiento antes de saber cuál es la verdadera carencia.

Una lista sencilla para decidir

1. ¿La tarea depende de datos que cambian más de una vez por trimestre? Usa RAG.
2. ¿Los usuarios o auditores necesitan saber de dónde procede una respuesta? Usa RAG.
3. ¿El problema está en el formato, el tono o el vocabulario de las respuestas, y no en los datos? Considera el ajuste fino.
4. ¿Se trata de una tarea específica que se ejecuta a gran escala y para la que el costo o la velocidad son importantes? Considera ajustar un modelo más pequeño.
5. ¿Has medido por separado la calidad de la recuperación? Si no, hazlo antes que nada.

Conclusión

RAG y el ajuste fino no son métodos opuestos. Uno proporciona al modelo la información adecuada; el otro da forma a su comportamiento. Aclara cuál es el problema que realmente tienes, mejora la recuperación antes de culpar al modelo y considera el ajuste fino como algo que te ganas una vez que el sistema funciona, no como un atajo para hacerlo funcionar.