¿Qué es una búsqueda semántica?

La búsqueda semántica es la que encuentra documentos por lo que significan, no por las palabras exactas que contienen. Convierte cada texto en un vector numérico (un embedding) y devuelve los fragmentos cuyo significado se parece más al de la consulta, aunque no compartan ni una palabra. Es lo que permite que quien busca “efectos secundarios” encuentre un documento que solo habla de “reacciones adversas”.

Imaginemos un buscador interno de una empresa. Una persona escribe “¿Cómo recupero el acceso a mi cuenta?” y la documentación contiene un apartado titulado “Restablecimiento de credenciales”. La búsqueda semántica puede recuperar ese apartado aunque el título use otras palabras: relaciona la necesidad de recuperar el acceso con el procedimiento para restablecer las credenciales.

Los límites de la búsqueda clásica

Desde que Internet se popularizó, hemos concebido el buscador como la puerta de entrada al conocimiento. AltaVista, el directorio de Yahoo! y después Google nos acostumbraron a la idea de que basta con escribir unas palabras y esperar a que aparezca la respuesta.

Un buscador clásico rastrea millones de documentos (por ejemplo, páginas web) y los indexa: construye un gran mapa que indica en qué documentos aparece cada palabra. Cuando el usuario escribe algo, compara esos términos con el índice y decide qué páginas son más relevantes.

Este tipo de búsqueda es léxica: se basa en palabras y en coincidencias de palabras. No intenta entender lo que el usuario quiere decir. El problema que resuelve es otro: qué palabras ha escrito, en qué documentos aparecen y con qué peso.

Para mejorar los resultados, los buscadores clásicos aplican técnicas de stemming o lematización, que reducen las variantes de una palabra a una forma común. Así, “correr”, “corriendo” o “corrí” pasan a ser una misma familia.

Además, no basta con encontrar coincidencias: hay que decidir cuáles son las más relevantes y presentarlas en orden. Para ello se ponderan señales como la frecuencia de la palabra, su posición, la popularidad de la página, la calidad de los enlaces que recibe o la frescura del contenido. El algoritmo clásico para puntuar las coincidencias de palabras es BM25, que sigue siendo el punto de partida de muchos buscadores. Descubrir y aprovechar los factores que determinan el ranking es a lo que se dedica el SEO.

Los buscadores clásicos son rápidos y funcionan muy bien con nombres propios, referencias de producto, identificadores y normas. Son potentes cuando la consulta y el documento comparten vocabulario, y es fácil entender por qué apareció un resultado concreto.

Pero también tienen límites. A menudo se produce lo que en el lenguaje técnico se denomina vocabulary mismatch: el usuario y el documento hablan de lo mismo, pero con palabras distintas. Un paciente busca “efectos secundarios” y el prospecto habla de “reacciones adversas”; lo que uno llama “coche”, otro lo llama “auto” y otro “vehículo”. Los términos cambian con el tiempo, muchas palabras son polisémicas (un “banco” sirve para sentarse en la calle y para abrir una cuenta) y cada idioma expresa las cosas a su manera.

Puede parecer un problema menor, pero el estudio de referencia de Le Zhao y Jamie Callan, Term Necessity Prediction (se abre en una pestaña nueva) (CIKM 2010), mostró que un término de búsqueda medio no aparece en un 30 % a 40 % de los documentos relevantes para esa búsqueda.

El desarrollo de la búsqueda semántica

Encontrar documentos que hablen de lo mismo aunque no usen las mismas palabras tiene una larga historia. Un hito temprano fue el Latent Semantic Indexing (LSI), con solicitud de patente presentada en 1988 y patente concedida en 1989 (se abre en una pestaña nueva), que partía de una idea sencilla: las palabras con significado parecido aparecen en fragmentos de texto parecidos.

Después llegaron Word2Vec (se abre en una pestaña nueva), en 2013, y GloVe (se abre en una pestaña nueva), en 2014, que popularizaron la representación de palabras como vectores capaces de capturar regularidades semánticas y sintácticas. Su limitación era que resultaban estáticos: cada palabra tenía un único vector, fuera cual fuera el contexto. El “banco” del parque y el “banco” de la cuenta corriente quedaban representados igual.

El gran avance llegó con la arquitectura de transformadores, presentada por investigadores de Google en 2017 (se abre en una pestaña nueva) y base de los grandes modelos de lenguaje actuales. En 2018, también en Google, se creó BERT (se abre en una pestaña nueva), un modelo que interpreta cada palabra según las que la rodean. Y en 2019 Nils Reimers e Iryna Gurevych, de la Universidad Técnica de Darmstadt, publicaron SBERT (se abre en una pestaña nueva) (Sentence-BERT) junto con la librería de código abierto sentence-transformers, hoy una de las más utilizadas en Python para búsqueda vectorial.

La aportación clave de SBERT fue práctica. Para encontrar las dos frases más parecidas entre 10.000, BERT necesitaba comparar cada pareja: unos 50 millones de cálculos y cerca de 65 horas. SBERT convierte cada frase en un vector una sola vez y reduce la tarea a unos 5 segundos (se abre en una pestaña nueva), con una precisión similar. Ese esquema en dos etapas es el que seguimos usando hoy:

