De quanto armazenamento vetorial necessita um milhão de fragmentos de documentos domésticos?
Um milhão de segmentos requer aproximadamente 1,5–6,1 GB apenas para vetores float32 comuns, antes de índices de grafos, metadados, texto, réplicas e espaço de trabalho.
A aritmética começa pelas dimensões, não pela quantidade de documentos: um milhão de vetores com 768 dimensões contém 768 milhões de valores de quatro bytes, ou cerca de 3,07 GB em decimal. Um armazenamento utilizável é maior porque tem de identificar os vetores, pesquisá-los de forma eficiente, filtrar metadados, conservar o texto dos segmentos e suportar a manutenção dos índices durante as operações de pesquisa e manutenção no servidor.
Os bytes dos vetores em bruto fornecem o limite inferior reproduzível
Multiplique o número de segmentos pelas dimensões dos embeddings e pelos bytes por coordenada. Para um milhão de vetores float32, 384 dimensões utilizam 1,536 GB, 768 utilizam 3,072 GB e 1.536 utilizam 6,144 GB. Os gigabytes binários parecem ser cerca de sete por cento mais pequenos nas unidades apresentadas.
Uma visão geral da escalabilidade apresenta a mesma relação de armazenamento de vetores em bruto: o número de dimensões multiplicado pela largura do valor determina a carga útil das coordenadas antes das estruturas da base de dados.
O float16 pode reduzir para metade o componente dos vetores, e o int8 ou a quantização de produto podem reduzi-lo ainda mais. A compressão pode afetar a recuperação e requer suporte da base de dados. Os documentos de origem e o texto dos segmentos gerados não estão incluídos nestes números.
Os índices e os metadados podem ser tão pesados como as coordenadas
A pesquisa plana acrescenta relativamente pouca estrutura de índice, mas percorre muitos vetores. O HNSW armazena ligações entre vizinhos e várias camadas de grafos para reduzir o trabalho de pesquisa. IDs por vetor, marcadores de registos eliminados, filtros, alinhamento e páginas da base de dados acrescentam mais sobrecarga.
Uma introdução à conectividade HNSW explica por que motivo a conectividade dos grafos acelera a pesquisa aproximada, consumindo simultaneamente memória e armazenamento adicionais. O número de vizinhos configurado altera diretamente esse custo.
Os metadados variam ainda mais. Um ID de documento compacto e um código de idioma podem acrescentar dezenas de bytes; caminhos repetidos, permissões e o texto completo de cada segmento podem acrescentar centenas ou milhares. Armazene o texto uma única vez ou de forma consistente dentro da base de dados vetorial antes de comparar os totais.
Onde falha uma única estimativa de armazenamento
Um intervalo prático de planeamento para um milhão de segmentos float32 com 768 dimensões é frequentemente de 5–12 GB para os vetores e um índice aproximado, antes de texto substancial e réplicas. Este é um intervalo orçamental, não uma garantia de formato.
Uma comparação de arquiteturas vetoriais estima uma sobrecarga de armazenamento HNSW que excede substancialmente as coordenadas em bruto em algumas configurações HNSW. As predefinições do motor e os parâmetros do grafo determinam o multiplicador real.
O intervalo falha quando existem vários embeddings por segmento, índices híbridos de palavras-chave, replicação, instantâneos ou reconstruções que duplicam temporariamente os dados. Também pode sobrestimar um armazenamento comprimido suportado em disco. “Um milhão de segmentos” não é suficiente, a menos que sejam indicados a dimensão, o tipo de dados, o índice, os metadados e o número de cópias.
Extrapole a partir de uma amostra de índice de dez por cento
Insira 100.000 segmentos representativos utilizando o tipo de dados final dos embeddings, o esquema de metadados e os parâmetros do índice. Meça separadamente os bytes da coluna de vetores em bruto, do índice, dos metadados, do texto, do registo de escrita antecipada e dos instantâneos após a compactação. Extrapole os componentes escaláveis multiplicando-os por dez e acrescente margem para reconstrução e cópias de segurança.
Coloque o teste no nível de armazenamento pretendido para o espaço de trabalho de armazenamento, porque a compressão e a alocação do sistema de ficheiros afetam os totais físicos. Evite extrapolar a partir de ficheiros de bases de dados vazios.
Reserve pelo menos o total estável medido, mais uma cópia temporária do índice e 20 por cento de espaço livre. Se a replicação estiver ativada, multiplique apenas os componentes replicados. Repita a amostra sempre que as dimensões, os metadados ou as definições de vizinhos HNSW forem alterados.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Como medir a qualidade da recuperação RAG local e interpretar a cobertura da recuperação, da precisão e das citações
Crie um conjunto de teste RAG local, calcule as principais métricas de recuperação, interprete os seus compromissos e audite se as afirmações das respostas...
Porque é que a computação das funcionalidades de casa inteligente se torna mais importante à medida que aumenta o número de sensores à mesma taxa de amostragem?
Monitorize o processamento por sensor e entre sensores à medida que o número de dispositivos aumenta, identifique os custos não lineares da fusão e...
Porque é que o custo da avaliação de RAG se torna mais importante à medida que a biblioteca de documentos cresce, com o mesmo volume de consultas?
Compreenda por que o crescimento do corpus aumenta o esforço de avaliação do RAG sem mais consultas dos utilizadores e como os testes estratificados...
