Teneo Developers

Teneo Engine and the answering process

Requests and responses

The Teneo Engine allows text-based natural language dialogues with end-users; it makes use of a knowledge base (or solution) which defines how the conversational AI application will behave. During a dialogue, the Teneo Engine can communicate with external applications, databases and other informational sources, using calls to the internal scripting language. Additionally, it also generates detailed dialogue log files on a daily basis.

The main functionality of the Engine could be described as an answering process, or rather a coherent sequence of answering processes that make up a dialogue. The sequence of events starts when a request is sent to Engine (containing the user input) and ends when the answer is delivered to the conversational AI application.

Requests

The request stands for the data made available to Teneo Engine for the purpose of locating an answer. The request data consist of the following:

Session identifier: it enables the continuation of a session and is provided as a HTTP cookie or an addition to a URL path.

Additional data

  • User input: it represents the core data required to determine the response that should be provided.
  • Data accessible via the environment
    • HTTP cookies
    • Environment variables
    • Self-defined data

Request format

An HTTP request is sent to an application where the Teneo Engine is running. This request can be made using the POST or GET methods.

Usually, the web browser will generate the request, which could be based on submission of an HTML form, an AJAX request, a request from a Flash script, etc.

Responses

During the answer process, the application server adds a response line to the answer document and then the final HTTP response is sent back to the requester. Session information is added by the application server in order to identify the next request as belonging to the same session.

Once the answer is delivered to the frontend application, the clock will start ticking for the session time-out. If the user makes another request before time-out, the same session will continue. Once the session has timed out, the application server informs the Teneo Engine about it. Then, the Teneo Engine will take the dialogue data and will write it into the session log file.

Standard rules of HTTP requests and response data formatting will apply.

The answering process consists of the following steps:

Preparation and evaluation of request data

General request data

Together with the request for an answer, data can be passed to the Teneo Engine. The user input is, as a rule, included in the request data.

The Teneo Engine will attempt to locate a meaningful response to the user input. The inquiry data is parsed and made available to Teneo Engine as follows:

  • The session identifier is evaluated by the application server and the objects belonging to the session are made available for the request (session continued) or created (new session created)
  • The content of the key user input represents the user input text (it can be changed by internal scripting)
  • Cookies, environment variables and the content of self-defined request parameters (consisting of key-value pairs) become accessible via the scripting language.

Script events can be initiated during the answering process. Parts of the request data are accessible via scripts. This includes cookies, environment variables, and self-defined request parameters (key-value pairs).

It is also possible to manipulate the user input by means of scripts (at pre-processing level only). The occurrence of script events causes the value of some pre-defined variables to be modified, as well as the definition of variables, and the assignment of variable content. This is also useful during the generation of the answer document.

Evaluation of the session identifier

If the session could be identified by the application server (if the session for that identifier still exists) the session will be continued. Otherwise, a new session will be started.

For each session, the existence of certain object is tested:

  • If these objects do not exist, they are created, script events for the session are triggered and the answering process is continued.
  • If the objects exist, the session is continued.
  • If the current transaction ID is the same as the last request and the request data is the same, the old answer is returned again without starting an answer process (it does not add something to the history).
  • Otherwise, the answering process is continued.

User input is prepared for the matching process

The user input is prepared for the matching process as follows in the below sections.

Division into sentences

The division of the user input into sentences works in accordance with the list of sentence delimiters available in the Input Processors chain. A sequence of uninterrupted delimiters counts as a single delimiter. Corresponding entries in the abbreviation list override sentence division. Before division, protected areas are created based on the abbreviation list, for which division is prevented (this applied subsequently for division into words).

Consider the following example:

Isn't there a onctact section at www.whatever.com? Is your compny in Cancun?

In this case, the areas www. and .com are protected, since these areas correspond to entries in the abbreviation list. For this reason, the input is evaluated as consisting of two sentences, rather than four (if the two entries had not been present).

Division into words

The division of sentences into words is performed in the language dependent input processors, for example for European languages this is taken care of in the Standard Splitting Input Processor. For more specific information about the word delimiters, please see the Input Processor section selecting language.

Example

Isn't
there
a
onctact
section
at
www.whatever.com
Is
your
compny
in
Cancún

Simplification

The simplification takes place in the Simplifier in the Input Processor chain. For English, the following would happen during the simplification process.

Isn't > isnt
there
a
onctact
at
www.whatever.com
Is > is
your
compny
in
Cancún > cancun

Automatic spelling correction

