Best practice per la configurazione dell'analisi conversazionale in Looker

Analisi conversazionale utilizza Gemini Google Cloud per interpretare le domande in linguaggio naturale, utilizzando il tuo modello semantico (LookML), i valori dei dati e le configurazioni dell'agente di dati di Looker come fonte attendibile. La qualità delle risposte dipende dall'efficacia con cui prepari questi input.

Questa guida fornisce strategie e best practice per sviluppatori e amministratori LookML per configurare e ottimizzare Conversational Analytics. Seguendo questi consigli per il modello LookML, le esplorazioni e gli agenti di dati, puoi aumentare l'adozione da parte degli utenti e assicurarti che ricevano risposte accurate, pertinenti e utili alle loro domande. Questa guida illustra le best practice relative all'analisi conversazionale, seguendo un flusso logico che inizia con lo sviluppo di una base solida nel LookML di un modello, la configurazione di Explore basate su questo modello e la creazione di agenti di dati che utilizzano queste esplorazioni come origini dati.

Best practice di LookML per l'analisi conversazionale

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

  • Il modello LookML: l'agente recupera lo schema delle esplorazioni a cui è connesso. Lo schema include campi (dimensioni, misure), campi solo con filtri (filtri, parametri) e le relative etichette, descrizioni e sinonimi definiti nel modello LookML sottostante l'esplorazione di Looker. Per l'elenco completo dei parametri LookML analizzati da Analisi conversazionale, consulta la panoramica di Analisi conversazionale.
  • Valori di campo distinti: l'agente può campionare i valori dei dati ed eseguire ricerche fuzzy per verificare la presenza di valori di campo specifici nel database sottostante. Questi metodi consentono all'agente di scegliere i campi corretti, applicare i valori di filtro corretti e identificare le categorie e le entità disponibili su cui gli utenti potrebbero porre domande.

L'efficacia di Conversational Analytics è direttamente correlata alla qualità e alla chiarezza di questi 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 ridurre la latenza e migliorare l'output e l'esperienza utente.

Problema di qualità di LookML Soluzione per un'analisi conversazionale più chiara
Mancanza di chiarezza e conflitti di denominazione:i campi che non hanno etichette chiare, hanno definizioni ambigue o condividono nomi simili in diverse visualizzazioni possono portare a una selezione errata dei campi. Applica etichette chiare e descrizioni dettagliate:
  • Utilizza il parametro etichetta per assegnare ai campi nomi intuitivi e adatti all'attività.
  • Utilizza il parametro descrizione per fornire contesto critico, definizioni in linguaggio naturale e terminologia specifica del settore. L'analisi conversazionale utilizza le descrizioni per identificare meglio i significati dei campi e mappare i termini degli utenti.
Eccesso di campi:l'esposizione di un numero eccessivo di campi, ad esempio ID interni, campi duplicati da join o calcoli intermedi, ingombra le opzioni disponibili per Conversational Analytics. Nascondi i campi non pertinenti:assicurati che tutte le chiavi primarie, le chiavi esterne e i campi tecnici rimangano nascosti.

(Facoltativo) Estendi le esplorazioni:per le esplorazioni con molti campi, valuta la possibilità di creare una versione dedicata per l'analisi conversazionale estendendo un'esplorazione esistente.
Carico del database per il campionamento e la ricerca:il recupero di valori di esempio e suggerimenti dal database può essere lento o comportare un carico non necessario, soprattutto quando gli utenti fanno riferimento a valori di dati specifici nelle query. Definisci i suggerimenti in LookML:evita le query di database in tempo reale per i suggerimenti sui campi codificando i valori o puntando a dimensioni più efficienti:
  • Utilizza il parametro suggestions per codificare in modo permanente un elenco di valori possibili.
  • Utilizza i parametri suggest_explore e suggest_dimension per eseguire query su una dimensione alternativa più efficiente per i suggerimenti sui filtri.
Carico del database per le query sui dati: query di grandi dimensioni o inefficienti possono aumentare la latenza e il carico del database. Ottimizza le query sui dati:rispetta le best practice generali per ottimizzare il rendimento delle query, ad esempio utilizzando la consapevolezza aggregata e una logica di join efficiente.
Definizioni LookML incomplete:l'utilizzo di campi personalizzati o calcoli tabulari a livello di dashboard rende la logica di business critica inaccessibile all'Analisi conversazionale. Incorpora la logica personalizzata:converti i campi personalizzati o i calcoli tabellari importanti e di uso comune in dimensioni e misure LookML.
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ò portare alla duplicazione dei dati o a 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 filtro errati.
 Qualità dei dati degli indirizzi: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.

