Corrective RAG y Self-RAG: patrones de recuperación autocorrectivos para reducir alucinaciones

Corrective RAG (CRAG) y Self-RAG son dos patrones de recuperación autocorrectivos que amplían el esquema clásico de RAG con un control de calidad. CRAG evalúa la relevancia de los resultados recuperados y, cuando la calidad de la recuperación es baja, recurre a un fallback de búsqueda web. Self-RAG deja que el modelo de lenguaje decida por sí mismo, mediante tokens de reflexión, si necesita recuperar información y, después, comprueba si su propia respuesta está respaldada por las fuentes. Ambos apuntan al mismo problema: las alucinaciones que se producen a pesar del RAG.

• CRAG en una frase: un evaluador de recuperación clasifica los resultados como correctos, ambiguos o incorrectos y, si el contexto es deficiente, activa una medida correctiva en lugar de seguir generando a ciegas.
• Self-RAG en una frase: el modelo controla por sí mismo, mediante tokens de reflexión entrenados, cuándo recupera información y si su respuesta encaja con las fuentes.
• Núcleo común: ambos pertenecen a la familia de patrones de Agentic RAG y no tratan la recuperación como un preprocesamiento estático, sino como un paso verificable y controlable.

Por qué el RAG clásico no basta

El RAG estándar (Naive RAG según la taxonomía de Gao et al. 2023, arXiv:2312.10997) sigue un flujo fijo: vectorizar, recuperar, insertar en el prompt, generar. El problema: el pipeline confía a ciegas en los resultados top-k. Si son semánticamente similares pero irrelevantes en su contenido, o si directamente no existen, el modelo genera una respuesta igualmente y la apoya en fuentes inservibles.

Hay dos patrones de error típicos. En la context-unfaithful generation, el modelo cita fuentes, pero se aparta de su contenido. Las contramedidas habituales son los guardrails de fidelidad, la autocrítica y los prompts que obligan a citar (citation forcing). El segundo patrón de error aparece cuando no hay re-ranking: los resultados top-k suelen ser similares, pero no relevantes. Justo ahí entran CRAG y Self-RAG: hacen que la calidad de la recuperación sea explícitamente verificable y reaccionan en consecuencia.

Para situarlo bien: la mayor palanca contra las alucinaciones sigue estando en la propia calidad de la recuperación. Anthropic Contextual Retrieval reduce la tasa de error de recuperación top-20 en un 49 % (del 5,7 al 2,9 %) y, combinado con re-ranking, en un 67 % (hasta el 1,9 %); se trata de benchmarks del propio proveedor, Anthropic, con datos de septiembre de 2024. La autocorrección es la segunda línea de defensa, no la primera.

Corrective RAG (CRAG): evaluar los resultados y luego corregir

CRAG añade al pipeline un evaluador de recuperación. Después de la recuperación, pero antes de la generación, este evaluador valora la relevancia de los documentos encontrados y los clasifica en tres clases de confianza:

• Correct (confianza alta): los resultados son relevantes. Se refinan (por ejemplo, mediante decompose-recompose, para eliminar ruido) y se pasan al generador.
• Incorrect (confianza baja): los resultados no sirven. En lugar de generar sobre un contexto deficiente, se activa un fallback, normalmente una búsqueda web, para incorporar contenido externo actualizado.
• Ambiguous (confianza media): hay incertidumbre. Se combinan ambas vías: contexto interno más resultados de la búsqueda web.

El mecanismo decisivo es el fallback de búsqueda web cuando la calidad de la recuperación interna es baja. Así, CRAG compensa una base de conocimiento incompleta o desactualizada sin que el modelo empiece a alucinar. CRAG es independiente del modelo: se puede colocar como nodo adicional delante de cualquier pipeline de RAG existente sin reentrenar el LLM generador. CRAG se remonta a Yan et al. 2024 (arXiv:2401.15884).

Self-RAG: el modelo se critica a sí mismo

Self-RAG (Asai et al., University of Washington, arXiv:2310.11511, octubre de 2023) traslada el control al modelo. Se entrena para generar los llamados tokens de reflexión, con los que dirige y evalúa su propio proceso. De forma simplificada, se toman cuatro decisiones:

• Retrieve? El modelo decide en cada consulta (o en cada segmento) si la recuperación es realmente necesaria. Las preguntas triviales o ya cubiertas por el conocimiento del modelo no requieren recuperación.
• Is Relevant? El modelo evalúa si el pasaje recuperado es relevante para la pregunta.
• Is Supported? Tras la recuperación, el modelo comprueba si la afirmación generada está respaldada por el pasaje recuperado: una autocrítica de fidelidad integrada.
• Is Useful? El modelo valora en una escala del 1 al 5 lo útil que es la respuesta para la pregunta.

