pgvector en detalle
pgvector es una extensión de Postgres que enseña a la base de datos un nuevo tipo de dato y una nueva forma de clasificar filas: por distancia geométrica en lugar de igualdad o rango.
Esta página se mantiene conceptual y no repite la sintaxis de tipos, el DDL de índices o los patrones de esquemas que ya se cubren en las otras páginas de esta sección.
Resumen
- pgvector representa los embeddings como puntos en un espacio de alta dimensionalidad y permite que SQL clasifique las filas por la distancia geométrica entre esos puntos.
- Por qué es Importante: La búsqueda semántica, la recuperación RAG y los sistemas de recomendación se reducen a "encontrar las filas cuyo vector esté más cerca de este", y pgvector responde a esa pregunta sin salir de Postgres.
- Conceptos Clave: embedding, métrica de distancia, vecino más cercano aproximado (ANN), recall, clase de operador, planificador de consultas.
- Cuándo Usar: Utiliza este modelo mental al elegir una métrica de distancia, al razonar sobre por qué un índice devuelve resultados "suficientemente buenos" en lugar de exactos, o al explicar a un compañero por qué pgvector no es una caché externa.
- Limitaciones / Compensaciones: La geometría es solo un proxy del significado, y ese proxy solo es tan bueno como el modelo de embedding que produjo los vectores.
- Temas Relacionados: tipo de dato
vectory operadores, indexación IVFFlat y HNSW, diseño de esquemas de almacenamiento RAG, escalado de pgvector.
Fundamentos
Un embedding es una lista de números producida por un modelo de aprendizaje automático, y esa lista está pensada para ser leída como las coordenadas de un punto en un espacio de alta dimensionalidad.
Dos fragmentos de texto, imágenes o clips de audio que significan cosas similares se entrenan para aterrizar cerca unos de otros en ese espacio, mientras que el contenido no relacionado aterriza lejos.
pgvector almacena cada embedding como un valor vector, y trata ese valor de la misma manera que Postgres trata un entero o una marca de tiempo: una columna tipada con operadores definidos.
La idea central detrás de la búsqueda vectorial es que "significado similar" se convierte en "distancia pequeña", lo que convierte una pregunta semántica en una pregunta de geometría que SQL puede responder con ORDER BY y LIMIT.
La distancia en sí no es una idea fija, ya que existen varias formas matemáticamente válidas de medir cuán separados están dos puntos.
La distancia Euclidiana (L2) mide la distancia en línea recta a través del espacio, de la misma manera que una regla mediría la distancia entre dos puntos en un papel.
La distancia del coseno ignora la longitud de cada vector y mide solo el ángulo entre ellos, lo que importa cuando los embeddings de un modelo varían en magnitud pero no en dirección.
El producto interior mide una mezcla de ángulo y magnitud a la vez, y es el ajuste natural para modelos entrenados explícitamente para maximizar una puntuación de producto escalar.
Ninguna de estas métricas es universalmente "correcta", ya que la elección adecuada depende de cómo se entrenó y normalizó el modelo de embedding.
Una analogía simple ayuda aquí: imagina cada documento como una ciudad en un mapa, donde las ciudades que discuten temas similares se agrupan en barrios.
Encontrar "los documentos más relevantes" se convierte en "las ciudades más cercanas", y el mapa en sí lo define el modelo de embedding, no pgvector.
pgvector no crea ese mapa, solo le da a Postgres las herramientas para medirlo y buscarlo eficientemente.
Mecánica e Interacciones
A pequeña escala, la búsqueda de similitud es un problema de geometría de fuerza bruta: calcula la distancia del vector de consulta a cada vector almacenado, luego ordena y toma los mejores resultados.
Ese enfoque es exacto, pero su coste crece linealmente con el número de filas, por lo que deja de ser rápido una vez que una tabla alcanza decenas de miles de vectores.
La indexación de vecino más cercano aproximado (ANN) existe para romper esa relación lineal organizando los vectores de antemano para que una consulta solo tenga que mirar un subconjunto pequeño y prometedor.
La compensación que se está haciendo es explícita: un índice ANN renuncia a la garantía de encontrar los vecinos más cercanos exactos a cambio de encontrar vecinos que probablemente estén lo suficientemente cerca, a una fracción del coste.
Esto es fundamentalmente diferente de un índice B-tree, que nunca sacrifica la corrección por la velocidad.
Recall (recuperación) es el término para cuántas veces un índice ANN realmente devuelve los verdaderos vecinos más cercanos en comparación con un escaneo exacto de fuerza bruta, y es un dial ajustable en lugar de una garantía fija.
Girar ese dial hacia un mayor recall generalmente cuesta más latencia de consulta y más tiempo de construcción, y girarlo hacia un menor recall recupera velocidad.
Lo que hace que pgvector sea interesante arquitectónicamente es que no añade la búsqueda ANN a Postgres como un servicio separado.
Registra el tipo vector y sus operadores de distancia a través del mismo sistema de clases de operadores en el que todos los métodos de índice de Postgres ya se basan para saber cómo comparar valores.
Debido a eso, un índice ANN sobre vectores es un índice de primera clase de Postgres, no una estructura externa que la base de datos simplemente tolera.
El planificador de consultas trata un escaneo de índice vectorial de la misma manera que trata un escaneo B-tree o GiST al estimar el coste y decidir si usar el índice o no.
-- Las clases de operadores son cómo Postgres sabe que un operador de distancia puede impulsar un escaneo de índice
SELECT opcname, amname
FROM pg_opclass oc
JOIN pg_am am ON am.oid = oc.opcmethod
WHERE opcname LIKE 'vector%';Es por eso que cambiar el operador de distancia de la consulta sin que coincida con la clase de operador del índice derrota silenciosamente el índice: el planificador ya no puede probar que el orden del índice coincide con el orden solicitado por la consulta.
Consideraciones Avanzadas y Aplicaciones
Los espacios de alta dimensionalidad se comportan de manera contraintuitiva, y esto se manifiesta como la "maldición de la dimensionalidad", donde los puntos tienden a volverse aproximadamente equidistantes entre sí a medida que aumenta el número de dimensiones.
Ese efecto es una de las razones por las que los índices ANN aceptan la aproximación: en dimensiones muy altas, encontrar el vecino más cercano matemáticamente exacto a menudo no es significativamente mejor que encontrar uno muy cercano.
Combinar la búsqueda vectorial con filtros tradicionales, como "documentos similares propiedad de este inquilino", es más difícil de lo que parece, ya que un índice ANN está optimizado para el ordenamiento por distancia, no para la selectividad arbitraria de predicados.
Filtrar antes o después del escaneo ANN puede cambiar el recall de maneras que son fáciles de pasar por alto durante las pruebas en conjuntos de datos pequeños.
La búsqueda híbrida, que combina la relevancia de palabras clave y vectorial, existe precisamente porque la similitud vectorial pura a veces devuelve resultados que están geométricamente cerca pero pragmáticamente incorrectos.
La deriva de embeddings es un riesgo de producción que no tiene nada que ver con la mecánica de pgvector y todo que ver con el modelo que generó los vectores y que cambia con el tiempo.
Si el modelo de embedding se actualiza, los vectores antiguos y nuevos ya no tienen garantizado vivir en un espacio comparable, y mezclarlos corrompe silenciosamente los rankings de distancia.
La observabilidad para una función de búsqueda vectorial debe rastrear el recall contra un conjunto de consultas etiquetado a lo largo del tiempo, no solo la latencia de consulta, porque la latencia por sí sola no puede revelar un índice que se degrada silenciosamente.
Las representaciones cuantificadas, como los vectores de media precisión, son parte de cómo el ecosistema gestiona el coste de almacenamiento y memoria de los índices ANN a medida que crecen los corpus.
La lección arquitectónica más amplia es que pgvector tiene éxito extendiendo los puntos de extensibilidad existentes de Postgres en lugar de reinventarlos, que es también por lo que hereda las garantías transaccionales de Postgres de forma gratuita.
| Estrategia de Búsqueda | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Escaneo exacto de fuerza bruta | Siempre correcto, cero mantenimiento de índice | El coste escala linealmente con el número de filas | Tablas pequeñas o análisis puntuales |
| Índice de vecino más cercano aproximado (ANN) | Coste de consulta sub-lineal a escala | El recall es probabilístico, no garantizado | Búsqueda semántica en producción a escala significativa |
| Híbrido palabra clave + vectorial | Captura coincidencias de términos exactos que ANN puede pasar por alto | Más partes móviles para ajustar y monitorizar | Búsqueda orientada al usuario donde la precisión en nombres o códigos importa |
Conceptos Erróneos Comunes
- "pgvector convierte a Postgres en una base de datos vectorial dedicada" - la realidad es que pgvector añade un tipo y métodos de índice a Postgres ordinario, por lo que cada fila vectorial todavía vive dentro de transacciones, copias de seguridad y uniones normales.
- "La distancia del coseno y la Euclidiana siempre clasifican los resultados de la misma manera" - la realidad es que solo coinciden cuando los vectores se normalizan a la misma longitud, y los rankings discrepantes son una fuente común de informes de errores confusos.
- "Un índice ANN siempre encuentra los verdaderos vecinos más cercanos" - la realidad es que los índices ANN son aproximados por diseño, y "aproximado" es la razón por la que son rápidos.
- "Más dimensiones de embedding siempre mejoran la calidad de la búsqueda" - la realidad es que una dimensionalidad muy alta puede hacer que los puntos sean menos distinguibles entre sí, lo que es la maldición de la dimensionalidad en la práctica.
- "La similitud vectorial equivale a la corrección semántica" - la realidad es que la similitud solo refleja lo que el modelo de embedding aprendió a codificar, y puede pasar por alto el significado para el que el modelo nunca fue entrenado.
- "Cualquier operador de distancia funciona con cualquier índice vectorial" - la realidad es que el operador de distancia de la consulta debe coincidir con la clase de operador del índice o el planificador no podrá usar el índice en absoluto.
Preguntas Frecuentes
¿Qué problema resuelve realmente pgvector?
Permite a Postgres clasificar filas por cercanía geométrica entre vectores de embedding, que es la operación de la que dependen la búsqueda semántica, la recuperación RAG y las recomendaciones.
¿Es un vector "cercano" lo mismo que "similar en significado"?
Solo en la medida en que el modelo de embedding codificó ese significado como geometría, por lo que la distancia es un proxy de la similitud, no una garantía de ella.
¿Por qué L2, coseno y producto interior a veces clasifican los mismos vectores de forma diferente?
- Cada métrica mide una propiedad geométrica diferente: distancia en línea recta, ángulo o una mezcla de ángulo y magnitud.
- Los vectores con la misma dirección pero diferente longitud pueden parecer idénticos bajo la distancia del coseno y muy diferentes bajo L2.
¿Por qué Postgres no puede simplemente hacer fuerza bruta en cada consulta de similitud?
El coste de comparación de fuerza bruta crece linealmente con el número de filas, por lo que se vuelve demasiado lento una vez que una tabla contiene más de aproximadamente decenas de miles de vectores.
¿Qué significa realmente "aproximado" en la búsqueda de vecino más cercano aproximado?
Significa que se permite que el índice falle ocasionalmente en encontrar las filas más cercanas verdaderas a cambio de responder mucho más rápido que un escaneo exacto.
¿Cómo encaja pgvector en el framework de índices de Postgres en lugar de ser una característica añadida?
Registra sus operadores de distancia a través del mismo sistema de clases de operadores que utilizan todos los métodos de acceso a índices de Postgres, por lo que el planificador de consultas puede razonar sobre los escaneos de índices vectoriales exactamente como los escaneos B-tree o GiST.
¿Sabe el planificador de consultas cuándo usar un índice vectorial?
Sí, estima el coste de la misma manera que lo hace para cualquier otro tipo de índice y elige entre un escaneo secuencial y un escaneo de índice en consecuencia.
¿Qué es el recall y por qué es más importante que la velocidad de consulta bruta?
El recall mide cuántas veces un índice ANN devuelve los verdaderos vecinos más cercanos en comparación con un escaneo exacto, y un índice rápido que silenciosamente devuelve coincidencias pobres es peor que uno ligeramente más lento que no lo hace.
¿Cuándo debería un equipo evitar por completo la indexación ANN?
- Cuando la tabla es lo suficientemente pequeña como para que un escaneo exacto ya sea rápido.
- Cuando la aplicación no puede tolerar ninguna aproximación en sus resultados clasificados.
¿Por qué la actualización del modelo de embedding pone en riesgo los vectores existentes?
Las diferentes versiones del modelo generalmente producen vectores en espacios incomparables, por lo que mezclar embeddings antiguos y nuevos puede corromper silenciosamente los rankings de distancia.
¿Por qué es más difícil combinar la búsqueda vectorial con filtros que una cláusula WHERE normal?
Los índices ANN están construidos para optimizar el ordenamiento por distancia, no la selectividad arbitraria de predicados, por lo que el filtrado interactúa con el recall de maneras que son fáciles de pasar por alto.
¿Qué se debe monitorizar en producción además de la latencia de consulta?
El recall contra un conjunto de consultas fijo y etiquetado debe rastrearse a lo largo del tiempo, ya que la latencia por sí sola no puede revelar un índice cuya calidad de resultados se está degradando silenciosamente.
Relacionados
- Conceptos Básicos de pgvector - el tipo
vector, los operadores de distancia y los límites de dimensiones que esta página asume. - Índices IVFFlat vs HNSW - los pasos concretos de construcción y ajuste de índices detrás de la compensación ANN descrita aquí.
- Esquema de Almacenamiento RAG - cómo organizar las tablas de fragmentos y metadatos alrededor de una columna vectorial.
- pgvector a Escala - memoria, construcción paralela e interacciones de vacuum una vez que la teoría de recall se encuentra con el volumen de producción.
- Conceptos Básicos de Extensiones - cómo funciona realmente el sistema de extensiones al que se integra pgvector.
Versiones de Stack: Esta página fue escrita para pgvector 0.8+. Por lo demás, es conceptual y no está ligada a una versión menor específica de PostgreSQL.