Best practices voor het verbeteren van de querygeneratie van data-agents

Een dataagent genereert betere queries wanneer hij gefocuste, accurate context heeft over de data die hij kan gebruiken. Objectnamen en schemametadata bieden een uitgangspunt, maar ze leggen mogelijk niet de zakelijke betekenis, verwachte waarden, relaties of de querylogica uit die nodig is om een vraag te beantwoorden.

Gebruik de configuratie die het beste past bij de context die je moet geven:

Voor een overzicht van deze instellingen, zie Data agent configuraties.

Gebruik duidelijke schemanamen

Gebruik beschrijvende namen voor databronnen, tabellen en kolommen wanneer je het schema bestuurt. Namen zoals CustomerOrders, , en product_unit_price geven de agent nuttigere signalen dan namen zoals Table1, date1, en valueorder_submission_date.

Vertrouw niet alleen op naamgeving zelf. Zelfs een duidelijke technische naam communiceert mogelijk niet de zakelijke betekenis, het detailniveau, de eenheden of geldige waarden van het object. Gebruik beschrijvingen en gegevensbroninstructies om die context te bieden.

Beperk het geselecteerde schema

Selecteer alleen de tabellen, kolommen, weergaven en functies die nodig zijn voor de vragen die de dataagent moet beantwoorden. Irrelevante objecten vergroten ambiguïteit en geven het query-genererende hulpmiddel meer mogelijke paden om te overwegen.

Als gebruikers bijvoorbeeld vragen naar huidige klantorders, neem dan geen gearchiveerde stagingtabellen of niet-gerelateerde financiële tabellen toe. Wanneer twee geselecteerde objecten vergelijkbare gegevens bevatten, leg dan uit welk object gezaghebbend is en wanneer elk object gebruikt moet worden.

Beschrijf schema-objecten (Voorbeeld)

Voor grote of ambigue SQL-schema's gebruik je schema-objectbeschrijvingen om uit te leggen wat individuele tabellen, kolommen en andere schema-elementen vertegenwoordigen. Schema-objectbeschrijvingen zijn alleen beschikbaar wanneer de data-agent de preview-runtime gebruikt.

Beschrijvingen zijn nuttig wanneer:

• Objectnamen worden afgekort, generiek of vergelijkbaar met elkaar.
• De granulariteit of het zakelijke doel van een tabel blijkt niet uit de naam.
• Een kolom bevat codes, vlaggen, eenheden of categoriewaarden die geïnterpreteerd moeten worden.
• Een datumkolom geeft een specifiek bedrijfsevenement aan, zoals het indienen van een bestelling in plaats van de vervulling.
• Het schema is te groot om elk object duidelijk uit te leggen in datasource-instructies.

Beschrijf zowel betekenis als verwachtingswaarden wanneer die informatie de zoekgeneratie beïnvloedt. Voorbeeld:

Geef prioriteit aan beschrijvingen van objecten die moeilijk af te leiden zijn. Vermijd het herhalen van een voor de hand liggende naam zonder zakelijke context toe te voegen.

Gebruik databroninstructies voor regels over objecten heen

Instructies voor gegevensbronn bieden richtlijnen voor het genereren van zoekopdrachten voor een specifieke databron. Gebruik ze voor context die meerdere schema-objecten omvat of definieert hoe een query moet worden opgebouwd, waaronder:

• Gezaghebbende tabellen voor een onderwerp.
• Koppelingssleutels en vereiste koppelingspaden.
• Regels voor tabelgranulariteit en deduplicatie.
• Standaardfilters, zoals het gebruik van alleen huidige of actieve records.
• Datumlogica, fiscale kalenders en tijdzone-aannames.
• Vereiste berekeningen of uitvoerkolommen.

Schrijf directe instructies waarin staat wat de agent moet doen. Gebruik bijvoorbeeld "Voeg EmployeeStatusFact samen met EmployeeDim op basis van EmployeeID" in plaats van "Voorkom dat werknemerstabellen onjuist worden samengevoegd."

