FLOW

This chapter will explain what is a dialogue flow and how to build a dialogue flow on the platform.

Mostly, the purpose of end-users interaction with chatbot are not just to obtain the answer to a common question (this simple task can be realized by FAQs).

The purpose of end-user interaction can be complicate. For example, when users query "order status" through the agent, in order to meet this purpose, first, The agent needs to understand the user's "intention"; then, the agent needs to take some dialogue actions and obtain the necessary information (such as order number, order time, etc.) to complete the intention; finally, the agent use the obtained information to complete the task. This often requires multiple rounds of interaction.

The Dialogue Flow of this platform provides the function of building multi-round interaction interactive agent.

Core competence of Dialogue Flow

Flow has three important abilities: intention recognition, entity extraction and dialogue management. Each of these is accomplished by a core module:

1. Intention recognition: after the user sends the first sentence, the agent judges the intention the user wants to express and starts the corresponding flow.

For example, the user said "help me book a train ticket to Shanghai tomorrow". The agent judges the user's intention as "booking a ticket". In the platform, you can teach the agent to recognize intention by setting the trigger mode of intention.

2. Entity extraction: from each sentence of the user, the agent attempts to collect the information needed to complete the task.

For example, the user said "help me book a train ticket to Shanghai tomorrow". The agent can extract the key information "destination = Shanghai" and "departure date = tomorrow". In the platform, you can teach agents to extract entities by creating entities and slots and associating slots in the intended dialogue unit.

3. Dialogue management: according to the extracted key information, the agent judges what operation to perform next.

For example, after the user says "help me book the train ticket to Shanghai tomorrow", the agent knows the destination and departure date, so it can be judged that the next step is to ask for the departure place and departure time. You can teach the agent how to manage dialogue by creating dialogue units in the intention process and the jump relationship between dialogue units.

Request Block

Robots often need to "ask" the user and obtain the necessary information to complete the task from the user's reply.

For example, in order to complete the task intention of "booking air tickets", the robot will ask the user "where are you going", "where do you start" and "when do you start". Through the user's response to the information "from Beijing to Shanghai, starting at 10 o'clock", the robot obtains the information and promotes the dialogue.

Such dialogue and interaction can be realized by using the Request Block.

Inform Block

In multiple rounds of dialogue, the robot is often required to send a notice to the user, but the user is not expected to respond.

For example, at the end of the intention of booking a ticket, the robot sends, "thank you for using the service and have a nice trip!"

Such dialog interaction can be realized by using the Inform Block.

Compute Block

Most of the time, the information obtained by the robot from the end user does not collect the final data required by the task, but needs to be processed. However, if only use Request Block, the data in slots cannot be changed.

For example, the data obtained in the slot needs to be changed as follows:

No matter what value is filled in before the slot, as long as the user process goes to this unit, the value in the slot needs to be reset to a fixed value or cleared.

The information entered by the user exists in two slots respectively, but the content of the other slot needs to be spliced into the current slot.

The above requirements can be realized by Compute Block.

Webhook Block

Sometimes in an intent process, the bot needs to obtain multiple pieces of information from a third-party interface and use them in subsequent processes.

For example, in the intent to query for airline tickets there are the following steps.

• The bot asks the user for the origin, arrival, and departure time.
• The bot passes the origin, arrival, and departure time to the third-party interface, which returns flight information based on these three pieces of information.
• The agent sends the queried flight information to the user.
• The flight information queried by the bot is likely to contain multiple fields, e.g., flight number, ticket total, transfer information, etc.

The desired result might be.

• Slot "flight number": SA1234.
• Slot "Total amount of airfare": $1100.
• Slot "transfer information": direct flight.

At this point, you can achieve this by using a Webhook Block. It is possible to obtain multiple slot values in a single unit by making a single call to a third-party interface.

Interface request format

When sending a request, the multi-slot interface unit can splice multiple slot values to send out according to the needs of the third-party interface.

The interface request format is as follows.

http://yourhttpserver:port?attr1_name={slot1_name}&attr2_name={_slot2_name}

there are two syntaxes for citing slots：

When using {slot1_name}, if the value belongs to an entity, it will be replaced with the entity-normalized value.

Using {_slot2_name} will use the text value of slot2 directly.

For example, a user says to the bot on January 1, 2019, "I want to book a meeting room for today." The slot "meeting date" gets the slot value "today", and queries "today" as the entity "date ".

If you use:

http://yourhttpserver:port?attr_name={meeting date}

attr_name=“2019-01-01”。

If you use:

http://yourhttpserver:port?attr_name={_meeting date}

attr_name=“today”。

Interface return format

In receiving the return value, the webhook unit can receive the slot values for multiple slots from the third-party interface, as well as the responses to be sent to the user. Among them.

• Receive the slot value: usually need to return. If not returned, the slot value is empty, and the default jump will be entered when determining the jump logic.
• Reply to the user: optional.

Interface return parameters are as follows.

 {
    "slots": [{
        "name":"new_slot_name",
        "value":"new_slot_value"
        },{
        "name":"new_slot_name",
        "value":"new_slot_value"
        }
      ],
    "msg_body": [{
        "data":{
            "content": "Test content"
          },
        "type":"text" 
      }]
  }

Mock Slot Value

End Block

The End Block exists as the end of the skill process. It is recommended to configure this block for the end of each skill process.

When a skill process is completed, the agent may need to jump to another process. Or, the agent may need to determine whether to terminate the process immediately, or keep the current session and wait for the user to return to the session at any time.

At this time, you need to use the End Block to set it up.

The core capabilities of the End Block are:

1. Clear the filled slot content after completing this terminal block: If you choose to clear, all the filled slot content will be cleared immediately after completing the terminal block. If it is not cleared (default), the contents of all filled slots will be retained until the logic of other slots being cleared or changed is triggered.

• The "clear the filled slot content after completing this end unit" in the skill end block only controls whether the slot of this unit is reserved
• The "reserved slot" in the skill settings controls the entire intent.

2. Transfer to skill: You can choose whether to jump to other skills after completing this block. The default is empty and no jump.

3. The skill after the previous runs from the beginning：If this function is turned off, after the skill jumps, the breakpoint will be searched first, and the process will continue from the breakpoint. If it is turned on, the jumped skill will start from the beginning.