Beste praksis for å forbedre generering av spørringer fra dataagenter

En dataagent genererer bedre spørringer når den har fokusert, nøyaktig kontekst om dataene den kan bruke. Objektnavn og skjemametadata gir et utgangspunkt, men de forklarer kanskje ikke forretningsbetydning, forventede verdier, relasjoner eller spørringslogikken som kreves for å svare på et spørsmål.

Bruk konfigurasjonen som best matcher konteksten du trenger å oppgi:

For en oversikt over disse innstillingene, se Dataagent-konfigurasjoner.

Bruk klare skjemanavn

Bruk beskrivende navn for datakilder, tabeller og kolonner når du kontrollerer skjemaet. Navn som CustomerOrders, , og product_unit_price gir agenten mer nyttige signaler enn navn som Table1, date1, og valueorder_submission_date.

Ikke stol bare på navngivning. Selv et klart teknisk navn kan ikke kommunisere objektets forretningsbetydning, detaljnivå, enheter eller gyldige verdier. Bruk beskrivelser og instruksjoner fra datakilden for å gi den konteksten.

Begrens det valgte skjemaet

Velg kun tabeller, kolonner, visninger og funksjoner som trengs for spørsmålene som dataagenten skal svare på. Irrelevante objekter øker tvetydigheten og gir spørringsgenereringsverktøyet flere mulige veier å vurdere.

For eksempel, hvis brukere spør om nåværende kundeordrer, bør du ikke inkludere arkiverte staging-tabeller eller ikke-relaterte finanstabeller. Når to valgte objekter inneholder lignende data, forklar hvilket som er autoritativt og når hvert enkelt skal brukes.

Beskriv skjemaobjekter (Forhåndsvisning)

For store eller tvetydige SQL-skjemaer, bruk skjemaobjektbeskrivelser for å forklare hva individuelle tabeller, kolonner og andre skjemaelementer representerer. Skjemaobjektbeskrivelser er kun tilgjengelige når dataagenten bruker forhåndsvisningskjøringen.

Beskrivelser er nyttige når:

• Objektnavn er forkortet, generiske eller ligner på hverandre.
• Et bords korn eller forretningsformål er ikke tydelig ut fra navnet.
• En kolonne inneholder koder, flagg, enheter eller kategoriverdier som krever tolkning.
• En datokolonne representerer en spesifikk forretningshendelse, som bestillingsinnsending i stedet for oppfyllelse.
• Skjemaet er for stort til å forklare hvert objekt tydelig i datakildeinstruksjoner.

Beskriv både betydning og forventede verdier når denne informasjonen påvirker generering av spørringer. Eksempel:

Prioriter beskrivelser for objekter som er vanskelige å slutte seg til. Unngå å gjenta et åpenbart navn uten å legge til forretningskontekst.

Bruk datakildeinstruksjoner for regler på tvers av objekter

Instruksjoner for datakilde gir veiledning for spørringsgenerering for en spesifikk datakilde. Bruk dem som kontekst som spenner over flere skjemaobjekter eller definerer hvordan en spørring skal konstrueres, inkludert:

• Autoritative tabeller for et.
• Join-nøkler og nødvendige join-stier.
• Regler for tabellkorn og deduplisering.
• Standardfiltre, som å bruke kun nåværende eller aktive poster.
• Datologikk, regnskapskalendere og tidssoneantakelser.
• Påkrevde beregninger eller utdatakolonner.

Skriv direkte instruksjoner som sier hva agenten skal gjøre. For eksempel, bruk «Join EmployeeStatusFact to EmployeeDim on EmployeeID» i stedet for «Unngå å koble til ansatttabeller feil.»

Hold instruksjonene fokusert. Legg objektspesifikke definisjoner i skjema-objektbeskrivelser i stedet for å bruke begrenset instruksjonsplass som ordliste for hver tabell og kolonne.

Definer forretningstermer og forventningsverdier

Definer terminologi som brukere kan inkludere i spørsmålene sine, men som ikke samsvarer direkte med skjemaet. Eksempler inkluderer forkortelser som «MAU», organisasjonsspesifikke betydninger av «aktiv kunde», og forskjeller som regnskapsår versus kalenderår.

Dokumenter også verdier agenten trenger for å konstruere filtre riktig:

• Om en tilstandskolonne bruker "CA" eller "California".
• Om en boolsk verdi lagres som 1 og 0, Y og N, eller tekst.
• Enten valutaverdier lagres i dollar eller cent.
• Hvilke statusverdier som representerer fullførte, kansellerte eller aktive poster.
• Om det er null, null eller en sentinel-dato har en spesiell betydning.

Plasser en definisjon i skjema-objektbeskrivelsen når den gjelder for ett objekt. Plasser det i datakildeinstruksjoner når det gjelder på tvers av datakilden eller påvirker flerobjekt-spørringslogikk.

Forklar sammenhenger og tabellkorn

Nøyaktige sammenføyninger avhenger av mer enn matchende kolonnenavn. Identifiser kornet av viktige tabeller, gyldige relasjonsstier og nøkler som ikke er åpenbare fra metadata.

For eksempel, forklar om en salgstabell inneholder én rad per ordre, ordrelinje eller daglig produkttotal. Hvis sammenkobling av to faktatabeller ville duplisere rader, instruer agenten til å aggregere hver tabell før sammenføyning eller bruke riktig dimensjonstabell.

Inkluder relasjonsveiledning som:

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

Bruk eksempelspørringer for kompleks logikk

Bruk eksempelspørringer når spørringen er klarere enn å beskrive logikken i prosa. Et godt eksempel parer et representativt spørsmål i naturlig språk med et gyldig spørsmål som viser det forventede mønsteret.

Prioriter eksempler som viser:

• Multi-table joins eller påkrevd pre-aggregering.
• Forretningsspesifikke beregninger.
• Relative datoer, regnskapsperioder eller øyeblikksbildelogikk.
• Filtre som mapper brukerterminologi til lagrede verdier.
• Rangering, vindusfunksjoner eller andre komplekse spørringsmønstre.

Hold hvert eksempel fokusert på ett gjenbrukbart mønster. Unngå overlappende eller motstridende eksempler, og verifiser at hvert eksempel fortsatt samsvarer med det nåværende skjemaet.

Test og forbedre konteksten

Test representative spørsmål, inspiser det genererte spørsmålet, og identifiser hvilken kontekst som manglet eller ble misforstått. Oppdater konfigurasjonen nærmest problemet:

• Fjern irrelevante objekter eller legg til manglende objekter i skjemavalget.
• Klargjør betydningen eller forventningsverdiene til ett objekt i skjemabeskrivelsen.
• Legg til tverrobjekt-forretnings- eller join-logikk i instruksjonene for datakilden.
• Legg til et eksempel på en spørring når agenten trenger å lære et spesifikt spørringsmønster.

Gjenta denne prosessen etter hvert som skjemaet og brukerspørsmålene utvikler seg. For en strukturert testarbeidsflyt, se Utvikle en dataagent ved å bruke en iterativ prosess.

Neste trinn

• Dataagentkonfigurasjoner
• Legg til skjema-objektbeskrivelser til en dataagent
• Fabric dataagent-kjøretid
• Eksempelforespørsler
• Legg til og konfigurer datakilder