Évaluation des performances de l'IA générative : quand vos données vous apportent « les réponses dont vous avez besoin »

Notre mission derrière le développement de New Relic AI était de libérer l'observabilité pour tous afin de permettre aux utilisateurs de poser toutes les questions qu'ils souhaitent à leurs données télémétriques. New Relic AI a pu y arriver en permettant aux clients d'interagir en langage naturel avec la base de données New Relic (NRDB), en réduisant la dépendance sur les compétences requises avec le langage de requête de New Relic (NRQL) et en uniformisant l'analyse sur tous les stacks technologiques. Les autres capacités comprennent la synthèse des informations détaillées de la documentation et de la base de connaissances, le surfaçage des anomalies système et plus encore.

Évaluations des performances

La mise en place de mesures et protocoles d'évaluation robustes est un aspect essentiel du travail avec le big data, où les modèles d'IA prolifèrent. Quand il y a d'innombrables décisions à prendre, il est essentiel de les évaluer systématiquement et à l'échelle. Pour y arriver, les algorithmes d'apprentissage machine classiques comportent souvent des métriques d'évaluation bien définies et bien établies. Par exemple, en cas de problème de classification de véhicules, vous pouvez demander : « Ai-je correctement identifié cette voiture sur la route ? » ou un problème de régression, « Quelle est l'écart entre le nombre que j'ai prédit et le résultat réel ? »

Avec l'introduction de ChatGPT, OpenAI a permis de relever d'un cran la barre de ce que nous pouvons réaliser grâce à l'IA générative. Les nouvelles performances établies sont un grand pas en avant par rapport à tout ce que nous avons pu voir jusqu'à présent. Elles ont non seulement amélioré les capacités existantes, mais elles ouvrent aussi les portes à toute une nouvelle gamme de possibilités. Pourtant, cette nouvelle technologie ne vient pas sans difficulté, et l'une de ces difficultés est la validation des performances. Si chaque jour de nouvelles fonctionnalités d'IA générative voient le jour, il reste encore à établir les normes des protocoles et métriques d'évaluation servant à mesurer les tâches sous-jacentes. En effet, le caractère non structuré de la sortie en langage naturel fait de la formulation de ces protocoles une entreprise d'envergure. Nous —l'équipe de développement de l'IA chez New Relic — y faisons très attention, car il est essentiel de créer une fonctionnalité vraiment digne de confiance qui apporte de réels avantages aux utilisateurs.

Notre objectif avec New Relic AI a été de créer un outil qui peut répondre à toutes les questions que vous lui posez. Comme avec tout projet big data, nous devons évaluer les réponses pour prendre des décisions de conception éclairées et optimiser les performances. Mais comment pouvons-nous déterminer si elles sont correctes ? Dans cet article, nous partageons quelques‑unes des mesures que nous prenons pour nous attaquer à ce problème.

1^re stratégie - Identification des endroits où des mesures claires de la réussite peuvent être appliquées

Bien que le langage naturel ne soit pas structuré et que les systèmes basés sur l'IA générative comme New Relic AI puissent être complexes, nous pouvons les scinder en composants et identifier les endroits du système où des mesures claires de la réussite peuvent être définies. La conception de New Relic AI est modulaire et les composants indépendants et gérables permettent une évaluation plus systématique de tout le système. Tout au long des étapes de conception et d'implémentation, nous avons examiné l'importance de la mesurabilité et localisé les endroits précis où de telles mesures peuvent être appliquées.

Exemple 1 : Catégorisation des requêtes d'utilisateur par cas d'utilisation

