--- term: 'Base de Datos Vectorial & Embeddings' seoTitle: 'Base de Datos Vectorial y Embeddings: HNSW, ANN, Cuándo Usarla' headline: '¿Qué son las Bases de Datos Vectoriales y los Embeddings?' slug: base-de-datos-vectorial category: ai-modern-stack shortDefinition: '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.' relatedTerms: - retrieval-augmented-generation-rag - nosql-vs-sql - database-index - access-control-lists-acl contrastsWith: - nosql-vs-sql aboutTerms: - 'Embeddings' - 'Vector Database' - 'HNSW / ANN' - 'Cosine Similarity' faq: - question: '¿Qué es un embedding en términos simples?' answer: '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.' - question: '¿Qué es una base de datos vectorial?' answer: '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.' - question: '¿Cómo funciona la búsqueda por similitud?' answer: '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.' - question: '¿Cuál es la diferencia entre búsqueda exacta y aproximada?' answer: '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.' - question: '¿Qué es HNSW?' answer: '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.' - question: '¿Necesito una base de datos vectorial dedicada?' answer: '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.' - question: '¿Qué es el filtrado por metadatos y por qué importa?' answer: '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.' - question: '¿Para qué sirve una base de datos vectorial además de RAG?' answer: '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.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'HNSW — Malkov & Yashunin (arXiv:1603.09320)' url: 'https://arxiv.org/abs/1603.09320' - name: 'Efficient Estimation of Word Representations (word2vec, arXiv:1301.3781)' url: 'https://arxiv.org/abs/1301.3781' - name: 'pgvector — open-source vector search for Postgres' url: 'https://github.com/pgvector/pgvector' - name: 'MongoDB Vector Search — overview' url: 'https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/' cta: title: 'Vectores junto a tus datos' text: 'En Back4app, los embeddings son solo campos de array en tus objetos — indexados para similitud, filtrados por las mismas ACLs que protegen todo lo demás, generados en Cloud Code con la clave del modelo en el servidor.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-03' translationKey: vector-database-embeddings --- **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](/glossary/es/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*. ```text 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](https://arxiv.org/abs/1301.3781), *rey − hombre + mujer* cae cerca de *reina*. El significado convertido en coordenadas hace álgebra. ## Cómo funciona la búsqueda por similitud ```mermaid flowchart LR accTitle: De los datos a los embeddings y a la búsqueda por similitud accDescr: Un modelo embebe cada elemento en un vector almacenado en un índice vectorial. Al momento de la consulta, la consulta se embebe con el mismo modelo, y el índice devuelve los vectores más cercanos según una métrica de distancia, opcionalmente filtrados por metadatos como permisos, rankeados por similitud. D["Elementos
(texto, imágenes, audio)"] -->|"embedding"| VS["Vectores en un índice"] Q["Consulta"] -->|"mismo modelo"| QV["Vector de la consulta"] QV --> S{"Más cercanos por
coseno / punto / L2"} VS --> S S -->|"filtro por metadatos / ACL"| K["Top-k resultados
similares"] ``` 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](https://arxiv.org/abs/1603.09320)** — 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](/glossary/es/indice-de-base-de-datos/): 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](https://github.com/pgvector/pgvector), los [índices vectoriales HNSW de MongoDB](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/) 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](/glossary/es/listas-de-control-de-acceso-acl/). 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](/glossary/es/listas-de-control-de-acceso-acl/), el pre-filtrado es la diferencia entre una búsqueda semántica y una brecha — la misma lección que [RAG](/glossary/es/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:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // 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>>( "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](/glossary/es/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](/glossary/es/listas-de-control-de-acceso-acl/) | | 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](/glossary/es/listas-de-control-de-acceso-acl/) 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](/glossary/es/cloud-code-funciones-serverless/) llamando a un modelo de embedding con la [clave guardada en el servidor](/glossary/es/seguridad-de-claves-de-api/); 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.