Improving Natural Language Queries with Tag configuration

AI instructions add more business context to natural language queries. They guide users and promote responses that more closely align with their needs and expectations.

AI instructions

AI instructions help clarify how the knowledge graph interprets user queries and accesses data. When a user submits a query, relevant instructions at all applicable levels like node, property, and edge are considered.

Referencing data within tables directly in instructions is not a general guideline. Instead, instructions should be generalized and context-driven.

You can add instructions at three levels:

• Node (entity/table)
• Property (column/attribute)
• Edge (relationship) level

The Always Include flag

The option to set an Always include flag enables users to indicate that a particular instruction should be considered unconditionally. This is useful for enforcing critical business filters, such as always excluding certain asset statuses unless requested otherwise.

Instructions:

• Use Always include for business-critical filters that must apply regardless of user query phrasing.
• Omit Always include for context-sensitive instructions that should only apply when relevant.
• Verify that flagged instructions do not conflict with each other or produce duplicate results.

Examples of Good AI Instructions:

Effective AI instructions are clear, precise, and contextually aware. The following examples illustrate the recommended approach:

• "Always add WHERE alm_asset.install_status <> 7 to filter out retired assets by default." This instruction respects business context automatically. Retired assets are excluded unless the user explicitly requests them.
• "When generating a query involving sc_cat_item, don't include state='published' unless explicitly mentioned." This avoids unintended filtering caused by ambiguous instructions.
• "For life-cycle-related queries, use sam_sw_product_lifecycle_report as the primary/default table."- This aligns query logic with performance and business requirements.

Table 1. Identifying good vs. bad instructions

Good Instruction	Bad Instruction
Consider normalized_company only when user asks for normalised manufacturer.	Check company (no indication of which property or relationship to use).
Always add WHERE alm_asset.install_status <> 7 to filter out retired assets by default.	Filter by manufacturer (no column or condition specified).

Poor instructions may result in hallucinations. The AI generates incorrect data or misinterprets the query intent. This can occur due to:

• Missing context or incomplete references.
• Ambiguous column or table names.
• Contradictory guidelines across instruction levels.

AI instructions must adhere to the same basic guidelines as user queries. Reference structured elements, avoid unsupported query types, and follow prescribed business logic. What applies to good queries also applies to effective AI instructions.

Support for Synonyms and Data Filters

Content for this section needs to be added.

The following table shows common scenarios where AI instructions improve query accuracy and provide better business context.

Table 2. Examples of how to use AI instructions effectively

No.	Instruction Pattern	Example Query	Behavior without AI instruction	Sample AI instructions	Behavior with AI instruction
1	Preventing incorrect traversal paths	Which companies are located in New York?	When no instructions are added, the query goes from core_company to cmn_location table and filters on city field by default. But if your use case requires to query location from city field of core_company table, you need to write an AI instruction to guide the system on the traversal path.	Table Instruction on core_company table: For company-city queries, always use core_company.city directly. Do NOT traverse through cmn_location. This instruction avoids the system from using cmn_location path for city-based company queries.	When instruction is added, the query matches with city field in core_company table and then filters city=New York and returns all matching companies.
2	Providing column specific context	Who hosted BBS0000013 brown bag session?	When there is no AI instruction, the system will return sys_id without traversing to host_s. You need to add an instruction on host_s column to provide business context to use this column when query is about host.	Column Instruction on host_s of x_snc_brown_bags_sessions table: Use s.host_s or :host_s relationship for the host of a brown bag session, NOT s.sys_created_by	When instructions are added, the query correctly returns the name from host_s column.
3	Providing column specific context	What is Kelsey Rodriguez's tenure in current role (months)?	When there is no AI instruction, the system may not give accurate result as it may provide incorrect information for tenure column. You need to add an instruction to guide the system to refer right column for such queries.	Column instruction on time_in_current_role column: Prioritize this column when query contains 'tenure in current role'	When instructions are added, the query correctly returns the time from time_in_current_role column.
4	Providing context on what to prioritize in case of similar tables	Give me name of Allison Hill's reports having goals pastdue >0?	When there is no AI instruction, LLM will directly refer to “sys_user” table to fetch user details instead of traversing to WDF table where this information is stored. We need to add an instruction to guide LLM to refer right table when there are similar tables.	Table instruction on WDF table – “x_snc_wdf_user” “Always give more priority to " x_snc_wdf_user”over sys_user and other glide tables”	When instructions are added, the query correctly refers to WDF table and return results.
5	Providing context on what to prioritize in case of similar tables	What is your job title?	When there is no AI instruction, LLM will directly refer to “sn_hr_core_job” table to fetch job details instead of traversing tosn_hr_core_profile" table where this information is stored. We need to add an instruction to guide LLM to refer right table when there are similar tables.	Table instruction on table – “sn_hr_core_profile” “Always give more priority to "sn_hr_core_profile" over “sn_hr_core_job” when user specifically asks about job titles.	When instructions are added, the query correctly refers to “sn_hr_core_profile” table and return results.
6	Disambiguate among multiple similar and confusing choice values	What are the hardware models that are in normalized state?	When there is no AI instruction, LLM will refer to “normalized” choice value of “normalization status” column which could confuse LLM whether to use other choice values or not as “normalization status” field has 5 choice values (normalized, manufacturer normalized, manually normalized, partially normalized, match not found). We need to add instruction to guide LLM on which all choices to include in normalization status.	Column instruction on “Column- normalization status”: “Always consider normalization status as normalized when choice values is any of the following choices: “normalized, manufacturer normalized, manually normalized”	When instructions are added, the query correctly considers all 3 choices “normalized, manufacturer normalized, manually normalized” as normalized state and return results.

Best practices for AI instructions

Follow these guidelines when creating AI instructions to verify optimal performance and accuracy:

• Write clear, unambiguous, and actionable instructions tied to business logic. Always reference the correct tables (nodes), columns (properties), and relationships (edges). Use flags like Always include only when enforcing true default business behavior.
• Avoid vague or contradictory instructions. Instructions that do not align with the underlying data model can confuse the system and lead to incorrect results. For example, an instruction like "Filter by manufacturer" without specifying the column or condition is ambiguous.
• Use conditions to control when logic applies. Clearly state when an instruction should be applied (for example, only when the user asks for host information), rather than applying logic universally.
• Keep instructions focused and generalized. Instructions should guide intent interpretation across similar queries, not solve a single one-off case.
• Do not duplicate logic already handled elsewhere. Avoid restating filters or constraints that are already enforced through data filters to avoid conflict.

Support for Synonyms, Data Filters and hidden columns

Synonyms:

Knowledge Graph supports configuring synonyms for tables, columns, edges, and reverse edges to enhance flexibility and user-friendliness. Synonyms enable users to define alternate names for these entities, accommodating different terminologies.

• Each entity can have up to five synonyms.
• Synonyms promote broad coverage for commonly used alternate terms.
• Maintaining a manageable synonym set reduces ambiguity in query resolution.

Data Filters:

Data filters are applied deterministically as post-processing rules to refine query results. After initial Cypher generation, filters are systematically applied to promote consistency and reliability of outcomes.

• Filters are applied after Cypher generation, not during.
• Dynamic filters enable real-time adaptation based on user context.
• Improves precision and relevance of returned data. Does not modify the core graph query.

Hidden columns:

Hidden columns cannot be queried and do not appear in the result.

For example: add Employee number as hidden columns for sys_user table to hide the employee number from query results.