RAG frente a fine-tuning y flujos deterministas: criterios de elección

Antes de elegir entre RAG y ajuste fino conviene preguntarse qué parte del problema no necesita un modelo de lenguaje. Calcular un plazo de entrega, comprobar si un proveedor está homologado internamente o decidir a quién se envía una aprobación son reglas que se pueden escribir. Un modelo puede ayudar a interpretar la entrada (leer un correo, identificar el pedido), pero la decisión que tiene consecuencias debería tomarla una lógica verificable o una persona.

Esta separación tiene una ventaja práctica: reduce la superficie donde el modelo puede equivocarse y facilita las pruebas. Muchos sistemas que funcionan bien en producción son, en su mayor parte, software convencional con uno o dos pasos donde interviene un modelo, cada uno con su validación.

Cada enfoque pide un material distinto, y a menudo es la disponibilidad de ese material la que decide.

• Flujo determinista: reglas conocidas y documentadas, y datos estructurados accesibles desde los sistemas de origen.
• RAG: un corpus de documentos con versión, vigencia y permisos identificables, y un proceso para mantenerlo al día.
• Fine-tuning: cientos o miles de ejemplos de entrada y salida correcta, coherentes entre sí y revisados por quien conoce el criterio. Si dos expertos clasificarían el mismo caso de forma distinta, el modelo aprenderá esa contradicción.

Un error frecuente es plantear un ajuste fino con los documentos de la empresa como material de entrenamiento, esperando que el modelo «se los aprenda». Lo normal es que retenga el estilo y parte del contenido de forma imprecisa, sin poder citar de dónde sale cada dato ni olvidar lo que quedó obsoleto.

Sin entrar en cifras, que dependen del proveedor y del volumen, el reparto del esfuerzo es distinto en cada caso. Un flujo determinista concentra el coste en el análisis y la programación, y su operación suele ser barata. Un RAG exige preparar la ingesta de documentos, el índice y los permisos, y su coste de operación crece con el número de consultas y el volumen de texto que se entrega al modelo en cada una. Un ajuste fino requiere sobre todo preparar y revisar ejemplos, entrenar y evaluar, y repetir el ciclo cada vez que cambie el criterio o el modelo base.

Este último punto se olvida a menudo: un modelo ajustado está ligado a una versión concreta del modelo base. Si el proveedor la retira o aparece una mejor, el ajuste hay que rehacerlo. Conviene guardar el conjunto de entrenamiento y el de evaluación como activos del proyecto, porque son lo que permite repetir el proceso.

Si la información cambia con frecuencia (tarifas, procedimientos, normativa interna, fichas de producto), RAG tiene una ventaja clara: basta con actualizar el índice, y la respuesta siguiente ya usa la versión nueva. Con un ajuste fino, lo aprendido queda fijado en el momento del entrenamiento, y retirar un dato obsoleto exige reentrenar y comprobar que ha desaparecido.

Los flujos deterministas se actualizan cambiando datos o reglas, con las ventajas del software convencional: control de versiones, pruebas automáticas y despliegues reversibles. Cuando la regla vive en una tabla mantenida por el área de negocio, la actualización ni siquiera requiere tocar código.

Las tres opciones se pueden evaluar con el mismo conjunto de casos reales, cada uno con su respuesta correcta validada. Lo que cambia es dónde mirar cuando algo falla. En un RAG hay que distinguir si el fallo está en la recuperación o en la generación, algo que se detalla en la guía sobre cómo evaluar un RAG empresarial. En un ajuste fino hay que vigilar que el conjunto de evaluación no se parezca demasiado al de entrenamiento y comprobar que el modelo no ha empeorado en lo que antes hacía bien. En un flujo determinista, las pruebas automáticas cubren los casos conocidos y la duda está en los casos que nadie previó.

En la práctica, los sistemas maduros combinan enfoques. Algunas combinaciones razonables:

• Flujo determinista con un paso de extracción: el modelo lee un documento y devuelve campos estructurados; la aplicación los valida contra el ERP y aplica las reglas.
• RAG con salida validada: el modelo responde con fragmentos recuperados y una capa determinista comprueba que cita documentos vigentes a los que el usuario tiene acceso.
• Fine-tuning ligero con RAG: el ajuste fija el formato y la terminología de las respuestas y la recuperación aporta el contenido actualizado.
• Clasificador ajustado dentro de un flujo: un modelo pequeño ajustado clasifica entradas a gran volumen y las reglas deciden qué hacer con cada categoría.

Pensemos, como ejemplo ilustrativo, en una empresa que vende equipos industriales y quiere ayudar a su servicio técnico. Las preguntas sobre cómo calibrar un equipo se responden con los manuales, que cambian con cada revisión: es terreno de RAG. Decidir si una avería está cubierta por la garantía depende de la fecha de venta, del número de serie y de las condiciones firmadas: es un flujo determinista que consulta el ERP. Redactar el informe de intervención con el formato y el tono de la casa, a partir de las notas del técnico, podría justificar un ajuste fino si las instrucciones y los ejemplos no bastan, después de comprobarlo con un conjunto de informes reales.

1. ¿Qué parte del proceso se puede resolver con reglas explícitas?
2. ¿El problema es de conocimiento (qué dice un documento) o de comportamiento (cómo se responde)?
3. ¿Cada cuánto cambia la información y quién la mantiene?
4. ¿Existen los datos que cada enfoque necesita, con la calidad necesaria?
5. ¿Hay un conjunto de evaluación común para comparar opciones antes de elegir?

Si quieres analizar un proceso concreto, podemos ayudarte a separar lo determinista de lo que realmente necesita un modelo y a comparar alternativas con vuestros propios casos.