L'indien NPCI teste les agents IA d'une banque : jusqu'à 12% de « succès » avec des étapes sautées

La National Payments Corporation of India (NPCI), l'organisation qui gère l'infrastructure nationale de paiement du pays, a publié le benchmark TauIndianBankBench. Il s'agit d'un ensemble de 1000 tâches où un modèle de langage joue le rôle d'assistant d'une banque de détail. Il dialogue avec un client incarné par un autre modèle et appelle des outils : bloquer une carte, clôturer un dépôt, consulter un échéancier de paiements. Principal constat des auteurs : si l'on ne vérifie que l'état final de la base de données, comme le font la plupart des tests de ce type, 6,5–12,0% des sessions « réussies » de tous les modèles contiennent en réalité une violation de procédure.

Pourquoi l'état final de la base ne suffit pas

Aujourd'hui, les banques indiennes répondent à leurs clients via des pages FAQ et des chatbots scriptés aux réponses figées. Un modèle pourrait répondre plus vite et traiter des questions absentes de la FAQ. Mais une banque ne peut lui confier ce travail que s'il fournit des informations exactes et respecte les règles internes : une erreur touche immédiatement le client.

Le problème, c'est que de nombreuses étapes obligatoires prévues par les règles n'écrivent rien dans la base. Exemples tirés de l'étude :

• avant de clôturer un dépôt, il faut obtenir le calcul de clôture pour que le client connaisse le montant de la pénalité ; • avant d'ouvrir un dépôt pour un montant que le solde du compte pourrait ne pas couvrir, il faut retrouver la règle du solde minimal ; • avant de bloquer une carte, il faut vérifier son statut.

Un agent qui a sauté toutes ces étapes laissera exactement les mêmes enregistrements dans la base. Une vérification fondée sur l'état final le laissera passer, mais le client ne recevra pas l'information pour laquelle ces étapes existent. En Inde, beaucoup de ces étapes sont imposées par la réglementation : mise à jour périodique du KYC (vérification d'identité du client), retenue à la source de l'impôt (TDS) avec formulaires d'exonération, conditions légales de participation aux plans d'épargne publics.

Deux vérifications au lieu d'une

Chaque session reçoit deux verdicts, « réussi » ou « échoué » :

• Vérification de l'état final. La chaîne d'appels de référence est rejouée sur une copie identique de la base, puis les enregistrements sont comparés. Avant la comparaison, on en retire les champs qui varient d'une exécution à l'autre : numéros générés, références, notes libres. • Vérification des actions. L'agent doit effectuer chaque appel de la chaîne de référence, lectures comprises, dans n'importe quel ordre. Toute modification que le client n'a pas demandée fait échouer la session. Même si l'agent l'a ensuite annulée : tant qu'elle était en vigueur, le client en a déjà subi le préjudice.

Une session n'est validée que si les deux vérifications sont réussies. Il n'y a pas de points partiels : trois appels sur quatre donnent zéro, tout comme l'inaction. L'évaluation est entièrement déterministe, sans modèle-juge, dont les biais favorisent les réponses longues et son propre style.

Comment le benchmark est construit

• Une banque synthétique de 944 clients : comptes, cartes, dépôts, crédits, ordres permanents, statut KYC, historique des opérations. • 34 outils : 33 outils de service et un pour transférer le client à un employé humain. Parmi les outils de service, 20 se limitent à lire des données et 13 relèvent de l'écriture (11 modifient des enregistrements, deux passent commande d'un chéquier ou d'un duplicata de relevé).

• 24 documents de base de connaissances : plafonds de paiement, mise à jour du KYC, assurance des dépôts, impôt sur les intérêts, délais de remboursement des paiements, plans publics. • 50 familles de tâches réparties en quatre catégories : tâches multi-étapes dépendantes, tâches avec une condition à repérer avant d'agir (par exemple, le client ne remplit pas les conditions), opérations rares et simples tâches de contrôle. La chaîne d'appels compte en moyenne 3,54 appels, de un à six.

• Sur les 1000 tâches, 962 exigent au moins un appel en lecture et 114 n'exigent aucune écriture.

Le benchmark propose plusieurs sous-ensembles : l'ensemble complet de 1000 tâches, une version allégée de 200 tâches (quatre par famille) et son découpage en parties d'entraînement et de test, afin d'affiner un modèle et de mesurer le résultat de façon honnête.

Aucun humain n'a rédigé les tâches de zéro : un modèle de langage les a esquissées, puis elles ont franchi quatre filtres. Les premiers messages du client doivent différer : au plus 40% des tâches d'une famille peuvent commencer de la même façon, et il faut au minimum huit variantes. Pour les tâches complexes, la chaîne doit comporter au moins trois appels. Une tâche ne peut pas figurer à la fois dans la partie d'entraînement et dans la partie de test. La chaîne de référence doit réussir les deux vérifications.

Ce que montrent les six modèles

Les auteurs ont testé six modèles ouverts, dont cinq de la famille Gemma 4. Résultats :

• pour chaque modèle, 6,5–12,0% des sessions passent la vérification de l'état final alors que l'agent a sauté un appel obligatoire ou introduit une modification superflue ; • chez les trois modèles les plus performants, la plupart des sessions qui échouent à exactement une vérification sont des violations de procédure que seule la vérification des actions détecte ; • chez le modèle le plus faible, c'est l'inverse : il effectue tous les appels nécessaires mais termine avec des enregistrements erronés, ce que seule la vérification de l'état final repère ; • les agents factices scriptés ne réussissent aucune tâche ; • sur les tâches de contrôle, le résultat ne dépend pas de la taille du modèle, tandis que les trois catégories plus difficiles permettent de départager les modèles.

Pour vérifier la fiabilité de la comparaison elle-même, l'implémentation de l'évaluateur a été confrontée à une implémentation indépendante sur 600 sessions enregistrées : les verdicts concordent partout. Avant sa publication, le package a recalculé 5000 sessions et reproduit toutes les évaluations. Le classement des modèles s'est aussi retrouvé avec un autre dispositif d'exécution des modèles.

Ce que cela signifie pour les banques et les développeurs

Qui choisit ou affine un modèle pour la banque ne peut pas se contenter de regarder l'état final des données : une partie des sessions « réussies » a en réalité enfreint le règlement, et le client n'a pas reçu les informations obligatoires. Le code, les données et les résultats de référence sont publiés sur GitHub et Hugging Face. Les limites sont elles aussi claires : la banque est synthétique, le client est joué par un modèle, et seuls des modèles ouverts ont été testés.