Best Practices für die Konfiguration von Conversational Analytics in Looker

Bei der konversationellen Analyse wird Gemini Google Cloud verwendet, um Fragen in natürlicher Sprache zu interpretieren. Als „Single Source of Truth“ dienen dabei Ihr semantisches Looker-Modell (LookML), Datenwerte und Konfigurationen von Daten-KI-Agenten. Die Qualität der Antworten hängt davon ab, wie effektiv Sie diese Eingaben vorbereiten.

In dieser Anleitung finden Sie Strategien und Best Practices für LookML-Entwickler und ‑Administratoren zum Konfigurieren und Optimieren der konversationellen Analyse. Wenn Sie diese Empfehlungen für Ihr LookML-Modell, Explores und Daten-KI-Agenten befolgen, können Sie die Akzeptanz bei den Nutzern erhöhen und dafür sorgen, dass sie genaue, relevante und nützliche Antworten auf ihre Fragen erhalten. In dieser Anleitung werden Best Practices im Zusammenhang mit der konversationellen Analyse behandelt. Dabei wird ein logischer Ablauf verfolgt, der mit der Entwicklung einer soliden Grundlage in der LookML eines Modells beginnt, mit der Konfiguration von Explores auf Basis dieses Modells fortgesetzt wird und mit der Erstellung von Daten-KI-Agenten endet, die diese Explores als Datenquellen verwenden.

LookML-Best Practices für die konversationelle Analyse

Bei der konversationellen Analyse werden Fragen in natürlicher Sprache anhand der folgenden primären Eingaben interpretiert:

  • LookML-Modell: Der Agent ruft das Schema für die Explores ab, die mit ihm verbunden sind. Das Schema enthält Felder (Dimensionen, Messwerte), Nur-Filter-Felder (Filter, Parameter) und die entsprechenden Labels, Beschreibungen und Synonyme, die im LookML-Modell definiert sind, das dem Looker-Explore zugrunde liegt. Die vollständige Liste der LookML-Parameter, die bei der konversationellen Analyse analysiert werden, finden Sie in der Übersicht zur konversationellen Analyse.
  • Eindeutige Feldwerte: Der Agent kann Datenwerte als Stichprobe verwenden und Fuzzy-Suchen durchführen, um nach bestimmten Feldwerten in der zugrunde liegenden Datenbank zu suchen. So kann der Agent die richtigen Felder auswählen, die richtigen Filterwerte anwenden und die verfügbaren Kategorien und Entitäten identifizieren, nach denen Nutzer fragen könnten.

Die Effektivität der konversationellen Analyse hängt direkt von der Qualität und Klarheit dieser Eingaben ab. In der folgenden Tabelle sind häufige Möglichkeiten aufgeführt, wie unklare oder mehrdeutige LookML die konversationelle Analyse negativ beeinflussen kann. Außerdem finden Sie Lösungen, um die Latenz zu verringern und die Ausgabe und Nutzerfreundlichkeit zu verbessern.

Problem mit der LookML-Qualität Lösung für eine klarere konversationelle Analyse
Mangelnde Klarheit und Namenskonflikte:Felder ohne klare Labels, mit mehrdeutigen Definitionen oder mit ähnlichen Namen in verschiedenen Ansichten können zu einer falschen Feldauswahl führen. Klare Labels und ausführliche Beschreibungen anwenden:
  • Verwenden Sie den Parameter label, um Feldern intuitive, geschäftsfreundliche Namen zu geben.
  • Verwenden Sie den Parameter description, um wichtigen Kontext, Definitionen in natürlicher Sprache und branchenspezifische Terminologie bereitzustellen. Bei der konversationellen Analyse werden Beschreibungen verwendet, um die Bedeutung von Feldern besser zu identifizieren und Nutzerbegriffe zuzuordnen.
