MSTech Geeks

La pelea con los RAGs artesanales, poco a poco, va llegando a su fin gracias a las automatizaciones, paquetes y evoluciones de la tecnología. Hoy, para quienes no lo sepan todavía, hablamos de Foundry IQ y Content Understanding, la nueva forma de crear y entender los RAGs desarrollada e implementada por Microsoft dentro de su Microsoft Foundry.

Foundry IQ + Content Understanding: el fin del RAG artesanal

Llevamos dos años construyendo lo mismo una y otra vez. Cada equipo que monta un agente empresarial acaba escribiendo su propio pipeline de carga, chunking, embeddings, índice y retrieval, casi siempre desde cero, casi siempre con los mismos fallos de PDFs con tablas rotas y diagramas que se pierden por el camino. Foundry IQ es la apuesta de Microsoft para que eso deje de ser trabajo de cada equipo y pase a ser una capa compartida. Content Understanding es la pieza, menos conocida, que decide si lo que entra en esa capa llega limpio o llega hecho un desastre.

El problema que todos hemos sufrido ya

Si has montado un RAG en los últimos dos años, esta secuencia te va a sonar: cargas los documentos, decides cómo trocearlos, generas embeddings, los metes en un índice, escribes la lógica de recuperación y la enchufas al prompt. Y la repites entera cada vez que un equipo distinto de tu misma empresa necesita que su agente sepa algo sobre los mismos documentos. Nadie reutiliza nada porque no había una capa pensada para reutilizarse: cada aplicación traía su propio RAG artesanal, con su propia forma de romperse.

Microsoft lo plantea como un problema de arquitectura, no de modelos: el modelo detrás de un agente tiene un corte de conocimiento y no puede acceder solo a tus datos propios, así que alguien tiene que construirle ese acceso. La apuesta de Foundry IQ es que ese «alguien» deje de ser cada equipo por separado.

Qué es exactamente Foundry IQ

Una Knowledge Base en Foundry IQ es la combinación de Knowledge Sources (las conexiones a tus almacenes de datos internos y externos) más los parámetros que controlan cómo se recupera esa información. Lo que cambia el juego es que una misma base de conocimiento se puede conectar a varios agentes distintos a la vez, en vez de vivir enterrada dentro del código de una sola aplicación.

Y no es recuperación clásica de «busca las tres frases más parecidas y pégalas en el prompt». Es recuperación agéntica: el motor descompone la pregunta del usuario en subconsultas, las lanza en paralelo combinando búsqueda por palabra clave, vectorial e híbrida, aplica un reranking semántico sobre los resultados y sintetiza una única respuesta con referencias a las fuentes originales. Todo eso ya viene incluido, no lo escribes tú. Un matiz que genera bastante confusión, y que conviene aclarar bien: MCP no aparece como Knowledge Source cuando creas la base de conocimiento. Eso está a otro nivel. La propia Knowledge Base se expone hacia afuera como servidor MCP, con una única tool llamada knowledge_base_retrieve, y eso es lo que conectas al agente. Es decir, el MCP es la puerta de salida de tu conocimiento, no una de las fuentes que entran.

De dónde sale el conocimiento antes de ser conocimiento

Aquí es donde entra la pieza que suele quedarse fuera de estas explicaciones: Content Understanding. Antes de que un PDF, una imagen o un audio se conviertan en algo que Foundry IQ pueda indexar, alguien tiene que decidir qué partes de ese archivo importan y en qué forma se representan. Content Understanding junta el Document Intelligence tradicional de Microsoft con razonamiento basado en modelos de lenguaje para hacer justo eso, con documentos, audio, imágenes y vídeo.

La integración concreta con Foundry IQ no es cosmética. En las fuentes de archivo (Blob, SharePoint, OneLake), basta con activar el modo de extracción estándar para que Content Understanding entre en juego dentro del propio pipeline de ingesta, sin que tengas que orquestar tú la llamada. Convierte tablas que cruzan varias páginas en una sola unidad coherente, genera descripciones de los diagramas y gráficos incrustados, y produce Markdown consciente del layout del documento en vez de texto plano que pierde toda la estructura.