1. Precomputación. Los documentos se dividen en fragmentos y cada fragmento se pasa una sola vez por el modelo. El vector resultante se guarda en una base de datos vectorial.
2. Búsqueda. Cuando el usuario escribe una consulta, la frase se convierte en vector y se buscan, entre los vectores ya calculados, los más cercanos. Con millones de fragmentos no se compara uno a uno: se usan índices de vecinos aproximados, como HNSW (se abre en una pestaña nueva), que encuentran los más próximos sin recorrer toda la colección.

Convertir el significado en geometría

Un vector define un lugar en un espacio de N dimensiones. En un plano, de dos dimensiones, cualquier posición se describe con dos números: (2, -1), (3, 0) o (-5, 3). ¿Por qué hablamos de vectores y no de puntos? Porque vamos a operar con ellos y a medir los ángulos que forman entre sí, y para eso hay que verlos como flechas que salen del origen.

Si en lugar de dos dimensiones tuviéramos tres, añadiríamos un número más. Un modelo de embeddings trabaja con cientos o miles: cada fragmento se transforma en un vector de longitud fija que resume su significado.

Esa longitud la fija el modelo. Los modelos base de Sentence-BERT usan 768 dimensiones; uno compacto como all-MiniLM-L6-v2 (se abre en una pestaña nueva), 384; y los más grandes de OpenAI (se abre en una pestaña nueva) llegan a 3.072. Más dimensiones no garantizan mejores resultados: la calidad depende sobre todo de cómo se entrenó el modelo y de si sus textos de entrenamiento se parecen a los de nuestro dominio. Lo que sí implican es más coste, porque cada vector ocupa más memoria y cada comparación exige más cálculo. Por eso han aparecido modelos, llamados Matryoshka (se abre en una pestaña nueva), cuyos vectores se pueden recortar a una fracción de su tamaño perdiendo poca precisión.

Para comparar vectores se usa la similitud del coseno. Mide el ángulo que forman las flechas, no lo lejos que están sus puntas:

• Si dos vectores apuntan en la misma dirección, el ángulo es de 0° y el coseno vale 1: es la máxima similitud según esta medida.
• Si son perpendiculares, el ángulo es de 90° y el coseno vale 0. En la práctica rara vez se llega a 0; los textos sin relación suelen quedarse en valores bajos pero positivos.
• En teoría, si apuntan en direcciones opuestas, el coseno vale -1. En la práctica, con embeddings de texto casi nunca ocurre, y no conviene leerlo como “significado opuesto”.

La primera vez que uno ve que “caliente” y “frío” salen casi pegados, piensa que el modelo está roto. No lo está. Palabras como esas aparecen en contextos muy parecidos (hablamos de temperatura, de bebidas, del tiempo) y el modelo suele colocarlas cerca. Para él, dos antónimos hablan del mismo tema, que es justo lo que mide la similitud.

Las palabras pueden no coincidir; basta con que el resultado signifique algo parecido. El paciente que busca “efectos secundarios” llega al apartado de “reacciones adversas”.

Lo mejor de los dos mundos

La búsqueda semántica tiene sus propios fallos. Puede devolver resultados que se parecen en tema pero no responden a la pregunta, y le cuesta justo lo que al buscador clásico se le da bien: una referencia exacta, un código de producto, el número de una norma.

La más extendida es el re-ranking. Primero se recupera deprisa una lista amplia de candidatos (con embeddings, a veces recortados para ganar velocidad) y después un modelo más preciso, un cross-encoder, lee cada candidato junto a la consulta y reordena la lista. Es más lento, pero solo trabaja sobre unas decenas de resultados.

La otra es la búsqueda híbrida. Lo hemos visto en buscadores de tienda online: alguien escribe la referencia exacta de un producto y le sale en cuarta posición, detrás de tres “parecidos”. Lo razonable es que ese producto aparezca el primero; que vea también productos relacionados está bien, pero no a costa del que buscaba. En un enfoque híbrido se lanzan las dos búsquedas a la vez, la léxica (BM25) y la semántica, y se combinan sus listas. Una forma sencilla de hacerlo es la Reciprocal Rank Fusion (se abre en una pestaña nueva), que premia los resultados bien situados en ambas listas sin tener que ajustar pesos a mano.

Cada combinación de técnicas encaja mejor en un caso u otro. No es lo mismo un buscador como Google que el buscador de productos de una tienda o el buscador interno con el que una empresa quiere localizar sus propios documentos. En este último caso, los modelos de embeddings pueden ejecutarse dentro de la propia infraestructura, como contamos en nuestro artículo sobre modelos locales, y la búsqueda semántica es un componente habitual de los asistentes que responden con documentación propia.

Si tenéis un buscador que no encuentra lo que la gente busca, podemos mirarlo juntos: desde el de una tienda hasta el documental de toda una empresa.