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

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

Dieser Leitfaden enthält Strategien und Best Practices für LookML-Entwickler und ‑Administratoren zum Konfigurieren und Optimieren von Conversational Analytics. Wenn Sie diese Empfehlungen für Ihr LookML-Modell, Ihre Explores und Ihre Daten-Agents befolgen, können Sie die Akzeptanz bei den Nutzern steigern und dafür sorgen, dass Nutzer genaue, relevante und nützliche Antworten auf ihre Fragen erhalten. In diesem Leitfaden werden Best Practices für Conversational Analytics beschrieben. Er folgt einem logischen Ablauf, der mit der Entwicklung einer soliden Grundlage in der LookML eines Modells beginnt, dann die Konfiguration von Explores behandelt, die auf diesem Modell basieren, und schließlich die Erstellung von Daten-Agents, die diese Explores als Datenquellen verwenden.

LookML-Best Practices für die konversationelle Analyse

Bei Conversational Analytics 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 damit 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. Eine vollständige Liste der LookML-Parameter, die von Conversational Analytics analysiert werden, finden Sie in der Übersicht über Conversational Analytics.
  • Eindeutige Feldwerte: Der Agent kann Datenwerte als Stichprobe nehmen und unscharfe Suchen durchführen, um nach bestimmten Feldwerten in der zugrunde liegenden Datenbank zu suchen. Mit diesen Methoden kann der Agent die richtigen Felder auswählen, die richtigen Filterwerte anwenden und die verfügbaren Kategorien und Einheiten identifizieren, nach denen Nutzer fragen könnten.

Die Effektivität von Conversational Analytics hängt direkt von der Qualität und Klarheit dieser Eingaben ab. In der folgenden Tabelle finden Sie häufige Möglichkeiten, wie unklare oder mehrdeutige LookML Conversational Analytics negativ beeinflussen kann, sowie Lösungen zur Reduzierung der Latenz und zur Verbesserung der Ausgabe und Nutzerfreundlichkeit.

Problem mit der LookML-Qualität Lösung für eine übersichtlichere konversationelle Analyse
Unübersichtlichkeit und Namenskonflikte:Felder ohne eindeutige Labels, mit mehrdeutigen Definitionen oder mit ähnlichen Namen in verschiedenen Ansichten können zu einer falschen Auswahl führen. Eindeutige Labels und ausführliche Beschreibungen verwenden:
  • Verwenden Sie den Parameter label, um Feldern intuitive, unternehmensfreundliche Namen zu geben.
  • Verwenden Sie den Parameter description, um wichtigen Kontext, Definitionen in natürlicher Sprache und branchenspezifische Terminologie anzugeben. Bei Conversational Analytics werden Beschreibungen verwendet, um die Bedeutung von Feldern besser zu erkennen 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, die für Conversational Analytics verfügbar sind, unübersichtlich. Irrelevante Felder ausblenden:Alle Primärschlüssel, Fremdschlüssel und technischen Felder müssen ausgeblendet sein.

(Optional) Explores erweitern:Wenn Sie Explores mit vielen Feldern verwenden, sollten Sie eine spezielle 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 Echtzeit-Datenbankabfragen für Feldvorschläge, indem Sie Werte fest codieren oder auf effizientere Dimensionen verweisen:
  • Mit dem Parameter suggestions können Sie eine Liste möglicher Werte hartzucodieren.
  • Verwenden Sie die Parameter suggest_explore und suggest_dimension, 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:Halten Sie sich an die allgemeinen Best Practices zur Optimierung der Abfrageleistung, z. B. durch 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 Conversational Analytics nicht zugänglich. Benutzerdefinierte Logik einbinden:Konvertieren Sie wichtige und häufig verwendete benutzerdefinierte Felder oder Tabellenberechnungen in LookML-Dimensionen und ‑Messwerte.
