New Relic AI parle couramment le NRQL

Alors que les systèmes actuels deviennent de plus en plus distribués, éphémères et complexes, la capacité à comprendre les subtilités de l'architecture système sur mesure de votre organisation s'accompagne souvent d'une courbe d'apprentissage, tout comme les systèmes qui vous aident à les observer. Bien que New Relic vous offre l'expérience d'une plateforme intégrée vous permettant de collecter les métriques, événements, logs et traces à partir de n'importe quelle source de données télémétriques pour générer des rapports et envoyer des alertes, il reste néanmoins possible que votre capacité à comprendre l'état de santé de votre système peut être restreinte par votre maîtrise du langage de requête New Relic (NRQL). New Relic AI réduit cette courbe d'apprentissage en vous aidant au niveau de l'acquisition des compétences requises, de l'analyse, du dépannage et du débogage à l'aide de prompts en langage naturel et d'une intégration à l'échelle de la plateforme. Ainsi, les ingénieurs et les parties prenantes non techniques peuvent obtenir des informations plus détaillées sur leurs données télémétriques et prendre des décisions plus éclairées en fonction de la santé de leurs environnements numériques.

La capacité de New Relic AI à traduire les questions posées du langage naturel en langage NRQL provient des grands modèles de langage (LLM) de pointe, tels que GPT-4 Turbo d'OpenAI. Bien que ces LLM soient robustes et instruits avec de nombreuses données web, dont la documentation New Relic, ils ne fonctionnent pas immédiatement parfaitement avec NRQL et nécessitent des instructions supplémentaires pour fonctionner comme voulu. Dans ce blog, vous découvrirez certaines des techniques utilisées par notre équipe d'ingénieurs pour optimiser la capacité de New Relic AI à générer des requêtes NRQL basées sur des entrées en langage naturel (que l'on appelle également « NL2NRQL »).

Contexte basé sur l'utilisateur et few-shot prompting

Le prompt engineering implique diverses stratégies de création et d'amélioration des prompts afin de maîtriser efficacement les capacités des LLM. Cela se déroule généralement sur plusieurs phases. En effet, il faut non seulement leur apprendre la politesse et les réponses constructives, mais il faut également affiner leurs réglages afin de promouvoir des comportements et des tâches spécifiques. Bien que les LLM aient la capacité de comprendre NRQL, ils mélangent parfois sa syntaxe avec celle de SQL (notamment pour les requêtes complexes), car les connaissances sur SQL disponibles sur Internet pour les LLM sont bien supérieures à celles qui sont disponibles dans la documentation de New Relic. Par exemple, l'expression NRQL pour filtrer les données datant d'il y a une semaine est « SINCE 1 week ago ». Mais lorsque vous essayez de générer une clause NRQL, les LLM ont tendance à utiliser par défaut la syntaxe SQL, qui renvoie « WHERE timestamp >= (CURRENT_DATE - interval '1 week') », ou une syntaxe similaire.

À chaque prompt envoyé au LLM via l'assistant, diverses techniques de prompt engineering sont utilisées pour personnaliser la sortie LLM en fonction de vos besoins et convertir la requête en réponses NRQL valides : 

1. Nous cernons tout d'abord la tâche en obtenant une liste de tous les événements de la base de données New Relic (NRDB) qui sont accessibles dans le compte et en les fournissant (avec la requête) au LLM. Le LLM peut alors faire son choix parmi les événements NRDB les plus pertinents sur la liste qui est générée. 
2. Nous récupérons ensuite le schéma de ces événements sur NRDB et nous y ajoutons des informations provenant de la documentation de New Relic. En utilisant uniquement les données NRDB disponibles pour vos autorisations utilisateurs, nous garantissons qu'aucun aspect du contexte n'est partagé avec d'autres utilisateurs et comptes. Cela aide également l'IA à gérer les situations dans lesquelles vous pouvez poser des questions sur des événements ou des attributs définis par l'utilisateur et/ou non fournis par New Relic.
3. Nous envoyons ensuite un prompt au LLM qui génère une requête NRQL comprenant les éléments suivants :
   • Une description générale des tâches. Par exemple, « vous êtes une IA qui traduit les questions des utilisateurs dans le langage de requête New Relic (NRQL). Votre tâche consiste à générer une requête basée sur une question posée par un utilisateur, les renseignements sur l'utilisateur, les descriptions du schéma de l'événement et des prompts d'exemple. »
   • Un aperçu des différences entre la syntaxe NRQL et SQL.
   • Un schéma détaillé des événements de votre compte qui correspond le mieux à votre question.
   • Des exemples d'autres questions d'utilisateurs et des réponses NRQL attendues.

La stratégie consistant à fournir des exemples de questions similaires au LLM est connue sous le nom anglais de few-shot prompting. Nous donnons au LLM des exemples de questions qui pourraient être posées par les utilisateurs et nous lui indiquons les requêtes NRQL correspondantes pour répondre à ces questions (c'est une sorte d'antisèche). Le volume et la qualité des exemples dans le pool sont cruciaux. Les exemples ainsi appariés sont stockés dans la base de données vectorielle Pinecone. Lorsque vous posez une question qui doit être traduite en NRQL, nous la transformons en vecteur d'incorporation (ou embedding) qui est une représentation numérique du texte, puis nous demandons à Pinecone de récupérer des exemples où le vecteur d'incorporation d'une question est similaire à celui que nous interrogeons. 

Malgré ces préparations, le LLM peut encore commettre des erreurs avec la syntaxe NRQL. Pour résoudre ce problème, nous avons implémenté un service de validation supplémentaire qui vérifie la requête générée. Si une requête est syntaxiquement incorrecte, elle déclenche une boucle de rétroaction : le message d'erreur est renvoyé dans le LLM avec un extrait d'exemples de syntaxe NRQL et des exemples de corrections d'erreurs courantes. Cela aboutit généralement à une requête NRQL corrigée lors de la deuxième tentative, que nous présentons ensuite à l'utilisateur avec les résultats visualisés. Si la correction échoue, nous partageons la requête avec l'utilisateur ainsi qu'un avertissement indiquant que nous n'avons pas pu générer un NRQL valide permettant de garantir la transparence. Nous monitorons ces cas et les utilisons pour améliorer notre pipeline NL2NRQL sur la base de ces apprentissages.

Apprentissages, défis et limites

Prévention des hallucinations syntaxiques

Si vous avez utilisé un LLM pour traduire un langage naturel en langage de programmation, il est possible que vous ayez rencontré des hallucinations syntaxiques : il s'agit d'un bloc de code parfaitement structuré, mais contenant un mot-clé, une fonction ou un attribut qui n'existe pas. L'utilisation par New Relic AI d'un LLM pour traduire le langage naturel en NRQL le rend susceptibles aux mêmes erreurs. Pour y arriver, nous pouvons tester la validité du NRQL généré en le faisant passer dans l'analyseur et le compilateur pour évaluer la syntaxe, puis le comparer à NRDB pour nous assurer qu'il renvoie des résultats. New Relic AI effectue la validation de la syntaxe en continu et en temps réel, et renvoie seulement les requêtes qui sont syntaxiquement correctes aux utilisateurs. Vous pouvez en savoir plus sur nos méthodes d'évaluation des performances de New Relic AI dans ce billet de blog de Tal Reisfeld, Scientifique principal des données chez New Relic.

Réponse à l’ambiguïté des questions

La modélisation d'une question en langage naturel en une question dans un langage de requête bien défini nécessite que l'IA accomplisse la tâche difficile de comprendre précisément ce qui est recherché. Par exemple, si vous demandez « Combien d’erreurs se sont produites récemment ? », notre assistant d'IA doit émettre des hypothèses sur les types d'erreurs dont vous parlez (appareils mobiles, transactions ou navigateurs ?), ainsi que sur la période la plus raisonnable qui peut être considérée comme étant « récente ».

Pour éliminer les ambiguïtés potentielles dans les requêtes des utilisateurs, nous utilisons une approche pluridimensionnelle. Nous fournissons en premier lieu des informations contextuelles sur la partie de l’interface que vous utilisez lorsque vous posez la question. Ce contexte comprend des détails tels que l'entité que vous analysez et les valeurs du sélecteur d'intervalle de temps sélectionné, et si vous éditez activement une requête NRQL, il inclura la requête elle-même. Nous élargissons ensuite notre ensemble d'exemples de few-shot prompts pour mieux démontrer le comportement attendu et fournir des informations plus complètes sur les schémas des événements et attributs fournis par New Relic. En utilisant ces informations contextuelles et exemples enrichis, notre modèle de langage comprend mieux votre intention et fournit des réponses plus précises et pertinentes, ce qui réduit ainsi les ambiguïtés.

Prédiction des métadonnées inconnues

L'architecture sans schéma de NRDB est très différente de celle des bases de données télémétriques de New Relic et des offres concurrentes et elle vous apporte une plus grande flexibilité au niveau du stockage de vos données. En outre, NRQL étant capable de lire et de récupérer des champs personnalisés, vous bénéficiez de la même flexibilité lorsque vous accédez et analysez ultérieurement ces données. Toutefois, ces attributs et événements personnalisés n'ayant pas de documentation standard, il est beaucoup plus difficile d'estimer la forme et le contenu des données qu'ils stockent. Dans de tels cas, l'IA s'appuie sur la nature descriptive des événements et des noms d'attributs définis par l'utilisateur pour rédiger des requêtes correctes.

Juste équilibre entre coût et complexité

La recherche et le développement d’une traduction NL2NRQL (du langage naturel en langage NRQL) de haute précision ont nécessité d'importants investissements en temps et en argent. Il était important pour nous de trouver le juste équilibre entre le niveau de complexité du pipeline NL2NRQL que nous pouvions gérer et le respect du temps et des ressources financières budgétisés. 

Voici quelques exemples de décisions que nous avons prises pour trouver le juste équilibre entre les performances et l’utilisation des ressources :

• Nous limitons la plage de temps de toutes les requêtes NRQL au niveau du backend pour garantir que nous limitons la consommation des ressources et réduisons le temps nécessaire à l'exécution de la requête.
• Pour les prompts où nous devons résumer la sortie NRDB, nous sélectionnons le format de représentation (par exemple, JSON ou CSV) qui minimise le nombre de jetons utilisés.
• Dans les appels LLM non orientés vers l'utilisateur, nous demandons au modèle d'IA de fournir des réponses courtes et hautement structurées. Cette approche garantit que les réponses du modèle sont plus rapides, plus rentables et plus faciles à analyser.

L'optimisation des performances et de l'utilisation des ressources est un effort continu, et nous explorons constamment différents moyens d'affiner et d'améliorer ce processus.

Améliorations continues

Les tests continus des capacités essentielles, dont la traduction NL2NRQL, restent des éléments essentiels de l'amélioration de notre assistant d'IA avec de nouveaux outils et fonctionnalités afin d'assurer une expérience utilisateur harmonieuse. L’un des domaines clés de cette étape de développement vise à créer davantage d’intégrations qui font remonter à la surface des informations full-stack détaillées par le biais de boutons et de prompts intuitifs directement dans les workflows utilisateur par le biais d'expériences de plateforme intégrées. Des exemples récents incluent un bouton « Explain this error » (Expliquer cette erreur) qui vous aide à comprendre la trace d'appels des erreurs provenant d'Errors Inbox, et une assistance au diagnostic et à la correction des logs d'erreurs. En un clic, ces intégrations lancent un prompt choisi — ainsi que le contexte précis et des garde-fous — vers l'assistant d'IA pour vous aider à rationaliser le dépannage et à améliorer l'expérience utilisateur. Ces outils spécifiques aux capacités ne sont qu'une partie de notre système d’IA composé qui donne à tous l'accès à des informations de télémétrie approfondies et détaillées permettant de prendre plus de décisions data-driven à tous les niveaux de l'organisation.