Fundamentos de Azure AI Search: recuperación híbrida y patrones agentivos en Azure AI Foundry

Introducción

Azure AI Search es un servicio de búsqueda gestionado de Azure que puede actuar como capa de recuperación para aplicaciones de IA generativa, asistentes internos, buscadores corporativos y arquitecturas RAG (Retrieval-Augmented Generation).

En el contexto de soluciones construidas con Azure AI Foundry, conviene entender Azure AI Search como una pieza especializada en:

indexar contenido estructurado y no estructurado;
ejecutar consultas por texto, filtros y facetas;
realizar búsqueda vectorial sobre embeddings;
combinar señales léxicas y semánticas mediante búsqueda híbrida;
aplicar ranking semántico cuando está configurado;
servir resultados recuperados a una capa de orquestación o a un modelo generativo.

No es correcto asumir que Azure AI Search “decide solo” siempre la mejor estrategia. La aplicación, el orquestador o la configuración de consulta determinan si se usa búsqueda por palabras clave, búsqueda vectorial, búsqueda híbrida, ranking semántico o una combinación de estas capacidades.

De Azure Cognitive Search a Azure AI Search

El servicio fue conocido durante años como Azure Cognitive Search. Microsoft lo renombró a Azure AI Search para alinearlo con el resto de servicios de IA de Azure y con su uso creciente en escenarios de búsqueda semántica, vectores y generación aumentada por recuperación.

El cambio de nombre no implica que todos los conceptos clásicos desaparezcan. Siguen siendo fundamentales:

índices;
campos;
analizadores;
filtros;
facetas;
indexadores;
skillsets;
consultas;
scoring;
particiones y réplicas;
control de acceso mediante claves o Microsoft Entra ID.

La novedad práctica para arquitecturas GenAI es que estos componentes pueden combinarse con embeddings, modelos generativos y orquestadores para construir experiencias de búsqueda y respuesta más ricas.

Recuperación híbrida: palabras clave más vectores

La recuperación híbrida combina dos familias de señales:

Búsqueda léxica o por palabras clave
Usa coincidencias textuales sobre campos indexados. Es útil cuando el usuario busca términos concretos, identificadores, nombres de producto, códigos, referencias legales o expresiones exactas.
Búsqueda vectorial
Usa embeddings para localizar documentos semánticamente cercanos a la consulta, aunque no compartan las mismas palabras. Es útil cuando el usuario formula preguntas en lenguaje natural, usa sinónimos o expresa una intención más conceptual.

En Azure AI Search, una consulta híbrida suele enviar tanto un search_text como una o varias consultas vectoriales. El motor combina los resultados de ambos enfoques. En escenarios habituales, la fusión de rankings permite que documentos relevantes por texto exacto y documentos relevantes por proximidad semántica compitan en una misma lista de resultados.

Además, si se configura semantic ranking, puede aplicarse una capa adicional de reordenación semántica sobre los resultados candidatos. Esto no sustituye a la búsqueda híbrida: la complementa.

Cuándo usar cada enfoque

No todas las consultas necesitan el mismo tipo de recuperación.

Escenario	Enfoque recomendado
Buscar por número de contrato, SKU, identificador o código	Búsqueda por palabras clave y filtros
Preguntas en lenguaje natural sobre documentación	Búsqueda vectorial o híbrida
Consultas con términos exactos y significado contextual	Búsqueda híbrida
Experiencias RAG con respuestas generadas	Búsqueda híbrida, filtros y posible ranking semántico
Catálogos con navegación por atributos	Búsqueda textual, filtros y facetas
Contenido sensible por permisos	Filtros de seguridad aplicados en la consulta

Una buena arquitectura no consiste en “usar vectores para todo”, sino en combinar señales. En muchos sistemas empresariales, los filtros, metadatos y permisos son tan importantes como la similitud semántica.

Diseño básico de un índice híbrido

Un índice híbrido necesita, como mínimo:

una clave única;
campos textuales buscables;
metadatos filtrables o facetables si son necesarios;
uno o varios campos vectoriales;
una configuración de búsqueda vectorial;
embeddings generados con la misma dimensionalidad que el campo vectorial.

Ejemplo conceptual con el SDK de Azure para Python:

from azure.identity import DefaultAzureCredential
from azure.search.documents.indexes import SearchIndexClient
from azure.search.documents.indexes.models import (
    HnswAlgorithmConfiguration,
    SearchField,
    SearchFieldDataType,
    SearchIndex,
    SearchableField,
    SimpleField,
    VectorSearch,
    VectorSearchProfile,
)

