Mit der konversationellen Analyse können Nutzer Daten abfragen, die in LookML modelliert sind. Dazu stellen sie in einer Looker-Instanz Fragen in natürlicher Sprache. Nutzer können Daten auf folgende Arten abfragen:
- Unterhaltung mit einem Looker-Explore starten, das auf einem LookML-Modell basiert
- Unterhaltung mit einem Daten-Agenten starten, der mit bis zu fünf Looker-Explores verbunden ist
In dieser Anleitung finden Sie Strategien und Best Practices, die LookML-Entwicklern helfen, die konversationelle Analyse erfolgreich zu konfigurieren und zu optimieren. In dieser Anleitung werden folgende Themen behandelt:
- LookML-Best Practices für die konversationelle Analyse
- Wann Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden sollte
- Best Practices für die Einrichtung eines Explore zur Verwendung mit der konversationellen Analyse
Wenn Sie Ihr LookML-Modell und die konversationelle Analyse vorbereiten, können Sie die Akzeptanz bei den Nutzern steigern und dafür sorgen, dass sie genaue und nützliche Antworten auf ihre Fragen erhalten.
Weitere Informationen dazu, wie und wann Gemini forIhre Daten verwendet. Google Cloud
LookML-Best Practices für die konversationelle Analyse
Die konversationelle Analyse interpretiert Fragen in natürlicher Sprache anhand von zwei primären Eingaben:
LookML-Modell: Die konversationelle Analyse analysiert die Struktur, die Felder (Dimensionen, Maße), Labels, Beschreibungen und Synonyme, die im LookML-Modell definiert sind, das dem Looker-Explore zugrunde liegt.
Unterschiedliche Feldwerte: Die konversationelle Analyse untersucht die Datenwerte in den Feldern (insbesondere Stringdimensionen und Synonyme), um die verfügbaren Kategorien und Entitäten zu ermitteln, nach denen Nutzer fragen könnten. Die Kardinalität (Anzahl der eindeutigen Werte) kann beeinflussen, wie diese Werte verwendet werden.
Die Effektivität der konversationellen Analyse hängt direkt von der Qualität und Klarheit dieser beiden Eingaben ab. Die folgende Tabelle enthält häufige Beispiele dafür, wie unklar oder mehrdeutig formuliertes LookML die konversationelle Analyse negativ beeinflussen kann, sowie Lösungen zur Verbesserung der Ausgabe und der Nutzererfahrung.
| Häufiges Problem mit der LookML-Qualität | Lösung für eine klarere konversationelle Analyse |
|---|---|
| Mangelnde Klarheit:Felder ohne klare Labels oder Beschreibungen sind sowohl für die konversationelle Analyse als auch für die Nutzer mehrdeutig. | Klare 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 von Joins übernommen wurden, oder Felder für Zwischenberechnungen, kann dies die Optionen für die konversationelle Analyse unübersichtlich machen. | Irrelevante Felder ausblenden: Alle Primärschlüssel, Fremdschlüssel, redundanten Felder aus Joins und rein technischen Felder müssen 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 die konversationelle Analyse erstellen, ohne Explores zu ändern, auf die sich andere Inhalte möglicherweise verlassen. |
| Namenskonflikte:Mehrere Felder mit ähnlichen oder identischen Namen oder Labels in verschiedenen Ansichten innerhalb des Explore können zu einer falschen Feldauswahl führen. | Ausführliche Beschreibungen verfassen:Beschreibungen liefern wichtigen Kontext für die konversationelle Analyse. Verwenden Sie den Parameter description für die folgenden Aufgaben:
Ein Feld mit dem Label |
| Versteckte Komplexität:Wenn Sie sich stark auf benutzerdefinierte Felder oder Tabellenkalkulationen auf Dashboard-Ebene verlassen, kann die konversationelle Analyse nicht auf potenziell wichtige Geschäftslogik zugreifen. | Benutzerdefinierte Logik einbeziehen: Ermitteln Sie wichtige und häufig verwendete benutzerdefinierte Felder oder Tabellenkalkulationen. Wandeln Sie die Logik für diese Felder in LookML-Dimensionen und -Maße um, damit sie von der konversationellen Analyse verwendet werden können. |
Unübersichtliche Daten:Die folgenden Arten von inkonsistenten oder schlecht strukturierten Daten erschweren es der konversationellen Analyse, Abfragen genau zu interpretieren.
|
Datenqualität verbessern:Markieren Sie nach Möglichkeit Probleme mit der Datenqualität (inkonsistente Werte, Typen, Zeitzonen), die Sie bei der Datenaufbereitung feststellen. Arbeiten Sie mit Datenteams zusammen, um die Quelldaten zu bereinigen oder Transformationen in der ETL-/Datenmodellierungsebene anzuwenden. |
Weitere Best Practices für das Schreiben von sauberem, effizientem LookML finden Sie in der folgenden Dokumentation:
- Best Practice: Was Sie mit LookML tun und lassen sollten
- Best Practice: Eine positive Nutzererfahrung für Looker-Nutzer schaffen
- Best Practice: Nachhaltiges, wartungsfreundliches LookML schreiben
Wann Kontext zu LookML und wann zur konversationellen Analyse hinzugefügt werden sollte
In der konversationellen Analyse können Sie sowohl LookML als auch Agentenanweisungen Kontext eingeben, z. B. Synonyme und Beschreibungen für Felder. Wenn Sie entscheiden, wo Sie Kontext hinzufügen möchten, sollten Sie folgende Richtlinien beachten: Kontext, der immer zutrifft, sollte direkt zu Ihrem LookML-Modell hinzugefügt werden. Looker-Explores können an mehreren Stellen verwendet werden, sowohl in Dashboards als auch in der konversationellen Analyse. Daher muss der in LookML angewendete Kontext für alle möglichen Nutzer gelten, die mit den Daten interagieren.
Der Agentenkontext sollte qualitativ sein und sich auf den Nutzer konzentrieren. Es können viele Agenten vorhanden sein, die verschiedene Nutzer aus einem Explore bedienen. Beispiele für Kontext, der in Agentenanweisungen, aber nicht in LookML enthalten sein sollte:
- Wer ist der Nutzer, der mit dem Agenten interagiert? Welche Funktionen haben diese Personen? Sind sie interne oder externe Mitarbeiter des Unternehmens? Welche Analytics-Erfahrung haben sie?
- 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?
- Was sind die wichtigsten Felder für diesen Nutzer? Welche Felder muss dieser Nutzer nie verwenden?
Best Practices für die Einrichtung eines Explore zur Verwendung mit der konversationellen Analyse
Damit die konversationelle Analyse möglichst hilfreiche Antworten geben kann, sollten Sie beim Definieren Ihrer Explores als Datenquelle für die konversationelle Analyse die folgenden Best Practices beachten:
- Definieren Sie im zugrunde liegenden LookML Ihres Explore 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 jedem Feld eine klare Beschreibung, einschließlich Beispielwerten, falls relevant. Diese Feldbeschreibungen sind im Prompt enthalten, der an die konversationelle Analyse gesendet wird, und können hilfreich sein, um Kontext zu liefern. Beispielwerte sind besonders hilfreich für Stringfelder.