Cómo funciona la búsqueda semántica en 2026
Cómo funciona la búsqueda semántica: embeddings, vectores y búsqueda híbrida explicados con claridad, y por qué la búsqueda por palabra clave no basta.
Escribe «cuánto cuesta adquirir clientes» en el buscador de tus marcadores y verás que no aparece nada. El video que buscas está en tu biblioteca: lo guardaste. El ponente dijo «CAC» dieciséis veces. Tú escribiste «coste de adquisición de clientes». Las palabras no coinciden. La búsqueda falla.
Este fallo tiene nombre: el problema del desajuste de vocabulario. Es la razón por la que la búsqueda por palabra clave sigue quedándose corta, y la razón por la que la búsqueda semántica es hoy la opción por defecto en cualquier herramienta seria que busque en texto. A continuación, cómo funciona de verdad la búsqueda semántica en 2026, explicado con claridad y sin necesidad de saber matemáticas, y por qué la mayoría de las apps de consumo que anuncian «búsqueda con IA» todavía lo hacen mal.
El problema del desajuste de vocabulario en 60 segundos
Los sistemas de búsqueda antiguos buscaban cadenas de texto literales. Escribías coste de adquisición de cliente y el sistema encontraba los documentos que contenían exactamente esas palabras. Los que decían «CAC», «cuánto pagamos por conseguir compradores nuevos» o «lo que nos cuesta cada registro» no aparecían.
En el campo de la recuperación de información esto se mide desde hace cuarenta años. El desajuste de vocabulario típico ronda el 70-80%: la mayoría de las veces, la gente usa palabras distintas para el mismo concepto. Si tu búsqueda solo encuentra coincidencias literales, te pierdes cuatro de cada cinco documentos relevantes. Es una forma educada de decir que la búsqueda por palabra clave lleva rota desde 1985.
Lo arreglaron dos cosas. La primera, los embeddings: una forma de representar el significado con números, de modo que dos frases que significan lo mismo quedan «cerca» aunque no compartan palabras. La segunda, las bases de datos vectoriales: almacenamiento e índices capaces de encontrar rápido los vectores más cercanos, incluso cuando hay millones de documentos.
Juntas, son las que hacen que la «búsqueda semántica» exista como categoría.
Qué es un embedding, explicado sin rodeos
Toma una frase. Pásala por una red neuronal. La red devuelve una lista de números, normalmente 384, 768 o 1.536. Esa lista es el embedding de la frase.
La clave es que la red está entrenada para que frases con significados parecidos den listas parecidas. Un ejemplo concreto:
"Qué es el coste de adquisición de cliente"→ embedding A"Cuánto pagamos por traer un cliente nuevo"→ embedding B"Qué tal las gaviotas hoy"→ embedding C
Los embeddings A y B estarán cerca en el espacio de 1.536 dimensiones en el que se sitúan. C estará lejos. La cercanía se mide con la similitud coseno, que indica cuánto se alinean los dos vectores en ese espacio. Un valor cercano a 1,0 significa un significado casi idéntico; cercano a 0, que no tienen relación.
Puedes imaginarlo como si cada frase fuera un punto en una galaxia de 1.536 dimensiones en la que la dirección representa el significado. Las coordenadas en sí no significan nada: lo que importa es qué frases quedan cerca de cuáles.
El modelo que lo hace
En 2026 hay varios modelos a la par. text-embedding-3-small de OpenAI genera 1.536 dimensiones de forma nativa y admite Matryoshka representation (puedes recortar a 768 o 256 dimensiones para ahorrar espacio sin volver a entrenar). embed-v3 de Cohere compite bien con contenido multilingüe. Las alternativas de código abierto, como bge-large y nomic-embed-text, están a pocos puntos de precisión y funcionan en un Mac.
Para contenido multilingüe, como los videos que han guardado los usuarios de SavedThat (en 24 idiomas a 30 de septiembre de 2026, con búsquedas en cualquiera de ellos), text-embedding-3-small ofrece ahora mismo el mejor equilibrio entre precisión, coste y dimensiones. En SavedThat usamos el recorte Matryoshka a 768 dimensiones: la mitad de espacio y ~99% de la calidad de búsqueda. (Más sobre Matryoshka representation.)
Por qué «meterle IA» no es lo mismo que búsqueda semántica
Muchas apps de consumo anuncian en 2026 «búsqueda con IA». La mayoría se refiere a una de estas tres cosas:
- Búsqueda semántica real: embeddings y búsqueda vectorial, como se ha descrito arriba.
- Un LLM encima de una búsqueda por palabra clave: el sistema hace una búsqueda por palabra clave, obtiene resultados y luego le pide a un LLM que los reformule o los resuma. La búsqueda sigue teniendo los fallos de las palabras clave; el LLM solo los maquilla.
- Preguntas y respuestas con un LLM, sin más: haces una pregunta, el LLM responde con lo que aprendió en su entrenamiento y tu contenido guardado ni se consulta.
Solo la primera resuelve de verdad el desajuste de vocabulario en tus datos. Las otras dos se venden como producto, pero no sirven para encontrar lo que tú guardaste.
Prueba rápida: si buscas el concepto y no encuentras el documento, pero sí lo encuentras al buscar una de sus palabras concretas, la herramienta está haciendo la 2 o la 3 disfrazada de «búsqueda con IA». Si encuentras el documento con una paráfrasis, es la 1.
Bases de datos vectoriales: guardar embeddings y encontrarlos rápido
Los embeddings por sí solos no sirven de mucho si hay que comparar cada búsqueda con millones de vectores uno a uno. Recorrer así un índice de 50.000 documentos lleva cientos de milisegundos, demasiado para un uso interactivo.
La solución es el índice de vecinos más cercanos aproximados (ANN). Estructuras de datos especializadas, como HNSW (Hierarchical Navigable Small World), IVF o ScaNN, organizan los vectores para encontrar los más cercanos en menos de 10 milisegundos incluso en bibliotecas con decenas de millones de vectores.
Lo más avanzado hoy (mayo de 2026) en búsqueda semántica en producción:
- Índices HNSW: son los más usados. Postgres los ofrece con la extensión
pgvector; bases de datos vectoriales independientes como Qdrant, Pinecone y Weaviate usan todas HNSW o variantes muy parecidas. SavedThat usa HNSW sobrepgvectorporque tener los vectores junto a los metadatos relacionales es más sencillo de operar que mantener dos bases de datos. - Almacenamiento en media precisión: con números de 16 bits por dimensión en lugar de 32, los vectores ocupan la mitad de disco. La pérdida de calidad en la búsqueda es insignificante. El tipo
halfvec(768)depgvectores ya la opción por defecto en cualquier instalación que cuide los costes. - Recorte MRL (Matryoshka): los embeddings se entrenan una vez con 1.536 dimensiones y se guardan recortados a 768 o 256 según el caso. Primero se busca en un índice rápido de 256 dimensiones y después se reordenan los 100 mejores resultados con la versión de 768 o 1.536.
Con el volumen de SavedThat, unos 230.000 fragmentos de transcripción en todo el índice a 30 de septiembre de 2026, el índice HNSW cabe de sobra en RAM.
El problema: la búsqueda semántica sola falla con frases exactas
Y ahora lo que la mayoría de los tutoriales no cuentan: con frases exactas, la búsqueda semántica funciona peor que la búsqueda por palabra clave.
Si buscas "text-embedding-3-small" (un nombre de producto exacto), la búsqueda por palabra clave pone en primer lugar el documento que contiene exactamente ese texto. La búsqueda semántica puede colocar por delante un documento que habla de «los embeddings de OpenAI en general», porque está semánticamente más cerca del sentido global de la búsqueda, aunque no contenga el texto literal.
Esto pasa de verdad. Las pruebas públicas muestran una y otra vez que la búsqueda semántica pura rinde peor que la de palabra clave con búsquedas muy concretas: nombres de producto, firmas de funciones, citas exactas, fechas, marcas. El problema que la semántica venía a resolver (el desajuste de vocabulario) no existe en esos casos, porque el usuario escribió justo el texto literal que buscaba.
La solución es hacer las dos búsquedas y combinar los resultados.
Búsqueda híbrida con Reciprocal Rank Fusion
La búsqueda híbrida es la técnica que, sin hacer mucho ruido, se ha convertido desde 2024 en la opción por defecto en los sistemas de búsqueda serios en producción:
- Haz una búsqueda semántica (similitud vectorial). Quédate con los K mejores resultados ordenados por coseno.
- Haz una búsqueda de texto completo (palabra clave, tsvector, BM25, la que sea). Quédate con los K mejores ordenados por puntuación de relevancia.
- Combina las dos listas con reciprocal rank fusion (RRF): la puntuación RRF de cada documento es
1 / (rank + 60), sumada en los dos métodos. Los documentos que salen bien en ambos suben bastante; los que salen solo en uno también cuentan. - Ordena por la puntuación RRF combinada.
La constante 60 es un número casi mágico que se ha probado hasta la saciedad y funciona con la mayoría de los corpus. Se puede ajustar, pero normalmente no hace falta.
El resultado: las búsquedas con paráfrasis siguen encontrando coincidencias por concepto (gracias a la parte semántica), y las búsquedas de frase exacta siguen poniendo la coincidencia literal en primer lugar (gracias a la parte de palabra clave). El punto ciego de cada método lo cubre el otro.
Esta es la búsqueda que SavedThat usa por defecto. La función RPC search_chunks de nuestra base de datos Postgres ejecuta las dos búsquedas en paralelo, calcula las puntuaciones RRF y devuelve los resultados ordenados. De principio a fin, incluida la llamada que convierte tu búsqueda en embedding, una búsqueda tardó una mediana de unos 1,3 segundos en septiembre de 2026. (Microsoft sobre búsqueda híbrida)
Un paso más allá: la reordenación
En casos en los que hay mucho en juego, como el e-discovery en procesos judiciales, la literatura médica o la búsqueda empresarial en millones de documentos, la búsqueda híbrida con RRF suele ser la penúltima capa. La última es reordenar los resultados con un modelo cross-encoder.
Un cross-encoder es un modelo más pequeño y más lento que recibe la búsqueda completa y el documento candidato completo y calcula una puntuación de relevancia más fina analizando los dos a la vez. No se puede aplicar a un millón de documentos (es demasiado lento); se aplica a los 50-200 primeros resultados de la búsqueda híbrida para reordenarlos con precisión.
Cohere ofrece rerank-v3 para esto. Alternativas de código abierto: bge-reranker-large, jina-reranker-v2. En productos de consumo como SavedThat, la mejora marginal no compensa los 100 ms de latencia extra. En la búsqueda empresarial para e-discovery judicial, reordenar con un cross-encoder ya es lo habitual.
Lo añadiremos cuando nuestro corpus o nuestro caso de uso lo exijan. Antes no.
Lo que cuesta
El proceso completo cuesta más o menos esto:
| Etapa | Coste |
|---|---|
| Embeddings de 1.000 fragmentos | ~0,02 $ en créditos de OpenAI |
| Guardar 1M de fragmentos en pgvector | ~25 $/mes en una instancia pequeña de Postgres |
| Crear el índice HNSW para 1M de fragmentos | ~30 segundos, una vez por cada cambio grande de datos |
| Una búsqueda (embedding + consulta HNSW + texto completo + RRF) | ~0,0001 $, unos 1,3 s en total |
Con los precios de SavedThat, una suscripción Pro (9,99 $/mes) cubre miles de búsquedas y varios cientos de guardados nuevos al mes. Las cuentas salen en un producto de consumo; lo que no funciona es intentar pagarlo con un plan gratuito para siempre y sin límites, porque la factura de OpenAI crece en proporción al contenido mientras los ingresos se quedan en cero.
Por qué la mayoría de las herramientas de «segundo cerebro» no lo ofrecen
Tres motivos:
- Complejidad técnica. La búsqueda híbrida con RRF obliga a mantener dos sistemas de búsqueda y combinarlos. La mayoría de los equipos solo implementa uno, y suele ser el de palabra clave, porque es más antiguo y sus herramientas están más maduras.
- Coste de almacenamiento. Embeddings de 1.536 dimensiones × 4 bytes por dimensión = ~6 KB por fragmento. Una biblioteca de 100.000 fragmentos ocupa 600 MB de vectores, además del texto original. Sin
halfvecni MRL, la cifra se duplica. - Inercia. La mayoría de las herramientas de notas que existen se lanzaron antes de que los embeddings de frases fueran algo corriente y barato. Añadir búsqueda semántica a Evernote o Pocket habría exigido un proyecto de base de datos vectorial que la empresa nunca priorizó.
Las herramientas que ofrecen búsqueda semántica desde el primer día (Mem, Reflect, el plan premium de Glasp, SavedThat) nacieron casi todas después de 2022, porque fue entonces cuando el coste de los embeddings bajó lo suficiente como para poner un precio sostenible a un producto de consumo.
Qué significa esto en la práctica
Cuando evalúes en 2026 una herramienta que promete buscar dentro de algo, pregunta:
- ¿Genera embeddings? Si en su arquitectura no hay una base de datos vectorial, la respuesta es no.
- ¿Hace búsqueda híbrida? La semántica pura funciona peor que la híbrida con muchas búsquedas reales. Las herramientas que ofrecen «búsqueda vectorial» pero no búsqueda de texto completo se quedan a medias.
- ¿Es multilingüe? Depende del modelo de embeddings, no de la infraestructura de búsqueda.
text-embedding-3-smallfunciona en más de 100 idiomas; los modelos antiguos o pequeños no. - ¿Explica cómo funciona? Las herramientas que explican su sistema de búsqueda suelen hacerlo bien. Las que dicen «búsqueda con IA ✨» sin más detalle suelen estar haciendo la opción 2 o 3 de antes (un LLM sobre palabra clave, o preguntas y respuestas sin más).
Para guardar videos y encontrarlos después: SavedThat cumple las cuatro (visión general de la arquitectura aquí). Glasp ofrece solo palabra clave (plan gratuito) y semántica (de pago). Mem ofrece semántica sin híbrida. La «búsqueda con IA» de Notion es la opción 2: un LLM sobre palabra clave.
Así está el panorama en mayo de 2026.
Sigue leyendo
Buscar dentro de videos guardados: la guía completa 2026
Busca dentro de videos guardados por lo que se dijo en YouTube, Instagram y TikTok: cómo funciona la búsqueda en transcripciones y cuatro herramientas.
Buscar en transcripciones de vídeo en 2026
Buscar en transcripciones de vídeo en 2026: qué herramientas buscan de verdad en tus vídeos guardados de YouTube, Reels y TikTok.
Marcadores de vídeo con búsqueda en transcripciones (2026)
Gestor de marcadores de vídeo con búsqueda en transcripciones en 2026: siete herramientas comparadas sin rodeos, de SavedThat y Quiki a Raindrop Pro y Mymind.
Preguntas frecuentes (2026)
¿Cuál es la diferencia entre un embedding y un vector?
En la práctica, ninguna: los dos términos se usan como sinónimos. En sentido estricto, un embedding es la *representación* que genera un modelo, y un vector es simplemente una lista de números. Todo embedding es un vector, pero no todo vector es un embedding (una columna de intensidades de píxeles es un vector, pero no un embedding). La mayoría de los artículos científicos y de la documentación técnica usan «vector» al hablar de almacenamiento y «embedding» al hablar del concepto.
¿La búsqueda semántica funciona en cualquier idioma?
Depende del modelo de embeddings. text-embedding-3-small de OpenAI se entrenó en más de 100 idiomas y genera vectores más o menos alineados entre ellos: una búsqueda en ruso y un documento en inglés sobre el mismo concepto quedan en zonas parecidas del espacio vectorial. Los modelos de código abierto más pequeños suelen empeorar bastante fuera del inglés. Si necesitas que sea multilingüe, comprueba que la ficha del modelo mencione expresamente la alineación entre idiomas.
¿En qué se diferencia la búsqueda híbrida de hacer dos búsquedas y mostrar ambas?
Hacer dos búsquedas y juntar los resultados solo te da el doble de resultados. La búsqueda híbrida los combina por puntuación (RRF o fusión ponderada), así que el orden final refleja en qué coinciden los dos métodos. Un documento que sale primero por palabra clave y primero por semántica acaba primero en total; uno que sale primero por palabra clave pero en el puesto 50 por semántica baja hasta la mitad de la lista. Sin combinarlos, no sabes de qué resultados fiarte.
¿Por qué la búsqueda semántica pura funciona peor que la de palabra clave con frases exactas?
Los embeddings representan el significado, no el texto literal. En una búsqueda como «text-embedding-3-small», el significado es más bien «un modelo de la familia de embeddings de OpenAI» que esa secuencia exacta de caracteres. El vector de la búsqueda se parece a los de los documentos que hablan de los embeddings de OpenAI en general, y esos pueden quedar por delante del documento concreto que menciona el nombre exacto del producto. La búsqueda por palabra clave no tiene ninguna ambigüedad con los textos exactos: aparecen o no aparecen. La híbrida cubre los dos casos.
¿RAG es lo mismo que búsqueda semántica?
Están relacionados, pero no son lo mismo. La búsqueda semántica es el paso de recuperación: encontrar los documentos cercanos a una búsqueda en el espacio vectorial. RAG (Retrieval-Augmented Generation, generación aumentada por recuperación) es un sistema que usa la búsqueda semántica para obtener documentos y luego se los pasa a un LLM generativo, que redacta una respuesta usándolos como contexto. RAG incluye la búsqueda semántica como una de sus piezas; puedes tener búsqueda semántica sin RAG (cuando solo quieres encontrar los documentos, no generar texto a partir de ellos).
¿Hace falta una GPU para usar búsqueda semántica?
Para la inferencia, es decir, buscar en un índice ya creado, no. Una CPU basta para buscar en un producto de consumo. Para crear el índice, es decir, pasar tu contenido por el modelo de embeddings, una GPU va rápido pero no es imprescindible. La API de OpenAI calcula los embeddings en su centro de datos y te devuelve el vector para que lo guardes; de tu lado solo quedan la base de datos vectorial y el embedding de la búsqueda (una llamada corta a la API por búsqueda). El coste es de céntimos por cada mil búsquedas.