Punti chiave di LookML

Tieni presente questi punti chiave quando definisci LookML per le esplorazioni che verranno utilizzate come origini dati per l'analisi conversazionale:

  • Utilizza etichette chiare e precise:scegli etichette per i tuoi dati che riflettano il modo in cui parlano gli utenti aziendali. Evita abbreviazioni tecniche come "amt_usd_curr" e utilizza invece "Amount (USD)".
  • Attiva la mappatura perfetta:utilizza sinonimi e descrizioni per aiutare l'agente a mappare le domande degli utenti ai campi corretti.
  • Centralizza i calcoli:definisci i calcoli utilizzati di frequente direttamente come dimensioni o misure LookML per garantire una singola fonte di attendibilità e ridurre la latenza.
  • Semplifica il contesto: nascondi i campi tecnici o solo interni in LookML (come le chiavi esterne o gli ID non elaborati) per assicurarti che solo i campi necessari per rispondere alle domande aziendali vengano visualizzati in Analisi conversazionale. Concentrarsi solo sui campi pertinenti riduce il rumore e migliora l'accuratezza della selezione dei campi.
  • Ottimizza i dati di esempio e le query di ricerca fuzzy: definisci valori hardcoded nel parametro suggestions o utilizza suggest_dimension e suggest_explore per query di database più efficienti.
  • Ottimizza le query sui dati:rispetta le best practice generali di Looker per ottimizzare il rendimento delle query, ad esempio utilizzando la consapevolezza degli aggregati e una logica di join efficiente.

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

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

Per aiutare l'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 l'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 e una descrizione chiari e concisi.
    • Includi valori di esempio, se pertinenti. I valori di esempio sono particolarmente utili per i campi di tipo stringa.
  • Valuta la possibilità di curare esplorazioni specifiche per gli agenti di dati che riutilizzano i contenuti.
    • Utilizza extends per basarti sul codice LookML esistente e selezionare i campi necessari all'agente. In Attività di sistema, gli utenti possono vedere quali campi vengono utilizzati nelle query generate dagli agenti e decidere quali campi escludere.
    • Utilizza i miglioramenti LookML a livello di campo per creare descrizioni create appositamente per gli agenti, ad esempio "Utilizza il campo Ordini quando gli utenti fanno riferimento alle vendite".

Best practice per la creazione di agenti di dati

Dopo aver stabilito una base solida con le best practice di LookML ed esplorazioni ben configurate, puoi creare agenti di dati per fornire esperienze conversazionali personalizzate per casi d'uso o gruppi di utenti specifici. Gli agenti di dati si connettono a un massimo di cinque esplorazioni e utilizzano istruzioni in linguaggio naturale per fornire contesto, definire la terminologia e impostare linee guida comportamentali.

Seguire le best practice durante la creazione di agenti e la stesura delle istruzioni è fondamentale per personalizzare le risposte dell'agente in modo da soddisfare le esigenze specifiche degli utenti e migliorare l'accuratezza complessiva. Queste best practice includono la progettazione di agenti specializzati per domini specifici e la scrittura di istruzioni chiare ed efficaci.

Crea agenti specializzati

Sebbene possa essere allettante creare un unico agente di dati globale per gestire tutte le domande aziendali, gli agenti funzionano meglio quando sono specializzati per un dominio specifico, come vendite, marketing o analisi dei prodotti. A un agente incentrato su una o poche esplorazioni strettamente correlate possono essere fornite istruzioni più precise, il che riduce l'ambiguità e migliora l'accuratezza delle risposte.

Quando progetti gli agenti, evita di creare un singolo agente per gestire tutti i modelli di dati non correlati. Crea invece agenti mirati per aree aziendali distinte, collegandoti solo a esplorazioni strettamente correlate. Ad esempio, anziché un solo agente per tutti i dati aziendali, crea un "agente per le entrate" incentrato in modo specifico su Orders e sulle esplorazioni Transactions.

Scrivere istruzioni dell'agente efficaci

Le istruzioni dell'agente sono lo strumento principale per personalizzare il comportamento di un agente dati e infondergli la logica di business e la terminologia uniche della tua organizzazione. Considera le istruzioni come un modo per addestrare l'agente a interpretare le domande degli utenti, gestire l'ambiguità e rispondere nel modo più utile per gli utenti. Istruzioni ben scritte sono fondamentali per generare risposte accurate, pertinenti e affidabili.

Inserisci le istruzioni dell'agente nel campo Istruzioni quando crei l'agente di dati. Per saperne di più sulla creazione di agenti, consulta la pagina della documentazione Creare e gestire agenti di dati di Explore.

