Vector é o novo JSON do PostgreSQL

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

Vetores são estruturas matemáticas bem estudadas, enquanto JSON é um formato de intercâmbio de dados Mas, no mundo de armazenamento e consulta de dados, essas duas formas de representação de dados se tornaram uma linguagem comum e em breve serão elementos essenciais no desenvolvimento de aplicações modernas Se a tendência atual continuar, vetores também se tornarão tão importantes quanto JSON na construção de aplicações O PostgreSQL acabou sendo a escolha natural para armazenar e consultar os resultados da IA generativa Mas isso não é um novo padrão de dados. Vetores, como conceito matemático, existem há centenas de anos Arrays, a estrutura de dados básica dos vetores, são ensinados na maioria dos cursos introdutórios de ciência da computação. O PostgreSQL também oferece suporte a operações com vetores há mais de 20 anos Então, o que há de novo? É a "acessibilidade" desses algoritmos de IA/ML e o quão "fácil" ficou representar algumas estruturas do "mundo real" (texto, imagem, vídeo) como vetores e depois usá-las em aplicações Além disso, embora armazenar em um data store as saídas desses sistemas ("embeddings") também não seja exatamente novo, o novo padrão é a "acessibilidade" para consultar e retornar esses dados em quase tempo real em praticamente qualquer aplicação Então, o que isso tem a ver com PostgreSQL? Um padrão comum para armazenar e consultar tipos de dados de forma eficiente simplificou bastante o desenvolvimento de apps e permitiu que as pessoas armazenassem dados no mesmo lugar e trabalhassem com eles usando as ferramentas existentes Vimos isso com JSON há 10 anos, e agora estamos vendo esse padrão com dados vetoriais Uma breve história do JSON no PostgreSQL (Consulte o texto original) A ascensão dos vetores, "um novo tipo de JSON" Hoje eles estão ganhando popularidade rapidamente Um caso de uso comum é construir um modelo sobre dados armazenados, convertê-los para o formato vetorial e depois usá-los em "busca semântica" Nesse caso, uma nova entrada de busca é convertida para o formato vetorial e então o banco de dados procura os itens mais semelhantes A similaridade é medida com funções de distância, como distância euclidiana ou cosseno, e os resultados geralmente são limitados a k-NN (Nearest Neighbors) ou aos k itens mais similares Como pode levar muito tempo para codificar o conjunto de treino dos vetores, é melhor armazená-lo em cache em algum lugar como o banco de dados e executar as consultas k-NN ali mesmo Ter um conjunto de vetores pronto para consulta para busca semântica costuma oferecer uma experiência melhor ao usuário, o que levou à necessidade de um "banco de dados vetorial" Armazenamento de vetores não é novidade no PostgreSQL Na verdade, isso é até um nome inadequado, porque o PostgreSQL consegue armazenar dados multidimensionais (por exemplo, matrizes) Por padrão, os arrays do PostgreSQL já incluem suporte limitado para vetores, como cálculo de "distância" entre dois arrays É possível escrever stored procedures, mas isso exige um pouco mais de trabalho do desenvolvedor Felizmente, o tipo de dado cube supera essas limitações cube é usado há mais de 20 anos e foi projetado para permitir operações com vetores de alta dimensionalidade cube inclui a maioria das funções de distância mais comuns usadas em buscas por similaridade vetorial, incluindo distância euclidiana Também é possível executar consultas K-NN eficientes usando índices GiST Mas cube só consegue armazenar vetores de até 100 dimensões, enquanto sistemas modernos de IA/ML exigem mais do que isso pgvector: uma extensão open source para armazenar e consultar vetores no PostgreSQL Com pgvector, é possível armazenar vetores e executar consultas k-NN com várias métricas de distância (euclidiana, cosseno, produto interno etc.) Atualmente, pvector vem com um índice, ivfflat, que implementa o método IVR FLAT de indexação vetorial Consultar dados vetoriais indexados pode ser diferente de consultar dados comuns Devido ao custo de buscar os vizinhos mais próximos em vetores de alta dimensionalidade, muitos métodos de indexação vetorial encontram respostas "aproximadas" que são "boas o suficiente" Isso levou ao campo de busca "ANN (Approximate Nearest Neighbor)" As duas dimensões que as pessoas costumam observar nas consultas ANN são o equilíbrio entre desempenho e "recall" (a porcentagem de resultados relevantes retornados) Usando ivfflat como exemplo, ao criar um índice ivfflat, decide-se quantas listas ele vai conter Cada lista representa um "centro", e esse centro é calculado com o algoritmo k-means Depois que todos os centros são determinados, o ivfflat decide qual é o centro mais próximo de cada vetor e o adiciona ao índice Na hora de consultar os dados vetoriais, a variável ivfflat.probes determina quantos centros devem ser verificados É aqui que aparece o trade-off entre desempenho e recall em ANN. Quanto mais centros são visitados, mais preciso é o resultado, mas o desempenho cai Próximos passos para dar melhor suporte a vetores no PostgreSQL Assim como na época do PostgreSQL 9.2, quando o tipo JSON passou a ter suporte oficial, ainda estamos nos estágios iniciais de como armazenar dados vetoriais no PostgreSQL PostgreSQL e pgvector já são bons, mas vão ficar muito melhores pgvector já consegue lidar com casos de uso comuns de dados de IA/ML. Muitos usuários já o colocaram em produção O próximo passo é ajudar a melhorar e expandir isso, e boa parte desse trabalho já está em andamento Adicionar mais paralelismo Suporte a vetores com mais de 2 mil dimensões Uso de aceleração por hardware para aumentar a velocidade de cálculo Há muita expectativa em torno do uso do PostgreSQL como "banco de dados vetorial" Como mostra a história do JSON, a comunidade PostgreSQL encontrará uma forma de oferecer esse suporte de maneira extensível e segura

(jkatz05.com)

26 pontos por xguru 2023-06-28 | 7 comentários | Compartilhar no WhatsApp

Vetores são estruturas matemáticas bem estudadas, enquanto JSON é um formato de intercâmbio de dados
Mas, no mundo de armazenamento e consulta de dados, essas duas formas de representação de dados se tornaram uma linguagem comum e em breve serão elementos essenciais no desenvolvimento de aplicações modernas
Se a tendência atual continuar, vetores também se tornarão tão importantes quanto JSON na construção de aplicações
O PostgreSQL acabou sendo a escolha natural para armazenar e consultar os resultados da IA generativa
Mas isso não é um novo padrão de dados. Vetores, como conceito matemático, existem há centenas de anos
Arrays, a estrutura de dados básica dos vetores, são ensinados na maioria dos cursos introdutórios de ciência da computação. O PostgreSQL também oferece suporte a operações com vetores há mais de 20 anos
Então, o que há de novo? É a "acessibilidade" desses algoritmos de IA/ML e o quão "fácil" ficou representar algumas estruturas do "mundo real" (texto, imagem, vídeo) como vetores e depois usá-las em aplicações
Além disso, embora armazenar em um data store as saídas desses sistemas ("embeddings") também não seja exatamente novo, o novo padrão é a "acessibilidade" para consultar e retornar esses dados em quase tempo real em praticamente qualquer aplicação
Então, o que isso tem a ver com PostgreSQL?
- Um padrão comum para armazenar e consultar tipos de dados de forma eficiente simplificou bastante o desenvolvimento de apps e permitiu que as pessoas armazenassem dados no mesmo lugar e trabalhassem com eles usando as ferramentas existentes
- Vimos isso com JSON há 10 anos, e agora estamos vendo esse padrão com dados vetoriais

Uma breve história do JSON no PostgreSQL

(Consulte o texto original)

A ascensão dos vetores, "um novo tipo de JSON"

Hoje eles estão ganhando popularidade rapidamente
Um caso de uso comum é construir um modelo sobre dados armazenados, convertê-los para o formato vetorial e depois usá-los em "busca semântica"
- Nesse caso, uma nova entrada de busca é convertida para o formato vetorial e então o banco de dados procura os itens mais semelhantes
- A similaridade é medida com funções de distância, como distância euclidiana ou cosseno, e os resultados geralmente são limitados a k-NN (Nearest Neighbors) ou aos k itens mais similares
- Como pode levar muito tempo para codificar o conjunto de treino dos vetores, é melhor armazená-lo em cache em algum lugar como o banco de dados e executar as consultas k-NN ali mesmo
- Ter um conjunto de vetores pronto para consulta para busca semântica costuma oferecer uma experiência melhor ao usuário, o que levou à necessidade de um "banco de dados vetorial"
Publicidade
Armazenamento de vetores não é novidade no PostgreSQL
- Na verdade, isso é até um nome inadequado, porque o PostgreSQL consegue armazenar dados multidimensionais (por exemplo, matrizes)
- Por padrão, os arrays do PostgreSQL já incluem suporte limitado para vetores, como cálculo de "distância" entre dois arrays
- É possível escrever stored procedures, mas isso exige um pouco mais de trabalho do desenvolvedor
Felizmente, o tipo de dado cube supera essas limitações
- cube é usado há mais de 20 anos e foi projetado para permitir operações com vetores de alta dimensionalidade
- cube inclui a maioria das funções de distância mais comuns usadas em buscas por similaridade vetorial, incluindo distância euclidiana
- Também é possível executar consultas K-NN eficientes usando índices GiST
- Mas cube só consegue armazenar vetores de até 100 dimensões, enquanto sistemas modernos de IA/ML exigem mais do que isso

