Meilleures pratiques pour améliorer la génération de requêtes des agents de données

Un agent de données génère de meilleures requêtes lorsqu’il dispose d’un contexte précis et ciblé sur les données qu’il peut utiliser. Les noms d’objets et les métadonnées de schéma fournissent un point de départ, mais ils peuvent ne pas expliquer la signification métier, les valeurs attendues, les relations ou la logique de requête nécessaire pour répondre à une question.

Utilisez la configuration qui correspond le mieux au contexte que vous devez fournir :

Pour un aperçu de ces paramètres, voir Configurations des agents de données.

Utilisez des noms de schémas clairs

Utilisez des noms descriptifs pour les sources de données, les tables et les colonnes lorsque vous contrôlez le schéma. Des noms tels que CustomerOrders, , et product_unit_price donnent à l’agent des signaux plus utiles que des noms tels que Table1, date1, et valueorder_submission_date.

Ne vous fiez pas uniquement au nom. Même un nom technique clair peut ne pas communiquer la signification commerciale de l’objet, son niveau de détail, ses unités ou ses valeurs valides. Utilisez des descriptions et des instructions de source de données pour fournir ce contexte.

Limitez le schéma sélectionné

Sélectionnez uniquement les tableaux, colonnes, vues et fonctions nécessaires aux questions auxquelles l’agent de données doit répondre. Les objets non pertinents augmentent l’ambiguïté et offrent à l’outil de génération de requêtes plus de chemins possibles à considérer.

Par exemple, si les utilisateurs demandent des informations sur les commandes clients en cours, n’incluez pas de tables de préproduction archivées ni de tables financières non pertinentes. Lorsque deux objets sélectionnés contiennent des données similaires, expliquez lequel est autoritaire et quand utiliser chacun.

Décrire les objets de schéma (Aperçu)

Pour les schémas SQL grands ou ambigus, utilisez des descriptions d’objets de schéma pour expliquer ce que représentent les tables, colonnes et autres éléments de schéma individuels. Les descriptions des objets de schéma ne sont disponibles que lorsque l’agent de données utilise l’exécution de prévisualisation.

Les descriptions sont utiles lorsque :

• Les noms des objets sont abrégés, génériques ou similaires entre eux.
• La granularité ou la finalité métier d’une table ne ressort pas de son nom.
• Une colonne contient des codes, des drapeaux, des unités ou des valeurs de catégorie qui nécessitent une interprétation.
• Une colonne de date représente un événement commercial spécifique, comme la soumission d’une commande plutôt que la réalisation d’une commande.
• Le schéma est trop grand pour expliquer chaque objet clairement dans les instructions de source de données.

Décrivez à la fois le sens et les valeurs attendues lorsque ces informations affectent la génération des requêtes. Par exemple:

Priorisez les descriptions des objets difficiles à déduire. Évitez de répéter un nom évident sans ajouter de contexte professionnel.

Utiliser les instructions de source de données pour les règles entre objets

Les instructions de source de données fournissent des indications de génération de requêtes pour une source de données spécifique. Utilisez-les pour un contexte qui englobe plusieurs objets de schéma ou définit comment une requête doit être construite, notamment :

• Tables de référence pour un sujet.
• Clés de jonction et chemins de jonction obligatoires.
• Règles de grain de table et de déduplication.
• Filtres par défaut, comme n’utiliser que les enregistrements actuels ou actifs.
• Logique des dates, calendriers fiscaux et hypothèses de fuseaux horaires.
• Calculs ou colonnes de sortie requises.

Rédigez des instructions directes indiquant ce que l’agent doit faire. Par exemple, utilisez « Joignez EmployeeStatusFact à EmployeeDim sur EmployeeID » au lieu de « Évitez de joindre incorrectement les tables des employés ».

Restez concentré sur les instructions. Mettez des définitions spécifiques à chaque objet dans les descriptions d’objets du schéma au lieu d’utiliser un espace d’instructions limité comme glossaire pour chaque tableau et colonne.

Définir les termes métier et les valeurs attendues

Définissez une terminologie que les utilisateurs peuvent inclure dans leurs questions mais qui ne correspond pas directement au schéma. Parmi les exemples, on trouve des acronymes tels que « MAU », des significations spécifiques à l’organisation de « client actif » et des distinctions telles que exercice fiscal et année civile.

Documentez également les valeurs dont l’agent a besoin pour construire correctement les filtres :

• Qu’une colonne d’état utilise "CA" ou "California".
• Qu’une valeur booléenne soit stockée sous la forme de 1 et 0, de Y et N, ou sous forme de texte.
• Que les valeurs monétaires soient stockées en dollars ou en centimes.
• Quelles valeurs de statut représentent des enregistrements complétés, annulés ou actifs.
• Que null, zéro ou une date sentinelle ait une signification particulière.

Placez une définition dans la description de l’objet schéma lorsqu’elle s’applique à un objet. Placez-le dans les instructions de la source de données lorsqu’il s’applique à la source de données ou affecte la logique de requête multi-objet.

Expliquez les relations et le grain de table

Les jointures précises dépendent de plus que de simples noms de colonnes correspondants. Identifiez le grain des tables importantes, des chemins de relations valides et des clés qui ne sont pas évidents à partir des métadonnées.

Par exemple, expliquez si un tableau de vente contient une ligne par commande, ligne de commande ou produit total quotidien. Si la fusion de deux tables de faits duplique des lignes, demandez à l’agent d’agréger chaque table avant de la joindre ou d’utiliser la table de dimension appropriée.

Incluez des conseils relationnels tels que :

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

Utilisez des requêtes d’exemple pour la logique complexe

Utilisez des requêtes d’exemple pour montrer que la requête est plus claire que la logique en prose. Un bon exemple associe une question représentative en langage naturel à une requête valide qui démontre le schéma attendu.

Priorisez des exemples qui démontrent :

• Jointures multi-tables ou préagrégation obligatoire.
• Calculs spécifiques à l’entreprise.
• Dates relatives, périodes fiscales ou logique d’instantané.
• Des filtres qui associent la terminologie utilisateur aux valeurs stockées.
• Classement, fonctions fenêtres ou autres schémas de requête complexes.

Gardez chaque exemple concentré sur un motif réutilisable. Évitez les exemples qui se chevauchent ou sont contradictoires, et vérifiez que chaque exemple correspond toujours au schéma actuel.

Tester et affiner le contexte

Testez des questions représentatives, inspectez la requête générée et identifiez quel contexte manquait ou a été mal interprété. Mettez à jour la configuration la plus proche du problème :

• Supprimez des objets non pertinents ou ajoutez des objets manquants dans la sélection du schéma.
• Clarifiez la signification ou les valeurs attendues d’un objet dans la description de son schéma.
• Ajouter une logique de gestion ou de jointure entre objets aux instructions de la source de données.
• Ajoutez un exemple de requête lorsque l’agent doit apprendre un schéma de requête spécifique.

Répétez ce processus au fur et à mesure que le schéma et les questions des utilisateurs évoluent. Pour un flux de travail de tests structuré, voir Développer un agent de données en utilisant un processus itératif.

Étapes suivantes

• Configurations de l’agent de données
• Ajouter des descriptions d’objets de schéma à un agent de données
• Environnement d’exécution de l’agent de données Fabric
• Exemples de requêtes
• Ajouter et configurer les sources de données