🏠Accueil 📚Certifications 📱Applications Mobiles

🎓Infos examen

✍️Blog 💼Carrières 📊Progrès 📅Calendrier 💬Support

Politique de Confidentialité Conditions d'Utilisation Nous Contacter Politique des Cookies Avertissement Accessibilité DMCA / Droits d'Auteur

Aller au contenu

AIP-C01Guide

Guide - AIP-C01 AWS Certified Generative AI Developer - Professional

Dernière révision : mai 2026

Une référence concise des modèles d'architecture évalués par l'examen AIP-C01. Lisez de haut en bas ou sautez à une section.

Sections

Intégration de modèles de fondation, gestion des données et conformité31 entrées
Mise en œuvre et intégration33 entrées
Sécurité et gouvernance de l'IA24 entrées
Efficacité opérationnelle et optimisation13 entrées
Test, validation et dépannage12 entrées

Intégration de modèles de fondation, gestion des données et conformité

Choisir un modèle de fondation Bedrock pour un cas d'utilisation.

Raisonnement à contexte long + utilisation d'outils → Claude (Sonnet/Opus). Chat optimisé en termes de coûts → Claude Haiku ou Titan Text Lite. Code → Claude ou Llama. Embeddings → Titan Embeddings V2 ou Cohere Embed. Génération d'images → Titan Image, Stable Diffusion ou Nova Canvas. Poids ouverts avec contrôle de l'auto-hébergement → Llama, Mistral ou Custom Model Import.

Pourquoi: Aucun modèle unique n'est le meilleur en termes de coût, de latence, de capacité et de conditions de licence. Faites correspondre la classe de modèle au goulot d'étranglement.

La source de la base de connaissances (KB) est constituée de FAQ courtes et autonomes ou de descriptions de produits (~100 à 500 mots chacune).

Découpage en chunks de taille fixe avec la taille de token par défaut (300) et un chevauchement (20%).

Pourquoi: Les unités autonomes ne bénéficient pas du découpage conscient des limites. La taille fixe est la plus simple et la moins chère.

Les documents contiennent des changements de sujet naturels au sein des paragraphes ; les divisions de taille fixe interrompent les phrases en plein milieu d'une idée.

Découpage sémantique. Les bases de connaissances Bedrock regroupent des phrases consécutives dont les embeddings sont proches, et effectuent des divisions aux frontières de sens.

Pourquoi: Préserve les idées cohérentes à l'intérieur d'un chunk → récupération plus propre, meilleure qualité de réponse.

Manuels techniques longs avec des références croisées entre les sections ; les questions nécessitent une synthèse à travers un document.

Découpage hiérarchique. Bedrock construit des chunks parents (grands) + enfants (petits) ; récupère sur les embeddings des enfants, renvoie le contexte parent.

Pourquoi: Les petits chunks permettent une récupération précise ; le contexte parent préserve les références croisées et les détails environnants.

Les fichiers source sont pré-découpés en chunks ou chaque fichier est intentionnellement une seule unité logique.

Aucune stratégie de découpage. Chaque fichier devient un chunk dans la base de connaissances (KB).

La source PDF contient du texte + des diagrammes ; les utilisateurs posent des questions qui nécessitent de comprendre les diagrammes.

Activer l'analyse avancée de Bedrock KB avec un modèle de fondation (Claude/Nova) comme parseur. Les diagrammes et les tableaux sont décrits via la vision, puis intégrés.

Pourquoi: L'analyse par défaut est textuelle uniquement. L'analyse multimodale convertit le contenu visuel en texte descriptif avant l'intégration.

Choisir Titan Embeddings G1 ou V2.

V2 prend en charge des dimensions configurables (256/512/1024) et surpasse G1 sur les benchmarks multilingues. G1 est fixe à 1536. Choisir V2 pour les cas d'utilisation limités en stockage ou non-anglais ; G1 uniquement pour la compatibilité héritée.

Catalogue de 500 000 produits : titres courts (50 mots) + spécifications longues (500 mots). Optimiser la qualité de recherche + le coût.

Intégrer chaque élément une fois (champs combinés ou séparés). Utiliser Titan Embeddings V2 avec des dimensions réduites (256 ou 512) pour le coût ; intégrer la requête et le document avec le même modèle.

Pourquoi: Mélanger les modèles d'embedding ou ignorer la normalisation perturbe la recherche de similarité. Des dimensions inférieures réduisent le coût de stockage et de requête avec une perte de qualité marginale.

Choisir un magasin vectoriel pour les bases de connaissances Bedrock.

Configuration par défaut / la plus rapide → Amazon OpenSearch Serverless (autogéré). Sous-ms avec mises à jour fréquentes de schéma + jointures relationnelles → Aurora PostgreSQL avec pgvector. Client Pinecone / MongoDB Atlas / Redis existant → le conserver. KB minuscule (<10 000 documents) optimisée en termes de coûts → Aurora pgvector ou Neptune Analytics.

Pourquoi: OpenSearch Serverless est la valeur par défaut la plus simple. Aurora pgvector l'emporte lorsque vous avez besoin de transactions ou de jointures sur les métadonnées.

La base de connaissances (KB) renvoie des documents sémantiquement pertinents, mais ils proviennent de versions obsolètes/de mauvaise région.

Ajouter des métadonnées aux fichiers source (`version`, `region`, `effective_date`) et appliquer des filtres de métadonnées au moment de la requête via `retrievalConfiguration.vectorSearchConfiguration.filter`.

Pourquoi: La pure similarité vectorielle ignore la récence et l'autorité. Le filtrage des métadonnées réduit le pool de candidats avant le classement.

