Amazon Bedrock

Vous avez décidé que votre application a besoin d'un modèle de fondation. Arrivent alors les questions que personne n'aime : quelles instances GPU, combien, dans quelle région, qui les patche, que se passe-t-il à 3 heures du matin quand le trafic triple, et comment remplacer ce modèle par un meilleur dans six mois sans tout reconstruire.

Amazon Bedrock existe pour que vous ne répondiez jamais à ces questions. AWS le définit comme « un service entièrement managé qui fournit un accès sécurisé, de qualité entreprise, à des modèles de fondation performants issus des principales entreprises d'IA, vous permettant de créer et de faire évoluer des applications d'IA générative ».

Lisez cette phrase comme une liste de choses que vous ne faites plus. Aucun serveur à dimensionner. Aucun poids de modèle à télécharger. Aucune pile d'inférence à exploiter. Vous envoyez une requête à un endpoint d'API, vous recevez du texte généré, et la capacité en dessous est le problème de quelqu'un d'autre.

Une API, de nombreux modèles

Bedrock prend en charge plus de 100 modèles de fondation, chez des fournisseurs comme Amazon, Anthropic, DeepSeek, MiniMax, Moonshot AI et OpenAI. Ce catalogue mérite d'être noté, mais il n'est pas le point important. Ce qui compte, c'est ce qui se trouve devant lui.

Chacun de ces modèles s'atteint par le même service. En pratique vous appelez la Converse API, vous nommez un identifiant de modèle et vous passez vos messages :

import boto3

client = boto3.client('bedrock-runtime', region_name='us-east-1')
response = client.converse(
    modelId='anthropic.claude-opus-4-7',
    messages=[
        {'role': 'user', 'content': [{'text': 'Résume ce ticket de support.'}]}
    ]
)

Remplacez maintenant modelId par un modèle Amazon Nova. Rien d'autre ne change dans cet appel. Votre authentification, votre SDK, votre gestion d'erreurs, vos logs et vos politiques IAM continuent de fonctionner.

Comparez avec l'alternative. Sans Bedrock, chaque fournisseur signifie un compte séparé, une clé d'API stockée quelque part, un SDK avec sa propre forme de requête, une facture séparée et une revue de sécurité séparée. Ajouter un deuxième fournisseur de modèles devient un projet. Sur Bedrock c'est une chaîne de caractères.

C'est la raison pour laquelle la leçon sur la sélection de modèle pouvait qualifier ce choix de réversible. Cette réversibilité n'est pas une propriété générale de l'IA générative. C'est une propriété de la construction derrière une couche d'abstraction, et Bedrock est cette couche.

Une limite honnête : l'appel est portable, le comportement ne l'est pas. Un prompt ajusté pour un modèle ne produit pas une sortie identique sur un autre, et les modèles diffèrent par la fenêtre de contexte, la longueur maximale de sortie et les paramètres d'inférence acceptés. Bedrock rend le basculement bon marché. Il ne rend pas la revalidation inutile.

Ce que Bedrock ajoute autour du modèle

Un appel de modèle brut n'est pas une application. Entre « le modèle répond » et « la fonctionnalité part en production » se logent des problèmes que toutes les équipes rencontrent, et Bedrock livre des réponses managées à la plupart d'entre eux.

Knowledge Bases prend en charge la génération augmentée par récupération. AWS décrit l'objectif directement : le RAG « utilise l'information de sources de données pour améliorer la pertinence et l'exactitude des réponses générées », et avec Knowledge Bases « vous pouvez intégrer de l'information propriétaire dans vos applications d'IA générative ». Vous le pointez sur vos données, et il gère l'ingestion, le chunking, l'embedding, le stockage et la récupération, puis rend des réponses avec citations pour qu'une affirmation soit traçable jusqu'à sa source. Une Managed Knowledge Base laisse AWS exécuter tout ce pipeline ; une base gérée par le client vous laisse apporter votre propre vector store, comme Amazon OpenSearch Serverless, Amazon Aurora ou Amazon Neptune, et contrôler vous-même l'ingestion et l'indexation.

Guardrails est la couche de sécurité. Elle fournit « des garde-fous configurables pour vous aider à construire des applications d'IA générative sûres », en six types de politiques :

Deux détails sur Guardrails sont à retenir. Ils évaluent le prompt d'entrée et la complétion du modèle, pas un seul des deux côtés. Et ils fonctionnent sans modèle du tout : l'API ApplyGuardrail filtre du contenu seule, donc vous pouvez vérifier un texte avant qu'il n'entre dans votre pipeline.

La personnalisation de modèle couvre trois méthodes. Le fine-tuning supervisé s'entraîne sur des exemples entrée-sortie étiquetés. Le reinforcement fine-tuning apprend à partir de fonctions de récompense que vous définissez au lieu de paires étiquetées. La distillation transfère la connaissance d'un grand modèle enseignant vers un modèle élève plus petit, plus rapide et moins cher. Le domaine 3 traite du bon moment pour chacune.