Zu viele Felder:Wenn zu viele Felder verfügbar sind, z. B. interne IDs, doppelte Felder aus Joins oder Zwischenberechnungen, werden die Optionen für die konversationelle Analyse unübersichtlich. Irrelevante Felder ausblenden: Alle Primärschlüssel, Fremdschlüssel und technischen Felder müssen ausgeblendet bleiben.

(Optional) Explores erweitern:Für Explores mit vielen Feldern können Sie eine eigene Version für die konversationelle Analyse erstellen, indem Sie ein vorhandenes Explore erweitern.
Datenbanklast für Stichproben und Suche:Das Abrufen von Stichprobenwerten und Vorschlägen aus der Datenbank kann langsam sein oder unnötige Last verursachen, insbesondere wenn Nutzer in Abfragen auf bestimmte Datenwerte verweisen. Vorschläge in LookML definieren:Vermeiden Sie Datenbankabfragen in Echtzeit für Feldvorschläge, indem Sie Werte fest codieren oder auf effizientere Dimensionen verweisen:
  • Verwenden Sie den suggestions Parameter, um eine Liste möglicher Werte fest zu codieren.
  • Verwenden Sie die suggest_explore und suggest_dimension Parameter, um eine alternative, effizientere Dimension für Filtervorschläge abzufragen.
Datenbanklast für Datenabfragen:Große oder ineffiziente Abfragen können die Latenz und die Datenbanklast erhöhen. Datenabfragen optimieren: Beachten Sie die allgemeinen Best Practices zur Optimierung der Abfrageleistung, z. B. die Verwendung von Aggregate Awareness und einer effizienten Join-Logik.
Unvollständige LookML-Definitionen:Wenn Sie sich auf benutzerdefinierte Felder oder Tabellenkalkulationen auf Dashboard-Ebene verlassen, ist die kritische Geschäftslogik für die konversationelle Analyse nicht zugänglich. Benutzerdefinierte Logik einbeziehen: Wandeln Sie wichtige und häufig verwendete benutzerdefinierte Felder oder Tabellenkalkulationen in LookML-Dimensionen und ‑Messwerte um.
Unübersichtliche Daten:Die folgenden Arten von inkonsistenten oder schlecht strukturierten Daten erschweren es der konversationellen Analyse, Abfragen genau zu interpretieren.
  • Wertvariationen:Inkonsistente Groß- und Kleinschreibung oder Benennungskonventionen (z. B. eine Mischung aus den Werten complete, Complete und COMPLETE) können zu Datenduplizierung oder falschen Datenbeziehungen bei der konversationellen Analyse führen.
  • Inkonsistente Datentypen:Spalten, die numerisch sein sollen und gelegentlich Stringwerte enthalten, erzwingen den Feldtyp string, wodurch numerische Operationen verhindert werden.
  • Mehrdeutigkeit bei Zeitzonen:Fehlende standardisierte Zeitzonen in Zeitstempelfeldern können zu falscher Filterung oder Aggregation führen.
 Datenqualitätsprobleme beheben:Kennzeichnen Sie nach Möglichkeit Datenqualitätsprobleme (inkonsistente Werte, Typen, Zeitzonen), die Sie bei der Datenkuration feststellen. Arbeiten Sie mit Datenteams zusammen, um die Quelldaten zu bereinigen oder Transformationen in der ETL-/Datenmodellierungsebene anzuwenden.

Wichtige LookML-Erkenntnisse

