Description: is also a day without a joke….. In the days without jokes…. Let’s study aliyun’s customer service robot….

I. Functional survey

Official website: help.aliyun.com/document_de…

SDK and API address: help.aliyun.com/document_de…

Feature list access: help.aliyun.com/document_de…

Intelligent robots have paid version, experience version. Early adopters like Wshanshi….. To an experience version…..

Friendly reminder: the experience version can only create a robot, provide free call times 1000 times, beyond the call times, the cost is at one’s own expense.

Create a management Demo example

2.1. Management robot can be created

2.2. Answer word database can be customized

2.3. Robot binding FAQ category library can be defined

Once the FAQ class library is bound, all conversation replies match data from the bound Q&A library.

2.4. Dialogue factories can be defined

2.5. Chat mode can be opened

Session factory configures custom data collection and function calls

Here we go, here we go

In the following example, the author will make a custom function interface call on how to collect user input data as a parameter.

3.1. Click to go to session Factory

3.2. Create a dialog flow

3.3. New intent

3.4. Editorial intent

Enter the utterances triggered by the process. This process is triggered when the user consults the robot to contain the words.

3.5. Customize process configuration

Click Intention to configure the flow. Select user node, enter node name, trigger mode select intention trigger. (When the user enters a data keyword matching the corresponding message, the process is triggered to go down).

If the user asked, there must be an answer. Follow: “The customer is king and the customer is right.” . You know…

Next we need to define a reply node. In the example below, the main building is a guide. Guide the user to enter some keywords that can be collected as parameters to invoke the custom interface later in our process.

We are directing customer input, so we also need to define a user input node.

According to the above procedure, we guide the customer to enter the number. But the customer may not enter the number….

“Let me go east, I must go west…. Ah… Play the West Coast……..” So what do you do? This is…

Imagine that the reason we direct the user to enter a keyword (number) is to collect this keyword as a parameter request interface. So, on the one hand, we have to think about how to collect the data that users input, and on the other hand, we have to think about how to collect the data that we want.

Well, there are ways. You call me big brother, I’ll tell you. Hahaha……

Solution: User input data collection [define regular expression, intention + regular match + slot filling].

The specific steps are as follows:

  • First, add an intent specifically to collect user input information.

  • Edit intention and fill in relevant information.

If the above use of identification capability is not defined, it is not saved. Now let’s talk about what this recognition capability is.

The so-called recognition ability is nothing more than the user input information for discrimination. There are two ways of discrimination, one is standard entity matching, the other is regular entity matching.

Two ways. So what’s the difference?

1. Create a standard entity

Data needs to be maintained into entity members, which are matched by default from member variables configured for an entity. In plain English, it is matched from a fixed circle. If you want to match the data, you have to maintain it.

Cons: Not very flexible and requires maintenance. No import function, large amount of data, difficult to maintain. “Hey, brother! Circle is small……”

2. Create a re entityRegular expressions can be defined to collect data, which is relatively flexible.

Since my custom function in the example requires a number of type Integer, my regular expression naturally writes to collect numbers, as shown in the figure below.

Going back to the above flow, if the user enters a number, we need to collect it. So how do you collect user input parameters?

First, the user input node selects the condition to trigger. Conditions are intents = intents for custom collection parameters.

For example, in response to “Enter a number? After that, assume that the user enters 77 (or, of course, a non-numeric value).

Since we defined a regular expression to collect values, if the user enters a value at this node, the data will be collected in accordance with the regular matching rules.

Data can be collected through slot filling nodes, which are defined as follows.If you look back here, you are essentially matching the user input with the bound regular entity, and if it matches the rule, you are collecting the parameters by filling in the slots. Of course, if you choose to create a standard entity, this matches the member variables of the entity.

Next, the parameters are collected, and the call interface is white. Make! Define a function node, configure our custom interface, and take the collected data as a parameter. Collected parameters: ${collect user input. User input.origin})Function node variables are passed as parameters. For parameter description, refer to the official website documents.

Links: help.aliyun.com/document_de…

The interface calls, of course, and returns data, so you need to define a reply node that will call the result and output it.

Well, that’s the end of the sample process definition. Now let’s test the robot.

As you can see, the external function was requested and returned successfully.

At this point, the complete process is configured and tested. The end…..

Break up…….. Ow, that what…. Have a careful heart point oh!