Was hinter den NRQL-Sprachkenntnissen von New Relic AI steckt

Heutige Systeme werden immer verteilter, kurzlebiger und komplexer. Deshalb geht das Erlernen aller Einzelheiten der individuell auf Ihr Unternehmen zugeschnittenen Systemarchitektur mit einer steilen Lernkurve einher. Das Gleiche gilt für die Systeme, mit denen Sie sie überwachen. New Relic ermöglicht Ihnen zwar das Erfassen, Reporting und Alerting zu Metriken, Events, Logs und Traces aus beliebigen Telemetriedatenquellen in einer integrierten Plattform. Wenn Ihnen aber unsere proprietäre Abfragesprache New Relic Query Language (NRQL) nicht vertraut genug ist, ist es nicht ganz einfach für Sie, den Zustand Ihres Systems zu verstehen. New Relic AI macht Ihnen die Sache leichter, indem es Sie mithilfe von Prompts in natürlicher Sprache und mit plattformweiten Integrationen bei Onboarding, Analyse, Fehlerdiagnose und Fehlerbehebung unterstützt. So können sowohl Engineers als auch Stakeholder ohne technische Kenntnisse bessere Einblicke in ihre Telemetriedaten gewinnen und anhand der Integrität ihrer digitalen Umgebungen fundiertere Entscheidungen treffen.

Die Fähigkeit von New Relic AI, Fragen in natürlicher Sprache in NRQL umzuwandeln, basiert auf den neuesten Large Language Models (LLMs) wie GPT-4 Turbo von OpenAI. Obwohl diese LLMs robust sind und anhand umfassender Webdaten, einschließlich der New Relic Dokumentation, trainiert wurden, funktionieren sie nicht sofort perfekt mit NRQL und erfordern zusätzliche Anweisungen, um die erwartete Leistung zu erbringen. In diesem Blog erfahren Sie mehr über einige der Techniken, die unser Entwicklungsteam eingesetzt hat, um die Fähigkeit von New Relic AI zu optimieren, NRQL-Abfragen auf der Grundlage natürlicher Spracheingaben zu generieren – eine Fähigkeit, die wir intern als „NL2NRQL“ bezeichnen. 

Benutzerbasierter Kontext und Few-Shot Prompting

Prompt Engineering umfasst verschiedene Strategien zur Erstellung und Verbesserung von Prompts, um die Fähigkeiten von LLMs effektiv zu nutzen. Dies geschieht normalerweise stufenweise; neben dem Erlernen von Höflichkeit und konstruktiven Antworten ist eine Feinabstimmung erforderlich, um bestimmte Verhaltensweisen und Aufgaben zu fördern. Obwohl LLMs in der Lage sind, NRQL zu verstehen, vermischen sie deren Syntax manchmal mit SQL (insbesondere bei komplexen Abfragen). Dies liegt daran, dass die Menge an SQL-Wissen, die LLMs im Internet zur Verfügung steht, weitaus größer ist als das, was in der New Relic Dokumentation verfügbar ist. Beispielsweise lautet der NRQL-Ausdruck zum Herausfiltern einwöchiger Daten „SINCE 1 week ago“. Beim Versuch, eine NRQL-Klausel zu generieren, greifen LLMs jedoch standardmäßig auf die SQL-Syntax zurück und geben so etwas wie WHERE timestamp >= (CURRENT_DATE - interval '1 week') zurück.

Bei jedem Prompt, die über den Assistenten an das LLM gesendet wird, werden verschiedene Prompt-Engineering-Techniken verwendet, um den LLM-Output an Ihre Bedürfnisse anzupassen und Ihre Abfragen in gültige NRQL-Antworten umzuwandeln: 

1. Wir grenzen die Aufgabe zunächst ein, indem wir eine Liste aller in Ihrem Konto zugänglichen New-Relic-Datenbank(NRDB)-Events erstellen und diese zusammen mit Ihrer Abfrage dem LLM zur Verfügung stellen. Dadurch wird eine Liste der relevantesten NRDB-Events generiert, aus denen das LLM auswählen kann. 
2. Anschließend rufen wir das Schema dieser Events aus NRDB ab und ergänzen sie durch Informationen aus der New Relic Dokumentation. Indem wir nur NRDB-Daten verwenden, die gemäß Ihren Benutzerberechtigungen zur Verfügung stehen, stellen wir sicher, dass kein Kontext zwischen anderen Benutzer:innen oder Konten geteilt wird. Dies hilft der KI auch in Situationen, in denen Sie möglicherweise nach Events oder Attributen fragen, die benutzerdefiniert sind und/oder nicht von New Relic bereitgestellt werden.
3. Als Nächstes senden wir einen Prompt an das LLM, das eine NRQL-Abfrage mit folgendem Inhalt generiert:
   • Eine allgemeine Aufgabenbeschreibung, zum Beispiel: „Du bist eine KI, die Benutzerfragen in NRQL-Abfragen übersetzt. Deine Aufgabe ist es, eine Abfrage basierend auf einer Benutzerfrage, Benutzerinformationen, Event-Schema-Beschreibungen und Beispiel-Prompts zu generieren.“
   • Eine Übersicht der Unterschiede zwischen der NRQL-Syntax und SQL.
   • Ein detailliertes Schema der Events aus Ihrem Konto, das am besten zu Ihrer Frage passt.
   • Beispiele für andere Benutzerfragen und erwartete NRQL-Antworten.

