Data Preparation and Fine-Tuning Guidelines – Author Users

To maximize the effectiveness of your interactions with the Oracle Analytics AI Assistant, follow these guidelines.

1. Limit the number of columns in a local subject area. Only include columns used or needed for the functional context of the workbook(s) in the local subject area. Even if it isn't explicitly used in the workbook, a data column close to the context of the workbook can be a candidate for the local subject area, if the following conditions are met:
   1. Consumer users are expected to potentially ask a question or prompt involving these.
   2. Adding it to the local subject area won't introduce potential ambiguity with other existing columns already in the local subject area.
2. Avoid high-cardinality columns in a local subject area. Don't bring Order_id, or Customer name, which potentially carry more than 1000 distinct members. High cardinality columns typically increase the indexing time and may eventually not be of a critical need in answering many of the "high-level" consumer user prompts.
3. Avoid multiple functional dates in a single local subject area.
   1. When possible, only include one functional date (set of date hierarchy) in the local subject area, as opposed to multiple functional date hierarchies. For example, order-date, shipped-date, and billed-date are all distinct date hierarchies part of a subject area about sales. Ideally, only include one of these hierarchies in your local subject area. Having multiple date hierarchies could result in ambiguity with Oracle Analytics AI Assistant responses.
   2. If you must give consumer user access to multiple dates in a single local subject area, require they always specify which functional date type they refer to when they ask time-related questions. Otherwise, this may not always be intuitive for consumer users, for example, when order date and ship date objects are both included in local subject area.
4. Properly set metrics aggregation rules. Metric type columns default with a Sum aggregation rule. If a metric isn't additive, such as Age, manually override the aggregation rule that defaults in the local subject area to Avg. At a high level, typical objects that need aggregation-rules override are Count, Count Distinct, and Averages. You need to override metrics that are ratio calculations with a numerator and a denominator with an Average aggregation rule in the local subject area.
5. Be aware of column names and descriptions. If necessary, change column names to more meaningful values. Better column names are more effective than adding synonyms. While adding synonyms helps, good column names have a higher impact on the LLM resolution.
6. Set local subject areas to live data access mode. That allows user data security criteria to pass into the query.
7. Avoid subject area columns with complex aggregation rules in your local subject areas. As much as possible, try to use simple additive metrics in your local subject areas.