Knowledge Generation and Similarity Check Logic

With you select the Generate Knowledge button, the following Aisera Gen AI platform processes take place:

1. Generate knowledge for the ticket cluster representatives

2. Verify the similarity of the representatives compared with the committed knowledge (in other words, comparing knowledge repositories that are available for downstream consumption). Downstream consumption is exporting to the original external 3rd party data store, such as ServiceNow or Salesforce.

Knowledge Generation Data Processing

The Knowledge Generation Processing includes the following steps.

Step 1: Ticket Selection

Tickets are selected from the Data Source when you choose the Action → Configuration command in the Generated Knowledge page.

Step 2: Preprocessing

The following checks are performed during preprocessing:

Title Validation: The ticket title must not be null or an empty string.

Content Check: Either the comment or resolution notes must contain text and must not be null or empty.

Timestamp Validation: Comments without timestamps are eliminated.

Filtering: Tickets marked as "Good" or "Very Good" from previous clustering runs are filtered out.

Check if any of the prompt and model has been changed, if yes, then all bad quality tickets though it is not updated will be reconsidered. If no, then only the bad quality tickets that are updated will be considered.

Step 3: Resolution Classification

This step extracts key attributes:

Ticket Quality Classification:

Very Good: The ticket contains a solution and receives user feedback or instructions.

Good Quality: The Ticket contains solutions but not having users feedback.

Bad: The ticket lacks a solution or contains irrelevant information.

Unclassified: This is a case where GPT was unable to process the ticket due to model capacity limitations, excessive ticket size, or failure to generate a response in the correct format, among other internal GPT issues.

Resolution Category: Identifies the category under which the ticket's resolution falls. The fixed categories include:

Cannot Be Self-Resolved – Internal Fix Needed: Issues arising from internal company systems that require specific personnel intervention like Developer.

No Resolution Found / Agent Support Required to Resolve: Issues that the user can partially resolve but necessitate assistance from an agent for certain steps, such as granting permissions etc also this category will have the tickets that has no resolution steps.

◦ Issue Reviewed in Other Channels & No Resolution Captured: Cases where the issue is discussed offline via teams, slack etc and no solution has been captured.

◦ Resolution Without Feedback: Situations where a solution is provided, but has not confirmation that the issue is resolved.

◦ Resolution with Feedback: A situation where a solution is provided, and has confirmation that the issue is resolved.

Quality Classification Reason:

Provides the rationale for assigning a particular quality category to the ticket. example say for 'Resolution with Feedback" - The agent provided a resolution action which the user followed and confirmed that it resolved the issue.

Resolution Identification: Identifies specific comments containing resolution steps (such as, comment 5, or 9).

Issue Summarization: Extracts the intent of the issue by summarizing the ticket title and description.

Resolution Summarization: Extracts the intent of the resolution from the resolution steps.

Step 4: Ticket Clustering

This step organizes tickets into meaningful clusters:

Master Cluster Formation: Groups tickets based on the summarized issue.

Sub-cluster Formation: Further refined clusters based on resolution summarization. (Summarization of issue + Resolution)

Step 5: Representative Extraction

The Aisera Gen AI platform determines the representative ticket among the sub-cluster by considering the below points:

• Medoid Selection (a representative object in a cluster)

• Good/Very Good

• Resolution Verbosity

Step 6: Cluster Evaluation

The purpose of this step is to reevaluate the cluster representative to ensure it closely represents the entire cluster.

Step 7: Document Generation

The final step generates a structured knowledge document based on the clustered and summarized information.

Step 8: Inlyer Analyzer

To improve the coverage and quality of resolution steps, we have introduced Multi-Resolution Extraction. This enhancement involves analyzing multiple representative tickets within a cluster to generate a richer and more comprehensive knowledge document. This step further refines each cluster by analyzing summarized issues and resolutions, splitting them into smaller, tightly aligned further groups, and selecting multiple representatives to generate more accurate and targeted knowledge documents.

How Does It Help?

• Enables visibility of multiple resolutions related to the same issue/topic.

• Consolidates various resolution approaches into a single document, helping reviewers view different resolution steps at once.

• Allows reviewers to edit, select, and retain only the most accurate steps.

Note: Achieving 100% tight clusters is challenging due to variations in ticket content.

To improve clustering:

• Master and Sub-clustering allow you to tighten the groupings

• With the goal of incorporating more representative tickets, it's essential that these representatives address similar issues. Hence, sub-clusters are further grouped to select more accurate representatives for document generation.

• Each granular group requires a minimum of 2 tickets to ensure meaningful document creation. If any group contains only 1 ticket, those will be merged into a single group.

• Among the resulting smaller groups, the dominant group will be selected and displayed in the UI.

• Maximum number of representatives that will be picked in each group is 4.

Tickets Considered for Subsequent Runs

The following types of tickets are considered for future Knowledge Generation runs:

• Bad-quality tickets that have been updated after the most recent KB Generation run

• Good-quality tickets classified as outliers (not part of any valid cluster)

• Newly ingested tickets

• Tickets are released when an AI-generated document is deleted

Similarity Check Logic

The logic analyzes all the cluster representative documents and compares them against the committed knowledge repository available in the knowledge module.

If no duplicates are found, they will be automatically approved and committed, and will be directly accessible under the knowledge module for Fulfillments.

However, if any documents are identified as duplicates, they will not be automatically committed or approved.

You can view the duplicate documents and decide whether to commit or delete the generated document.