S3 Vectors ajoute le pré-filtrage par métadonnées et multiplie jusqu’à 5× le rappel des recherches filtrées
Amazon S3 Vectors évalue désormais le filtre de métadonnées avant la recherche de similarité, ce qui remonte jusqu’à 5 fois plus de vecteurs pertinents sur les filtres très sélectifs. L’activation est gratuite, en place et sans ré-ingestion : passez vos index en mode ENHANCED.
30 septembre 2026. Amazon S3 Vectors ajoute le pré-filtrage par métadonnées : le service évalue désormais le filtre avant la recherche de similarité. 30 septembre 2026. Sur les filtres très sélectifs, la même requête remonte jusqu’à 5 fois plus de vecteurs pertinents qu’auparavant. 30 septembre 2026. Chaque vecteur porte 2 Ko de métadonnées filtrables, une requête accepte 100 contraintes de filtre, et un nouvel opérateur $startsWith couvre les chemins, URL et clés hiérarchiques. Pourquoi c’est important : la plupart des applications de RAG ou de recherche sémantique ne fouillent jamais tout l’index — elles cherchent le sous-ensemble d’un client, d’un compte ou d’une catégorie, et c’est précisément là qu’elles perdaient des résultats en silence.
Le problème : filtrer après coup, c’est perdre des correspondances
Une recherche vectorielle filtrée doit répondre à deux exigences à la fois : ne renvoyer que des vecteurs pertinents et ne chercher que dans le bon périmètre. Historiquement, S3 Vectors traitait les deux en tandem : la recherche de similarité tirait ses candidats de l’index entier, puis validait chacun contre le filtre au fil de l’eau. Ce mode, désormais appelé CLASSIC, produit une conséquence contre-intuitive : plus le filtre est sélectif, plus les correspondances réellement pertinentes risquent d’être absentes du résultat.
Prenons une base de tickets de support de 8 millions d’enregistrements. Un agent interroge l’historique d’un client qui ne représente que 400 tickets. En mode CLASSIC, la recherche tirait ses candidats des 8 millions, puis ne gardait que ceux du client : le résultat ne contenait qu’une fraction des 400 tickets réellement pertinents. Avec le pré-filtrage, le filtre customer_id est résolu d’abord, la similarité ne s’exécute que sur les 400 tickets du client, et l’agent voit enfin ses occurrences précédentes.
C’est le point clé : le pré-filtrage ne rend pas la recherche « plus précise » au sens strict, il lui rend l’accès à l’ensemble des correspondances qui auraient dû figurer dans la réponse.
Deux modes d’index, un basculement en place
Chaque index de S3 Vectors possède un mode d’index. En mode ENHANCED, le service résout le filtre d’abord, puis ne cherche que les vecteurs qui correspondent. En mode CLASSIC, il mène la recherche et l’évaluation du filtre en tandem, comme avant. Les index existants restent en CLASSIC tant que vous ne les mettez pas à jour.
La bascule est volontairement légère : une seule commande, aucun changement de requête, aucune ré-ingestion.
aws s3vectors update-index-mode \
--vector-bucket-name my-vector-bucket \
--index-name product-catalog \
--index-mode ENHANCEDLe pré-filtrage prend effet en place. Les vecteurs existants ne sont pas ré-ingérés, les requêtes ne changent pas, et les nouveaux opérateurs de filtre sont disponibles immédiatement. Le tout sans coût supplémentaire — seule la tarification standard de S3 Tables s’applique.
Des métadonnées riches et un opérateur de préfixe
Le modèle de données s’étoffe dans la foulée. Chaque vecteur peut porter jusqu’à 2 Ko de métadonnées filtrables, et par défaut tout champ de métadonnées est filtrable sans déclarer de schéma au préalable. Une requête accepte jusqu’à 100 contraintes, combinables avec $and, $or, des égalités, des plages numériques et des tests d’existence.
L’opérateur le plus attendu est $startsWith, qui introduit le préfixe dans le langage de filtre. Pour une base documentaire qui encode le dossier et l’arborescence dans l’identifiant, une seule condition suffit à borner une recherche à un sous-arbre :
--filter '{"$startsWith": {"document_id": "matter-4417/exhibits/"}}'Cet opérateur rejoint les égalités, les plages numériques, l’appartenance à un ensemble, les tests d’existence et la logique booléenne. Pour les index multi-locataires, le bénéfice est direct : un champ tenant_id résolu en pré-filtrage isole la recherche dans les données d’un seul client avant même le calcul de similarité.
Le flux complet, en trois étapes
La mise en œuvre suit le chemin habituel. On crée l’index en déclarant la dimension du modèle d’embedding et la distance, on écrit les vecteurs avec leurs métadonnées, puis on interroge avec un filtre.
# 1. Créer l’index
aws s3vectors create-index \
--index-name product-catalog \
--vector-bucket-name my-vector-bucket \
--dimension 1536 \
--distance-metric cosine
# 2. Écrire un vecteur avec ses métadonnées
aws s3vectors put-vectors \
--index-name product-catalog \
--vector-bucket-name my-vector-bucket \
--vectors '[{
"key": "doc-001",
"data": {"float32": [0.1, 0.2, 0.3]},
"metadata": {"tenant_id": "t-10428", "category": "legal", "active": true}
}]'
# 3. Interroger avec un filtre combiné
aws s3vectors query-vectors \
--index-name product-catalog \
--vector-bucket-name my-vector-bucket \
--query-vector '{"float32": [0.1, 0.2, 0.3]}' \
--top-k 50 \
--return-metadata \
--filter '{"$and": [{"tenant_id": "t-10428"}, {"category": "legal"}, {"active": true}]}'La dimension doit correspondre à la taille de sortie du modèle d’embedding, et la distance à la façon dont il a été entraîné — cosine est l’usage courant pour les embeddings de texte. En mode ENHANCED, S3 Vectors réduit d’abord l’espace de recherche aux vecteurs qui satisfont les trois conditions, puis renvoie les 50 plus proches de ce sous-ensemble, et non d’un échantillon tiré de l’index entier. C’est la différence entre chercher « dans tout l’index en écartant au passage » et chercher « dans le bon tiroir dès le départ ».
La fonctionnalité est disponible dès maintenant dans toutes les régions où S3 Tables est proposé, sans coût supplémentaire : seule la tarification standard de S3 Vectors s’applique. L’activation passe par la console ou la CLI, et les équipes qui pilotent leur infrastructure via des agents IA peuvent interroger la documentation et les dépannages au travers du serveur MCP d’AWS et de ses plugins. Pour les index existants, la bascule vers ENHANCED est la seule action requise : aucune migration de données, aucun changement de schéma, aucun redéploiement d’application.
Pré-filtrage contre post-filtrage : le dilemme que la fonction tranche
Le choix entre pré-filtrage et post-filtrage n’est pas une nouveauté propre à AWS : il traverse tout l’écosystème des bases vectorielles, de pgvector aux moteurs spécialisés. Chaque approche a son prix. Le post-filtrage garantit qu’aucun vecteur pertinent n’est écarté par une erreur de filtre, mais il dilue la recherche dans l’index entier — et plus l’index est gros, plus les correspondances d’un sous-ensemble précis risquent d’être noyées. Le pré-filtrage réduit l’espace de recherche avant le calcul, donc accélère et remonte davantage, mais il suppose que le filtre lui-même est correct : un filtre mal écrit ne renvoie rien du tout.
Ce que fait S3 Vectors est de rendre ce choix explicite via le mode d’index, plutôt que de l’imposer silencieusement. L’utilisateur garde la main : il peut laisser un index en CLASSIC s’il craint un filtre imparfait, ou passer en ENHANCED dès qu’il a confiance dans ses conditions. Le chiffre « jusqu’à 5× » s’applique aux filtres très sélectifs — typiquement le scénario multi-locataire où un tenant_id isole quelques centaines de vecteurs parmi des millions — et c’est précisément là que le post-filtrage était le plus pénalisant.
Cette bascule élimine aussi un choix d’architecture coûteux. Jusqu’ici, une équipe qui voulait un pré-filtrage fiable devait parfois multiplier les index par client, ou adopter une base vectorielle externe. Le mode ENHANCED rend ce besoin obsolète pour la majorité des cas de RAG et de recherche documentaire scoped, en conservant un seul index et un seul point de vérité.
Verdict
Si vous exploitez un index S3 Vectors multi-locataires ou une recherche documentaire bornée par client, basculez vos index en mode ENHANCED dès maintenant : le gain de rappel peut atteindre 5× sur les filtres sélectifs, l’opération est gratuite, en place et sans ré-ingestion, et vos requêtes n’ont pas à changer. Si vous filtrez rarement ou à très large périmètre, le passage est sans risque mais moins décisif — le pré-filtrage paie surtout quand le filtre réduit fortement l’espace de recherche. Dans tous les cas, vérifiez que votre politique IAM accorde les nouvelles actions liées à la mise à jour du mode d’index avant de lancer la bascule.