Bonnes pratiques pour configurer Conversational Analytics dans Looker

Conversational Analytics utilise Gemini for Google Cloud pour interpréter les questions en langage naturel, en se basant sur votre modèle sémantique Looker (LookML), les valeurs de données et les configurations d'agent de données comme source de référence. La qualité de ses réponses dépend de l'efficacité avec laquelle vous préparez ces entrées.

Ce guide fournit des stratégies et des bonnes pratiques aux développeurs et administrateurs LookML pour configurer et optimiser Conversational Analytics. En suivant ces recommandations pour votre modèle LookML, vos explorations et vos agents de données, vous pouvez augmenter l'adoption par les utilisateurs et vous assurer qu'ils obtiennent des réponses précises, pertinentes et utiles à leurs questions. Ce guide couvre les bonnes pratiques liées à Conversational Analytics, en suivant un flux logique qui commence par le développement d'une base solide dans le LookML d'un modèle, la configuration d'explorations basées sur ce modèle et la création d'agents de données qui utilisent ces explorations comme sources de données.

Bonnes pratiques LookML pour Conversational Analytics

Conversational Analytics interprète les questions en langage naturel en s'appuyant sur ces entrées principales :

  • Le modèle LookML : l'agent récupère le schéma des explorations qui y sont connectées. Le schéma inclut les champs (dimensions, mesures), les champs de filtre uniquement (filtres, paramètres) et leurs libellés, descriptions et synonymes correspondants définis dans le modèle LookML sous-jacent à l'exploration Looker Explore. Pour obtenir la liste complète des paramètres LookML analysés par Conversational Analytics, consultez la présentation de Conversational Analytics.
  • Valeurs de champ distinctes : l'agent peut échantillonner des valeurs de données et effectuer des recherches approximatives pour vérifier des valeurs de champ spécifiques dans la base de données sous-jacente. Ces méthodes permettent à l'agent de choisir les champs appropriés, d'appliquer les valeurs de filtre correctes et d'identifier les catégories et entités disponibles sur lesquelles les utilisateurs peuvent poser des questions.

L'efficacité de Conversational Analytics est directement liée à la qualité et à la clarté de ces entrées. Le tableau suivant présente les façons courantes dont un LookML peu clair ou ambigu peut avoir un impact négatif sur Conversational Analytics, ainsi que des solutions pour réduire la latence et améliorer la sortie et l'expérience utilisateur.

Problème de qualité LookML Solution pour une analyse plus claire avec Conversational Analytics
Manque de clarté et conflits de noms : les champs qui ne comportent pas de libellés clairs, qui ont des définitions ambiguës ou qui partagent des noms similaires dans différentes vues peuvent entraîner une sélection de champ incorrecte. Appliquez des libellés clairs et des descriptions complètes :
  • Utilisez le paramètre label pour attribuer aux champs des noms intuitifs et adaptés à l'entreprise.
  • Utilisez le paramètre description pour fournir un contexte essentiel, des définitions en langage naturel et une terminologie spécifique au secteur. Conversational Analytics utilise des descriptions pour mieux identifier la signification des champs et mapper les termes des utilisateurs.
Surcharge de champs : exposer trop de champs, tels que des ID internes, des champs en double provenant de jointures ou des calculs intermédiaires, encombre les options disponibles pour Conversational Analytics. Masquez les champs non pertinents : assurez-vous que toutes les clés primaires, les clés étrangères et les champs techniques restent masqués.

(Facultatif) Étendez les explorations : pour les explorations comportant de nombreux champs, envisagez de créer une version dédiée pour Conversational Analytics en étendant une exploration existante.
Charge de la base de données pour l'échantillonnage et la recherche : la récupération d'exemples de valeurs et de suggestions à partir de la base de données peut être lente ou entraîner une charge inutile, en particulier lorsque les utilisateurs font référence à des valeurs de données spécifiques dans les requêtes. Définissez des suggestions dans LookML : évitez les requêtes de base de données en temps réel pour les suggestions de champs en codant en dur des valeurs ou en pointant vers des dimensions plus efficaces :
  • Utilisez le suggestions paramètre pour coder en dur une liste de valeurs possibles.
  • Utilisez les suggest_explore et suggest_dimension paramètres pour interroger une autre dimension plus efficace pour les suggestions de filtres.
