Prouvez-le, 2e partie : logique formelle, politiques Cedar et aspects économiques de la vérification

Le raisonnement automatisé permet de vérifier les résultats générés par les LLM en traduisant les politiques métier en logique formelle et en les comparant à ces règles. Il détecte les hallucinations, garantit le respect des contraintes de conformité et contrôle les actions des agents avec une couverture totale, pour un coût bien inférieur à celui d’un contrôle qualité manuel.

Dans la première partie (« Probablement correct » ne suffit pas »), nous avons expliqué pourquoi les start-ups qui s’appuient sur l’IA ont besoin d’une vérification déterministe, et pas seulement de mesures de sécurité probabilistes. Dans cet article, nous allons voir les coulisses du système. Si vous êtes cofondateur technique, responsable de l’ingénierie ou développeur senior dans une start-up spécialisée dans l’IA, vous découvrirez ici comment fonctionne réellement le raisonnement automatisé, ce qui se passe lorsque votre grand modèle de langage (LLM) génère une réponse et que la logique formelle la vérifie, et pourquoi, d’un point de vue économique, cette solution s’impose comme une évidence par rapport au recrutement d’équipes d’assurance qualité.

Cet article ne contient pas de code API. Celui-ci sera présenté dans la troisième partie. Ici, nous nous concentrons sur les concepts, la logique formelle et le processus de vérification afin que vous compreniez ce que vous êtes en train de développer.

Stochastique ou déterministe : la distinction fondamentale

Avant d’aborder les aspects techniques, il convient de bien cerner cette distinction fondamentale, car elle influe sur chacune de vos décisions architecturales.

Les LLM sont stochastiques.

Ils prédisent le jeton suivant en se basant sur des distributions de probabilité apprises à partir des données d’entraînement. Les paramètres d’échantillonnage température, top-k et top-p introduisent un caractère aléatoire délibéré. Si vous lancez deux fois la même requête, vous pouvez obtenir des réponses différentes. Il s’agit là d’une fonctionnalité, et non d’un bug : c’est ce qui rend les LLM flexibles, créatifs et capables de traiter des entrées variées en langage naturel. Mais cela signifie également que toute sortie est un échantillon issu d’une distribution de probabilité, et non un fait avéré.

Le raisonnement automatisé (AR) est correct.

À partir d’un ensemble de règles et d’une entrée, le résultat n’est pas une simple estimation. C’est une preuve. Une affirmation est soit valide de manière démontrable au regard de vos règles, soit invalide de manière démontrable, soit le système vous indique précisément quelles informations manquent ou sont ambiguës. Si la réponse est erronée, le raisonnement automatisé ne se contente pas de la signaler ; il vous fournit un contre-exemple montrant exactement pourquoi elle est incorrecte. Le résultat est mathématiquement vérifiable, et non probabiliste. Il n’y a pas de bouton de réglage. Il n’y a pas d’échantillonnage. Il y a une preuve que vous pouvez examiner.

Il ne s’agit pas de déterminer quelle approche est « meilleure ». Les LLM sont plus performants pour comprendre le langage naturel et générer des réponses de type humain. Le raisonnement automatisé est plus efficace pour vérifier si ces réponses sont logiquement correctes. Ensemble, ils forment une pile complète : le LLM gère la conversation, tandis que le raisonnement s’assure de l’exactitude des réponses. C’est cette combinaison de réseaux neuronaux et de logique formelle que les chercheurs appellent IA neurosymbolique.

Pour une start-up de cinq personnes qui s’apprête à livrer ses 100 premiers clients, cette distinction a une conséquence très concrète. Vous ne disposez pas des effectifs nécessaires pour constituer une équipe d’assurance qualité, ni de la marge de manœuvre suffisante pour faire face à un incident de conformité. La vérification formelle devient alors un multiplicateur de force qui permet à une petite équipe de livrer ses produits avec la même assurance qu’une équipe bien plus importante.

Quels sont les deux niveaux de protection d’Amazon Bedrock ?

AWS propose deux niveaux de raisonnement automatisé, qui correspondent parfaitement à la courbe de maturité de la plupart des start-ups spécialisées dans l’IA. Au tout début, votre produit prend généralement la forme d’un chatbot ou d’un assistant : un LLM qui répond aux questions des clients, génère des recommandations ou fournit des conseils. À ce stade, le raisonnement automatisé d’Amazon Bedrock Guardrails vérifie la conformité du contenu des résultats du modèle par rapport à des règles métier définies.

