Best practice per la configurazione dell'analisi conversazionale in Looker

Analisi conversazionale consente agli utenti di eseguire query sui dati modellati in LookML ponendo domande in linguaggio naturale all'interno di un'istanza di Looker. Gli utenti possono eseguire query sui dati nei seguenti modi:

Questa guida fornisce strategie e best practice per aiutare gli sviluppatori LookML a configurare e ottimizzare Conversational Analytics. Questa guida tratta i seguenti argomenti:

Preparando il modello LookML e l'analisi conversazionale, puoi aumentare l'adozione da parte degli utenti e assicurarti che ricevano risposte accurate e utili alle loro domande.

Scopri come e quando Gemini per Google Cloud utilizza i tuoi dati.

Best practice di LookML per Analisi conversazionale

L'analisi conversazionale interpreta le domande in linguaggio naturale utilizzando due input principali:

  1. Il modello LookML: Conversational Analytics analizza la struttura, i campi (dimensioni, misure), le etichette, le descrizioni e i sinonimi definiti nel modello LookML alla base dell'esplorazione di Looker.

  2. Valori dei campi distinti: Conversational Analytics esamina i valori dei dati all'interno dei campi (in particolare, dimensioni stringa e sinonimi) per identificare le categorie e le entità disponibili su cui gli utenti potrebbero porre domande. La cardinalità (il numero di valori unici) può influire sul modo in cui vengono utilizzati questi valori.

L'efficacia di Conversational Analytics è direttamente correlata alla qualità e alla chiarezza di questi due input. La seguente tabella contiene i modi comuni in cui LookML poco chiaro o ambiguo può influire negativamente su Conversational Analytics, insieme a soluzioni per migliorare l'output e l'esperienza utente.

Problema comune di qualità di LookML Soluzione per un'analisi conversazionale più chiara
Mancanza di chiarezza:i campi che non hanno etichette o descrizioni chiare sono ambigui sia per Conversational Analytics sia per i suoi utenti. Applica etichette chiare:utilizza il parametro label per assegnare ai campi nomi intuitivi e adatti alle attività che gli utenti probabilmente utilizzeranno nelle loro domande.
Eccesso di campi:l'esposizione di un numero eccessivo di campi, in particolare ID interni (chiavi primarie), campi duplicati ereditati dalle unioni o campi di calcolo intermedi, può ingombrare le opzioni disponibili per Conversational Analytics. Nascondi i campi irrilevanti:assicurati che tutte le chiavi primarie, le chiavi esterne, i campi ridondanti dei join e i campi puramente tecnici rimangano nascosti.

(Facoltativo) Estendi le esplorazioni:se l'esplorazione contiene un numero elevato di campi, valuta la possibilità di crearne una nuova che estenda una esistente. In questo modo, puoi personalizzare una versione dedicata dei contenuti più popolari per l'analisi conversazionale senza modificare le esplorazioni su cui potrebbero basarsi altri contenuti.
Conflitti di denominazione:più campi con nomi o etichette simili o identici in diverse visualizzazioni all'interno dell'esplorazione possono comportare una selezione errata dei campi. Scrivi descrizioni dettagliate:le descrizioni forniscono un contesto fondamentale per l'analisi conversazionale. Utilizza il parametro description per le seguenti attività:
  • Descrivi il campo in modo chiaro utilizzando il linguaggio naturale.
  • Includi terminologia o sinonimi specifici del settore o dell'azienda.
  • Spiega i calcoli o il contesto. L'analisi conversazionale utilizza le descrizioni per identificare meglio il significato dei campi e mappare i termini degli utenti.

Ad esempio, un campo con l'etichetta user_count potrebbe avere la descrizione "Il numero totale di utenti unici che hanno visitato il sito web".

Standardizza la denominazione:rivedi i nomi dei campi e le etichette per coerenza e chiarezza.
Complessità nascosta:se si fa molto affidamento sui campi personalizzati a livello di dashboard o sui calcoli delle tabelle, la logica di business potenzialmente critica non sarà accessibile ad Analytics conversazionale. Incorpora logica personalizzata:identifica campi personalizzati o calcoli tabellari importanti e di uso comune. Converti la logica di questi campi in dimensioni e misure LookML in modo che Conversational Analytics possa utilizzarli.
Dati disordinati:i seguenti tipi di dati incoerenti o scarsamente strutturati rendono difficile l'interpretazione accurata delle query da parte dell'analisi conversazionale.
  • Variazioni di valore:l'uso di maiuscole o convenzioni di denominazione incoerenti (ad esempio, un mix dei valori complete, Complete e COMPLETE) può comportare la duplicazione dei dati o relazioni errate tra i dati in Conversational Analytics.
  • Tipi di dati incoerenti:le colonne che devono essere numeriche e che contengono valori stringa occasionali forzano il tipo di campo a string, il che impedisce le operazioni numeriche.
  • Ambiguità del fuso orario: la mancanza di fusi orari standardizzati nei campi timestamp può comportare un'aggregazione o un filtraggio errati.
Qualità dei dati dell'indirizzo:se possibile, segnala i problemi di qualità dei dati (valori, tipi e fusi orari incoerenti) che identifichi durante la cura dei dati. Collabora con i team di data engineering per pulire i dati di origine o applicare trasformazioni nel livello ETL/di modellazione dei dati.

Per altre best practice per scrivere codice LookML pulito ed efficiente, consulta la seguente documentazione:

Quando aggiungere il contesto a LookML anziché ad Analisi conversazionale

In Conversational Analytics, puoi aggiungere input di contesto, come sinonimi di campi e descrizioni, sia a LookML sia all'interno delle istruzioni dell'agente. Quando decidi dove aggiungere il contesto, segui queste indicazioni: il contesto che è sempre vero deve essere aggiunto direttamente al modello LookML. Le esplorazioni di Looker possono essere utilizzate in più posizioni, tra cui dashboard e analisi conversazionale, pertanto il contesto applicato in LookML deve essere valido per tutti i possibili utenti che interagiranno con i dati.

Il contesto dell'agente deve essere qualitativo e incentrato sull'utente. Inoltre, possono esserci molti agenti che servono utenti diversi da un'unica esplorazione. Di seguito sono riportati alcuni esempi di contesto da includere nelle istruzioni dell'agente, ma non in LookML:

  • Chi è l'utente che interagisce con l'agente? Che ruolo ricopre? Sono interni o esterni all'azienda? Qual è la sua precedente esperienza di analisi?
  • Qual è l'obiettivo dell'utente? Che tipo di decisione vuole prendere al termine della conversazione?
  • Quali tipi di domande porrà questo utente?
  • Quali sono i campi principali specifici per questo utente? Quali sono i campi che questo utente non dovrà mai utilizzare?

Best practice per la configurazione di un'esplorazione da utilizzare con l'analisi conversazionale

Per aiutare Analisi conversazionale a fornire le risposte più utili, ti consigliamo di seguire queste best practice quando definisci le esplorazioni da utilizzare come origine dati per Analisi conversazionale:

  • Nel codice LookML sottostante dell'esplorazione, definisci solo i campi utili per l'analisi da parte degli utenti finali.
  • Assegna a ogni campo un nome chiaro e conciso.
  • Fornisci una descrizione chiara di ogni campo, inclusi esempi di valori, ove pertinente. Queste descrizioni dei campi sono incluse nel prompt inviato ad Analytics conversazionale e possono essere utili per fornire contesto. I valori di esempio sono particolarmente utili per i campi stringa.