GenAI-Performance unter der Lupe: Wenn Ihre Daten „alles Mögliche“ sind

Mit New Relic AI wollten wir Observability für alle bieten und Benutzer:innen erlauben, ihre Telemetriedaten alles Mögliche zu fragen. New Relic AI macht dies möglich: Kund:innen können in natürlicher Sprache mit der New Relic Database (NRDB) kommunizieren. Kenntnisse der New Relic Query Language (NRQL) ist jetzt nicht mehr notwendig und die Analyse des gesamten Tech-Stacks wird immens erleichtert. Zusätzlich kann das Tool Erkenntnisse aus unserer Dokumentations- und Wissensdatenbank ziehen und daraus verlässliche Antworten generieren sowie Systemanomalien und anderes ans Licht bringen.

Performance-Bewertung

Solide Bewertungskriterien und -protokolle sind ein Muss bei Big Data, für die sich KI-Modelle besonders eignen. Angesichts unzähliger zu treffender Entscheidungen ist eine systematische, skalierbare Bewertung unerlässlich, und herkömmliche ML-Algorithmen verfügen dazu oft über klar definierte und etablierte Bewertungsmetriken. Bei einem Fahrzeugklassifizierungsproblem könnte man zum Beispiel fragen: „Habe ich dieses Auto auf der Straße richtig erkannt?“, bei einer Fehlerregression könnte die Frage lauten: „Wie sehr weichte meine Prognose vom tatsächlichen Ergebnis ab?“

Mit der Veröffentlichung von ChatGPT wurden die Möglichkeiten dessen, was wir mit generativer KI erreichen können, noch einmal nach vorn katapultiert. Nicht nur übertrifft es alles bisher Dagewesene, es zeigt auch, was sonst noch alles möglich ist. Natürlich hat auch diese Technologie ihre Schwächen, und eine davon ist die Validierung der Performance. Tagtäglich sehen wir neue Features, die generative KI nutzen, aber die zur Messung der zugrundeliegenden Vorgänge notwendigen Bewertungslogs und -metriken müssen erst noch geschaffen werden. Outputs in natürlicher Sprache sind von Natur aus unstrukturiert, was die Erstellung dieser Logs nicht gerade einfach macht. Wir (das Team, das für New Relic AI verantwortlich ist) haben uns besonders mit diesem Aspekt befasst, denn nur so können wir ein zuverlässiges Feature liefern, das unseren Benutzer:innen echten Nutzen bietet.

Mit New Relic AI wollten wir ein Tool schaffen, das Ihnen jede beliebige Frage beantworten kann. Wie bei jedem anderen Big-Data-Projekt muss es auch hier möglich sein, die Antworten zu bewerten, damit wir das Design und die Performance optimieren können. Woher wissen wir aber, ob dabei nicht alles Mögliche falsch läuft? In diesem Blogpost möchten wir erläutern, wie wir das Problem angegangen sind.

Strategie 1: Feststellen von Bereichen, auf die sich eindeutige Erfolgskriterien anwenden lassen

Es stimmt, natürliche Sprache ist unstrukturiert. Und GenAI-gestützte Systeme wie New Relic AI können ziemlich komplex sein. Aber wir können das Ganze in kleinere Komponenten aufschlüsseln und diejenigen Teile identifizieren, für die eindeutige Erfolgskriterien definiert werden können. New Relic AI ist als modulares System konzipiert, das heißt die einzelnen, voneinander unabhängigen Komponenten sind leichter zu verwalten und ermöglichen eine systematischere Bewertung des gesamten Systems. Während der gesamten Entwicklung und Implementierung war die Messbarkeit ein wichtiger Faktor und wir konnten bestimmte Bereiche identifizieren, die sich leicht messen lassen.

Beispiel 1: Benutzeranfragen nach Use Case klassifizieren

Einer dieser Bereiche ist der erste Schritt bei der Verarbeitung einer Benutzeranfrage, nämlich die Klassifizierung der Anfragen in unterschiedliche Ströme. Wenn Sie New Relic AI eine Frage stellen, leitet das System die Frage als Erstes in den passenden Flow: Eine allgemeine Frage über New Relic führt zur Suche in unserer Dokumentation, für eine Frage über das kundenseitige System ist eine NRQL-Abfrage notwendig und eine Anfrage nach einer allgemeinen Übersicht der Fehler im System wird am besten vom Lookout-Service beantwortet. Zwar wirkt auch bei dieser Routing-Phase die generative KI mit, aber grundsätzlich geht es hier um ein Klassifikationsproblem, das heißt wir können etablierte Metriken für die Klassifizierungsbewertung anwenden. So können wir feststellen, ob unser Ansatz für die Lösung der richtige ist, und sind in der Lage, die Funktionen von New Relic AI in Zukunft durch Hinzufügen weiterer Flows auszuweiten.