Die Strategie, Beispiele für ähnliche Fragen ans LLM bereitzustellen, wird als Few-Shot Prompting bezeichnet. Wir stellen dem LLM Beispiele für mögliche Fragen sowie die entsprechenden NRQL-Abfragen zur Verfügung, die es unserer Erwartung nach für solche Fragen ausgeben soll (als eine Art Spickzettel). Dabei sind die Menge und Qualität der Beispiele im Pool von entscheidender Bedeutung. Die Beispielpaare sind in Pinecone, einer Vektordatenbank, gespeichert. Wenn Sie eine Frage stellen, die in NRQL übersetzt werden muss, wandeln wir sie in einen Einbettungsvektor um (eine numerische Darstellung des Textes) und fragen dann Pinecone ab, um Beispiele zu erhalten, bei denen der Einbettungsvektor einer Frage dem von uns abgefragten ähnelt. 

Selbst mit solchen Vorbereitungen können dem LLM immer noch Fehler bei der NRQL-Syntax unterlaufen. Um dies zu beheben, haben wir einen zusätzlichen Validierungsdienst implementiert, der die generierten Abfragen überprüft. Wenn eine Abfrage syntaktisch falsch ist, löst sie eine Feedbackschleife aus: Die Fehlermeldung wird zusammen mit einem Ausschnitt von NRQL-Syntaxbeispielen und Beispielen zur Korrektur häufiger Fehler an das LLM zurückgemeldet. Daraus resultiert typischerweise im zweiten Versuch eine korrigierte NRQL-Abfrage, die wir den Benutzer:innen anschließend komplett mit visualisierten Ergebnissen präsentieren. In Fällen, in denen die Korrektur nicht erfolgreich ist, geben wir die Abfrage an den oder die Benutzer:in weiter, fügen allerdings für maximale Transparenz den Hinweis hinzu, dass wir keine gültige NRQL-Abfrage generieren konnten. Wir beobachten solche Fälle und nutzen sie, um auf der Grundlage dieser Erkenntnisse unsere NL2NRQL-Pipeline zu verbessern.

Erkenntnisse, Herausforderungen und Einschränkungen

Syntax-Halluzinationen verhindern

Wenn Sie ein LLM verwendet haben, um natürliche Sprache in eine Programmiersprache zu übersetzen, sind Ihnen eventuell Syntax-Halluzinationen untergekommen, z. B. ist ein Codeblock perfekt strukturiert, allerdings fehlt ein Keyword, eine Funktion oder ein Attribut. Die Verwendung eines LLM durch New Relic AI zur Übersetzung natürlicher Sprache in NRQL macht es anfällig für dieselben Fehler. Um Syntax-Halluzinationen zu vermeiden, testen wir die Gültigkeit der erzeugten NRQL-Abfrage, indem wir sie durch unseren Parser und Compiler laufen lassen, der die Syntax prüft, und dann durch die NRDB, um sicherzustellen, dass diese Ergebnisse zurückgibt. Die Syntaxvalidierung durch New Relic AI erfolgt also kontinuierlich und in Echtzeit, sodass nur Abfragen an Benutzer:innen zurückgegeben werden, die syntaktisch einwandfrei sind. Mehr über unsere Methoden zur Bewertung der Performance von New Relic AI erfahren Sie in diesem Blogbeitrag von Tal Reisfeld, Senior Data Scientist bei New Relic.

Mehrdeutigkeiten bei Fragen beheben

Um eine Frage in einer natürlichen Sprache zu einer Frage in einer klar definierten Abfragesprache zuzuordnen, muss unsere KI genau verstehen, wonach gesucht wird – eine anspruchsvolle Aufgabe. Angenommen, Sie fragen: „Wie viele Fehler sind in letzter Zeit aufgetreten?“ Unser KI-Assistent muss Vermutungen darüber anstellen, nach welchen Fehlertypen Sie fragen (mobil, Transaktion oder vielleicht Browser?), und auch den Zeitraum ermitteln, der als „in letzter Zeit“ betrachtet werden kann.

