Corrective RAG y Self-RAG: verificar antes de responder

Sexta entrega del bloque de técnicas de recuperación, y primera de nivel avanzado. Las técnicas anteriores mejoran lo que el sistema recupera. Estas dos hacen algo distinto: introducen un componente que juzga el trabajo del sistema mientras se ejecuta, y le permiten cambiar de plan a mitad de camino.

El cuarto punto de rotura

En la entrega 14 enumeramos los cuatro fallos estructurales del pipeline mínimo. El cuarto era que nadie comprueba nada: los fragmentos entran en el prompt por ser los más cercanos, no por ser relevantes, y la respuesta sale hacia el usuario sin que ningún componente verifique si se apoya en ellos.

Conviene precisar por qué eso importa más de lo que parece. Un sistema sin verificación no falla más que uno con ella; falla en silencio. Produce con idéntica fluidez la respuesta correcta y la respuesta construida sobre cinco fragmentos irrelevantes, y no dispone de ninguna señal interna que permita distinguirlas ni avisar al usuario. Para muchos casos de uso —soporte informal, exploración de un archivo— eso es tolerable. Para otros —asesoramiento con implicaciones económicas, consulta de normativa, cualquier cosa que alguien pueda citar como fuente— no lo es.

Corrective RAG y Self-RAG son dos respuestas al mismo problema, formuladas por vías distintas. La primera añade un evaluador externo entre la recuperación y la generación. La segunda entrena al propio modelo para que emita juicios sobre su trabajo. En la práctica, la mayoría de las implementaciones que verás combinan ideas de ambas.

Corrective RAG: evaluar lo recuperado y reaccionar

La idea es directa: antes de generar, un evaluador puntúa la relevancia de cada fragmento recuperado respecto a la pregunta. Con esas puntuaciones, el sistema clasifica la situación en uno de tres estados y actúa distinto en cada uno.

• Correcto. Hay fragmentos claramente relevantes. Se filtran los que no lo son y se genera con el resto. Coste añadido: el del evaluador y nada más.
• Ambiguo. Hay material parcialmente útil, pero insuficiente o poco concluyente. Se combina lo recuperado con una búsqueda adicional: la consulta reformulada, otra fuente, o ambas.
• Incorrecto. Nada de lo recuperado sirve. Se descarta todo el contexto y se va a una vía alternativa: reformular la consulta y volver a buscar, consultar otra fuente —una búsqueda web, otro índice, una base de datos estructurada— o, si no hay alternativa, responder que la información no está disponible.

Ese último caso es el que justifica el nombre: el sistema corrige su propia recuperación en lugar de generar sobre material malo. Y la opción de responder «no lo sé» deja de ser una instrucción en el prompt que el modelo puede ignorar y pasa a ser una rama del flujo de control, que no se puede ignorar.

El evaluador puede implementarse de tres maneras, en orden creciente de coste y de calidad: un umbral sobre la puntuación del reranker de la entrega 16, un modelo pequeño entrenado o instruido para clasificar relevancia, o una llamada al modelo grande con un prompt de juicio. Para la mayoría de los sistemas, un reranker con umbral calibrado cubre buena parte del beneficio a coste marginal cero, porque el reranker ya estaba ahí.

Self-RAG: el modelo se evalúa a sí mismo

Self-RAG plantea lo mismo desde dentro. En lugar de añadir componentes externos, el modelo se entrena para emitir, intercalados en su salida, unos marcadores especiales —tokens de reflexión— que expresan juicios sobre el proceso. Son de cuatro tipos:

• ¿Hace falta recuperar? Se emite antes de buscar. Muchas peticiones no necesitan corpus: un saludo, una petición de reformular lo anterior, una pregunta de conocimiento general. Recuperar siempre es desperdicio y además introduce ruido, porque el índice devolverá algo aunque no venga a cuento.
• ¿Es relevante este fragmento? Se emite por cada fragmento recuperado. Equivale al evaluador de Corrective RAG, pero incorporado.
• ¿Se apoya la respuesta en el fragmento? Es el juicio de groundedness o fundamentación, y es el que ataca la alucinación de frente: comprueba si lo afirmado está efectivamente soportado por el texto citado o si el modelo ha añadido de su cosecha.
• ¿Es útil la respuesta? Un juicio final de calidad: responde realmente a lo que se preguntó.

La diferencia arquitectónica es importante. En Corrective RAG los juicios los emite un componente aparte, con lo que se puede usar cualquier modelo y cualquier proveedor. En Self-RAG los juicios los emite el propio modelo generador, lo cual requiere un modelo específicamente entrenado para ello. La contrapartida es que un juicio no cuesta una llamada aparte.

Ahora bien, el concepto se puede aplicar sin modelo especializado. Las cuatro preguntas de Self-RAG funcionan igual de bien como pasos explícitos de un flujo orquestado con un modelo comercial cualquiera, a cambio de pagar cada juicio como una llamada. Es lo que hace la mayoría de las implementaciones reales, y por eso conviene ver ambos enfoques como un repertorio de comprobaciones más que como dos productos distintos.

