Improving Natural Language Queries with Tag configuration
Summarize
Summary of Improving Natural Language Queries with Tag configuration
This feature enhances the accuracy and relevance of natural language queries in ServiceNow by using AI instructions to add business context. AI instructions guide how the knowledge graph interprets queries and accesses data across entity (node), attribute (property), and relationship (edge) levels. This helps generate responses that better align with user intent and organizational requirements.
Show less
Key Features
- AI Instructions: Declarative rules applied at node, property, and edge levels to clarify query traversal and data selection logic.
- Always Include Flag: Ensures certain critical instructions—such as mandatory business filters—are always applied regardless of query phrasing.
- Synonyms Support: Allows defining alternate names for tables, columns, and relationships to accommodate various terminologies, improving usability.
- Data Filters: Applied after query generation as deterministic, real-time post-processing rules to refine results without altering the core query.
- Hidden Columns: Columns can be hidden to exclude sensitive or irrelevant data from query results (e.g., hiding employee numbers in user records).
Practical Use Cases and Examples
- Controlling Query Paths: Prevent incorrect table traversal by specifying exact fields to use, ensuring queries return accurate data (e.g., use company city field directly rather than location table).
- Column-Specific Context: Prioritize correct columns for certain queries, such as using a specific host field instead of system-generated identifiers.
- Prioritizing Similar Tables: Guide the system to prefer the correct table when multiple tables contain similar data, improving precision (e.g., selecting job profiles over generic job tables).
- Disambiguating Choice Values: Clarify which choice values to consider in queries with multiple similar options, avoiding confusion and enhancing accuracy.
Best Practices for ServiceNow Customers
- Write clear, unambiguous AI instructions tightly aligned with your business logic and data model.
- Use the Always Include flag only for essential default business rules to avoid conflicting or duplicate filters.
- Apply conditions to specify when instructions should trigger, preventing overly broad or irrelevant guidance.
- Maintain focused instructions that generalize well across similar queries rather than addressing isolated cases.
- Leverage synonyms to accommodate different user terminologies while keeping the set manageable for clarity.
- Utilize data filters for consistent post-query refinement without impacting the core graph query.
- Use hidden columns to protect sensitive data from appearing in query results.
Expected Outcomes
By implementing AI instructions and tag configurations effectively, ServiceNow customers can expect more precise, context-aware natural language query results. Queries will better reflect business priorities and data structures, minimize incorrect data access paths, and improve user satisfaction through relevant and accurate information retrieval.
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.
- Node (entity/table) level
- Property (column/attribute) level
- 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.
- 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.
The following table shows common scenarios where AI instructions improve query accuracy and provide better business context.
| 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:
- 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:
- 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.