Banco de Dados Vetorial

No sistema de conhecimento de uma casa inteligente, o banco de dados vetorial ocupa a camada que persiste embeddings, metadados e referências e executa consultas de vizinhança. Um registro pode conter um vetor de 384, 768, 1.536 ou mais dimensões, conforme o modelo, além de `document_id`, versão, produto, cômodo, permissão e timestamp. A busca calcula proximidade por cosseno, produto interno ou distância euclidiana. Para grandes coleções, índices aproximados como HNSW, IVF e quantização reduzem custo em troca de recall. O termo abrange produtos especializados e recursos vetoriais de bancos gerais. A escolha deve partir do volume, taxa de atualização, filtros, consistência, latência e operação. Um índice rápido sem controle de acesso ou capacidade de reconstrução é inadequado.

• O vetor não deve ser o único conteúdo persistido. O banco precisa de ID estável, referência à fonte, metadados, modelo de embedding, dimensão, versão e hash. O texto completo pode ficar no mesmo sistema ou em armazenamento separado. A recuperação retorna IDs e scores; a aplicação carrega o trecho autorizado. A origem permite citar, atualizar e apagar. Se um manual é substituído, os vetores antigos precisam ser removidos. Upserts devem ser idempotentes. Uma política de namespace ou tenant separa residências. Filtros são tão importantes quanto a similaridade: sem `model=S100`, um manual S200 pode ficar mais próximo semanticamente e induzir erro.
• Índices de vizinhança aproximada aceleram grandes volumes. HNSW constrói um grafo em camadas e usa parâmetros como `M`, `efConstruction` e `efSearch`; valores maiores tendem a elevar recall e memória ou latência. IVF particiona o espaço e consulta células. Product Quantization comprime vetores. Não há configuração universal. A avaliação mede recall contra busca exata, p95 de latência e memória. Para 10 mil chunks, uma busca exata em hardware comum pode ser suficiente. Introduzir cluster distribuído cria custo de backup, atualização e observabilidade. Em uma residência, simplicidade costuma superar escala teórica. Em plataforma de fabricante com milhões de documentos, índices distribuídos e sharding podem ser necessários.
• A métrica deve corresponder ao modelo. Alguns embeddings são treinados para cosseno e normalizados; outros para produto interno. Distância euclidiana pode produzir ordem diferente. O banco precisa configurar corretamente. A dimensão deve ser validada no insert. Misturar vetores de modelos diferentes no mesmo índice gera resultados sem sentido, mesmo se a dimensão coincide. Uma migração cria nova coleção, reindexa e troca tráfego após avaliação. O nome da coleção inclui versão. O sistema evita atualizar modelo da consulta antes do corpus. Dual write e dual read permitem comparar. Backups de vetores são úteis, mas a fonte e pipeline são a recuperação definitiva.
• Filtros estruturados e busca híbrida diferenciam uma solução de produção. Metadados podem ser indexados para `tenant_id`, `role`, `language`, `document_type`, `firmware`, `valid_from`, `valid_to` e classificação. O filtro precisa ser aplicado durante a busca, não depois de recuperar conteúdo proibido, quando a implementação suporta. Para busca híbrida, alguns produtos combinam vetores densos e esparsos; outros usam Elasticsearch/OpenSearch ou aplicação. O reranking pode ocorrer fora. Transações e consistência variam. Se um documento é apagado, a exclusão precisa ser refletida antes de novas consultas. Eventual consistency pode criar janela. Dados sensíveis exigem confirmação de deleção e cache invalidado.
• Operação inclui backup, replicação, monitoramento e segurança. Métricas: tamanho de coleção, inserts, falhas, latência p50/p95/p99, recall amostrado, filtros, memória, discos e compaction. O banco usa TLS, autenticação, RBAC e rede privada. Não deve ficar exposto à Internet. Chaves de API têm escopo. Logs não exibem vetores e payloads desnecessariamente. Vetores podem conter informação derivada e não são automaticamente anônimos. Criptografia em repouso e segregação. Uma vulnerabilidade no serviço pode expor corpus. Atualizações precisam de teste. O backup restaura índices ou permite reconstrução. A alta disponibilidade deve ser proporcional; automações locais não dependem do banco vetorial para funções básicas.
• A escolha entre banco especializado e extensão relacional é um trade-off. pgvector mantém SQL, transações, joins e operação conhecida, adequado quando metadados estruturados e volume moderado. Qdrant, Milvus, Weaviate e Pinecone oferecem recursos nativos de vetor, filtros e escala. FAISS é biblioteca, não um banco completo; persistência, multiusuário e API precisam ser construídos. Elasticsearch/OpenSearch combinam lexical e vetor. O critério inclui hospedagem local, cloud, custo, licença, backup e equipe. Para uma casa, SQLite ou PostgreSQL com poucos vetores pode bastar. Não se deve adotar um serviço distribuído apenas porque RAG é usado. A arquitetura deve poder trocar o backend sem perder fontes.