Audience

Administrator User within Admin UI

Prerequisites

1. Set up a knowledge base as a data source
   
   Creation of the knowledge base as a data source requires the following information from the customer administrator:
1. Knowledge base public URL: the URL must be publicly accessible without having to login through a customer VPN
2. Authentication information based on the security/authentication being used to protect the public URL. This may include one of the following:
1. Using Basic Auth - User name and password
2. Using API Token
3. Using OAuth
3. Function of the Data Source: One should be aware of the one or more functions of the data source (intended purpose/use of data source) - e.g. tickets learning, knowledge base learning, tickets creation etc.

How to Set Up a Scheduled Incremental KB Crawl

When a knowledge base has been set up as a data source under Settings, the administrator can either schedule an incremental crawl of the knowledge base on a cadence (Hourly, Weekly, etc.) or on an ad hoc basis (On Demand).

To view the data source to schedule the crawl, first click on Settings on the left hand main navigation pane, then select Aisera Apps, as below:

Next, select the app (also known as the bot) for which the knowledge base crawl should be run - there should be at least one app, but there may be more depending on the use case. Click on the respective app, in this example, ContentDemo:

Then, click on the row of the knowledge base data source for which the crawl should be run. There may be one or more knowledge base data sources set up depending on where the app pulls its knowledge documents. In the example shown below, the knowledge base is set as ServiceNow, and it is listed as a data source both on the Aisera App itself as well as above in the high level overview of the app.

Clicking on the row of the data source should lead to the page below. This will provide information on the data source on the right hand side with its purpose, its current state (if it is currently running a crawl or not), which apps the data source is being used on, its current scheduled cadence, and the data source’s creation date. Under Executions is a history of all crawls that have been done in the past or are currently being run for the knowledge base.

At the top right, there should be a pencil icon, which upon hover should state Edit:

Clicking on the pencil icon should bring up the Edit Data Source screen, where in this case the Schedule and Data Retrieval fields will be the most relevant for scheduling crawls of the knowledge base:

The Schedule field dictates the frequency at which documents are updated or brought in from the original knowledge base. By default, the data source will be set to On Demand, which will not be on a cadence but on an ad hoc basis defined by administrators in the Admin UI.

For the Data Retrieval field, setting this to be Incremental would bring in knowledge that has been added or modified since the previous crawl. Setting this to a Date Range would bring in any added or modified knowledge since a previous crawl within the specified date range.

Once everything has been set, select OK at the bottom right of the screen to save all changes.

Note: It is recommended that you run KB crawls on a bi-weekly schedule. 

How to Review Crawled Knowledge Documents

Assuming that there is a knowledge base properly set up as a data source and there has been a recent new crawl completed of the knowledge base (either scheduled or manually on demand), the administrator may then review all of the knowledge documents and sections within those documents that were added, modified, or deleted since the previous crawl.

To view all of the changes (added, modified, and deleted) made after the most recent crawl, navigate to AI Workbench on the left hand main navigation panel, then click on the Knowledge Review tab at the top of the page, as shown below:

This page lists all of the newly added, modified, or deleted knowledge documents that were pulled from the most recent crawl of the knowledge base. Please keep in mind that all knowledge articles displayed on the page are at the document title level, and can be reviewed at the section level by clicking on each individual knowledge document row. Please see below for the definitions and key features of this Knowledge Review page.

Knowledge Review Definitions

1. Change State
1. Added: The knowledge document did not exist in the previous crawl, and was brought into the platform via the most recent crawl of the knowledge base.
2. Modified: The knowledge document already existed in the previous crawl, but there was some change made to the document at its section title or content level.
3. Deleted: The knowledge document existed in the previous crawl, but was removed from the knowledge base and no longer exists after the most recent crawl of the knowledge base.
4. Note: Added documents and Deleted documents are added and committed to the platform automatically. As an administrator, you will not need to manually approve and commit documents with these specific change states. You will only need to manually review and approve documents with the status Needs Review.
   
   
2. Review Status