Unsaubere Daten:Die folgenden Arten von inkonsistenten oder schlecht strukturierten Daten erschweren es Conversational Analytics, Anfragen richtig zu interpretieren.
  • Wertabweichungen: Inkonsistente Groß- und Kleinschreibung oder Namenskonventionen (z. B. eine Mischung aus den Werten complete, Complete und COMPLETE) können zu Datenduplizierung oder falschen Datenbeziehungen in Conversational Analytics führen.
  • Inkonsistente Datentypen:Spalten, die numerisch sein sollen und gelegentlich Stringwerte enthalten, erzwingen den Feldtyp string, was numerische Operationen verhindert.
  • Mehrdeutigkeit der Zeitzone:Das Fehlen standardisierter Zeitzonen in Zeitstempelfeldern kann zu einer falschen Filterung oder Aggregation führen.
 Datenqualitätsprobleme beheben:Kennzeichnen Sie nach Möglichkeit Datenqualitätsprobleme (inkonsistente Werte, Typen, Zeitzonen), die Sie bei der Datenaufbereitung feststellen. Arbeiten Sie mit Data Engineering-Teams zusammen, um die Quelldaten zu bereinigen oder Transformationen in der ETL-/Datenmodellierungsebene anzuwenden.

Wichtige LookML-Erkenntnisse

Beachten Sie die folgenden Punkte, wenn Sie LookML für Explores definieren, die als Datenquellen für Conversational Analytics verwendet werden:

  • Klare und präzise Labels verwenden:Wählen Sie Labels für Ihre Daten aus, die der tatsächlichen Sprache Ihrer Unternehmensnutzer entsprechen. Vermeiden Sie technische Abkürzungen wie "amt_usd_curr" und verwenden Sie stattdessen "Amount (USD)".
  • Nahtlose Zuordnung aktivieren: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 oder nur intern verwendete Felder in LookML aus (z. B. Fremdschlüssel oder Roh-IDs), damit nur Felder, die zum Beantworten geschäftlicher Fragen erforderlich sind, in Conversational Analytics angezeigt werden. Wenn Sie sich nur auf relevante Felder konzentrieren, wird das Rauschen reduziert und die Genauigkeit der Feldauswahl verbessert.
  • Beispieldaten und Fuzzy-Suchanfragen optimieren: Definieren Sie fest codierte Werte im Parameter suggestions oder verwenden Sie suggest_dimension und suggest_explore für effizientere Datenbankabfragen.
  • Datenabfragen optimieren:Halten Sie sich an die allgemeinen Looker-Best Practices zur Optimierung der Abfrageleistung, z. B. die Verwendung von Aggregate Awareness und effizienter Join-Logik.

Weitere Best Practices für das Schreiben von übersichtlichem, effizientem LookML-Code finden Sie in der folgenden Dokumentation:

Best Practices für die Einrichtung eines Explores für die konversationelle Analyse

Damit die konversationelle Analyse möglichst hilfreiche Antworten liefern kann, sollten Sie die folgenden Best Practices beachten, wenn Sie Explores definieren, die als Datenquelle für die konversationelle Analyse verwendet werden sollen:

  • Definieren Sie in der zugrunde liegenden LookML der explorativen Datenanalyse nur die Felder, die für die Analyse durch Endnutzer nützlich sind.
    • Geben Sie jedem Feld einen klaren und prägnanten Namen und eine Beschreibung.
    • Fügen Sie bei Bedarf Beispielwerte ein. Beispielwerte sind besonders hilfreich für Felder vom Typ „String“.
  • Erwägen Sie, datenagentenspezifische Explores zu erstellen, in denen Inhalte wiederverwendet werden.
    • Mit extends können Sie vorhandene LookML nutzen und die Felder auswählen, die der Agent benötigt. Unter „Systemaktivität“ können Nutzer sehen, welche Felder in von Agents generierten Anfragen verwendet werden, und entscheiden, welche Felder ausgeschlossen werden sollen.
    • Verwenden Sie LookML-Optimierungen auf Feldebene, um Beschreibungen zu erstellen, die speziell für KI‑Agenten entwickelt wurden, z. B. „Verwende das Feld ‚Bestellungen‘, wenn Nutzer sich auf ‚Umsatz‘ beziehen“.