L'un de ces endroits est la catégorisation des questions des utilisateurs dans différents flux. Il s'agit de la première étape du traitement de chaque utilisateur. Lorsque vous posez une question à New Relic AI, l'IA décide d'abord dans quelle catégorie la question doit être placée : est-ce une question générale sur New Relic (auquel cas, nous allons rechercher la réponse dans notre documentation), une question sur le système de l'utilisateur (ce qui exige une requête NRQL), ou une demande de visualisation globale des erreurs dans le système (et l'appel du service Lookout) ? Bien que cette étape « d'acheminement » implique l'IA générative, il s'agit essentiellement d'un problème de catégorisation, ce qui nous permet d'utiliser des métriques d'évaluation établies pour cela. Cette étape est vitale pour évaluer si nous sommes sur la bonne voie avec notre approche de la solution, et pour faire évoluer les capacités de New Relic AI en ajoutant d'autres flux possibles à l'avenir.

Exemple 2 : Validation de la syntaxe dans NL2NRQL

Un autre exemple est la traduction du langage naturel en NRQL (NL2NRQL), où nous prenons ce que dit l'utilisateur en langage naturel et nous le convertissons en une requête NRQL. New Relic AI peut lancer NR2NRQL, comparer la requête à NRDB, trouver les données, puis expliquer les résultats. Si vous avez utilisé ChatGPT pour son aide à la programmation, vous avez peut-être rencontré des hallucinations de syntaxe, où un bloc de code est parfaitement structuré, mais il contient un mot clé, une fonction ou un attribut qui n'existe pas. Il était essentiel pour nous d'éviter ce problème avec NL2NRQL et de fournir aux utilisateurs des requêtes valides qui vont réellement récupérer les données. Pour y arriver, nous pouvons tester la validité de notre NRQL généré en le faisant passer dans l'analyseur et le compilateur pour évaluer la syntaxe, puis en le comparant à la NRDB pour nous assurer qu'il renvoie des résultats. New Relic AI effectue la validation de la syntaxe en continu en temps réel, et renvoie seulement des requêtes syntaxiquement correctes aux utilisateurs. Ainsi, nous avons une mesure claire et binaire de la réussite de cet aspect du système, ce qui est l'une des nombreuses raisons pour lesquelles nous voulions développer avec NRQL dès le départ.

Incidemment, OpenAI a récemment adopté une approche similaire avec son nouveau plug-in Code Interpreter, où le code suggéré est exécuté pour vérifier qu'il est correct.

2^e stratégie - La lutte contre les hallucinations : génération augmentée de récupération (RAG) et recadrage de la tâche

Dès que nous mentionnons notre travail avec l'IA générative à nos collègues ou amis, ils posent toujours la même question : « Qu'en est-il des hallucinations ? » 

Les hallucinations sont un écueil reconnu des modèles d'IA générative ; il s'agit de la tendance à créer avec confiance des résultats infondés. Pour l'essentiel, les réponses sont toujours présentées avec confiance qu'elles soient exactes ou incorrectes (reportez-vous à notre exemple sur les hallucinations de syntaxe). En outre, les modèles OpenAI ont un seuil de connaissance qui limite les connaissances intégrées. 

Pour New Relic AI (actuellement entièrement optimisés par GPT-4), ce problème est surtout pertinent avec les réponses générales ou pratiques sur New Relic. Nous visons à fournir des informations précises et actualisées dans toutes nos réponses.

Utilisation de RAG

La génération augmentée de récupération (RAG) est désormais une pratique courante pour gérer les hallucinations. Elle implique la récupération des informations pertinentes à partir d'une base de données externe et leur incorporation dans le prompt du modèle de langage. Et cela pour une raison claire : si vous n'êtes pas sûr que les connaissances intégrées à votre modèle sont exactes pour votre cas d'utilisation (ce qui est souvent le cas), et étant donné que vous savez qu'il ne contient pas les faits les plus récents, vous pouvez envoyer les faits au modèle à partir d'une source externe. Avec New Relic AI, cette source externe est notre documentation stockée dans une base de données vectorielle Pinecone.

Recadrage de la tâche

