Migliori pratiche per migliorare la generazione delle query degli agenti dati

Un data agent genera query migliori quando dispone di un contesto focalizzato e accurato sui dati che può utilizzare. I nomi degli oggetti e i metadati degli schemi forniscono un punto di partenza, ma potrebbero non spiegare il significato aziendale, i valori attesi, le relazioni o la logica di query necessaria per rispondere a una domanda.

Usa la configurazione che meglio corrisponde al contesto che devi fornire:

Per una panoramica di queste impostazioni, vedi Configurazioni degli agenti dati.

Usa nomi chiari degli schemi

Usa nomi descrittivi per sorgenti dati, tabelle e colonne quando controlli lo schema. Nomi come , , e product_unit_price forniscono all'agente segnali più utili rispetto a nomi come Table1, date1, e value. order_submission_dateCustomerOrders

Non affidarti solo al nome. Anche un nome tecnico chiaro potrebbe non comunicare il significato commerciale dell'oggetto, il livello di dettaglio, le unità o i valori validi. Usa descrizioni e istruzioni sulla fonte dei dati per fornire quel contesto.

Limita lo schema selezionato

Seleziona solo le tabelle, colonne, viste e funzioni necessarie per le domande a cui l'agente dati deve rispondere. Gli oggetti irrilevanti aumentano l'ambiguità e offrono allo strumento di generazione delle query più percorsi possibili da considerare.

Ad esempio, se gli utenti chiedono informazioni sugli ordini correnti dei clienti, non includere tabelle di staging archiviate o tabelle finanziarie non correlate. Quando due oggetti selezionati contengono dati simili, spiega quale è autorevole e quando utilizzare ciascuno.

Descrivi gli oggetti schema (Anteprima)

Per schemi SQL grandi o ambigui, usa descrizioni degli oggetti schema per spiegare cosa rappresentano singole tabelle, colonne e altri elementi dello schema. Le descrizioni degli oggetti schema sono disponibili solo quando l'agente dati utilizza l'esecuzione di anteprima.

Le descrizioni sono utili quando:

• I nomi degli oggetti sono abbreviati, generici o simili tra loro.
• La granularità o la finalità aziendale di una tabella non è evidente dal suo nome.
• Una colonna contiene codici, flag, unità o valori di categoria che richiedono interpretazione.
• Una colonna di data rappresenta un evento aziendale specifico, come l'invio dell'ordine piuttosto che la soddisfazione.
• Lo schema è troppo grande per spiegare chiaramente ogni oggetto nelle istruzioni della fonte dati.

Descrivi sia il significato che i valori attesi quando tali informazioni influenzano la generazione delle query. Per esempio:

Dai priorità alle descrizioni degli oggetti difficili da dedurre. Evita di ripetere un nome ovvio senza aggiungere contesto aziendale.

Usa le istruzioni della sorgente dati per le regole tra gli oggetti

Le istruzioni per la sorgente dati forniscono indicazioni per la generazione di query per una specifica fonte di dati. Usali per contesto che copre più oggetti di schema o definisce come una query dovrebbe essere costruita, incluso:

• Tabelle autorevole per un argomento.
• Chiavi di join e percorsi di join necessari.
• Regole di granularità e deduplicazione della tabella.
• Filtri predefiniti, come l'uso solo di record attuali o attivi.
• Logica delle date, calendari fiscali e assunzioni di fuso orario.
• Calcoli o colonne di output richieste.

Scrivi istruzioni dirette che specifichino cosa deve fare l'agente. Ad esempio, utilizza "Unisci EmployeeStatusFact a EmployeeDim in base a EmployeeID" invece di "Evita di unire in modo errato le tabelle dei dipendenti."

Mantenere incentrate le istruzioni. Inserisci definizioni specifiche per oggetto nelle descrizioni degli oggetti schema invece di usare uno spazio limitato delle istruzioni come glossario per ogni tabella e colonna.

Definire i termini aziendali e i valori attesi

Definisci una terminologia che gli utenti potrebbero includere nelle loro domande ma che non corrisponde direttamente allo schema. Esempi includono acronimi come "MAU", significati specifici dell'organizzazione di "cliente attivo" e distinzioni come anno fiscale e anno solare.

Documenta anche i valori di cui l'agente ha bisogno per costruire correttamente i filtri:

• Se una colonna di stato utilizza "CA" o "California".
• Che un valore booleano sia memorizzato come 1 e 0, Y e N, oppure testo.
• Se gli importi in valuta sono memorizzati in dollari o in centesimi.
• Quali valori di stato rappresentano record completati, cancellati o attivi.
• Che sia nulla, zero o una data sentinella ha un significato speciale.

Inserisci una definizione nella descrizione dell'oggetto schema quando si applica a un oggetto. Inseriscila nelle istruzioni dell'origine dati quando si applica all'intera origine dati o influisce sulla logica delle query su più oggetti.

Spiega le relazioni e la grana della tabella

Le unioni accurate dipendono da più del semplice corrispondere dei nomi delle colonne. Identifica la granulatura delle tabelle importanti, i percorsi di relazione validi e le chiavi che non sono evidenti dai metadati.

Ad esempio, spiega se una tabella di vendita contiene una riga per ogni ordine, linea d'ordine o totale giornaliero del prodotto. Se l'unione di due tabelle di fatto dovesse duplicare le righe, istruisca l'agente ad aggregare ciascuna tabella prima di unirle oppure a utilizzare la tabella delle dimensioni appropriata.

Includi indicazioni sulle relazioni come:

- Join `OrderItems` to `Orders` on `OrderID`.
- Join `Orders` to `Customers` on `CustomerID`.
- Aggregate `OrderItems` to one row per `OrderID` before joining to order-level payment totals.

Usa query di esempio per la logica complessa

Usa query di esempio quando mostri che la query è più chiara rispetto a quella che descrive la logica in prosa. Un buon esempio abbina una domanda rappresentativa in linguaggio naturale a una query valida che dimostra il modello atteso.

Dai priorità agli esempi che dimostrano:

• Join tra più tabelle o preaggregazione necessaria.
• Calcoli specifici per l'azienda.
• Date relative, periodi fiscali o logica degli snapshot.
• Filtri che mappano la terminologia utente ai valori memorizzati.
• Classificazioni, funzioni di finestra o altri modelli di query complessi.

Mantieni ogni esempio focalizzato su un unico motivo riutilizzabile. Evita esempi sovrapposti o contraddittori e verifica che ogni esempio corrisponda ancora allo schema corrente.

Testare e affinare il contesto

Prova domande rappresentative, ispeziona la query generata e identifica quale contesto mancava o è stato frainteso. Aggiorna la configurazione più vicina al problema:

• Rimuovere oggetti irrilevanti o aggiungerne quelli mancanti nella selezione dello schema.
• Chiarisci il significato o i valori attesi di un oggetto nella descrizione dello schema.
• Aggiungi una logica di business tra oggetti o una logica di join alle istruzioni dell'origine dati.
• Aggiungi una query di esempio quando l'agente deve imparare un modello di query specifico.

Ripeti questo processo man mano che lo schema e le domande degli utenti si evolvono. Per un flusso di lavoro di testing strutturato, vedi Sviluppa un data agent utilizzando un processo iterativo.

Passaggi successivi

• Configurazioni dell'agente dati
• Aggiungi descrizioni degli oggetti schema a un data agent
• runtime dell'agente dati Fabric
• Query di esempio
• Aggiungi e configura le fonti dei dati