Les résurrections métriques : action ! Action! Action!

Arrière-plan

Voyant l’étonnante réponse aux 3 premiers articles de cette série, j’ai dû en sortir une 4ème partie.

Dans les 3 articles précédents, nous avons discuté des définitions des métriques de performances, de l'instrumentation et de l'évolutivité des agents d'IA de conversation. Si vous n'avez pas consulté les articles précédents, voici les liens :

• Partie 1 - Métriques : avalez la pilule rouge
• Partie 2 - Métriques rechargées : l'Oracle
• Partie 3 - La révolution des métriques : mise à l'échelle

Dans cet article, nous discuterons de la manière de rendre ces métriques plus exploitables (en utilisant les dernières avancées du LLM) afin d'améliorer les performances de manière continue. L'objectif sera de maintenir la discussion simplifiée et d'un niveau assez élevé pour tous ceux qui travaillent dans ce domaine.

Le problème

Les métriques perçues par l'utilisateur et les métriques signalées par l'utilisateur sont deux classes de métriques de haut niveau dont nous avons discuté. Traditionnellement, la première est considérée comme une métrique au niveau du système : ces métriques sont mesurées directement à partir des journaux. En conséquence, les métriques perçues par l’utilisateur sont exploitables par nature et donc opérationnelles.

Les mesures opérationnelles sont suivies régulièrement à partir des journaux de production et peuvent être utilisées pour définir des objectifs par rapport aux OKR à l'échelle de l'équipe.

Cependant, même si les métriques perçues par l'utilisateur sont faciles à opérationnaliser, il convient de noter qu'il s'agit de métriques d'utilisateur « perçues » et non « réelles ». Par conséquent, l’escalade de ces métriques pourrait ne pas conduire à une amélioration significative de la perception des utilisateurs de votre agent d’IA conversationnel. Cela pourrait conduire à une gestion inefficace des ressources si ces projets s'étendent sur plusieurs trimestres.

Il doit y avoir un moyen de mesurer l'impact attendu de toutes les améliorations de performances directement par rapport aux métriques signalées par l'utilisateur. Cela devrait être traité comme l’ impact de « l’étoile du Nord ». Alors quel est le problème?

Les commentaires directs des utilisateurs ne devraient pas être structurés, ce qui les rend non exploitables et différents à opérationnaliser.

Les commentaires détaillés rapportés par les utilisateurs doivent être non structurés par nature. Si les commentaires rapportés par les utilisateurs sont structurés, ils peuvent alors se concentrer sur des domaines dont l'équipe interne est déjà consciente. En plus de cela, les mesures signalées par les utilisateurs sont également affectées par des facteurs tels que la saisonnalité et la perception de l'entreprise.

L'impact sur les métriques perçues par l'utilisateur peut être estimé avec plus de précision, mais les métriques signalées par l'utilisateur comportent de nombreux facteurs incontrôlables.

Solution

Les commentaires non structurés signalés par l'utilisateur doivent être convertis dans un format structuré pouvant être rendu exploitable. Il peut exister des modèles de ML spécifiques formés dans le but de convertir les commentaires non structurés en métriques existantes au niveau du système.

Il convient de noter qu'il pourrait être plus pratique d'utiliser l'objectif principal des métriques signalées par les utilisateurs pour les régressions « récentes » des métriques des utilisateurs afin de se protéger contre le biais inhérent à ces métriques. Pour les projets à long terme plus horizontaux , ces métriques doivent être utilisées pour mesurer l'impact sur la perception des utilisateurs ainsi que les métriques au niveau du système.

Les LLM changent la donne

Maintenant, la question demeure : quel est l'effort nécessaire pour former les modèles ML pour les métriques spécifiques que nous recherchons ? Avec la récente augmentation de la popularité et de la disponibilité des LLM, il pourrait être possible d'utiliser des API prêtes à l'emploi pour convertir les commentaires non structurés en quelque chose qui peut être suivi et mesuré de la même manière que les métriques au niveau du système.

Il est important de noter qu’avec l’augmentation du nombre de jetons que les LLM peuvent traiter, de nombreuses informations spécifiques au produit peuvent être fournies dans le cadre de l’« invite » elle-même. En conséquence, les API LLM disponibles dans le commerce ainsi qu'une ingénierie rapide peuvent fournir des métriques exploitables signalées par l'utilisateur.

Cela fournit un moyen très rapide d'évaluer l'impact des projets d'amélioration des métriques au niveau du système sur la perception des utilisateurs, ce qui peut être utile pour prioriser les projets d'amélioration des performances.

Même avec cette approche de métriques structurées signalées par les utilisateurs, il reste encore de la place pour des changements inattendus. Cependant, on peut supposer avec un certain niveau de confiance que si un projet spécifique (visant à améliorer une métrique au niveau du système) finit par avoir un impact positif sur les métriques rapportées, alors le projet améliore probablement réellement la perception des utilisateurs.

Cependant, rien ne garantit que tous les changements réellement « bons » amélioreront toujours efficacement les métriques signalées par les utilisateurs. Par conséquent, il est important d’utiliser une combinaison des deux pour prioriser et évaluer les projets d’amélioration des performances.