Y hay una novedad reciente que me parece de las más interesantes de todo el Microsoft Build 2026: image serving. Foundry IQ ahora conserva las imágenes extraídas durante la ingesta y las sirve también en el momento de la recuperación, no solo el texto que las describe. El ejemplo que pone Microsoft es bastante gráfico: un técnico preguntando por un diagrama de cableado y recibiendo, además del texto, la imagen real sobre la que razonar. Si has pasado por el infierno de vectorizar PDFs a mano como hicimos con el scraping y la carga de documentos del BOE, vas a apreciar lo que significa que esta parte ya venga resuelta de fábrica.

Identidad, permisos y de dónde viene cada respuesta

En una empresa de verdad, «el agente puede buscar en SharePoint» nunca es la pregunta completa. La pregunta real es si el agente respeta los mismos permisos que tendría la persona que le está preguntando. Foundry IQ ejecuta las consultas bajo la identidad de Entra de quien llama, no bajo una identidad genérica de servicio con acceso a todo, y sincroniza las listas de control de acceso de las fuentes soportadas, respetando además las etiquetas de sensibilidad de Purview. Si un documento está marcado como confidencial y el usuario que pregunta no tiene acceso, el agente no lo va a usar para responder, por muy relevante que sea.

La otra pieza que suele faltar en los RAG artesanales es la procedencia. Aquí cada respuesta llega con referencias a las fuentes concretas que la sustentan, así que se puede rastrear de dónde salió cada afirmación en vez de fiarte de que el modelo no se lo ha inventado. Es exactamente el mismo principio que ya defendíamos al hablar de DSPM for AI y los riesgos de datos sensibles en prompts: la gobernanza no puede vivir fuera del flujo de trabajo del agente, tiene que estar cosida dentro.

Coste, dependencia de plataforma y cuándo NO usar esto

Vamos con la parte incómoda. Foundry IQ Serverless, el tier pensado para arrancar rápido con precio de escalado a cero, sigue en preview, y la facturación todavía no ha empezado: Microsoft dice que arrancará a finales de 2026, con al menos 30 días de aviso previo. Traducido: lo que hoy es gratis en el tier developer no lo va a ser eternamente, y conviene planificar el coste real antes de construir media plataforma encima.

Y no hay Foundry IQ sin Azure AI Search por debajo, así que si tu estrategia de datos no pasa por Azure, esto no es una capa neutral que se pueda mover a otro proveedor sin fricción.

Un RAG personalizado te da control total sobre cada pieza del pipeline, a cambio de que tú mantengas cada pieza para siempre. Ir directo contra Azure AI Search te da toda la potencia de búsqueda sin la capa agéntica encima, así que sigues escribiendo tú la lógica de orquestación. Foundry IQ te da reutilización entre agentes y gobierno centralizado, al precio de acoplarte más al ecosistema de Microsoft. Meter todo el contexto directamente en la ventana del modelo es lo más simple de arrancar, pero se paga caro en tokens y en calidad según crece el documento. Y el fine-tuning interioriza comportamiento y estilo, pero nunca sustituye a tener datos actuales: un modelo afinado en marzo no sabrá nada de lo que pase en junio.

¿Cuándo sigue mereciendo la pena montar tu propio pipeline? Cuando tu lógica de recuperación es realmente distinta de lo que ofrece agentic retrieval por defecto, cuando ya tienes una infraestructura de búsqueda madura que funciona y migrar solo añade riesgo, o cuando el acoplamiento a Azure AI Search es una línea roja que tu arquitectura no puede cruzar. Fuera de esos casos, escribir el enésimo pipeline de chunking a mano en 2026 empieza a sonar más a orgullo técnico que a buena ingeniería.

El RAG dejó de ser un pipeline

Si algo queda claro después de todo esto es que la pregunta ya no es «cómo implemento retrieval en mi aplicación», es «qué conocimiento necesita compartirse entre cuántos agentes, y quién es responsable de gobernarlo». Foundry IQ no elimina la necesidad de pensar en arquitectura, la traslada de «cómo trocear un PDF» a «quién puede ver qué, y cómo lo pruebo». Y Content Understanding es la pieza silenciosa que hace que esa promesa no se rompa en cuanto alguien sube un PDF con una tabla que ocupa tres páginas y un diagrama en medio.

Para arquitecturas de agentes que ya conocéis bien por aquí, como el propio Microsoft Agent Framework, esto encaja como la pieza de conocimiento que faltaba: construyes la base una vez, la gobiernas una vez, y la reutilizas en cuantos agentes hagan falta, en vez de repetir el mismo pipeline cada trimestre con un nombre de proyecto distinto.