Beachten Sie diese Erkenntnisse, wenn Sie LookML für Explores definieren, die als Datenquellen für die konversationelle Analyse verwendet werden:

  • Klare und präzise Labels verwenden:Wählen Sie Labels für Ihre Daten aus, die widerspiegeln, wie Ihre Nutzer im Unternehmen tatsächlich sprechen. Vermeiden Sie technische Abkürzungen wie "amt_usd_curr" und verwenden Sie stattdessen "Amount (USD)".
  • Nahtlose Zuordnung ermöglichen:Verwenden Sie Synonyme und Beschreibungen, damit der Agent Nutzerfragen den richtigen Feldern zuordnen kann.
  • Berechnungen zentralisieren:Definieren Sie häufig verwendete Berechnungen direkt als LookML-Dimensionen oder ‑Messwerte, um eine „Single Source of Truth“ zu gewährleisten und die Latenz zu verringern.
  • Kontext optimieren: Blenden Sie technische Felder oder Felder, die nur intern verwendet werden, in LookML aus (z. B. Fremdschlüssel oder Roh-IDs), damit der konversationellen Analyse nur Felder angezeigt werden, die für die Beantwortung geschäftlicher Fragen erforderlich sind. Wenn Sie sich nur auf relevante Felder konzentrieren, wird das Rauschen reduziert und die Genauigkeit der Feldauswahl verbessert.
  • Stichprobendaten und Fuzzy-Suchabfragen optimieren: Definieren Sie fest codierte Werte im Parameter suggestions oder verwenden Sie suggest_dimension und suggest_explore für effizientere Datenbankabfragen.
  • Datenabfragen optimieren: Beachten Sie die allgemeinen Looker-Best Practices zur Optimierung der Abfrageleistung, z. B. die Verwendung von Aggregate Awareness und einer effizienten Join-Logik.

Weitere Best Practices für das Schreiben von sauberer, effizienter LookML finden Sie in der folgenden Dokumentation:

Best Practices für die Einrichtung eines Explores zur Verwendung mit der konversationellen Analyse

Damit die konversationelle Analyse die hilfreichsten Antworten liefern kann, sollten Sie die folgenden Best Practices beachten, wenn Sie Ihre Explores als Datenquelle für die konversationelle Analyse definieren:

Best Practices für die Erstellung von Daten-KI-Agenten

Nachdem Sie mit LookML-Best Practices und gut konfigurierten Explores eine solide Grundlage geschaffen haben, können Sie Daten-KI-Agenten erstellen, um für bestimmte Anwendungsfälle oder Nutzergruppen angepasste Konversationserlebnisse zu bieten. Daten-KI-Agenten stellen eine Verbindung zu bis zu fünf Explores her und verwenden Anweisungen in natürlicher Sprache, um Kontext bereitzustellen, Terminologie zu definieren und Verhaltensrichtlinien festzulegen.

Wenn Sie beim Erstellen von Agenten und beim Schreiben von Anweisungen Best Practices befolgen, können Sie die Antworten des Agenten an die spezifischen Bedürfnisse der Nutzer anpassen und die allgemeine Genauigkeit verbessern. Zu diesen Best Practices gehören die Entwicklung spezialisierter Agenten für bestimmte Bereiche und das Schreiben klarer, effektiver Anweisungen.

Spezialisierte Agenten erstellen

Es kann zwar verlockend sein, einen globalen Daten-KI-Agenten zu erstellen, der alle geschäftlichen Fragen beantwortet, aber Agenten sind am effektivsten, wenn sie auf einen bestimmten Bereich spezialisiert sind, z. B. Vertrieb, Marketing oder Produktanalyse. Einem Agenten, der sich auf ein oder wenige eng verwandte Explores konzentriert, können genauere Anweisungen gegeben werden, was die Mehrdeutigkeit verringert und die Genauigkeit der Antworten verbessert.

Vermeiden Sie beim Entwerfen Ihrer Agenten, einen einzelnen Agenten zu erstellen, der alle nicht verwandten Datenmodelle verarbeitet. Erstellen Sie stattdessen gezielte Agenten für verschiedene Geschäftsbereiche und stellen Sie nur eine Verbindung zu eng verwandten Explores her. Erstellen Sie beispielsweise anstelle eines Agenten für alle Unternehmensdaten einen „Umsatz-Agenten“, der sich speziell auf die Explores Orders und Transactions konzentriert.

Effektive Anweisungen für KI-Agenten schreiben

