Mit konversationeller Analyse können Nutzer Daten abfragen, die in LookML modelliert sind. Dazu stellen sie Fragen in natürlicher Sprache in einer Looker-Instanz. Nutzer können Daten auf folgende Weise abfragen:
- Unterhaltung mit einem Looker-Explore starten, das auf einem LookML-Modell basiert
- Eine Unterhaltung mit einem Daten-KI-Agenten starten, der mit bis zu fünf Looker-Explores verbunden ist
In diesem Leitfaden finden Sie Strategien und Best Practices, mit denen LookML-Entwickler Conversational Analytics erfolgreich konfigurieren und optimieren können. In dieser Anleitung werden folgende Themen behandelt:
- LookML-Best Practices für die konversationelle Analyse
- Wann sollte Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden?
- Best Practices für die Einrichtung eines Explores für die Verwendung mit Conversational Analytics
Wenn Sie Ihr LookML-Modell und Conversational Analytics vorbereiten, können Sie die Akzeptanz bei den Nutzern steigern und dafür sorgen, dass Nutzer genaue und nützliche Antworten auf ihre Fragen erhalten.
Weitere Informationen dazu, wie und wann Gemini for Google Cloud Ihre Daten verwendet
LookML-Best Practices für Conversational Analytics
Bei der konversationellen Analyse werden Fragen in natürlicher Sprache anhand von zwei primären Eingaben interpretiert:
Das LookML-Modell: Conversational Analytics analysiert die Struktur, die Felder (Dimensionen, Messwerte), die Labels, die Beschreibungen und die Synonyme, die im LookML-Modell definiert sind, das dem Looker-Explore zugrunde liegt.
Eindeutige Feldwerte: Bei der Conversational Analytics werden die Datenwerte in Feldern (insbesondere String-Dimensionen und Synonyme) untersucht, um die verfügbaren Kategorien und Entitäten zu ermitteln, nach denen Nutzer fragen könnten. Die Kardinalität (die Anzahl der eindeutigen Werte) kann beeinflussen, wie diese Werte verwendet werden.
Die Effektivität von Conversational Analytics hängt direkt von der Qualität und Klarheit dieser beiden Eingaben ab. In der folgenden Tabelle finden Sie häufige Beispiele dafür, wie sich unklare oder mehrdeutige LookML negativ auf Conversational Analytics auswirken kann, sowie Lösungen zur Verbesserung der Ausgabe und Nutzerfreundlichkeit.
| Häufige Probleme mit der LookML-Qualität | Lösung für eine übersichtlichere konversationelle Analyse |
|---|---|
| Mangelnde Klarheit:Felder ohne eindeutige Labels oder Beschreibungen sind sowohl für Conversational Analytics als auch für die Nutzer mehrdeutig. | Eindeutige Labels anwenden:Verwenden Sie den Parameter label, um Feldern intuitive, geschäftsfreundliche Namen zu geben, die Nutzer wahrscheinlich in ihren Fragen verwenden. |
| Zu viele Felder:Wenn zu viele Felder verfügbar sind, insbesondere interne IDs (Primärschlüssel), doppelte Felder, die aus Joins übernommen werden, oder Felder für Zwischenberechnungen, kann das die Optionen, die für Conversational Analytics verfügbar sind, unübersichtlich machen. | Irrelevante Felder ausblenden:Achten Sie darauf, dass alle Primärschlüssel, Fremdschlüssel, redundanten Felder aus Joins und rein technischen Felder ausgeblendet bleiben. (Optional) Explores erweitern:Wenn Ihr Explore eine große Anzahl von Feldern enthält, sollten Sie ein neues Explore erstellen, das ein vorhandenes erweitert. So können Sie eine spezielle Version beliebter Inhalte für Conversational Analytics anpassen, ohne Explores zu ändern, auf die sich andere Inhalte möglicherweise stützen. |
| Namenskonflikte:Wenn mehrere Felder in verschiedenen Ansichten im Explore ähnliche oder identische Namen oder Labels haben, kann es zu einer falschen Feldauswahl kommen. | Ausführliche Beschreibungen verfassen:Beschreibungen liefern wichtigen Kontext für Conversational Analytics. Verwenden Sie den Parameter description für die folgenden Aufgaben:
Ein Feld mit dem Label |
| Unnötige Datenbanklast:Conversational Analytics verwendet die Methode Model field name suggestions der Looker API, um Beispielwerte für Felder abzurufen und den richtigen Feld- oder Filterwert für generierte Abfragen auszuwählen. Diese Vorschläge werden aus der Datenbank abgerufen. Es kann daher dauern, bis sie angezeigt werden, oder es kann zu einer unnötigen Belastung kommen. | LookML verwenden:Sie können API-Abfragen zum Abrufen von Vorschlagswerten ganz vermeiden, indem Sie Beispielwerte in LookML definieren:
|
| Verborgene Komplexität:Wenn Sie sich stark auf benutzerdefinierte Felder oder Tabellenberechnungen auf Dashboard-Ebene verlassen, ist die möglicherweise kritische Geschäftslogik für die konversationelle Analyse nicht zugänglich. | Benutzerdefinierte Logik einbinden:Ermitteln Sie wichtige und häufig verwendete benutzerdefinierte Felder oder Tabellenkalkulationen. Konvertieren Sie die Logik für diese Felder in LookML-Dimensionen und ‑Measures, damit sie von Conversational Analytics verwendet werden können. |
Unsaubere Daten:Die folgenden Arten von inkonsistenten oder schlecht strukturierten Daten erschweren es Conversational Analytics, Anfragen richtig zu interpretieren.
|
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. |
Weitere Best Practices für das Schreiben von übersichtlichem, effizientem LookML-Code finden Sie in der folgenden Dokumentation:
- Best Practice: Was Sie mit LookML tun sollten und was nicht
- Best Practice: Für Looker-Nutzer*innen eine positive Erfahrung schaffen
- Best Practices: Nachhaltige, wartungsfreundliche LookML schreiben
Wann Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden sollte
In Conversational Analytics können Sie sowohl in LookML als auch in Agent-Anweisungen Kontexteingaben wie Feldsynonyme und Beschreibungen hinzufügen. Wenn Sie entscheiden, wo Sie Kontext hinzufügen, sollten Sie die folgenden Richtlinien beachten: Kontext, der immer zutrifft, sollte direkt in Ihr LookML-Modell aufgenommen werden. Looker-Explores können an mehreren Stellen verwendet werden, z. B. in Dashboards und in Conversational Analytics. Daher muss der in LookML angewendete Kontext für alle möglichen Nutzer gelten, die mit den Daten interagieren.
Der Kontext des Agents sollte qualitativ und nutzerorientiert sein. Es kann viele Agents geben, die verschiedene Nutzer in einem Explore bedienen. Beispiele für Kontext, der in Agent-Anweisungen, aber nicht in LookML enthalten sein 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 sind die wichtigsten Felder, die für diesen Nutzer spezifisch sind? Welche Felder muss dieser Nutzer nie verwenden?
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.
- Geben Sie für jedes Feld eine klare Beschreibung an, einschließlich Beispielwerten, sofern relevant. Diese Feldbeschreibungen sind im Prompt enthalten, der an Conversational Analytics gesendet wird. Sie können hilfreich sein, um Kontext bereitzustellen. Beispielwerte sind besonders hilfreich für Stringfelder.