Best Practices für das Erstellen von Daten-Agents

Nachdem Sie mit LookML-Best Practices und gut konfigurierten Explores eine solide Grundlage geschaffen haben, können Sie KI-Datenagenten erstellen, um für bestimmte Anwendungsfälle oder Nutzergruppen maßgeschneiderte dialogorientierte Funktionen bereitzustellen. Data-Agents 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.

Es ist wichtig, Best Practices beim Erstellen von Agents und beim Schreiben von Anweisungen zu befolgen, damit die Antworten des Agents auf die spezifischen Nutzeranforderungen zugeschnitten werden und die allgemeine Genauigkeit verbessert wird. Zu diesen Best Practices gehören das Entwerfen von spezialisierten KI-Agenten für bestimmte Bereiche und das Verfassen klarer, effektiver Anweisungen.

Spezialisierte Agents erstellen

Es kann zwar verlockend sein, einen globalen Daten-Agenten zu erstellen, der alle geschäftsbezogenen Fragen beantwortet, aber Agenten sind am leistungsstärksten, wenn sie auf eine bestimmte Domain wie Vertrieb, Marketing oder Produktanalyse spezialisiert sind. Einem Agenten, der sich auf ein oder wenige eng verwandte Explores konzentriert, können präzisere Anweisungen gegeben werden. Das verringert Unklarheiten und verbessert die Genauigkeit der Antworten.

Vermeiden Sie es, einen einzelnen Agent zu erstellen, der alle nicht zusammenhängenden Datenmodelle verarbeitet. Erstellen Sie stattdessen fokussierte Agents für bestimmte Geschäftsbereiche, die nur mit eng verwandten Explores verbunden sind. Erstellen Sie beispielsweise nicht einen Agenten für alle Unternehmensdaten, sondern einen „Umsatz-Agenten“, der sich speziell auf Orders- und Transactions-Explores konzentriert.

Effektive Anweisungen für KI-Agenten schreiben

Agent-Anweisungen sind Ihr wichtigstes Tool, um das Verhalten eines Data-Agents anzupassen und ihn mit der einzigartigen Geschäftslogik und Terminologie Ihrer Organisation zu versehen. Anweisungen sind eine Möglichkeit, Ihrem Agenten beizubringen, wie er Nutzerfragen interpretieren, Unklarheiten behandeln und so antworten soll, dass es für Ihre Nutzer am hilfreichsten ist. Gut formulierte Anweisungen sind entscheidend, um genaue, relevante und zuverlässige Antworten zu erhalten.

Geben Sie beim Erstellen Ihres Daten-Agents die Agent-Anweisungen in das Feld Anweisungen ein. Weitere Informationen zum Erstellen von Agents finden Sie auf der Dokumentationsseite Explore-Daten-Agents erstellen und verwalten.

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

  • Geschäftskontext und Standardverhalten definieren: Geben Sie dem Agenten Informationen zur einzigartigen Logik und Terminologie Ihres Unternehmens. Verwenden Sie Anweisungen, um Akronyme zu definieren (z. B. „LJ bedeutet letztes Jahr“), gängige Filterlogik zu erläutern oder Standardverhalten für Mehrdeutigkeiten festzulegen (z. B. „Wenn kein date_created angegeben ist, nach den letzten 6 Monaten filtern“).
  • 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 kann der Agent nachvollziehen, welche Felder oder Filter angewendet werden sollen. Beispiel: „Wenn ein Nutzer nach der Region fragt, verwende das Feld account_holder.geo_region.“
  • Prägnant sein: Schreiben Sie klar und vermeiden Sie unnötige Wörter oder Wiederholungen in der Anleitung.
  • Redundanz vermeiden: Wiederholen Sie keine Informationen, die in LookML gehören, z. B. Feldbeschreibungen oder Synonyme. Weitere Informationen dazu, wann Sie Kontext in LookML und wann in Agent-Anweisungen definieren sollten, finden Sie unter Kontext in LookML und in der konversationellen Analyse hinzufügen. Vermeiden Sie außerdem, grundlegende Konzepte zu erklären, die der Agent bereits versteht, z. B. den Unterschied zwischen einer Dimension und einem Messwert oder wie man grundlegende Datumsfilter anwendet.