During automatic spelling correction, the individual words forming the sentences are compared with entries in the auto correction file. If an entry is found, that word is exchanged with the corrected form.

In the second sentence of the user input, two letters are switched; a typographical error that the standard correction list anticipates:

compny > company

Spelling tolerance

The spelling tolerance is applied to all the words in the user input which are not found in the solution dictionary. The dictionary is made up of words from word conditions in the conditions (triggers, transitions, listeners, Language Objects, Entities). For these words, a property file driven mechanism will find the closest match in the dictionary, within the defined spelling tolerance value.

Instead of using an unknown word in the matching process, the closest dictionary word will be used instead.

Note: the spelling tolerance has an important effect on performance. The more comprehensive the dictionary, the less spelling tolerance is needed.

The matching process

Once the user input is prepared for the matching process, the sentences are first tested against the global pre-listeners. These listeners are used to extract information from the entire user input, for later use in other language or script conditions.

Next, the sentences are tested against the outgoing Match Requirements of the last visited node of the currently active Flow. In case of a match, the global, Flow-level, and transition-level post-listeners are evaluated. These listeners are used to extract information from the matching input, for use in the currently active Flow. After this, the input matching process is ended, but the Flow processing continues until no matching transition exists, or until a transition is reached, which requires new user input.

If no matching Match Requirement is found in the previous step, the sentences are tested against the Flow triggers, in a predefined order (Ordering). This process stops when a Flow trigger's Match Requirements are fulfilled. The associated Flow is pushed on top of the stack of active Flows, and the Flow processing starts as described before.

If there is a current Flow (a non-active stack of active Flows) there are several possibilities:

A transition is found from the last output node in the current Flow (the last Flow that was put on the stack of active Flows). In that case, the output text from the next output node is given.

A Flow is completed. Is there another active Flow on the stack?

  • Yes: adds the resume prompt of that Flow to the final output
  • No: adds a standard prompt to the final output

No matching transition is found in the active Flow. In this case, a complex Flow is triggered (put on the stack). The new Flow then becomes the current Flow and the output from the new Flow is given.

No matching transitions or triggers are found on the active Flow. In this case, the Safetynet Flow will be triggered instead. The final output equals the chosen Safetynet output plus the resume prompt of the last active Flow.

If there is no current Flow, the possibilities are the following:

  • A new simple Flow is triggered. In this case, the final output will consist of an answer from the simple Flow, plus the standard prompt.
  • A complex Flow is triggered. In this case, the new Flow will become the current Flow (put on stack) and the output from the new Flow will be given.
  • No trigger is found. In this case, the prompt Flow triggers are tested and the Safetynet Flow is usually triggered. The final output will be the chosen Safetynet output.

Final output creation

The selected output(s) will have an effect on:

  • Logging data (dialogue transcripts)
  • Session history and session context (outputs given)
  • Answer document (via replacement of view variables)

The selected output(s) are composed into the final output and made available as answer data. Parts of the data form the dynamic part of the answer document, together with more general Teneo Engine data. The content of view variables that receive their values form output data can be modified at runtime via script expression replacement and/or via scripting API methods.

Important answer data:

  • Answer text
  • Emotion
  • Values of the extra view variables including link URL.

Session update

A new state of the session is stored in the application server. The new dialogue step and additional information is added to it. This collection of data will be used to provide a context for the next user input turn (for example, to recall that an answer has already been given) and to write the dialogue into the session log.

Generation of the answer document

After determining the final answer for the request, an answer document is generated as follows: the Engine sends the required data to a Java Server Page (JSP), which builds the response document in the requested view. During this process, the dynamic parts in the view (the view variables) will be replaced with the data provided by the Engine (general Teneo Engine data, the answer text, the emotion, etc.).

It is possible to create as many views as needed. For example, it is possible to have an HTML view for a conversational AI application based on a website, a JSON view for a mobile app, etc.

The design of the views should allow the creation of a complete document fulfilling the individual requirements after the replacement of the dynamic parts.

The answer

The application server will take the created view and the additional HTTP headers that have been created and adds a response line to it. Then, the completed HTTP response is sent back to the requester. This response will include session information in order to identify the next request as belonging to the same session.

Then, the application server delivers the answer to the frontend application, which displays the document (or computes changes in the document from the transferred data).

Once a response is delivered, the clock will start ticking for the session time-out. If the user makes another request before time-out, the session will be continued. when the session times out, the application server will inform the Teneo Engine about it. Finally, the Teneo Engine takes the dialogue data and adds it to the session log file.