RAG manque les requêtes contenant des identifiants exacts (SKU, codes d'erreur, numéros de réglementation) car la recherche sémantique surpondère le texte de sens similaire.

Activer la recherche hybride sur la base de connaissances (sémantique + mot-clé/BM25). Combine la similarité vectorielle avec la correspondance lexicale pour les ID, les codes et les noms propres.

Top-k=5 récupère 5 chunks mais le plus pertinent est souvent classé 3ème ou 4ème.

Augmenter `numberOfResults` à 20, puis activer un modèle de reranking (Cohere Rerank ou Amazon Rerank) pour réorganiser par pertinence par rapport à la requête originale.

Pourquoi: La similarité d'embedding ≠ pertinence de la tâche. Les rerankers à encodeur croisé voient la requête + le chunk ensemble et les notent précisément.

Les questions des utilisateurs sont conversationnelles, en plusieurs parties, ou contiennent des pronoms/suivis ; la qualité de récupération de la base de connaissances (KB) diminue.

Activer la reformulation des requêtes de la base de connaissances (KB) Bedrock. Le modèle réécrit les requêtes complexes en plusieurs sous-requêtes ciblées avant la récupération.

Les documents source S3 sont mis à jour fréquemment ; la base de connaissances (KB) doit toujours refléter les dernières versions sans synchronisation manuelle.

Configurer la source de données de la base de connaissances (KB) pour une synchronisation automatisée via les notifications d'événements S3 → EventBridge → StartIngestionJob, ou utiliser la synchronisation planifiée de la KB. Éviter de dépendre du bouton "Sync" manuel de la console.

Le modèle QA à document long hallucine sur les questions dont les réponses se trouvent au milieu du document.

Ne pas passer des documents entiers dans le prompt - découper en chunks + récupérer via RAG afin que seuls les chunks pertinents atteignent le modèle. Si le document entier est obligatoire, utiliser un modèle avec une forte capacité de rappel de contexte long (Claude Sonnet 200K) et placer la question après le document.

Pourquoi: La plupart des LLM présentent une dégradation du rappel "perdu au milieu". RAG contourne ce problème ; le placement aide lorsque RAG n'est pas disponible.

Choisir la personnalisation la moins chère qui répond aux exigences de qualité.

Essayer dans l'ordre : (1) ingénierie de prompt, (2) RAG avec base de connaissances (KB), (3) fine-tuning, (4) pré-entraînement continu, (5) Custom Model Import. S'arrêter à la première qui satisfait les exigences.

Pourquoi: L'effort et le coût continu augmentent à chaque étape. Le fine-tuning + Provisioned Throughput est beaucoup plus cher que RAG.

Fine-tuner un modèle Bedrock avec des exemples de tâches étiquetés.

Fichier JSONL dans S3 avec un exemple par ligne : `{"prompt": "...", "completion": "..."}` (ou équivalent au format chat pour la famille de modèles).

Pourquoi: Chaque famille de modèles (Titan, Claude, Llama) a un schéma spécifique ; vérifier la documentation de fine-tuning du modèle avant de formater.

Adapter un modèle de fondation à un vocabulaire spécialisé (juridique, médical, scientifique) en utilisant de nombreux textes de domaine non étiquetés.

Pré-entraînement continu sur le corpus de domaine non étiqueté. Différent du fine-tuning d'instructions (qui nécessite des paires prompt-complétion).

Pourquoi: Le pré-entraînement continu met à jour la compréhension du langage ; le fine-tuning d'instructions enseigne le comportement de la tâche. Forme de données différente, objectif différent.

Les données d'interaction client pour le fine-tuning contiennent des noms, des e-mails, des numéros de téléphone.

Nettoyer ou tokeniser les PII avant de télécharger l'ensemble de données d'entraînement vers S3. Une fois que les poids absorbent les PII, le filtrage de sortie ne peut pas les masquer de manière fiable.

Pourquoi: Le modèle fine-tuné peut régurgiter des fragments de données d'entraînement. Le nettoyage au niveau de la couche de données est la seule atténuation durable.

Apporter un modèle Llama ou Mistral auto-fine-tuné et le servir via l'API unifiée de Bedrock.

Importation de modèle personnalisé (Custom Model Import). Télécharger les poids vers S3, les enregistrer auprès de Bedrock, les invoquer via le runtime Bedrock avec IAM et logging unifiés.

Pourquoi: Permet de réutiliser les Guardrails, les bases de connaissances (KB) et les Agents Bedrock sur vos propres poids sans avoir à déployer des points de terminaison SageMaker.

Déployer un modèle Bedrock fine-tuné en production.

Acheter un débit provisionné (Provisioned Throughput). Les modèles personnalisés (fine-tunés, pré-entraînés en continu, importés) ne peuvent pas être invoqués à la demande.

Une application Claude à fort trafic atteint les quotas par région pendant les pics ; besoin d'un débit plus élevé sans acheter de débit provisionné (Provisioned Throughput).

Profils d'inférence inter-régions. Bedrock route les invocations à travers plusieurs régions de manière transparente pour augmenter les quotas TPM/RPM effectifs.

Pourquoi: Les quotas à la demande d'une seule région plafonnent pendant les pics ; les profils inter-régions multiplient approximativement les quotas sans modification du code de l'application au-delà de l'utilisation de l'ARN du profil d'inférence.

Les utilisateurs de l'APAC constatent une latence significativement plus élevée que les utilisateurs US/EU sur une application Bedrock déployée en us-east-1.

Déployer des points de terminaison Bedrock régionaux dans ap-northeast-1 / ap-southeast-1 / ap-south-1 (là où le modèle est GA). Router les utilisateurs via la politique de latence ou de géolocalisation de Route 53.

Pourquoi: Le temps d'aller-retour des LLM domine pour les contextes longs ; le RTT trans-Pacifique seul est de 150 à 250 ms.

Une application réglementée par la HIPAA doit résumer des informations de santé protégées (PHI) avec Bedrock.

Utiliser uniquement des modèles de fondation éligibles HIPAA (selon la liste des services éligibles HIPAA). Signer un BAA avec AWS. Chiffrer les prompts/réponses avec des clés KMS gérées par le client. Désactiver la journalisation des invocations de modèle ou la restreindre à un compartiment S3 privé avec un accès restreint.

Décider quelles données peuvent transiter vers Bedrock en fonction de leur sensibilité (publique / confidentielle / restreinte).

Public → non restreint. Confidentiel → uniquement via les points de terminaison VPC + clés de chiffrement gérées par le client (CMK) + journalisation des invocations dans des compartiments privés. Restreint (secrets commerciaux, PHI/PCI réglementées) → bloquer entièrement l'accès à Bedrock ou utiliser un régime de conformité éligible à Bedrock + rédiger avant l'invocation.

Une organisation multi-comptes souhaite que le Compte A partage un modèle Bedrock personnalisé avec le Compte B sans copier les poids.

Partage de modèle personnalisé via AWS RAM. Le propriétaire partage l'ARN du modèle personnalisé ; les comptes consommateurs l'invoquent via le runtime Bedrock standard avec des principaux IAM inter-comptes sur la politique de ressource.

Pourquoi: Évite les coûts de fine-tuning redondants et centralise le cycle de vie du modèle. RAM contrôle qui peut consommer la ressource partagée.

Besoin d'un modèle tiers de niche (par exemple, un LLM spécialisé dans la santé) qui ne figure pas dans le catalogue Bedrock standard.

Amazon Bedrock Marketplace. S'abonner au modèle depuis le catalogue Marketplace, le déployer sur un point de terminaison Bedrock, l'invoquer via l'API runtime standard.

Pourquoi: Unifie la facturation tierce, IAM, KMS et l'observabilité avec les modèles Bedrock de première partie.

Une application de recherche à fort volume ré-intègre les mêmes documents à chaque rafraîchissement de requête ; le coût d'embedding domine.

Pré-calculer les embeddings lors de l'ingestion de documents, stocker le vecteur dans DynamoDB ou OpenSearch indexé par l'ID du document + le hachage du contenu. Ré-intégrer uniquement lorsque le hachage du contenu change.

Pourquoi: L'embedding répété du même texte est le coût évitable le plus courant. Un cache basé sur le hachage permet un saut en O(1).

Droit à l'oubli GDPR sur un modèle fine-tuné : un utilisateur demande la suppression de ses PII des données d'entraînement.

Supprimer les enregistrements du corpus d'entraînement, puis fine-tuner un nouveau modèle de base à partir de zéro. Il n'est pas possible de nettoyer de manière fiable les données des poids existants - le filtrage de sortie n'est pas suffisant.

Pourquoi: Une fois que les poids absorbent les données d'entraînement, le masquage à l'inférence n'est pas fiable. La voie défendable est le ré-entraînement complet sans les enregistrements concernés.

Une base de connaissances (KB) partagée dessert plusieurs équipes ; chaque équipe ne doit voir que ses propres documents.

Étiqueter chaque chunk avec les métadonnées `tenant_id` / `team_id` / `clearance` lors de l'ingestion. Au moment de la requête, définir `retrievalConfiguration.vectorSearchConfiguration.filter` aux valeurs autorisées de l'appelant à partir de la session IAM ou du contexte de l'application.

Pourquoi: La similarité vectorielle ignore le contrôle d'accès ; le filtrage des métadonnées est la seule isolation durable par tenant dans une base de connaissances (KB) partagée.

Un client de l'UE exige que les prompts et les embeddings de la base de connaissances (KB) ne quittent jamais eu-west-1.

Déployer Bedrock + KB + compartiment source S3 en eu-west-1. Épingler les invocations via l'ARN du profil d'inférence ciblé sur eu-west-1 ; SCP `aws:RequestedRegion` refuser sur d'autres régions pour `bedrock:*`.

Mise en œuvre et intégration

Un workflow multi-étapes nécessite le raisonnement d'un LLM, des appels à des API/bases de données externes et une synthèse.

Agent Amazon Bedrock. Définir des instructions, des groupes d'actions (Lambda + schéma OpenAPI) et une base de connaissances (KB) facultative. L'agent planifie, invoque des outils et assemble les résultats.

Pourquoi: Évite d'écrire la boucle d'orchestration vous-même. Trace intégrée, mémoire de session et points d'accroche de retour de contrôle.

L'agent Bedrock doit appeler trois API internes (CRM, inventaire, paiements).

Définir un groupe d'actions par API. Chaque groupe d'actions possède un schéma OpenAPI décrivant ses opérations et une fonction Lambda (ou un point de terminaison de retour de contrôle) qui exécute les appels.

L'agent doit effectuer des opérations à haut risque (suppression de compte, remboursements importants) uniquement après confirmation humaine/commerciale.

Configurer le groupe d'actions avec le Retour de Contrôle (RoC). Bedrock renvoie l'action proposée à l'application au lieu de l'invoquer ; l'application bloque l'exécution en attente d'approbation et soumet à nouveau les résultats.

Pourquoi: Maintient les étapes à haut risque en dehors du runtime de l'agent afin qu'elles puissent être auditées ou confirmées manuellement avant leur exécution.

L'agent doit se souvenir du contexte à travers les tours au sein d'une même session utilisateur.

Utiliser les attributs de session intégrés de l'agent et les attributs de session de prompt. Passer `sessionId` à InvokeAgent - Bedrock conserve l'état de la conversation pendant le délai d'inactivité configuré.

L'agent doit se souvenir de faits concernant un utilisateur récurrent à travers les sessions (préférences, historique) et résumer les échanges plus anciens.

Activer la mémoire de l'agent Bedrock. L'agent persiste l'historique de session résumé par `memoryId` et le rejoue comme contexte lors des invocations futures.

Un workflow nécessite des agents spécialisés (recherche, code, facturation) coordonnés par un planificateur de haut niveau.

Collaboration multi-agent des agents Bedrock : définir un agent superviseur et plusieurs agents collaborateurs. Le superviseur délègue les sous-tâches en fonction des descriptions des collaborateurs et synthétise les résultats.

Besoin d'un pipeline multi-étapes : extraire → classer → router → résumer, avec des branches conditionnelles.

Amazon Bedrock Prompt Flows. Workflow visuel avec des nœuds de prompt, des nœuds de condition, des nœuds de base de connaissances (KB), des nœuds Lambda ; versionné et invocable comme une seule API.

Pourquoi: Remplace les Step Functions écrites à la main pour les pipelines de prompt et expose un seul point d'entrée.

SaaS multi-tenant : prompts système par tenant, préférences de modèle et versionnement.

Gestion des prompts Amazon Bedrock. Stocker les prompts comme des actifs versionnés et paramétrés ; les référencer par ARN au runtime ; effectuer des tests A/B sur différentes versions par tenant.

L'application doit fonctionner avec Claude, Llama, Titan et Cohere avec une seule interface API de type chat.

Utiliser l'API Bedrock Converse. Format de liste de messages unifié, utilisation d'outils et prompts système pour toutes les familles de modèles. Éviter le JSON InvokeModel spécifique au modèle lorsque la portabilité est importante.

Le chatbot doit afficher les réponses token par token pour réduire la latence perçue.

ConverseStream (ou InvokeModelWithResponseStream). Associer à API Gateway WebSocket ou aux abonnements AppSync pour diffuser les tokens au navigateur.

Chat de support client en temps réel : streaming de réponses, 500 utilisateurs concurrents, historique de conversation.

Navigateur ↔ API Gateway WebSocket ↔ Lambda ↔ Bedrock ConverseStream. Persister la conversation dans DynamoDB indexée par `sessionId` et la recharger à chaque tour.

Pourquoi: WebSocket évite le polling HTTP ; le stockage de session DynamoDB survit à l'absence d'état de Lambda.

Besoin que le modèle décide quand appeler des fonctions (recherche de base de données, calculatrice, API).

Utiliser l'API Converse pour l'utilisation d'outils (`toolConfig`) - déclarer les outils avec un nom + un schéma JSON ; le modèle émet des blocs `toolUse` ; l'application exécute et renvoie `toolResult`. Fonctionne avec Claude, Llama, Mistral, Cohere Command R.

Nouveau ticket dans un système tiers → analyse automatique par Bedrock (sentiment, urgence, catégorie) → routage.

Webhook → API Gateway → EventBridge → cible Lambda → Bedrock. EventBridge découple les producteurs des consommateurs et offre gratuitement la réessai + la DLQ.

Plusieurs microservices soumettent des requêtes de génération Bedrock ; les consommateurs n'ont pas besoin des résultats immédiatement.

Producteurs → SQS → consommateur Lambda (ou ECS) → Bedrock InvokeModel → stocker le résultat dans S3/DynamoDB. SQS atténue les pics et gère les échecs de réessai dans les limites des quotas de service.

Générer des descriptions pour 100 000 SKU chaque nuit ; tolérant à la latence ; vouloir le coût le plus bas.

Inférence par lots Amazon Bedrock (Batch Inference). Soumettre un fichier JSONL d'entrée dans S3, Bedrock exécute la tâche avec un coût par token jusqu'à 50 % inférieur par rapport à l'utilisation à la demande, et écrit le fichier JSONL de sortie.

Pourquoi: Le traitement par lots échange la latence contre le coût. L'utiliser chaque fois que les résultats ne sont pas nécessaires en temps réel.

API Gateway devant Lambda + Bedrock renvoie un timeout 504 Gateway sur les générations longues.

Le timeout d'intégration REST d'API Gateway est plafonné à 29 secondes. Passer à un modèle asynchrone (retourner l'ID de tâche, sonder via un second endpoint) ou à API Gateway WebSocket + ConverseStream afin que les tokens partiels s'écoulent avant la fenêtre de timeout.

Générer des descriptions de produits à partir d'une image de produit + un texte bref.

Utiliser un modèle Bedrock capable de vision (Claude 3+ Sonnet, Nova) via l'API Converse avec des blocs de contenu `image` à côté du texte.

Traduction de messages en anglais en moins d'une seconde avec une haute qualité.

Modèle de fondation (Claude Haiku ou Llama petit) via Bedrock pour la nuance, OU Amazon Translate pour la vitesse/le coût lorsque la traduction littérale est suffisante. Bedrock pour la prise en compte du contexte ; Translate pour le transactionnel.

Déplacer progressivement le trafic de production du Modèle A vers le Modèle B avec une capacité de coupe-circuit.

Drapeau de fonctionnalité AWS AppConfig contenant l'identifiant du modèle actif et la répartition du trafic. Lambda lit le drapeau par invocation, achemine en conséquence. Revenir en arrière instantanément via le rollback de déploiement AppConfig.

Décider entre Bedrock et SageMaker JumpStart pour héberger un modèle de fondation.

Bedrock lorsque vous souhaitez une inférence gérée, une API unifiée, des bases de connaissances (KB)/Agents/Guardrails. SageMaker JumpStart lorsque vous avez besoin d'un point de terminaison privé hébergé dans un VPC avec un contrôle réseau/IAM complet ou un modèle à poids ouverts non disponible dans Bedrock.

Choisir le style de définition de groupe d'actions : spécification OpenAPI 3.0 vs schéma de fonction.

OpenAPI lorsque l'API sous-jacente possède déjà une spécification OpenAPI 3.0 ou lorsque vous avez besoin d'une sémantique HTTP complète (chemins, méthodes, types de paramètres). Schéma de fonction pour les actions inline/légères définies via de simples déclarations de propriétés JSON.

Pourquoi: OpenAPI est canonique pour les API REST existantes. Le schéma de fonction est plus rapide pour les nouvelles aides internes à l'agent.

L'agent doit effectuer des calculs précis, des analyses statistiques ou exécuter de petits extraits de code Python pour répondre aux questions.

Activer l'interpréteur de code des agents Bedrock. L'agent exécute Python dans un environnement sandbox géré ; les résultats sont réintégrés dans la synthèse de la réponse.

Pourquoi: Les LLM ne sont pas fiables pour les calculs exacts ; un runtime sandboxé donne des résultats numériques déterministes sans écrire de groupes d'actions personnalisés.

Les prompts d'agent par défaut produisent des réponses verbeuses ; besoin de resserrer le prompt d'orchestration pour la production.

Configurer des remplacements de modèles de prompt sur l'agent pour chaque étape (pré-traitement, orchestration, génération de réponse de la base de connaissances (KB), post-traitement). Les remplacements sont versionnés avec l'agent.

Itérer sur un agent en développement pendant que le trafic de production reste sur une version stable.

Utiliser les versions et alias d'agent. `DRAFT` pour les éditions actives ; publier des versions numérotées ; router via des alias (`prod` → version 7, `dev` → DRAFT). Promouvoir en mettant à jour l'alias.

L'agent choisit le mauvais groupe d'actions ; besoin de déboguer le raisonnement étape par étape.

Activer la trace sur InvokeAgent (`enableTrace: true`). Le flux de réponse inclut les blocs `preProcessingTrace`, `orchestrationTrace`, `postProcessingTrace` et `failureTrace` affichant la logique du modèle, la sélection d'outils et les entrées.

Construire un flux Bedrock pour "extraire les entités → rechercher dans la KB → résumer → envoyer un e-mail".

Composer les nœuds : nœud de prompt (extraire), nœud de base de connaissances (rechercher), nœud de prompt (résumer), nœud Lambda (envoyer un e-mail via SES). Utiliser des nœuds d'entrée/sortie S3 pour les flux par lots ; des nœuds de condition pour le branchement.

Choisir entre Bedrock Flows et Step Functions pour un pipeline GenAI multi-étapes.

Bedrock Flows lorsque les étapes sont principalement des primitives Bedrock (prompts, KBs, agents) - invocation API unique, pas de colle IAM supplémentaire. Step Functions lorsque le workflow s'étend sur de nombreux services AWS avec des réessais, des branches parallèles, une gestion d'erreurs complexe ou des attentes de longue durée.

Implémenter une boucle de chat où le modèle appelle itérativement des outils, puis formule la réponse finale.

Modèle : envoyer le message utilisateur → le modèle renvoie `toolUse` → l'application exécute l'outil → l'application renvoie `toolResult` via Converse → boucler jusqu'à ce que le modèle renvoie le texte final. Limiter les itérations pour éviter les boucles infinies.

Pourquoi: Le modèle décide quand il a suffisamment d'informations pour s'arrêter ; l'application doit piloter la boucle et appliquer une limite de pas maximale.

Le modèle doit rechercher le client + la commande + l'inventaire ; les appels d'outils séquentiels ajoutent 3× de latence.

Les modèles qui prennent en charge l'utilisation d'outils parallèles (Claude 3+, Nova) émettent plusieurs blocs `toolUse` en un seul tour. Les exécuter concurremment dans l'application et renvoyer tous les `toolResult` avant la prochaine inférence.

Persister l'état de chat multi-tours à travers des invocations Lambda sans état avec un nettoyage automatique des sessions obsolètes.

Table DynamoDB indexée par `sessionId` stockant `messages` + `lastActivity`. Définir l'attribut TTL (`expiresAt`) pour supprimer automatiquement les sessions de plus de 24 heures. Lambda lit/écrit à chaque tour.

Le chat voit environ 1000 QPS ; les lectures DynamoDB par tour sur l'historique de session sont un point chaud.

Placer ElastiCache pour Redis devant DynamoDB. Mettre en cache les N derniers messages par session dans un hachage Redis ; écrire en mode write-through vers DynamoDB pour la durabilité. Utiliser des clés Redis avec TTL pour limiter la mémoire.

Une nouvelle tentative sur un appel Bedrock InvokeModel risque de facturer deux fois la même requête logique.

Générer une clé d'idempotence par requête logique (par exemple, UUID v5 de l'entrée + utilisateur). Mettre en cache la réponse indexée par la clé d'idempotence dans DynamoDB ou ElastiCache ; retourner la réponse mise en cache en cas de nouvelle tentative.

Pourquoi: Bedrock lui-même n'est pas idempotent - la même entrée est facturée à chaque appel. Le cache au niveau de l'application est la seule solution d'idempotence.

Exécuter deux versions de modèle en production pendant la migration sans basculer tous les utilisateurs en même temps.

Hacher l'ID utilisateur dans N buckets ; router le bucket i vers le modèle A ou le modèle B en fonction d'un drapeau de fonctionnalité (AppConfig / Parameter Store). Surveiller les métriques côte à côte ; modifier l'affectation des buckets pour avancer ou reculer.

Sécurité et gouvernance de l'IA

Le chatbot en contact avec les clients doit bloquer les contenus nuisibles, les sujets interdits et les fuites d'informations personnelles identifiables (PII).

Amazon Bedrock Guardrails. Configurer les sujets interdits, les filtres de contenu (haine, violence, sexe, insultes, faute professionnelle), les filtres de mots, les filtres d'informations sensibles (rédaction de PII) et les vérifications de mise à la terre contextuelle. Appliquer à l'entrée et à la sortie d'InvokeModel.

Pourquoi: Les Guardrails sont agnostiques au modèle et appliqués dans les deux directions ; ils survivent à tout remplacement de modèle.

Le Guardrail bloque des réponses financières légitimes qui mentionnent des montants en dollars.

Diminuer le niveau de sensibilité sur le filtre de contenu affecté (par exemple, `MEDIUM` → `LOW`) et/ou supprimer les formulations de sujets interdits trop larges. Retester par rapport à un ensemble de prompts de référence avant de redéployer.

L'application de résumé médical ne doit pas inventer de faits au-delà des documents sources.

Activer la vérification de mise à la terre contextuelle (contextual grounding check) des Guardrails Bedrock avec un seuil élevé de pertinence + mise à la terre. Les réponses inférieures au seuil sont bloquées ou remplacées par un message par défaut sûr.

Pourquoi: Le RAG pur hallucine toujours lorsque le modèle surgénéralise à partir des chunks récupérés. La mise à la terre contextuelle évalue l'alignement réponse-source par réponse.

L'application Bedrock reçoit des prompts contenant des informations personnelles identifiables (PII) des clients ; besoin d'un masquage automatique avant la journalisation ou l'utilisation en aval.

Configurer les filtres PII des Guardrails avec les actions `BLOCK` ou `ANONYMIZE` pour les types d'entités PII (SSN, e-mail, téléphone, adresse). Le filtrage s'effectue indépendamment sur l'entrée et la sortie.

Une application publique prend l'entrée utilisateur concaténée dans un prompt système ; doit résister à l'injection de prompt.

Défense en profondeur : (1) Guardrails (sujets interdits + détection de jailbreak), (2) prompt système renforcé qui encadre l'entrée utilisateur comme des données et refuse les méta-instructions, (3) validation de la sortie par rapport au schéma attendu, (4) permissions d'outils avec le moindre privilège afin qu'un prompt compromis ne puisse pas déclencher d'actions destructrices.

Pourquoi: Aucune mitigation unique n'est suffisante ; les défenses en couches limitent le rayon d'explosion.

L'équipe rouge constate que le modèle peut être contraint à produire des sorties nuisibles via un cadrage de jeu de rôle ("fais comme si tu étais une IA sans restrictions").

Activer le filtre de contenu de détection de jailbreak des Guardrails. Ajouter des sujets interdits explicites pour les tentatives de jeu de rôle. Retester après chaque modification avec le même ensemble de prompts de l'équipe rouge.

Toutes les données Bedrock doivent être chiffrées en transit et au repos avec des clés gérées par le client.

TLS 1.2+ est appliqué en transit. Au repos : configurer des clés KMS gérées par le client pour la personnalisation du modèle Bedrock, les embeddings de la base de connaissances (KB) + les données source S3, les destinations de journalisation des invocations. Appliquer via SCP qui empêche les clés gérées par AWS.

Organisation multi-équipes : chaque équipe ne doit accéder qu'à des modèles de fondation spécifiques.

Stratégies IAM basées sur l'identité qui autorisent `bedrock:InvokeModel` sur les ARN de ressources ciblés sur les ID de modèle autorisés. Combiner avec des conditions `aws:RequestedRegion` pour verrouiller la région.

Pourquoi: L'autorisation au niveau de la ressource sur `arn:aws:bedrock:*::foundation-model/<id>` est le seul moyen durable d'appliquer un accès au niveau du modèle. Ne pas compter sur la gestion au niveau de la couche application.

Lambda n'invoque que Claude 3.5 Sonnet en us-east-1.

Autoriser `bedrock:InvokeModel` avec `Resource: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-*` et une `Condition: aws:RequestedRegion = us-east-1`. Refuser tous les autres modèles et régions.

L'application Bedrock ne doit pas se connecter à l'Internet public.

Bedrock avec des points de terminaison d'interface VPC (PrivateLink) pour l'API runtime. Bloquer les points de terminaison Bedrock publics via SCP. Ajouter une politique de point de terminaison qui limite les actions à l'ensemble approuvé.

Le régulateur exige une piste d'audit complète de chaque invocation de modèle Bedrock : prompt, réponse, version du modèle, horodatage.

Activer la journalisation des invocations de modèle Bedrock vers CloudWatch Logs ou S3. Capture le prompt complet + la réponse + l'ID du modèle + l'horodatage. Associer à CloudTrail pour la couche de métadonnées des appels API (qui/quand/d'où).

Pourquoi: CloudTrail capture uniquement les métadonnées ; la journalisation des invocations capture le contenu. La conformité exige généralement les deux.

Déterminer la part de responsabilité de l'entreprise en matière de sécurité pour un déploiement Bedrock.

Matrice de délimitation de la sécurité de l'IA générative AWS. Portée 1 (SaaS grand public) → Portée 5 (modèle auto-entraîné sur données privées). Bedrock avec des modèles de fondation à la demande est généralement de Portée 2 ; KB/Agent + RAG pousse vers la Portée 3 ; fine-tuning Portée 4 ; Custom Model Import Portée 5.

Protéger le point de terminaison API GenAI derrière API Gateway contre les abus.

AWS WAF avec des règles basées sur le débit (par IP), un ensemble de règles gérées de contrôle des bots et une règle personnalisée de correspondance de chaînes sur les phrases suspectes de jailbreak. Bloquer les schémas courants de DDoS de LLM (inondations de prompts longs).

Trouver des informations personnelles identifiables (PII) ou d'autres données sensibles dans les corpus source S3 avant qu'elles n'entrent dans une base de connaissances (KB) ou une tâche de fine-tuning.

Tâche de découverte planifiée Amazon Macie sur les compartiments S3 pertinents. Les découvertes sont envoyées à Security Hub / EventBridge pour une rédaction ultérieure.

Détecter les images générées par l'IA en aval pour la provenance du contenu.

Utiliser Titan Image Generator (ou Nova Canvas) - les sorties incluent un filigrane invisible. Vérifier avec l'API de détection de filigrane Bedrock.

Le chatbot marketing ne doit pas nommer de concurrents et ne doit pas faire d'affirmations non fondées.

Sujets interdits des Guardrails : liste explicite des noms de concurrents + "affirmations de produits non vérifiées" au niveau du sujet. Ajouter un filtre de mots pour les affirmations absolues ("garanti", "meilleur", "100%").

Appliquer un Guardrail Bedrock aux sorties d'un modèle non Bedrock (par exemple, un point de terminaison SageMaker auto-hébergé).

Appeler l'API autonome `ApplyGuardrail` avec le texte + l'ID du guardrail + la version. Renvoie si le contenu a été bloqué ou modifié, et quels filtres ont été déclenchés.

Pourquoi: Découple les Guardrails du modèle. Utiliser comme pré-vérification sur l'entrée utilisateur ou post-vérification sur toute sortie de modèle.

Une seule politique de Guardrail doit s'appliquer à us-east-1, eu-west-1 et ap-southeast-1.

Recréer le même guardrail (même configuration) dans chaque région. Les Guardrails sont des ressources régionales ; utiliser l'IaC (CloudFormation / CDK / Terraform) pour maintenir les configurations synchronisées.

Pourquoi: Il n'y a pas de réplication inter-régionale gérée pour les Guardrails. L'IaC est la seule solution de cohérence durable.

Un attaquant empoisonne des documents dans une base de connaissances (KB) publique afin que l'agent divulgue le prompt système ou des données lors de leur récupération.

Traiter le contenu récupéré de la base de connaissances (KB) comme non fiable : activer les Guardrails sur les entrées ET les sorties, assainir les chunks récupérés via la détection d'injection de prompt ou la correspondance de motifs, appliquer le moindre privilège sur les groupes d'actions de l'agent afin qu'un prompt compromis ne puisse pas escalader.

Pourquoi: L'injection indirecte contourne le filtrage d'entrée - le prompt malveillant arrive via le contexte récupéré, et non le message de l'utilisateur.

Besoin d'un accès au modèle par utilisateur sur une application multi-tenant avec un rôle backend unique.

Transmettre les attributs utilisateur comme tags de session lors d'AssumeRole. Les référencer via les conditions `aws:PrincipalTag/<key>` dans la politique d'identité Bedrock pour contrôler `bedrock:InvokeModel` par utilisateur.

Choisir la destination pour la journalisation des invocations Bedrock.

CloudWatch Logs pour les prompts/réponses courts, les requêtes rapides Logs Insights, les applications à plus petite échelle. S3 pour les gros volumes, les charges utiles importantes (KB + traces d'agent), la rétention à long terme, l'analyse en aval avec Athena/Glue. Utiliser S3 si une seule réponse peut dépasser 256 KB.

Pourquoi: CloudWatch Logs a des limites de taille par événement ; S3 n'en a pas. Choisir en fonction de la taille de la charge utile et du modèle d'analyse.

Protéger une API de chat publique contre les attaques DDoS et les abus de flood de tokens à grande échelle.

AWS Shield Standard est activé par défaut ; activer Shield Advanced sur les points de terminaison critiques pour les protections L7 + le support SRT 24/7. Associer à des règles basées sur le débit de WAF et à CloudFront pour l'absorption en périphérie.

L'application de génération d'images doit bloquer les images sexuellement explicites, violentes ou haineuses.

Filtres de contenu d'image Bedrock Guardrails sur l'entrée (images téléchargées) et la sortie (images générées). Les filtres classifient le contenu visuel avec des seuils HAUT/MOYEN/BAS.

Workflow avant le fine-tuning d'un modèle Bedrock sur des transcriptions de support client.

Pipeline : source S3 → tâche de découverte Macie pour identifier les PII → détection + rédaction de PII Comprehend (ou Glue avec regex) → jeu de données nettoyé vers un préfixe S3 séparé → fine-tuning Bedrock. Les échecs de Macie déclenchent EventBridge → SNS vers l'équipe de sécurité d'astreinte.

Pourquoi: Une fois que les données sont intégrées aux poids, leur suppression nécessite un ré-entraînement. La rédaction pré-vol est beaucoup moins chère que le ré-entraînement post-incident.

Efficacité opérationnelle et optimisation

Choisir entre à la demande et débit provisionné (Provisioned Throughput).

Trafic variable / inconnu → à la demande. Grand volume constant avec SLA de débit garanti → Débit provisionné (unités de modèle, engagement de 1 ou 6 mois). Modèles personnalisés (fine-tunés, importés) → le débit provisionné est obligatoire.

Pourquoi: L'option à la demande est par token, sans engagement. PT est par heure, capacité dédiée, environ 50 % moins cher par token à forte utilisation.

L'application réutilise le même prompt système de 4 000 tokens pour toutes les interactions utilisateur ; seul le message utilisateur change.

Activer le caching de prompt Bedrock. Marquer le préfixe statique comme cacheable ; les invocations ultérieures évitent de le re-traiter pendant une durée de vie du cache d'environ 5 minutes, réduisant le coût par appel d'environ 90 % sur les tokens mis en cache.

De nombreux utilisateurs posent des questions similaires mais non identiques ; veulent mettre en cache les réponses à travers des paraphrases.

Intégrer la requête utilisateur et rechercher les voisins les plus proches dans un cache vectoriel (DynamoDB + ElastiCache, ou OpenSearch) au-dessus d'un seuil de similarité. Succès du cache → retourner la réponse stockée. Échec du cache → invoquer Bedrock et réécrire.

Pourquoi: Les caches clé-valeur standard manquent les paraphrases. La similarité sémantique capture l'intention.

Réduire le coût par appel sur une application Bedrock.

Resserrez le prompt système, supprimez les exemples "few-shot" redondants, définissez `maxTokens` explicites sur la sortie, utilisez des séquences d'arrêt pour terminer tôt. Choisissez un modèle plus petit si la qualité le permet.

Pourquoi: Le coût est à peu près proportionnel au nombre total de tokens traités. Les tokens de sortie sont généralement plus chers que les tokens d'entrée - limiter la sortie est très efficace.

Complétion de code : latence inférieure à la seconde, coût équilibré, volume de requêtes élevé.

Claude Haiku (ou Nova Micro / Llama petit) sur Bedrock. Éviter Opus ou les grands modèles Llama pour les chemins de complétion de tokens sensibles à la latence.

La base de connaissances (KB) contient 500 000 documents mais seulement ~200 requêtes/jour ; minimiser le coût.

Aurora PostgreSQL Serverless v2 avec pgvector. S'adapte à des ACU presque nulles au repos ; le modèle de paiement par requête surpasse les planchers OCU d'OpenSearch Serverless toujours actifs à faible QPS.

La base de connaissances (KB) OpenSearch Serverless a une latence de requête de 800 ms ; besoin de <200 ms.

Augmenter le plancher d'unités de capacité OpenSearch (OCU) sur la collection de recherche (plus de calcul = plus de vecteurs mis en cache). Réduire la dimension de l'embedding, augmenter `top-k` de manière stricte, élaguer les métadonnées, activer la mise en cache des résultats au niveau de l'application.

Tâches de fine-tuning de longue durée qui tolèrent l'interruption ; minimiser le coût.

Pour le fine-tuning SageMaker, utiliser le Managed Spot Training (jusqu'à 90 % de réduction). Le fine-tuning natif de Bedrock est uniquement à la demande - choisir SageMaker JumpStart pour la formation personnalisée éligible aux instances Spot lorsque le budget est le facteur dominant.

Allouer les dépenses Bedrock entre les équipes ou les gammes de produits.

Appliquer des balises d'allocation de coûts aux ressources Bedrock (débit provisionné, modèles personnalisés, piles d'applications). Activer les balises dans Facturation → Balises d'allocation de coûts. Les rapports sont détaillés par balise.

Surveiller la latence d'invocation Bedrock, le volume de tokens et les erreurs.

Métriques CloudWatch sous `AWS/Bedrock` : `InvocationLatency`, `InputTokenCount`, `OutputTokenCount`, `Invocations`, `InvocationClientErrors`, `InvocationServerErrors`, `InvocationThrottles`. Définir des alarmes sur la latence p95 et les taux d'erreur.

~100 conversations/jour, FAQ simple ; minimiser le coût.

Bedrock à la demande avec le plus petit modèle compétent (Titan Text Lite, Claude Haiku ou Nova Micro). Lambda + API HTTP API Gateway. Pas de base de connaissances (KB) si la FAQ tient dans le prompt système ; petite KB sur Aurora pgvector si nécessaire.

Dimensionner le débit provisionné (Provisioned Throughput) pour une charge de travail Bedrock en régime stable.

Mesurer le pic de tokens d'entrée + sortie par seconde sur le trafic fantôme. Bedrock publie le débit unitaire par modèle ; provisionner `ceil(pic TPS / TPS par unité)` unités. Valider avec le trafic fantôme avant de s'engager.

Pourquoi: Un sous-provisionnement entraîne une limitation ; un sur-provisionnement gaspille l'engagement horaire. Le dimensionnement empirique sur le trafic fantôme est la seule approche fiable.

Allouer le coût Bedrock par application ou équipe dans un compte partagé.

Créer des profils d'inférence d'application par application, attacher des balises d'allocation de coûts (par exemple, `application=chatbot-X`, `team=marketing`). Chaque invocation référence l'ARN du profil ; Cost Explorer détaille les dépenses par balise.

Test, validation et dépannage

Comparer trois modèles de fondation sur une tâche de résumé ; souhaiter une évaluation automatisée et reproductible.

Tâches d'évaluation de modèle Amazon Bedrock (automatiques). Fournir un jeu de données de prompts ; Bedrock exécute chaque modèle et rapporte les scores BLEU, ROUGE, BERTScore ainsi que la toxicité / précision le cas échéant.

Les scores ROUGE semblent élevés mais les lecteurs humains disent que les résumés manquent des points clés.

Passer à l'évaluation basée sur l'humain de Bedrock avec des métriques personnalisées (pertinence, exhaustivité, fidélité). Définir une grille d'évaluation, acheminer un échantillon à une main-d'œuvre, agréger les scores.

Pourquoi: Les métriques de chevauchement lexical (BLEU, ROUGE) manquent la fidélité sémantique. L'évaluation humaine est la vérité fondamentale pour les tâches subjectives.

Besoin d'une évaluation évolutive et reproductible mais la révision humaine seule est trop lente/coûteuse.

Évaluation Bedrock LLM-as-a-judge. Un modèle puissant évalue les réponses par rapport à une grille ; les résultats corrèlent bien avec les évaluateurs humains et s'exécutent en minutes plutôt qu'en jours.

Les résumés de portefeuille générés doivent correspondre exactement aux chiffres du document source.

Contraindre la génération : basse température (0-0,2), instructions de prompt strictes ("citer les nombres textuellement de la source"), vérification de mise à la terre contextuelle des Guardrails sur la sortie, regex/parseur post-génération qui valide les nombres par rapport à la source.

Pourquoi: Même avec un RAG mis à la terre, les modèles paraphrasent les nombres. Plusieurs couches (prompt + mise à la terre + parseur) gèrent les cas résiduels.

Le RAG renvoie souvent "Je n'ai pas assez d'informations" même pour des sujets couverts dans la base de connaissances (KB).

Inspecter les traces de récupération : scores des chunks, nombre de chunks récupérés, alignement requête-chunk. Corrections courantes : activer la recherche hybride, augmenter `top-k`, ajuster la taille des chunks, passer au découpage sémantique, activer la reformulation des requêtes, abaisser le seuil de pertinence.

L'agent renvoie des prix obsolètes même après une synchronisation récente de la base de connaissances (KB) ; la source de données est S3 avec versioning.

Confirmer que la dernière tâche d'ingestion (IngestionJob) `status: COMPLETE` et `documentsModified` reflète les nouveaux objets. Le versioning signifie que les versions non courantes peuvent toujours être indexées si la source de données n'est pas limitée aux versions courantes uniquement - vérifier le filtre de la source de données et resynchroniser.

L'agent RH révèle occasionnellement des informations salariales sur d'autres employés lorsqu'on lui pose des questions astucieusement.

Resserrer les instructions de l'agent ("ne répondre que sur les données de l'utilisateur demandeur"), filtrer le groupe d'actions via des attributs de session qui incluent l'ID utilisateur, limiter l'IAM sur la fonction Lambda supportant le groupe d'actions pour ne consulter que les enregistrements de l'utilisateur, ajouter un sujet interdit aux Guardrails pour les requêtes salariales inter-utilisateurs.

Les invocations Bedrock présentent des pics de latence p95 intermittents.

Vérifier les `InvocationThrottles` (atteintes des limites de débit) et `ModelLatency` de CloudWatch ; activer le traçage AWS X-Ray sur la fonction Lambda appelante ; inspecter CloudWatch Logs Insights pour les appels d'outils lents ou la récupération de la base de connaissances (KB). Atténuer via l'inférence inter-régions, un modèle plus petit, le caching de prompt ou le traitement par lots.

Migrer de Claude v2 vers Claude 3.5 Sonnet sans régression.

Exécuter une tâche d'évaluation Bedrock comparant les deux sur un ensemble de prompts représentatif. Puis effectuer un trafic fantôme en production : envoyer la même entrée aux deux, comparer les sorties hors ligne. Promouvoir avec un drapeau de fonctionnalité AppConfig à 10 % → 50 % → 100 %.

Exécuter l'évaluation de modèle Bedrock dans le cadre de la CI/CD à chaque changement de configuration de modèle.

Utiliser l'API `CreateEvaluationJob`. Définir le jeu de données dans S3, les évaluateurs (intégrés ou personnalisés) et les modèles cibles. Interroger le statut de la tâche ; promouvoir si `COMPLETED` et les métriques sont au-dessus des seuils.

Pourquoi: L'interface utilisateur Studio est pour des usages ponctuels ; l'API est la seule voie vers des portes d'évaluation automatisées et reproductibles.

Éviter les régressions de qualité lors de la mise à niveau du modèle de fondation en production.

Maintenir un ensemble de tests de régression curaté : 100 à 500 prompts représentatifs avec les sorties attendues (ou des rubriques). Exécuter via l'évaluation de modèle Bedrock à chaque changement de modèle. Bloquer la promotion si les scores chutent de plus d'un seuil défini.

Mesurer si le modèle choisit le bon outil avec les bons arguments dans un chat utilisant des outils.

Construire un ensemble étiqueté : prompt + bloc(s) `toolUse` attendu(s). Exécuter via un évaluateur personnalisé qui compare le nom de l'outil réel vs attendu + les arguments JSON. Suivre la précision/le rappel par outil.

Pourquoi: Les métriques lexicales (BLEU) ne permettent pas de savoir si l'agent a invoqué la bonne action. La précision de l'utilisation des outils est la bonne métrique pour les charges de travail agentiques.