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

Bei Conversational Analytics 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-KI-Agentenkonfigurationen. Die Qualität der Antworten hängt davon ab, wie effektiv Sie diese Eingaben vorbereiten.

In diesem Leitfaden finden Sie 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. Dieser Leitfaden behandelt Best Practices für Conversational Analytics und folgt einem logischen Ablauf, der mit der Entwicklung einer soliden Grundlage in der LookML eines Modells beginnt, dann mit der Konfiguration von Explores, die auf diesem Modell basieren, und schließlich mit der Erstellung von Daten-Agents, die diese Explores als Datenquellen verwenden.

LookML-Best Practices für Conversational Analytics

Bei der Interpretation von Fragen in natürlicher Sprache werden in Conversational Analytics die folgenden primären Eingaben verwendet:

  • 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. Eine vollständige Liste der LookML-Parameter, die von Conversational Analytics analysiert werden, finden Sie in der Übersicht zu Conversational Analytics.
  • Unterschiedliche Feldwerte: Der Agent kann Datenwerte stichprobenartig erfassen und unscharfe Suchvorgänge ausführen, um nach bestimmten Feldwerten in der zugrunde liegenden Datenbank zu suchen. So kann er die richtigen Felder auswählen, die richtigen Filterwerte anwenden und die verfügbaren Kategorien und Entitäten ermitteln, 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 für Conversational Analytics 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:Wandeln Sie wichtige und häufig verwendete benutzerdefinierte Felder oder Tabellenkalkulationen in LookML-Dimensionen und ‑Messwerte um.
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:Wenn Zeitstempelfelder keine standardisierten Zeitzonen enthalten, kann dies zu falschen Filtern oder Aggregationen 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 widerspiegeln, wie Ihre Geschäftsnutzer tatsächlich sprechen. 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 Verwendung mit Conversational Analytics

Damit die konversationelle Analyse möglichst hilfreiche Antworten liefert, 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 Ihres Explores 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.
    • Geben Sie gegebenenfalls Beispielwerte an. Diese 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-Elemente nutzen und die Felder auswählen, die der Agent benötigt. In der Systemaktivität können Nutzer sehen, welche Felder in von Agents generierten Abfragen 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 Verfassen 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 Agenten für bestimmte Bereiche und das Verfassen klarer, effektiver Anweisungen.

Spezialisierte Agents erstellen

Es kann zwar verlockend sein, einen globalen Datenagenten zu erstellen, der alle geschäftsrelevanten Fragen beantwortet, aber Agenten sind am leistungsstärksten, wenn sie auf eine bestimmte Domain wie Vertrieb, Marketing oder Produktanalysen spezialisiert sind. Ein Agent, der sich auf ein oder wenige eng verwandte Explores konzentriert, kann präzisere Anweisungen erhalten, was die Mehrdeutigkeit verringert und die Genauigkeit der Antworten verbessert.

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 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 reagieren soll, dass es für Ihre Nutzer am hilfreichsten ist. Gut formulierte Anweisungen sind entscheidend für genaue, relevante und zuverlässige Antworten.

Geben Sie beim Erstellen des 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 die spezifische Logik und Terminologie Ihrer Organisation an die Hand. Verwenden Sie Anweisungen, um Akronyme zu definieren (z. B. „LJ bedeutet letztes Jahr“), gängige Filterlogik zu erläutern oder Standardverhalten für Unklarheiten 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.“
  • Golden Queries für komplexe Beispiele verwenden: Für häufig gestellte Fragen oder Abfragen mit komplexer Geschäftslogik sollten Sie golden queries bereitstellen – Paare aus Fragen in natürlicher Sprache und den entsprechenden, bestätigten Looker-Abfragen. Mithilfe von Golden Queries kann der Agent bestimmte Muster lernen. Konzentrieren Sie sich auf Anfragen, die schwierige Begriffe oder häufige Filterkombinationen erläutern. Goldene Abfragen müssen in einer bestimmten LookML-Abfragedarstellung und nicht als Roh-SQL oder Standard-Explore-URLs angegeben werden.
  • 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 Kundenservicemitarbeiter bereits kennt, 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:

  • In Conversational Analytics werden keine Abfragen unterstützt, die den Parameter pivots enthalten. Conversational Analytics kann zwar Daten für mehrere Dimensionen gleichzeitig zurückgeben, aber nicht wie in der Looker Explore-Benutzeroberfläche in separate Spalten aufteilen. Stattdessen werden die Daten in einem „langen“ oder „reduzierten“ Format zurückgegeben, sodass die Daten horizontal statt vertikal gruppiert werden.

  • Bei Conversational Analytics können keine benutzerdefinierten Felder wiederverwendet werden, die in vorhandenen Looker-Inhalten definiert sind. Das ist z. B. der Fall, wenn Sie die generierte LookML aus einem Explore, das ein benutzerdefiniertes Feld enthält, verwenden, um eine Golden Query zu erstellen. Es können auch keine neuen benutzerdefinierten Felder in einer neuen Abfrage generiert werden. Stattdessen werden vorhandene LookML-Felder verwendet oder mit Python benutzerdefinierte Berechnungen für die Datenergebnisse erstellt.

  • 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.

Beispiel für Anweisungen für den Agenten

Hier sind einige Beispielanweisungen für einen Data-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`.

# Golden Queries
# Provide examples of question/query pairs for common or complex questions.
Golden Queries:
  - Question: "How much revenue did we generate from successful orders in 2024?"
    Looker query:
      model: thelook_ecommerce
      explore: order_items
      fields: [order_items.total_sales]
      filters: [{field: order_items.status, value: "Complete"}, {field: order_items.created_year, value: "2024"}]

# 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 in Ihr LookML-Modell aufgenommen werden, da Looker-Explores an mehreren Stellen verwendet werden können, z. B. in Dashboards und in Conversational Analytics. Wenn Kontext nur für bestimmte Nutzer gelten soll, sollten Sie LookML-Funktionen wie Nutzerattribute verwenden, um benutzerdefinierte Umgebungen zu erstellen.
  • Priorisieren Sie LookML für feldspezifische Metadaten und wichtige Anforderungen. Platzieren Sie feldspezifische Metadaten, einschließlich Synonyme und Beschreibungen, direkt in LookML anstatt in Agent-Anweisungen. Anforderungen für Dinge wie Standardfilterwerte oder ausgeblendete Felder sollten idealerweise in LookML behandelt werden, um sicherzustellen, dass 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 für KI-Agenten sollte qualitativ und nutzerorientiert sein. Es können viele KI-Agenten vorhanden sein, die verschiedene Nutzer über ein Explore bedienen. Mit LookML lässt sich gut definieren, was ein Feld ist, aber in der Regel nicht die Geschäftsstrategie oder Vorhersageberechnungen. Hier einige Beispiele für Kontext, der in die Anweisungen für KI-Agenten, aber nicht in LookML aufgenommen werden sollte:

  • Wer ist der Nutzer, der mit dem Agent 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?