O que são Bancos de Dados Vetoriais e Embeddings?

Um embedding é um vetor numérico que captura significado; um banco de dados vetorial armazena e busca esses vetores por similaridade, não por igualdade. As duas ideias são uma capacidade só: um modelo transforma texto (ou imagens, ou áudio) numa lista de números posicionada de modo que significados parecidos caiam perto, e um banco de dados vetorial encontra os pontos mais próximos rápido. Esse é o truque inteiro por trás da busca semântica, das recomendações e do RAG — e, para quem desenvolve aplicações, a manchete prática é que embeddings são apenas um campo que você armazena ao lado dos dados que eles descrevem.

Principais pontos

Embeddings, concretamente

Esqueça 1.536 dimensões por um instante e imagine três: um modelo de brinquedo que pontua cada palavra em é-animal, é-veículo, é-pequeno.

                animal  veículo  pequeno
gatinho          0.95     0.02    0.90
gato             0.93     0.01    0.60
caminhão         0.03     0.96    0.05
moto             0.04     0.94    0.55

"gatinho" fica perto de "gato" (ambos com animal alto) e longe de "caminhão".
distância(gatinho, gato)     → pequena  → similares
distância(gatinho, caminhão) → grande   → sem relação

Modelos reais usam centenas ou milhares de dimensões em vez de três,
aprendidas dos dados em vez de rotuladas à mão — mas a intuição é exatamente esta:
significado vira geometria, e "similar" vira "próximo".

A demonstração famosa de que isso captura estrutura real é a aritmética sobre os vetores: em word embeddings treinados, rei − homem + mulher cai perto de rainha. Significado transformado em coordenadas faz álgebra.

Como funciona a busca por similaridade

Três métricas de distância dominam: o cosseno mede o ângulo entre os vetores (ignorando o comprimento), o produto escalar incorpora a magnitude e a euclidiana é a distância em linha reta. O insight que evita confusão: para vetores normalizados as três ranqueiam os resultados de forma idêntica, e como os modelos de embedding de texto tipicamente produzem vetores normalizados ajustados para cosseno, a pergunta “qual métrica?” em geral já vem respondida.

Exato vs. aproximado: o trade-off do ANN

A busca exata compara a consulta com cada vetor armazenado — perfeita, e perfeitamente adequada até por volta de um milhão de vetores. Além disso, o HNSW — o índice aproximado dominante — constrói um grafo de proximidade em camadas (camadas superiores esparsas para saltos longos, uma camada inferior densa com tudo) e desce gulosamente do grosso ao fino, pulando a maioria das comparações. É um primo semântico da B-tree: onde a B-tree indexa “igual a” e “menor que”, um índice ANN indexa “similar a”. A ressalva honesta que os concorrentes suavizam: o ANN pode perder o vizinho mais próximo verdadeiro, seus parâmetros trocam recall por velocidade e memória, e o grafo vive na RAM — motivo pelo qual dimensionar um banco vetorial é, na prática, uma conversa sobre memória.

Índice vetorial vs. banco de dados vetorial

Uma distinção que a sopa de termos esconde: uma biblioteca de índice em memória (como o FAISS) calcula vizinhos mais próximos, mas não persiste, não atualiza e não filtra — reindexe a cada restart, e não existe cláusula WHERE. Um banco de dados vetorial embrulha o índice com durabilidade, atualizações incrementais e filtragem por metadados. Essa lacuna é exatamente o motivo pelo qual “só usar uma biblioteca” falha em produção e pelo qual o seu banco de dados atual com um índice vetorial costuma ser a resposta certa — ele já tem a durabilidade, as transações e as permissões que faltam à biblioteca.

Você realmente precisa de um banco de dados vetorial dedicado?

A resposta neutra que as páginas de fornecedores não podem dar. Um banco de dados de uso geral com suporte vetorial — Postgres via pgvector, os índices vetoriais HNSW do MongoDB sobre campos de array — atende confortavelmente até cerca de um milhão de vetores por nó, ao lado dos dados da aplicação e das suas permissões. Um motor dedicado paga seu custo operacional e seu imposto de sincronização de sistema duplo (manter o armazém vetorial consistente com o banco fonte-da-verdade) em escala genuinamente grande: dezenas de milhões de vetores, taxas de consulta muito altas ou recall alto exigido sob filtragem pesada. Abaixo de mais ou menos um milhão de vetores, um armazém especializado costuma custar mais em código de cola do que devolve em performance — a aritmética que a maioria das páginas “você precisa de um banco vetorial” estruturalmente não consegue fazer, porque elas são o banco vetorial.

Filtragem por metadados é a fronteira de segurança

