Vector Database

Uma base de dados vetorial armazena embeddings, os vetores numéricos que os modelos produzem para texto, imagens, áudio ou vídeo, juntamente com um ID e metadados para cada item, e responde à pergunta «quais são os vetores armazenados mais próximos deste?» em milissegundos, mesmo com milhões ou milhares de milhões de itens. Envolve um índice de pesquisa vetorial com funcionalidades de base de dados: inserções, atualizações e eliminações, filtragem por metadados, persistência, controlo de acesso e replicação entre máquinas. As bases de dados vetoriais fornecem a etapa de recuperação para a geração aumentada por recuperação (RAG), a pesquisa semântica e os sistemas de recomendação.

Como funciona uma base de dados vetorial#

Na fase de escrita, um modelo de embeddings, executado fora da base de dados ou integrado nela, converte cada item num vetor, e a base de dados armazena esse vetor com um ID e uma carga de metadados, como o ficheiro de origem, a data, a câmara ou o cliente. Comparar uma consulta com todos os vetores armazenados é exato, mas lento à escala, por isso a base de dados cria um índice de vizinhos mais próximos aproximados (ANN). O HNSW liga cada vetor aos seus vizinhos próximos num grafo em camadas, que a pesquisa percorre de forma gulosa; os índices de ficheiro invertido (IVF) agrupam os vetores com agrupamento k-means e percorrem apenas os grupos mais próximos da consulta; e os métodos de quantização vetorial, como a quantização de produto, comprimem cada vetor em alguns bytes. Na fase de leitura, a consulta é convertida em embedding com o mesmo modelo e comparada usando uma métrica como a similaridade do cosseno, o produto escalar ou a distância euclidiana, e a base de dados devolve os IDs, as pontuações e as cargas dos k melhores resultados, que muitos sistemas combinam com resultados por palavras-chave na pesquisa híbrida.

Este exemplo usa o Chroma, uma base de dados vetorial de código aberto que é executada em memória dentro de um processo Python:

import chromadb

# Cliente em memória; chromadb.PersistentClient(path="db") mantém os dados no disco
client = chromadb.Client()
collection = client.create_collection("inspection_notes")

# O Chroma gera embeddings para cada documento com o seu modelo de embeddings predefinido e indexa os vetores
collection.add(
    ids=["n1", "n2", "n3"],
    documents=[
        "Hairline crack found near the weld on bracket B7",
        "Paint scratch on the left door panel",
        "Porosity in the weld seam of the frame rail",
    ],
    metadatas=[{"line": "A"}, {"line": "B"}, {"line": "B"}],
)

# Pesquisa de vizinhos mais próximos restrita a uma linha de produção
results = collection.query(query_texts=["welding defects"], n_results=1, where={"line": "B"})
print(results["ids"][0], results["documents"][0])

A consulta devolve a nota n3, sobre porosidade na soldadura da linha B. O filtro de metadados exclui da pesquisa a nota sobre a fissura na linha A, apesar de o respetivo texto ser igualmente semelhante a «defeitos de soldadura».

Bases de dados vetoriais vs. sistemas relacionados#

• Bibliotecas de pesquisa vetorial, como FAISS: Índices no processo, incluindo HNSW, IVF e quantização de produto, sem servidor, armazenamento de metadados ou replicação. Várias bases de dados vetoriais assentam nelas.
• Bases de dados vetoriais criadas para esse fim: Pinecone como serviço gerido, e Milvus, Qdrant, Weaviate e Chroma como projetos de código aberto, concebidos desde o início em torno de embeddings.
• Extensões vetoriais, como pgvector: Adicionam colunas vetoriais com índices HNSW e IVFFlat ao PostgreSQL, para que os embeddings fiquem junto dos dados relacionais. Elasticsearch, OpenSearch, MongoDB Atlas e Redis oferecem campos vetoriais semelhantes junto da pesquisa por palavras-chave.
• Armazéns de características: Servem características de entrada dos modelos por chave de entidade para treino e inferência. Procuram registos por ID, não por semelhança.
• Lagos de dados: Armazenam ficheiros brutos, como imagens e registos, aos quais uma base de dados vetorial faz referência por ID ou caminho.

Aplicações no mundo real#

• Memória para agentes de IA: Os pipelines RAG e os agentes armazenam segmentos de documentos e conversas anteriores para que um modelo de linguagem de grande dimensão os possa recuperar quando necessário.
• Pesquisa visual no retalho: As funcionalidades «Comprar semelhantes» geram embeddings para cada fotografia de produto e devolvem os itens mais próximos daquele que o cliente está a consultar.
• Deteção de anomalias: Uma nova amostra cujos vizinhos armazenados mais próximos estão todos muito distantes é assinalada como invulgar, por exemplo, uma transação ou uma leitura de sensor.

Coleções de imagens precisam de um modelo de visão para produzir os vetores. O Ultralytics YOLO26 oferece essa capacidade por meio de model.embed(), que executa o modelo em cada imagem e retorna um vetor de características agrupado a partir da penúltima camada, pronto para ser armazenado junto ao caminho da imagem e aos metadados de captura para detectar quase duplicatas ou buscar imagens semelhantes — o tipo de pesquisa por trás de Encontrar imagens semelhantes na Ultralytics Platform.

Dimensionamento e ajuste#

As definições do índice equilibram a revocação e a latência de inferência: a amplitude de pesquisa do HNSW (ef_search) e o número de grupos sondados pelo IVF (nprobe) encontram ambos mais vizinhos verdadeiros à custa de consultas mais lentas, por isso as equipas ajustam-nos comparando-os com a pesquisa exata em consultas de amostra. A memória determina o custo do hardware. Um milhão de embeddings float32 com 768 dimensões ocupa 3,07 GB (1 000 000 x 768 x 4 bytes) antes de qualquer sobrecarga do índice; a quantização escalar int8 dos vetores reduz esse valor para 768 MB; e os embeddings Matryoshka podem ser truncados para menos dimensões, reduzindo-o ainda mais.