Por qué la búsqueda vectorial sola no basta
La búsqueda vectorial es una pieza muy útil en sistemas RAG, buscadores sobre documentación técnica, bases de conocimiento internas y asistentes de soporte. Su principal ventaja es que permite recuperar documentos conceptualmente cercanos a una consulta aunque no compartan exactamente las mismas palabras.
Pero en producción aparece una limitación importante: no todas las consultas son semánticas.
Términos como nombres de API, códigos de error, identificadores internos, números de versión, referencias legales, SKU de producto o siglas muy específicas suelen comportarse mejor con búsqueda léxica tradicional. Si alguien busca HRESULT 0x80070057, AADSTS70011 o el nombre exacto de un método, el resultado relevante puede depender de encontrar esa cadena literal, no solo de aproximarse semánticamente a ella.
Por eso, en Azure AI Search, la opción más robusta para muchos escenarios no es elegir entre búsqueda de texto o búsqueda vectorial, sino combinarlas. La búsqueda híbrida permite enviar una única consulta que incluye una parte textual y una o varias consultas vectoriales. Azure AI Search ejecuta ambas aproximaciones y fusiona los resultados mediante Reciprocal Rank Fusion, o RRF.
Qué hace la búsqueda híbrida en Azure AI Search
Una consulta híbrida combina dos familias de señales:
- Búsqueda de texto completo, basada en el índice invertido y en ranking léxico, útil para coincidencias exactas, términos raros y consultas con vocabulario específico.
- Búsqueda vectorial, basada en embeddings, útil para recuperar contenido conceptualmente similar aunque no comparta las mismas palabras.
- Fusión de resultados con RRF, que combina listas ordenadas procedentes de distintas consultas sin intentar normalizar directamente puntuaciones que viven en escalas diferentes.
- Reranking semántico opcional, que puede reordenar el conjunto inicial de resultados usando modelos de comprensión del lenguaje de Microsoft.
El flujo lógico es el siguiente:
Consulta del usuario
│
├── Búsqueda de texto completo
│
├── Búsqueda vectorial
│
▼
Fusión con Reciprocal Rank Fusion
│
▼
Semantic ranker, si está habilitado
│
▼
Resultados finales
La documentación oficial de Azure AI Search describe la búsqueda híbrida como una única petición que incluye parámetros de búsqueda textual y vectorial, ejecuta esas búsquedas en paralelo y fusiona los resultados con RRF.
BM25, vectores y RRF: qué aporta cada capa
Búsqueda textual
La búsqueda textual sigue siendo muy valiosa cuando la consulta contiene términos que deben coincidir de forma precisa. Esto incluye:
- códigos de error;
- nombres de clases, métodos o endpoints;
- identificadores de producto;
- nombres propios;
- fechas;
- terminología especializada;
- expresiones que no tienen una representación semántica rica en el modelo de embeddings.
En estos casos, el índice invertido y el ranking textual pueden recuperar documentos que una búsqueda puramente vectorial podría no priorizar.
Búsqueda vectorial
La búsqueda vectorial funciona mejor cuando el usuario expresa una intención, un problema o una descripción conceptual. Por ejemplo:
- “cómo renovar credenciales caducadas”;
- “documentación sobre autenticación de aplicaciones”;
- “errores al iniciar sesión con permisos delegados”;
- “mejor forma de dividir documentos largos para RAG”.
Aquí los embeddings ayudan a encontrar contenido relacionado aunque los documentos no utilicen exactamente las mismas palabras que la consulta.
Reciprocal Rank Fusion
RRF combina listas de resultados ya ordenadas. En lugar de comparar directamente la puntuación textual con la puntuación vectorial, utiliza la posición de cada documento en cada lista. Un documento que aparece alto en varias listas tiende a recibir mejor puntuación final que uno que solo aparece en una lista o aparece en posiciones bajas.
Esta propiedad es útil porque las puntuaciones de búsqueda textual, búsqueda vectorial y reranking no tienen necesariamente la misma escala ni el mismo significado.
Semantic ranker: reranking sobre el primer conjunto de resultados
El semantic ranker de Azure AI Search es una capacidad opcional que mejora la relevancia reordenando un conjunto inicial de resultados. Según la documentación oficial, se aplica sobre resultados inicialmente ordenados mediante BM25 o RRF, y utiliza modelos de comprensión del lenguaje de Microsoft adaptados desde Bing.
En una consulta híbrida, el orden simplificado es:
- Azure AI Search obtiene candidatos mediante búsqueda textual y vectorial.
- Fusiona esos candidatos con RRF.
- Si se habilita semantic ranker, reordena el conjunto resultante.
- Opcionalmente, puede devolver captions y answers semánticos, si se solicitan y están soportados por la configuración de la consulta.
Es importante distinguir las puntuaciones:
@search.scorerepresenta la puntuación de búsqueda o fusión inicial.@search.rerankerScore, cuando semantic ranker está activo, representa la puntuación asignada por el reranker semántico.
Semantic ranker es una característica premium con facturación por uso, aunque puede existir uso gratuito sujeto a límites del servicio. Conviene validar el coste y las cuotas antes de activarlo de forma generalizada en producción.
Ejemplo de índice con campo vectorial y configuración semántica
Un índice típico para documentación técnica puede incluir campos textuales, metadatos filtrables y un campo vectorial. El siguiente ejemplo ilustra la estructura general de un índice con un perfil HNSW y una configuración semántica.
Ajusta
dimensionsal tamaño real de los embeddings que utilices. El valor debe coincidir con el modelo empleado para generar los vectores.
{
"name": "blog-articles",
"fields": [
{
"name": "id",
"type": "Edm.String",
"key": true,
"filterable": true
},
{
"name": "title",
"type": "Edm.String",
"searchable": true
},
{
"name": "content",
"type": "Edm.String",
"searchable": true
},
{
"name": "tags",
"type": "Collection(Edm.String)",
"filterable": true,
"facetable": true
},
{
"name": "date",
"type": "Edm.DateTimeOffset",
"sortable": true,
"filterable": true
},
{
"name": "content_vector",
"type": "Collection(Edm.Single)",
"searchable": true,
"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"
},
"prioritizedContentFields": [
{
"fieldName": "content"
}
],
"prioritizedKeywordsFields": [
{
"fieldName": "tags"
}
]
}
}
]
}
}
Este ejemplo asume que los embeddings ya se han generado durante la ingesta y se han almacenado en content_vector. Si quieres usar vectorización integrada en tiempo de consulta, debes configurar los vectorizers correspondientes en el índice y usar los tipos de consulta compatibles con esa configuración.
Ejemplo de consulta híbrida desde Python
En una consulta híbrida, se envía texto en search_text y, además, una consulta vectorial. El vector de la consulta debe generarse con el mismo modelo y la misma estrategia de normalización que se usaron al indexar los documentos.
from azure.search.documents import SearchClient
from azure.search.documents.models import QueryType, VectorizedQuery
# search_client debe estar inicializado con el endpoint, índice y credenciales.
# query_vector debe haberse generado previamente con el mismo modelo de embeddings
# utilizado durante la indexación.
results = search_client.search(
search_text=query_text,
vector_queries=[
VectorizedQuery(
vector=query_vector,
k_nearest_neighbors=50,
fields="content_vector"
)
],
query_type=QueryType.SEMANTIC,
semantic_configuration_name="semantic-config",
top=5,
select=["id", "title", "content", "tags", "date"]
)
for result in results:
print(result["title"])
print("search score:", result.get("@search.score"))
print("reranker score:", result.get("@search.rerankerScore"))
Si no quieres activar semantic ranker, puedes omitir query_type=QueryType.SEMANTIC y semantic_configuration_name. En ese caso, los resultados híbridos se fusionan con RRF, pero no pasan por la capa adicional de reranking semántico.
Parámetros que conviene ajustar
k_nearest_neighbors
Este parámetro indica cuántos vecinos vectoriales se recuperan antes de la fusión. Si pides muy pocos candidatos, puedes limitar la capacidad de RRF y del reranker para encontrar buenos resultados finales.
Una práctica habitual es recuperar más candidatos vectoriales que resultados finales. Por ejemplo, si la interfaz muestra 5 resultados, puede tener sentido recuperar 30, 50 o más candidatos vectoriales y medir el impacto en latencia y relevancia.
No hay un valor universal. Debe ajustarse con datos reales.
top
top controla cuántos resultados devuelve finalmente la consulta. En escenarios RAG, no siempre conviene pasar muchos fragmentos al modelo generativo. Más contexto no implica necesariamente mejor respuesta: también puede introducir ruido, aumentar coste y degradar la precisión.
Parámetros HNSW
En índices que usan HNSW, los parámetros principales son:
m: controla la conectividad del grafo. Valores más altos pueden mejorar la recuperación, pero aumentan el uso de memoria.efConstruction: afecta a la calidad de construcción del índice y al tiempo de indexación.efSearch: influye en el esfuerzo de búsqueda en tiempo de consulta. Valores más altos pueden mejorar recall, con mayor latencia.
Los valores adecuados dependen del tamaño del corpus, la distribución de los vectores, los objetivos de latencia y la exigencia de recall. No conviene cambiarlos sin un conjunto de evaluación que permita comparar resultados.
Filtros
Los filtros son útiles para limitar el espacio de búsqueda por metadatos como idioma, fecha, producto, permisos o tipo de documento. En sistemas empresariales, también son esenciales para aplicar recorte de seguridad.
Ejemplo:
results = search_client.search(
search_text=query_text,
vector_queries=[
VectorizedQuery(
vector=query_vector,
k_nearest_neighbors=50,
fields="content_vector"
)
],
query_type=QueryType.SEMANTIC,
semantic_configuration_name="semantic-config",
filter="tags/any(t: t eq 'Azure')",
top=5,
select=["id", "title", "content", "tags", "date"]
)
Al trabajar con búsqueda vectorial e híbrida, valida cuidadosamente cómo afectan los filtros al recall. Un filtro demasiado restrictivo puede eliminar documentos relevantes antes de que lleguen a la fusión o al reranking.
Evaluar la calidad de recuperación
La búsqueda híbrida debe evaluarse con consultas representativas, no solo con ejemplos manuales que “parecen funcionar”. Algunas métricas útiles son:
- Recall@k: mide si los documentos relevantes aparecen dentro de los primeros
kresultados. - MRR: mide la posición del primer resultado relevante.
- nDCG@k: tiene en cuenta tanto la relevancia como la posición de los resultados.
- Precisión@k: mide cuántos de los primeros
kresultados son relevantes. - Tasa de respuestas sin evidencia suficiente en sistemas RAG.
- Feedback explícito o implícito de usuarios: clics, reformulaciones, votos positivos/negativos o abandono.
Para sistemas RAG, la evaluación debe separar dos cosas:
- Calidad de recuperación: si los documentos correctos aparecen en el contexto.
- Calidad de generación: si el modelo responde bien usando ese contexto.
Si la recuperación falla, el modelo generativo suele compensar mal: puede responder de forma incompleta, mezclar fuentes o alucinar. Por eso, en arquitecturas RAG, mejorar el pipeline de recuperación suele tener un impacto mayor que cambiar únicamente el modelo generativo.
Buenas prácticas para producción
Al diseñar búsqueda híbrida en Azure AI Search, conviene aplicar algunas reglas prácticas:
- Mantén campos textuales limpios y bien segmentados. Los embeddings no compensan una mala estrategia de chunking.
- Conserva metadatos filtrables: producto, versión, idioma, fecha, permisos y tipo de documento.
- Usa búsqueda textual para identificadores exactos y terminología crítica.
- Usa búsqueda vectorial para intención semántica y reformulaciones.
- Activa semantic ranker cuando la mejora de relevancia justifique coste y latencia.
- Evalúa con consultas reales y etiquetas de relevancia, no solo con pruebas exploratorias.
- Monitoriza latencia, coste y calidad de respuesta de forma continua.
- No mezcles embeddings generados con modelos distintos en el mismo campo vectorial salvo que tengas una estrategia explícita para ello.
- Asegúrate de que el vector de consulta y los vectores indexados tienen la misma dimensionalidad y proceden del mismo modelo o de modelos compatibles.
Cuándo usar búsqueda híbrida
La búsqueda híbrida suele ser una buena elección cuando:
- el corpus contiene tanto lenguaje natural como términos técnicos exactos;
- los usuarios formulan consultas de formas muy distintas;
- hay códigos, nombres propios, siglas o identificadores importantes;
- el sistema alimenta un flujo RAG y necesitas mejorar la calidad del contexto;
- quieres combinar precisión léxica con recuperación semántica.
En cambio, si tu caso es puramente estructurado, con filtros exactos y poca ambigüedad semántica, puede bastar con búsqueda textual y filtros. Si tu caso es puramente exploratorio y sin dependencia de términos exactos, la búsqueda vectorial puede ser suficiente. En la práctica, muchos sistemas empresariales contienen ambos patrones, y por eso la búsqueda híbrida suele ofrecer un equilibrio más sólido.
Conclusión
Azure AI Search permite combinar búsqueda textual y vectorial en una única consulta híbrida. La fusión mediante RRF evita comparar directamente puntuaciones incompatibles y produce una lista unificada de resultados. Sobre esa lista, semantic ranker puede aplicar una capa adicional de reranking para mejorar la relevancia cuando el coste y la latencia encajan con el caso de uso.
Para sistemas RAG, esta combinación es especialmente importante: el modelo generativo solo puede responder bien si recibe contexto relevante. La búsqueda híbrida no elimina la necesidad de evaluar, ajustar y monitorizar, pero proporciona una base más robusta que depender únicamente de embeddings o únicamente de coincidencias léxicas.