Donde los pipelines RAG actúan ciegamente: mapeo de fallos a patrones agentes

La receta estándar de generación reforzada con recuperación de información sigue una línea recta: recuperar, generar, responder. Funciona bien para demostraciones, pero las preguntas en entornos reales exponen rápidamente sus puntos ciegos. El sistema de recuperación devuelve fragmentos irrelevantes, el usuario formula la pregunta en términos que sus documentos nunca utilizan, la respuesta no está presente en el índice o el modelo escribe algo que el texto recuperado en realidad no respalda. Incluir más documentos en la instrucción de entrada no soluciona ninguno de estos problemas, ya que el problema no es la cantidad de contexto sino la falta de una decisión sobre qué hacer a continuación.

Esa capa de toma de decisiones es lo que se entiende por RAG agente. Esta guía lo trata como un conjunto de respuestas dirigidas a modos específicos de fallo en lugar de como una arquitectura única, para que pueda analizar su propio proceso, identificar el paso en el que actualmente actúa de forma automática e inconsciente y elegir el patrón más sencillo que lo resuelva.

Por qué falla el pipeline de un solo uso

Una aplicación RAG convencional ejecuta una secuencia fija: toma la pregunta, realiza una búsqueda de similitud en una base de datos vectorial, conserva los mejores resultados, los envía a un LLM y devuelve lo que este genera. La suposición oculta es que el paso de búsqueda tuvo éxito.

Cuando esa suposición falla, nada en el pipeline se da cuenta:

• Los documentos de mala calidad siguen siendo enviados al modelo, el cual intenta responder a partir de ellos.
• Una consulta cuyo vocabulario no coincide con los documentos obtiene pocos resultados útiles.
• Si la base de conocimientos simplemente carece de la respuesta, el sistema no tiene otra vía alternativa.

El cambio de perspectiva útil es dejar de preguntarse solo cómo mejorar la recuperación de información y empezar a preguntarse qué debe hacer el sistema cuando esa recuperación no es lo suficientemente buena. Cada patrón que se presenta a continuación es una respuesta a alguna versión de esa segunda pregunta. Si desea una comparación más amplia de las arquitecturas de recuperación antes de analizar los patrones individuales, consulte RAG vs agentic RAG vs graph RAG.

Evaluación de la recuperación e reescritura de la consulta

Tomemos una pregunta como “¿Cómo maneja LangGraph la persistencia?”. Supongamos que el sistema de recuperación devuelve cinco fragmentos de información y solo uno de ellos es relevante. Un proceso lineal envía los cinco fragmentos y deja que el modelo los clasifique, lo cual diluye las pruebas útiles y genera confusión.

Un flujo de trabajo basado en agentes inserta primero un paso de evaluación. Un evaluador, que suele ser una llamada a un modelo LLM pequeño con una rúbrica de sí/no, determina si los documentos recuperados son lo suficientemente relevantes como para responder a la pregunta. Si no lo son, el flujo de trabajo no simplemente vuelve a buscar con el mismo texto; en lugar de eso, genera una consulta mejorada, basada en los resultados del primer intento, y vuelve a buscar. El ciclo resultante es:

• recuperar
• evaluar los resultados
• reescribir la consulta si no son suficientes
• recuperar nuevamente

El ciclo en sí no es la parte valiosa. Lo importante es que el sistema pueda reconocer que su primer intento fue inadecuado. En la práctica, también se necesita una condición de parada, como un número máximo de reescrituras, para que una pregunta a la que el índice no puede responder no siga en un ciclo infinito.

Recurrir a alternativas cuando el índice carece de la respuesta

La reescritura solo sirve de ayuda si la información existe en algún lugar de su corpus. A menudo no es así. Imagine un asistente basado en documentación recopilada hace un mes, y que un usuario pregunta sobre una función anunciada ayer. Ninguna cantidad de reformulación podrá hacer aparecer un documento que nunca fue indexado.

RAG correctivo aborda este caso. Después de evaluar los documentos recuperados, el flujo de trabajo considera que un resultado insuficiente es una señal para corregir el rumbo, por ejemplo consultando una fuente diferente como la búsqueda en la web. El flujo lineal de recuperar y luego generar se convierte en:

• recuperar
• evaluar los documentos
• corregir, si la evaluación es deficiente
• generar

"Correcto" es deliberadamente un término amplio. Dependiendo de la aplicación, podría significar reescribir la consulta, consultar otra fuente o tomar alguna otra acción. La característica definitoria es que un intento de recuperación fallido desencadena un camino diferente en lugar de una respuesta insuficiente. Tenga en cuenta que agregar un recurso alternativo en la web modifica su modelo de confianza: el contenido público de la web está menos curado que su propia documentación, por lo que podría querer etiquetar o filtrar las respuestas que dependen de él.