Einschränkungen von Anweisungen für KI-Agenten

Beachten Sie beim Schreiben der Agent-Anweisungen die folgenden Einschränkungen von Conversational Analytics:

  • Bei Conversational Analytics wird das Generieren von Abfragen, die den Parameter pivots enthalten, nicht unterstützt. Mit Conversational Analytics können zwar Daten für mehrere Dimensionen gleichzeitig zurückgegeben werden, sie können aber nicht wie in der Looker Explore-Benutzeroberfläche in separate Spalten umgebrochen werden. Stattdessen werden die Daten in einem „langen“ oder „reduzierten“ Format zurückgegeben, sodass die Daten horizontal statt vertikal gruppiert werden.
  • Im Gegensatz zu LookML, das verwaltet wird, sind Anweisungen oft Freiformtext und können veralten, wenn sich das zugrunde liegende Datenmodell im Laufe der Zeit weiterentwickelt. Damit die Anweisungen für Explore-Daten-Agents nicht veralten, verwenden Sie bestätigte Abfragen, um Paare aus Fragen in natürlicher Sprache und den entsprechenden Explore-Abfragen zu definieren.

Beispiel für Anweisungen für den Agenten

Hier sind einige Beispielanweisungen für einen Daten-Agenten, der mit Looker-Explores namens Order Items (Bestellartikel) und Products (Produkte) 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 Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden sollte

In Conversational Analytics können Sie LookML oder KI-Agenten-Anweisungen Kontext hinzufügen. Berücksichtigen Sie bei der Entscheidung, wo Sie Kontext hinzufügen möchten, die folgenden Richtlinien:

  • Kontext, der für alle Nutzer eines Explores gelten soll, sollte direkt Ihrem LookML-Modell hinzugefügt werden, da Looker-Explores an mehreren Stellen verwendet werden können, sowohl in Dashboards als auch in Conversational Analytics. Wenn der Kontext nur für bestimmte Nutzer gelten soll, können Sie LookML-Funktionen wie Nutzerattribute verwenden, um benutzerdefinierte Funktionen zu erstellen.
  • LookML hat Priorität für feldspezifische Metadaten und zwingende Anforderungen. Platzieren Sie feldspezifische Metadaten wie Synonyme und Beschreibungen direkt in LookML und nicht in den Anweisungen für den KI-Agenten. Anforderungen für Dinge wie Standardfilterwerte oder ausgeblendete Felder sollten idealerweise in LookML behandelt werden, damit sie berücksichtigt werden.
  • Wiederholen 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 grundlegende Datumsfilterung funktioniert. Definieren Sie denselben Begriff auch nicht sowohl in LookML als auch in den Agent-Anweisungen.

Der Kontext des KI-Agenten sollte qualitativ und nutzerorientiert sein. In einem Explore können viele KI-Agenten verschiedene Nutzer bedienen. LookML eignet sich gut, um zu definieren, was ein Feld ist. Geschäftsstrategien oder Vorhersageberechnungen lassen sich damit jedoch in der Regel nicht definieren. Beispiele für Kontext, der in Agent-Anweisungen, aber nicht in LookML enthalten sein sollte:

  • Wer ist der Nutzer, der mit dem Agenten interagiert? Welche Funktionen haben diese Personen? Sind sie intern oder extern? Welche Analytics-Erfahrung haben sie?
  • Was ist das Ziel des Nutzers? Welche Art von Entscheidung möchten sie am Ende der Unterhaltung treffen?
  • Welche Arten von Fragen wird dieser Nutzer stellen?
  • Welche Felder sind für diesen Nutzer am relevantesten? Welche Felder sollen für diesen Nutzer zugänglich sein, sollen bestimmte Filter immer angewendet werden oder sollen einige Felder für diesen Nutzer priorisiert werden?