Charge de la base de données pour les requêtes de données : les requêtes volumineuses ou inefficaces peuvent augmenter la latence et la charge de la base de données. Optimisez les requêtes de données : respectez les bonnes pratiques générales pour optimiser les performances des requêtes, par exemple en utilisant la reconnaissance d’agrégats et une logique de jointure efficace.
Définitions LookML incomplètes : s'appuyer sur des champs personnalisés au niveau du tableau de bord ou sur des calculs de table rend la logique métier essentielle inaccessible à Conversational Analytics. Intégrez une logique personnalisée : convertissez les champs personnalisés ou les calculs de tables importants et couramment utilisés en dimensions et mesures LookML.
Données désordonnées : les types de données incohérents ou mal structurés suivants empêchent Conversational Analytics d'interpréter les requêtes avec précision.
  • Variations de valeurs : une mise en majuscules ou des conventions de dénomination incohérentes (par exemple, un mélange des valeurs complete, Complete et COMPLETE) peuvent entraîner une duplication des données ou des relations de données incorrectes dans Conversational Analytics.
  • Types de données incohérents : les colonnes destinées à être numériques et qui contiennent des valeurs de chaîne occasionnelles forcent le type de champ à être string, ce qui empêche les opérations numériques.
  • Ambiguïté du fuseau horaire : l'absence de fuseaux horaires standardisés dans les champs d'horodatage peut entraîner un filtrage ou une agrégation incorrects.
 Résolvez les problèmes de qualité des données : dans la mesure du possible, signalez les problèmes de qualité des données (valeurs, types, fuseaux horaires incohérents) que vous identifiez lors de la curation des données. Collaborez avec les équipes d'ingénierie des données pour nettoyer les données sources ou appliquer des transformations dans la couche ETL/de modélisation des données.

Points clés à retenir concernant LookML

Gardez ces points à l'esprit lorsque vous définissez LookML pour les explorations qui seront utilisées comme sources de données pour Conversational Analytics :

  • Utilisez des libellés clairs et précis : choisissez des libellés pour vos données qui reflètent la façon dont vos utilisateurs professionnels parlent réellement. Évitez les abréviations techniques telles que "amt_usd_curr" et utilisez plutôt "Amount (USD)".
  • Activez le mappage fluide : utilisez des synonymes et des descriptions pour aider l'agent à mapper les questions des utilisateurs aux champs appropriés.
  • Centralisez les calculs : définissez directement les calculs fréquemment utilisés comme dimensions ou mesures LookML pour garantir une source unique de référence et réduire la latence.
  • Simplifiez le contexte : masquez les champs techniques ou réservés à un usage interne dans LookML (tels que les clés étrangères ou les ID bruts) pour vous assurer que seuls les champs nécessaires pour répondre aux questions métier sont présentés à Conversational Analytics. Se concentrer uniquement sur les champs pertinents réduit le bruit et améliore la précision de la sélection des champs.
  • Optimisez les exemples de données et les requêtes de recherche approximative : définissez des valeurs codées en dur dans le paramêtes suggestions, ou utilisez suggest_dimension et suggest_explore pour des requêtes de base de données plus efficaces.
  • Optimisez les requêtes de données : respectez les bonnes pratiques générales de Looker pour optimiser les performances des requêtes, par exemple en utilisant la reconnaissance d'agrégats et une logique de jointure efficace.

Pour en savoir plus sur les bonnes pratiques pour écrire un LookML propre et efficace, consultez la documentation suivante :

Bonnes pratiques pour configurer une exploration à utiliser avec Conversational Analytics

Pour aider Conversational Analytics à fournir les réponses les plus utiles, suivez ces bonnes pratiques lorsque vous définissez vos explorations à utiliser comme source de données pour Conversational Analytics :

Bonnes pratiques pour créer des agents de données

