View a markdown version of this page

Práticas recomendadas para índices vetoriais - Amazon DynamoDB

Práticas recomendadas para índices vetoriais

As recomendações a seguir ajudam você a criar índices vetoriais precisos, eficientes e econômicos.

Escolher primeiro o modelo de incorporação e as dimensões

O modelo de incorporação usado determina o número de dimensões que os vetores têm, e você define Dimensions ao criar o índice. Você não pode alterar o número de dimensões após a criação. Escolha um modelo de incorporação antes de criar o índice e use o mesmo modelo para gerar vetores armazenados e vetores de consulta. Menos dimensões reduzem os custos de pesquisa, gravação e armazenamento, mas modelos de maior dimensão podem capturar mais detalhes semânticos. Escolha o menor número de dimensões que satisfaça seus requisitos de relevância. Consulte Geração de incorporações vetoriais.

Combinar a função de distância com incorporações

Escolha a função de distância que corresponda à forma como seu modelo de incorporação representa a similaridade. COSINE compara a direção e ignora a magnitude, o que é adequado à maioria dos modelos de incorporação de texto. EUCLIDEAN mede a distância absoluta e é sensível à magnitude. DOT_PRODUCT também é sensível à magnitude. Se você usá-la, normalize suas incorporações para o comprimento unitário para que as pontuações reflitam a direção em vez do comprimento do vetor. Você não pode alterar a função de distância depois de criar o índice, portanto, primeiro valide sua escolha em relação a um conjunto de dados representativo. Consulte Como as funções de distância classificam os resultados.

Escolher uma chave de partição que corresponda aos padrões de consulta

Uma chave de partição restringe cada chamada de SearchVectors à parte do índice vetorial que pertence a um único valor de chave de partição. A chamada não pesquisa o índice inteiro. Pesquisar menos dados reduz os custos, pode melhorar a latência e a recuperação e dimensiona horizontalmente o throughput em todos os valores da chave de partição.

Você deve fornecer o valor da chave de partição na SearchConditionExpression em cada pesquisa. Cada pesquisa tem como escopo exatamente um valor de chave de partição. Escolha uma chave de partição que corresponda aos padrões de consulta compatíveis com seu aplicativo.

Por exemplo, se você armazenar dados baseados em localização por estado dos EUA, terá aproximadamente 50 valores de chave de partição. Cada estado contém um número significativo de vetores para uma boa recuperação. As 50 partições fornecem uma escala de throughput horizontal de até aproximadamente 50x. Isso funciona quando cada pesquisa é direcionada para um único estado.

Evite cardinalidade extrema em qualquer direção:

  • Muito alto (por exemplo, um ID de item exclusivo): cada partição contém um único item sem vizinhos para comparar, o que produz uma recuperação ruim.

  • Muito baixo (por exemplo, um booleano): a maioria dos itens fica em uma partição, o que limita o dimensionamento de throughput e reduz a latência e os benefícios de custo.

Para filtrar ainda mais dentro de uma partição, use atributos de filtro integrado.

Exemplo de throughput. Considere um modelo de incorporação de 768 dimensões (como o Cohere Embed v3) com 1 KB de dados de itens não vetoriais, fornecendo um tamanho total do item de aproximadamente 4 KB (768 dimensões × 4 bytes + 1 KB). Com esse tamanho de item, os limites por chave de partição se traduzem em:

  • Pesquisa: 1 GBps ÷ 4 KB ≈ 250.000 vetores examinados por segundo por valor de chave de partição. Conforme o número de vetores em uma partição aumenta, cada pesquisa examina mais dados e você se aproximará do limite mais cedo.

  • Gravação: 10 MBps ÷ 4 KB ≈ 2.500 gravações vetoriais por segundo por valor de chave de partição

Distribuir seus dados em mais valores de chave de partição multiplica esses limites. Por exemplo, 50 valores de chave de partição fornecem até 50 vezes o throughput agregado de pesquisa e gravação. Se a workload exceder esses limites de partição, entre em contato com o AWS Support.

Manter as incorporações sincronizadas com o conteúdo de origem

O DynamoDB não recalcula as incorporações para você. Sempre que você alterar o conteúdo de origem que uma incorporação representa, gere novamente o vetor com o mesmo modelo de incorporação e grave-o de volta no item. Caso contrário, o índice continuará retornando resultados com base no vetor obsoleto. Considere capturar alterações de conteúdo com o DynamoDB Streams e usar um processo downstream para repetir a geração e a gravação das incorporações afetadas.

Projetar somente os atributos necessários

SearchVectors não pode retornar atributos que não sejam projetados no índice vetorial. Projetar mais atributos aumenta o armazenamento do índice e o custo de gravação. Projete os atributos que seu aplicativo lê diretamente dos resultados da pesquisa e recupere o restante com um GetItem ou BatchGetItem de acompanhamento na tabela de base quando precisar deles.

Usar vários índices para comparar modelos de incorporação

É possível criar até cinco índices vetoriais em uma única tabela. Use índices separados para avaliar diferentes modelos de incorporação ou versões de modelos lado a lado. Armazene as incorporações de cada modelo em um atributo vetorial diferente e crie um índice vetorial para cada um. Isso permite comparar a qualidade da pesquisa entre modelos com os mesmos dados subjacentes sem migrar seu índice de produção.

Por exemplo, ao atualizar de uma versão do modelo para outra, crie um segundo índice com as dimensões e a função de distância do novo modelo. Preencha-o com incorporações do novo modelo, execute consultas de teste nos dois índices e compare a relevância. Quando estiver satisfeito, migre seu aplicativo para o novo índice e exclua o antigo.