storing-and-querying-vectors

À propos storing-and-querying-vectors

storing-and-querying-vectors Ce guide pratique explique comment utiliser Amazon S3 Vectors, un service AWS économique permettant de stocker et d’interroger des représentations vectorielles à grande échelle sous son propre espace de noms d’API s3vectors. Il est optimisé pour le stockage à long terme avec une latence inférieure à une seconde pour les requêtes « froides » et pouvant descendre jusqu’à 100 ms pour les requêtes « tièdes », ce qui le rend adapté au RAG et à d’autres charges de travail comportant des requêtes peu fréquentes. Un guide de décision oriente les utilisateurs vers d’autres solutions lorsque cela est approprié : OpenSearch pour des centaines ou des milliers de requêtes soutenues par seconde ou pour la recherche hybride et les agrégations (avec, en option, S3 Vectors comme moteur de stockage), et un modèle à plusieurs niveaux associant S3 Vectors à OpenSearch Serverless pour les besoins en temps réel.

Le workflow comprend la création d’un compartiment vectoriel, la création d’un index, la génération facultative d’embeddings avec Amazon Bedrock, l’écriture des vecteurs et leur interrogation, en privilégiant les outils serveur AWS MCP et en recourant à la CLI AWS en cas de besoin. L’immuabilité est un thème récurrent : le chiffrement du compartiment (SSE-S3 ou SSE-KMS) et tous les paramètres d’index, y compris la dimension (de 1 à 4 096), la métrique de distance (cosinus ou euclidienne) et jusqu’à dix clés de métadonnées non filtrables, ne peuvent pas être modifiés après la création ; ils doivent donc être validés dès le départ. La dimension d’embeddement doit correspondre à l’index et le même modèle doit être utilisé pour le stockage et l’interrogation.

Les limites opérationnelles sont précisées : 500 vecteurs au maximum par appel `put-vectors`, une nouvelle tentative avec délai d’attente en cas de limitation 429, et le filtrage des métadonnées via `--filter` ou `--return-metadata`, qui nécessite à la fois les autorisations `s3vectors:QueryVectors` et `s3vectors:GetVectors`. Un tableau de dépannage établit une correspondance entre les erreurs telles que DimensionMismatch, 403 et AccessDenied (le service utilise l’espace de noms s3vectors, et non s3) et des solutions concrètes, tandis que des références complémentaires traitent des limites, des modèles multi-locataires et du filtrage des métadonnées.

FAQ

Quand faut-il privilégier S3 Vectors plutôt qu’OpenSearch ?

S3 Vectors convient à un stockage à long terme économique avec des requêtes peu fréquentes et RAG ; pour des centaines ou des milliers de QPS soutenus, la recherche hybride ou les agrégations, la compétence recommande OpenSearch, éventuellement avec S3 Vectors comme moteur de stockage.

Quels paramètres d’index sont immuables ?

Tous les paramètres d’index sont immuables après leur création : la dimension (de 1 à 4 096), la métrique de distance (cosinus ou euclidienne) et jusqu’à dix clés de métadonnées non filtrables, tout comme le chiffrement des compartiments.

Combien de vecteurs puis-je écrire par appel ?

Pas plus de 500 vecteurs par appel « put-vectors » ; le traitement par lots est recommandé et les opérations en masse doivent utiliser un SDK plutôt que l’interface CLI.

Quelles autorisations IAM les filtres de métadonnées requièrent-ils ?

L'utilisation de --filter ou --return-metadata nécessite à la fois les autorisations s3vectors:QueryVectors et s3vectors:GetVectors ; sans GetVectors, ces options renvoient une erreur 403. Le service utilise l'espace de noms s3vectors, et non s3.

Comment les représentations sont-elles générées et mises en correspondance ?

Via la commande `invoke-model` de Bedrock (par exemple Titan ou Cohere) ; la dimension de l’embedding doit correspondre à l’index, et le même modèle doit être utilisé à la fois pour le stockage et pour les requêtes.

Tous les fichiers