Une fois que nous avons placé le contexte pertinent dans le modèle avec RAG, nous devons nous assurer que le modèle s'en sert vraiment au lieu d'utiliser les connaissances intégrées. Cela peut nécessiter des ajustements quant à la façon dont nous présentons la question de l'utilisateur au modèle lorsque la question porte sur les connaissances générales de New Relic.

Voici un exemple d'illustration. Imaginons que vous recevez une tâche avec des instructions spécifiques. Dans le premier scénario, on vous demande simplement de répondre à une question de type « qui était le troisième président des États‑Unis ? » Ce phrasé permet de présupposer que la réponse utilisera des connaissances préalables. Imaginons maintenant un deuxième paramètre où on nous pose la même question, mais où nous recevons en plus du texte qui peut nous aider. Dans ce cas, nous employons RAG et si notre objectif est d'optimiser l'exactitude de la réponse, cette approche donnera de meilleurs résultats. Enfin, allons encore un peu plus loin. Envisageons un troisième paramètre où les instructions sont : « Voici du texte ; la tâche consiste à déterminer si la réponse à la question « Qui était le troisième président des États‑Unis  ? » se trouve dans ce texte et si c'est le cas, fournir une explication. » Avec ce troisième cas, la tâche est complètement différente de la première, car elle se concentre sur la compréhension du texte plutôt que sur le rappel de connaissances.

Étant donné que la précision est un écueil potentiel de l'IA générative (hallucinations) et que la récapitulation et la compréhension du texte sont ces points forts, nous avons formulé notre prompt en suivant le concept du troisième paramètre.

3^e stratégie - Promotion de la fiabilité via des communications transparentes et claires

Nous avons pris une mesure supplémentaire pour améliorer la fiabilité de New Relic AI en fournissant aux utilisateurs les informations dont ils ont besoin pour évaluer les réponses elles‑mêmes. Si nous proposons des réponses sans contexte, les utilisateurs peuvent ne pas être sûrs de leur bien-fondé. Pour répondre à ce manque, nous mettons l'accent sur des communications claires tout au long du processus en ajoutant des étapes intermédiaires à différents stades du flux des questions/réponses.

Par exemple, lorsque les utilisateurs posent des questions sur leurs données (comme : « Combien de transactions ai-je obtenues aujourd'hui ? ») New Relic AI les informe tout d'abord que leur question va être convertie en requête NRQL. De cette façon, les utilisateurs savent qu'ils se servent de NRQL pour répondre à leur question et peuvent déjà évaluer si cette approche est appropriée. Ensuite, l'IA fournit la requête générée (par exemple : SELECT count(*) FROM Transaction SINCE TODAY), offre la visualisation créée en interrogeant NerdGraph — notre API GraphQL — avec la requête générée et présente enfin la réponse en fonction des données renvoyées par NRDB (par exemple : « 16 443 606 861 »). En partageant les mêmes informations utilisées pour déduire la réponse finale, les utilisateurs peuvent mieux comprendre et se fier à la réponse. Même s'ils ne maîtrisent pas NRQL, la syntaxe de la requête et les mots-clés sont souvent intuitifs et rendent ainsi la compréhension plus facile.

De même, lorsque l'IA répond à une question de connaissance sur New Relic, elle informe d'abord l'utilisateur qu'elle va faire une recherche dans la documentation, puis elle fournit les liens aux références qu'elle a utilisées avec la réponse.

Nous sommes à votre écoute

Nos utilisateurs (internes ou externes) portent le jugement définitif sur les capacités de New Relic et nous collectons continuellement leur feedback. Nous remercions tous ceux et celles qui nous ont fait part de leurs précieux commentaires. 

Si vous utilisez New Relic AI, nous aimerions savoir ce que vous en pensez. Merci de continuer à nous aider à nous améliorer en évaluant les réponses d'un pouce vers le haut ou vers le bas, ou en envoyant des commentaires supplémentaires via Help > Give Us Feedback sur le panneau de navigation sur la gauche.