Los vectores son el nuevo JSON de PostgreSQL

xguru · 2023-06-28T11:05:01+09:00

Los vectores son una estructura matemática bien estudiada, y JSON es un formato de intercambio de datos Pero en el mundo del almacenamiento y la recuperación de datos, ambas formas de representación se han convertido en un lenguaje común, y pronto serán elementos esenciales en el desarrollo de aplicaciones modernas Si la tendencia actual continúa, los vectores también llegarán a ser tan importantes como JSON a la hora de construir aplicaciones PostgreSQL se ha convertido naturalmente en la opción elegida para almacenar y consultar los resultados de la IA generativa Pero esto no es un patrón de datos nuevo. Los vectores, como concepto matemático, existen desde hace cientos de años Los arreglos, la estructura de datos básica de los vectores, se enseñan en la mayoría de los cursos introductorios de informática. PostgreSQL también ha soportado operaciones con vectores durante más de 20 años Entonces, ¿qué es lo nuevo? Es la "accesibilidad" de estos algoritmos de IA/ML y qué tan "fácilmente posible" es representar algunas estructuras del "mundo real" (texto, imágenes, video) como vectores y luego usarlas en aplicaciones Además, aunque almacenar la salida ("embeddings") de estos sistemas en un data store tampoco puede considerarse algo nuevo, el nuevo patrón es la "accesibilidad" para consultar y devolver estos datos casi en tiempo real desde prácticamente cualquier aplicación Entonces, ¿qué relación tiene esto con PostgreSQL? Un patrón común para almacenar y consultar tipos de datos de forma eficiente ha simplificado enormemente el desarrollo de aplicaciones, y ha permitido que la gente almacene los datos en el mismo lugar y trabaje con ellos usando herramientas existentes Vimos esto con JSON hace 10 años, y ahora estamos viendo el mismo patrón con los datos vectoriales Una breve historia de JSON en PostgreSQL (consulta el artículo original) El auge de los vectores: "un nuevo tipo de JSON" Su popularidad se ha disparado últimamente Un caso de uso común es construir modelos a partir de datos almacenados, convertirlos a formato vectorial y luego usarlos para "búsqueda semántica" En este caso, una nueva entrada de búsqueda se convierte a formato vectorial y luego se busca en la base de datos aquello que sea más similar La similitud se mide usando funciones de distancia como la distancia euclidiana o coseno, y los resultados suelen limitarse a k-NN (Nearest Neighbors) o a los k objetos más similares Como puede tomar mucho tiempo codificar el conjunto de entrenamiento de vectores, conviene almacenarlo en caché en algún lugar como la base de datos y ejecutar ahí las consultas k-NN Tener un conjunto de vectores listos para consultar para búsqueda semántica suele ofrecer una mejor experiencia al usuario, por lo que ha surgido la necesidad de una "base de datos vectorial" El almacenamiento de vectores no es algo nuevo para PostgreSQL De hecho, el nombre es algo engañoso porque PostgreSQL puede almacenar datos multidimensionales (por ejemplo, una matrix) De forma predeterminada, los arreglos de PostgreSQL incluyen soporte limitado para vectores, como calcular la "distancia" entre dos arreglos Se pueden escribir stored procedures, pero eso requiere un poco más de trabajo por parte del desarrollador Afortunadamente, el tipo de dato cube supera estas limitaciones cube se ha usado durante más de 20 años y fue diseñado para realizar operaciones sobre vectores de alta dimensión cube incluye la mayoría de las funciones de distancia comunes usadas en búsqueda de similitud vectorial, incluida la distancia euclidiana También permite realizar consultas K-NN eficientes usando índices GiST Pero cube solo puede almacenar vectores de hasta 100 dimensiones, y los sistemas modernos de IA/ML requieren dimensiones mayores pgvector: una extensión open source para almacenar y consultar vectores en PostgreSQL Con pgvector puedes almacenar vectores y ejecutar consultas k-NN con varias métricas de distancia (euclidiana, coseno, producto interno, etc.) Actualmente, pvector incluye un índice llamado ivfflat, que implementa el método IVR FLAT de indexación vectorial Consultar datos vectoriales indexados puede ser distinto a consultar datos normales Debido al costo de buscar los vecinos más cercanos en vectores de alta dimensión, muchos métodos de indexación vectorial encuentran una respuesta "aproximada" que está "lo suficientemente cerca" de la correcta Esto ha dado lugar al campo de búsqueda "ANN (Approximate Nearest Neighbor)" Las dos dimensiones que la gente suele observar en las consultas ANN son el equilibrio entre rendimiento y "recall" (el porcentaje de resultados relevantes que se devuelven) Tomando ivfflat como ejemplo, al crear un índice ivfflat se decide cuántas listas incluirá Cada lista representa un "centro", y ese centro se calcula con el algoritmo k-means Una vez determinados todos los centros, ivfflat decide cuál es el centro más cercano para cada vector y lo agrega al índice Cuando llega el momento de consultar los datos vectoriales, según la variable ivfflat.probes se determina cuántos centros deben revisarse Aquí puede verse el trade-off de rendimiento/recall en ANN. Cuantos más centros se visitan, más precisos son los resultados, pero el rendimiento disminuye Próximos pasos para dar mejor soporte a vectores en PostgreSQL Igual que con el soporte oficial del tipo JSON en PostgreSQL 9.2, estamos en una etapa temprana de cómo almacenar datos vectoriales en PostgreSQL PostgreSQL y pgvector ya son buenos, pero van a mejorar mucho más pgvector ya puede manejar casos de uso comunes de datos para IA/ML. Muchos usuarios ya lo han desplegado y lo están usando El siguiente paso es ayudar a mejorar y ampliar esto, y la mayor parte ya está en marcha Agregar más paralelización Soporte para vectores con más de 2,000 dimensiones Aprovechar aceleración por hardware para aumentar la velocidad de cálculo Hay muchas expectativas sobre usar PostgreSQL como "base de datos" vectorial Como puede verse en la historia de JSON, la comunidad de PostgreSQL encontrará la forma de dar soporte a esto de manera extensible y segura

