Un embedding es un vector numérico que captura significado; una base de datos vectorial almacena y busca esos vectores por similitud, no por igualdad. Las dos ideas son una sola capacidad: un modelo convierte texto (o imágenes, o audio) en una lista de números posicionada de modo que los significados parecidos caigan cerca, y una base de datos vectorial encuentra rápido los puntos más próximos. Ese es el truco entero detrás de la búsqueda semántica, las recomendaciones y RAG — y, para quien desarrolla aplicaciones, el titular práctico es que los embeddings son solo un campo que almacenas junto a los datos que describen.
Puntos clave
| Pregunta | Respuesta |
|---|---|
| Embedding | Un vector donde significado parecido → puntos vecinos |
| Base de datos vectorial | Almacena vectores + responde “los más cercanos a este” con índices ANN |
| La métrica | Coseno (lo usual para texto) · producto punto · euclidiana |
| Exacto vs. ANN | Perfecto-pero-lineal vs. ~99% de recall, órdenes de magnitud más rápido |
| ¿Necesitas una dedicada? | En general no hasta ~10M+ de vectores — tu base probablemente ya lo hace |
Embeddings, en concreto
Olvida las 1.536 dimensiones por un momento e imagina tres: un modelo de juguete que puntúa cada palabra en es-animal, es-vehículo, es-pequeño.
animal vehículo pequeño
gatito 0.95 0.02 0.90
gato 0.93 0.01 0.60
camión 0.03 0.96 0.05
moto 0.04 0.94 0.55
"gatito" queda cerca de "gato" (ambos con animal alto) y lejos de "camión".
distancia(gatito, gato) → pequeña → similares
distancia(gatito, camión) → grande → sin relación
Los modelos reales usan cientos o miles de dimensiones en lugar de tres,
aprendidas de los datos en vez de etiquetadas a mano — pero la intuición es exactamente esta:
el significado se vuelve geometría, y "similar" se vuelve "cercano".La demostración famosa de que esto captura estructura real es la aritmética sobre los vectores: en word embeddings entrenados, rey − hombre + mujer cae cerca de reina. El significado convertido en coordenadas hace álgebra.
Cómo funciona la búsqueda por similitud
Tres métricas de distancia dominan: el coseno mide el ángulo entre los vectores (ignorando la longitud), el producto punto incorpora la magnitud y la euclidiana es la distancia en línea recta. El insight que ahorra confusión: para vectores normalizados las tres rankean los resultados de forma idéntica, y como los modelos de embedding de texto típicamente producen vectores normalizados ajustados para coseno, la pregunta “¿qué métrica?” suele venir ya respondida.
Exacto vs. aproximado: el trade-off del ANN
| Exacto (kNN) | Aproximado (ANN) | |
|---|---|---|
| Compara contra | Todos los vectores | Un subconjunto astuto |
| Recall | 100% | ~95–99%, ajustable |
| Velocidad | Lineal — O(n) | Casi logarítmica |
| Suficiente hasta | ~1M de vectores | Decenas de millones+ |
| Costo | CPU por consulta | RAM para el grafo |
La búsqueda exacta compara la consulta contra cada vector almacenado — perfecta, y perfectamente adecuada hasta alrededor de un millón de vectores. Más allá, HNSW — el índice aproximado dominante — construye un grafo de proximidad por capas (capas superiores dispersas para saltos largos, una capa inferior densa con todo) y desciende con avidez de lo grueso a lo fino, saltándose la mayoría de las comparaciones. Es un primo semántico del B-tree: donde un B-tree indexa “igual a” y “menor que”, un índice ANN indexa “similar a”. La salvedad honesta que los competidores suavizan: el ANN puede perder al vecino más cercano verdadero, sus parámetros cambian recall por velocidad y memoria, y el grafo vive en RAM — por eso dimensionar una base vectorial es, en la práctica, una conversación sobre memoria.
Índice vectorial vs. base de datos vectorial
Una distinción que la sopa de términos esconde: una librería de índice en memoria (como FAISS) calcula vecinos más cercanos, pero no persiste, no actualiza y no filtra — reindexa en cada reinicio, y no existe cláusula WHERE. Una base de datos vectorial envuelve el índice con durabilidad, actualizaciones incrementales y filtrado por metadatos. Esa brecha es exactamente la razón por la que “usa solo una librería” falla en producción y por la que tu base de datos actual con un índice vectorial suele ser la respuesta correcta — ya tiene la durabilidad, las transacciones y los permisos que a la librería le faltan.
¿Realmente necesitas una base de datos vectorial dedicada?
La respuesta neutral que las páginas de proveedores no pueden dar. Una base de datos de uso general con soporte vectorial — Postgres vía pgvector, los índices vectoriales HNSW de MongoDB sobre campos de array — atiende con comodidad hasta cerca de un millón de vectores por nodo, justo al lado de los datos de tu aplicación y sus permisos. Un motor dedicado paga su costo operativo y su impuesto de sincronización de doble sistema (mantener el almacén vectorial consistente con la base fuente-de-verdad) a escala genuinamente grande: decenas de millones de vectores, tasas de consulta muy altas o recall alto exigido bajo filtrado pesado. Por debajo de más o menos un millón de vectores, un almacén especializado suele costar más en código pegamento de lo que devuelve en rendimiento — la aritmética que la mayoría de las páginas “necesitas una base vectorial” estructuralmente no puede hacer, porque ellas son la base vectorial.
El filtrado por metadatos es la frontera de seguridad
La similitud vectorial rankea por significado y no sabe nada sobre quién puede leer qué — así que la consulta de producción nunca es “los diez vecinos más cercanos”, sino “los diez vecinos más cercanos que este usuario puede ver”. Equivoca el orden y no es un bug de relevancia, es una fuga de datos: el pre-filtrado reduce los candidatos al conjunto permitido antes de la búsqueda ANN (correcto); el post-filtrado recorta después, filtrando la existencia de los elementos prohibidos y devolviendo silenciosamente menos que k. Cuando el filtro son las ACLs, el pre-filtrado es la diferencia entre una búsqueda semántica y una brecha — la misma lección que RAG aprende por las malas. Almacenar los embeddings en la base que ya aplica tus permisos es la forma en que el filtro sale gratis.
Embeddings en código real
// JavaScript — Cloud Code (cloud/main.js)
// Embeddings live as a field next to the data they describe
Parse.Cloud.beforeSave('Doc', async (req) => {
if (req.object.dirty('text')) {
// generate server-side; embedding API key stays on the server
req.object.set('embedding', await embed(req.object.get('text')));
req.object.set('embedModel', 'text-embed-v3'); // version it — models differ
}
});
// Similarity search, ACL-filtered: "nearest neighbors this user MAY see"
Parse.Cloud.define('semanticSearch', async (req) => {
const qVec = await embed(req.params.q);
return vectorSearch('Doc', qVec, { limit: 10, aclUser: req.user });
// The pre-filter is the security boundary, not a relevance tweak.
});// Flutter / Dart — Back4app Flutter SDK
// The client searches by meaning — the vector math is server-side
final results = await ParseCloudFunction('semanticSearch')
.execute(parameters: {'q': 'how do refunds work?'});
for (final doc in results.result) print(doc['title']);
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.// iOS / Swift — Back4app Swift SDK
// The client searches by meaning — the vector math is server-side
let results: [[String: Any]] = try await Cloud.run(
name: "semanticSearch",
parameters: ["q": "how do refunds work?"])
for doc in results { print(doc["title"] ?? "") }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.// Android / Kotlin — Back4app Android SDK
// The client searches by meaning — the vector math is server-side
val params = mapOf("q" to "how do refunds work?")
val results = ParseCloud.callFunction<List<Map<String, Any>>>(
"semanticSearch", params)
results.forEach { println(it["title"]) }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.Fíjate en el campo embedModel: los vectores de modelos distintos — o de versiones distintas del mismo modelo — no son comparables, así que cambiar de modelo de embedding significa re-embeber el corpus entero. Guarda el nombre del modelo junto a los vectores, o un upgrade silencioso convierte tu índice en ruido.
Casos de uso comunes
- Búsqueda semántica — “quiero mi dinero de vuelta” encuentra “política de reembolsos” aunque no compartan ninguna palabra.
- Recuperación para RAG — traer los chunks que fundamentan la respuesta de un LLM.
- Recomendaciones — elementos cercanos al historial del usuario en el espacio de embeddings.
- Deduplicación y clustering — contenido casi idéntico como vectores casi idénticos.
- Detección de anomalías y fraude — los outliers son vectores lejos de todos los ejemplos normales.
¿Dónde deberían vivir tus vectores? Matriz de decisión
| Situación | Elige |
|---|---|
| Corpus a escala de aplicación (< ~1M de vectores) | El índice vectorial de tu base — junto a los datos |
| Los vectores deben respetar permisos de usuario | Donde ya están las ACLs |
| Decenas de millones de vectores, QPS alto | Un motor vectorial dedicado |
| Importan los términos exactos y el significado | Búsqueda híbrida con fusión de rankings |
| Un prototipo rápido | pgvector o un almacén embebido — no sobreconstruyas |
| Un solo proceso, sin persistencia | Una librería de índice (FAISS) — aceptando sus límites |
Limitaciones y trade-offs
- Los embeddings codifican la visión del mundo del modelo. Sesgos, puntos ciegos y el corte de entrenamiento vienen incluidos; la geometría es solo tan buena como el modelo que la dibujó.
- ANN es aproximado a propósito. Ajusta el recall a lo que está en juego; “generalmente encuentra el mejor resultado” es el trato que firmaste a cambio de la velocidad.
- La versión del modelo es un esquema. Re-embeber un corpus grande al cambiar de modelo es una migración de verdad, no un flag de configuración.
- La memoria es el techo. Los grafos HNSW viven en RAM; los límites de vectores por nodo son límites de memoria con otra etiqueta.
- Similitud no es relevancia. Estar cerca en el espacio vectorial es una señal fuerte, no una garantía — la búsqueda híbrida y el re-ranking existen porque la búsqueda vectorial pura falla con los términos exactos.
Vectores en Back4app
Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Como corre sobre MongoDB, la historia de almacenamiento es la que este artículo recomienda: un embedding es un campo de array en el objeto que describe — el documento y su vector en el mismo registro — con la indexación vectorial HNSW como el mecanismo real por debajo. Las consecuencias se encadenan limpiamente: las ACLs que ya gobiernan cada consulta se convierten en el pre-filtro de la búsqueda por similitud gratis, así que la recuperación no puede cruzar una frontera de permisos; los embeddings se generan en un trigger beforeSave de Cloud Code llamando a un modelo de embedding con la clave guardada en el servidor; y no hay un servicio vectorial aparte que sincronizar, asegurar y pagar. Para los corpus a escala de aplicación que la mayoría de los productos realmente tiene, “base de datos vectorial” no es un sistema que adoptas — es un campo que agregas.
Preguntas frecuentes
¿Qué es un embedding en términos simples?
Una lista de números que un modelo le asigna a un dato — texto, una imagen, audio — de forma que las cosas con significado parecido reciban números parecidos. Dos documentos sobre el mismo tema terminan como puntos vecinos en un espacio de alta dimensión, y eso es lo que le permite a una computadora medir qué tan "similares" son.
¿Qué es una base de datos vectorial?
Un sistema que almacena embeddings y responde rápido "qué elementos almacenados son más similares a este", usando índices de vecinos más cercanos aproximados (ANN) en vez de búsquedas por coincidencia exacta. La parte de "base de datos" — durabilidad, actualizaciones, filtrado por metadatos — es lo que la separa de una simple librería de índice en memoria.
¿Cómo funciona la búsqueda por similitud?
La consulta se embebe con el mismo modelo y se compara con los vectores almacenados mediante una métrica de distancia: coseno (solo el ángulo), producto punto (ángulo y magnitud) o euclidiana (distancia en línea recta). Para vectores normalizados las tres rankean los resultados de forma idéntica, y los modelos de embedding de texto suelen estar ajustados para coseno.
¿Cuál es la diferencia entre búsqueda exacta y aproximada?
La exacta (kNN) compara la consulta contra cada vector — recall perfecto, pero tiempo lineal, viable hasta alrededor de un millón de vectores. La aproximada (ANN, usualmente HNSW) se salta la mayoría de las comparaciones y logra velocidad casi logarítmica, cambiando unos puntos porcentuales de recall por consultas órdenes de magnitud más rápidas. Perder el vecino más cercano verdadero de vez en cuando suele ser aceptable.
¿Qué es HNSW?
Hierarchical Navigable Small World — el índice ANN dominante en producción. Construye un grafo de proximidad de múltiples capas: las capas superiores, dispersas, dan atajos de largo alcance; la capa inferior, densa, contiene todos los vectores; y la búsqueda desciende con avidez de lo grueso a lo fino. Sus parámetros cambian recall por velocidad y memoria, y el grafo vive en RAM.
¿Necesito una base de datos vectorial dedicada?
A escala de aplicación, generalmente no. Una base de datos de uso general con soporte de índice vectorial — Postgres con pgvector, la búsqueda vectorial de MongoDB — maneja con comodidad hasta cerca de un millón de vectores por nodo, junto a tus datos y permisos. Los motores dedicados se pagan con decenas de millones de vectores, tasas de consulta muy altas o recall alto bajo filtrado pesado.
¿Qué es el filtrado por metadatos y por qué importa?
Restringir la búsqueda por similitud mediante campos — tenant, categoría, fecha, permisos. El pre-filtrado limita los candidatos antes de la búsqueda ANN; el post-filtrado recorta después y puede devolver silenciosamente menos resultados de los que pediste. Las consultas de producción casi siempre van filtradas, y cuando el filtro son los permisos, es una frontera de seguridad.
¿Para qué sirve una base de datos vectorial además de RAG?
Búsqueda semántica, recomendaciones, detección de casi-duplicados y detección de anomalías o fraude (los outliers son vectores lejos de todo lo demás), además de similitud de imagen y audio y clustering. RAG es el uso famoso; la búsqueda por similitud es la capacidad general que hay debajo.