Banco de dados vetorial, explicado

A resposta curta

Um banco de dados vetorial guarda texto como listas de números que representam significado, e encontra as entradas mais próximas da sua consulta nesse espaço numérico. É busca por similaridade em vez de por palavra exata.

É por isso que ele casa "consigo meu dinheiro de volta" com um documento chamado "política de reembolso" sem nenhuma palavra em comum. É também a razão inteira de ele existir, e todo o resto é implementação.

Por que a busca normal não basta

Busca por palavra-chave casa strings. É rápida, exata e completamente literal, o que é ótimo quando o usuário conhece o seu vocabulário e inútil quando não conhece. Seu cliente não diz "remessa", ele diz "o dinheiro que eu mandei".

A busca tradicional remedia parte disso com sinônimo e radicalização, tudo mantido na mão e tudo frágil. Busca por similaridade contorna o problema comparando significado direto.

O que não torna busca por palavra-chave obsoleta. Identificador exato, número de pedido, SKU, nome: isso continua melhor servido por correspondência exata, e os melhores sistemas de recuperação usam os dois.

O que é um embedding de verdade

Um modelo de embedding lê um pedaço de texto e devolve uma lista fixa de números, em geral de algumas centenas a alguns milhares deles. Textos com significados parecidos caem perto um do outro nesse espaço.

Você não precisa entender a geometria para usar. O que precisa saber é que o mesmo modelo de embedding tem que ser usado para guardar e para consultar, que trocar de modelo significa reprocessar tudo, e que a qualidade do embedding limita a qualidade da recuperação por melhor que seja o banco.

Como a busca funciona

Sua consulta é convertida do mesmo jeito que seus documentos foram. O banco então acha os vetores guardados mais próximos, usando um índice que troca um pouco de precisão por muita velocidade, porque comparar com todo registro de forma exata não escala.

Você recebe de volta as correspondências mais próximas com uma nota de similaridade. O detalhe crítico: ele sempre devolve alguma coisa. Não existe "nenhum resultado". Se nada relevante existe, você recebe o menos irrelevante, e é assim que sistemas acabam respondendo com confiança a partir do documento errado.

Você precisa de um dedicado?

Muitas vezes não. Se você já roda Postgres, o pgvector dá conta de um acervo considerável e te poupa de um sistema, de um deploy e de um problema de sincronização entre seus registros e seus vetores.

Um banco dedicado se justifica em escala de verdade, com carga alta de consulta concorrente, ou quando você precisa de recursos em que ele é especializado. Adotar cedo é uma forma comum de adicionar superfície operacional para um problema que você ainda não tem.

A pergunta não é qual é melhor. É se o custo operacional de um segundo banco é menor que a dor que você tem hoje.

A parte que decide a qualidade

Não é o banco. Chunking, metadado e filtro decidem se a recuperação presta, e é neles que o trabalho de fato está.

Corte pequeno demais e você tira o contexto, então o modelo vê a exceção sem a regra. Corte grande demais e você dilui o sinal. Anexe metadado para tudo que você vai precisar filtrar, principalmente permissão, porque recuperação que ignora quem está perguntando uma hora entrega um documento a quem nunca deveria vê-lo.

Filtre antes de buscar quando der. Restringir o conjunto candidato por cliente, data ou tipo de documento melhora velocidade e relevância de forma mais confiável do que trocar de banco.

O que quebra em escala

A qualidade degrada em silêncio. Um sistema que funciona com mil documentos fica sutilmente pior com cem mil, e nunca dá erro. Vizinhos mais próximos ficam menos significativos conforme o espaço lota, e quase duplicatas passam a abafar a única resposta correta.

Depois a realidade operacional: reprocessar um acervo grande após troca de modelo é caro e lento, e manter vetores em sincronia com uma fonte de verdade que muda é um pipeline, não um script.

Nada disso é visível sem medição, e é por isso que recuperação precisa de avaliação própria, separada da geração. Cobrimos essa divisão em o que é RAG e como medir em evals de LLM.

Quanto custa

Três linhas. Gerar embedding do acervo, custo único por documento mais um custo pequeno contínuo para as mudanças. Armazenamento e consulta, que escala com tamanho do acervo e tráfego. E o reprocessamento que você vai pagar quando trocar de modelo.

Para a maioria dos acervos de médio porte esses números são menores do que os times esperam. A parte cara é a engenharia em volta, não o armazenamento.

Quando você não precisa de um

Se o seu conhecimento cabe num prompt e muda pouco, coloque no prompt. Se suas perguntas são respondidas por uma consulta estruturada de formato conhecido, escreva a consulta, porque busca por similaridade sobre registros é uma versão pior de SQL.

E se a tarefa é uma decisão em vez de uma busca, recuperação não é a forma que você precisa. Escolher a forma errada é o erro caro, e é por isso que começamos pela decisão quando construímos IA em produção, ponta a ponta.