Après avoir établi une base solide avec les bonnes pratiques LookML et des explorations bien configurées, vous pouvez créer des agents de données pour offrir des expériences conversationnelles personnalisées pour des cas d'utilisation ou des groupes d'utilisateurs spécifiques. Les agents de données se connectent à un maximum de cinq explorations et utilisent des instructions en langage naturel pour fournir un contexte, définir une terminologie et définir des consignes comportementales.

Il est essentiel de suivre les bonnes pratiques lors de la création d'agents et de la rédaction d'instructions pour adapter les réponses de l'agent aux besoins spécifiques des utilisateurs et améliorer la précision globale. Ces bonnes pratiques incluent la conception d'agents spécialisés pour des domaines spécifiques et la rédaction d'instructions claires et efficaces.

Créer des agents spécialisés

Bien qu'il puisse être tentant de créer un agent de données global pour traiter toutes les questions métier, les agents sont plus performants lorsqu'ils sont spécialisés dans un domaine spécifique, tel que les ventes, le marketing ou l'analyse des produits. Un agent axé sur une ou quelques explorations étroitement liées peut recevoir des instructions plus précises, ce qui réduit l'ambiguïté et améliore la précision des réponses.

Lorsque vous concevez vos agents, évitez de créer un seul agent pour gérer tous les modèles de données non liés. Créez plutôt des agents ciblés pour des domaines d'activité distincts, en vous connectant uniquement à des explorations étroitement liées. Par exemple, au lieu d'un seul agent pour toutes les données de l'entreprise, créez un "agent de revenus" spécifiquement axé sur les explorations Orders et Transactions.

Rédiger des instructions d'agent efficaces

Les instructions de l'agent sont votre principal outil pour personnaliser le comportement d'un agent de données et l'imprégner de la logique métier et de la terminologie uniques de votre organisation. Considérez les instructions comme un moyen de former votre agent à interpréter les questions des utilisateurs, à gérer l'ambiguïté et à répondre de la manière la plus utile pour vos utilisateurs. Des instructions bien rédigées sont essentielles pour générer des réponses précises, pertinentes et fiables.

Saisissez les instructions de votre agent dans le champ Instructions lorsque vous créez votre agent de données. Pour en savoir plus sur la création d'agents, consultez la page de documentation Créer et gérer des agents de données d'exploration.

Pour rédiger des instructions efficaces, suivez ces bonnes pratiques :

  • Définissez le contexte métier et le comportement par défaut : formez l'agent à la logique et à la terminologie uniques de votre organisation. Utilisez des instructions pour définir des acronymes (par exemple, "LY signifie l'année dernière"), expliquer une logique de filtrage courante ou définir des comportements par défaut en cas d'ambiguïté (par exemple, "Si aucune date_created n'est fournie, filtrez sur les 6 derniers mois").
  • Utilisez la syntaxe LookML et de filtre : lorsque vous faites référence à des champs ou que vous appliquez des filtres dans les instructions, utilisez la syntaxe LookML (par exemple, events.date_created) et la syntaxe de filtre (par exemple, "last 6 months"). Cela permet de s'assurer que l'agent comprend les champs ou les filtres à appliquer. Par exemple : "Lorsqu'un utilisateur pose une question sur la "région", utilisez le champ account_holder.geo_region."
  • Utilisez des requêtes de référence pour des exemples complexes : pour les questions ou requêtes courantes impliquant une logique métier complexe, fournissez golden queries — c'est-à-dire des paires de questions en langage naturel et leurs requêtes Looker correspondantes et validées. Les requêtes de référence peuvent aider l'agent à apprendre des modèles spécifiques. Concentrez-vous sur les requêtes qui clarifient une terminologie délicate ou des combinaisons de filtres courantes. Les requêtes de référence doivent être fournies dans une représentation de requête LookML spécifique plutôt que dans du code SQL brut ou des URL d'exploration standard.
  • Soyez concis : écrivez clairement et évitez les mots ou les répétitions inutiles dans les instructions.
  • Évitez les redondances : ne dupliquez pas les informations qui appartiennent à LookML, comme les descriptions de champs ou les synonymes. Pour savoir quand définir le contexte dans LookML plutôt que dans les instructions de l'agent, consultez Quand ajouter du contexte à LookML plutôt qu'à Conversational Analytics. Évitez également d'expliquer des concepts de base que l'agent comprend déjà, comme la différence entre une dimension et une mesure ou comment effectuer un filtrage de date de base.