Anweisungen für KI-Agenten sind Ihr wichtigstes Tool, um das Verhalten eines Daten-KI-Agenten anzupassen und ihn mit der einzigartigen Geschäftslogik und Terminologie Ihres Unternehmens zu versehen. Anweisungen können Sie sich als eine Möglichkeit vorstellen, Ihren Agenten zu schulen, wie er Nutzerfragen interpretieren, Mehrdeutigkeiten behandeln und so antworten soll, dass es für Ihre Nutzer am hilfreichsten ist. Gut formulierte Anweisungen sind der Schlüssel zu genauen, relevanten und zuverlässigen Antworten.

Geben Sie Ihre Anweisungen für KI-Agenten beim Erstellen Ihres Daten-KI-Agenten in das Feld Anweisungen ein. Weitere Informationen zum Erstellen von Agenten finden Sie auf der Dokumentationsseite Daten-KI-Agenten für Explores erstellen und verwalten.

Beachten Sie die folgenden Best Practices, um effektive Anweisungen zu schreiben:

  • Geschäftskontext und Standardverhalten definieren: Schulen Sie den Agenten in der einzigartigen Logik und Terminologie Ihres Unternehmens. Verwenden Sie Anweisungen, um Akronyme zu definieren (z. B. „LY bedeutet Last Year“), allgemeine Filterlogik zu erklären oder Standardverhalten für Mehrdeutigkeiten festzulegen (z. B. „Wenn kein date_created angegeben ist, filtern Sie nach den letzten 6 Monaten“).
  • LookML- und Filtersyntax verwenden: Wenn Sie in Anweisungen auf Felder verweisen oder Filter anwenden, verwenden Sie die LookML-Syntax (z. B. events.date_created) und die Filtersyntax (z. B. "last 6 months"). So wird sichergestellt, dass der Agent weiß, welche Felder oder Filter angewendet werden müssen. Beispiel: „Wenn ein Nutzer nach der Region fragt, verwenden Sie das Feld account_holder.geo_region.“
  • Prägnant sein: Schreiben Sie klar und vermeiden Sie unnötige Wörter oder Wiederholungen in den Anweisungen.
  • Redundanz vermeiden: Duplizieren Sie keine Informationen, die in LookML enthalten sind, z. B. Feldbeschreibungen oder Synonyme. Weitere Informationen dazu, wann Kontext in LookML und wann in Anweisungen für KI-Agenten definiert werden sollte, finden Sie unter Wann sollte Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden? Erklären Sie auch keine grundlegenden Konzepte, die der Agent bereits versteht, z. B. den Unterschied zwischen einer Dimension und einem Messwert oder wie die grundlegende Datumsfilterung funktioniert.

Einschränkungen von Anweisungen für KI-Agenten

Beachten Sie beim Schreiben Ihrer Anweisungen für KI-Agenten die folgenden Einschränkungen der konversationellen Analyse:

  • Bei der konversationellen Analyse können keine Abfragen generiert werden, die den pivots Parameter enthalten. Bei der konversationellen Analyse können zwar Daten für mehrere Dimensionen gleichzeitig zurückgegeben werden, sie können aber nicht wie in der Looker-Explore-UI in separate Spalten umgewandelt werden. Stattdessen werden die Daten in einem „langen“ oder „vereinfachten“ Format zurückgegeben, sodass die Daten horizontal und nicht vertikal gruppiert werden.
  • Anders als LookML, das geregelt ist, sind Anweisungen oft Freiformtext und können veraltet sein, wenn sich das zugrunde liegende Datenmodell im Laufe der Zeit weiterentwickelt. Um veraltete Anweisungen mit Daten-KI-Agenten für Explores zu vermeiden, verwenden Sie bestätigte Abfragen, um Paare von Fragen in natürlicher Sprache und die entsprechenden Explore-Abfragen zu definieren.

Beispielanweisungen für KI-Agenten

Hier sind einige Beispielanweisungen für einen Daten-KI-Agenten, der mit Looker-Explores namens Order Items und Products verbunden ist:

# Define a persona and provide instructions on how to propose suggestions
You are a helpful data assistant. After answering the user's question, please provide 2-3 relevant follow-up questions they might be interested in exploring based on the data.
Anticipate the user's needs. Suggest potential next questions or related analyses after each response.
Always offer suggestions for deeper dives into the data.
Your tone should be professional and concise.

# Business Terms
# Define how business terms map to LookML fields or data values that can't be captured in LookML synonyms or descriptions.
Terms:
  EOP: End of Period. This is the last day of the period.
  LY: Last Year.
  Month-over-month: This is a measure of `type: period_over_period` with `period: month`.

# Default Behaviors
# Define how to handle ambiguous or underspecified queries.
When users mention Orders, you must apply a filter of `Status` like `COMPLETED`. Consider this a **hard-coded requirement**. Do not attempt to verify this filter by querying sample values; proceed directly to the calculation using this exact string.
Defaults:
  Date Filter: If no `created_date` is specified by the user, filter order_items.created_date to "last 12 months".
  Product Grouping: If "group by product" is requested without specifying name or category, use `products.category`.

# Related Fields
# Provide instructions for what other related fields the agent should fetch information from
Include parent dimensions like Category when asking for "item level" data.

Wann sollte Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden?

Bei der konversationellen Analyse können Sie Kontext zu LookML oder in Anweisungen für KI-Agenten hinzufügen. Wenn Sie entscheiden, wo Sie Kontext hinzufügen möchten, beachten Sie die folgenden Richtlinien:

  • Kontext, der für alle Nutzer eines Explores gelten soll, sollte direkt zu Ihrem LookML-Modell hinzugefügt werden, da Looker-Explores an mehreren Stellen verwendet werden können, sowohl in Dashboards als auch bei der konversationellen Analyse. Wenn Kontext nur für bestimmte Nutzer gelten soll, können Sie LookML-Funktionen wie Nutzerattribute verwenden, um angepasste Erlebnisse zu erstellen.
  • Priorisieren Sie LookML für feldspezifische Metadaten und zwingende Anforderungen. Platzieren Sie feldspezifische Metadaten, einschließlich Synonyme und Beschreibungen, direkt in LookML und nicht in Anweisungen für KI-Agenten. Anforderungen für Dinge wie Standardfilterwerte oder ausgeblendete Felder sollten idealerweise in LookML behandelt werden, um sicherzustellen, dass sie berücksichtigt werden.
  • Duplizieren Sie keine Informationen, die der Agent bereits kennt, z. B. wie eine Looker-Abfrage erstellt wird, eine Erklärung von Dimensionen oder Messwerten, die zugänglichen Explores oder wie die grundlegende Datumsfilterung funktioniert. Definieren Sie denselben Begriff auch nicht sowohl in LookML als auch in den Anweisungen für KI-Agenten.

Der Kontext für KI-Agenten sollte qualitativ und nutzerorientiert sein. Es können viele Agenten vorhanden sein, die verschiedene Nutzer aus einem Explore bedienen. LookML eignet sich gut, um zu definieren, was ein Feld ist, aber in der Regel können damit keine Geschäftsstrategien oder prädiktiven Berechnungen definiert werden. Beispiele für Kontext, der in Anweisungen für KI-Agenten, aber nicht in LookML enthalten sein sollte:

  • Wer ist der Nutzer, der mit dem Agenten interagiert? Welche Funktion hat er? Ist er intern oder extern? Welche Vorkenntnisse hat er im Bereich Analysen?
  • Was ist das Ziel des Nutzers? Welche Art von Entscheidung möchte er am Ende der Unterhaltung treffen?
  • Welche Arten von Fragen wird dieser Nutzer stellen?
  • Welche Felder sind für diesen Nutzer am relevantesten? Beispielsweise: Auf welche Felder sollte dieser Nutzer zugreifen können, sollten bestimmte Filter immer angewendet werden oder sollten einige Felder für diesen Nutzer priorisiert werden?