RAG o fine-tuning: decide a partir del fallo

Un asistente responde con una política comercial antigua. Entrenarlo de nuevo parece una forma de corregirlo, pero antes conviene averiguar de dónde salió esa política. Puede estar en el índice de búsqueda, en una respuesta guardada en caché o en los ejemplos del prompt. Cada origen exige una intervención distinta.

La decisión entre RAG y fine-tuning empieza por una pregunta que se pueda comprobar: ¿le falta información al modelo o utiliza mal la información que ya recibe? La recuperación de documentos aporta contexto en cada consulta. El ajuste del modelo modifica su comportamiento mediante entrenamiento. Pueden combinarse, pero conviene medir qué corrige cada uno antes de pagar por ambos.

Reproduce una respuesta incorrecta

Tomemos un ejemplo hipotético. La política de devoluciones cambió, pero el asistente sigue ofreciendo el plazo anterior. Guarda la consulta, la identidad de prueba y la versión del documento que debería aplicarse. Después inspecciona los fragmentos que recibió el modelo.

Si falta el documento vigente, revisa la ingesta y la búsqueda. Si llegó la versión antigua, comprueba cómo se retiran documentos y se invalidan respuestas almacenadas. Si recibió la versión correcta y aun así respondió mal, trabaja sobre las instrucciones o el comportamiento de generación. Repetir la prueba con el fragmento correcto introducido manualmente ayuda a separar esos fallos; sigue siendo necesario medir varias consultas representativas.

Si el modelo no recibe información correcta, revisa las fuentes, el índice, los permisos y la caché del RAG. Si sí la recibe, prueba instrucciones, ejemplos y validación de salida. Una variante que supera la prueba pasa a la comparación final. Cuando persiste un fallo de comportamiento en una tarea estable, ensaya fine-tuning. Evalúa calidad, tiempo y coste con las mismas consultas.

Cuando necesitas información vigente

RAG resulta una opción a probar cuando la respuesta depende de documentos que cambian, de fuentes que el usuario debe poder abrir o de permisos diferentes según la persona que pregunta. Un buscador por texto puede aportar los documentos que necesita el modelo. También puedes añadir búsqueda semántica o combinar ambas, según los fallos que observes en las consultas.

Pide una prueba completa de actualización. Publicar un archivo en el repositorio documental debe acabar en una versión identificable del índice y en una respuesta que utilice esa versión. También hay que probar la retirada. Por ejemplo, la documentación de recuperación de OpenAI advierte que algunas operaciones son asíncronas y que un archivo eliminado puede aparecer brevemente en búsquedas.

Una cita tampoco basta por sí sola. Comprueba que el fragmento respalda la afirmación y que la persona puede acceder a él. Un enlace válido puede señalar un documento irrelevante o una cláusula que dice lo contrario.

Cuando necesitas un comportamiento más consistente

El fine-tuning merece un experimento si el sistema recibe la información necesaria, pero falla de forma repetida en una tarea estable. Puede tratarse de asignar una categoría interna o seguir un criterio de extracción difícil de expresar con unas pocas instrucciones.

Antes, prueba instrucciones claras y ejemplos representativos. Si el problema es la forma del resultado, usa un esquema de salida y valida después sus valores. La guía de salidas estructuradas de OpenAI distingue el cumplimiento del esquema de los errores que todavía puede contener la respuesta.

Para entrenar necesitas ejemplos con resultados acordados por quienes conocen el trabajo. Separa los datos usados para ajustar el modelo de los que utilizarás para evaluarlo. Si cambian las etiquetas o los revisores no coinciden en la respuesta esperada, resuelve primero esa definición. El entrenamiento no decide qué criterio debería aplicar la empresa.

La guía de optimización de modelos sitúa la evaluación junto al trabajo de prompts y entrenamiento. Su disponibilidad comercial depende del proveedor y del modelo: confirma las condiciones vigentes y su ciclo de vida antes de incluir una modalidad concreta en el proyecto.

Diseña una comparación que permita decidir

Mantén las mismas consultas y criterios de aceptación entre variantes. Prueba primero el modelo con contexto e instrucciones suficientes. Añade recuperación si el problema observado es de acceso a información. Evalúa entrenamiento únicamente sobre los fallos de comportamiento que sigan presentes.

Registra por separado:

• Si la búsqueda encontró la fuente correcta y una versión permitida.
• Qué afirmaciones de la respuesta quedan respaldadas y cuáles sobran.
• Si el sistema se abstiene cuando falta información o hay fuentes incompatibles.
• Tiempo total y coste por tarea aceptada, incluidos reintentos y revisión manual.

Incluye preguntas sin respuesta en los documentos. Una colección formada solo por casos fáciles oculta la tendencia a completar información que falta. Conserva también casos de regresión para detectar si una mejora en extracción perjudica otras tareas.

Qué debe quedar en la propuesta técnica

Pide que el proveedor identifique el fallo que espera corregir, el experimento que lo comprobará y la condición para abandonar esa opción. El presupuesto debería separar preparación de datos, implementación y operación. Evita comparar solo el precio de los tokens: importa cuánto trabajo llega a ser utilizable y cuánto cuesta mantenerlo.

La consultoría RAG encaja cuando el problema está en recuperar conocimiento con sus permisos. Si ya existen varias capas y resulta difícil localizar el fallo, la auditoría técnica de IA ayuda a delimitar la revisión.

Envía una consulta que falle y describe la respuesta esperada, usando ejemplos anonimizados. Con ese punto de partida se puede acordar qué revisar antes de presupuestar una reconstrucción o un entrenamiento.