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

Bei der konversationellen Analyse wird Gemini for 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 der Grundlage 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 über die konversationelle 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. Die folgende Tabelle enthält häufige Beispiele dafür, wie unklare oder mehrdeutige LookML die konversationelle Analyse 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 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 detaillierte Beschreibungen verwenden:
  • 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 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 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: Halten Sie sich an 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 Namenskonventionen (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 Vorgänge verhindert werden.
  • Mehrdeutigkeit der Zeitzone:Das Fehlen standardisierter Zeitzonen in Zeitstempelfeldern kann zu falscher Filterung oder Aggregation führen.
 Datenqualität verbessern:Kennzeichnen Sie nach Möglichkeit Probleme mit der Datenqualität (inkonsistente Werte, Typen, Zeitzonen), die Sie bei der Datenkuration 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 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 reduzieren.
  • 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-Suchanfragen optimieren: Definieren Sie fest codierte Werte im suggestions Parameter 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 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 Explore 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 benutzerdefinierte Konversationserlebnisse für bestimmte Anwendungsfälle oder Nutzergruppen 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 bei der Erstellung 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 Produktanalysen. Einem Agenten, der sich auf ein oder wenige eng verwandte Explores konzentriert, können genauere Anweisungen gegeben werden, was die Mehrdeutigkeit reduziert und die Genauigkeit der Antworten verbessert.

Vermeiden Sie beim Erstellen Ihrer Agenten, einen einzelnen Agenten zu entwickeln, der alle nicht verwandten Datenmodelle verarbeitet. Erstellen Sie stattdessen spezialisierte Agenten für verschiedene Geschäftsbereiche und stellen Sie nur eine Verbindung zu eng verwandten Explores her. Erstellen Sie beispielsweise nicht einen Agenten für alle Unternehmensdaten, sondern 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 sind eine Möglichkeit, Ihren Agenten zu schulen, wie er Nutzerfragen interpretieren, mit Mehrdeutigkeiten umgehen 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 Abkürzungen zu definieren (z. B. „LY bedeutet Last Year“), gängige 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 versteht der Agent, welche Felder oder Filter angewendet werden müssen. Beispiel: „Wenn ein Nutzer nach der Region fragt, verwenden Sie das Feld account_holder.geo_region.“
  • Golden Queries für komplexe Beispiele verwenden: Für häufige Fragen oder Abfragen mit komplexer Geschäftslogik stellen Sie golden queries bereit. Das sind Paare aus Fragen in natürlicher Sprache und den entsprechenden, verifizierten Looker-Abfragen. Golden Queries können dem Agenten helfen, bestimmte Muster zu lernen. Konzentrieren Sie sich auf Abfragen, die schwierige Terminologie oder gängige Filterkombinationen verdeutlichen. Golden Queries müssen in einer bestimmten LookML-Abfragedarstellung und nicht als Raw-SQL oder Standard-Explore-URLs bereitgestellt werden.
  • 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 grundlegende Datumsfilterung funktioniert.

Einschränkungen von Anweisungen für KI-Agenten

Beachten Sie beim Schreiben Ihrer Anweisungen für 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.

  • Bei der konversationellen Analyse können keine benutzerdefinierten Felder wiederverwendet werden, die in vorhandenen Looker-Inhalten definiert sind (z. B. wenn Sie die generierte LookML aus einem Explore mit einem benutzerdefinierten Feld verwenden, um eine Golden Query zu erstellen), oder neue benutzerdefinierte Felder in einer neuen Abfrage generiert werden. Stattdessen werden vorhandene LookML-Felder verwendet oder mit Python benutzerdefinierte Berechnungen für die Datenergebnisse erstellt.

  • Anders als LookML, das geregelt ist, sind Anweisungen oft Freiformtext und können mit der Zeit veralten, wenn sich das zugrunde liegende Datenmodell weiterentwickelt.

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

# 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 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. Beachten Sie bei der Entscheidung, wo Sie Kontext hinzufügen möchten, die folgenden Richtlinien:

  • Kontext, der für alle Nutzer eines Explore 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 benutzerdefinierte Erlebnisse zu erstellen.
  • LookML sollte für feldspezifische Metadaten und zwingende Anforderungen verwendet werden. Feldspezifische Metadaten, einschließlich Synonyme und Beschreibungen, sollten direkt in LookML und nicht in Anweisungen für KI-Agenten platziert werden. Anforderungen an 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 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 Agenten sollte qualitativ sein und sich auf den Nutzer konzentrieren. 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 nicht, um Geschäftsstrategien oder prädiktive Berechnungen zu definieren. 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?