endpoint = "https://<tu-servicio>.search.windows.net"
index_name = "docs-hybrid-index"

credential = DefaultAzureCredential()
index_client = SearchIndexClient(endpoint=endpoint, credential=credential)

fields = [
    SimpleField(
        name="id",
        type=SearchFieldDataType.String,
        key=True,
        filterable=True,
    ),
    SearchableField(
        name="title",
        type=SearchFieldDataType.String,
        searchable=True,
        filterable=False,
        sortable=False,
    ),
    SearchableField(
        name="content",
        type=SearchFieldDataType.String,
        searchable=True,
    ),
    SimpleField(
        name="category",
        type=SearchFieldDataType.String,
        filterable=True,
        facetable=True,
    ),
    SearchField(
        name="content_vector",
        type=SearchFieldDataType.Collection(SearchFieldDataType.Single),
        searchable=True,
        vector_search_dimensions=1536,
        vector_search_profile_name="vector-profile",
    ),
]

vector_search = VectorSearch(
    algorithms=[
        HnswAlgorithmConfiguration(name="hnsw-config"),
    ],
    profiles=[
        VectorSearchProfile(
            name="vector-profile",
            algorithm_configuration_name="hnsw-config",
        ),
    ],
)

index = SearchIndex(
    name=index_name,
    fields=fields,
    vector_search=vector_search,
)

index_client.create_or_update_index(index)
print(f"Índice '{index_name}' creado o actualizado.")

Puntos importantes:

content_vector debe tener la misma dimensión que los embeddings que se van a cargar.
El ejemplo usa 1536 dimensiones, habitual en algunos modelos de embeddings, pero no debe copiarse sin validar el modelo usado.
Los permisos de la identidad deben permitir administrar índices. Para ingesta de documentos se requieren permisos de datos adecuados.
En producción conviene definir campos de seguridad, origen, fecha, versión documental y otros metadatos relevantes.

Carga de documentos con embeddings

Azure AI Search no genera automáticamente todos los embeddings en cualquier flujo. Puedes generarlos previamente con el modelo elegido y cargarlos junto con los documentos, o diseñar un pipeline de indexación que los produzca según las capacidades disponibles en tu arquitectura.

Ejemplo simplificado de carga por push API:

from azure.identity import DefaultAzureCredential
from azure.search.documents import SearchClient

endpoint = "https://<tu-servicio>.search.windows.net"
index_name = "docs-hybrid-index"

credential = DefaultAzureCredential()
search_client = SearchClient(
    endpoint=endpoint,
    index_name=index_name,
    credential=credential,
)

documents = [
    {
        "id": "doc-001",
        "title": "Política de renovación de contratos",
        "content": "Los contratos se revisan treinta días antes de su vencimiento...",
        "category": "legal",
        "content_vector": [0.012, -0.034, 0.056],  # Ejemplo abreviado
    },
    {
        "id": "doc-002",
        "title": "Procedimiento de soporte premium",
        "content": "Los clientes con soporte premium disponen de atención prioritaria...",
        "category": "soporte",
        "content_vector": [0.021, -0.011, 0.087],  # Ejemplo abreviado
    },
]

result = search_client.upload_documents(documents=documents)
print(result)

En un sistema real, el vector no tendría tres valores, sino tantos como indique el modelo de embeddings. Si el índice espera 1536 dimensiones, cada documento debe enviar exactamente 1536 valores en el campo vectorial.

Ejemplo de consulta híbrida

Una consulta híbrida combina texto y vector. La aplicación debe generar primero el embedding de la pregunta del usuario con el mismo modelo o familia compatible usada para indexar los documentos.

from azure.identity import DefaultAzureCredential
from azure.search.documents import SearchClient
from azure.search.documents.models import VectorizedQuery

endpoint = "https://<tu-servicio>.search.windows.net"
index_name = "docs-hybrid-index"

credential = DefaultAzureCredential()
search_client = SearchClient(
    endpoint=endpoint,
    index_name=index_name,
    credential=credential,
)

query_text = "¿Cómo se renueva un contrato antes de que caduque?"

# Debe generarse previamente con tu modelo de embeddings.
query_embedding = [0.015, -0.022, 0.041]  # Ejemplo abreviado

vector_query = VectorizedQuery(
    vector=query_embedding,
    k_nearest_neighbors=10,
    fields="content_vector",
)

results = search_client.search(
    search_text=query_text,
    vector_queries=[vector_query],
    filter="category eq 'legal'",
    top=5,
)

