Como é que a pesquisa HNSW troca memória por capacidade de recuperação numa base de dados vetorial local?
O HNSW troca memória por recall ao armazenar um grafo navegável de vizinhos, cuja conectividade e amplitude de pesquisa determinam até que ponto as consultas exploram os vetores próximos.
Uma base de dados vetorial local pode conter embeddings de documentos domésticos, texto obtido por OCR, metadados de fotografias, manuais, transcrições e registos de aplicações. A pesquisa por força bruta compara a consulta com todos os vetores, enquanto o HNSW tenta alcançar a mesma vizinhança útil percorrendo um grafo em camadas. Este atalho é rápido porque a base de dados armazena antecipadamente uma estrutura de grafo adicional, e a sua precisão depende do grau de conectividade desse grafo e do número de candidatos que uma consulta pode explorar.
O HNSW adiciona um grafo de proximidade em camadas em torno dos vetores armazenados
Cada vetor torna-se um nó ligado a vizinhos selecionados. Um pequeno subconjunto de nós também aparece em camadas superiores, criando rotas de longo alcance que ajudam a pesquisa a avançar rapidamente para a região onde é provável que se encontrem vetores próximos.
Um grafo de proximidade em várias camadas fornece ao HNSW rotas gerais nas camadas superiores e uma navegação progressivamente mais detalhada entre vizinhos perto da base da hierarquia.
Essas arestas armazenadas constituem o primeiro compromisso de memória. Ao contrário de um vetor plano de vetores, o índice mantém uma topologia que tem de estar disponível durante a travessia.
A hierarquia reduz a quantidade da coleção visitada por uma consulta normal, mas é aproximada: o percurso pode não encontrar um vizinho verdadeiro quando o grafo ou o orçamento de pesquisa não expõem a rota correta.
O parâmetro M utiliza mais memória do grafo para criar mais rotas
As implementações de HNSW expõem um parâmetro de conectividade normalmente designado por `m` ou `M`. Aumentá-lo permite que os nós mantenham mais ligações a vizinhos, criando caminhos alternativos através de partes densas ou irregulares do espaço vetorial.
Um valor m do HNSW mais elevado armazena mais ligações a vizinhos por nó, melhorando normalmente as opções de navegação e o recall, ao mesmo tempo que aumenta a memória do grafo e o trabalho de construção.
O aumento de memória resulta das arestas do grafo e das estruturas de índice associadas, não de tornar maiores os valores dos embeddings originais. Com milhões de vetores, algumas ligações adicionais por nó acumulam-se em toda a coleção. Reduzir `m` pode tornar mais confortável a utilização de um servidor doméstico com memória limitada, mas um grafo demasiado esparso oferece menos formas de contornar becos sem saída locais e pode reduzir o recall.
A construção de Ef utiliza mais trabalho de compilação para melhorar o próprio grafo
A qualidade do grafo também é determinada durante a inserção dos vetores. `ef_construct` controla a amplitude da vizinhança de candidatos que o construtor analisa antes de escolher as ligações para um novo nó.
Utilizar o efConstruction como parâmetro de qualidade da construção permite que a construção do índice analise uma vizinhança de candidatos mais ampla antes de escolher as arestas, melhorando a qualidade do grafo à custa de mais trabalho durante a construção.
Este custo é pago durante a construção ou reconstrução, e não em todas as consultas. Para um corpus privado que muda lentamente, pode ser aceitável investir mais tempo na construção se isso melhorar a qualidade da pesquisa sem aumentar permanentemente a precisão dos vetores.
No entanto, o esforço de construção não consegue compensar indefinidamente um grafo gravemente subdimensionado. `m`, a amplitude da construção, a distribuição dos dados e o histórico de inserções interagem entre si.
O Ef Search utiliza trabalho da consulta em vez de memória permanente do grafo
No momento da consulta, o HNSW mantém uma fronteira de candidatos e explora nós promissores do grafo. Um parâmetro normalmente designado por `ef`, `ef_search` ou `hnsw_ef` controla quantos candidatos permanecem sob consideração durante essa travessia.
Aumentar a amplitude da exploração da consulta permite que um pedido analise mais candidatos do grafo antes de selecionar os resultados mais próximos, aumentando normalmente o recall, mas também a latência da consulta.
Ao contrário de `m`, um `ef` de consulta maior não exige que todos os nós armazenados mantenham mais arestas permanentes. O seu principal custo surge através de cálculos de distância adicionais, acessos à memória e latência para esse pedido. Esta distinção dá a um servidor doméstico dois controlos diferentes: a conectividade do grafo determina a ocupação persistente do índice, enquanto a amplitude da consulta pode ser aumentada apenas para pesquisas difíceis que justifiquem trabalho adicional.
A compressão de vetores não elimina o custo do grafo HNSW
A quantização de embeddings pode tornar cada vetor armazenado muito mais pequeno, mas o HNSW continua a precisar das relações entre vizinhos. O índice total contém, por isso, pelo menos dois componentes principais de memória: os dados dos vetores e a topologia do grafo.
Mesmo quando os valores dos vetores são comprimidos, a quantização não reduz as ligações do grafo; o HNSW continua a precisar da topologia, dos IDs e das estruturas relacionadas em torno desses vetores.
É por isso que uma taxa de compressão dos vetores de 4x ou superior não produz automaticamente a mesma redução global da memória do HNSW. As arestas do grafo, os IDs dos objetos, os metadados, a sobrecarga do alocador e as caches permanecem.
Num servidor doméstico pequeno, meça o conjunto residente completo da coleção em vez de estimar a RAM apenas com base nas dimensões dos vetores.
O recall deve ser medido face aos vizinhos exatos, não inferido a partir das definições
Valores mais elevados de `m` e `ef` normalmente aproximam o sistema de um recall melhor, mas nenhum valor de parâmetro garante uma precisão fixa em todos os modelos de embeddings, tamanhos de corpus ou distribuições de documentos.
O custo da memória do grafo HNSW em várias coleções RAG acumula-se quando várias coleções privadas permanecem ativas ao lado de modelos locais, índices de metadados, caches e outros serviços do servidor doméstico.
Crie um conjunto representativo de consultas e compare os resultados aproximados com uma pesquisa exata numa amostra gerível. Registe o recall, a latência, a RAM do índice, o tempo de construção e o efeito de pedidos simultâneos. O compromisso prático do HNSW não é, portanto, “mais RAM equivale sempre a uma pesquisa melhor”. Trata-se de escolher conectividade suficiente do grafo e uma amplitude de exploração da consulta que cumpram o recall medido sem sobrecarregar o restante sistema de IA doméstico.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...
Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...
É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...
