The dataset of the intelligent agent serves as the data source for data queries performed by the Intelligent Analysis Agent. The data quality and related configuration of the dataset directly affect the data query results of the intelligent agent. Once you have ensured the data quality of the intelligent agent's dataset through data cleansing and other operations, optimizing the dataset configuration becomes crucial for influencing the data query results. This article introduces recommended approaches for data configuration and practical scenarios.

• When optimizing the configuration of a dataset, you need to consider the application scenarios of the intelligent agent. It is important to have a certain understanding of typical issues and frequently asked business metrics, and to configure the dataset based on these application scenarios.
• The data quality of the dataset itself has the greatest impact on the effectiveness of the intelligent agent's application. Therefore, when the query results do not meet expectations, you can first check whether the data quality of the dataset itself can be optimized, and whether it is necessary to process the dataset using ETL methods first. For example, frequently asked or easily misunderstood business metrics can be handled in advance through ETL. For related practical references, see Best Practices: Data ELT Processing Guidelines.

General configuration approach #

It is recommended to first clarify the current status of the datasets required by the intelligent agent and the fields within each dataset, including synonyms that may be involved in business query scenarios for each field. Then, configure based on the results of this clarification. The semantic model configuration of the agent consists of two main parts: the semantic configuration for the entire dataset and the semantic configuration for each field within the dataset.

• Semantic configuration for the entire dataset: An agent typically contains multiple datasets. When the agent selects a dataset, it prioritizes matching the semantic model results of the dataset (name, description, features). It is recommended to carefully review the user's question set to identify features that can significantly distinguish datasets, so that, for most user questions, datasets can be distinguished based on their features.
• Semantic configuration for each field within the dataset:
  • It is recommended to enable only the necessary fields. If there are multiple date fields with identical values, only one needs to be enabled, preferably enable partition fields.
  • For [field name synonyms], if a field name has multiple expressions in the user's question set, add these expressions here.
    Caution: When adding, strictly follow the expressions in the question set. More is not always better. As long as the question set is satisfied, fewer is better.

Planning & configuration examples #

General configuration approach #

• The knowledge base name must be precise: Currently, the knowledge base uses a name/description key-value (KV) structure. The system recalls knowledge based on the similarity between the user's question and the knowledge name. Therefore, the definition of the knowledge name must be precise and should match the question as accurately as possible, avoiding broad names.
• Knowledge definition requires caution: If a question can be resolved by defining expressions in the dataset definition or by defining synonyms in the semantic model, there is no need to use the knowledge base.
• Pay attention to generalization: If defining knowledge solves the current issue, it is strongly recommended to conduct regression testing to check whether this knowledge definition causes performance degradation for other issues.

Principle 1: Use custom rules for recall whenever possible #

• It is recommended to use "custom rules" as much as possible when configuring the knowledge base. The recall rules for the vast majority of knowledge can be achieved by carefully configuring rules.
• "Providing content to the large model for reference every time" is not the optimal configuration method; unless there are special circumstances, frequent use is not recommended. It is advised not to use the default recall for convenience, as this may unexpectedly degrade the quality of answers to certain questions.

Principle 2: When a piece of knowledge applies to multiple scenarios, multiple pieces of knowledge with precise rules should be added, rather than a single piece of knowledge with vague rules. #

For example: Suppose a user asks a question related to "Doubao large model"—this knowledge applies; similarly, if the user asks a question related to "Doubao small model," this knowledge also applies. It is advised not to use the default recall method for convenience, but to configure two pieces of knowledge: one for "Doubao large model" using rule recall, and another for "Doubao small model" using rule recall.
When using rule recall, business terms are not critical; simply write the beginning of the sentence to which you want to add knowledge. In addition, pay special attention to the "Preview" section, which is the content ultimately transmitted to the large model; ensure its accuracy. In rule recall mode, business terms, conjunctions, and explanations can be arranged as needed—the key is to ensure the accuracy of the preview content.
Based on all question formulations in the question set and the fields in the dataset, determine the most precise rule so that the rule applies only to questions requiring the added knowledge, while avoiding impact on other questions that do not require this knowledge.
Caution: If a piece of knowledge is added solely for calculation using certain fields, it is recommended to add a calculation expression field in the dataset to achieve this, rather than directly adding the knowledge; otherwise, the effectiveness may unexpectedly worsen.

Planning and configuration examples #

Usually, you can configure the internal terminology, jargon, and metric calculation logic related to the current dataset's business scenario in the knowledge base for this dataset. It is recommended to first organize each field of the current dataset individually. The following is an example.

• Internal terminology and jargon

  Dataset name	Business term	Synonym	Explanation (term definition)	Related dataset fields
  Contract detail execution summary_CK	How are sales performing	Sales volume	How are sales performing refers to [purchase quantity] and the corresponding [purchase amount]	Order quantity, order amount, outbound quantity
  	Technical type	Technical route	Technical type indicates the product's technical type, including PERC, TOPCon, HJT, and other types
  xxx shopping omnichannel analysis	Live and recorded broadcast	Program playback type	Playback type; of these, Live broadcast: playback type is not replay; Recorded broadcast: playback type is replay;

• Metric calculation logic

  Dataset name	Business term	Explanation (term definition)
  xxx shopping omnichannel analysis	Cancellation rate	Cancellation amount / purchase amount
  	Outbound rate	Outbound amount / purchase amount
  	Delivery completion rate	Delivery completion amount / outbound amount
  	Return rate	Return amount / outbound amount
  	Conversion rate (quantity)	Sales quantity / purchase quantity
  	Conversion rate (amount)	Sales amount / purchase amount
  	Gross profit margin	Sales profit / sales revenue
  	Live broadcast conversion rate	Number of buyers during live broadcast / number of live broadcast viewers
  	Fan retention	Net followers / total followers
  	Average transaction value - video channel	Transaction amount / number of buyers
  	Average unit price	Purchase amount / purchase quantity
  	Number of playbacks	During a period, count the number of times this item appears in each playback time slot; count time slots
  	Live sales quantity / amount / profit (average)	Total profit or amount divided by number of playbacks