Um mögliche Mehrdeutigkeiten in Benutzerabfragen auszuräumen, verwenden wir einen mehrgleisigen Ansatz. Zunächst stellen wir Kontextinformationen darüber bereit, welchen Teil der UI Sie gerade verwenden, wenn Sie die Frage stellen. Dazu gehören Details wie die Entity, die Sie momentan analysieren, und die angegebenen Zeitauswahlwerte. Falls Sie aktiv eine NRQL-Abfrage bearbeiten, umfasst der Kontext die Abfrage selbst. Zweitens erweitern wir unsere Few-Shot-Beispielsammlung, um das erwartete Verhalten besser vorzugeben und umfassendere Informationen zu den Schemata der von New Relic bereitgestellten Events und Attribute bereitzustellen. Durch die Verwendung dieser Kontextinformationen und erweiterten Beispiele versteht unser Sprachmodell Ihre Absichten besser und bietet genauere und relevantere Antworten, wodurch Mehrdeutigkeiten reduziert werden.

Unbekannte Metadaten vorhersagen

Die schemalose Architektur von NRDB unterscheidet New Relic Telemetrie-Datenbanken deutlich von Konkurrenzangeboten und bietet Ihnen überlegene Flexibilität bei der Speicherung Ihrer Daten. Und da NRQL benutzerdefinierte Felder lesen und abrufen kann, profitieren Sie von der gleichen Flexibilität, wenn Sie später auf diese Daten zugreifen und sie analysieren. Da diesen benutzerdefinierten Events und Attributen jedoch eine Standarddokumentation fehlt, ist es weitaus schwieriger, die Form und den Inhalt der darin gespeicherten Daten abzuschätzen. In solchen Fällen verlässt sich die KI auf die deskriptive Natur der von Benutzer:innen erstellten Events und Attributnamen, um korrekte Abfragen zu schreiben.

Kosten und Komplexität abwägen

Forschung und Entwicklung an einer hochpräzisen NL2NRQL-Übersetzung erforderte erhebliche finanzielle und zeitliche Investitionen. Für uns war es wichtig, eine Balance zu finden zwischen einem Komplexitätsgrad der NL2NRQL-Pipeline, den wir bewältigen konnten, und den budgetierten Zeit- und Finanzressourcen. 

Hier sind einige Beispiele für Entscheidungen, die wir getroffen haben, um Performance und Ressourcennutzung ins Gleichgewicht zu bringen:

• Wir begrenzen die Zeitspanne aller NRQL-Abfragen im Backend, um den Ressourcenverbrauch einzuschränken und die zur Ausführung der Abfragen erforderliche Zeit zu reduzieren.
• Für Prompts, bei denen wir den NRDB-Output zusammenfassen müssen, wählen wir jeweils das Darstellungsformat (z. B. JSON oder CSV), das die Anzahl der verwendeten Token minimiert.
• Bei internen LLM-Aufrufen weisen wir das KI-Modell an, kurze, hochstrukturierte Antworten bereitzustellen. Dieser Ansatz stellt sicher, dass die Antworten des Modells schneller, kostengünstiger und einfacher zu parsen sind.

Die Optimierung von Performance und Ressourcennutzung ist ein laufendes Unterfangen und wir erkunden ständig Möglichkeiten, diesen Prozess zu verfeinern und zu verbessern.

Laufende Verbesserungen

Das kontinuierliche Testen wesentlicher Fähigkeiten, einschließlich NL2NRQL-Übersetzung, gehört weiterhin zur Optimierung unseres KI-Assistenten durch neue Tools und Funktionen, um ein nahtloses Endbenutzererlebnis zu gewährleisten. Ein wichtiger Schwerpunkt dieser Entwicklungsphase besteht darin, mehr Integrationen zu schaffen, die durch eingebettete Plattformerlebnisse proaktiv Full-Stack-Einblicke über intuitive Schaltflächen und Prompts direkt in Benutzerworkflows zum Vorschein bringen. Zwei der jüngsten Beispiele sind eine Schaltfläche zum Aufrufen von Fehlererläuterungen, die Ihnen helfen, Stack-Traces von Fehlern aus Errors Inbox zu verstehen, sowie eine weitere ähnliche Funktion, die Ihnen bei der Diagnose und Behebung von Fehlerlogs hilft. Mit einem Mausklick wird durch diese Integrationen ein kuratierter Prompt zusammen mit spezifischem Kontext und mit Leitlinien für den KI-Assistenten ausgeführt. Das straffte das Troubleshooting und hilft Ihnen, das Endbenutzererlebnis zu verbessern. Diese Toolset-spezifischen Tools sind nur ein Teil unseres umfassenden KI-Systems, das den Zugriff auf tiefgreifende Telemetrie-Einblicke für bessere datengestützte Entscheidungen im gesamten Unternehmen demokratisiert.