(jkatz05.com)

26 puntos por xguru 2023-06-28 | 7 comentarios | Compartir por WhatsApp

Los vectores son una estructura matemática bien estudiada, y JSON es un formato de intercambio de datos
Pero en el mundo del almacenamiento y la recuperación de datos, ambas formas de representación se han convertido en un lenguaje común, y pronto serán elementos esenciales en el desarrollo de aplicaciones modernas
Si la tendencia actual continúa, los vectores también llegarán a ser tan importantes como JSON a la hora de construir aplicaciones
PostgreSQL se ha convertido naturalmente en la opción elegida para almacenar y consultar los resultados de la IA generativa
Pero esto no es un patrón de datos nuevo. Los vectores, como concepto matemático, existen desde hace cientos de años
Los arreglos, la estructura de datos básica de los vectores, se enseñan en la mayoría de los cursos introductorios de informática. PostgreSQL también ha soportado operaciones con vectores durante más de 20 años
Entonces, ¿qué es lo nuevo? Es la "accesibilidad" de estos algoritmos de IA/ML y qué tan "fácilmente posible" es representar algunas estructuras del "mundo real" (texto, imágenes, video) como vectores y luego usarlas en aplicaciones
Además, aunque almacenar la salida ("embeddings") de estos sistemas en un data store tampoco puede considerarse algo nuevo, el nuevo patrón es la "accesibilidad" para consultar y devolver estos datos casi en tiempo real desde prácticamente cualquier aplicación
Entonces, ¿qué relación tiene esto con PostgreSQL?
- Un patrón común para almacenar y consultar tipos de datos de forma eficiente ha simplificado enormemente el desarrollo de aplicaciones, y ha permitido que la gente almacene los datos en el mismo lugar y trabaje con ellos usando herramientas existentes
- Vimos esto con JSON hace 10 años, y ahora estamos viendo el mismo patrón con los datos vectoriales

Una breve historia de JSON en PostgreSQL

(consulta el artículo original)

El auge de los vectores: "un nuevo tipo de JSON"

Su popularidad se ha disparado últimamente
Un caso de uso común es construir modelos a partir de datos almacenados, convertirlos a formato vectorial y luego usarlos para "búsqueda semántica"
- En este caso, una nueva entrada de búsqueda se convierte a formato vectorial y luego se busca en la base de datos aquello que sea más similar
- La similitud se mide usando funciones de distancia como la distancia euclidiana o coseno, y los resultados suelen limitarse a k-NN (Nearest Neighbors) o a los k objetos más similares
- Como puede tomar mucho tiempo codificar el conjunto de entrenamiento de vectores, conviene almacenarlo en caché en algún lugar como la base de datos y ejecutar ahí las consultas k-NN
- Tener un conjunto de vectores listos para consultar para búsqueda semántica suele ofrecer una mejor experiencia al usuario, por lo que ha surgido la necesidad de una "base de datos vectorial"
El almacenamiento de vectores no es algo nuevo para PostgreSQL
- De hecho, el nombre es algo engañoso porque PostgreSQL puede almacenar datos multidimensionales (por ejemplo, una matrix)
- De forma predeterminada, los arreglos de PostgreSQL incluyen soporte limitado para vectores, como calcular la "distancia" entre dos arreglos
- Se pueden escribir stored procedures, pero eso requiere un poco más de trabajo por parte del desarrollador
Afortunadamente, el tipo de dato cube supera estas limitaciones
- cube se ha usado durante más de 20 años y fue diseñado para realizar operaciones sobre vectores de alta dimensión
- cube incluye la mayoría de las funciones de distancia comunes usadas en búsqueda de similitud vectorial, incluida la distancia euclidiana
- También permite realizar consultas K-NN eficientes usando índices GiST
- Pero cube solo puede almacenar vectores de hasta 100 dimensiones, y los sistemas modernos de IA/ML requieren dimensiones mayores

