Entities and variables
The matter of initial planning is also important as to entities, but often simpler than in case of intents. In general, entities should be constructed in accordance with real-life ontologies. That is, the hierarchy of entities (in a broad sense) should mirror the relationships among things in real life. Then, when new flows and features appear in the bot, the architecture makes it possible to grow without shake-ups (i.e. it is scalable).
For instance, at the beginning we only plan our bot to cover information about a credit and debit card. Thus we arrange entities in accordance with the current business needs and create two separate entities:
Name | Reference value | Synonyms |
---|---|---|
debit_card | debit | debit card, charge card, atm card |
credit_card | credit | credit card, gold card, platinum card |
Over time the business priorities change and for the purpose of conditions in the flow we need to recognize a general concept of a card and also include other types of cards offered by the bank. Keeping the currently existing entities separate would enforce adding the rest of card types separately too, and therefore listing all the instances in the flow outputs.
Then we would have to build a condition like this:
‘IF entity: debit_card OR credit_card OR general_card OR virtual_card OR (...) → go to block A’.
This would be time-consuming and inefficient. Therefore, for the sake of maintenance, we need to rebuild the initial structure to make it more functional and manageable.
For instance:
Name | Reference value | Synonyms |
---|---|---|
card | general debit credit virtual | card, charge plate, plastic money, visa, mastercard debit card, charge card, atm card credit card, gold card, platinum card virtual card |
Now all the card references are enclosed in one entity and the same effect can be achieved by that condition:
‘IF entity: card → go to block A’.
Also, if any other kind of card is to be included, we don’t have to edit all the blocks that include that condition; it’s enough to just add another reference value and retrain the model.
Action/object architecture
The action/object architecture refers to the way of structuring intents and entities that is the most efficient for our NLU model.
In short, it may be explained as building intents around actions (accompanied by entities), for instance:
Intent | Entity |
---|---|
change | date time pickup place destination number of people luggage size |
pay | card transfer electronic wallet |
download | Android iOS |
Such structure makes it possible to keep intents discrete. It’s effective for the model because usually there is a limited set of phrases that express a given action, while they are accompanied by various objects.
When an object is seen as an entity by the model, it does not take part in training – what is being trained is a placeholder. Therefore if two intents express the same action and only differ in entities, the model will probably be unable to see the difference between them.
What we see | What the model sees |
---|---|
I’d like to get the booking mobile app for iOS | I’d like to get the booking mobile app for |
I want to book a taxi from Stansted at 4 p.m. tomorrow | I want to book a taxi from at |
I’d like to pay via Apple Pay | I’d like to pay via |
Note
Note that it is sufficient for the model to see an entity annotated in the platform only once. You do not need to have all instances annotated – they will be treated as entities, according to the currently trained state of the model.
Updated 5 months ago