El problema que RAG 2.0 resuelve
Si has construido un sistema RAG en producción con más de un agente o componente consumiendo la misma base de conocimiento, conoces el problema. Cada agente tiene su propio índice vectorial, su propia pipeline de indexación, su propia versión de la verdad sobre los documentos disponibles. Cuando el corpus se actualiza, hay que actualizar cada índice por separado. Cuando quieres aplicar una política de calidad o un filtro de seguridad, hay que hacerlo en cada pipeline de forma independiente. A medida que el sistema crece, el coste de mantenimiento crece en proporción directa al número de agentes.
RAG 2.0 resuelve esto con tres principios. El primero es la centralización del conocimiento: un único knowledge layer que todos los agentes consultan, en lugar de índices por agente. El segundo es la recuperación agéntica: el propio sistema de búsqueda razona sobre cómo recuperar la información, planifica consultas, selecciona fuentes e itera si los resultados no son suficientes, sin que el agente consumidor tenga que orquestar ese proceso. El tercero es la gobernanza unificada: las políticas de calidad, seguridad y actualización se configuran en un único punto y se aplican automáticamente a todas las consultas de todos los agentes.
Foundry IQ es la implementación de estos tres principios en Azure AI Search. Está disponible en vista previa pública desde finales de 2025 en aka.ms/FoundryIQ.
Arquitectura interna de una Knowledge Base en Foundry IQ
El flujo de procesamiento de una consulta en Foundry IQ tiene cinco etapas que se ejecutan de forma automatizada.
La consulta del agente — que puede ser una pregunta en lenguaje natural o una instrucción compleja — entra al módulo de Query Planning. Este módulo usa un LLM especializado en descomponer intención para analizar la consulta y generar N consultas más precisas y específicas. El LLM de planificación es distinto al LLM que el agente usa para generar respuestas finales; es un modelo más pequeño y rápido optimizado específicamente para análisis de intención y descomposición de consultas.
Las consultas generadas se ejecutan en paralelo contra las fuentes configuradas en la Knowledge Base: índices de Azure AI Search, OneLake, SharePoint, y Bing Web Knowledge. Cada fuente devuelve sus propios resultados con sus propias puntuaciones de relevancia.
Los resultados de todas las fuentes se fusionan en un conjunto unificado usando un proceso similar al RRF descrito en el artículo sobre búsqueda híbrida.
A continuación, el sistema evalúa si los resultados fusionados son suficientes para responder la consulta original. Esta evaluación es automática y se basa en cobertura temática, confianza en los fragmentos recuperados y completitud de la respuesta potencial.
Si los resultados no son suficientes, el sistema refina las consultas usando el contexto de lo que ya encontró y vuelve a ejecutar el proceso. Esta recuperación iterativa puede repetirse varias veces hasta alcanzar el criterio de suficiencia o el límite de iteraciones configurado.
Al final del proceso, Foundry IQ genera una síntesis de los resultados encontrados y un activity log completo que registra qué consultas generó el planificador, qué fuentes consultó, qué resultados obtuvo en cada iteración y por qué decidió iterar o detenerse. El activity log es una herramienta de debugging extraordinariamente útil que no tiene equivalente en sistemas RAG clásicos.
Los niveles de esfuerzo de recuperación
Foundry IQ expone tres niveles de esfuerzo que controlan el balance entre latencia, coste y calidad de los resultados.
Esfuerzo mínimo (minimal): Sin LLM para planificación, sin selección de fuentes, sin síntesis. El sistema ejecuta una búsqueda directa contra todas las fuentes configuradas con los parámetros por defecto. La latencia es mínima, típicamente inferior a 500ms. Este nivel es ideal para consultas simples en tool calls donde el agente necesita recuperación rápida sin razonamiento complejo. Es el nivel por defecto en la API según la documentación oficial.
Esfuerzo bajo (low): El LLM de planificación entra en juego para descomponer la consulta y seleccionar las fuentes más relevantes. Una sola iteración de búsqueda. El sistema genera síntesis de los resultados. La latencia suele estar entre 1 y 3 segundos. Este es el nivel por defecto recomendado para la mayoría de las consultas en sistemas de producción.
Esfuerzo medio (medium): Igual que bajo, pero con recuperación iterativa activada. Si los resultados de la primera iteración no son suficientes, el sistema refina las consultas y vuelve a buscar. Puede iterar entre 2 y 5 veces dependiendo de la complejidad de la consulta. La latencia puede variar entre 5 y 30 segundos. Este nivel está justificado solo cuando la calidad es más importante que la latencia: evaluaciones profundas de novedad, análisis comparativos complejos, síntesis que requieren cubrir múltiples ángulos de un tema.
La decisión de qué nivel usar para cada tipo de consulta en tu sistema es una de las decisiones de arquitectura más importantes. Usar esfuerzo medio para tool calls en tiempo real es un error de diseño común que genera experiencias de usuario pobres por latencia. Usar esfuerzo mínimo para evaluaciones de calidad que requieren cobertura exhaustiva produce resultados incompletos.
Fuentes disponibles en Foundry IQ
Azure AI Search (índices propios) es la fuente más madura y la que ofrece mayor control. Tus índices existentes se conectan directamente como fuentes de una Knowledge Base sin migración ni transformación. La búsqueda híbrida con reranking que describimos en el artículo sobre Azure AI Search se aplica automáticamente cuando la fuente es un índice de Azure AI Search.
OneLake y SharePoint son las fuentes de datos corporativos. Foundry IQ se conecta a ellas sin duplicar los datos: los consulta en tiempo de consulta mediante conectores nativos. Esto resuelve el problema clásico de sincronización entre el índice vectorial y la fuente de datos original.
Bing Web Knowledge es la fuente estratégica para información en tiempo real. Cuando el corpus indexado no puede responder una consulta sobre novedades recientes, cambios de producto o tendencias del mercado, Bing Web Knowledge completa la respuesta con información actual. Sin esta fuente, cualquier knowledge layer se queda obsoleto progresivamente.
Configuración en el portal de Azure
Crear una Knowledge Base en Foundry IQ desde el portal de Azure AI Foundry requiere cuatro pasos. Primero, navegar a Azure AI Search y acceder a la sección Knowledge Bases (en vista previa). Segundo, añadir las fuentes: para cada índice de Azure AI Search, se especifica el nombre del índice y la configuración semántica a usar. Tercero, configurar el modelo de planificación (un deployment de Azure OpenAI) y el modelo de síntesis. Cuarto, probar la Knowledge Base desde el playground integrado, donde el activity log es visible directamente.
La API de consulta es consistente independientemente de las fuentes configuradas:
from azure.ai.search import SearchIndexClient
from azure.ai.search.models import KnowledgeBaseQuery
client = SearchIndexClient(endpoint, credential)
response = client.query_knowledge_base(
knowledge_base_name="azurebrains-kb",
query=KnowledgeBaseQuery(
query_text="¿Qué es RAG 2.0 y cómo lo implementa Foundry IQ?",
effort_level="low",
top=5
)
)
print(response.answer)
print(response.activity_log)
El activity log como herramienta de observabilidad
Una de las características más valiosas de Foundry IQ en operaciones es el activity log. Para cada consulta, el log registra la consulta original recibida, las N consultas generadas por el planificador con el razonamiento de por qué se generaron esas variantes específicas, las fuentes consultadas y por qué se seleccionaron esas fuentes, los resultados obtenidos en cada iteración con sus puntuaciones de relevancia, la decisión de iterar o detenerse con la justificación, y la síntesis final generada.
En un sistema RAG clásico, cuando los resultados son malos, es difícil saber por qué: ¿la consulta era mala? ¿El índice no tiene el documento correcto? ¿El chunk era demasiado pequeño? El activity log de Foundry IQ hace visible todo ese proceso interno, convirtiendo el debugging de problemas de calidad de recuperación de un arte oscuro en un proceso sistemático.
Foundry IQ como spine del sistema de agentes de Azurebrains
El blog que estás leyendo ahora mismo es mantenido por el sistema de cinco agentes que usa Foundry IQ como knowledge layer centralizado. Los detalles completos de la arquitectura están en el artículo El sistema de agentes de Azurebrains: arquitectura completa, pero el papel de Foundry IQ es el siguiente: tanto el Discoverer como el Analyzer, el Reuser, el Writer y el Improver consultan la misma Knowledge Base con diferentes niveles de esfuerzo según sus necesidades. El Discoverer usa esfuerzo bajo para deduplicación rápida. El Analyzer usa esfuerzo medio para evaluaciones de novedad profundas. El Improver usa esfuerzo bajo con Bing Web Knowledge activado para detectar obsolescencia. Ningún agente tiene su propio índice. Todos hablan con el mismo knowledge layer.
Esta arquitectura centralizada es lo que permite añadir un nuevo agente al sistema sin multiplicar la infraestructura de conocimiento ni crear nuevas fuentes de inconsistencia. Es RAG 2.0 en producción.