AWS a ajouté le skill amazon-opensearch-service à son Agent Toolkit, et je l'ai soumis à un test full-stack en construisant un backend de génération augmentée par récupération (RAG) sur Amazon OpenSearch Serverless NextGen. L'outil réduit considérablement le temps nécessaire pour configurer un cluster OpenSearch de niveau production, mais il échoue encore lorsqu'on demande à un agent IA de configurer la recherche vectorielle dans l'environnement serverless NextGen.
Pourquoi ce skill est important
OpenSearch est désormais la pile technologique par défaut pour les entreprises qui ont besoin de recherche textuelle, d'analyse de logs et, de plus en plus, de recherche de similarité basée sur les vecteurs. La mise en place d'un cluster impose de prendre des dizaines de décisions interdépendantes : politiques de chiffrement, isolation réseau, rôles d'accès aux données, dimensionnement des instances, allocation des shards et, pour les charges de travail vectorielles, le choix du moteur k-NN. Manquez une étape et vous vous retrouvez avec un surprovisionnement coûteux ou un pipeline de recherche défaillant.
Ce nouveau skill promet un agent IA capable de traduire des instructions en langage naturel en la série exacte d'appels API et de fichiers de configuration requis pour un déploiement OpenSearch complet.
Ce qu'est réellement ce skill
Il ne s'agit pas d'un chatbot avec lequel vous pouvez converser. Considérez-le comme une base de connaissances structurée qu'un agent de codage automatisé peut interroger. Le package regroupe :
- Des formules de dimensionnement qui transforment le volume de requêtes attendu et la taille des données en recommandations concrètes de types d'instances et de niveaux de stockage.
- Une logique de sélection du moteur qui fait correspondre les modèles de charge de travail (texte uniquement, hybride, pur vecteur) au moteur k-NN ou à la configuration de recherche hybride appropriés.
- Des check-lists de migration qui mappent les schémas de Solr ou d'Elasticsearch vers leurs équivalents OpenSearch.
- Des recettes de Query DSL qui fournissent des extraits prêts à l'emploi du langage spécifique au domaine (DSL) d'OpenSearch pour les modèles de recherche courants.
Le skill s'articule autour de cinq tâches principales :
- Migration – conversion des schémas Solr/ES existants.
- Provisionnement – calcul de la taille des instances, des niveaux de stockage et des politiques réseau.
- Recherche – sélection des moteurs k-NN, configuration de la recherche hybride et ajustement des paramètres de pertinence.
- Analyse de logs – gestion des requêtes Piped Processing Language (PPL) et des définitions de pipeline.
- Analyse de traces – configuration des collecteurs OpenTelemetry et des pipelines Data Prepper.
Là où il excelle
Lors de mon test, le gain de temps le plus important a été la logique de séquençage des politiques. Le skill connaît l'ordre correct et me fournit une check-list étape par étape, ce qui a considérablement réduit mon temps de configuration.
Pour les domaines gérés classiques, les recommandations du skill sur la mise à niveau des instances et la mathématique des shards correspondent à la configuration réelle du cluster. Il lit le nombre de nœuds actuel, l'utilisation du stockage et la latence des requêtes, puis vous indique si vous avez besoin de plus de shards, d'instances plus grandes ou d'un niveau de stockage différent. Ces conseils contextuels sont habituellement éparpillés dans plusieurs documentations AWS.
Le skill comprend également les indicateurs spécifiques à NextGen tels que le scale-to-zero, qui indique au service serverless de libérer les ressources de calcul lorsque la collection est inactive. En signalant cela correctement, l'outil maintient les coûts bas sans ajustements manuels.
La lacune majeure
La gestion du mappage vectoriel dans NextGen Serverless est encore bloquée sur la logique "Classic". Lorsque j'ai demandé à l'agent de configurer une collection compatible avec les vecteurs, il a suggéré un moteur FAISS. Dans le mode Classic Serverless, vous pouvez choisir un moteur k-NN, mais NextGen l'abstrait : l'accélération vectorielle est gérée automatiquement et vous ne pouvez pas spécifier le moteur. La recommandation est donc totalement erronée.
Une deuxième inexactitude, moins dramatique, concernait les attentes en matière de latence d'écriture. L'assistant a prévenu de délais d'écriture de 30 à 60 secondes, un chiffre qui s'appliquait aux anciens déploiements Classic Serverless. Dans mon test NextGen, les documents sont devenus consultables en environ deux secondes, rendant l'avertissement obsolète.
Ces erreurs sont importantes car de nombreuses équipes adoptent NextGen précisément pour son modèle opérationnel simplifié. Si l'assistant IA impose des paramètres de l'ère Classic à un cluster NextGen, cela peut provoquer des échecs de déploiement ou des cycles de débogage inutiles.
Qui devrait (et ne devrait pas) l'utiliser
Si vous déployez régulièrement des clusters OpenSearch — que ce soit pour de la recherche plein texte, de l'agrégation de logs ou des charges de travail hybrides — ce skill constitue un solide filet de sécurité. Il détecte les oublis courants tels que :
- Oublier d'attacher des politiques de chiffrement avant la création d'une collection.
- Provisionner accidentellement une collection Classic alors qu'une collection NextGen serait moins chère et plus facile à gérer.
- Sélectionner une taille d'instance incapable de supporter de lourdes charges de travail vectorielles.
Pour les équipes dont le besoin principal est la recherche vectorielle pure, la compétence offre peu d'avantages. Le service S3 Vectors d'Amazon offre une voie plus rapide et moins coûteuse pour les pipelines RAG simples, et ne nécessite pas les étapes de provisionnement complexes pour lesquelles la compétence est conçue.
À surveiller ensuite
La compétence est déjà utile, mais sa prochaine itération nécessite deux mises à jour :
- Logique vectorielle compatible NextGen – l'assistant doit reconnaître que la sélection du moteur est inutile et doit plutôt guider l'utilisateur à travers les paramètres qui affectent réellement les performances vectorielles dans le modèle serverless (par exemple, les limites de dimension, la taille des lots).
- Benchmarks de latence actuels – la base de connaissances devrait être actualisée avec les derniers chiffres de latence d'écriture pour Classic et NextGen, afin que les utilisateurs aient des attentes réalistes.
En attendant, considérez la compétence comme un guide, et non comme un remplacement pour un ingénieur OpenSearch chevronné.
À retenir
La compétence amazon-opensearch-service réduit la courbe d'apprentissage pour les configurations OpenSearch complexes et aide à éviter des erreurs de politique coûteuses. Ses lacunes se limitent aux fonctionnalités vectorielles serverless les plus récentes, ce qui signifie qu'elle reste un assistant précieux pour la plupart des charges de travail — à condition de vérifier tout conseil lié aux vecteurs par rapport à la dernière documentation NextGen.