> For the complete documentation index, see [llms.txt](https://docs.aisera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aisera.com/aisera-platform/content-generation-from-tickets/analyze-kb-article-generation-results/ai-generated-documents-from-bulk-tickets.md). # AI Generated Documents from Bulk Tickets The **Bulk Tickets** tab of the **AI Generated Documents** window allows you to see and choose tickets that were clustered together during the **Knowledge Generation** job.
The **Bulk** tab includes the following **Filter Options:** **Search:** The system will allow users to search for 'Knowledge Clusters' or 'Knowledge Documents' (both have the similar names). You can input the desired knowledge cluster or document name to retrieve relevant results. If no search result found, the application displays the message, No results found under the Knowledge Document section. **Job Run Drop down Filter option:**  This option should be enabled by default with the latest job run. It has the list of last job runs that are executed. Users will have an option to choose the job run and the corresponding clusters should get displayed in the ‘Knowledge Generation’ tab. Format should be in Date followed with time.  By default, this option is selected with the latest run date/time details. **Filter options:** Users can click on the "+" icon and add the following fields. **Similar Documents:** This is a drop-down menu displaying options for Yes and No: Yes filters the documents in the return list by similarity. **No** filters the documents in the return by dissimilarity. ### Similar Documents Count Similar Documents = Yes (integer) The count represents the number of original (data source) documents (Tickets) that this AI-generated document matches with. **Example:** Assume you have 3 generated documents: Data Source Ticket 1 → AI-generated docs matched: (1, 2) Data Source Ticket 2 → AI-generated docs matched: (2, 3) Data Source Ticket 3 → AI-generated docs matched: (1, 3) #### For AI-generated Document 1: The generated document matches with the original Data Source Ticket 1 and Data Source Ticket 3. So, **Similar Documents** = **Yes (2)** ### Count Selection When you select **Yes (2)**, the Similar Documents window opens. This page displays the crawled documents that match this AI-generated document in this example: * Ticket 1 * Ticket 3 The **Similar Documents** count is also a link in the **side panel** of the **AI-Generated Document Details** page.
**KB Accuracy Feedback:** allows you to filter and view generated documents based on the feedback application/bot users have provided. KB Accuracy Feedback values include:  * ALL * Highly Accurate  * Moderately Accurate * Inaccurate * None **Published to Repository:** displays the list of documents in the External data source knowledge repository where the AI generated documents have been uploaded (when the **Publish to SOR** toggle is selected in the application/bot **Details** window.). The data store type is also displayed, such as ‘**ServieNow**’, ‘**Salesforce**’ or the ‘**Aisera**’ option that uploads documents to the internal tenant data store. **Status:** filters documents to track their publishing progress to  the source system. * **In progress** – Document publishing is in progress. * **Published** – Document has been successfully published. * **Failed** – Publishing was unsuccessful due to an issue. (see section above: Failure messages when any of the configurations are missing **Generated By:** displays the name of the user who triggered the **Knowledge Generation** job for that application/bot. **Template:** a drop down menu with the following options: * **Default** * **KCS** * **Master Default** * **Master KCS** **Default:** This template is simple and includes the **Title**, **Description**, and **Solution** fields. It is extracted by one representative ticket in the cluster. **KCS** is an industry standard template using the **Knowledge-Centered Service** methodology, which is a process that involves collecting, structuring, reusing, and improving knowledge content to enhance the customer experience.  It has **Title**, **Issue**, **Cause**, **Environment**, and **Solution**. Extracted with one Representative ticket in the cluster. **Master KCS (sample):** **Multiple Resolution**, **Environment**, and other sections are displayed, each containing multiple representative tickets within the cluster instead of just one. The same behavior applies to the **Master Default** view. **Tags:** displays the list of tags associated with the document. Tags are shared across Aisera modules, meaning that metadata tags created in **Tickets**, **Requests**, or **Knowledge** in the original source systems will be available and visible in this list. You can add tags to the **AI-generated knowledge articles** to help organize and filter documents more effectively. For example, if the article relates to VPN issues and John is the SME responsible for review, you can add tags such as **`VPN Issues`** or **`John`**. These tags can then be used as filters to quickly retrieve relevant documents for further review. ### Knowledge Clusters The bar graph displays the clusters in descending order. Each cluster represents a distinct set of similar Ticket pools.
When you click on a cluster, the **Recommended Knowledge Document** associated with that cluster is filtered in the table column, to keep it consistent with other pages. You have the ability to choose from the data visualization options listed below. There is also a **Download** option. ### Fields in Tabular Section **Knowledge Cluster:** displays the knowledge cluster name **Knowledge Cluster Representatives:** displays the recommended knowledge document that is generated for the specific cluster. You can click on the **Knowledge Document**, which will route you to the corresponding **Knowledge Document Details** page, where you can view the generated document. **Tickets:** displays the count of tickets per cluster, representing groups of tickets related to similar issues. **Similar Documents:** contains the similar documents found for the specific cluster representatives. * **Yes:** Indicates that the cluster representative has similar documents among the committed (alias live) documents available for downstream consumption. These documents will be auto-approved and auto-committed automatically when no duplicates are found. * **No:** Indicates that the cluster representative has no similar documents. These documents will also be auto-approved and auto-committed automatically when no duplicates are found. They will be available for downstream consumption. For documents with duplicates, you need to review them and then either **Publish to SOR, Publish to Aisera,** or **delete** the duplicate document, as shown in the **Actions** section below. **Template:** displays the Template for the document. **Published to Repository:** displays the data store where the document has been uploaded, for example, **ServiceNow**, or **Aisera**. **Status:** tracks document publishing progress to the source system. **KB Gen Accuracy Feedback:** holds the feedback provided by the application/bot users and displays the corresponding feedback for each document. This field is not displayed by default, so to view this field, locate the **Add/Remove Columns** command, represented by **three dots**, and add the field to your display. Application/bot users have the option to edit and resubmit their feedback. They can also delete the feedback, which will reset the section, making it appear new with all radio options unselected. The application/bot user can then choose to add new feedback or ignore it.   **Date:** holds the **Date & Time** of the cluster when it has been extracted. **Generated By:** This will show the user id who triggered the job. **Tags:** This will show the assigned tags to the specific document. **Job Run On:** displays the job name provided by the person who ran the **Knowledge Generation** job along with the date and time when the document was generated. ### Action Button In the **Actions** dropdown, along with **Job Configuration**, the following options are available: * **Set Recurring Schedule** * **Publish to Aisera** * **Publish to SOR** * **Delete Document**
#### Publishing AI-Generated Documents You can publish AI-generated documents either to Aisera or to their external System of Record (SOR) by selecting single or multiple documents from the AI Generated Documents page. **Publish to Aisera:** \ \ When a document is published to Aisera, the document is stored under **SOR → Knowledge** within your Aisera tenant module. This makes the document available for indexing. It can be consumed by downstream systems, such as application/bots that use the same tenant endpoint.. This option is particularly useful for customers with a limited external data source knowledge base (such as people who have Tickets in Zendesk, Salesforce, ServiceNow or other system but do not have a lot of Knowledge Articles within the Support Knowledge Base for that system) who want to quickly review and enable content within Aisera for bot consumption, helping reduce ticket inflow. **Publish to SOR:** Publishing to SOR is intended for customers who: * Have an established a review and approval process in their external knowledge management system. * Prefer to review and approve AI-generated documents externally before making them available. Once the document is approved and published in the external system, the Aisera Gen AI platform can ingest the content for bot consumption. #### Publishing AI Generated Documents To Publish AI Generated Documents: 1. Make sure the **Publish to SOR** toggle swith on your application/bot Details window has the correct data source set with **Publish to SOR** enabled, unless you just plan to **Publish to Aisera** (the internal data store for your Aisera tenant). 2. Select one or multiple documents on the **AI Generated Documents** page. 3. Choose **Actions → Publish to SOR** or **Actions → Publish to Aisera**. 4. Select one or multiple documents on the **AI Generated Documents** page. 5. Select **Actions → Publish to SOR** or **Actions → Publish to Aisera**. You can also publish directly from the **Document Details** page. **NOTE:** After a document has been published, it cannot be republished. #### Deleting AI-Generated Documents You can delete AI-generated documents by selecting single or multiple documents from the **AI Generated Documents** page. 1. Select one or more documents. 2. Navigate to **Actions → Delete**. When an AI-generated document is deleted: * The associated representative tickets are released. * These tickets become eligible for consideration in subsequent runs. * You can delete a document directly from the **Document Details** page by clicking the **Delete** icon. ### Automatic Knowledge Base Generation Trigger The Aisera Gen AI platform supports automated recurring Knowledge Base (KB) generation based on user-defined schedules and configurations. After the schedule is configured, this process runs automatically without manual intervention.
Once configured, this process runs automatically without manual intervention. Schedule Options are: * **Available Recurrence Options** * **Monthly** * **Bi-Monthly** * **Quarterly** #### Steps to Configure Recurring KB Generation 1. Navigate to **Content Generation → AI Generated Documents** in the Aisera Admin UI. 2. Select **Actions → Set Recurring Schedule** to open the recurring configuration window. 3. Navigate to **Content Generation → AI Generated Documents**. 4. Select **Actions → Set Recurring Schedule** to open the recurring configuration window. 5. Configure the following options as described below. #### Configuration Details **Frequency Selection:** You can select the recurrence frequency: Select the recurrence frequency: * Monthly * Bi-Monthly * Quarterly
**Start Date:** after selecting the frequency, you must specify a **Start Date**. The **Start Date** determines when the recurring **Knowledge Generation** job begins. **Ticket Threshold Setting:** To ensure high-quality clustering, a minimum of approximately 40,000 tickets is recommended. After selecting the frequency, specify a **Start Date**. The **Start Date** determines when the recurring Knowledge Generation job begins. Past dates are disabled. You can only select current or future dates. Lower ticket volumes may result in: * Looser clusters * Broader topics * Less meaningful document generation Since you may not have 40K tickets for a specific configuration, the system allows document generation with lower ticket volumes. You can disable the **Ticket Threshold** option to lower the ticket count. If the **Ticket Threshold** is **Enabled**: * The system checks the total ticket count on the scheduled job run date. * If the ticket count is below the threshold, the Knowledge Generation job will not run. * The skipped job will not appear as scheduled or canceled in the UI. If Ticket Threshold is **Disabled**: * The system ignores the ticket count threshold. * All available tickets will be processed when the job is triggered. **Additional Configurations:** * The system ignores the ticket count threshold. * All available tickets will be processed when the job is triggered. **Additional Configuration:** All other configurations remain the same as those available for a regular job run, including: * **Ticket Conditions** * **Knowledge Field Mapping** * **Pre-Generation Configuration** ### Troubleshooting a 0 Cluster Result There is a possibility that there will not be any similar tickets found, resulting in zero clusters. This situation is more likely to occur when a very small number of tickets are inserted as input, so no clusters can be formed. In such cases, even if **auto-publish** is **enabled**, no Knowledge Base articles will be automatically published. This is because the absence of clusters indicates a lack of similar tickets, making the generated documents less valuable for the customer, due to the infrequency of the tickets. As an example, consider a scenario where 1000 tickets are present, but no clusters are found. f auto-publish is enabled, the Aisera Gen AI platform will publish 1000 documents to the source system, leading to an influx of unwanted documents. To address this issue, you can implement the following solution: 1. Generate a cluster for each ticket, assuming that if no cluster is formed, each ticket is distinct and not similar to others. This allows the Aisera Gen AI platform to create multiple clusters, displaying ticket-specific documents under the **Recommended Knowledge Document** section. 2. Keep **Auto Publish** turned **OFF**, which means that even if the configuration states **YES,** the document will not be automatically published to the source system. For now, if you need the document to be published, please contact our Customer Success Team. We will help you publish the requested document. ### Data Processing & Ticket Quality Transparency The Knowledge Generation process offers limited visibility into ticket selection, making it difficult for an observer to understand why only certain tickets are used for Knowledge Base Article creation while others are not. This often leads to questions, especially when a large volume of tickets is ingested but only a subset is utilized. Additionally, Knowledge Article quality is directly impacted by Ticket quality, which can raise concerns about accuracy and completeness. Providing transparency into Ticket quality is essential for evaluating Knowledge Article quality effectively. It also enables you to identify poor-quality tickets, improve them, and then train your human agents to add better comments, or train your application/bot to skip poor quality tickets for improved knowledge generation. During testing and validation, you may need to perform detailed investigations to understand why specific tickets were selected, and manually review numerous ticket comments to trace solution sources and selection criteria. These efforts demand significant time from both technical teams analyzing system logs and support teams conducting manual reviews.
To address this, the Aisera Gen AI platform includes a **Data Processing Funnel** that provides visibility into each step of the **Knowledge Generation** job process. ### Breakdown of Data Processing Stages Before getting into the details, lets understand the limitations The **Data Processing Funnel** (shown in the section above) will not be available for past jobs that have already been executed. (The reason is that these are new calculations and newly added schemas, and the corresponding data will not be available for past runs executed before April 2025). There is no stored metadata that was extracted from the runs prior to April 2025. Therefore, you can't access quality data and a few other parameters for tickets from previous runs. Since there is no metadata for past runs, when you run a **Knowledge Generation** job, the platform analyzes all tickets, regardless of whether they were part of past runs. This is important because the **Data Funnel** needs metadata for all tickets. As the consideration of tickets for consecutive jobs increases, the platform gradually starts eliminating very good and good quality tickets that were part of past runs. Therefore, we recommend rerunning each **Knowledge Generation** for all tickets, even if they have already been processed. (Refer to the [ticket consideration](https://aisera.atlassian.net/wiki/spaces/PM1/pages/3420192806/Knowledge+Generation+Functional+Specification#Tickets-consideration-for-the-next-runs%3A) in consecutive runs for clarity). The following table describes each of the **Data Funnel** components. | **Data Processing Stages** | **Summary** | **Data Navigation** | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Total Tickets** | Represents the total number of tickets in the selected ticket data source/'s on the day of execution. |

Currently the Total Tickets command will be disabled and non-clickable.

However, when you click on Total Tickets the csv file is downloaded.

| |

Filtered & Processed
Ticket Set

|

This stage displays the list of tickets that remain after applying filters in Action → Configuration and removing those that do not meet preprocessing criteria.

Preprocessing Criteria:

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 prompts or models have been changed, if yes, then all bad quality tickets (even though it is not updated) will be reconsidered. If no, then only the bad quality tickets that are updated will be considered. 

|

Select Filtered & Processed Ticket Set to navigate to the pre processed Tickets page, to view the list of tickets.

The grey box beside this stage represents tickets that do not meet the filtering criteria. This section is non-clickable.

| | **Tickets with Resolution** |

Represents the subset of filtered tickets that contain a solution and are part of clusters (There are a few tickets that, despite being of good or very good quality, did not meet the minimum threshold criteria for clustering. As a result, they will be considered outliers and will not be included in any clusters.)

The grey box beside this stage represents filtered tickets that do not have a solution.

|

Click on Tickets with Resolution to navigate to the Ticket Details page, as shown in the screenshot.

Similarly by clicking on the Grey box (beside purple), it will navigate to a new Ticket Details page that shows all the bad quality tickets with all their associated meta data.

| | **Total Clusters** | Displays the number of ticket clusters formed, which are visible on the **Knowledge Generation** window. | After you select the Total Clusters box, you can see the total clusters formed in the **Knowledge Generation** window.  | ### Ticket Quality Transparency This feature enhances transparency in the **Knowledge Base Article Generation** process by allowing you to assess the quality of processed tickets. Recognizing that knowledge article quality is directly proportional to ticket quality, this feature classifies tickets into three categories: * **Very Good** – A ticket that has a resolution and also has acknowledgment from the end user. * **Good** – A ticket that has a resolution but no acknowledgment from the end user. * **Poor** – A ticket that has no resolution. During **Knowledge Generation**, only tickets rated as **Very Good** and **Good** are considered for inclusion into the generated knowledge article, while **Poor quality** tickets are excluded. This classification enables you to evaluate your ticket quality and, consequently, the resulting knowledge article quality. ### Access Ticket Quality Details **To access the Quality information for a ticket:** 1. Navigate to **Knowledge Generation** and select the desired configuration. 2. Click on the **Generate Knowledge** button. 3. Once the job completes successfully, you will see the knowledge clusters. 4. Click on **Tickets with Resolution** (Purple Box) or **Tickets Without Resolution** (grey box) in the data processing funnel or click on the **Ticket Count** at each cluster level, to access the **Ticket Details** window, that provides comprehensive information about each ticket. ### Ticket Details Page Overview The following table describes the parameters on the **Ticket Details** window. | **Column Names** | **Description** | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ID | Shows the unique identifier of the ticket. | | Title | Presents the ticket's title. | | Ticket Type | Indicates the type of ticket (incident, problem, request, alert). | | Priority | Reflects the priority level assigned to the ticket from your Ticket Management System. | | Quality | Specifies the quality classification of the ticket as determined by the **Knowledge Generation** job, based on the presence of a resolution. | | 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.

Issue Reviewed in Other Channels & No Resolution Captured: Cases where no resolution exists, which falls under the Poor category.

Resolution Without Feedback: Situations where a solution is provided, but the end user has not confirmed that the issue is resolved.

Resolution with Feedback: A situation where a solution is provided, and the end user has confirmed that the issue is resolved.  

| | Quality Classification Reason | Provides the rationale for assigning a quality category to the ticket. As an example, the reason for a ticket titled, 'Resolution with Feedback' might be, `The agent provided a resolution action which the user followed and confirmed that it resolved the issue.` | | Created Date | Indicates when the ticket was created. | ### Acknowledgement Messages after the job runs During the **Knowledge Base Article Generation** process, tickets undergo multiple stages of processing. In some cases, certain tickets may not proceed further due to various reasons. To ensure transparency, we provide messages for each scenario. #### **Case 1: No Tickets in the Data Source** **Description:** No tickets are available in the ticket data source due to ingestion failure, or while ingestion was successful, no tickets were actually ingested.  **Acknowledgment Message:** `No tickets found in the data source.` #### Case 2: Data Source Has Tickets, but None Meet the Applied Conditions **Description:** After applying ticket filter conditions, no tickets qualify for further processing. **Acknowledgment Message:** `No tickets match the specified conditions.` Cases 3, 4 are related to backend techincal processing. #### Case 3: Tickets Exist but Are Filtered Out During Preprocessing **Description:** The data source contains tickets, but preprocessing or database joins result in zero tickets before sending them for resolution classification. \ **Acknowledgment Message:** `No tickets found after preprocessing the filtered set.` #### Case 4: Tickets Exist but Are Marked as Invalid **Description:** The system detects tickets, but GPT-4 determines them to be invalid based on content analysis. \ **Acknowledgment Message:** `No tickets found after preprocessing the filtered set.` #### Case 5: Tickets Exist but None Contain a Valid Solution **Description:** All retrieved tickets are classified as poor quality and do not provide a valid solution for KB generation. \ **Acknowledgement Message:** `No tickets have a valid solution to process.` #### Case 6: No Knowledge Clusters Found **Description:** Despite having high-quality tickets, the number of qualifying tickets does not meet the minimum threshold required to form a knowledge cluster. \ **Acknowledgment Message:** `No clusters identified as tickets are unique and do not meet the minimum requirement.` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.aisera.com/aisera-platform/content-generation-from-tickets/analyze-kb-article-generation-results/ai-generated-documents-from-bulk-tickets.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.