Les évaluations notent des modèles sur vos propres données, de façon programmatique, avec un modèle juge ou avec des relecteurs humains. Vous les avez rencontrées dans la leçon sur la sélection de modèle.

AgentCore transforme un modèle en agent qui planifie et agit. C'est un sujet en soi, et la leçon suivante le reprend.

Le schéma est le même partout : chacune de ces briques est un problème que vous résoudriez sinon avec votre propre infrastructure, livré ici sous forme de configuration.

La question des données, répondue concrètement

Toute organisation pose une version de ceci : si nous envoyons du texte client au modèle d'un tiers, que voit ce tiers ?

Pour Bedrock, AWS répond par l'architecture plutôt que par une promesse. Dans chaque région où Bedrock est disponible, il existe un compte de déploiement de modèle par fournisseur. Ces comptes sont détenus et exploités par l'équipe du service Bedrock. Quand un fournisseur livre un modèle, AWS effectue une copie profonde de son logiciel d'inférence et d'entraînement dans ces comptes. Puis vient la phrase qui compte : « Parce que les fournisseurs de modèles n'ont pas accès à ces comptes, ils n'ont pas accès aux journaux Amazon Bedrock ni aux prompts et complétions des clients. »

Appeler un modèle tiers sur Bedrock n'est donc pas la même chose qu'appeler l'API publique de ce fournisseur. Votre prompt part vers un compte exploité par AWS, pas vers le fournisseur. Le fournisseur a livré le modèle ; il ne reçoit pas le trafic.

Par-dessus, vous retrouvez les contrôles AWS habituels : chiffrement avec AWS KMS, connectivité privée via Amazon VPC et AWS PrivateLink pour que les requêtes ne traversent jamais l'internet public, IAM pour décider qui peut invoquer quel modèle, et CloudTrail pour la trace d'audit.

C'est le fait le plus utile de cette leçon en question de scénario. Quand un énoncé mentionne un secteur régulé, une règle de résidence des données ou une revue de sécurité qui doit approuver le fournisseur, c'est sur l'isolation par compte de déploiement que la réponse se construit.

Là où Bedrock s'arrête

Bedrock est un bon choix par défaut, et un choix par défaut n'est pas une réponse universelle. Il sert et personnalise des modèles qui existent déjà. Trois situations sortent de son périmètre.

Vous voulez entraîner un modèle de zéro, sur votre propre architecture, avec votre propre boucle d'entraînement. Bedrock n'offre aucun point d'entrée pour cela.

Vous avez besoin d'un modèle absent du catalogue, ou d'un contrôle complet de l'environnement de service : un conteneur d'inférence précis, un type d'instance précis, ou un déploiement dans votre propre VPC sur du matériel que vous choisissez.

Vous faites du machine learning classique plutôt que de l'IA générative. Un modèle de détection de fraude sur des données transactionnelles tabulaires est un arbre à gradient boosté, pas un modèle de fondation, et Bedrock n'a rien à lui proposer.

Chacun de ces points désigne le même service, sujet de la leçon suivante.

Conseils pour l'examen

• Bedrock est le chemin serverless entièrement managé vers les modèles de fondation. Les mots d'un scénario comme « aucune infrastructure à gérer », « le chemin le plus rapide vers la production » ou « nous ne voulons pas exploiter de GPU » pointent ici.
• Une API unique vers de nombreux fournisseurs est le différenciateur à retenir. Toute question sur un changement de modèle peu coûteux, ou sur la comparaison de modèles sans réécrire l'application, teste ce point.
• Associez la capacité au problème : des données propriétaires dans les réponses veut dire Knowledge Bases ; bloquer du contenu nuisible ou hors sujet veut dire Guardrails ; détecter une réponse non ancrée veut dire contextual grounding checks précisément.
• Les guardrails évaluent l'entrée et la sortie, et ApplyGuardrail fonctionne sans invoquer de modèle. Une option affirmant qu'ils ne voient que la sortie est fausse.
• « Entraîner un modèle de zéro » est la formule qui sort Bedrock du jeu. « Nous avons besoin du contrôle complet du conteneur de service » aussi.
• L'isolation des fournisseurs par comptes de déploiement est la réponse à toute question sur ce que voient les fournisseurs de modèles. Ils ne voient rien.
• Un modèle personnalisé exige du Provisioned Throughput pour être servi. Retenez cette paire ; la leçon sur les coûts explique pourquoi elle pique.

L'idée à emporter est que Bedrock échange du contrôle contre de la vitesse, et que cet échange est le bon la plupart du temps. La leçon suivante porte sur les cas où il ne l'est pas, et sur le service qui se trouve juste en dessous.