Directives pour la préparation des données et le réglage fin – Utilisateurs auteurs

Pour optimiser l'efficacité de vos interactions avec l'assistant IA d'Oracle Analytics, suivez ces directives.

1. Limitez le nombre de colonnes dans un domaine local. Incluez uniquement les colonnes utilisées ou nécessaires pour le contexte fonctionnel du ou des classeurs dans le domaine local. Même si elle n'est pas explicitement utilisée dans le classeur, une colonne de données proche du contexte du classeur peut être candidate pour le domaine local, si les conditions suivantes sont remplies :
   1. On s'attend à ce que les utilisateurs consommateurs posent potentiellement une question ou une invite les concernant.
   2. L'ajout au domaine local n'introduira pas d'ambiguïté potentielle avec d'autres colonnes existantes déjà dans le domaine local.
2. Evitez les colonnes de cardinalité élevée dans un domaine local. N'apportez pas Order_id ou le nom du client, qui peut contenir plus de 1000 membres distincts. Les colonnes de cardinalité élevée augmentent généralement le temps d'indexation et peuvent éventuellement ne pas être d'un besoin critique de répondre à la plupart des invites utilisateur de consommateur de haut niveau.
3. Evitez les dates fonctionnelles multiples dans un seul domaine local.
   1. Si possible, n'incluez qu'une seule date fonctionnelle (hiérarchie de jeux de dates) dans le domaine local, par opposition à plusieurs hiérarchies de dates fonctionnelles. Par exemple, la date de commande, la date d'expédition et la date de facturation sont toutes des hiérarchies de dates distinctes faisant partie d'un domaine relatif aux ventes. Idéalement, n'incluez qu'une seule de ces hiérarchies dans votre domaine local. Le fait d'avoir plusieurs hiérarchies de dates peut entraîner une ambiguïté avec les réponses d'Oracle Analytics AI Assistant.
   2. Si vous devez autoriser l'utilisateur consommateur à accéder à plusieurs dates dans un même domaine local, vous devez toujours spécifier le type de date fonctionnelle auquel il se réfère lorsqu'il pose des questions liées au temps. Sinon, cela peut ne pas toujours être intuitif pour les utilisateurs, par exemple, lorsque les objets date de commande et date d'expédition sont tous deux inclus dans le domaine local.
4. Définissez correctement les règles d'agrégation des mesures. Les colonnes de type de mesure sont définies par défaut avec une règle d'agrégation Sum. Si une métrique n'est pas additive, telle que Age, remplacez manuellement la règle d'agrégation qui prend par défaut la valeur Moyenne dans le domaine local. A un niveau général, les objets typiques nécessitant un remplacement des règles d'agrégation sont le nombre, le nombre distinct et les moyennes. Vous devez remplacer les métriques qui sont des calculs de ratio par un numérateur et un dénominateur par une règle d'agrégation Moyenne dans le domaine local.
5. Gardez à l'esprit les noms et descriptions des colonnes. Si nécessaire, remplacez les noms de colonne par des valeurs plus significatives. De meilleurs noms de colonne sont plus efficaces que l'ajout de synonymes. Bien que l'ajout de synonymes aide, les noms de colonne corrects ont un impact plus important sur la résolution du LLM.
6. Définir les domaines locaux en mode d'accès aux données en direct. Cela permet aux critères de sécurité des données utilisateur de passer à la requête.
7. Evitez les colonnes de domaine avec des règles d'agrégation complexes dans vos domaines locaux. Dans la mesure du possible, essayez d'utiliser des métriques additives simples dans vos domaines locaux.