Houd de instructies gericht. Plaats objectspecifieke definities in schema-objectbeschrijvingen in plaats van beperkte instructieruimte als woordenlijst te gebruiken voor elke tabel en kolom.

Definieer zakelijke termen en verwachte waarden

Definieer terminologie die gebruikers in hun vragen kunnen opnemen, maar die niet direct aansluiten bij het schema. Voorbeelden zijn acroniemen zoals "MAU", organisatiespecifieke betekenissen van "actieve klant" en onderscheidingen zoals boekjaar versus kalenderjaar.

Documenteer ook waarden die de agent nodig heeft om filters correct te construeren:

• Of een toestandskolom "CA" of "California" gebruikt.
• Of een Booleaanse waarde wordt opgeslagen als 1 en 0, Y en N, of als tekst.
• Of valutawaarden nu in dollars of centen worden opgeslagen.
• Welke statuswaarden vertegenwoordigen voltooide, geannuleerde of actieve records.
• Of het nu nul, nul of een sentineldatum is, heeft een speciale betekenis.

Plaats een definitie in de schema-objectbeschrijving wanneer deze op één object van toepassing is. Plaats het in de databroninstructies wanneer het van toepassing is op de databron of de multi-object querylogica beïnvloedt.

Leg relaties en tabelkorrel uit

Nauwkeurige joins hangen af van meer dan het matchen van kolomnamen. Identificeer de korrel van belangrijke tabellen, geldige relatiepaden en sleutels die niet duidelijk zijn uit metadata.

Leg bijvoorbeeld uit of een verkooptabel één rij per order, orderregel of dagelijks producttotaal bevat. Als het samenvoegen van twee feitentabellen rijen dupliceert, geef dan opdracht aan de agent om elke tabel te aggregeren voordat hij samenvoegt of om de juiste dimensietabele te gebruiken.

Voeg relatieadvies toe, zoals:

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

Gebruik voorbeeldqueries voor complexe logica

Gebruik voorbeeldzoekopdrachten wanneer de query duidelijker is dan het beschrijven van de logica in proza. Een goed voorbeeld koppelt een representatieve vraag in natuurlijke taal aan een geldige vraag die het verwachte patroon aantoont.

Geef prioriteit aan voorbeelden die het volgende aantonen:

• Joins met meerdere tabellen of vereiste voorafgaande aggregatie.
• Bedrijfsspecifieke berekeningen.
• Relatieve datums, fiscale periodes of momentopnamelogica.
• Filters die gebruikersterminologie koppelen aan opgeslagen waarden.
• Rangordening, vensterfuncties, of andere complexe querypatronen.

Houd elk voorbeeld gericht op één herbruikbaar patroon. Vermijd overlappende of tegenstrijdige voorbeelden en controleer dat elk voorbeeld nog steeds overeenkomt met het huidige schema.

Test en verfijn de context

Test representatieve vragen, inspecteer de gegenereerde query en identificeer welke context ontbrak of verkeerd begrepen werd. Werk de configuratie bij die het dichtst bij het probleem ligt:

• Verwijder irrelevante objecten of voeg ontbrekende objecten toe bij schemaselectie.
• Verduidelijkt de betekenis of verwachte waarden van één object in de schemabeschrijving.
• Voeg bedrijfslogica voor meerdere objecten of koppelingslogica toe aan instructies voor de gegevensbron.
• Voeg een voorbeeldquery toe wanneer de agent een specifiek querypatroon moet leren.

Herhaal dit proces terwijl het schema en de gebruikersvragen zich ontwikkelen. Voor een gestructureerde testworkflow, zie Ontwikkel een data-agent door gebruik te maken van een iteratief proces.

Volgende stappen

• Configuraties van gegevensagent
• Voeg schema-objectbeschrijvingen toe aan een data-agent
• runtime van de Fabric-gegevensagent
• Voorbeeldqueries
• Voeg databronnen toe en configureer