pgvector: una extensión open source para almacenar y consultar vectores en PostgreSQL

Con pgvector puedes almacenar vectores y ejecutar consultas k-NN con varias métricas de distancia (euclidiana, coseno, producto interno, etc.)
Actualmente, pvector incluye un índice llamado ivfflat, que implementa el método IVR FLAT de indexación vectorial
Consultar datos vectoriales indexados puede ser distinto a consultar datos normales
Debido al costo de buscar los vecinos más cercanos en vectores de alta dimensión, muchos métodos de indexación vectorial encuentran una respuesta "aproximada" que está "lo suficientemente cerca" de la correcta
Esto ha dado lugar al campo de búsqueda "ANN (Approximate Nearest Neighbor)"
Las dos dimensiones que la gente suele observar en las consultas ANN son el equilibrio entre rendimiento y "recall" (el porcentaje de resultados relevantes que se devuelven)
- Tomando ivfflat como ejemplo, al crear un índice ivfflat se decide cuántas listas incluirá
- Cada lista representa un "centro", y ese centro se calcula con el algoritmo k-means
- Una vez determinados todos los centros, ivfflat decide cuál es el centro más cercano para cada vector y lo agrega al índice
- Cuando llega el momento de consultar los datos vectoriales, según la variable ivfflat.probes se determina cuántos centros deben revisarse
- Aquí puede verse el trade-off de rendimiento/recall en ANN. Cuantos más centros se visitan, más precisos son los resultados, pero el rendimiento disminuye

Próximos pasos para dar mejor soporte a vectores en PostgreSQL

Igual que con el soporte oficial del tipo JSON en PostgreSQL 9.2, estamos en una etapa temprana de cómo almacenar datos vectoriales en PostgreSQL
PostgreSQL y pgvector ya son buenos, pero van a mejorar mucho más
pgvector ya puede manejar casos de uso comunes de datos para IA/ML. Muchos usuarios ya lo han desplegado y lo están usando
El siguiente paso es ayudar a mejorar y ampliar esto, y la mayor parte ya está en marcha
- Agregar más paralelización
- Soporte para vectores con más de 2,000 dimensiones
- Aprovechar aceleración por hardware para aumentar la velocidad de cálculo
Hay muchas expectativas sobre usar PostgreSQL como "base de datos" vectorial
Como puede verse en la historia de JSON, la comunidad de PostgreSQL encontrará la forma de dar soporte a esto de manera extensible y segura

7 comentarios

atempest 2025-05-07

Puede que sea muy versátil, pero al final la clave no será la velocidad? Creo que, comparado con las vector DB puras, va a ser desesperadamente lento....

nicewook 2023-06-28

Me pregunto por qué habría expectativas sobre PostgreSQL cuando ya existen bases de datos vectoriales como Pinecone. @@

tkwlsrl 2023-06-28

En mi experiencia, PostgreSQL fue lo más accesible.

Cuando usaba cosas como Pinecone, ChromaDB o Weaviate, no había una forma estandarizada de usar cada base de datos.

Es decir, había que usar SDK distintos para cada base de datos, y como también se usaban de manera diferente, había que volver a escribir el código para cada una. Además, los lenguajes compatibles con los SDK oficiales eran limitados, así que a veces incluso había que cambiar de lenguaje.

Claro, al intentar usar vectores en PostgreSQL pasa algo parecido, pero al menos es fácil empezar porque solo hace falta agregar un poco de conocimiento sobre la sintaxis SQL que ya existe.

Por ahora, cuando comparas la velocidad de las bases de datos vectoriales, PostgreSQL es bastante lento. Ojalá lo mejoren pronto jaja.

xguru 2023-06-28

Probablemente sea algo como: "es más cómodo instalar y administrar solo una base de datos que ya soporte todo" + "es fácil integrarla con otras funciones".
Cuando aumentan las instancias, poco a poco se vuelve más tedioso..

nicewook 2023-06-28

Ajá, ya entendí.
Con razón Redis le va agregando de todo. asiente

iolothebard 2023-06-28

La historia siempre termina en... tensores...