Die Wiederauferstehung der Metriken: Aktion! Aktion! Aktion!

Hintergrund

Angesichts der erstaunlichen Resonanz auf die ersten drei Artikel dieser Reihe musste ich einen vierten Teil herausbringen.

In den vorherigen 3 Artikeln haben wir Leistungsmetrikdefinitionen, Instrumentierung und Skalierbarkeit für Konversations-KI-Agenten besprochen. Falls Sie die vorherigen Artikel noch nicht gelesen haben, hier die Links:

• Teil 1 - Kennzahlen: Schlucken Sie die rote Pille
• Teil 2 - Metrics Reloaded: Das Orakel
• Teil 3 - Die Metrik-Revolution: Skalierung

In diesem Artikel besprechen wir, wie wir diese Kennzahlen (mithilfe der neuesten LLM-Fortschritte) umsetzbarer machen können, um die Leistung kontinuierlich zu verbessern. Ziel ist es, die Diskussion für alle, die in diesem Bereich arbeiten, vereinfacht und auf einem relativ hohen Niveau zu halten.

Das Problem

Vom Benutzer wahrgenommene Metriken und vom Benutzer gemeldete Metriken sind zwei hochrangige Metrikklassen, die wir besprochen haben. Traditionell wird Ersteres als Metrik auf Systemebene betrachtet – diese Metriken werden direkt aus Protokollen gemessen. Daher sind vom Benutzer wahrgenommene Metriken von Natur aus umsetzbar und daher betriebsbereit.

Betriebskennzahlen werden regelmäßig anhand von Produktionsprotokollen verfolgt und können zur Zielsetzung für teamweite OKRs verwendet werden.

Obwohl sich vom Benutzer wahrgenommene Metriken leicht operationalisieren lassen, sollte beachtet werden, dass es sich dabei um „wahrgenommene“ und nicht um „tatsächliche“ Benutzermetriken handelt. Daher führt das Anheben dieser Metriken möglicherweise nicht zu einer signifikanten Verbesserung der Benutzerwahrnehmung Ihres Konversations-KI-Agenten. Dies kann zu einer ineffizienten Ressourcenverwaltung führen, wenn sich diese Projekte über mehrere Quartale erstrecken.

Es muss eine Möglichkeit geben, die erwarteten Auswirkungen aller Leistungsverbesserungen direkt anhand der vom Benutzer gemeldeten Metriken zu messen. Dies sollte als „Nordstern“-Auswirkung behandelt werden. Also, wo liegt das Problem?

Direktes Benutzerfeedback ist voraussichtlich unstrukturiert, nicht umsetzbar und schwer zu operationalisieren.

Detailliertes benutzerberichtetes Feedback sollte von Natur aus unstrukturiert sein. Wenn das benutzerberichtete Feedback strukturiert ist, kann es sich auf Bereiche konzentrieren, die dem internen Team bereits bekannt sind. Darüber hinaus werden benutzerberichtete Metriken auch von Faktoren wie Saisonalität und Unternehmenswahrnehmung beeinflusst.

Die Auswirkungen auf vom Benutzer wahrgenommene Metriken können genauer geschätzt werden, aber von Benutzern gemeldete Metriken enthalten viele unkontrollierbare Faktoren.

Lösung

Das unstrukturierte Feedback des Benutzers sollte in ein strukturiertes Format umgewandelt werden, das umsetzbar ist. Es können spezielle ML-Modelle trainiert werden, um unstrukturiertes Feedback in vorhandene Metriken auf Systemebene umzuwandeln.

Es sollte beachtet werden, dass es praktischer sein könnte, das Hauptziel von User Reported Metrics für „aktuelle“ Regressionen von Benutzermetriken zu verwenden, um sich vor der inhärenten Schiefe dieser Metriken zu schützen. Bei horizontaleren Langzeitprojekten sollten diese Metriken zusammen mit Metriken auf Systemebene verwendet werden, um die Auswirkungen auf die Benutzerwahrnehmung zu messen.

LLMs verändern das Spiel

Nun bleibt die Frage, wie viel Aufwand erforderlich ist, um ML-Modelle für die spezifischen Metriken zu trainieren, nach denen wir suchen. Angesichts der in letzter Zeit gestiegenen Popularität und Verfügbarkeit von LLMs könnte es möglich sein, sofort einsatzbereite APIs zu verwenden, um unstrukturiertes Feedback in etwas umzuwandeln, das ähnlich wie Metriken auf Systemebene verfolgt und gemessen werden kann.

Es ist wichtig zu beachten, dass mit der zunehmenden Anzahl von Token, die LLMs verarbeiten können, viele produktspezifische Informationen als Teil der „Eingabeaufforderung“ selbst bereitgestellt werden können. Infolgedessen können handelsübliche LLM-APIs zusammen mit etwas Eingabeaufforderungs-Engineering umsetzbare, vom Benutzer gemeldete Metriken bereitstellen.

Auf diese Weise lässt sich die Auswirkung von Projekten zur Verbesserung der Messgrößen auf Systemebene auf die Benutzerwahrnehmung sehr schnell beurteilen. Dies kann bei der Priorisierung von Projekten zur Leistungsverbesserung hilfreich sein.

Selbst bei diesem Ansatz strukturierter , vom Benutzer gemeldeter Metriken besteht immer noch Raum für unerwartete Änderungen. Man kann jedoch mit einiger Sicherheit davon ausgehen, dass ein bestimmtes Projekt (das auf die Verbesserung einer Metrik auf Systemebene abzielt) sich am Ende positiv auf die gemeldeten Metriken auswirkt, dann verbessert das Projekt höchstwahrscheinlich tatsächlich die Benutzerwahrnehmung.

Es gibt jedoch keine Garantie dafür, dass alle wirklich „guten“ Änderungen auch immer die vom Benutzer gemeldeten Metriken effektiv verbessern. Daher ist es wichtig, eine Mischung aus beidem zu verwenden, um Projekte zur Leistungsverbesserung zu priorisieren und zu bewerten.