Limites des instructions de l'agent

Tenez compte des limites suivantes de Conversational Analytics lorsque vous rédigez les instructions de votre agent :

  • Conversational Analytics n'est pas compatible avec la génération de requêtes contenant le pivots paramètre. Bien que Conversational Analytics puisse renvoyer des données pour plusieurs dimensions à la fois, il ne peut pas les faire pivoter dans des colonnes distinctes comme le peut l'interface utilisateur de Looker Explore. Au lieu de cela, il renvoie les données dans un format "long" ou "aplatit", de sorte que les données sont regroupées horizontalement plutôt que verticalement.

  • Conversational Analytics ne peut pas réutiliser les champs personnalisés définis dans le contenu Looker existant (par exemple, lorsque vous utilisez le LookML généré à partir d'une exploration contenant un champ personnalisé pour créer une requête de référence) ni générer de nouveaux champs personnalisés dans une nouvelle requête. Au lieu de cela, il utilise des champs LookML existants ou Python pour créer des calculs personnalisés sur les résultats des données.

  • Contrairement à LookML, qui est contrôlé, les instructions sont souvent du texte libre et peuvent devenir "obsolètes" à mesure que le modèle de données sous-jacent évolue au fil du temps.

Exemples d'instructions d'agent

Voici quelques exemples d'instructions pour un agent de données connecté aux explorations Looker appelées Order Items et Products :

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

Quand ajouter du contexte à LookML plutôt qu'à Conversational Analytics ?

Dans Conversational Analytics, vous pouvez ajouter du contexte à LookML ou dans les instructions de l'agent. Lorsque vous décidez où ajouter du contexte, appliquez les consignes suivantes :

  • Le contexte qui doit s'appliquer à tous les utilisateurs d'une exploration doit être ajouté directement à votre modèle LookML, car les explorations Looker peuvent être utilisées à plusieurs endroits, y compris dans les tableaux de bord et dans Conversational Analytics. Si le contexte ne doit s'appliquer qu'à certains utilisateurs, envisagez d'utiliser des fonctionnalités LookML telles que les attributs utilisateur pour créer des expériences personnalisées.
  • Privilégiez LookML pour les métadonnées spécifiques aux champs et les exigences strictes. Placez les métadonnées spécifiques aux champs, y compris les synonymes et les descriptions, directement dans LookML plutôt que dans les instructions de l'agent. Les exigences concernant les valeurs de filtre par défaut ou les champs masqués doivent idéalement être gérées dans LookML pour s'assurer qu'elles sont respectées.
  • Ne dupliquez pas les informations que l'agent connaît déjà, par exemple comment créer une requête Looker, une explication des dimensions ou des mesures, ses explorations accessibles ou comment effectuer un filtrage de date de base. De même, ne définissez pas le même terme à la fois dans LookML et dans les instructions de l'agent.

Le contexte de l'agent doit être qualitatif et axé sur l'utilisateur. De nombreux agents peuvent servir différents utilisateurs à partir d'une même exploration. LookML est utile pour définir ce qu'est un champ, mais il ne peut généralement pas définir de stratégie commerciale ni de calculs prédictifs. Voici quelques exemples de contexte à inclure dans les instructions de l'agent, mais pas dans LookML :

  • Qui est l'utilisateur qui interagit avec l'agent ? Quel est son rôle ? Est-il interne ou externe à l'entreprise ? Quelle est son expérience précédente en matière d'analyse ?
  • Quel est l'objectif de l'utilisateur ? Quel type de décision cherche-t-il à prendre à la fin de la conversation ?
  • Quels types de questions cet utilisateur posera-t-il ?
  • Quels sont les champs les plus pertinents pour cet utilisateur ? Par exemple, quels champs doivent être accessibles à cet utilisateur, certains filtres doivent-ils toujours être appliqués ou certains champs doivent-ils être prioritaires pour cet utilisateur ?