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.
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.
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 CLos 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.
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.)
Muchas apps de consumo en 2026 anuncian «búsqueda IA». La mayoría se refieren a una de estas tres cosas:
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.
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:
pgvector; las bases de datos vectoriales standalone como Qdrant, Pinecone y Weaviate usan todas HNSW o variantes cercanas. SavedThat corre HNSW sobre pgvector porque mantener los vectores al lado de los metadatos relacionales es operacionalmente más simple que mantener dos bases de datos.halfvec(768) en pgvector es ahora el default para cualquier despliegue consciente del coste.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.
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.
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:
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.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)
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 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 (9,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.
Tres razones:
halfvec y MRL las cuentas son el doble.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.
Cuando evalúes una herramienta de buscar-dentro-de-X en 2026, pregunta:
text-embedding-3-small funciona en 100+ idiomas; los modelos viejos o pequeños no.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.
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.
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.
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.
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.
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).
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.
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, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.