Best practice per la configurazione dell'analisi conversazionale in Looker

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

Questa guida fornisce strategie e best practice per gli sviluppatori e gli amministratori di LookML per configurare e ottimizzare Analisi conversazionale. 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 ad Analisi conversazionale, seguendo un flusso logico che inizia con lo sviluppo di una base solida in LookML di un modello, la configurazione delle esplorazioni basate su questo modello e la creazione di agenti di dati che utilizzano queste esplorazioni come origini dati.

Best practice di LookML per Analisi conversazionale

Analisi conversazionale interpreta le domande in linguaggio naturale sfruttando 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 Explore. Per l'elenco completo dei parametri LookML analizzati da Analisi conversazionale, consulta la panoramica di Analisi conversazionale.
  • Valori dei campi distinti: l'agente può campionare i valori dei dati ed eseguire ricerche approssimative per verificare la presenza di valori di campi specifici nel database sottostante. Questi metodi consentono all'agente di scegliere i campi corretti, applicare i valori dei filtri corretti e identificare le categorie e le entità disponibili su cui gli utenti potrebbero porre domande.

L'efficacia di Analisi conversazionale è direttamente correlata alla qualità e alla chiarezza di questi input. La tabella seguente contiene i modi comuni in cui LookML non chiaro o ambiguo può influire negativamente su Analisi conversazionale, 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 viste diverse possono portare a una selezione errata dei campi. Applica etichette chiare e descrizioni dettagliate:
  • Utilizza il parametro label per assegnare ai campi nomi intuitivi e adatti all'attività.
  • Utilizza il parametro description per fornire contesto critico, definizioni in linguaggio naturale e terminologia specifica del settore. Analisi conversazionale utilizza le descrizioni per identificare meglio i significati dei campi e mappare i termini degli utenti.
Eccessivo numero di campi: l'esposizione di troppi campi, come ID interni, campi duplicati da join o calcoli intermedi, ingombra le opzioni disponibili per Analisi conversazionale. 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 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 suggestions parametro per codificare un elenco di valori possibili.
  • Utilizza i parametri suggest_explore e suggest_dimension per eseguire query su una dimensione alternativa e più efficiente per i suggerimenti sui filtri.