Au fur et à mesure que vous vous développez, vous commencez à mettre en place des flux de travail automatisés : votre IA prend des rendez-vous, traite les remboursements, interroge des bases de données et appelle des API externes. À ce niveau, la Policy dans Amazon Bedrock AgentCore régit les actions qu’un agent est autorisé à effectuer, grâce à des politiques Cedar appliquées au niveau de la passerelle avant toute exécution d’outil.

Les politiques Cedar régissent les actions autorisées à un agent. Mais vous pouvez également intégrer l’API de vérification du raisonnement automatisé à la boîte à outils de l’agent, ce qui lui permet de valider ses propres conclusions intermédiaires avant de les mettre en œuvre. L’agent appelle ApplyGuardrail en fonction de votre politique, examine les résultats et se corrige de lui-même sans impliquer l’utilisateur. Un agent planifiant un flux de travail en plusieurs étapes peut vérifier si la séquence qu’il propose enfreint une contrainte, détecter une contradiction dans ses hypothèses ou confirmer qu’une valeur dérivée découle bien des données d’entrée. Le raisonnement automatisé passe ainsi du simple contrôle des limites à un véritable partenaire de raisonnement : l’agent n’est pas simplement bloqué à la barrière, il évite dès le départ de s’en approcher.

Voici comment ils se comparent :

Les contrôles de raisonnement automatisé Policy dansAmazon Bedrock AgentCore protègent les différentes couches de votre application.

• Les contrôles de raisonnement automatisé permettent de vérifier les informations fournies par votre IA, comme par exemple : la réponse concernant l’éligibilité à un prêt immobilier est-elle correcte au regard de vos critères d’octroi de crédit ?
• Policy dans Amazon Bedrock AgentCore détermine ce que fait votre IA, c’est-à-dire : cet agent est-il autorisé à lancer un remboursement ou à consulter le compte d’un client ?

Selon ce que vous développez aujourd’hui, vous pouvez commencer par l’un ou l’autre, voire les deux.

• Si votre MVP est un chatbot destiné à répondre à des questions sur les polices d’assurance, les contrôles de raisonnement automatisé constituent votre première intégration.
• Si vous recrutez un agent chargé de prendre des rendez-vous et d’effectuer des virements bancaires, le règlement est non négociable dès le premier jour.

La plupart des start-ups finiront par utiliser les deux ensemble.

Comment fonctionnent les contrôles de raisonnement automatisé : encoder vos règles métier sous forme de logique formelle

L’entrée du raisonnement automatisé est une politique, et une politique commence par les documents que vous possédez déjà.

Si vous êtes une start-up spécialisée dans les technologies financières, il peut s’agir d’un document définissant les critères d’octroi de crédit. Dans le secteur de la santé, il peut s’agir de protocoles cliniques ou de procédures de traitement des données relevant de la loi HIPAA. Dans le domaine de l’assurance, ce sont les directives de souscription. Ces documents définissent ce que votre IA doit dire et ce qu’elle ne doit pas dire. Ils ont été examinés par votre conseiller juridique. Vos investisseurs vous ont posé des questions à leur sujet lors de la due diligence. Le raisonnement automatisé transforme ces documents existants en règles applicables. Vous ne créez pas quelque chose de nouveau à partir de zéro. Vous activez simplement ce dont vous disposez déjà.

Lorsque vous importez un document de politique (au format PDF, Markdown ou texte brut) sur Amazon Bedrock, le système en extrait deux éléments : des variables et des règles.

Les variables représentent les concepts de votre domaine. Chaque variable possède un nom, un type et une description. Par exemple, dans une politique d’éligibilité à un prêt immobilier :

Les descriptions des variables constituent le facteur le plus déterminant pour la précision. Des descriptions vagues obligent le LLM à deviner ce que représente une variable. En revanche, des descriptions détaillées qui expliquent la signification du concept, la manière dont vos utilisateurs s’y réfèrent et la façon dont il apparaît dans vos documents de politique fournissent au LLM le contexte dont il a besoin pour associer le langage naturel aux variables formelles appropriées. C’est là que votre expertise dans le domaine, en tant que créateur de start-up, revêt toute son importance.

