Búsqueda Híbrida: Combinando lo Semántico y lo Léxico
Qué cubre este artículo
- Comprendes qué es la búsqueda híbrida y por qué importa para sistemas RAG
- Conoces la diferencia entre búsqueda léxica y búsqueda semántica
- Ves cómo se combinan ambos enfoques, incluyendo métodos como Reciprocal Rank Fusion
- Tienes ejemplos de código concretos para Chroma, Qdrant y LanceDB
- Identificas las trampas típicas y cómo evitarlas
Introducción: Búsqueda Híbrida explicada
En RAG local el objetivo es encontrar pasajes relevantes en tus documentos y proporcionarlos como contexto a un modelo de lenguaje. La calidad de las respuestas depende en gran medida de qué tan bien funciona la búsqueda. La búsqueda híbrida combina dos estrategias que cada una tiene fortalezas y debilidades propias: la búsqueda léxica y la búsqueda semántica. Juntas entregan resultados significativamente mejores que cualquiera de los métodos por separado.
Si quieres profundizar en los fundamentos, encontrarás más información en Fundamentos de RAG y en el artículo de descripción general Qué es IA local.
¿Por qué necesito búsqueda híbrida?
Imagina que buscas en documentación técnica el término “Error 404”. Una búsqueda pura por vectores, es decir, una búsqueda semántica, entiende el significado de tu consulta. Encuentra secciones sobre “Página no encontrada” o “Page not found”, porque el término es semánticamente relacionado. Pero probablemente pierda el código de error exacto 404, ya que una número tiene poco peso semántico en el espacio vectorial.
Una búsqueda pura por palabras clave, la búsqueda léxica, encuentra cada documento que contiene la palabra “404”. Localiza el código de error de forma confiable. Pero pierde todas las secciones que describen el problema sin mencionar el número. Una sección sobre “Página no encontrada” no aparecerá si no contiene la palabra “404”.
La búsqueda híbrida ejecuta ambas búsquedas y combina los resultados. Así encuentras tanto el código de error exacto como las explicaciones semánticamente relacionadas. Es particularmente valioso en documentación técnica, referencias de API y manuales, donde códigos, nombres y términos técnicos conviven con texto descriptivo.
Búsqueda Híbrida en pocas palabras
La búsqueda híbrida es como un bibliotecario que busca simultáneamente de dos formas. Por un lado pregunta: “¿Qué libros tratan el mismo tema que tu pregunta?” Esa es la búsqueda semántica, se enfoca en significado y contexto. Por otro lado pregunta: “¿Qué libros contienen exactamente las palabras que mencionaste?” Esa es la búsqueda léxica, se enfoca en coincidencias exactas.
Ambos conjuntos de resultados se fusionan y se ordenan por relevancia. Un documento que aparece alto en ambas listas también ocupa un lugar destacado en el resultado final. Un documento que solo sobresale en una lista se penaliza. De esta forma la búsqueda se beneficia de ambas fortalezas al mismo tiempo.
¿Para quién es la búsqueda híbrida?
La búsqueda híbrida está dirigida a cualquiera que construya sistemas RAG y quiera mejorar la calidad de búsqueda. Incluye desarrolladores que construyen bases de datos de conocimiento interno, equipos que hacen documentaciones consultables, y usuarios que implementan soluciones de IA local para sus propios documentos. Los casos de uso que más se benefician son aquellos con una mezcla de texto descriptivo e información estructurada como códigos, IDs, nombres o términos técnicos.
Si recién comienzas con RAG, es recomendable leer primero Fundamentos de RAG y Modelos de Embedding antes de profundizar en búsqueda híbrida.
Términos clave en búsqueda híbrida
| Término | Significado |
|---|---|
| Búsqueda Híbrida | Combinación de búsqueda léxica y búsqueda semántica |
| Dense Retrieval | Búsqueda semántica sobre vectores densos, también llamados embeddings |
| Sparse Retrieval | Búsqueda léxica sobre vectores sparse, donde solo ciertas dimensiones están pobladas |
| BM25 | Algoritmo mejorado de TF-IDF para búsqueda por palabras clave |
| TF-IDF | Medida de la importancia de una palabra en un documento |
| Embedding | Vector numérico que representa el significado de un texto |
| Palabra clave | Término de búsqueda que debe aparecer exactamente en el texto |
| Semántica | Relacionado con el significado, no con coincidencia exacta de palabras |
| Fusión | Método para combinar múltiples listas de resultados en una sola |
| RRF | Reciprocal Rank Fusion, un método de fusión ampliamente utilizado |
¿Qué es la búsqueda léxica?
La búsqueda léxica es la búsqueda de texto clásica. Busca coincidencias exactas de palabras entre la consulta y el documento. Los algoritmos más conocidos son TF-IDF y BM25.
TF-IDF significa Term Frequency, Inverse Document Frequency. El algoritmo evalúa con qué frecuencia aparece una palabra en un documento y la pondera más alto si aparece en pocos documentos. Una palabra que aparece en todas partes tiene menos valor informativo.
BM25 se basa en TF-IDF y lo mejora. BM25 considera la longitud del documento y reduce el efecto de palabras muy frecuentes. Esto produce resultados más relevantes. BM25 sigue siendo el estándar para búsqueda por palabras clave y se utiliza en motores de búsqueda como Elasticsearch y Lucene.
Las fortalezas de la búsqueda léxica radican en coincidencias exactas. Encuentra nombres, códigos de error, números de versión, IDs y términos técnicos de forma confiable. Si un documento no contiene la palabra buscada, no aparece en los resultados. En muchas consultas ese es exactamente el comportamiento deseado.
¿Qué es la búsqueda semántica?
La búsqueda semántica funciona con embeddings. Un modelo de embedding convierte texto en un vector que representa el significado del texto. Para una consulta de búsqueda también se genera un vector, y la base de datos vectorial busca los vectores más cercanos. Más información en Modelos de Embedding.
La fortaleza de la búsqueda semántica está en entender significado. Reconoce sinónimos, paráfrasis y relación temática. Una búsqueda “¿Cómo detengo el servidor?” encuentra también secciones sobre “Apagar el servidor” o “Terminar el proceso”, sin necesidad de que las palabras coincidan exactamente.
La debilidad de la búsqueda semántica aparece con términos específicos. Un código de error como “404” o un nombre de producto como “Model-X100” tiene poco significado semántico. El vector de un número o un ID difiere poco de otros números o IDs. La búsqueda semántica encuentra estos términos deficientemente o no los encuentra en absoluto.
Debilidades de ambos enfoques
Ninguno de los dos métodos es óptimo por sí solo. Cada uno tiene puntos ciegos donde falla.
La búsqueda léxica fracasa cuando la consulta y el documento usan palabras diferentes para el mismo concepto. Quien busca “auto” no encuentra un documento que solo contiene “vehículo”. Quien busca “detener servidor” no encuentra documentos sobre “terminar proceso”. No entiende sinónimos ni paráfrasis.
La búsqueda semántica fracasa con términos exactos que carecen de significado semántico. Códigos de error, números de versión, IDs, nombres de productos y abreviaturas son difíciles de distinguir en el espacio vectorial. La búsqueda “HTTP 500” tal vez encuentra todas las secciones sobre errores del servidor, pero no la que contiene exactamente ese código.
La búsqueda híbrida resuelve este problema ejecutando ambas búsquedas y combinando los resultados. Las fortalezas de un método compensan las debilidades del otro.
Cómo funciona Hybrid Search
Hybrid Search opera en tres pasos:
- Búsqueda léxica: La consulta se busca contra todos los documentos usando BM25 u otro algoritmo similar. El resultado es una lista ordenada por relevancia de palabras clave.
- Búsqueda semántica: La consulta se convierte en un vector y se busca contra todos los embeddings en la base de datos vectorial. El resultado es una lista ordenada por similitud vectorial.
- Fusión: Ambas listas se combinan en una sola. Los documentos que salen bien en ambas listas aparecen arriba.
La fusión es el paso crítico. Existen varios métodos para combinar dos listas ordenadas. Los dos más conocidos son la suma ponderada y la Reciprocal Rank Fusion.
Con la suma ponderada, cada lista obtiene un factor. Por ejemplo, 0.7 para la búsqueda semántica y 0.3 para la léxica. Los scores se suman para dar un score total. El problema: los scores de ambas búsquedas suelen estar en escalas diferentes, lo que complica la ponderación.
Reciprocal Rank Fusion resuelve esto combinando los rangos en lugar de los scores. Así, las escalas son irrelevantes.
Reciprocal Rank Fusion (RRF)
RRF es el método de fusión más usado en Hybrid Search. Combina listas ordenadas sin conocer los scores reales. Esto la hace robusta y fácil de aplicar.
La fórmula es:
RRF(d) = suma sobre todas las listas de: 1 / (k + rango(d))Donde d es el documento, rango(d) es su posición en cada lista, y k es una constante, típicamente 60. Un documento en posición 1 en ambas listas obtiene un RRF-score alto. Uno que solo destaca en una lista obtiene un score medio.
El parámetro k controla cuánto se pesan los rangos superiores. Un k pequeño hace los primeros lugares dominantes; uno grande distribuye la influencia de manera más uniforme. El valor 60 ha demostrado ser práctico y se usa como estándar en muchos sistemas.
RRF es popular porque no requiere normalización de scores. Los scores de BM25 y las similitudes de coseno están en escalas completamente distintas. RRF ignora los scores y usa solo los rangos. Esto la hace robusta contra problemas de escala.
Implementación con herramientas locales
Varias bases de datos vectoriales locales soportan Hybrid Search directamente. A continuación verás ejemplos con Chroma, Qdrant y LanceDB. Encontrarás más información sobre estas bases de datos en Vektordatenbanken.
Chroma
Chroma ofrece Hybrid Search combinando búsqueda de embeddings con su propia implementación de BM25. Más detalles en Chroma.
import chromadb
client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection("dokumente")
# Agregar documentos
collection.add(
documents=["Error 404: Seite nicht gefunden", "Server stoppen und neu starten"],
metadatas=[{"quelle": "docs"}, {"quelle": "docs"}],
ids=["doc1", "doc2"]
)
# Búsqueda semántica
results_semantic = collection.query(
query_texts=["Seite nicht gefunden"],
n_results=5
)
# Búsqueda léxica via filtros where o BM25 externo
# Chroma soporta Hybrid Search via Custom Embedding Functions
# o implementaciones BM25 externas como rank_bm25
from rank_bm25 import BM25Okapi
docs = collection.get()["documents"]
tokenized = [doc.lower().split() for doc in docs]
bm25 = BM25Okapi(tokenized)
scores = bm25.get_scores("404 seite nicht gefunden".split())En la práctica, combinas los resultados de ambas búsquedas con RRF. Chroma ofrece creciente soporte nativo para Hybrid Search, pero la combinación manual con rank_bm25 es un enfoque probado.
Qdrant
Qdrant soporta Hybrid Search nativamente a través de vectores sparse y dense. Más en Qdrant.
from qdrant_client import QdrantClient
from qdrant_client.models import SparseVector, SearchRequest, FusionQuery
client = QdrantClient(path="./qdrant_db")
# Búsqueda híbrida con fusión nativa
results = client.query_points(
collection_name="dokumente",
prefetch=[
SearchRequest(
using="dense",
vector=[0.1, 0.2, 0.3], # Embedding de la consulta
limit=20
),
SearchRequest(
using="sparse",
vector=SparseVector(
indices=[10, 25, 80],
values=[0.8, 0.5, 0.3]
),
limit=20
)
],
query=FusionQuery(fusion="rrf"),
limit=10
)Qdrant ejecuta la fusión directamente en el servidor. No necesitas implementar RRF tú mismo. Esto es especialmente útil cuando tienes muchos documentos y quieres que la fusión sea eficiente.
LanceDB
LanceDB también ofrece Hybrid Search con soporte integrado para RRF.
import lancedb
db = lancedb.connect("./lancedb_db")
table = db.open_table("dokumente")
# Búsqueda híbrida con FTS y búsqueda vectorial
results = table.search(
query="Error 404",
query_type="hybrid"
).limit(10).to_list()LanceDB combina Full-Text Search y búsqueda vectorial en una sola llamada. La fusión ocurre automáticamente vía RRF.
Ejemplo: Hybrid Search en documentación
Imagina una documentación con estas secciones:
- Sección A: “Error 404: La página solicitada no fue encontrada.”
- Sección B: “Si una página no existe, el servidor devuelve un error.”
- Sección C: “Error 500: Error interno del servidor al procesar.”
La consulta es: “¿Qué significa Error 404?”
Búsqueda léxica (BM25):
- Sección A, contiene “Error” y “404” exactamente
- Sección C, contiene “Error”, pero no “404”
- Sección B, no contiene ninguna de las palabras
Búsqueda semántica (búsqueda vectorial):
- Sección B, semánticamente más cercana, “página no existe” coincide con la pregunta
- Sección A, semánticamente relacionada, contiene el error
- Sección C, semánticamente relacionada, pero error diferente
Hybrid Search (RRF):
- Sección A, bien posicionada en ambas listas
- Sección B, en posición 1 en la lista semántica
- Sección C, posición media en ambas listas
La Sección A termina en primer lugar porque cubre tanto el código exacto como el significado semántico. Este es el beneficio de Hybrid Search: lo mejor de ambos mundos al final.
Trampa típicas en Hybrid Search
Hybrid Search es potente, pero hay algunos obstáculos que debes considerar.
- Ponderación incorrecta: Si usas suma ponderada en lugar de RRF, las ponderaciones inadecuadas pueden sesgar los resultados. Prueba diferentes pesos con consultas reales.
- Tokenización en BM25: Los compuestos alemanes como “Datenbankverbindung” no se dividen con tokenizadores simples. Un stemmer o tokenizador para alemán mejora significativamente la búsqueda por palabras clave.
- Tamaños de chunk diferentes: Si la búsqueda léxica y semántica funcionan en chunks de diferentes tamaños, los resultados son difíciles de comparar. Ambas búsquedas deben usar los mismos chunks.
- Indexación faltante: BM25 requiere un índice invertido. Si solo usas una base de datos vectorial, debes construir el índice para la búsqueda por palabras clave por separado.
- Dependencia del idioma: BM25 depende del idioma. Un tokenizador en inglés funciona mal para textos en alemán. Asegúrate de que la tokenización coincida con el idioma de tus documentos.
- Demasiados resultados: Si ambas búsquedas devuelven 100 resultados cada una, la fusión se vuelve lenta e inmanejable. Limita el número de resultados por búsqueda a 20 o 50.
- Sin reranking: Hybrid Search proporciona buenos candidatos, pero el orden no es perfecto. Un modelo de reranking posterior mejora la calidad. Más en Reranking.
Hardware, costos y seguridad en Hybrid Search
Hybrid Search requiere dos índices: uno vectorial para la búsqueda semántica y otro invertido para la búsqueda léxica. Juntos necesitan más memoria que un único índice, pero el sobrecosto es moderado. Los índices BM25 son compactos y rápidos.
Capacidad de cómputo: La búsqueda semántica necesita un modelo de embedding que vectorice la consulta. Es lo suficientemente rápido en CPU. La búsqueda léxica es muy veloz y exige pocos recursos. La fusión en sí es trivial y consume apenas tiempo.
Costos: Todas las herramientas necesarias son Open Source y gratuitas. Chroma, Qdrant y LanceDB están bajo licencias libres. Las implementaciones de BM25 como rank_bm25 también son de libre acceso.
Seguridad: Si todos los componentes corren localmente, tus documentos permanecen en tu máquina. Ni la consulta ni los documentos abandonan el sistema. Esta es una ventaja central de la IA local, tal como se describe en ¿Qué es la IA local?.
Enlaces e información adicional sobre Hybrid Search
- RAG local como tema transversal
- Fundamentos de RAG para lo básico
- Modelos de embedding para el lado semántico
- Bases de datos vectoriales para almacenamiento
- Chroma con ejemplos de Hybrid Search
- Qdrant con soporte nativo para Hybrid Search
- Reranking como siguiente paso útil después de Hybrid Search
FAQ: Hybrid Search - Preguntas frecuentes
¿Qué es Hybrid Search explicado de forma simple?
Hybrid Search combina la búsqueda clásica por palabras clave con la búsqueda semántica vectorial. Ambas búsquedas se ejecutan y los resultados se fusionan. De esta forma, la búsqueda se beneficia simultáneamente de coincidencias exactas y comprensión semántica.
¿Necesito Hybrid Search para cada sistema RAG?
No necesariamente. Para textos corridos sin código o nombres, la búsqueda semántica suele ser suficiente. En cambio, si tus documentos contienen códigos de error, IDs, nombres de productos u otros términos exactos, se recomienda Hybrid Search.
¿Cuál es la diferencia entre Dense Retrieval y Sparse Retrieval?
Dense Retrieval utiliza vectores densos, es decir, embeddings donde todas las dimensiones están ocupadas. Sparse Retrieval usa vectores dispersos donde solo unas pocas dimensiones están ocupadas, típicamente para búsqueda por palabras clave. Hybrid Search combina ambos.
¿Qué es RRF y por qué se usa tan frecuentemente?
RRF significa Reciprocal Rank Fusion. Combina listas de ranking sin conocer los scores concretos. Esto lo hace robusto frente a diferentes escalas de puntuación. Es simple de implementar y proporciona buenos resultados en la práctica.
¿Tengo que implementar BM25 yo mismo?
No. Existen bibliotecas listas como rank_bm25 para Python. Qdrant y LanceDB ofrecen BM25 directamente en la base de datos. Chroma puede combinarse con bibliotecas externas de BM25.
¿Cómo elijo el peso entre búsqueda vectorial y búsqueda por palabras clave?
Con RRF no necesitas configurar un peso, el método combina automáticamente. Con suma ponderada comienza con 0.5 para ambas y prueba con consultas reales. Ajusta el peso hasta que los resultados se alineen con tus expectativas.
¿Funciona Hybrid Search con textos en alemán?
Sí, pero la tokenización para BM25 debe configurarse en alemán. Un stemmer alemán y una lista de palabras vacías mejoran la búsqueda por palabras clave. Para la búsqueda semántica deberías usar un modelo de embedding multilingüe.
¿Es Hybrid Search más lento que una búsqueda individual?
Sí, se ejecutan dos búsquedas. La diferencia de velocidad es pequeña porque ambas pueden ejecutarse en paralelo. La fusión en sí es muy rápida. En la práctica apenas se nota la diferencia.
¿Debería usar Reranking después de Hybrid Search?
Sí, es recomendable. Hybrid Search entrega buenos candidatos, pero el orden puede mejorarse aún más con un modelo de reranking. Este evalúa nuevamente los principales resultados con un modelo más potente.
¿Puedo usar Hybrid Search sin GPU?
Sí. La búsqueda léxica no requiere GPU. La búsqueda semántica necesita un modelo de embedding que corra en CPU. Para colecciones de documentos pequeñas a medianas, la CPU es lo suficientemente rápida.
¿Qué bases de datos vectoriales soportan Hybrid Search nativamente?
Qdrant y LanceDB soportan Hybrid Search con RRF integrada directamente. Chroma puede ampliarse con bibliotecas externas de BM25. Weaviate y Milvus también ofrecen funcionalidades nativas de Hybrid Search.
Fuentes y bibliografía adicional
- Artículo original sobre Reciprocal Rank Fusion de Cormack et al.
- Documentación de Qdrant sobre Hybrid Search
- Documentación de LanceDB sobre Hybrid Search
- Documentación de Chroma
- Publicación original de BM25 de Robertson y Zaragoza
- Documentación de Sentence Transformers