for result in results:
    print(result["title"])

Este patrón permite combinar:

coincidencias textuales sobre title y content;
similitud vectorial sobre content_vector;
filtros estructurados, como category;
límite de resultados con top.

Si se usa ranking semántico, debe configurarse explícitamente en el índice y solicitarse en la consulta según el SDK o API utilizados.

Recuperación agentiva: patrón de orquestación, no magia automática

La expresión recuperación agentiva suele usarse para describir un patrón en el que una capa de orquestación decide cómo recuperar información antes de responder. En soluciones con Azure AI Foundry, esta capa puede formar parte de un asistente, una aplicación RAG o un flujo más amplio.

Un enfoque agentivo puede decidir, por ejemplo:

si la consulta requiere buscar en uno o varios índices;
si conviene aplicar filtros por permisos, departamento, región o fecha;
si basta con búsqueda textual o es mejor usar recuperación híbrida;
si hay que reformular la consulta;
si se necesitan varias búsquedas sucesivas;
si los resultados son suficientes o debe pedirse aclaración al usuario;
qué fragmentos se envían al modelo generativo como contexto.

Lo importante es no atribuir estas decisiones automáticamente a Azure AI Search si no están implementadas o configuradas. Azure AI Search proporciona capacidades de recuperación; la lógica agentiva suele residir en la aplicación, en el orquestador o en servicios de IA que trabajan sobre la capa de búsqueda.

Flujo recomendado para una experiencia RAG agentiva

Un flujo razonable para una solución empresarial sería:

Recibir la pregunta del usuario
Capturar texto, identidad, idioma, canal y contexto conversacional.
Clasificar la intención
Determinar si es una búsqueda documental, una petición transaccional, una consulta sobre datos estructurados o una pregunta fuera de alcance.
Seleccionar estrategia de recuperación
Elegir entre búsqueda textual, vectorial, híbrida o múltiples consultas.
Aplicar filtros de seguridad
Limitar resultados por permisos, tenant, unidad organizativa o clasificación de datos.
Ejecutar consulta en Azure AI Search
Recuperar documentos, fragmentos o registros candidatos.
Reordenar o comprimir contexto
Aplicar ranking semántico si está disponible y seleccionar los fragmentos más útiles.
Generar respuesta con citas
Pasar al modelo generativo solo el contexto necesario e incluir referencias a las fuentes recuperadas.
Validar respuesta
Controlar alucinaciones, ausencia de evidencia, contenido sensible y trazabilidad.
Registrar métricas
Medir consultas sin resultados, latencia, documentos más usados, feedback del usuario y calidad de respuesta.

Este patrón permite separar responsabilidades: Azure AI Search recupera información; la capa agentiva decide cómo y cuándo usar esa información.

Pseudocódigo de una recuperación agentiva

El siguiente ejemplo es pseudocódigo de aplicación. No representa una API específica de Azure AI Foundry ni una capacidad automática de Azure AI Search.

def retrieve_for_answer(user_query, user_context):
    intent = classify_intent(user_query)

    if intent == "out_of_scope":
        return {
            "answerable": False,
            "reason": "La pregunta está fuera del dominio configurado.",
            "documents": [],
        }

    filters = build_security_filter(user_context)

    if intent == "exact_lookup":
        results = keyword_search(
            text=user_query,
            filters=filters,
            top=5,
        )
    else:
        query_vector = create_embedding(user_query)
        results = hybrid_search(
            text=user_query,
            vector=query_vector,
            filters=filters,
            top=10,
        )

    if not results:
        reformulated_query = rewrite_query(user_query)
        query_vector = create_embedding(reformulated_query)
        results = hybrid_search(
            text=reformulated_query,
            vector=query_vector,
            filters=filters,
            top=10,
        )

    selected_context = select_relevant_chunks(results)

    return {
        "answerable": bool(selected_context),
        "documents": selected_context,
    }

La clave está en hacer explícita la política de decisión. En entornos regulados, esto facilita auditoría, pruebas y control de riesgos.

Validación de índices tras cambios estructurales

Los cambios en un índice deben tratarse con cuidado. En Azure AI Search, no todos los aspectos de un campo pueden modificarse libremente después de crear el índice. En muchos casos, si se cambia el tipo de campo, la clave, ciertas propiedades de búsqueda o la estrategia vectorial, conviene crear un índice nuevo y reindexar.

Buenas prácticas:

Versionar índices
Usar nombres como docs-v1, docs-v2 o alias si la arquitectura lo permite.
Probar en un entorno no productivo
Validar esquema, dimensionalidad de embeddings, filtros y consultas antes del cambio.
Reindexar cuando cambie la estructura
Si cambian campos relevantes, analizadores, embeddings o particionado lógico, reconstruir el índice suele ser más seguro.
Validar consultas representativas
Probar preguntas reales, búsquedas exactas, filtros y casos sin resultado.
Medir calidad, no solo latencia
Revisar precisión, cobertura, orden de resultados, citas correctas y satisfacción del usuario.
Monitorizar capacidad
Observar latencia, throttling, tamaño del índice, uso de réplicas y particiones.

Ejemplo de actualización de documentos

Para actualizar documentos sin cambiar el esquema del índice, puede usarse merge_or_upload_documents. Este método inserta documentos nuevos o fusiona campos en documentos existentes.

from azure.identity import DefaultAzureCredential
from azure.search.documents import SearchClient

endpoint = "https://<tu-servicio>.search.windows.net"
index_name = "docs-hybrid-index"

credential = DefaultAzureCredential()
search_client = SearchClient(
    endpoint=endpoint,
    index_name=index_name,
    credential=credential,
)

updated_documents = [
    {
        "id": "doc-001",
        "title": "Política actualizada de renovación de contratos",
        "content": "Los contratos se revisan cuarenta y cinco días antes de su vencimiento...",
        "category": "legal",
        "content_vector": [0.018, -0.031, 0.049],  # Ejemplo abreviado
    }
]

result = search_client.merge_or_upload_documents(documents=updated_documents)
print(result)

Si se modifica el contenido textual de un documento, también debe regenerarse su embedding. Mantener un vector antiguo asociado a contenido nuevo degrada la calidad de la búsqueda semántica.

Consideraciones de arquitectura

Antes de llevar Azure AI Search a producción en una solución de IA generativa, revisa estos puntos:

Seguridad

Usa Microsoft Entra ID cuando sea posible.
Aplica filtros de seguridad en tiempo de consulta.
No envíes al modelo generativo documentos que el usuario no esté autorizado a ver.
Separa datos por tenant o dominio cuando sea necesario.

Calidad de recuperación

Evalúa con preguntas reales.
Incluye casos negativos.
Mide si el documento correcto aparece entre los primeros resultados.
Ajusta campos, pesos, filtros y fragmentación de documentos.

Fragmentación documental

Fragmentos demasiado grandes pueden introducir ruido.
Fragmentos demasiado pequeños pueden perder contexto.
Conserva metadatos de origen, página, sección y versión.

Coste y rendimiento

Los campos vectoriales aumentan tamaño de índice.
La búsqueda híbrida puede requerir más cómputo que una consulta textual simple.
El ranking semántico puede añadir latencia.
Ajusta réplicas y particiones según tráfico y tamaño.

Operación

Monitoriza errores de indexación.
Registra consultas sin resultados.
Revisa cambios de esquema con control de versiones.
Automatiza pruebas de regresión de búsqueda.

Errores frecuentes

Al implementar Azure AI Search en arquitecturas RAG o agentivas, son comunes estos errores:

asumir que la búsqueda vectorial sustituye todos los filtros;
indexar contenido sin metadatos suficientes;
mezclar embeddings de modelos distintos en el mismo campo vectorial;
usar una dimensión de vector distinta a la definida en el índice;
no regenerar embeddings cuando cambia el contenido;
pasar demasiados documentos al modelo generativo;
no aplicar seguridad en la recuperación;
confundir ranking semántico con generación de respuestas;
no medir calidad de recuperación con un conjunto de evaluación.

Conclusión

Azure AI Search es una pieza sólida para construir recuperación híbrida en soluciones de IA generativa sobre Azure. Su valor aumenta cuando se combina con una buena estrategia de indexación, embeddings coherentes, filtros de seguridad, ranking adecuado y una capa de orquestación que tome decisiones explícitas.

La recuperación agentiva no debe entenderse como una capacidad mágica que resuelve automáticamente la intención del usuario. Es un patrón arquitectónico: la aplicación decide cómo consultar, qué fuentes usar, cómo validar resultados y qué contexto entregar al modelo generativo.

Para una solución empresarial, la recomendación es empezar con una base sencilla:

índice bien modelado;
documentos fragmentados con metadatos;
búsqueda híbrida;
filtros de seguridad;
evaluación de calidad;
orquestación progresiva solo donde aporte valor.