Beispiel 2: Syntaxvalidierung bei NL2NRQL

Ein weiteres Beispiel wäre die Übersetzung natürlicher Sprache in NRQL (NL2NRQL). Dabei wird die Benutzereingabe, die in natürlicher Sprache erfolgte, in eine NRQL-Abfrage umgewandelt. New Relic AI ist in der Lage, die NR2NRQL-Umwandlung durchzuführen, die Abfrage mit der NRDB abzugleichen, die Daten abzurufen und dann die Ergebnisse in verständlicher Form auszugeben. Wenn Sie ChatGPT zur Unterstützung bei Programmierungsfragen verwendet haben, sind Ihnen eventuell KI-Halluzinationen untergekommen, z. B. ist ein Codeblock perfekt strukturiert, allerdings fehlt ein Keyword, eine Funktion oder ein Attribut. Das Problem wollten wir natürlich bei NL2NRQL von vornherein vermeiden und stattdessen gültige Abfragen erzeugen, mit denen die richtigen Daten abgerufen werden. Dazu können wir die erzeugte NRQL-Abfrage durch unseren Parser und Compiler laufen lassen, der die Syntax prüft, und dann durch die NRDB, um sicherzustellen, dass diese ein Ergebnis zurückgibt. Die Syntaxvalidierung durch New Relic AI erfolgt kontinuierlich und in Echtzeit, sodass nur Abfragen an Benutzer:innen zurückgegeben werden, die syntaktisch einwandfrei sind. Damit haben wir ein klares, binäres Erfolgskriterium für diesen Aspekt des Systems – das war einer der Gründe, weshalb wir von Anfang an NRQL einbeziehen wollten.

Übrigens hat OpenAI vor Kurzem mit dem Code Interpreter-Plug-in ein ähnliches Konzept eingeführt. Dabei wird der vorgeschlagene Code ausgeführt, um ihn auf Fehler zu prüfen.

Strategie 2: Der Kampf gegen Halluzinationen: Retrieval-Augmented Generation (RAG) und ein neuer Aufgabenansatz

Jedes Mal, wenn wir mit Kolleg:innen oder Bekannten über unsere Arbeit an generativer KI sprachen, kam die gleiche Rückfrage: „Was macht ihr denn mit Halluzinationen?“ 

Unter Halluzinationen versteht man ein bekanntes Problem bei GenAI-Modellen: Informationen, die sie nicht finden, denken sie sich gerne aus. Die erfundenen Informationen werden selbstbewusst und sehr überzeugend als Fakten präsentiert, ganz gleich, ob sie das wirklich sind oder nicht. Dazu gehört auch das oben erwähnte Beispiel für Syntaxhalluzinationen. Nicht nur das, die Modelle von OpenAI können zudem nur auf Informationen aus einem begrenzten Zeitraum zugreifen, sodass das verfügbare Wissen begrenzt ist. 

Für New Relic, das sich momentan komplett auf GPT-4 stützt, ist das ein echtes Problem bei Fragen zu New Relic, denn wir möchten 100 % verlässliche und aktuelle Antworten auf alle Fragen liefern, die uns gestellt werden.

RAG in der Praxis

KI-Halluzinationen werden inzwischen üblicherweise mithilfe von Retrieval-Augmented Generation (RAG) verhindert. Dabei werden relevante Informationen aus einer externen Datenbank gezogen und in die Eingabeaufforderung des Sprachmodells integriert. Der Gedanke dahinter ist: Wenn wir nicht sicher sind, dass das Sprachmodell die korrekten oder aktuelle Informationen enthält (und das kommt oft vor), dann können wir ihm die Fakten aus einer externen Quelle zuführen. Bei New Relic AI besteht diese externe Quelle aus unserer Dokumentation, die in einer Pinecone-Vektordatenbank gespeichert ist.

Die Aufgabe neu durchdacht

