Strong intents
Building well-functioning intents requires a preliminary analysis. The best time investment before starting intents on the platform is to list all the actions that your bot is expected to understand. The more scenarios you come up with, the bigger the chance that you won’t have tough challenges maintaining your bot’s NLU.
To start with, we recommend shifting focus from objects (products, services, themes) to actions that your bot is expected to perform. It’s often a shift from a business perspective to a linguistic one. Although it may seem unintuitive at the beginning, it’s the key to a well-functioning NLU.
Examples:
"I’d like to change my debt consolidation loan schedule."
"I’d like to change my mortgage loan schedule."
From a business perspective (also often based on IVR architecture), these two topics are separate, as the user journeys lead to different customer service departments. However, from the linguistic perspective, these utterances are identical apart from the parameters: debt consolidation loan, mortgage loan.
Therefore they should belong to the same intent and be differentiated on the basis of the parameters (objects, entities). The output paths in the flow should include both of them as a condition:
nlu.intent == your_intent AND nlu.variables == parameter1
The reality about bots is that they tend to grow over time. It’s a very common situation that with time it turns out the initially built intent infrastructure becomes inadequate. Therefore we highly recommend building intents according to general actions or specific concepts, depending on how they instantiate in relevant phrases.
The examples below show intents built around broad actions (where specific cases are expressed by entities).
Not safe | Safe |
---|---|
activate card activate account | activate (+ entities: card, account) |
remind login recover password | recover (+ entities: login, password) |
loan | view change (+ entities: loan, details) (+ entities: loan, repayment) |
payment | view help (+ entities: payment, methods) (+ entities: payment, failure) |
Such data architecture alleviates the risk of content overlap among intents, because it groups the most common phrases and sentence structures within a single intent.
The rule of thumb is to focus on actions that a given intent would cover. Objects, in turn, can be treated as parameters that point these actions in a specific direction (the function of entities is perfect for that purpose).
If different user actions become visible within a single intent, it should be split as soon as possible.
“I want to repay the loan quicker”
“Is it possible to arrange higher installments”
“I have a problem with repayment”
The first two sentences contain phrases commonly used to ask about repayment schedules. The third one, although still related to repayment, asks for a different kind of action than the first two. The phrases used in these two situations will never overlap. You can save a lot of time by applying this distinction right from the beginning.
Updated 8 months ago