Dirigir cada pregunta a la fuente adecuada

Otra suposición implícita en los sistemas RAG básicos es que cada pregunta debe llegar al mismo mecanismo de recuperación. Muchos sistemas reales cuentan con varias fuentes de conocimiento al mismo tiempo: documentación interna de la empresa, documentos públicos del producto, uno o más almacenes vectoriales y búsqueda en la web en tiempo real.

Esos orígenes no son intercambiables. Una pregunta sobre una política interna de recursos humanos no debe responderse a partir de la web abierta. Una pregunta sobre una versión de la biblioteca publicada la semana pasada no debe depender únicamente de un almacén de vectores creado antes de dicha publicación.

RAG adaptativo añade una decisión de enrutamiento al inicio. Antes de recuperar cualquier información, el sistema clasifica la pregunta y decide qué origen es el más adecuado para responderla, luego evalúa el contexto que proviene de ese origen. La ruta de recuperación se elige según cada pregunta en lugar de ser fija para todas ellas. Un enrutador puede ser tan simple como una pregunta de clasificación o un conjunto de reglas; no necesita ser sofisticado para eliminar toda una categoría de respuestas provenientes de orígenes incorrectos.

Revisar la respuesta, no solo los documentos

Un fallo más sutil es fácil de pasar por alto: una recuperación excelente no garantiza una buena respuesta. El modelo puede recibir exactamente los pasajes adecuados y, aun así, generar una respuesta que va más allá de ellos o se desvía de la pregunta.

La solución es evaluar también la salida. Después de la generación, un flujo de trabajo basado en agentes puede preguntar:

• ¿Cada afirmación en la respuesta está fundamentada en el contexto recuperado?
• ¿La respuesta aborda lo que realmente preguntó el usuario?
• ¿El modelo ha añadido información que el contexto no respalda?

Si la respuesta falla, el flujo de trabajo puede revisarla o regenerarla. Esto permite realizar dos verificaciones separadas que conviene mantener distintas: si se obtuvieron las informaciones correctas y si esas informaciones se utilizaron adecuadamente. Separarlas también facilita enormemente la depuración, ya que un fallo puede atribuirse a la fase de obtención o a la fase de generación, en lugar de simplemente decir “el bot se equivocó”. El artículo sobre evaluar RAG por fase de fallo profundiza en esa idea.

Pausa para una decisión humana

Algunos resultados no deben decidirse automáticamente. Los motivos típicos para una revisión humana incluyen:

• evidencias ambiguas o contradictorias
• respuestas que requieren aprobación formal antes de ser utilizadas
• baja confianza por parte de los propios evaluadores del sistema

Un borrador de respuesta que claramente necesita edición

El enfoque RAG con intervención humana incluye un punto de control en el flujo de trabajo donde alguien puede aprobar el resultado, rechazarlo o editarlo antes de que continúe la ejecución. Esto no representa un retroceso frente a la automatización. El sistema sigue manejando por sí mismo los casos rutinarios y solo eleva aquellos que realmente requieren juicio, lo cual suele ser un uso mucho mejor del tiempo de los revisores que verificarlo todo o nada. Los marcos de orquestación basados en grafos como LangGraph son muy adecuados para esto, ya que pueden conservar el estado del flujo de trabajo en ese punto de control y reanudarlo una vez que la persona haya respondido.

Distribuir el trabajo entre agentes especializados

A medida que los flujos de trabajo crecen, resulta difícil gestionar a un único agente encargado de todas las responsabilidades y darle instrucciones efectivas. Algunos problemas se descomponen naturalmente en roles distintos: recuperación de información, investigación, evaluación, etc.

Una configuración con supervisor multiagente asigna la tarea de coordinación a un agente específico. El supervisor decide qué especialista debe dar el siguiente paso, y cada especialista se ocupa de una tarea concreta. El objetivo no es añadir agentes por sí mismos; cada agente adicional genera latencia, costos y requiere más instrucciones para su mantenimiento. Vale la pena hacerlo cuando el problema realmente implica varios pasos o especialidades y las instrucciones para un solo agente se convierten en una lista ingobernable de casos especiales.

Ejecución independiente de la recuperación de información en paralelo

No es necesario esperar al paso anterior para avanzar al siguiente. Si una respuesta requiere información de varias fuentes independientes, consultarlas una tras otra —primero la fuente A, luego B y después C— antes de dar una respuesta es una pérdida de tiempo.