Nachdem der relevante Kontext nun mithilfe von RAG seinen Weg ins Modell gefunden hat, müssen wir sicherstellen, dass das Modell ihn auch nutzt, anstatt die Antworten aus seinem eingebauten Wissen zu generieren. Dazu müssen wir dem Modell die Benutzerfragen anders präsentieren, wenn es sich beispielsweise um Wissensfragen zu New Relic handelt.

Am besten lässt sich das an einem Beispiel erläutern. Angenommen, Sie haben eine Aufgabe erhalten. Im ersten Szenario sollen Sie nur eine einfache Frage beantworten, z. B. „Wer war der dritte Präsident der Vereinigten Staaten?“. Mit dieser Formulierung würde man erwarten, dass Sie eine Antwort geben, die auf Ihrem bisherigen Wissen beruht. Nun wird Ihnen dieselbe Frage gestellt, aber gleichzeitig gibt man Ihnen einen Text zu lesen, der eventuell hilfreich sein könnte. In diesem zweiten Szenario haben wir RAG eingesetzt. Wenn Sie sicherstellen möchten, dass die Antwort möglichst korrekt ist, ist dies der bessere Ansatz. Gehen wir aber noch einen Schritt weiter: Angenommen, die Anweisung lautet: „Hier ist ein Text. Finden Sie heraus, ob die Antwort auf die Frage, wer der dritte Präsident der USA war, in diesem Text zu finden ist. Wenn ja, ziehen Sie die Antwort aus dem Text.“ Dieses Szenario unterscheidet sich komplett vom ersten, da es hier um das Textverständnis geht anstatt um das Abrufen von gespeichertem Wissen.

Wir wissen, dass das Abrufen korrekter Informationen eine Schwäche der generativen KI ist und es zu Halluzinationen kommen kann, während sie in der Regel beim Textverständnis und bei der Zusammenfassung von Fakten punktet. Deshalb formulieren wir die Eingabeaufforderung wie im dritten Szenario.

Strategie 3: Vertrauen stärken durch Transparenz und klare Kommunikation

Zusätzlich geben wir den Benutzer:innen die nötigen Informationen an die Hand, damit sie sich selbst überzeugen können, wie zuverlässig New Relic AI ist. Denn wenn wir nur Antworten bereitstellen, aber keinen Kontext, wissen die Benutzer:innen nicht, ob sie sich darauf verlassen können. Deshalb sorgen wir für Transparenz im gesamten Prozess und liefern Informationen zu den Zwischenschritten des Frage-und-Antwort-Ablaufs.

Nehmen wir die Frage einer Benutzerin zu ihren eigenen Daten, z. B. „Wie viele Transaktionen hatte ich heute?“. New Relic AI informiert die Benutzerin als Erstes, dass es die Frage in eine NRQL-Abfrage umwandelt. So weiß die Benutzerin, dass wir zum Beantworten der Frage NRQL verwenden, und kann bereits beurteilen, ob der Ansatz bei dieser Frage sinnvoll ist. Als Nächstes liefert die KI die NRQL-Abfrage (z. B. SELECT count(*) FROM Transaction SINCE TODAY) und bietet eine grafische Darstellung an, die durch Abfrage von NerdGraph, unserer GraphQL-API, erstellt wurde. Und zum Schluss wird die Antwort ausgegeben, die auf den von der NRDB zurückgegebenen Daten beruht (z. B. „16.443.606.861“). Durch die transparente Darstellung des gesamten Ablaufs bis zur fertigen Antwort weiß die Benutzerin, wie diese zustande gekommen und ob sie verlässlich ist. Selbst für Benutzer:innen, die mit NRQL nicht vertraut sind, sind Abfragesyntax und Schlüsselwörter oft selbsterklärend.

Bei Wissensfragen zu New Relic verfährt New Relic AI ähnlich: Es erklärt zunächst, dass es die Dokumentation durchsucht, und liefert mit der Antwort auch Links zu den verwendeten Dokumenten.

Feedback unserer Benutzer:innen

Letztendlich zählt für uns das Urteil unserer Benutzer:innen zu den New Relic Toolsets, und wir sammeln daher laufend Feedback. Vielen Dank an alle, ob extern oder intern, die uns wertvolle Rückmeldungen gegeben haben. 

Wenn auch Sie New Relic AI benutzen, möchten wir von Ihnen hören. Indem Sie Sie jede erhaltene Antwort mit „Daumen hoch“ oder „Daumen runter“ bewerten, helfen Sie uns, das Tool zu optimieren. Alternativ können Sie auch links im Navigationsbereich über Help > Give Us Feedback zusätzliches Feedback geben.