Les règles sont des expressions de logique formelle qui décrivent les relations entre les variables. Elles utilisent un sous-ensemble de la syntaxe SMT-LIB, et la plupart suivent un format « si… alors » (implicatif) :

Voici ce que Bedrock génère en arrière-plan lorsque vous chargez le document de votre politique d’assurance hypothécaire. Vous pouvez consulter ces règles dans la console pour vérifier que le système a bien saisi votre intention, mais vous n’écrivez pas le code SMT-LIB à la main. Vous rédigez la politique en langage naturel, et le système la traduit en logique formelle.

Le processus de vérification en deux étapes

Une fois que vous avez défini une politique de raisonnement automatisé et que vous l’avez associée à une barrière de protection (comme expliqué dans la partie 3), chaque réponse LLM que votre application envoie à ApplyGuardrail est soumise à un processus de vérification en deux étapes. Il est essentiel de bien comprendre cette distinction, car elle vous indique où concentrer vos efforts.

Étape 1 : traduction

Le système convertit le langage naturel utilisé tant dans la question de l’utilisateur que dans la réponse du LLM en prédicats de logique formelle, c’est-à-dire en expressions telles que « revenus >= 180 et revenus <= 220 » plutôt qu’en simples affectations, en utilisant les variables déclarées dans votre politique. C’est là que les descriptions des variables entrent en jeu.

Par exemple, si la réponse indique « un client ayant versé un apport de 30 000 USD pour l’achat d’une maison de 350 000 USD est éligible à un prêt immobilier classique », l’étape de traduction génère les valeurs suivantes : downPaymentAmount = 30000, purchasePrice = 350000, mortgageType = CONVENTIONAL.

C’est précisément parce que nous utilisons des LLM pour traduire votre entrée en langage naturel en logique que le système revendique une précision de vérification pouvant atteindre 99 %. Pour garantir l’exactitude de notre traduction, nous ne nous appuyons pas sur un seul LLM. Nous utilisons plutôt plusieurs LLM à différentes variations en parallèle pour effectuer la même traduction. Ce n’est que lorsque les traductions redondantes sont sémantiquement équivalentes que nous pouvons établir un résultat de validation. Lorsque les traductions divergent, nous renvoyons alors un résultat AMBIGUOUS (ambigu) qui inclut deux interprétations possibles de l’entrée. Votre LLM peut utiliser ce retour d’information pour lever l’ambiguïté de sa réponse ou poser des questions de clarification à l’utilisateur. Lorsque nous avons évalué notre système par rapport à l’ensemble de données de questions-réponses conditionnelles de Carnegie Mellon, dans plus de 99 % des cas où une réponse avait été marquée comme VALID (valide) par notre système, ce marquage s’est avéré correct. Vous trouverez plus de détails sur la méthodologie dans cet article.

Étape 2 : vérification

Un solveur SMT (Satisfiability Modulo Theories) évalue si les affectations traduites satisfont à toutes vos règles de politique. Cette étape est, par définition, mathématiquement rigoureuse. Dès lors que la traduction est correcte, la vérification est certifiée correcte.

Pour l’exemple de prêt immobilier : le solveur calcule downPaymentPercentage = (30 000 / 350 000) * 100 = 8,57 %, compare ce résultat à la règle (=> (< downPaymentPercentage 20,0) (not (= mortgageType CONVENTIONAL))), constate que 8,57 < 20 et conclut que mortgageType = CONVENTIONAL est logiquement invalide. Le système renvoie un résultat invalide accompagné d’une trace complète indiquant précisément quelle règle a été enfreinte et pourquoi.

Quelle leçon concrète les fondateurs de start-ups peuvent-ils en tirer ? Vous pouvez contrôler la qualité de la traduction en améliorant la description des variables. Quant aux calculs de vérification, vous n’avez pas à vous en soucier. Investissez dans une description rigoureuse de votre domaine, et le solveur s’occupe du reste.

Que signifient les résultats ?

Les contrôles de raisonnement automatisé ne se contentent pas d’indiquer « réussi » ou « échoué ». Ils fournissent des résultats structurés qui vous indiquent précisément ce qui s’est passé et les mesures à prendre ensuite. Chaque résultat correspond à l’un des types suivants :