Lo atractivo: el modelo solo recupera información cuando él mismo lo considera necesario (lo que ahorra costes en preguntas sencillas). Durante la generación, Self-RAG produce varios segmentos candidatos, los evalúa mediante una puntuación ponderada a partir de los tokens de crítica (relevancia, respaldo, utilidad) y se queda con el mejor valorado (Asai et al. 2023). Negarse a responder o escalar a una persona no forma parte del método, aunque se puede construir sobre estos tokens. El precio: la implementación original de Self-RAG presupone un modelo entrenado específicamente con tokens de reflexión. En la práctica, muchos equipos aproximan ese comportamiento con prompting y un bucle de autocrítica sobre un modelo estándar, lo que resulta más barato de implementar, pero menos fiable que un modelo entrenado para ello.

Comparativa: CRAG vs. Self-RAG vs. RAG estándar

Según la taxonomía de evolución de RAG (Naive, Advanced, Modular, Graph, Agentic), ambos patrones se sitúan en la etapa de Agentic RAG. Singh et al. 2025 (arXiv:2501.09136) describen Agentic RAG como patrones en los que la recuperación funciona como una herramienta que un agente invoca de forma dinámica e iterativa, con reflexión, planificación y uso de herramientas. Self-RAG no aparece en este trabajo de revisión, pero encaja como ejemplo temprano, porque es el propio modelo el que decide sobre la recuperación. Singh et al. presentan Corrective RAG como arquitectura propia (Agentic Corrective RAG). Para ser honestos, hay que añadir que en 2026 el término Agentic RAG todavía no está claramente consolidado.

Ejemplo concreto: base de conocimiento de soporte con lagunas

Supongamos que una agencia gestiona para un cliente B2B un asistente de soporte basado en RAG sobre una base de conocimiento interna. Un usuario pregunta por una funcionalidad que se publicó ayer en una nota de versión que todavía no está indexada.

• RAG estándar: recupera los tres documentos antiguos más similares, no encuentra la respuesta y alucina una configuración que suena plausible, pero es incorrecta. Una alucinación clásica a pesar del RAG.
• CRAG: el evaluador de recuperación clasifica los resultados como incorrect (baja confianza en la relevancia), lanza una búsqueda web en la documentación pública del producto, encuentra la nota de versión y genera una respuesta correcta con su fuente.
• Self-RAG: el modelo clasifica los chunks recuperados como irrelevantes mediante el token Is Relevant y detecta, con el token Is Supported, que ninguna respuesta está respaldada por ellos. Una regla de aplicación construida sobre esto suprime entonces la respuesta sin respaldo y la escala a una persona.

Un cálculo sobre la contrapartida: si una llamada de RAG estándar cuesta, por ejemplo, una invocación al LLM, CRAG añade al menos una llamada al evaluador y, cuando se activa el fallback, el procesamiento de la búsqueda web; un bucle de autocrítica al estilo Self-RAG puede suponer más llamadas según el diseño. En preguntas sencillas, Self-RAG puede incluso ahorrarse el paso de recuperación. Como regla general: la autocorrección no es una mejora gratuita, sino un intercambio consciente de latencia y costes adicionales por un menor riesgo de alucinación. En los sistemas de RAG agénticos se suma un riesgo típico: bucles de herramientas descontrolados que multiplican el coste por consulta.

Cuándo tienen sentido estos patrones

Los patrones autocorrectivos compensan cuando se cumple al menos uno de estos puntos:

• La base de conocimiento está incompleta o desactualizada, y un fallback a la web o a fuentes de terceros cubre lagunas reales (CRAG).
• Las respuestas erróneas salen caras: derecho, finanzas, soporte regulado, todo lo que implique responsabilidad legal.
• Negarse a responder en caso de incertidumbre es deseable y aceptado (Self-RAG aporta para ello los tokens de crítica).

Tienen menos sentido si la base de conocimiento está completa y bien indexada, si la latencia es prioritaria o si el presupuesto por consulta es ajustado. En esos casos, las medidas más baratas de la etapa de Advanced RAG suelen ofrecer una mejor relación coste-beneficio: búsqueda híbrida (dense más BM25 para no perder códigos exactos), Contextual Retrieval contra los chunks a los que les falta el contexto circundante, re-ranking con cross-encoder y un guardrail de fidelidad con RAGAS en el pipeline de CI. Según Anthropic, Contextual Retrieval (embeddings contextualizados más BM25 sobre los chunks contextualizados), combinado con re-ranking, reduce la tasa de error de recuperación hasta en un 67 %. Solo después merece la pena añadir CRAG o Self-RAG de forma selectiva en las rutas críticas.

Para agencias y responsables de decisiones B2B

Para las agencias, el mensaje a los clientes es claro: los patrones de recuperación autocorrectivos no son una funcionalidad estándar que se activa sin más, sino una inversión específica para casos de uso con alto riesgo de alucinación. El camino pragmático pasa por una línea base medible (medir la calidad de la recuperación y la fidelidad con RAGAS) y añade CRAG o Self-RAG solo donde las cifras lo justifiquen. En proyectos B2B en Europa hay que tener en cuenta, además, que un fallback de búsqueda web (CRAG) debe estar alineado con la gobernanza de protección de datos y de fuentes, ya que de repente entra contenido externo en la cadena de respuesta. Blck Alpaca diseña arquitecturas RAG de forma que la autocorrección esté donde marca la diferencia y no infle costes y latencia en todas partes.