Por qué la búsqueda vectorial sola no basta
Azure AI Search lleva soportando búsqueda vectorial desde 2023, y la adopción ha sido masiva en sistemas RAG sobre documentación técnica, bases de conocimiento corporativas y chatbots de soporte. Sin embargo, los equipos que operan estos sistemas en producción descubren pronto una limitación consistente: la búsqueda puramente vectorial falla de formas específicas y predecibles.
Los fallos más comunes tienen un patrón claro. Los términos técnicos muy específicos, como nombres de APIs, códigos de error o siglas de producto, no tienen una representación semántica rica en el espacio de embeddings. Cuando alguien busca “HRESULT 0x80070057” o “error AADSTS70011”, el modelo de embeddings genera un vector que simplemente no está cerca de los documentos que contienen esa cadena específica. La búsqueda vectorial busca similitud semántica, y esos términos no tienen semántica que el modelo pueda capturar de forma confiable.
Por eso la respuesta en producción no es elegir entre búsqueda vectorial o búsqueda de texto: es combinar ambas. La búsqueda híbrida en Azure AI Search hace exactamente eso, y el pipeline de tres capas resultante es sustancialmente más robusto que cualquiera de los dos enfoques por separado.
El pipeline de búsqueda híbrida
El pipeline tiene tres etapas que se ejecutan en secuencia para cada consulta.
Primera etapa: búsqueda paralela. La consulta se procesa simultáneamente por dos motores independientes. El motor BM25 (Best Match 25) indexa el texto original de los documentos y calcula una puntuación de relevancia basada en la frecuencia de los términos de búsqueda en el documento y en la colección completa. BM25 es especialmente bueno con términos raros y específicos: cuanto menos frecuente sea un término en la colección, más peso tiene su presencia en un documento concreto. El motor vectorial, en paralelo, convierte la consulta en un embedding y busca los fragmentos más cercanos en el espacio vectorial mediante HNSW.
Segunda etapa: fusión RRF. Los dos conjuntos de resultados, cada uno con sus propias puntuaciones en escalas distintas, se fusionan usando Reciprocal Rank Fusion. RRF no intenta normalizar las puntuaciones; en su lugar, trabaja solo con los rankings. Para cada documento, la puntuación RRF se calcula como la suma de 1 / (k + posición) en cada lista donde aparece, donde k es una constante de suavizado (típicamente 60). Los documentos que aparecen en posiciones altas en ambas listas reciben las puntuaciones más altas. Los que solo aparecen en una lista reciben una bonificación menor.
Tercera etapa: reranking semántico. El reranker de Azure AI Search recibe los mejores resultados del fusionador RRF, evalúa cada par (consulta, documento) de forma conjunta usando un modelo de cross-encoding, y reordena los resultados. Esta evaluación conjunta es lo que diferencia al reranker del proceso de recuperación inicial: el modelo puede entender la relación específica entre la consulta y el fragmento, detectando relevancia contextual que los embeddings independientes no pueden capturar.
Configurar búsqueda híbrida en Azure AI Search
La configuración en el índice requiere definir tanto el campo vectorial como la configuración de algoritmo. Un esquema de índice típico para un corpus de artículos técnicos:
{
"name": "blog-articles",
"fields": [
{"name": "id", "type": "Edm.String", "key": true},
{"name": "title", "type": "Edm.String", "searchable": true},
{"name": "content", "type": "Edm.String", "searchable": true},
{"name": "tags", "type": "Collection(Edm.String)", "filterable": true},
{"name": "date", "type": "Edm.DateTimeOffset", "sortable": true, "filterable": true},
{
"name": "content_vector",
"type": "Collection(Edm.Single)",
"dimensions": 1536,
"vectorSearchProfile": "hnsw-profile"
}
],
"vectorSearch": {
"profiles": [{"name": "hnsw-profile", "algorithm": "hnsw-config"}],
"algorithms": [{
"name": "hnsw-config",
"kind": "hnsw",
"hnswParameters": {"m": 4, "efConstruction": 400, "efSearch": 500}
}]
},
"semantic": {
"configurations": [{
"name": "semantic-config",
"prioritizedFields": {
"titleField": {"fieldName": "title"},
"contentFields": [{"fieldName": "content"}]
}
}]
}
}
La consulta híbrida combina texto y vector en la misma petición, con queryType: "semantic" para activar el reranker:
from azure.search.documents import SearchClient
from azure.search.documents.models import VectorizableTextQuery
results = search_client.search(
search_text=query_text,
vector_queries=[
VectorizableTextQuery(
text=query_text,
k_nearest_neighbors=50,
fields="content_vector"
)
],
query_type="semantic",
semantic_configuration_name="semantic-config",
top=5,
select=["id", "title", "content", "tags", "date"]
)
Tuning de los parámetros críticos
Los parámetros HNSW m y efConstruction controlan el equilibrio entre calidad de los resultados, tiempo de indexación y uso de memoria. Un valor de m más alto (conexiones por nodo) mejora la calidad de búsqueda a costa de mayor memoria. efConstruction más alto mejora la calidad del grafo construido a costa de mayor tiempo de indexación. Los valores por defecto (m=4, efConstruction=400) son adecuados para la mayoría de los casos; solo ajusta si tienes métricas de evaluación que justifiquen el cambio.
El parámetro k_nearest_neighbors en la consulta (cuántos candidatos vectoriales recuperar antes de la fusión) debería ser al menos el doble del número final de resultados que quieres. Si quieres los 5 mejores resultados finales, pide al menos 50 candidatos vectoriales para que el fusionador RRF y el reranker tengan suficiente material con el que trabajar.
El reranker tiene un límite de 50 documentos de entrada. Si tu consulta puede generar más de 50 candidatos en la fase de fusión, asegúrate de filtrar antes de llegar al reranker. Los filtros $filter de Azure AI Search se aplican antes de la puntuación y son eficientes para reducir el espacio de búsqueda.
Evaluación de la calidad de recuperación
La métrica estándar para evaluar sistemas de recuperación es nDCG (normalized Discounted Cumulative Gain), que penaliza los resultados relevantes que aparecen en posiciones alejadas del primer lugar. Azure AI Evaluation SDK incluye evaluadores específicos para RAG: RetrievalEvaluator, GroundednessEvaluator y RelevanceEvaluator.
Un patrón de evaluación robusto para un sistema en producción combina evaluación offline con un conjunto de consultas anotadas manualmente, monitorización online de métricas de satisfacción implícitas (clicks, tiempo en respuesta, retroalimentación explícita), y pruebas A/B controladas cuando se modifican los parámetros de búsqueda.
La calidad de la recuperación es el factor más determinante en la calidad final de las respuestas de un sistema RAG. Un LLM excelente con recuperación mediocre produce respuestas mediocres. La inversión en evaluación y tuning del pipeline de recuperación es la que mayor retorno tiene en sistemas RAG de producción. El artículo complementario sobre Foundry IQ y recuperación agéntica describe cómo Azure AI Search extiende este pipeline con capacidades de planificación automática de consultas.