C’est important : les contrôles de raisonnement automatisé fonctionnent en mode détection. Ils renvoient des résultats et des commentaires, mais ne bloquent pas la réponse. Votre application examine ces résultats et décide de la marche à suivre : servir la réponse telle quelle, la réécrire, demander des précisions ou revenir à une valeur par défaut sûre. Cela vous offre un contrôle total sur l’expérience utilisateur tout en bénéficiant d’une vérification mathématique pour chaque réponse. Pour découvrir un exemple concret de ce modèle, consultez l’implémentation open source d’un chatbot à réécriture, qui montre comment exploiter les résultats de du raisonnement automatisé et les renvoyer au LLM pour une correction automatisée.

Politique AgentCore : limites déterministes pour les agents d’IA

Si votre start-up développe des applications agentiques, dans lesquelles votre IA orchestre des flux de travail en plusieurs étapes, fait appel à des outils et effectue des actions pour le compte des utilisateurs, vous êtes confronté à un autre problème de confiance. Il ne s’agit pas seulement de ce que dit l’IA, mais aussi de ce qu’elle fait.

Pour les start-ups des secteurs de la santé, de la fintech ou du droit, le fait qu’« un agent ait agi de manière inattendue » n’est pas acceptable d’un point de vue réglementaire ou de conformité. Il est nécessaire de définir des limites vérifiables quant au comportement de l’agent, et ces limites doivent être respectées même lorsque l’agent est manipulé par l’injection d’invite ou commet une erreur de raisonnement.

La Policy dans Amazon Bedrock AgentCore résout ce problème grâce à une couche d’autorisation appliquée à chaque interaction entre un agent et un outil au niveau de la passerelle. Les politiques sont rédigées en Cedar, le langage d’autorisation développé par AWS pour être vérifié avec le raisonnement automatisé. Les politiques Cedar définissent qui (le principal) peut faire quoi (l’action) sur quelle ressource, et dans quelles conditions. Aucune invocation d’outil ne traverse la passerelle sans autorisation correspondante. Vous pouvez rédiger vos politiques directement en Cedar ou décrire vos règles en langage naturel et laisser le système générer le code Cedar à votre place.

Avant le déploiement de vos politiques, un raisonnement automatisé effectue une validation sémantique afin de détecter d’éventuels problèmes, notamment :

• Des politiques trop permissives qui autoriseraient toutes les requêtes pour une combinaison donnée de principal, d’action et de ressource
• Des politiques trop restrictives qui nieraient tout
• Politiques inefficaces lorsqu’un permis ne permet rien ou une interdiction n’interdit rien

Cette application de la réglementation repose sur deux principes particulièrement importants pour les start-ups évoluant dans des secteurs réglementés :

1. Refus par défaut : si aucune règle n’autorise explicitement une action, celle-ci est bloquée. Votre agent ne peut effectuer aucune action que vous n’avez pas autorisée.
2. L’interdiction l’emporte toujours sur l’autorisation : vous pouvez définir des règles strictes qui ne peuvent pas être contournées, quelles que soient les autres politiques en vigueur.

Prenons l’exemple d’une start-up du secteur de la santé qui développe un agent de prise de rendez-vous. Grâce à AgentCore Policy, vous pouvez vous assurer que les patients n’accèdent qu’à leur propre dossier médical, que la prise de rendez-vous soit limitée aux heures d’ouverture et que les montants des remboursements soient plafonnés conformément à la politique en vigueur. Ces règles s’appliquent indépendamment des invites que reçoit l’agent, des éventuels bugs présents dans votre code ou de la créativité dont fait preuve l’utilisateur dans ses requêtes. L’application de ces règles s’effectue au niveau de la passerelle, en dehors de l’agent lui-même.

Quel est le coût du raisonnement automatisé par rapport à l’assurance qualité manuelle ?

Pour comprendre les enjeux économiques du raisonnement automatisé, il est utile de le comparer à la méthode de référence actuellement utilisée par la plupart des équipes : la vérification manuelle par assurance qualité des résultats des modèles.

L’ancienne méthode : contrôle qualité manuel