El bucle, en pseudocódigo

def responder_con_verificacion(pregunta, max_intentos=2):
    consulta = pregunta
    intentos = 0

    if not hace_falta_recuperar(pregunta):
        return generar_sin_contexto(pregunta)

    while intentos < max_intentos:
        fragmentos = recuperar(consulta)
        utiles = [f for f in fragmentos if es_relevante(f, pregunta)]

        if len(utiles) >= MINIMO:
            break                          # estado: correcto

        intentos += 1
        if intentos < max_intentos:
            consulta = reformular(pregunta, fragmentos)   # estado: ambiguo
        else:
            utiles += buscar_fuente_alternativa(pregunta) # estado: incorrecto

    if not utiles:
        return "No he encontrado información suficiente para responder."

    respuesta = generar(pregunta, utiles)

    if not se_apoya_en_contexto(respuesta, utiles):
        respuesta = generar(pregunta, utiles, modo="estricto")
        if not se_apoya_en_contexto(respuesta, utiles):
            return "No puedo responder con la documentación disponible."

    return respuesta

Tres detalles del esqueleto merecen comentario. El primero: max_intentos no es decorativo. Sin un tope explícito de iteraciones, un sistema con reformulación automática puede quedarse dando vueltas indefinidamente sobre una pregunta cuya respuesta sencillamente no está en el corpus, acumulando llamadas y latencia hasta que alguien lo corte. Todo bucle de este tipo necesita un presupuesto duro de pasos.

El segundo: las dos ramas de salida devuelven una negativa explícita. Un sistema con verificación tiene que poder decir que no, y esa negativa debe llegar al usuario tal cual, no maquillada. Si el diseño del producto no admite esa respuesta, el bucle de verificación sobra, porque sus conclusiones no se pueden actuar.

El tercero: la comprobación de fundamentación va después de generar, lo que significa que en el peor caso se paga la generación dos o tres veces. Es el punto más caro del esquema y el primero que conviene aplicar selectivamente.

La cuenta

Los números son órdenes de magnitud, no medidas. Lo que la tabla sí muestra con fidelidad es la propiedad más incómoda de estos esquemas: la latencia deja de ser predecible. Una consulta fácil se resuelve casi como en la línea base; una difícil puede tardar tres o cuatro veces más. Un percentil 50 aceptable puede convivir con un percentil 95 inaceptable, y en un chat con respuesta en tiempo real eso se percibe como un sistema que a veces se cuelga.

Dos mitigaciones prácticas: usar modelos pequeños y rápidos para todos los juicios, reservando el grande sólo para la generación final, y transmitir al usuario que el sistema está trabajando —mostrar el paso en curso— en lugar de dejar la interfaz en blanco.

Cuándo se justifica y cuándo no

Se justifica cuando una respuesta incorrecta cuesta más que una respuesta lenta. Consulta de normativa, información con implicaciones económicas o contractuales, sistemas de cara al público en sectores regulados, cualquier contexto donde el usuario no tenga forma de detectar que la respuesta es falsa. También cuando el corpus tiene cobertura irregular y hay muchas preguntas legítimas sin respuesta en él: ahí la capacidad de decir «no está» vale más que cualquier mejora de recuperación.

No se justifica en tres casos. En un sistema interno con usuarios expertos que detectan el error de un vistazo, donde el coste de verificar es mayor que el del error. En interfaces con presupuesto de latencia estricto. Y, sobre todo, antes de haber agotado lo barato: si el sistema no tiene búsqueda híbrida, ni reranking, ni metadatos bien puestos, montar bucles de autoevaluación es poner un control de calidad sofisticado sobre una línea de producción defectuosa. El evaluador estará descartando fragmentos malos que no deberían haber llegado hasta ahí.

Una advertencia final sobre la fiabilidad del propio evaluador. Un modelo juzgando relevancia comete errores, y no simétricos: tiende a ser condescendiente y a aceptar como relevante material que sólo comparte tema con la pregunta. Un evaluador demasiado permisivo no aporta nada y cuesta; uno demasiado estricto convierte el sistema en una máquina de decir que no. El umbral es un parámetro de producto, no técnico, y hay que calibrarlo contra preguntas reales, incluidas las que no tienen respuesta en el corpus. Sin esas últimas en el conjunto de evaluación, no hay forma de medir si la verificación funciona.

Qué viene ahora

Queda un punto de rotura sin atacar: las preguntas cuya respuesta no está en ningún fragmento sino repartida por todo el corpus. Preguntas globales, de agregación, de relación entre entidades. La siguiente entrega entra en GraphRAG: extracción de entidades y relaciones, construcción del grafo, detección de comunidades y resúmenes jerárquicos, búsqueda local frente a global, y el coste de indexación —alto— que decide si merece la pena.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.