El problema que intenta resolver RAG 2.0
Cuando un sistema de IA generativa pasa de un único asistente a una arquitectura con varios agentes, el patrón RAG tradicional suele empezar a duplicarse.
Un agente tiene su propio índice. Otro agente mantiene una variante del mismo corpus. Un tercer componente usa una pipeline de indexación diferente. Cada uno aplica sus propios filtros, sus propios prompts, su propia lógica de recuperación y sus propias decisiones sobre qué documentos son relevantes.
Al principio parece manejable. En producción, aparecen los problemas:
- varias versiones de la verdad sobre el mismo contenido;
- pipelines de ingesta duplicadas;
- políticas de acceso difíciles de auditar;
- cambios de esquema que deben replicarse en varios sitios;
- resultados inconsistentes entre agentes;
- mayor coste operativo cada vez que se añade un nuevo caso de uso.
En este artículo uso RAG 2.0 como una forma práctica de describir la evolución desde un RAG aislado por aplicación hacia una capa de conocimiento compartida, gobernada y reutilizable por múltiples agentes. No es un SKU ni un nombre formal de producto de Microsoft; es un patrón de arquitectura.
La idea central es sencilla: en lugar de que cada agente construya su propio sistema de recuperación, los agentes consumen una capa común de conocimiento. Esa capa se encarga de conectar fuentes, aplicar criterios de recuperación, devolver fragmentos citables y facilitar la observabilidad.
En el ecosistema de Microsoft, Foundry IQ apunta precisamente a ese papel: proporcionar una capa de conocimiento para agentes dentro de Microsoft Foundry, apoyándose en capacidades de búsqueda, recuperación y conexión con datos empresariales.
Qué es Foundry IQ en este contexto
Foundry IQ puede entenderse como una plataforma para conectar agentes con conocimiento empresarial mediante bases de conocimiento reutilizables. Su objetivo no es reemplazar todo el diseño de RAG, sino abstraer parte de la complejidad que normalmente se repite en cada agente.
En una arquitectura multi-agente, esto permite separar responsabilidades:
- los agentes mantienen la lógica de tarea, conversación, herramientas e instrucciones;
- la capa de conocimiento concentra las fuentes, la recuperación, las citas y parte de la gobernanza;
- los sistemas de datos siguen siendo la fuente de la verdad: índices de Azure AI Search, almacenamiento documental, SharePoint, OneLake u otras fuentes soportadas según la configuración disponible.
Esta separación es importante. Foundry IQ no convierte automáticamente cualquier repositorio documental en una experiencia RAG perfecta. Sigue siendo necesario diseñar bien los datos, controlar permisos, validar la calidad de los fragmentos y evaluar las respuestas. Lo que cambia es que esas decisiones pueden centralizarse más, en lugar de repetirse agente por agente.
Arquitectura conceptual de una capa de conocimiento compartida
Una arquitectura basada en Foundry IQ suele tener cuatro bloques principales.
1. Fuentes de conocimiento
El primer bloque son las fuentes. Según la documentación y materiales de Microsoft sobre Foundry IQ, el patrón contempla la conexión con fuentes como:
- Azure AI Search;
- Blob Storage;
- SharePoint;
- OneLake.
La disponibilidad concreta de conectores y opciones puede depender de la región, del tipo de proyecto en Foundry, de la versión de la experiencia y del estado de preview de cada capacidad.
En la práctica, Azure AI Search sigue siendo una pieza especialmente relevante cuando necesitas control fino sobre esquemas, campos buscables, filtros, ranking, búsqueda híbrida o preparación avanzada del índice.
2. Knowledge base
La knowledge base actúa como unidad lógica de conocimiento. No debería verse solo como “un índice vectorial más”, sino como una definición reutilizable que agrupa fuentes, configuración de recuperación e instrucciones para que los agentes consulten conocimiento de forma coherente.
Una misma organización puede tener varias knowledge bases. De hecho, suele ser recomendable separarlas por:
- dominio funcional;
- nivel de confidencialidad;
- audiencia;
- requisitos regulatorios;
- ciclo de vida del contenido;
- patrón de uso.
Un error frecuente en arquitecturas RAG es intentar crear una única base global para todo. En entornos empresariales, normalmente es más seguro y mantenible diseñar knowledge bases alineadas con límites reales de seguridad y responsabilidad.
3. Agentes consumidores
Los agentes no deberían conocer todos los detalles internos de cada fuente. Su responsabilidad es expresar una necesidad de información y utilizar el resultado de forma controlada.
Por ejemplo:
- un agente de soporte puede recuperar procedimientos y documentación operativa;
- un agente comercial puede consultar fichas de producto aprobadas;
- un agente de análisis puede comparar políticas o informes;
- un agente de gobierno puede verificar si una respuesta cita fuentes aceptadas.
El valor aparece cuando varios agentes pueden usar la misma capa de conocimiento sin duplicar ingestión, embeddings, conectores o lógica de recuperación.
4. Evaluación y observabilidad
La recuperación es una parte crítica del sistema, no una caja negra que se configura una vez y se olvida.
Para operar una solución de este tipo conviene monitorizar:
- consultas que no encuentran resultados útiles;
- documentos recuperados con frecuencia;
- fragmentos recuperados pero no utilizados;
- respuestas sin citas o con citas débiles;
- latencia por tipo de consulta;
- diferencias entre agentes que consultan la misma knowledge base;
- regresiones tras cambios en documentos, chunking o configuración.
Foundry IQ y Microsoft Foundry se orientan a facilitar el desarrollo y evaluación de agentes con conocimiento, pero la responsabilidad de definir métricas de calidad sigue siendo del equipo que construye la solución.
Recuperación agéntica: qué conviene afirmar y qué no
En muchos debates recientes se habla de agentic retrieval o recuperación agéntica. La idea general es que el sistema de recuperación no se limite a ejecutar una búsqueda literal, sino que pueda interpretar mejor la intención, transformar la consulta, consultar varias fuentes o estructurar mejor los resultados para un agente.
Ese patrón es muy útil, pero conviene evitar afirmaciones demasiado específicas si no están confirmadas para la versión exacta que estás usando.
Por ejemplo, es razonable decir que una capa moderna de recuperación puede ayudar con:
- comprensión de intención;
- reformulación de consultas;
- acceso a varias fuentes;
- generación de respuestas con citas;
- integración con agentes;
- evaluación y monitorización de la calidad de recuperación.
En cambio, no conviene asumir sin validación que una implementación concreta ofrece siempre:
- un número determinado de iteraciones;
- un modelo específico para planificación;
- selección automática de fuentes en todos los escenarios;
- latencias garantizadas;
- una API estable;
- compatibilidad idéntica entre portal, SDK y REST API;
- comportamiento apto para producción si la capacidad está en preview.
La arquitectura debe diseñarse teniendo en cuenta que muchas capacidades avanzadas de recuperación evolucionan rápidamente y pueden tener diferencias entre experiencias de portal, API y SDK.
Perfiles de recuperación: rápido, equilibrado y exhaustivo
Aunque no conviene inventar nombres de parámetros ni valores de API, sí es útil pensar en perfiles de recuperación desde el diseño de la aplicación.
En un sistema multi-agente no todas las consultas merecen el mismo coste.
Perfil rápido
Adecuado para consultas sencillas o interacciones donde la latencia es crítica.
Ejemplos:
- recuperar una definición breve;
- buscar un documento conocido;
- completar un dato operativo;
- responder a una tool call que forma parte de un flujo mayor.
Aquí interesa limitar el trabajo de recuperación y devolver pocos resultados muy relevantes.
Perfil equilibrado
Adecuado para la mayoría de las consultas de negocio.
Ejemplos:
- responder preguntas sobre documentación interna;
- resumir una política;
- comparar dos procedimientos;
- encontrar información relacionada en varias fuentes del mismo dominio.
Este perfil busca un equilibrio entre calidad, coste y latencia.
Perfil exhaustivo
Adecuado para análisis donde la cobertura es más importante que la velocidad.
Ejemplos:
- revisar impacto de cambios normativos;
- comparar documentación de varios equipos;
- preparar una respuesta que debe citar múltiples fuentes;
- analizar inconsistencias entre documentos.
Este perfil puede justificar más reformulación, más fuentes o más validación, siempre que el usuario entienda la latencia esperada.
La decisión importante no es si existe un parámetro llamado de una forma u otra, sino que la arquitectura distinga entre consultas baratas y consultas que merecen más esfuerzo de recuperación.
Fuentes corporativas y permisos
Uno de los puntos delicados de cualquier sistema RAG empresarial es la seguridad.
Conectar SharePoint, almacenamiento documental o data lake no significa que todo agente deba poder recuperar todo. La capa de conocimiento debe respetar los límites de acceso definidos por la organización.
Antes de llevar una solución a producción, conviene validar:
- cómo se autentica el agente o la aplicación;
- si se aplican permisos del usuario final, de la aplicación o de ambos;
- qué ocurre con documentos restringidos;
- cómo se filtran resultados por identidad, grupo o atributo;
- si las citas pueden revelar metadatos sensibles;
- dónde se procesan y almacenan los datos durante la recuperación;
- qué límites aplican si una capacidad está en preview.
La gobernanza no se consigue solo centralizando la búsqueda. Se consigue combinando diseño de conocimiento, control de identidad, auditoría, evaluación y límites explícitos por dominio.
Cómo diseñar una knowledge base para agentes
Un buen diseño de knowledge base empieza antes de conectar la primera fuente.
Estas son decisiones que conviene tomar de forma explícita.
Definir el dominio
Una knowledge base debe tener un propósito claro.
No es lo mismo una base para soporte técnico que una base para cumplimiento normativo. El tipo de documentos, el nivel de precisión requerido, la longitud de fragmentos y el tono de respuesta pueden ser muy distintos.
Preparar el contenido
RAG no compensa automáticamente contenido desordenado.
Antes de indexar o conectar fuentes, conviene revisar:
- duplicados;
- documentos obsoletos;
- versiones contradictorias;
- PDFs escaneados con OCR deficiente;
- tablas difíciles de interpretar;
- páginas sin título o sin metadatos;
- permisos heredados incorrectamente.
La calidad de la respuesta final depende en gran medida de la calidad del contenido recuperado.
Diseñar metadatos
Los metadatos son esenciales para filtrar y gobernar.
Algunos campos habituales:
- tipo de documento;
- propietario;
- fecha de vigencia;
- área funcional;
- nivel de confidencialidad;
- idioma;
- versión;
- estado de aprobación.
Sin metadatos, la recuperación suele depender demasiado del texto libre y es más difícil controlar qué documentos debe usar cada agente.
Exigir citas
Para agentes empresariales, las citas no son un adorno. Son una condición de confianza.
Las instrucciones del agente deberían dejar claro cuándo debe citar, cómo debe hacerlo y qué debe responder cuando no encuentra evidencia suficiente.
Una regla práctica: si la respuesta afecta a una decisión de negocio, debe poder rastrearse hasta una fuente verificable.
Evaluar con preguntas reales
No basta con probar tres preguntas en el playground.
Una evaluación mínima debería incluir:
- preguntas frecuentes;
- preguntas ambiguas;
- consultas con terminología distinta a la usada en los documentos;
- preguntas sin respuesta en el corpus;
- documentos con información parecida pero no idéntica;
- casos con permisos restringidos;
- consultas multi-idioma si aplican.
El objetivo no es demostrar que el sistema responde bien en demos, sino detectar dónde falla antes de exponerlo a usuarios reales.
Configuración práctica: una secuencia razonable
Sin depender de nombres concretos de menús o clases de SDK, una configuración típica seguiría esta secuencia:
- Crear o seleccionar el proyecto de agentes en Microsoft Foundry.
- Definir la knowledge base que utilizarán uno o varios agentes.
- Conectar las fuentes relevantes, por ejemplo un índice de Azure AI Search, documentos en almacenamiento o repositorios corporativos soportados.
- Configurar instrucciones de recuperación y respuesta, incluyendo cuándo citar y cómo comportarse si no hay evidencia suficiente.
- Probar con consultas representativas, no solo con ejemplos simples.
- Revisar resultados, citas y trazas disponibles para entender qué documentos se están usando.
- Ajustar contenido, metadatos, filtros e instrucciones.
- Publicar gradualmente, empezando por usuarios o agentes con alcance controlado.
- Monitorizar calidad y seguridad de forma continua.
La parte importante es no tratar la knowledge base como un componente estático. En producción, la base de conocimiento evoluciona igual que evoluciona el contenido de la organización.
Patrón multi-agente para Azurebrains
En una arquitectura como Azurebrains, donde pueden existir varios agentes especializados, Foundry IQ encaja como capa común de conocimiento.
Un diseño posible sería:
- un agente Discoverer consulta la knowledge base para detectar si un tema ya está cubierto;
- un agente Analyzer recupera fuentes y documentos relacionados para evaluar profundidad o novedad;
- un agente Writer usa fragmentos citables para redactar contenido;
- un agente Reviewer comprueba afirmaciones contra fuentes aprobadas;
- un agente Improver identifica contenido obsoleto o incompleto.
La ventaja no es solo técnica. También es operativa: al añadir un nuevo agente, no hace falta crear otra pipeline de conocimiento desde cero. El nuevo agente puede reutilizar las mismas fuentes, políticas y criterios de recuperación, siempre que tenga permisos y propósito adecuados.
Esto reduce duplicidad y mejora la consistencia. Pero no elimina la necesidad de evaluar cada agente por separado, porque dos agentes pueden usar la misma knowledge base y aun así producir resultados de distinta calidad por sus instrucciones, herramientas o flujo de razonamiento.
Riesgos y límites a tener en cuenta
Foundry IQ es prometedor para arquitecturas multi-agente, pero conviene diseñar con cautela.
Principales riesgos:
- Dependencia de capacidades en preview: las APIs, experiencias de portal o límites pueden cambiar.
- Exceso de centralización: una única knowledge base global puede convertirse en un cuello de botella de seguridad y calidad.
- Confianza excesiva en la recuperación automática: la capa de conocimiento no corrige documentos obsoletos o contradictorios.
- Falta de evaluación: sin datasets de prueba, no sabrás si una mejora aparente empeora casos importantes.
- Permisos mal modelados: el RAG empresarial debe respetar límites de acceso igual que cualquier otra aplicación corporativa.
- Citas débiles: citar un documento no garantiza que la respuesta esté correctamente fundamentada en él.
La recomendación práctica es empezar con un dominio acotado, medir calidad y ampliar después.
Conclusión
RAG 2.0 no debería entenderse como “usar vectores con un nombre nuevo”. El cambio relevante es arquitectónico: pasar de sistemas RAG aislados por agente a una capa de conocimiento compartida, gobernada y reutilizable.
Foundry IQ apunta a resolver precisamente ese problema dentro del ecosistema Microsoft Foundry: conectar agentes con conocimiento empresarial, permitir que varias experiencias reutilicen una misma base y mejorar la consistencia de las respuestas con fuentes y citas.
Para arquitectos y equipos técnicos, la pregunta clave no es solo “¿qué conector soporta?”, sino:
- qué dominios de conocimiento deben separarse;
- qué agentes pueden consultar cada base;
- qué permisos se aplican;
- cómo se evalúa la calidad;
- cómo se observan fallos de recuperación;
- cómo se evita que contenido obsoleto llegue a respuestas finales.
Si esas decisiones están bien diseñadas, Foundry IQ puede convertirse en una pieza central para sistemas multi-agente sobre Azure y Microsoft Foundry.