Où le modèle de langage doit s’arrêter : concevoir l’IA pour la paie, les admissions et les autres domaines où les erreurs ont de lourdes conséquences

Depuis plusieurs années, je conçois des produits qui intègrent l’IA dans des domaines où une mauvaise réponse a un coût : une plateforme de conformité de la paie assistée par l’IA pour le marché australien, où une erreur peut se retrouver sur le compte bancaire de quelqu’un, et un produit d’aide à l’admission dans l’enseignement supérieur, où une mauvaise adéquation peut peser sur les quatre prochaines années d’un étudiant. Dans les deux cas, la même question a déterminé l’architecture : jusqu’où le modèle de langage peut-il aller avant qu’un système déterministe prenne le relais ?

Une paie sur cinq aux États-Unis comporte une erreur, pour un coût moyen de 291 $ par erreur, avant même d’en arriver à un litige. Le règlement européen sur l’IA classe parmi les domaines à haut risque l’utilisation de l’IA pour les décisions d’admission et la gestion de l’emploi.

Confier les chiffres aux règles

Les règles déterministes prennent en charge tout ce qui comporte un montant en dollars ou entraîne des conséquences juridiques ; le modèle les interprète et les explique, sans aller plus loin.

Sur la plateforme de paie, notre objectif était d’établir une séparation nette entre les règles de paie et l’IA. Les spécialistes de la paie définissent d’abord les règles de rémunération dans un format structuré. Le système traite ensuite ces règles et génère tous les scénarios possibles qui peuvent en découler. L’ensemble complet de ces scénarios devient la source de référence du modèle. Celui-ci ne peut ni créer de nouvelles règles, ni modifier celles qui existent, ni décider quelles sources utiliser. Il peut uniquement récupérer l’ensemble de règles pertinent, consulter les barèmes et citer le scénario sur lequel il s’est appuyé. La création des règles, la génération des scénarios et le choix des sources restent entièrement en dehors de la couche d’IA.

Le produit d’admission suit la même logique : les exigences géographiques, les limites budgétaires, le statut des établissements et les seuils d’admissibilité sont appliqués sous forme de règles avant que le modèle puisse influer sur le classement. Si un étudiant indique qu’il doit fréquenter un établissement en Californie, une université située dans un autre État ne peut pas passer outre à cette exigence au motif que le modèle estime qu’elle lui conviendrait par ailleurs très bien. Le modèle prend en charge les préférences moins impératives et les explications ; la logique déterministe sert de garde-fou dès qu’une réponse simplement approximative n’est pas acceptable.

La récupération ancre le modèle, jusqu’à un certain point

La génération augmentée par récupération rattache les réponses aux propres politiques de l’organisation, plutôt qu’à tout ce que le modèle a assimilé pendant son entraînement. Cette approche est aussi survendue. Lorsque le RegLab de Stanford a testé des outils commerciaux de recherche juridique fondés sur la RAG, ceux-ci produisaient encore des hallucinations dans 17 % à 33 % des cas. La récupération restreint ce que le modèle peut dire, mais celui-ci peut toujours se tromper.

Je l’ai appris directement. Sur la plateforme de paie, le système a un jour trouvé la convention collective qui s’appliquait à un cas, mais le modèle a tout de même mal interprété les règles relatives aux heures supplémentaires. La bonne source avait été récupérée, mais la réponse était erronée ; nous avons donc ensuite considérablement restreint ce que le modèle pouvait décider de lui-même. Les règles importantes de paie ont été intégrées à une logique métier explicite, chaque réponse devait être étayée par des sources et nous avons ajouté des tests fondés sur le cas qui avait échoué. L’accès aux bonnes informations n’est utile que si l’on contrôle également la façon dont le modèle les utilise.

Rendre chaque réponse traçable

Avant la génération d’une réponse, le système consigne précisément le recueil de règles et la version utilisés, ainsi que le modèle et d’autres détails de la requête. Il est difficile de vérifier qu’une réponse de l’IA s’appuyait sur la politique de l’entreprise. Il est beaucoup plus probant d’indiquer qu’elle a été générée à partir de la version 7 d’un accord précis, qui a été conservée et peut être comparée à d’autres versions. Nous retraçons également chaque appel au modèle et à un outil : la demande de l’utilisateur, les informations récupérées, les outils exécutés, la réponse du modèle et les éventuelles erreurs survenues en cours de route. Lorsqu’un problème est signalé au service d’assistance, nous pouvons voir précisément d’où vient une réponse incorrecte. La décision concernant Air Canada rendue en 2024, par laquelle un tribunal a contraint la compagnie aérienne à honorer une réduction inventée par son robot conversationnel, montre le coût de l’alternative.

Faire intervenir des personnes là où les conséquences se jouent

Le Profil de l’IA générative du NIST considère que la distinction entre ce qu’un système fait de manière autonome et ce qui nécessite l’intervention d’une personne relève d’une décision de gouvernance. Nous transmettons un dossier à une personne lorsque le système est incertain, que les informations se contredisent ou que la décision risque d’avoir des répercussions importantes pour l’utilisateur. Pour les admissions, un profil étudiant atypique ou une recommandation qui ne répond pas clairement aux exigences impératives de l’étudiant est signalé pour examen par un conseiller d’orientation. Cette étape a permis de repérer des recommandations qui semblaient raisonnables à première vue, mais ne tenaient pas compte d’une contrainte figurant dans le profil de l’étudiant ; chacune a ensuite permis d’améliorer le système. Aucun des deux produits ne prend de décision finale de manière autonome. L’avis d’un conseiller est nécessaire avant qu’une recommandation puisse être prise en compte, et chaque bulletin de paie généré par le système est signalé pour approbation avant son envoi. L’examen humain n’est pas prévu pour chaque demande. L’objectif est d’automatiser les cas courants en toute confiance et de faire intervenir une personne lorsque le système a de bonnes raisons d’être incertain.

Déterminer ce que le modèle peut prendre en charge aujourd’hui

J’applique à chaque processus de travail un test pratique. Si une erreur peut être détectée et corrigée avant que le résultat ne parvienne à une personne, le modèle peut prendre en charge cette étape. Si la réponse peut être vérifiée à l’aune d’une règle, c’est la règle qui fait foi et le modèle l’explique. Si un résultat erroné risque d’atteindre une fiche de paie ou d’influer sur une décision d’admission avant que quiconque ne le voie, cette étape n’est pas prête.

Les modèles de langage sont les meilleurs interprètes que nous ayons jamais placés devant un recueil de règles. Dans les domaines où les erreurs ont de lourdes conséquences, ils devraient s’arrêter à l’interprétation.