pgvector: uma extensão open source para armazenar e consultar vetores no PostgreSQL

Com pgvector, é possível armazenar vetores e executar consultas k-NN com várias métricas de distância (euclidiana, cosseno, produto interno etc.)
Atualmente, pvector vem com um índice, ivfflat, que implementa o método IVR FLAT de indexação vetorial
Consultar dados vetoriais indexados pode ser diferente de consultar dados comuns
Devido ao custo de buscar os vizinhos mais próximos em vetores de alta dimensionalidade, muitos métodos de indexação vetorial encontram respostas "aproximadas" que são "boas o suficiente"
Isso levou ao campo de busca "ANN (Approximate Nearest Neighbor)"
As duas dimensões que as pessoas costumam observar nas consultas ANN são o equilíbrio entre desempenho e "recall" (a porcentagem de resultados relevantes retornados)
- Usando ivfflat como exemplo, ao criar um índice ivfflat, decide-se quantas listas ele vai conter
- Cada lista representa um "centro", e esse centro é calculado com o algoritmo k-means
- Depois que todos os centros são determinados, o ivfflat decide qual é o centro mais próximo de cada vetor e o adiciona ao índice
- Na hora de consultar os dados vetoriais, a variável ivfflat.probes determina quantos centros devem ser verificados
- É aqui que aparece o trade-off entre desempenho e recall em ANN. Quanto mais centros são visitados, mais preciso é o resultado, mas o desempenho cai

Próximos passos para dar melhor suporte a vetores no PostgreSQL

Assim como na época do PostgreSQL 9.2, quando o tipo JSON passou a ter suporte oficial, ainda estamos nos estágios iniciais de como armazenar dados vetoriais no PostgreSQL
PostgreSQL e pgvector já são bons, mas vão ficar muito melhores
pgvector já consegue lidar com casos de uso comuns de dados de IA/ML. Muitos usuários já o colocaram em produção
O próximo passo é ajudar a melhorar e expandir isso, e boa parte desse trabalho já está em andamento
- Adicionar mais paralelismo
- Suporte a vetores com mais de 2 mil dimensões
- Uso de aceleração por hardware para aumentar a velocidade de cálculo
Há muita expectativa em torno do uso do PostgreSQL como "banco de dados vetorial"
Como mostra a história do JSON, a comunidade PostgreSQL encontrará uma forma de oferecer esse suporte de maneira extensível e segura

7 comentários

atempest 2025-05-07

A versatilidade pode até ser alta, mas no fim das contas acho que a questão é a velocidade.
Comparado aos bancos de dados vetoriais puros, parece que vai ser lento a ponto de ficar difícil de engolir....

nicewook 2023-06-28

Eu me pergunto por que há expectativa em relação ao PostgreSQL, considerando que já existem bancos de dados vetoriais como o Pinecone. @@

tkwlsrl 2023-06-28

Pela minha experiência, o PostgreSQL foi o mais acessível.

Quando eu usava coisas como Pinecone, ChromaDB ou Weaviate, não havia uma padronização que permitisse usar cada banco de dados da mesma forma.

Ou seja, era preciso usar SDKs diferentes para cada banco de dados, e como o modo de uso também era diferente, era necessário reescrever o código para cada um deles. Além disso, havia poucos idiomas suportados pelos SDKs oficiais, então às vezes eu até precisava mudar de linguagem.

Claro que, ao tentar usar vetores no PostgreSQL, a situação é parecida em certa medida, mas pelo menos basta acrescentar um pouco de conhecimento à sintaxe SQL que já existe, então a barreira de entrada era menor.

No momento, comparando a velocidade dos bancos de dados vetoriais, o PostgreSQL está entre os mais lentos. Tomara que melhore logo haha.

xguru 2023-06-28

Talvez seja algo como: "é prático instalar/administrar só um único banco de dados que já oferece suporte a tudo" + "é fácil integrar com outros recursos".
Conforme o número de instâncias aumenta, isso vai ficando cada vez mais incômodo..

nicewook 2023-06-28

Ah, entendi.
Então é por isso que o Redis vai adicionando todo tipo de coisa. Faz sentido.

iolothebard 2023-06-28

Começo, meio e fim... tensor...