La mayoría de los tutoriales de RAG que encontrás online muestran el mismo patrón donde tomás un documento, lo partís en chunks, generás embeddings, los guardás en una base de datos vectorial, y cuando llega una consulta buscás los vectores más cercanos y se los mandás al LLM. Esto sí, funciona, pero el problema es que en producción ese patrón falla de formas que no aparecen en el tutorial.

Un usuario escribe "error SNAT en la configuración de red". El vector de esa query es semánticamente similar a decenas de documentos sobre NAT, networking y configuraciones de red en general. La búsqueda vectorial devuelve resultados relevantes conceptualmente, pero el documento específico que contiene "SNAT" repetidas veces puede no estar entre los primeros cinco. Keyword search lo hubiera encontrado de inmediato.

Azure AI Search existe para resolver exactamente ese tipo de problema, y en 2026 el servicio cambió lo suficiente como para que mucho de lo que se escribió antes sobre él esté desactualizado.

Qué es Azure AI Search hoy

El servicio se llamó Azure Search, luego Azure Cognitive Search, y desde noviembre de 2023 es Azure AI Search. El nombre más reciente que apareció en Build 2026 es Foundry IQ, que es cómo Microsoft lo expone dentro del portal de Azure AI Foundry. No son dos servicios distintos: Foundry IQ es Azure AI Search visto desde la plataforma de agentes.

Internamente, el servicio combina tres tecnologías de búsqueda. El motor de texto completo usa BM25, el mismo algoritmo que usan los motores de búsqueda tradicionales, que puntúa documentos según frecuencia de términos y frecuencia inversa en el corpus. El motor vectorial usa HNSW (Hierarchical Navigable Small World) para búsqueda aproximada de vecinos más cercanos sobre embeddings. Y el Semantic Ranker es un modelo transformer tipo cross-encoder adaptado desde Microsoft Bing que reordena los resultados de los dos anteriores según relevancia semántica.

Estos tres componentes pueden usarse por separado o en combinación. La mayoría de los sistemas en producción los usan juntos.

Por qué la búsqueda vectorial sola no alcanza

El embedding de una consulta captura significado general. Es bueno para preguntas conceptuales como "cómo funciona la autenticación en OAuth", donde la intención es semántica y no hay un término exacto que buscar. Falla cuando la consulta contiene términos muy específicos: códigos de producto, números de error, siglas técnicas, nombres propios.

El motivo es técnico, ya que los modelos de embedding comprimen mucha información semántica en un vector de dimensión fija. Términos raros o muy específicos tienden a diluirse en ese proceso de compresión. BM25 no tiene ese problema porque trabaja con frecuencia de términos exactos.

La búsqueda híbrida ejecuta ambas consultas en paralelo y fusiona los resultados usando Reciprocal Rank Fusion (RRF). RRF combina listas de ranking sin requerir que los scores de ambos sistemas estén en la misma escala, usando una fórmula que penaliza resultados que aparecen muy abajo en cualquiera de las dos listas. El resultado es consistentemente mejor que cualquiera de las dos búsquedas por separado, especialmente para contenido empresarial que mezcla texto descriptivo con identificadores específicos.

El Semantic Ranker y qué hace exactamente

Después de que la búsqueda híbrida devuelve sus resultados rankeados, el Semantic Ranker toma los primeros 50 y los reordena. Usa un modelo cross-encoder que procesa la consulta y el fragmento de documento juntos, a diferencia de los bi-encoders que generan embeddings independientes para cada uno. Esa diferencia importa porque el cross-encoder puede capturar relaciones sutiles como negaciones y dependencias contextuales que la similitud vectorial pierde.

El Semantic Ranker también genera captions (fragmentos representativos del documento) y opcionalmente answers (pasajes que respondan directamente a la pregunta si fue formulada como pregunta). Tanto captions como answers son texto verbatim del índice, no texto generado por el modelo.

Un detalle importante, es que Semantic Ranker opera solo sobre texto, incluso en consultas híbridas. Y solo procesa los primeros 50 resultados del ranking anterior, lo que significa que si el documento correcto no aparece en esos 50, el ranker no puede recuperarlo. La calidad del ranking inicial importa.

Una consideración, las semantic queries tienen costo adicional. No es necesario activarlo para todas las consultas. Para búsqueda de fondo o procesamiento en batch donde la precisión no es crítica, puede omitirse. Para búsqueda de cara al usuario donde la calidad del resultado afecta la respuesta del LLM, vale la pena.

Dos caminos para RAG en 2026

Desde 2026, Azure AI Search ofrece dos enfoques distintos para construir un pipeline RAG. Microsoft los llama classic RAG pattern y agentic retrieval, y la elección entre ellos depende del tipo de consultas que necesitás responder.

Classic RAG

El classic RAG pattern es el enfoque probado y en disponibilidad general. Vos controlás el pipeline completo: generás la query de búsqueda (o usás directamente la pregunta del usuario), ejecutás la búsqueda híbrida con semantic ranking, tomás los N resultados más relevantes, y los mandás como contexto al LLM.

Es el camino correcto cuando las preguntas son relativamente directas, tenés código de orquestación existente que no querés reemplazar, o necesitás features de disponibilidad general para producción. La ventaja es control total y latencia predecible.

Agentic retrieval

