El equipo de investigación de Google ha introducido un nuevo marco RAG agente. Está integrado en la plataforma Gemini Enterprise Agent. Impulsa una función llamada Cross-Corpus Retrieval, ahora en versión preliminar pública.
El objetivo es un modo de fallo conocido en la búsqueda empresarial. El RAG estándar de un solo paso no se creó para consultas de múltiples fuentes y múltiples saltos. Pregunte “¿Cuáles son las especificaciones del servidor utilizado en el Proyecto X?” El sistema puede encontrar un documento con el nombre de un ID de servidor. No sabrá tomar esa identificación y buscar especificaciones en una segunda base de datos. La respuesta es parcial o “no encontrada”.
¿Qué es el nuevo Agentic RAG de Google?
Agentic RAG planifica, razona e interactúa de forma iterativa con fuentes de datos. Maneja consultas complejas para aumentar la confiabilidad y la precisión. La versión de Google es la recuperación entre corpus alojada en la plataforma Gemini Enterprise Agent con tecnología de Agentic RAG. Al igual que otros marcos RAG de múltiples agentes, utiliza agentes que trabajan juntos. A diferencia de ellos, agrega una verificación de contexto suficiente antes de generar una respuesta. En comparación con el RAG estándar, aumenta la precisión de los conjuntos de datos factuales hasta en un 34 %. El equipo de investigación de Google también lo probó en conjuntos de datos internos propietarios. Informa una mejor base y una mayor precisión del razonamiento en tareas de dominios específicos.
Cómo funciona la arquitectura multiagente
Piense en ello como un departamento de investigación organizado, no como un motor de búsqueda. Un sistema RAG “Vainilla” simplemente relaciona su pregunta con los documentos. Luego, un LLM genera una respuesta a partir de esas coincidencias. El marco de múltiples agentes divide el trabajo en roles especializados.
El orquestador decide que la solicitud no es un trabajo de un solo paso y la delega. El Agente Planificador mapea las rutas de información entre las fuentes de datos. Query Rewriter convierte una solicitud vaga en varias consultas de búsqueda precisas. El agente Search Fanout envía esas consultas a varias fuentes de recuperación. Finalmente, un LLM agrega el contexto recopilado en una respuesta.
¿Qué hace que este marco sea diferente?
La diferencia clave es la persistencia. El marco sabe cuándo falta información y sigue buscando. Esto evita que el modelo adivine cuándo la primera búsqueda está vacía. También evita un prematuro “no tengo suficiente información”.
Esa persistencia proviene del Agente de Contexto Suficiente, un nuevo componente en el marco de Google. Considere un médico que solicita medicamentos para el alta, restricciones dietéticas y reacciones alérgicas de un paciente.
En la Fase 1, Orquestación, el Agente raíz analiza la solicitud y delega. El agente planificador se dirige a farmacia, nutrición y notas clínicas. Query Rewriter divide la solicitud larga en preguntas simples que permiten realizar búsquedas.
En la Fase 2, Búsqueda, el Agente RAG ejecuta todas las consultas a la vez. Encuentra medicamentos y dieta, pero no menciona alergias. Un sistema Vanilla RAG podría detenerse aquí con una respuesta incompleta.
En la Fase 3, el Agente de Contexto Suficiente inspecciona el resultado. Lee los fragmentos recuperados extraídos de la base de datos. Revisa un borrador intermedio comparándolo con el mensaje y los fragmentos. Luego ejecuta un análisis de piezas faltantes. No sólo señala un “contexto insuficiente”. Escribe un registro de motivos y comentarios específico que nombra la brecha.
En la Fase 4, Iteración, Query Rewriter crea una nueva búsqueda para el término que falta. El agente RAG investiga los archivos que omitió y encuentra los datos.
En la Fase 5, Síntesis, el agente confirma que el contexto está completo. Luego, el agente de síntesis escribe un resumen limpio y preciso.
El caso de referencia
El equipo de Google evaluó el sistema en FramesQA, que se basa en el artículo de investigación de FRAMES. FramesQA tiene 824 consultas y un corpus de 2676 documentos PDF. La línea de base “Vanilla” utilizó el motor RAG de Google. Ese motor incluye un motor de recuperación avanzado, un analizador LLM y un reclasificador.
Agentic RAG se ejecutó en dos configuraciones. El corpus único se recupera únicamente de los documentos de FramesQA. Cross-corpus agrega tres conjuntos de datos que distraen, por lo que el agente planificador debe elegir dónde recuperarlos. Esto imita a las empresas cuyas bases de datos son administradas por equipos separados. La precisión utilizó un LLM como juez contra las respuestas reales.
En corpus cruzados, el sistema casi igualó su precisión de corpus único. Respondió correctamente al 90,1% de las preguntas y seleccionó el corpus correcto entre cuatro. La latencia se mantuvo dentro del 3% en promedio entre las dos configuraciones.
Casos de uso
El marco se adapta al trabajo empresarial de múltiples saltos y múltiples fuentes. Los equipos de atención médica pueden recopilar datos sobre medicamentos, dieta y alergias a partir de registros separados. Los equipos de ingeniería pueden rastrear la identificación de un servidor hasta las especificaciones de otra base de datos. Los equipos de finanzas y proyectos pueden unir datos presupuestarios con registros de cronograma. El diseño entre corpus se adapta a organizaciones con bases de datos propiedad de diferentes equipos.
Conclusiones clave
El RAG agente de Google agrega un Agente de contexto suficiente que vuelve a buscar hasta que se completa el contexto. Se envía como Cross-Corpus Retrieval en Gemini Enterprise Agent Platform, en versión preliminar pública. La ganancia reportada es hasta un 34% mayor en precisión de factibilidad en comparación con el RAG estándar. El enrutamiento entre corpus respondió el 90,1% de las preguntas de FramesQA al seleccionar entre cuatro corpus. La latencia se mantuvo dentro del 3% entre ejecuciones de un solo corpus y de corpus cruzados.
Consulta los detalles técnicos. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 150.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros
Michal Sutter es un profesional de la ciencia de datos con una Maestría en Ciencias de Datos de la Universidad de Padua. Con una base sólida en análisis estadístico, aprendizaje automático e ingeniería de datos, Michal se destaca en transformar conjuntos de datos complejos en conocimientos prácticos.