Per scrivere istruzioni efficaci, segui queste best practice:

  • Definisci il contesto aziendale e il comportamento predefinito: istruisci l'agente sulla logica e sulla terminologia uniche della tua organizzazione. Utilizza le istruzioni per definire gli acronimi (ad esempio, "LY significa l'anno scorso"), spiegare la logica di filtraggio comune o impostare i comportamenti predefiniti per l'ambiguità (ad esempio, "Se non viene fornito alcun date_created, filtra gli ultimi 6 mesi").
  • Utilizza la sintassi di LookML e dei filtri: quando fai riferimento a campi o applichi filtri nelle istruzioni, utilizza la sintassi di LookML (ad esempio events.date_created) e la sintassi dei filtri (ad esempio "last 6 months"). In questo modo, l'agente capisce quali campi o filtri applicare. Ad esempio: "Quando un utente chiede informazioni sulla "regione", utilizza il campo account_holder.geo_region".
  • Sii conciso: scrivi in modo chiaro ed evita parole o ripetizioni non necessarie nelle istruzioni.
  • Evita la ridondanza: non duplicare le informazioni che appartengono a LookML, come le descrizioni dei campi o i sinonimi. Per scoprire di più su quando definire il contesto in LookML rispetto alle istruzioni dell'agente, consulta Quando aggiungere il contesto a LookML rispetto all'analisi conversazionale. Evita inoltre di spiegare concetti di base che l'agente già conosce, ad esempio la differenza tra una dimensione e una metrica o come eseguire il filtro di base per data.

Limitazioni delle istruzioni dell'agente

Quando scrivi le istruzioni per l'agente, tieni presente le seguenti limitazioni di Analisi conversazionale:

  • Conversational Analytics non supporta la generazione di query che contengono il parametro pivots. Anche se Conversational Analytics può restituire dati per più dimensioni contemporaneamente, non può pivotarli in colonne separate come l'interfaccia utente di Esplora di Looker. Restituisce invece i dati in formato "lungo" o "appiattito", in modo che i dati vengano raggruppati orizzontalmente anziché verticalmente.
  • A differenza di LookML, che è governato, le istruzioni sono spesso testo in formato libero e possono diventare "obsolete" man mano che il modello dei dati sottostante si evolve nel tempo. Per evitare istruzioni non aggiornate con gli agenti di dati di Esplora, utilizza le query verificate per definire coppie di domande in linguaggio naturale e le query di Esplora corrispondenti.

Istruzioni dell'agente di esempio

Di seguito sono riportate alcune istruzioni di esempio per un agente dati connesso alle esplorazioni di Looker chiamate Elementi ordine e Prodotti:

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

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

Quando aggiungere il contesto a LookML anziché ad Analisi conversazionale

In Conversational Analytics, puoi aggiungere contesto a LookML o all'interno delle istruzioni dell'agente. Quando decidi dove aggiungere il contesto, segui queste indicazioni:

  • Il contesto che deve essere applicato a tutti gli utenti di un'esplorazione deve essere aggiunto direttamente al modello LookML, poiché le esplorazioni di Looker possono essere utilizzate in più posizioni, tra cui dashboard e analisi conversazionale. Se il contesto deve essere applicato solo a determinati utenti, valuta la possibilità di utilizzare funzionalità LookML come gli attributi utente per creare esperienze personalizzate.
  • Dai la priorità a LookML per i metadati specifici dei campi e i requisiti rigidi. Inserisci i metadati specifici del campo, inclusi sinonimi e descrizioni, direttamente in LookML anziché nelle istruzioni dell'agente. I requisiti per elementi come i valori predefiniti dei filtri o i campi nascosti devono essere gestiti idealmente in LookML per garantire che vengano rispettati.
  • Non duplicare informazioni che l'agente già conosce, ad esempio come creare una query di Looker, una spiegazione di dimensioni o misure, le esplorazioni accessibili o come eseguire il filtro di base per data. Allo stesso modo, non definire lo stesso termine sia in LookML sia nelle istruzioni dell'agente.

Il contesto dell'agente deve essere qualitativo e incentrato sull'utente. Inoltre, da un'unica esplorazione possono essere disponibili molti agenti che servono utenti diversi. LookML è utile per definire che cos'è un campo, ma in genere non può definire la strategia aziendale o i calcoli predittivi. 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 sono alcuni tipi di domande che questo utente porrà?
  • Quali campi sono più pertinenti per questo utente? Ad esempio, quali campi devono essere accessibili a questo utente, quali filtri devono essere sempre applicati o quali campi devono essere prioritari per questo utente?