AWS combine IA générative et IA symbolique
AWS a largement mis en avant l’importance d’une architecture RAG lors de Re:Invent 2024, mais son autre priorité n’est autre que la maîtrise des hallucinations et le développement d’agents capables de collaborer entre eux.
Ainsi, AWS estime qu’il faut améliorer les garde-fous des grands modèles de langage, d’autant qu’il propose des modèles multimodaux et de génération d’images, dont ceux d’Amazon (Nova) et d’Anthropic. Depuis Bedrock Guardrails, le fournisseur propose en préversion un service pour détecter et bloquer les contenus haineux, insultants, sexuels ou violents potentiellement générés par les LLM et les modèles de diffusion. À cela s’ajoutent des filtres afin d’éviter la fuite de données personnelles ou confidentielles. Contrairement à d’autres outils au sein de la plateforme, ces garde-fous s’appliquent à tous les modèles compatibles.
En la matière, Microsoft et OpenAI ont donné le ton avec des dispositifs plutôt performants, notamment pour éviter la production de contenus nocifs depuis Microsoft Designer. Ce n’est donc pas vraiment nouveau.
L’IA symbolique à la rescousse
En revanche, AWS entend proposer une fonctionnalité que peu d’acteurs proposent actuellement pour maîtriser le raisonnement des LLM. En préversion, Guardrails permet d’effectuer des vérifications issues d’un outil de raisonnement automatisé (Automated Reasoning checks).
« Le raisonnement automatisé est un domaine de l’informatique qui utilise des preuves mathématiques et des déductions logiques pour vérifier le comportement des systèmes et des programmes », indique Antje Barth, principal developer advocate pour l’IA générative chez AWS, dans un billet de blog. « Le raisonnement automatisé se distingue de l’apprentissage automatique (Machine Learning, ML) – qui fait des prédictions – en offrant des garanties mathématiques concernant le comportement d’un système ». Le raisonnement automatisé à un nom plus connu et plus ancien : l’IA symbolique.
Il s’avère qu’AWS a développé une expertise dans ce domaine.
« Nous utilisons cette technologie depuis plus de dix ans pour vérifier les règles de configuration, l’accessibilité d’un VPC, les accès au IAM, la présence de vulnérabilités (Inspector), pour bloquer les accès publics à S3, etc. », assure Byron Cook, vice-président scientifique distingué chez AWS, lors d’une session consacrée à Amazon Bedrock Guardrails. « D’une façon ou d’une autre, tous les services d’AWS sont “affectés” par le raisonnement automatisé ».
Dans Bedrock, l’outil permet de charger une politique d’entreprise que le système d’IA sous-jacent – un LLM couplé à une IA symbolique (un moteur de règles) – interprète afin d’appliquer les règles de l’organisation aux résultats d’un LLM. Pour les connaisseurs, ce n’est rien d’autre qu’un système d’IA neuro-symbolique.
Plus particulièrement, l’outil identifie des concepts clés et des règles exprimés en langage naturel. Sous le capot, il les traduit en arbres de décision.
« Cette méthode est particulièrement efficace pour vérifier des données factuelles », explique Stefano Buliani, responsable produit du groupe raisonnement automatisé chez AWS. « Il s’agit de choses qui se résument à des réponses par oui ou par non : des politiques RH, l’application de réglementations ou des flux de travail opérationnels », poursuit-il.
En revanche, il se peut que le système n’ait pas identifié correctement le sens d’une politique ou d’une règle. Il est possible d’affiner ces politiques en langage naturel et de créer des versions de ces règles liées à un compte AWS. Une fois sauvegardée, la création d’un tel document prend quatre à cinq minutes environ. Un test permet de vérifier si le LLM répond correctement ou non afin d’affiner l’explication des règles.
Ces vérifications peuvent être implémentées de différentes manières, plus ou moins coûteuses.
Seule, cette approche n’est pas efficace pour la vérification de bonnes pratiques de messages marketing, de calculs probabilistes (quelles sont les chances que cet événement se produise) et les descriptions qualitatives. Il convient de la combiner avec les autres mécanismes fournis par Bedrock, dont une architecture RAG et les filtres évoqués plus haut.
Toutefois, ce raisonnement automatisé pourrait avoir d’autres applications que la protection contre les hallucinations. Appian a déjà testé ce service pour concevoir un agent autonome capable d’appliquer des conditions commerciales dans le cadre d’un support client.
La collaboration multiagent débarque dans Bedrock
En parlant d’agents, AWS a présenté la préversion d’un outil de collaboration multiagent. Il doit permettre de faire interagir plusieurs LLM « spécialisés » responsables de gérer des tâches comprenant plusieurs étapes.
Les ingénieurs et chercheurs d’AWS ont développé un concept où un agent « superviseur » délègue les tâches à d’autres « sous-agents », dans le but de fournir une réponse à l’usager.
« Par exemple, un système multiagent de conseil en investissement peut inclure des agents spécialisés dans l’analyse des données financières, la recherche, les prévisions et les recommandations d’investissement », illustre AWS.
Toutefois, dans Amazon Bedrock, il existe deux modes de collaboration. Le premier consiste à exploiter un agent « superviseur » qui transmet les éléments de la requête de l’utilisateur à des sous-agents « collaborateurs », puis qui coordonne la réponse finale.
« Après avoir reçu les réponses des sous-agents, l’agent superviseur les traite pour déterminer si le problème est résolu ou si d’autres mesures sont nécessaires », précise la documentation d’AWS.
Le second, appelé « superviseur avec routage », permet à l’agent orchestrateur/superviseur de s’appuyer sur un classifieur afin de choisir le bon « sous-agent » capable de proposer la réponse finale.
Ces deux concepts s’appuient sur les travaux de chercheurs d’Amazon Science. Ils ont développé un framework s’appuyant sur la technique de prompting « Chain of Though ». Dans ce cadre, certains LLM désignés comme des collaborateurs sont chargés du « raisonnement », tandis qu’un autre doit coordonner la réponse à l’utilisateur. Ils ont également testé le second mode de collaboration décrit plus haut, mais ont déterminé qu’il était moins fiable quand il faut traiter des séries de tâches complexes. Dans Bedrock, si la requête est trop complexe, le premier mode de supervision est automatiquement appliqué, selon AWS.
Le rôle d’un sous-agent peut lui être spécifié en lui donnant un titre, en décrivant son rôle et ses tâches à l’aide d’instructions en langage naturel. Pour l’heure, AWS semble recommander l’usage de Claude Sonnet 3.5.
Aussi, la préversion ne permet pas la collaboration asynchrone. Il faut donc exécuter plusieurs instances de LLM simultanément, ce qui peut être coûteux. Il est possible de déployer jusqu’à trois couches d’agents hiérarchiques.
Confier un rôle à travers des prompts n’est souvent pas suffisant pour qu’un LLM produise les meilleurs résultats. Les grands modèles de langage ont reçu un enseignement « généraliste » dans des domaines comme les mathématiques, la chimie, l’histoire, etc. Ils n’ont pas l’expertise d’un métier dans un domaine d’activité précis.
Distillation de connaissances à la demande
D’où la pertinence de l’annonce suivante. Avant de spécialiser ces modèles, Amazon Bedrock se dote d’un outil managé de distillation de connaissances. Un LLM « professeur » est utilisé dans le cadre de l’entraînement d’un modèle « élève », plus petit. À partir d’une série de données, le professeur génère des données synthétiques qui serviront lors du fine-tuning du LLM cible.
C’est l’une des techniques les plus intéressantes pour former des SLM (Small Language Models) capables de traiter des tâches ou répondre à des questions d’expertise. En effet, la distillation permet de transférer une partie des connaissances d’un LLM à un membre de sa collection.
Pour que cela fonctionne, « le professeur et l’élève doivent être de la même famille », indique AWS. Ici, le fournisseur prend en charge les LLM des collections Claude 3.5 d’Anthropic, Llama 3.1 de Meta et Nova (Pro, Lite, Micro) d’Amazon. Il faut également respecter la hiérarchie de taille. Par exemple, dans la collection Llama 3.1, les variantes dotées de 405 milliards et 70 milliards de paramètres peuvent être utilisées pour entraîner la variante 8B. L’inverse est contre-productif.
Là encore, AWS propose deux modes de distillation : l’un à partir des logs de production tirés des précédentes interactions avec Amazon Bedrock, l’autre en chargeant un fichier JSONL comprenant des paires d’instructions-réponses annotées.
Le processus semble encore complexe et n’est pour l’instant accessible que depuis certaines régions cloud américaines du fournisseur. Pour autant, AWS promet des gains de latence de l’ordre 50 % et une réduction « jusqu’à 75 % » des coûts d’inférence avec les modèles « distillés ».
En matière de systèmes multiagents et de SLM, AWS semble vouloir rattraper son retard sur Microsoft Azure. À partir de son framework AutoGen, Microsoft a développé Magentic One, un système multiagent. Toutefois, la firme de Redmond a préféré mettre en production l’évolution d’AutoGen : Semantic Kernel. Quant à l’entraînement de SLM spécialisés, il entretient déjà des partenariats avec des éditeurs IT-OT, dont Rockwell Automation, Siemens, ou encore Bosch.
