Auditar el RAG agéntico: por qué la confianza exige trazabilidad de la recuperación

El Retrieval-Augmented Generation (RAG) básico funciona bien para consultas simples: el usuario pregunta, el sistema busca en la base de conocimiento y el modelo genera una respuesta. Pero en entornos de producción, muchos sistemas requieren un control más fino sobre cómo y dónde se realiza la búsqueda. Ahí entra el RAG agéntico, donde un agente reescribe la consulta, elige fuentes (bases de datos, sistemas de cuentas, grafos) y combina búsquedas léxicas, semánticas y de grafos para fusionar resultados antes de responder.

Del intento ciego a la trazabilidad

El problema central no es la capacidad de búsqueda, sino la opacidad del proceso. Un agente puede realizar múltiples intentos de recuperación, rechazar fuentes y cambiar de herramienta, todo sin que esta actividad quede visible en la respuesta final. Un sistema que responde con confianza pero no revela su ruta de búsqueda genera una deuda técnica difícil de gestionar. Como señala el texto, "más decisiones requieren una ruta de evidencia clara".

La propuesta para resolverlo es tratar la recuperación como una cadena de decisiones auditables. Cada paso debe registrar datos estructurados: la consulta original, las consultas reescritas, los identificadores de las fuentes consultadas, los filtros aplicados, los scores de ranqueo y, crucialmente, las razones por las que se aceptó o rechazó un candidato. Este registro actúa como una "caja negra" del sistema de recuperación. Si un ingeniero no puede responder por qué se eligió una fuente concreta en un momento dado basándose en el rastro, el sistema no cumple su función.

Evidencia para el usuario y para el operador

Hay dos audiencias con necesidades distintas. El usuario final necesita citas claras que identifiquen la fuente y el pasaje relevante, incluyendo fechas de vigencia y recuperación. Si hay incertidumbre, el sistema debe declararlo en lenguaje llano ("no pude verificar la tarifa actual").

Para los operadores y equipos de ingeniería, la traza debe ser mucho más detallada. Debe conservar las consultas fallidas, las llamadas a herramientas y las reglas de acceso que filtraron resultados. Es vital distinguir entre una cita que el modelo añadió artificialmente después de generar la respuesta y una fuente que realmente informó la generación. La procedencia de la cita debe verificarse mapeando cada afirmación con el fragmento específico que la sustenta. Si una afirmación no tiene soporte, el sistema debe eliminarla o marcarla para revisión humana, especialmente en casos de alto riesgo regulatorio o contractual.

La similitud no es autoridad

Un error frecuente en RAG es confiar ciegamente en la similitud semántica. Un documento obsoleto puede tener una coincidencia vectorial perfecta con la consulta, pero ser incorrecto por estar fuera de vigencia o fuera del alcance del inquilino (tenant). La similitud mide parecido, no validez. Los metadatos (fecha de efectividad, propietario, estado de aprobación, jurisdicción) deben actuar como filtros duros previos a la ranqueo. Un filtro de alcance es una regla aplicable; un score de similitud es solo una opinión del modelo. Sin esta distinción, el RAG agéntico corre el riesgo de ofrecer respuestas convincentes pero operativamente incorrectas, comprometiendo la confianza del equipo de TI en la infraestructura.