Cómo funciona la búsqueda semántica (y por qué la búsqueda por palabra clave falla)
Cómo funciona la búsqueda semántica en 2026 — embeddings, vectores y retrieval híbrido explicados en cristiano. Por qué la búsqueda por palabra clave no encuentra tus marcadores, y qué lo arregla.
Escribe «cuánto cuesta adquirir clientes» en la búsqueda de marcadores guardados y mira cómo no matchea nada. El video que buscas está ahí en tu biblioteca — lo guardaste. El ponente dijo «CAC» dieciséis veces. Tu consulta dijo «coste de adquisición de clientes». Las palabras no se solapan. El match falla.
Este modo de fallo tiene nombre: el problema del desajuste de vocabulario. Es la razón por la que la búsqueda por palabra clave sigue perdiendo, y es la razón por la que la búsqueda semántica es ahora el default en cualquier herramienta seria que busque algo con forma de texto. Abajo: cómo funciona realmente la búsqueda semántica en 2026 — en cristiano, sin necesidad de título en matemáticas — y por qué la mayoría de las apps de consumo que lanzan «búsqueda IA» todavía se equivocan.
El problema del desajuste de vocabulario en 60 segundos
Los sistemas de búsqueda viejos matcheaban strings literales. Escribías coste de adquisición de cliente, el sistema encontraba documentos que contenían esas palabras exactas. Los documentos que decían «CAC» o «cuánto pagamos por traer compradores nuevos» o «lo que pagamos por signup» se quedaban invisibles.
En investigación de recuperación de información esto se mide desde hace cuarenta años. El desajuste de vocabulario típico está alrededor del 70-80%: la gente usa palabras distintas para el mismo concepto la mayoría del tiempo. Si tu búsqueda solo matchea strings literales, te pierdes cuatro de cada cinco documentos relevantes. Es una forma educada de decir «la búsqueda por palabra clave está rota desde 1985».
Dos cosas lo arreglaron. La primera son los embeddings: una forma de representar el significado como números, para que dos frases que significan lo mismo acaben «cerca» aunque no compartan palabras. La segunda son las bases de datos vectoriales: almacenamiento e índices que pueden encontrar los vectores más cercanos rápido, incluso cuando el corpus son millones de documentos.
Juntos, son los que hacen que «búsqueda semántica» exista como categoría.
Qué es un embedding, claramente
Coge una frase. Pásala por una red neuronal. La red devuelve una lista de números — típicamente 384, 768 o 1.536 de ellos. Esa lista es el embedding de la frase.
El truco es que la red está entrenada para que frases con significados parecidos produzcan listas parecidas. El ejemplo literal:
"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 donde viven. C estará lejos. La cercanía se mide por similitud coseno — cuán alineados están los dos vectores en ese espacio de alta dimensión. Números cerca de 1.0 significan significado casi idéntico; cerca de 0, no relacionados.
Puedes imaginártelo como dibujar cada frase como un punto en una galaxia de 1.536 dimensiones donde la dirección codifica significado. Las coordenadas reales no significan nada por sí solas — lo que importa es qué otras frases aterrizan cerca de cuáles.
El modelo que hace esto
Varios modelos están a la par en 2026. text-embedding-3-small de OpenAI entrega 1.536 dimensiones de forma nativa y soporta Matryoshka representation (puedes truncar a 768 o 256 dimensiones para ahorrar almacenamiento sin reentrenar). El embed-v3 de Cohere compite en contenido multilingüe. Las alternativas open-source como bge-large y nomic-embed-text están a unos pocos puntos de precisión y corren en un Mac.
Para cargas multilingües — como videos guardados en 30 idiomas con consultas en cualquiera de ellos — text-embedding-3-small es ahora mismo el mejor equilibrio entre precisión, coste y dimensiones. En SavedThat usamos la truncación Matryoshka de 768 dimensiones: la mitad del almacenamiento, ~99% de la calidad de búsqueda. (Más sobre Matryoshka representation.)
Por qué «usar IA y ya» no es lo mismo que búsqueda semántica
Muchas apps de consumo en 2026 anuncian «búsqueda IA». La mayoría se refieren a una de estas tres cosas:
- Búsqueda semántica real — embeddings + retrieval vectorial, como se ha descrito arriba.
- LLM por encima de búsqueda por palabra clave — el sistema corre una búsqueda por palabra clave, obtiene resultados, luego le pide a un LLM que los reformule o resuma. El retrieval sigue roto de palabra clave; el LLM solo pinta los fallos.
- Q&A puro de LLM — haces una pregunta, el LLM responde desde su entrenamiento general, tu contenido guardado no se consulta para nada.
Solo el primero resuelve de verdad el desajuste de vocabulario sobre tus datos. Los otros dos están productizados pero no son útiles para encontrar lo que tú guardaste.
Diagnóstico rápido: si puedes buscar el concepto y no encontrar el documento, pero sí lo encuentras buscando una de sus palabras específicas, la herramienta está haciendo #2 o #3 envuelto como «búsqueda IA». Si encuentras el documento vía paráfrasis, es #1.
Bases de datos vectoriales: almacenar y encontrar embeddings rápido
Los embeddings por sí solos no ayudan si tienes que comparar cada consulta contra millones de vectores uno por uno. La búsqueda completa de un índice de 50.000 documentos tarda cientos de milisegundos hecha de forma ingenua — demasiado lenta para uso interactivo.
El arreglo es el indexado de vecinos más cercanos aproximado (ANN). Estructuras de datos especializadas — HNSW (Hierarchical Navigable Small World), IVF, ScaNN — almacenan vectores para que los matches más cercanos puedan encontrarse en menos de 10 milisegundos incluso en bibliotecas con decenas de millones de vectores.
El estado del arte actual (mayo de 2026) para búsqueda semántica en producción:
- Indexado HNSW es el más desplegado. Postgres lo tiene vía la extensión
pgvector; las bases de datos vectoriales standalone como Qdrant, Pinecone y Weaviate usan todas HNSW o variantes cercanas. SavedThat corre HNSW sobrepgvectorporque mantener los vectores al lado de los metadatos relacionales es operacionalmente más simple que mantener dos bases de datos. - Almacenamiento en half-precision. Con floats de 16 bits por dimensión en lugar de 32, los vectores ocupan la mitad del disco. La pérdida de calidad es despreciable para retrieval. El tipo
halfvec(768)enpgvectores ahora el default para cualquier despliegue consciente del coste. - Truncación MRL (Matryoshka). Embeddings entrenados una vez a 1.536 dimensiones se truncan en almacenamiento a 768 o 256 dimensiones según el caso de uso. Buscas en un índice rápido de 256-dim primero, re-rankeas el top 100 contra la versión de 768 o 1.536 dim.
A escala de SavedThat (actualmente ~120 videos guardados × ~50 chunks cada uno = 6.000 vectores), el índice cabe en RAM y los lookups son sub-milisegundo.
El truco: la búsqueda semántica sola se equivoca con frases exactas
Ahora el remate que la mayoría de los tutoriales se saltan: la búsqueda semántica pierde frente a la búsqueda por palabra clave en frases exactas.
Si buscas "text-embedding-3-small" (un nombre de producto exacto), la búsqueda por palabra clave devuelve el documento que menciona ese string exacto en el puesto 1. La búsqueda semántica puede rankear más alto un documento que habla de «embeddings de OpenAI en general» porque está semánticamente más cerca del significado promedio de la consulta, aunque falte el string literal.
Esto es real. Los benchmarks públicos muestran de manera consistente que la semántica pura rinde peor que la palabra clave para consultas con alta especificidad: nombres de producto, firmas de función, citas exactas, fechas, nombres de marca. La cosa que la semántica iba a arreglar (el desajuste de vocabulario) no existe para esas consultas porque el usuario tecleó el string literal que quería.
El arreglo es correr ambas y fusionar los resultados.
Retrieval híbrido con Reciprocal Rank Fusion
El retrieval híbrido es la técnica que se ha convertido silenciosamente en el default en los sistemas de búsqueda en producción serios desde 2024:
- Corre una búsqueda semántica (similitud vectorial). Saca los top-K resultados rankeados por coseno.
- Corre una búsqueda por texto completo (palabra clave, tsvector, BM25, lo que sea). Saca los top-K rankeados por score de relevancia.
- Fusiona las dos listas usando reciprocal rank fusion (RRF): el score RRF de cada documento es
1 / (rank + 60), sumado a través de ambos métodos. Los documentos que aparecen bien en los dos reciben un boost significativo; los que aparecen solo en uno todavía contribuyen. - Ordena por score RRF combinado.
La constante 60 es un número mágico que se ha benchmarkeado hasta la saciedad y funciona en la mayoría de los corpus. Puedes ajustarla; normalmente no hace falta.
El resultado: las consultas parafraseadas siguen encontrando matches por concepto (vía el lado semántico), y las consultas de frase exacta siguen rankeando el match literal en el puesto 1 (vía el lado de palabra clave). El punto ciego de cada método lo cubre el otro.
Esto es lo que SavedThat lanza como búsqueda por defecto. El RPC search_chunks en nuestra Postgres corre ambas consultas en paralelo, computa los scores RRF y devuelve hits rankeados en ~80ms para nuestro tamaño actual de corpus. (Microsoft sobre búsqueda híbrida)
Donde esto se pone fancy: re-ranking
Para casos de uso de alto valor — e-discovery legal, literatura médica, búsqueda enterprise sobre millones de documentos — el RRF híbrido suele ser la penúltima capa. La última es re-ranking con un modelo cross-encoder.
Un cross-encoder es un modelo más pequeño y más lento que toma la consulta completa y el documento candidato completo y computa un score de relevancia ajustado prestando atención conjuntamente a ambos. No puedes correrlo sobre un millón de documentos (demasiado lento); lo corres sobre los top 50-200 resultados del retrieval híbrido para reordenarlos con precisión.
Cohere lanza rerank-v3 para esto. Alternativas open-source: bge-reranker-large, jina-reranker-v2. Para cargas a escala de consumo como SavedThat, la ganancia marginal no justifica el hit de 100ms de latencia. Para búsqueda enterprise de e-discovery legal, el re-ranking con cross-encoder es ahora estándar.
Lo añadiremos cuando nuestro corpus o nuestro caso de uso lo exija. Antes no.
El cuadro de costes
El pipeline completo es aproximadamente:
| Etapa | Coste |
|---|---|
| Embeddings de 1.000 chunks (~50 videos) | ~0,02 $ en créditos de OpenAI |
| Almacenar 1M de chunks en pgvector | ~25 $/mes en una instancia pequeña de Postgres |
| Build de índice HNSW para 1M de chunks | ~30 segundos, una sola vez por cambio mayor de datos |
| Una consulta (embed + lookup HNSW + FTS + RRF) | ~0,0001 $ + 80ms |
Con el pricing de SavedThat, una suscripción Pro (6,99 $/mes) cubre miles de búsquedas y varios cientos de nuevos guardados al mes. La economía cuadra a escala de consumo; lo que no funciona es intentar financiar esto con un plan gratis-para-siempre-ilimitado porque la factura de OpenAI crece linealmente con el contenido mientras los ingresos topan en cero.
Por qué la mayoría de las herramientas de «segundo cerebro» no lanzan esto
Tres razones:
- Complejidad de ingeniería. El retrieval híbrido con RRF requiere correr dos sistemas de recuperación y fusionarlos. La mayoría de los equipos lanzan uno. Ese uno suele ser palabra clave porque es más antiguo y el stack es maduro.
- Coste de almacenamiento. Embeddings a 1.536 dimensiones × 4 bytes/dim = ~6KB por chunk. Una biblioteca de 100.000 chunks son 600MB de almacenamiento vectorial encima del texto original. Sin
halfvecy MRL las cuentas son el doble. - Inercia. La mayoría de las herramientas de notas existentes se lanzaron antes de que los embeddings de frase fueran commodity. Retrofittear búsqueda semántica en Evernote o Pocket habría requerido un proyecto de base de datos vectorial que la org nunca priorizó.
Las herramientas que lanzan búsqueda semántica desde el día uno — Mem, Reflect, el tier premium de Glasp, SavedThat — son mayoritariamente builds post-2022 porque es cuando el coste de los embeddings bajó del umbral en el que la escala de consumo se podía precificar de forma sostenible.
Qué significa esto en la práctica
Cuando evalúes una herramienta de buscar-dentro-de-X en 2026, pregunta:
- ¿Embebe? Si el diagrama de arquitectura no incluye un vector store, la respuesta es no.
- ¿Corre retrieval híbrido? La semántica pura es peor que la híbrida para muchas consultas reales. Las herramientas que lanzan «búsqueda vectorial» pero no búsqueda por texto completo lo están haciendo a medias.
- ¿Soporta multilingüe? Es función del modelo de embeddings, no de la infraestructura de búsqueda.
text-embedding-3-smallfunciona en 100+ idiomas; los modelos viejos o pequeños no. - ¿Expone la matemática para nada? Las herramientas que explican su retrieval suelen hacerlo bien. Las que dicen «búsqueda con IA ✨» sin especificar suelen estar haciendo el ítem 2 o 3 de antes (LLM sobre palabra clave, o Q&A puro).
Para guardar videos y encontrarlos luego: SavedThat lanza las cuatro (visión general de la arquitectura aquí). Glasp lanza solo palabra clave (plan gratuito) y semántica (de pago). Mem lanza semántica sin híbrida. La «búsqueda IA» de Notion es ítem 2 — LLM sobre palabra clave.
Ese es el panorama en mayo de 2026.
Keep reading
Search inside saved videos: the complete 2026 guide
Search inside saved videos by what was actually said — across YouTube, Instagram, and TikTok. How transcript search works in 2026, and four tools that do it.
The 7 best video transcript search tools in 2026
The 7 best video transcript search tools in 2026, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
Best AI video bookmark manager in 2026: 4 tools compared
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.
Frequently asked questions (2026)
¿Cuál es la diferencia entre un embedding y un vector?
Funcionalmente ninguna — en la práctica los términos se usan indistintamente. Estrictamente, un embedding es la *representación* que produce un modelo, y un vector es solo una lista de números. Todo embedding es un vector; 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 papers y la documentación de ingeniería usan «vector» como término de almacenamiento y «embedding» como término conceptual.
¿La búsqueda semántica funciona en cualquier idioma?
Depende del modelo de embedding. text-embedding-3-small de OpenAI se entrenó en 100+ idiomas y produce vectores que están aproximadamente alineados entre ellos — una consulta en ruso y un documento en inglés sobre el mismo concepto aterrizan en regiones similares del espacio vectorial. Los modelos open-source más pequeños suelen degradarse significativamente en no-inglés. Si lo multilingüe es requisito, verifica que la model card mencione explícitamente alineamiento cross-lingual.
¿En qué se diferencia la búsqueda híbrida de correr dos búsquedas y mostrar las dos?
Correr dos búsquedas y concatenar los resultados solo te da el doble de resultados. La búsqueda híbrida los fusiona por score (RRF o fusión ponderada), así que el ranking final refleja el acuerdo entre los dos métodos. Un documento en el puesto 1 en palabra clave y en el puesto 1 en semántica acaba en el puesto 1 global; un documento en el puesto 1 en palabra clave pero en el puesto 50 en semántica cae a la mitad. Sin fusionar, no sabes en qué resultados confiar.
¿Por qué la búsqueda semántica pura pierde frente a la palabra clave para frases exactas?
Los embeddings codifican significado semántico, no strings literales. Una consulta como 'text-embedding-3-small' tiene su significado en 'miembro de la familia de embeddings de OpenAI' más que en la secuencia literal de tokens. El vector de la consulta es similar a los vectores de documentos que hablan de los embeddings de OpenAI en general, que pueden rankear más alto que el documento específico que menciona el nombre exacto del producto. La búsqueda por palabra clave tiene cero ambigüedad sobre strings exactos — aparecen o no. La híbrida cubre ambos modos.
¿RAG es lo mismo que búsqueda semántica?
Relacionados pero no lo mismo. La búsqueda semántica es el paso de retrieval — encontrar documentos cercanos a una consulta en el espacio vectorial. RAG (Retrieval-Augmented Generation) es un sistema que usa búsqueda semántica para obtener documentos y luego los pasa a un LLM generativo que escribe una respuesta usando los documentos como contexto. RAG incluye búsqueda semántica como uno de sus componentes; puedes tener búsqueda semántica sin RAG (cuando solo quieres encontrar los documentos, no generar texto encima).
¿Necesito GPU para correr búsqueda semántica?
Para inferencia — buscar contra un índice ya construido — no. CPU está bien para retrieval a escala de consumo. Para construir el índice — correr el modelo de embedding sobre tu contenido — una GPU es rápida pero no requerida. La API de OpenAI hace los embeddings en su datacentro, devolviéndote el vector para que lo almacenes; lo único de tu lado es la base de datos vectorial y el embedding de la consulta (una llamada corta a la API por consulta). El coste son céntimos por mil búsquedas.