El patrón de distribución paralela realiza esas búsquedas al mismo tiempo: la pregunta se envía simultáneamente a A, B y C, y sus resultados se combinan antes de generar la respuesta. Las tareas de recuperación o procesamiento independientes se ejecutan en paralelo y se unen al final. Esto puede hacer que los flujos de trabajo complejos sean más rápidos y fáciles de estructurar, ya que cada ramificación es autónoma. La desventaja es que el paso de combinación debe manejar resultados superpuestos o contradictorios, y debe decidir qué hacer si una ramificación falla o se agota el tiempo asignado.

Planificar antes de ejecutar

Algunas preguntas no pueden responderse con una sola búsqueda. Requieren varias búsquedas, transformaciones intermedias o etapas de razonamiento cuyo orden es importante.

Plan-and-execute RAG aborda esto separando el proceso de pensamiento del de ejecución. El flujo se convierte en:

• recibir la pregunta
• elaborar un plan
• ejecutar los pasos planificados
• evaluar los resultados
• dar una respuesta

El planificador determina qué debe hacerse; la ejecución se encarga de los pasos individuales. Esto es especialmente útil para preguntas con varias partes, como comparaciones entre varios documentos, donde pasar directamente a las llamadas de herramientas tiende a generar respuestas superficiales o incompletas. Un plan también permite inspeccionar qué salió mal cuando algo falla, lo cual es más difícil con un agente que improvisa en cada paso.

¿Qué hace realmente que un sistema RAG sea agente?

Llamar a un LLM o calificar algo como agente no convierte por sí solo a un sistema en agente. La característica distintiva es que el sistema puede evaluar su situación y elegir su siguiente paso. Un flujo fijo supone una búsqueda seguida de una respuesta. Uno agente puede hacerse una serie de preguntas:

• ¿Es realmente necesaria la búsqueda para esta pregunta?
• ¿Fue útil lo que se obtuvo?
• ¿Debería buscar de nuevo con una consulta diferente?
• ¿Sería otra fuente más adecuada?
• ¿Está la respuesta respaldada por las pruebas?
• ¿Es necesario que interviniera un humano?
• ¿Debería asumir el control otro agente especializado?
• ¿Generaría planificar el trabajo primero un mejor resultado?

Cada pregunta corresponde a uno de los patrones anteriores, y por eso es útil considerar al RAG agente como una caja de herramientas con puntos de decisión en lugar de un diseño monolítico. Estos patrones se corresponden naturalmente con la orquestación de grafos: la calificación y el enrutamiento se convierten en aristas condicionales, los bucles se transforman en ciclos con un contador en el estado, la revisión humana pasa a ser una interrupción, y la expansión en ramas paralelas que se unen.

Asocia el patrón con la falla

Ninguna aplicación necesita todos estos patrones, ya que cada uno añade latencia, costo y componentes móviles. Elige según la falla que realmente observes:

• Si el principal problema es la calidad de la recuperación, podría ser suficiente reescribir las consultas con un evaluador de relevancia.
• Si la base de conocimientos tiene lagunas, agrega una fuente alternativa.
• Si utilizas varias fuentes de conocimiento, incorpora mecanismos de enrutamiento.
• Si algunas decisiones requieren supervisión, añade un punto de control humano.

Si el flujo de trabajo implica tareas especializadas distintas o búsquedas independientes, considere la posibilidad de contar con un supervisor o una estructura de distribución paralela.

Si las preguntas requieren varios pasos dependientes, añada una fase de planificación.

Conclusión

La pregunta que conduce a mejoras útiles no es cómo hacer que un sistema RAG sea más autónomo, sino dónde el sistema actúa actualmente de forma ciega: enviando documentos que nadie ha revisado, buscando en la fuente incorrecta, confiando en una respuesta sin fundamento o tomando decisiones que debería tomar una persona. Implemente herramientas en el proceso para poder identificar cuáles de estos fallos ocurren con mayor frecuencia, añada el punto de decisión más sencillo que permita abordar el más común y vuelva a medir antes de incorporar el siguiente.

Lecturas relacionadas

• Aprender Engineering de IA Agente con el Ensayo de Fallas en Order Failures Teach It — Un camino estructurado hacia el engineering de agentes: los modos de fallo que presentan, la capa fundamental, cinco proyectos ordenados, y los patrones de estado, revisión y seguridad que los mantienen seguros.
• De Texto Bruto a Tuberías: Analizadores, LCEL, Ejecutables y Memoria en LangChain — Cómo LangChain convierte el texto bruto del modelo en datos estructurados, compone pasos con LCEL y la interfaz Runnable, y gestiona la memoria conversacional en la actualidad.