Bedste praksis for at forbedre generering af forespørgsler fra dataagenter

En dataagent genererer bedre forespørgsler, når den har fokuseret og præcis kontekst om de data, den kan bruge. Objektnavne og skemametadata giver et udgangspunkt, men de forklarer måske ikke forretningsbetydning, forventede værdier, relationer eller den forespørgselslogik, der kræves for at besvare et spørgsmål.

Brug den konfiguration, der bedst matcher den kontekst, du skal give:

For et overblik over disse indstillinger, se Dataagent-konfigurationer.

Brug klare skema-navne

Brug beskrivende navne til datakilder, tabeller og kolonner, når du styrer skemaet. Navne som CustomerOrders, , og product_unit_price giver agenten mere nyttige signaler end navne som Table1, date1, og valueorder_submission_date.

Stol ikke kun på navngivning. Selv et klart teknisk navn kommunikerer måske ikke objektets forretningsbetydning, detaljegrad, enheder eller gyldige værdier. Brug beskrivelser og datakildeinstruktioner til at give den kontekst.

Begræns det valgte skema

Vælg kun tabeller, kolonner, visninger og funktioner, der er nødvendige for de spørgsmål, som dataagenten skal besvare. Irrelevante objekter øger tvetydigheden og giver forespørgselsgenereringsværktøjet flere mulige veje at overveje.

For eksempel, hvis brugere spørger om aktuelle kundeordrer, skal du ikke inkludere arkiverede staging-tabeller eller ikke-relaterede finanstabeller. Når to udvalgte objekter indeholder lignende data, forklar hvilket der er autoritativt, og hvornår hvert enkelt skal bruges.

Beskriv skema-objekter (Forhåndsvisning)

For store eller tvetydige SQL-skemaer skal du bruge skemaobjektbeskrivelser til at forklare, hvad individuelle tabeller, kolonner og andre skemaelementer repræsenterer. Skemaobjektbeskrivelser er kun tilgængelige, når dataagenten bruger preview-runtime.

Beskrivelser er nyttige, når:

• Objektnavne forkortes, generiske eller ligner hinanden.
• Et bords korn eller forretningsformål fremgår ikke af navnet.
• En kolonne indeholder koder, flag, enheder eller kategoriværdier, der kræver fortolkning.
• En datokolonne repræsenterer en specifik forretningsbegivenhed, såsom ordreindsendelse i stedet for opfyldelse.
• Skemaet er for stort til klart at forklare hvert objekt i datakildeinstruktionerne.

Beskriv både betydning og forventede værdier, når denne information påvirker forespørgselsgenerering. Eksempel:

Prioriter beskrivelser af objekter, der er svære at udlede. Undgå at gentage et åbenlyst navn uden at tilføje forretningskontekst.

Brug datakildeinstruktioner for regler på tværs af objekter

Instruktioner til datakilden giver vejledning til generering af forespørgsler for en specifik datakilde. Brug dem til kontekst, der spænder over flere skemaobjekter eller definerer, hvordan en forespørgsel skal konstrueres, herunder:

• Autoritative tabeller for et emne.
• Join-nøgler og nødvendige join-stier.
• Regler for tabelkorn og deduplikation.
• Standardfiltre, såsom kun at bruge aktuelle eller aktive poster.
• Datologik, finansielle kalendere og tidszoneantagelser.
• Påkrævede beregninger eller outputkolonner.

Skriv direkte instruktioner, der angiver, hvad agenten skal gøre. For eksempel kan du bruge "Join EmployeeStatusFact to on EmployeeDimEmployeeID" i stedet for "Undgå at joine medarbejdertabeller forkert."

Hold vejledningen fokuseret. Sæt objektspecifikke definitioner i skema-objektbeskrivelser i stedet for at bruge begrænset instruktionsplads som ordliste for hver tabel og kolonne.

Definér forretningstermer og forventede værdier

Definér terminologi, som brugerne måske inkluderer i deres spørgsmål, men som ikke direkte matcher skemaet. Eksempler inkluderer forkortelser som "MAU", organisationsspecifikke betydninger af "aktiv kunde" og skelnen som regnskabsår versus kalenderår.

Dokumentér også værdier, som agenten har brug for for at konstruere filtre korrekt:

• Uanset om en tilstandskolonne bruger "CA" eller "California".
• Om en boolesk værdi gemmes som 1 og 0, Y og N, eller tekst.
• Om valutaværdier opbevares i dollars eller cent.
• Hvilke statusværdier repræsenterer færdige, annullerede eller aktive poster.
• Om det er null, nul eller en sentinel-dato har en særlig betydning.

Placer en definition i skemaobjektbeskrivelsen, når den gælder for ét objekt. Placer det i datakildeinstruktionerne, når det gælder på tværs af datakilden eller påvirker multi-objekt-forespørgselslogikken.

Forklar relationer og tabellkorn

Nøjagtige joins afhænger af mere end matchende kolonnenavne. Identificer kornet af vigtige tabeller, gyldige relationsstier og nøgler, der ikke er åbenlyse ud fra metadata.

For eksempel kan du forklare, om en salgstabel indeholder én række pr. ordre, ordrelinje eller dagligt produkttotal. Hvis sammenslutning af to faktatabeller ville duplikere rækker, instruer agenten i at aggregere hver tabel før sammenføjning eller bruge den relevante dimensionstabel.

Inkluder forholdsvejledning så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.

Brug eksempelforespørgsler til kompleks logik

Brug eksempelforespørgsler , når forespørgslen vises er klarere end at beskrive logikken i prosa. Et godt eksempel parrer et repræsentativt spørgsmål i naturligt sprog med et gyldigt spørgsmål, der demonstrerer det forventede mønster.

Prioriter eksempler, der demonstrerer:

• Multi-table joins eller krævet præaggregation.
• Forretningsspecifikke beregninger.
• Relative datoer, regnskabsperioder eller snapshot-logik.
• Filtre, der mapper brugerterminologi til lagrede værdier.
• Rangering, vinduesfunktioner eller andre komplekse forespørgselsmønstre.

Hold hvert eksempel fokuseret på ét genanvendeligt mønster. Undgå overlappende eller modstridende eksempler, og bekræft, at hvert eksempel stadig matcher det aktuelle skema.

Test og forfine konteksten

Test repræsentative spørgsmål, inspicer den genererede forespørgsel, og identificer hvilken kontekst, der manglede eller blev misforstået. Opdater konfigurationen tættest på problemet:

• Fjern irrelevante objekter eller tilføj manglende objekter i skemavalget.
• Præciser betydningen eller de forventede værdier af et objekt i dets skemabeskrivelse.
• Tilføj tvær-objekt-forretnings- eller join-logik til datakildeinstruktionerne.
• Tilføj et eksempelforespørgsel, når agenten skal lære et specifikt forespørgselsmønster.

Gentag denne proces, efterhånden som skemaet og brugerspørgsmålene udvikler sig. For en struktureret testarbejdsgang, se Udvikl en dataagent ved at bruge en iterativ proces.

Næste trin

• Dataagent-konfigurationer
• Tilføj skema-objektbeskrivelser til en dataagent
• Fabric data agent runtime
• Eksempelforespørgsler
• Tilføj og konfigurer datakilder