Un réviseur chargé de vérifier les réponses générées par l’IA peut traiter environ 50 interactions par heure, pour un coût horaire d’environ 40 USD. Pour une start-up traitant 100 000 interactions clients par mois, la vérification de chaque interaction coûte 80 000 USD par mois. Même en ne vérifiant que 10 % des interactions, le coût s’élève à 8 000 USD par mois, et les 90 % restants ne sont toujours pas vérifiés. Avec un coût annuel compris entre 80 000 et 150 000 USD par réviseur, une équipe de 5 à 10 réviseurs représente un coût annuel de 400 000 à 1,5 million d’USD. Pour la plupart des start-ups, cela représente une part importante de leur budget consacrée à la vérification du bon fonctionnement de leur IA.

La nouvelle méthode : le raisonnement automatisé

Les contrôles de raisonnement automatisé sont facturées par demande de validation. (Les tarifs exacts doivent être confirmés sur la page des tarifs de Bedrock, car ils peuvent varier.) Contrairement à la révision manuelle, chaque interaction peut être vérifiée, et non pas seulement un échantillon. Amazon Bedrock Guardrails utilise des unités de texte comme unité de validation, chaque unité de texte correspondant à 1 000 caractères. Voici à quoi cela ressemble pour une start-up type :

Hypothèses

Calcul

En reprenant l’exemple ci-dessus d’une start-up traitant 100 000 interactions par mois, et en supposant que chaque interaction génère environ 200 jetons, nous pouvons facilement estimer le coût lié à l’utilisation des contrôles de raisonnement automatisé pour la validation. Amazon Bedrock Guardrails mesure l’utilisation en unités de texte, une unité de texte correspondant à 1 000 caractères. En partant d’une moyenne de 4 caractères par jeton, nous estimons que chaque interaction représente environ 800 caractères, soit 0,8 unité de texte.

La validation de 100 000 interactions de 0,8 unité de texte chacune nous donne un total de 80 000 unités de texte par mois. Avec des contrôles de raisonnement automatisé à 0,17 USD pour 1 000 unités de texte, notre coût mensuel total pour une seule politique s’élèverait à 13,60 USD. Lorsque plusieurs politiques sont appliquées, les coûts augmentent de manière linéaire. Même avec plusieurs politiques, le coût total reste nettement inférieur à celui d’une révision manuelle.

Les chiffres relatifs à la conformité sont encore plus éloquents. Une seule infraction à la loi HIPAA peut coûter jusqu’à 2 067 813 USD par an, selon les chiffres actuels ajustés en fonction de l’inflation. Pour une start-up du secteur de la santé dont l’IA traite quotidiennement des milliers d’interactions avec des patients, le risque réglementaire lié à des résultats non vérifiés est une question de survie. Dans ce contexte, le raisonnement automatisé s’apparente moins à une dépense logicielle qu’à un outil de gestion des risques.

Pour les développeurs, l’analogie la plus proche est le borrow checker de Rust. Rust détecte les corruptions de mémoire lors de la compilation, avant que le code ne soit mis en production. AR détecte les violations de politique lors de la vérification, avant qu’elles n’atteignent votre client. Il est toujours moins coûteux de détecter les erreurs avant qu’elles ne causent des dommages que de devoir remédier aux conséquences par la suite.

Il y a toutefois un compromis à faire : la validation du raisonnement automatisé ajoute une latence à chaque réponse, et la réécriture implique que votre LLM s’exécute deux fois sur les résultats signalés. Pour la plupart des applications, cependant, ces coûts sont négligeables par rapport à l’impact opérationnel, juridique ou en termes de réputation qu’aurait un résultat erroné.

Cet argument trouve un écho auprès des investisseurs. Pouvoir affirmer que les résultats générés par l’IA sont systématiquement vérifiés au regard des politiques d’entreprise officielles n’est pas simplement une fonctionnalité du produit. C’est la preuve que les risques sont gérés de manière proactive. C’est ce genre d’argument concret et vérifiable qui renforce le profil de risque d’une start-up.

Qu’est-ce qui va suivre ?

Dans la partie 3 : guide de mise en œuvre étape par étape, nous passons des concepts au code. Vous apprendrez à créer une politique de raisonnement automatisé à partir de vos documents existants, à la déployer sur une barrière de protection, à l’intégrer à l’API ApplyGuardrail, à traiter les résultats par programmation, à configurer la politique AgentCore via la passerelle AgentCore et à établir une piste d’audit. Tout ce dont vous avez besoin pour passer de la théorie de la vérification mathématique à sa mise en production.