1. 1. Needs Review: The knowledge document needs an administrator’s manual approval. Once approved, the document will still not be accessible to Aisera end users until the administrator clicks on Commit Changes and clicks Retrain for the app on the Conversation Lens page.
   2. Reviewed: The knowledge document change was either 1) automatically or manually approved, or 2) manually rejected. This document will not be accessible to Aisera end users until the administrator clicks on Commit Changes and clicks Retrain for the app on the Conversation Lens page.
   3. Committed: The knowledge document was approved and committed to the platform (either automatically by the system or manually by an administrator clicking on Commit Changes), which means that they are now accessible to Aisera end users after clicking Retrain for the app on the Conversation Lens page.

Knowledge Review Functionality

1. Knowledge Review Filters
   At the top, there are filters to save or apply custom pre-saved filters, search by the document name or section, or filter by various document metadata, as below. The default primary filters will be Change State and Review Status, with definitions listed in the section above.
   
   
   
   
2. Conditions for Each Review Status
1. All documents shown on Knowledge Review are titles of the full knowledge documents themselves. Drilling down on these documents will show the document sections and content.
2. Added and Deleted documents from crawls are approved and committed to the platform to be accessible to users automatically after a retrain of the app. These documents will show statuses of Reviewed.
3. Modified documents need to be manually approved and manually committed.
   
   
   
3. Reviewing Knowledge Documents
1. Clicking on each individual knowledge document row will lead to the knowledge document section titles and their respective content. 
2. Approve: Aisera keeps all phrases associated with the old section and accepts the new section.
3. Reject: Aisera keeps all phrases associated with the old section and does not accept the new section.
4. Reassign: Manually reassign the new section copy to the section it was in the previous crawl.
5. Added and Deleted knowledge documents will be automatically marked as Reviewed.
   
4. Commit Changes

1. Committing changes commits all knowledge documents to the platform and makes them accessible after a retrain. To do this, click on Commit Changes, then go to AI Workbench > Conversation Lens on the top leftmost tab and click Retrain at the top right of the screen: 

Retrain the app after clicking Commit Changes:

Reviewing Knowledge Documents

Please keep in mind that you will only be required to review knowledge documents that are under the status Needs Review. Any other documents that show as Reviewed have either been approved or rejected, and any documents that show as Committed have been both reviewed and committed to the platform under Commit Changes, as defined in the previous section. 

If section titles and content within a knowledge document have stayed the same in both the previous and most recent crawl, the sections will automatically be approved:

For Modified change type knowledge documents, there are three scenarios:

1. Within the knowledge document that needs review from the most recent crawl, a section title has stayed the same as it did in the previous crawl, but the content under the section title has changed.

1. 1. In Knowledge Review, the section will be approved automatically, and the status will also automatically be set as Reviewed.
   2. An administrator will still need to click Commit Changes and retrain the app for the changes to take effect.
   3. Any existing knowledge intents from the previous crawl that shared the same title will be updated with the correct content.

In the example below, the section title How to Deal with Spam has stayed the same in both the previous and most recent crawls, but the content has been modified. Aisera understands that the section title means that the section is still pointing to the same knowledge intent(s):

2. Within the knowledge document that needs review from the most recent crawl, a section title has changed since the previous crawl, but the content under the section title has stayed the same.

1. 1. In Knowledge Review, the section will be approved automatically, and the status will also automatically be set as Reviewed.
   2. An administrator will still need to click Commit Changes and retrain the app for the changes to take effect.
   3. Any existing knowledge intents from the previous crawl that shared the same content will be updated with the correct section title and knowledge intent name.

In the example below, one of the section titles changed from Why did the beavers pick my ditch, lake, river or pond? to Why did the beavers pick my lake, river or pond? - this is detected as the same section due to the section still having the same content as before:

3. Within the knowledge document that needs review from the most recent crawl, both the section title and content under the section title have changed.

1. 1. In Knowledge Review, the system will not know for sure whether it is the same section, and an administrator will need to either Approve, Reject, or Reassign the section. The status will then be set as Reviewed.
   2. An administrator will still need to click Commit Changes and retrain the app for the changes to take effect.
   3. Knowledge intents that were created from sections that no longer exist will be deactivated. Any existing knowledge intents that exist and are reassigned will be updated with the correct name of the reassigned section title.

In the example below, the section Firefox 2 is the same as Firefox 2 and more, but because the section content has also changed, Aisera isn’t sure that it is the same section. In this case, one of the sections can be reassigned to the other, so that they are marked as the same section and therefore the same knowledge intents, which will be updated: