LLM e Bases de Dados Vetoriais na Pesquisa Semântica

A capacidade de uma aplicação de inteligência artificial gerar respostas corretas não depende exclusivamente do modelo de linguagem de grande escala utilizado. A forma como o modelo acede à informação de que necessita é igualmente determinante. As perguntas dos utilizadores podem não coincidir textualmente com as expressões presentes nos registos. Neste ponto, ganha relevância a diferença entre a pesquisa baseada em correspondência de palavras e a pesquisa que avalia a proximidade semântica. Ao avaliar a escolha da base de dados em aplicações de LLM, a questão inicial não deve ser qual é o produto mais potente, mas sim a que informação se deve aceder e de que modo.

Considerar as bases de dados SQL e NoSQL insuficientes para a inteligência artificial seria uma generalização incorreta. O limite reside, muitas vezes, mais no método de pesquisa utilizado do que na própria base de dados. Por exemplo, um registo cuja descrição contenha «automóvel desportivo vermelho» não será encontrado através de uma consulta SQL LIKE que procure literalmente «carro rápido». A pesquisa de texto integral pode melhorar o acesso baseado em palavras, mas a mera correspondência de termos não é, em todos os casos, suficiente para captar conceitos semelhantes expressos por palavras distintas.

Na base da pesquisa semântica encontram-se modelos de embedding que convertem o conteúdo em vetores numéricos. Os textos são transformados, através de um modelo adequado, em coordenadas multidimensionais que representam relações de significado. A pergunta do utilizador é igualmente vetorizada através do mesmo modelo ou de um modelo compatível. Em seguida, o vetor da consulta é comparado com os vetores dos registos. Desta forma, uma pesquisa por «carro rápido» pode incluir o registo «automóvel desportivo vermelho» entre os resultados relevantes, mesmo sem conter as mesmas palavras. O sucesso deste processo depende da qualidade do modelo e dos dados.

À medida que o número de vetores aumenta, comparar cada consulta individualmente com todos os registos pode tornar-se dispendioso. A ANN, ou seja, a pesquisa aproximada dos vizinhos mais próximos, visa encontrar vetores semelhantes de forma mais eficiente. O HNSW é uma das abordagens de indexação utilizadas para este fim. Aqui, o termo «aproximada» é fundamental: estabelece-se um equilíbrio entre a velocidade de pesquisa, o consumo de recursos e a eficácia na obtenção de resultados relevantes. Por conseguinte, o valor de um índice não deve ser avaliado apenas pela velocidade, mas em conjunto com a qualidade dos resultados exigida pela aplicação.

Esta abordagem de acesso desempenha um papel crucial na arquitetura RAG. O RAG recupera conteúdos relevantes para a questão do utilizador a partir de uma fonte de informação e fornece-os como contexto ao modelo de linguagem. A pesquisa vetorial é um dos métodos que podem ser utilizados para selecionar estes conteúdos; não se trata do mesmo processo que o treino do modelo. Caso os documentos recuperados sejam incorretos, incompletos ou irrelevantes, a qualidade da resposta poderá ser comprometida. Por isso, na conceção de um sistema RAG, é essencial focar não apenas na escolha do modelo, mas também na preparação do conteúdo de origem e na relevância dos resultados da pesquisa.

Na prática, a solução não passa necessariamente pela substituição da base de dados existente. Extensões que fornecem suporte vetorial, como o pgvector, e soluções dedicadas a vetores, como Pinecone, Weaviate ou Milvus, podem ser avaliadas para diferentes necessidades. Na tomada de decisão, a integração com os sistemas existentes, o volume de dados, os requisitos de filtragem e as condições operacionais devem ser considerados em conjunto. Na X Mind Solutions, abordamos esta questão não como uma rejeição das bases de dados tradicionais, mas como a conceção de uma arquitetura adaptada às necessidades de acesso à informação da inteligência artificial.