Carico del database per le query sui dati: le 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 l'ottimizzazione del rendimento delle query, ad esempio utilizzando la consapevolezza degli aggregati 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 ad Analisi conversazionale. Incorpora la logica personalizzata: converti i campi personalizzati o i calcoli tabulari importanti e di uso comune in dimensioni e misure LookML.
Dati disordinati: i seguenti tipi di dati incoerenti o scarsamente strutturati rendono difficile per Analisi conversazionale interpretare le query in modo accurato.
  • Variazioni dei valori: la capitalizzazione o le convenzioni di denominazione incoerenti (ad esempio, una combinazione dei valori complete, Complete e COMPLETE) possono comportare la duplicazione dei dati o relazioni errate tra i dati in Analisi conversazionale.
  • Tipi di dati incoerenti: le colonne che devono essere numeriche e che contengono valori stringa occasionali forzano il tipo di campo a essere string, il che impedisce le operazioni numeriche.
  • Ambiguità del fuso orario: la mancanza di fusi orari standardizzati nei campi timestamp può comportare un filtraggio o un'aggregazione errati.
 Risolvi i problemi di qualità dei dati: se possibile, segnala i problemi di qualità dei dati (valori, tipi, 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 Analisi conversazionale:

  • Utilizza etichette chiare e precise: scegli etichette per i tuoi dati che riflettano il modo in cui parlano effettivamente gli utenti aziendali. Evita le abbreviazioni tecniche come "amt_usd_curr" e utilizza invece "Amount (USD)".
  • Consenti una mappatura senza interruzioni: 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 un'unica fonte di attendibilità e ridurre la latenza.
  • Semplifica il contesto: nascondi i campi tecnici o solo interni in LookML (come chiavi esterne o 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 approssimativa: definisci i valori codificati nel parametro suggestions oppure 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 l'ottimizzazione del rendimento delle query, ad esempio utilizzando la consapevolezza degli aggregati e una logica di join efficiente.

Per ulteriori best practice per la scrittura di codice LookML pulito ed efficiente, consulta la seguente documentazione:

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

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

  • Nel codice LookML sottostante l'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 le esplorazioni specifiche degli agenti di dati che riutilizzano i contenuti.
    • Utilizza extends per basarti sul codice LookML esistente e curare i campi di cui l'agente ha bisogno. In Attività di sistema, gli utenti possono vedere quali campi vengono utilizzati nelle query generate dagli agenti e decidere quali campi escludere.
    • Utilizza i perfezionamenti 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 e le 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 le linee guida comportamentali.

Seguire le best practice durante la creazione di agenti e la scrittura di 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 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 di business distinte, collegandoti solo a esplorazioni strettamente correlate. Ad esempio, anziché un agente per tutti i dati aziendali, crea un "Agente di entrate" incentrato specificamente sulle esplorazioni Orders e Transactions.

Scrivi istruzioni efficaci per gli agenti

Le istruzioni dell'agente sono lo strumento principale per personalizzare il comportamento di un agente di dati e infonderlo con la logica di business e la terminologia uniche della tua organizzazione. Considera le istruzioni come un modo per addestrare l'agente su come interpretare le domande degli utenti, gestire l'ambiguità e rispondere nel modo più utile per gli utenti. Le 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 ulteriori informazioni sulla creazione di agenti, consulta la pagina della documentazione Creare e gestire agenti di dati di esplorazione.

Per scrivere istruzioni efficaci, segui queste best practice:

  • Definisci il contesto aziendale e il comportamento predefinito: addestra l'agente sulla logica e la terminologia uniche della tua organizzazione. Utilizza le istruzioni per definire gli acronimi (ad esempio, "LY significa anno scorso"), spiegare la logica di filtraggio comune o impostare comportamenti predefiniti per l'ambiguità (ad esempio, "Se non viene fornita alcuna 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 comprende quali campi o filtri applicare. Ad esempio: "Quando un utente chiede informazioni sulla 'regione', utilizza il campo account_holder.geo_region."
  • Utilizza le query dorate per esempi complessi: per le domande o le query comuni che coinvolgono una logica di business complessa, fornisci golden queries, ovvero coppie di domande in linguaggio naturale e le relative query di Looker verificate. Le query dorate possono aiutare l'agente a imparare pattern specifici. Concentrati sulle query che chiariscono la terminologia complessa o le combinazioni di filtri comuni. Le query dorate devono essere fornite in una rappresentazione di query LookML specifica anziché in SQL non elaborato o URL di esplorazione standard.
  • 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 saperne di più su quando definire il contesto in LookML rispetto alle istruzioni dell'agente, consulta Quando aggiungere il contesto a LookML rispetto ad Analisi conversazionale. Evita anche di spiegare concetti di base che l'agente comprende già, come la differenza tra una dimensione e una misura o come eseguire il filtraggio di base delle date.

Limitazioni delle istruzioni dell'agente

Tieni presente le seguenti limitazioni di Analisi conversazionale quando scrivi le istruzioni dell'agente:

  • Analisi conversazionale non supporta la generazione di query che contengono il pivots parametro. Sebbene Analisi conversazionale possa restituire dati per più dimensioni contemporaneamente, non può eseguirne il pivot in colonne separate come può fare l'UI di esplorazione di Looker. Restituisce invece i dati in formato "lungo" o "appiattito", quindi i dati vengono raggruppati orizzontalmente anziché verticalmente.

  • Analisi conversazionale non può riutilizzare i campi personalizzati definiti nei contenuti di Looker esistenti (ad esempio, quando utilizzi il codice LookML generato da un'esplorazione che contiene un campo personalizzato per creare una query di riferimento) o generare nuovi campi personalizzati all'interno di una nuova query. Utilizza invece i campi LookML esistenti o Python per creare calcoli personalizzati sui risultati dei dati.

  • A differenza di LookML, che è regolamentato, le istruzioni sono spesso testo in formato libero e possono diventare "obsolete" man mano che il modello dei dati sottostante si evolve nel tempo

Esempio di istruzioni dell'agente

Di seguito sono riportate alcune istruzioni di esempio per un agente di dati connesso alle esplorazioni di Looker denominate Order Items e 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.

Quando aggiungere il contesto a LookML rispetto ad Analisi conversazionale

In Analisi conversazionale, puoi aggiungere il contesto a LookML o all'interno delle istruzioni dell'agente. Quando decidi dove aggiungere il contesto, applica le seguenti 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 le funzionalità di 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 dei campi, inclusi sinonimi e descrizioni, direttamente in LookML anziché nelle istruzioni dell'agente. I requisiti per elementi come i valori dei filtri predefiniti o i campi nascosti devono essere gestiti idealmente in LookML per garantirne il rispetto.
  • Non duplicare le informazioni che l'agente conosce già, ad esempio come creare una query di Looker, una spiegazione di dimensioni o misure, le esplorazioni accessibili o come eseguire il filtraggio di base delle date. 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 e possono essere presenti molti agenti che servono utenti diversi da un'esplorazione. LookML è utile per definire cos'è un campo, ma in genere non può definire la strategia aziendale o i calcoli predittivi. Di seguito sono riportati esempi di contesto che devono essere inclusi nelle istruzioni dell'agente, ma non in LookML:

  • Chi è l'utente che interagisce con l'agente? Che ruolo ricopre? È interno o esterno all'azienda? Qual è la sua esperienza di analisi precedente?
  • Qual è l'obiettivo dell'utente? Che tipo di decisione sta cercando di prendere alla fine della conversazione?
  • Quali sono alcuni tipi di domande che questo utente porrà?
  • Quali sono i campi più pertinenti per questo utente? Ad esempio, quali campi devono essere accessibili a questo utente, devono essere sempre applicati determinati filtri o alcuni campi devono avere la priorità per questo utente?