--- term: 'Banco de Dados Vetorial & Embeddings' seoTitle: 'Banco de Dados Vetorial e Embeddings: HNSW, ANN, Quando Usar' headline: 'O que são Bancos de Dados Vetoriais e Embeddings?' slug: banco-de-dados-vetorial category: ai-modern-stack shortDefinition: '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.' relatedTerms: - retrieval-augmented-generation-rag - nosql-vs-sql - database-index - access-control-lists-acl contrastsWith: - nosql-vs-sql aboutTerms: - 'Embeddings' - 'Banco de Dados Vetorial' - 'HNSW / ANN' - 'Similaridade de Cosseno' faq: - question: 'O que é um embedding em termos simples?' answer: 'Uma lista de números que um modelo atribui a um dado — texto, imagem, áudio — de forma que coisas com significado parecido recebam números parecidos. Dois documentos sobre o mesmo assunto acabam como pontos vizinhos num espaço de alta dimensão, e é isso que permite a um computador medir o quanto duas coisas são "similares".' - question: 'O que é um banco de dados vetorial?' answer: 'Um sistema que armazena embeddings e responde rapidamente "quais itens armazenados são mais similares a este", usando índices de vizinhos mais próximos aproximados (ANN) em vez de buscas por correspondência exata. A parte "banco de dados" — durabilidade, atualizações, filtragem por metadados — é o que o separa de uma simples biblioteca de índice em memória.' - question: 'Como funciona a busca por similaridade?' answer: 'A consulta vira embedding com o mesmo modelo e é comparada aos vetores armazenados por uma métrica de distância: cosseno (só o ângulo), produto escalar (ângulo e magnitude) ou euclidiana (distância em linha reta). Para vetores normalizados as três ranqueiam os resultados de forma idêntica, e modelos de embedding de texto costumam ser ajustados para cosseno.' - question: 'Qual é a diferença entre busca exata e aproximada?' answer: 'A exata (kNN) compara a consulta com cada vetor — recall perfeito, mas tempo linear, viável até por volta de um milhão de vetores. A aproximada (ANN, geralmente HNSW) pula a maioria das comparações e atinge velocidade quase logarítmica, trocando alguns pontos percentuais de recall por consultas ordens de magnitude mais rápidas. Perder o vizinho mais próximo verdadeiro de vez em quando costuma ser aceitável.' - question: 'O que é HNSW?' answer: 'Hierarchical Navigable Small World — o índice ANN dominante em produção. Ele constrói um grafo de proximidade em múltiplas camadas: as camadas superiores, esparsas, dão atalhos de longo alcance; a camada inferior, densa, contém todos os vetores; e a busca desce gulosamente do grosso ao fino. Seus parâmetros trocam recall por velocidade e memória, e o grafo vive na RAM.' - question: 'Preciso de um banco de dados vetorial dedicado?' answer: 'Em escala de aplicação, geralmente não. Um banco de dados de uso geral com suporte a índice vetorial — Postgres com pgvector, a busca vetorial do MongoDB — lida confortavelmente com até cerca de um milhão de vetores por nó, ao lado dos seus dados e permissões. Motores dedicados se pagam com dezenas de milhões de vetores, taxas de consulta muito altas ou recall alto sob filtragem pesada.' - question: 'O que é filtragem por metadados e por que ela importa?' answer: 'Restringir a busca por similaridade por campos — tenant, categoria, data, permissões. A pré-filtragem limita os candidatos antes da busca ANN; a pós-filtragem corta depois e pode silenciosamente devolver menos resultados do que você pediu. Consultas de produção são quase sempre filtradas, e quando o filtro é de permissões, ele é uma fronteira de segurança.' - question: 'Para que serve um banco de dados vetorial além do RAG?' answer: 'Busca semântica, recomendações, detecção de quase-duplicatas e detecção de anomalias ou fraude (outliers são vetores longe de todo o resto), além de similaridade de imagem e áudio e clustering. O RAG é o uso famoso; a busca por similaridade é a capacidade geral por baixo dele.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'HNSW — Malkov & Yashunin (arXiv:1603.09320)' url: 'https://arxiv.org/abs/1603.09320' - name: 'Efficient Estimation of Word Representations (word2vec, arXiv:1301.3781)' url: 'https://arxiv.org/abs/1301.3781' - name: 'pgvector — open-source vector search for Postgres' url: 'https://github.com/pgvector/pgvector' - name: 'MongoDB Vector Search — overview' url: 'https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/' cta: title: 'Vetores ao lado dos seus dados' text: 'No Back4app, embeddings são apenas campos de array nos seus objetos — indexados para similaridade, filtrados pelas mesmas ACLs que protegem todo o resto, gerados no Cloud Code com a chave do modelo no servidor.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: vector-database-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](/glossary/pt/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 | Pergunta | Resposta | | --- | --- | | Embedding | Um vetor em que significado parecido → pontos vizinhos | | Banco de dados vetorial | Armazena vetores + responde "os mais próximos deste" via índices ANN | | A métrica | Cosseno (padrão para texto) · produto escalar · euclidiana | | Exato vs. ANN | Perfeito-mas-linear vs. ~99% de recall, ordens de magnitude mais rápido | | Você precisa de um dedicado? | Em geral só a partir de ~10M+ vetores — seu banco provavelmente já resolve | ## 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*. ```text 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](https://arxiv.org/abs/1301.3781), *rei − homem + mulher* cai perto de *rainha*. Significado transformado em coordenadas faz álgebra. ## Como funciona a busca por similaridade ```mermaid flowchart LR accTitle: Dos dados aos embeddings e à busca por similaridade accDescr: Um modelo transforma cada item num vetor armazenado num índice vetorial. No momento da consulta, a consulta vira embedding com o mesmo modelo, e o índice devolve os vetores mais próximos por uma métrica de distância, opcionalmente filtrados por metadados como permissões, ranqueados por similaridade. D["Itens
(texto, imagens, áudio)"] -->|"embedding"| VS["Vetores num índice"] Q["Consulta"] -->|"mesmo modelo"| QV["Vetor da consulta"] QV --> S{"Mais próximos por
cosseno / escalar / L2"} VS --> S S -->|"filtro por metadados / ACL"| K["Top-k resultados
similares"] ``` 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 | | Exato (kNN) | Aproximado (ANN) | | --- | --- | --- | | Compara contra | Todos os vetores | Um subconjunto esperto | | Recall | 100% | ~95–99%, ajustável | | Velocidade | Linear — O(n) | Quase logarítmica | | Suficiente até | ~1M de vetores | Dezenas de milhões+ | | Custo | CPU por consulta | RAM para o grafo | 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](https://arxiv.org/abs/1603.09320)** — 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](/glossary/pt/indice-de-banco-de-dados/): 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](https://github.com/pgvector/pgvector), os [índices vetoriais HNSW do MongoDB](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/) 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](/glossary/pt/listas-de-controle-de-acesso-acl/). 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](/glossary/pt/listas-de-controle-de-acesso-acl/), a pré-filtragem é a diferença entre uma busca semântica e um incidente de segurança — a mesma lição que o [RAG](/glossary/pt/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:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // 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>>( "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](/glossary/pt/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 | Situação | Escolha | | --- | --- | | Corpus em escala de aplicação (< ~1M de vetores) | O índice vetorial do seu banco — ao lado dos dados | | Vetores precisam respeitar permissões de usuário | Onde as [ACLs](/glossary/pt/listas-de-controle-de-acesso-acl/) já estão | | Dezenas de milhões de vetores, QPS alto | Um motor vetorial dedicado | | Termos exatos *e* significado importam | Busca híbrida com fusão de rankings | | Um protótipo rápido | pgvector ou um armazém embutido — não superconstrua | | Um processo só, sem persistência | Uma biblioteca de índice (FAISS) — aceitando os limites | ## 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](/glossary/pt/listas-de-controle-de-acesso-acl/) 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](/glossary/pt/cloud-code-funcoes-serverless/) chamando um modelo de embedding com a [chave mantida no servidor](/glossary/pt/seguranca-de-chaves-de-api/); 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.