A similaridade vetorial ranqueia por significado e não sabe nada sobre quem pode ler o quê — então a consulta de produção nunca é “os dez vizinhos mais próximos”, e sim “os dez vizinhos mais próximos que este usuário pode ver”. Erre a ordem e o problema não é um bug de relevância, é um vazamento de dados: a pré-filtragem restringe os candidatos ao conjunto permitido antes da busca ANN (correto); a pós-filtragem corta depois, vazando a existência dos itens proibidos e devolvendo silenciosamente menos que k. Quando o filtro são as ACLs, a pré-filtragem é a diferença entre uma busca semântica e um incidente de segurança — a mesma lição que o RAG aprende do jeito difícil. Armazenar os embeddings no banco que já aplica as suas permissões é como o filtro sai de graça.

Embeddings em código real

// JavaScript — Cloud Code (cloud/main.js)
// Embeddings live as a field next to the data they describe
Parse.Cloud.beforeSave('Doc', async (req) => {
  if (req.object.dirty('text')) {
    // generate server-side; embedding API key stays on the server
    req.object.set('embedding', await embed(req.object.get('text')));
    req.object.set('embedModel', 'text-embed-v3'); // version it — models differ
  }
});

// Similarity search, ACL-filtered: "nearest neighbors this user MAY see"
Parse.Cloud.define('semanticSearch', async (req) => {
  const qVec = await embed(req.params.q);
  return vectorSearch('Doc', qVec, { limit: 10, aclUser: req.user });
  // The pre-filter is the security boundary, not a relevance tweak.
});

// Flutter / Dart — Back4app Flutter SDK
// The client searches by meaning — the vector math is server-side
final results = await ParseCloudFunction('semanticSearch')
    .execute(parameters: {'q': 'how do refunds work?'});
for (final doc in results.result) print(doc['title']);
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.

// iOS / Swift — Back4app Swift SDK
// The client searches by meaning — the vector math is server-side
let results: [[String: Any]] = try await Cloud.run(
    name: "semanticSearch",
    parameters: ["q": "how do refunds work?"])
for doc in results { print(doc["title"] ?? "") }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.

// Android / Kotlin — Back4app Android SDK
// The client searches by meaning — the vector math is server-side
val params = mapOf("q" to "how do refunds work?")
val results = ParseCloud.callFunction<List<Map<String, Any>>>(
    "semanticSearch", params)
results.forEach { println(it["title"]) }
// "refund policy" matches "money back" though they share no keywords —
// because their embeddings are near each other. Filtered to your ACL.

Repare no campo embedModel: vetores de modelos diferentes — ou de versões diferentes do mesmo modelo — não são comparáveis, então trocar de modelo de embedding significa re-embeddar o corpus inteiro. Guarde o nome do modelo junto dos vetores, ou um upgrade silencioso transforma seu índice em ruído.

Casos de uso comuns

• Busca semântica — “quero meu dinheiro de volta” encontra “política de reembolso” mesmo sem nenhuma palavra em comum.
• Recuperação para RAG — buscar os chunks que fundamentam a resposta de um LLM.
• Recomendações — itens próximos do histórico do usuário no espaço de embeddings.
• Deduplicação e clustering — conteúdo quase idêntico como vetores quase idênticos.
• Detecção de anomalias e fraude — outliers são vetores longe de todos os exemplos normais.

Onde seus vetores devem morar? Matriz de decisão

Limitações e trade-offs

• Embeddings codificam a visão de mundo do modelo. Vieses, pontos cegos e o corte de treinamento vêm junto; a geometria só é tão boa quanto o modelo que a desenhou.
• ANN é aproximado de propósito. Ajuste o recall ao que está em jogo; “geralmente encontra o melhor resultado” é o acordo que você assinou pela velocidade.
• A versão do modelo é um schema. Re-embeddar um corpus grande numa troca de modelo é uma migração de verdade, não um flag de configuração.
• Memória é o teto. Grafos HNSW vivem na RAM; limites de vetores por nó são limites de memória com outro rótulo.
• Similaridade não é relevância. Estar perto no espaço vetorial é um sinal forte, não uma garantia — busca híbrida e re-ranking existem porque a busca vetorial pura erra termos exatos.

Vetores no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Como ele roda sobre MongoDB, a história de armazenamento é a que este artigo recomenda: um embedding é um campo de array no objeto que ele descreve — o documento e seu vetor no mesmo registro — com indexação vetorial HNSW como o mecanismo real por baixo. As consequências se encadeiam de forma limpa: as ACLs que já governam cada consulta viram o pré-filtro da busca por similaridade de graça, então a recuperação não consegue cruzar uma fronteira de permissão; os embeddings são gerados num gatilho beforeSave de Cloud Code chamando um modelo de embedding com a chave mantida no servidor; e não existe um serviço vetorial separado para sincronizar, proteger e pagar. Para os corpora em escala de aplicação que a maioria dos produtos realmente tem, “banco de dados vetorial” não é um sistema que você adota — é um campo que você adiciona.