Le seuil est un prix, pas un pourcentage

avoir une ligne comme ESCALATION_THRESHOLD = 0.90. Au-dessus, l’agent agit. En dessous, un humain reçoit un ping.

C’est simple. C’est réglable. Cela permet à chacun de sentir que son autonomie est sous contrôle.

Mais ce n’est pas la bonne solution.

Le correctif n’est pas un meilleur numéro. Le correctif remarque que le seuil d’escalade n’a jamais été un pourcentage en premier lieu. C’est un prix.

Commencez par la mauvaise question

La plupart des équipes posent une question de capacité. L’agent peut-il écrire le SQL ? Peut-il procéder au remboursement ? Si oui, laissez-le fonctionner.

Mais être capable de faire quelque chose et décider de le faire seul sont des problèmes différents. La seconde concerne vraiment la décision elle-même : combien coûte une erreur, et combien coûte l’implication d’un humain à la place ?

C’est le vrai choix. Si l’agent agit, vous risquez le prix d’une erreur. Si vous faites une escalade, vous payez le temps d’un humain, que l’agent ait eu raison ou non.

Mettez des chiffres dessus et la comparaison est d’une simplicité presque embarrassante. Une hypothèse d’abord : l’humain obtient correctement les tickets escaladés. Nous y reviendrons plus tard. Pour l’instant, agissez seul lorsque :

(1 - p) * cost_of_error  <  cost_of_escalation

où p est la probabilité que l’agent ait raison. Réorganisé, escalader à chaque fois :

p  <  1 - (cost_of_escalation / cost_of_error)

Cette valeur à droite est le véritable seuil. Remarquez de quoi cela dépend. Pas le modèle. Ce n’est pas une politique issue d’un atelier. Juste un rapport entre deux coûts. Si les erreurs sont peu coûteuses, le seuil est plus bas et l’agent peut agir plus souvent. Si les erreurs coûtent cher, le seuil est plus élevé et même un agent confiant devrait demander de l’aide.

Un seuil fixe suppose que le ratio est le même pour chaque décision à laquelle l’agent sera confronté. C’est rare.

Cette approche est basée sur la règle de rejet de Chow de 1970, qui constitue le fondement de la recherche actuelle sur l’apprentissage du report. Les vieilles idées vieillissent bien lorsqu’elles sont justes.

Deux billets

Le moyen le plus simple de le montrer : le tri des tickets d’assistance. Un agent lit les tickets entrants et les résout ou les achemine vers une personne. Les chiffres ici sont inventés pour l’argumentation, mais ils tiennent ensemble.

Une demande de remboursement de routine. Petit montant, politique claire. Si l’agent le bâcle, le nettoyage est un ticket de suivi et un crédit de bonne volonté. Appelez ça 15 £. L’escalade consomme environ trois minutes du temps d’un spécialiste. Appelez ça 4 £.

Le seuil ressort à 1 moins 4/15. Environ 0,73.

Ainsi, si l’agent est confiant à 90 %, il doit clairement agir. L’escalade coûterait 4 £ pour éviter seulement 1,50 £ d’erreur attendue. Lorsque vous le dites à voix haute, personne ne ferait cette transaction, mais un seuil fixe le fait automatiquement toute la journée.

Maintenant, un possible rachat de compte. Un client signale un changement de mot de passe qu’il n’a pas effectué. Si l’agent traite cela comme une routine, l’inconvénient n’est pas un crédit. Il s’agit d’une perte due à la fraude, de mesures correctives, d’une exposition réglementaire, d’un client qui ne revient jamais. Mettez-y une somme conservatrice de 2 000 £. L’escalade coûte toujours 4 £.

Le nouveau seuil est de 1 moins 4/2000, soit 0,998. En pratique, cela signifie que vous devez toujours escalader la situation. Avec un niveau de confiance de 90 %, laisser l’agent agir seul risque de coûter 200 £, contre seulement 4 £ pour une augmentation. C’est cinquante fois moins cher de le remettre.

Même agent. Même 90%. Réponses correctes opposées. La règle des 90 % dit d’agir dans les deux cas, et dans le second, elle brûle tranquillement 196 £ par ticket pour faire gagner trois minutes à quelqu’un.

Cette observation atterrit généralement dans la conversation.

Une ride honnête. L’exemple suppose que l’agent sait quel ticket il détient. Dans le vrai tri, c’est là l’incertitude. Si l’agent est sûr à 90 % qu’un ticket est un remboursement de routine, une partie des 10 % restants pourrait être une prise de contrôle déguisée. Pondérez donc le coût de l’erreur en fonction de ce que pourrait être le ticket, et non de ce qu’il est probablement. En cas de doute, évaluez-le comme la pire classe plausible. Les billets bon marché sont exactement l’endroit où se cachent des erreurs coûteuses.

Le piège

Toute cette arithmétique repose sur une seule hypothèse. Lorsque l’agent dit 90 %, c’est vrai environ 90 % du temps.

C’est de l’étalonnage, et ce n’est pas la même chose que de la confiance. La confiance est un nombre émis par le modèle. L’étalonnage consiste à savoir si le nombre signifie quelque chose.