El agentic retrieval agrega una capa de planificación LLM antes de ejecutar la búsqueda. El sistema recibe la consulta del usuario, usa un LLM para descomponerla en sub-consultas enfocadas, ejecuta todas en paralelo (cada una puede ser keyword, vector o híbrida), aplica semantic ranking a cada resultado, y sintetiza una respuesta unificada con referencias.

Esto resuelve un problema: preguntas del tipo "encontrá las políticas de tiempo libre para empleados remotos contratados después de 2023" no tienen una sola dimensión de búsqueda. Son varias preguntas combinadas. Una consulta vectorial simple tiende a capturar solo una parte del significado.

La contrapartida es latencia adicional (el paso de planificación agrega tiempo) y que algunos features de agentic retrieval todavía están en preview a julio de 2026. La API REST 2026-04-01 tiene agentic retrieval en disponibilidad general para acceso programático. El portal de Azure y el portal de Foundry todavía muestran agentic retrieval en preview.

Foundry IQ, el nuevo modelo de knowledge base

Foundry IQ es la capa de conocimiento unificada que Microsoft construyó sobre Azure AI Search para el ecosistema de agentes de Foundry. La idea es resolver un problema que aparece cuando una organización empieza a escalar desde uno o dos agentes a decenas: cada equipo termina reconstruyendo su propia pipeline de RAG, con su propio vector store, su propia lógica de chunking y su propio sistema de control de acceso.

Con Foundry IQ, creás una knowledge base una vez y la exponés como endpoint compartido para múltiples agentes. La knowledge base puede conectarse a SharePoint, OneLake, Azure Blob Storage, Fabric IQ, el web, y servidores MCP. No necesitás configurar por separado la estrategia de retrieval para cada fuente: el sistema hace routing automático.

Cada knowledge base en Azure AI Search es también un servidor MCP standalone. Cualquier cliente compatible con MCP, incluyendo Foundry Agent Service, GitHub Copilot, Claude y Cursor, puede invocar la herramienta knowledge_base_retrieve para consultar la base. El endpoint tiene la forma:

https://<servicio>.search.windows.net/knowledgebases/<nombre>/mcp?api-version=<version>

Foundry IQ maneja automáticamente el pipeline de indexación para fuentes conectadas: ingesta, chunking, vectorización y enriquecimiento. Cuando habilitás Azure Content Understanding en fuentes compatibles, los documentos complejos con tablas, figuras y headers se procesan con layout-aware enrichment sin que tengas que escribir código extra.

El acceso y los permisos son parte del diseño desde el inicio. Foundry IQ usa Entra ID para control de acceso a nivel de documento, lo que significa que cuando un agente consulta la knowledge base, solo recibe documentos a los que el usuario que inició la conversación tiene acceso. Ese control viaja automáticamente a través del sistema sin necesidad de implementar filtros de seguridad por separado.

Chunking, porque importa más de lo que parece

La calidad del retrieval depende fuertemente de cómo partís los documentos antes de indexarlos. Chunks muy grandes comprimen demasiada información en un solo embedding y dificultan la recuperación precisa. Chunks muy pequeños pierden contexto y fragmentan información que pertenece junta.

La recomendación que aparece de forma consistente en benchmarks: chunks de 512 tokens con 25% de superposición (overlap), preservando límites de oración. Partir en el medio de una oración degrada tanto la calidad del embedding como la legibilidad del fragmento cuando llega al LLM.

Azure AI Search tiene integración nativa de vectorización que elimina la necesidad de escribir código personalizado para este proceso. Configurás la fuente de datos, definís el skillset (incluyendo el modelo de embeddings a usar), y el indexer maneja el ciclo completo: extrae texto de PDFs y documentos Office, lo parte en chunks, genera los embeddings, y los almacena en el índice. El indexer puede configurarse para correr en horario y mantener el índice actualizado cuando los documentos fuente cambian.

Para volúmenes grandes, los uploads deben hacerse en batch usando la API upload_documents con entre 500 y 1000 documentos por lote. Subir uno por uno a escala es inviable en tiempo.

Cómo elegir entre los dos enfoques

Classic RAG para: preguntas directas con una sola dimensión de búsqueda, pipelines existentes que no querés tocar, necesidad de features en disponibilidad general, latencia crítica donde cada segundo importa.

Agentic retrieval para: consultas conversacionales complejas con múltiples preguntas implícitas, agentes que necesitan la mayor relevancia posible, implementaciones nuevas donde la latencia adicional es aceptable, y escenarios donde el contexto de la conversación anterior es relevante para interpretar la consulta actual.

Foundry IQ tiene sentido cuando estás construyendo múltiples agentes que necesitan acceder a las mismas fuentes de datos, o cuando querés delegar a Microsoft la gestión del pipeline de indexación y enfocarte en la lógica del agente.

La documentación oficial de Microsoft recomienda empezar con vector_semantic_hybrid en el tier Standard como punto de partida por defecto, y agregar agentic retrieval cuando aparecen patrones de consulta complejos que el classic RAG no maneja bien.

Para cerrar

Azure AI Search no es un vector store con algunas features extra. Es una plataforma de retrieval con tres capas de ranking que trabajan juntas: keyword para exactitud, vector para semántica, semantic ranker para relevancia contextual.

Si querés explorar la documentación oficial y los quickstarts de agentic retrieval:

👉 https://learn.microsoft.com/azure/search/?wt.mc_id=studentamb_510930

Referencias oficiales