6 min.
Vetores
Na sua essência, as soluções atuais de IA Generativa possuem um desafio central: Encontrar dados similares sob diversas óticas. Para responder uma requisição de um usuário, um Large Language Model, como o ChatGPT, precisa buscar palavras que tenham uma certa relação com o que o usuário realmente pediu. As soluções de RAG (Retrieval Augmented Generation), que aparentemente vem sendo a principal alternativa para a criação de soluções generativas proprietárias dentro das organizações, precisam buscar conteúdos relevantes que possam enriquecer as requisições dos usuários com informações que permitam ao modelo criar uma resposta satisfatória.
Mas como eu falei, isso é um certo desafio. Se pensarmos em dados na forma de texto, por exemplo, como é possível comparar duas palavras e dizer que elas são relacionadas? Olhando unicamente para as palavras, isso é um pouco difícil, visto que há outras variáveis que devem ser consideradas para cumprir esse objetivo: Gramática, semântica, contexto, metáforas, ironias, sinônimos. Tudo isso deve ser considerado.
Mas então, como criar uma forma de representar os dados, onde todos esses elementos estão inseridos, e aí sim poder compará-los propriamente? A resposta está nos Vetores, e explorá-los é a ideia central desse artigo.
Números e Dimensões
Os Vetores basicamente consistem em uma forma numérica de representação dos dados em um espaço de alta dimensionalidade. Vamos quebrar isso em partes.
- Os Vetores são Numéricos: Ao transformar dados em Vetores, cada registro, independente do seu formato e tipos de colunas, são transformados em um monte de números.
- Os Vetores possuem Alta Dimensionalidade: Cada vetor, que corresponde a um registro de um conjunto de dados, é composto por vários números, onde cada um deles representa uma dimensão.
Vetores são um monte de números
Imagine um ponto no meio de um espaço tridimensional. Agora imagine aumentar absurdamente a quantidade de dimensões para um número grande, como 300 dimensões. Conseguiu enxergar? Nem eu, afinal é impossível para nós. Mas apesar de ser algo meio abstrato, é isso que os vetores propõem fazer com os dados: Convertê-los em pontos organizados em um espaço que vai além do tridimensional.
Um ponto perdido no espaço
Mas qual a vantagem disso? Perceba que estamos perdendo o poder de visualizar os dados de uma maneira clara convertendo-os em vetores. Para o que vale esse sacrifício?
O principal motivo é atender justamente o problema levantado no começo: O processo de converter os dados em vetores, comumente chamado de vetorização, é feito de forma que cada dimensão gerada representa várias informações relevantes sobre os dados. E quando se fala em texto, por exemplo, temos dimensões que podem representar informações gramaticais, outras informações semânticas, informações de gêneros, contextos, sinônimos, e em alguns casos, até pontuações e letras maiúsculas e minúsculas.
E ao conseguir trazer todas essas informações para os dados, se alcança um outro importante objetivo, que marca uma das principais utilidades dos vetores: Vetores que representam dados semelhantes são posicionados próximos uns aos outros no espaço dimensional. E o contrário também é verdade, com vetores pouco relacionados se localizando distantes uns dos outros.
Fonte: Xomnia.
Com isso, o problema de comparar dados, como palavras, se torna um problema simples de calcular distâncias entre pontos. Não só é mais simples, mas nos permite representar a similaridade entre dados através de um número, eliminando o fator subjetivo nessa análise: O menor número indica dados mais próximos e não resta dúvida disso.
Voltando para o problema apresentado lá no começo desse artigo, onde as soluções de RAG precisam procurar dados semelhantes ao conteúdo da consulta de um usuário e criar um prompt mais efetivo para um modelo de linguagem, parece que encontramos nos vetores uma solução. Mas falar em Big Data está na moda, então não basta só ter um monte de vetores, precisamos otimizá-los para grandes quantidades de dados.
Vector Databases
E ai entram os Vector Databases, e o nome já entrega tudo: são soluções que trazem boa parte das vantagens e garantias dos bancos de dados tradicionais para o armazenamento de vetores. Coisas como as listadas abaixo estão incluídas no pacote:
- Gerenciamento de dados, com operações de inserção, atualização e deleção de dados.
- Escalabilidade, para os grandes volumes de dados.
- Robustez, com backups automáticos dos dados.
- Segurança, com controle de acessos e proteção de dados sensíveis.
- Otimizações de performance, com técnicas de indexação, particionamento e métodos de buscas otimizados.
- Integrações com diversas ferramentas, de plataformas de ETL a ferramentas de visualização.
Apesar de todos esses empréstimos de funcionalidades, a forma de interagir com estes bancos muda drasticamente. Em bancos de dados tradicionais, o usuário que consulta os dados espera obter registros que atendam exatamente a uma determinada condição, como por exemplo, registros de vendas de um determinado mês, ou um usuário que possua exatamente o endereço de e-mail “chocolate.god@gmail.com” (Certamente não é o meu e-mail). Quando se trata de bancos de vetores, se encontra o contrário: Não se busca exatamente um registro, mas sim alguns registros semelhantes àquilo que o usuário consulta, sejam palavras semelhantes, imagens relacionadas ou qualquer outro tipo de dado. Afinal, buscar coisas semelhantes é o que os vetores fazem de melhor.
E isso também influencia um pouco no seu funcionamento. Para uma consulta ser realizada, o seu valor precisa primeiro ser vetorizado. Ou seja, a requisição feita pelo usuário, que se encontra em um formato entendível, seja um texto, imagem ou linha em uma tabela, precisa ser primeiro levada ao mesmo espaço multidimensional complexo e abstrato, citado na seção passada, onde os vetores habitam.
Uma vez posicionada nesse lugar, como também vimos na última seção, basta olhar ao redor da requisição, e encontrar outros registros próximos que estarão relacionados a ela de alguma forma. E assim se obtém dados semelhantes, que é o que se espera na saída.
E no fim, como fica o desenho?
No último artigo que escrevi, fiz um desenho simples do que seria a arquitetura básica de soluções RAG. Mas deixei a parte em que a vetorização se encaixa de maneira mais vaga de propósito para explorar um pouco melhor os seus conceitos, afinal acho que podem ser conceitos úteis para a área de Engenharia de Dados em um futuro próximo.
Bem, agora eu posso completar o desenho, substituindo o que seria um vago “Repositório de Conhecimentos” por um Vector Database que, recebendo a requisição do usuário em forma de vetor, pode procurar informações semelhantes ao recebido e fornecê-las para a criação do prompt que é de fato entregue ao LLM.
Agora sim temos um desenho completo. Espero que possa ajudar alguém :)
Referências
Understanding Vector Databases por Microsoft
Vector Databases por Microsoft