Insérez cela dans la règle et regardez-la se briser. Si 0,95 indiqué signifie en réalité 0,70, votre coût d’erreur attendu est six fois supérieur à ce que prétend l’arithmétique. Le seuil que vous avez fixé avec tant de soin est une fiction. Vous ne gérez plus les risques. Vous le blanchissez grâce à un nombre qui ressemble à une probabilité mais n’en est pas une.

Alors avant tout cela, vérifiez le numéro. Enregistrez chaque décision avec sa confiance déclarée. Compartiment par bande de confiance, par classe de décision. Comparez la précision déclarée avec la précision réalisée dans chaque compartiment. Si l’agent dit 90 % et atteint 78 %, vous avez trouvé votre correction : mappez-les l’un sur l’autre avant que quoi que ce soit n’atteigne le seuil. La régression isotonique ou la mise à l’échelle de Platt feront l’affaire.

Deux détails piquent ici. Les agents sont souvent les moins bien calibrés sur la classe rare et aux enjeux élevés, précisément parce qu’elle est rare. C’est la classe qui atteint votre seuil extrême, donc une moyenne mondiale cache l’échec qui compte. Et la carte dérive à mesure que la composition des billets change, alors mesurez-la à nouveau selon un calendrier. La technique compte moins que l’habitude. Tant que vous n’avez pas mesuré l’écart, aucun seuil n’a gagné votre confiance.

La règle dans le code

Le voici comme jouet pédagogique. Quelques lignes pour rendre la structure visible, pas quelque chose que j’ai construit ou expédié.

def should_act_autonomously(stated_confidence: float,
                            cost_of_error: float,
                            cost_of_escalation: float,
                            calibrate) -> bool:
    """
    Teaching toy: act alone or escalate, by expected cost.

    `calibrate` maps stated confidence to a measured
    probability of being correct, built from logged
    decisions and realised outcomes.
    """
    p_correct = calibrate(stated_confidence)

    expected_cost_of_acting = (1 - p_correct) * cost_of_error
    expected_cost_of_asking = cost_of_escalation

    return expected_cost_of_acting < expected_cost_of_asking

Il n’y a rien d’extraordinaire dans la fonction. Ce qui compte vraiment, c’est la façon dont vous choisissez les trois entrées. C’est là que devraient aller vos efforts, plutôt que de débattre pour savoir si le nombre magique devrait être 0,85 ou 0,92.

Où les chiffres deviennent compliqués

Deux facteurs rendent les saisies plus compliquées.

Le coût d’escalade ne se résume pas à quelques minutes multipliées par le salaire. Les escalades s’accumulent dans une file d’attente et les files d’attente se congestionnent. Pire encore, une escalade excessive entraîne les évaluateurs à approuver sans discussion. Envoyez à quelqu’un quarante remboursements de routine par heure et en une semaine, il ne les lit plus. Un humain qui approuve tout n’est pas un contrôle. C’est un rituel. La hausse marginale coûte donc plus cher qu’il n’y paraît, et l’écart se creuse avec le volume.

Et rappelez-vous l’hypothèse que nous avons formulée plus tôt : l’humain a raison. Souvent, ce n’est pas le cas. Donnez au spécialiste un taux d’erreur h et la règle devient effective lorsque (1 − p) × coût d’erreur est inférieur au coût d’escalade plus h × coût d’erreur. Habituellement, h est suffisamment petit pour être ignoré. Sur les tickets véritablement ambigus, ce n’est pas le cas et cela fait pencher le seuil vers l’agent. Cela surprend les gens.

Aucune de ces questions ne change l’approche globale ; ils affectent simplement les chiffres. C’est l’avantage d’utiliser une méthode numérique.

Faire cela pour votre propre agent

La procédure est courte.

Tout d’abord, regroupez les décisions de l’agent en classes où le coût d’une erreur est à peu près le même. Par exemple, placez les remboursements dans une classe et les incidents de sécurité dans une autre. Si vous ne pouvez pas estimer le coût d’une erreur pour une classe, c’est qu’elle n’est pas encore prête pour l’autonomie. En fait, comprendre cela est une partie précieuse du processus.

Ensuite, évaluez chaque classe. Parlez aux personnes qui nettoient les dégâts, pas seulement à celles qui ont construit l’agent. Les opérations financières et de support connaissent ces chiffres mieux que l’ingénierie, et elles sont généralement ravies que quelqu’un leur pose enfin la question.

Estimez également le coût de l’escalade, y compris les effets de la congestion et de l’approbation automatique.

Utilisez la probabilité corrigée dans votre règle, pas le score brut.

Dernière étape : dériver le seuil par classe à partir du ratio de coûts et le laisser évoluer lorsque les coûts évoluent. Un nouveau modèle de fraude augmente le prix d’une erreur de sécurité, de sorte que le seuil augmente avec elle. Aucune réunion n’est requise, car elle est dérivée plutôt que décrétée.

Au final, votre agent aura plusieurs seuils, pas un seul. Elle disposera de plus d’autonomie là où les erreurs sont peu coûteuses, et bien moins là où les erreurs coûtent cher. Le modèle et la comparaison restent les mêmes.

Et c’est la réponse honnête à la question avec laquelle tout le monde commence. « Dans quelle mesure mon agent doit-il être confiant avant d’agir seul ? » on ne peut pas y répondre, car il est sous-spécifié. « Combien coûte un mauvais appel ici, et combien coûte une demande ? » peut. Définissez le seuil sous forme de prix. Le pourcentage s’arrange tout seul.