Using Dialogflow CX composite entities to work around system entities limitations
Dialogflow CX provides many system entities to extract common types from end-user expressions. For most use cases, the values provided by system entities work well however support differs for languages and regions. Some system entity types are not yet available in non-US and non-global regions while others that are currently available have some limitations for specific languages like Italian. This post describes how system entities can be combined into custom composite entities to overcome some of those limitations.
Let’s dive in!
Some time ago one of my clients discovered a quirk of @sys.date-time when used with the Italian language. I will provide some examples below and if you don’t speak Italian this is a good opportunity to start learning ;-)
The table shows that user input like “in a week’s time at 9 AM” or “on 22nd August at 9 AM” are not parsed correctly. In the first scenario the date is correct but the time is wrong. In the second one the date is missing. In the third and the forth scenarios the system entity resolves the date as a date period and it doesn’t match the time.
The issues were also reproduced outside of europe-west1 in the Global region and when the NLU team tested all the cases they found the scores of the output were not ideal. To be more specific:
- "tra una settimana alle 9" - The output has both datetime point of 9am/pm today (correct), as well as a datetime annotation “in a week” (wrong) annotation, but the latter has higher score.
- “22 agosto alle ore 9” - Again the output has both datetime point of Aug 22nd 9am (correct), as well as a period (wrong) annotation, but the latter has higher score.
I found that a possible way to work around those issues is a custom composite entity that uses both @sys.date and @sys.time.
A composite entity is a special kind of list entity. Entity entries for list entities typically contain simple words or phrases, but they may also contain other entity types. When an entity type is referenced in another entity type, the reference is called an alias. When a list entity contains aliases to other entity types, it is called a composite entity.
For this specific purpose of parsing a date and a time from the user input we need to create a custom composite entity that has the following entity entries and doesn’t have synonyms:
In a composite entity the reference to another entity type (like @sys.date and @sys.time) is called an alias. When creating an alias, you supply the name of the referenced entity type and a property name of your choosing. You can also use multiple entity aliases in an entity entry. That’s exactly what we are doing here. Our custom entity type contains aliases to the @sys.date system entity type and the @sys.time system entity type in one entry. The format for entering an alias is:
@entity-name:property-nameWhen a composite entity is matched at runtime, the extracted value is returned as a JSON object, with alias property names used as JSON property names. If an end-user input contains both a date and a time like “22 agosto alle 9” the extracted value is returned as a JSON object like:
I want to bring your attention to the second entry of the composite entity.
@sys.time:time del @sys.date:date“del” (of) is the preposition that precedes the date and it allows the entity to match both time and date when they’re passed in this order. Words or phrases used in composite entities are very powerful. For example, consider a flight booking agent and the following end-user input “I need to book a flight from Melbourne to Sydney”. Melbourne and Sydney are locations hence the system entity @sys.location can extract them however how do we disambiguate between departure city and destination? That’s why we need to include the prepositions “from” and “to” in a composite entity entry.
from @sys.location:departure to @sys.location:destinationBack to date and time you would have noticed that I also added @sys.date:date and @sys.time:time as two separate entries. That allows the composite entity to match an end-user input that contains a date or a time part only. If the input contains a “22 agosto” part, the date entity type is matched and the extracted value is returned as:
Why? According to the Cooperative Principle, efficient communication relies on the assumption that there’s an undercurrent of cooperation between conversational participants. Research has shown that people respond to technology as they would to another human. There is a chance our end-user provides only the date or the time and in a human-to-human conversation that piece of information would certainly be collected. A human assistant will follow up asking “what time?” if just the date is provided or “what day?” if just the time is provided. That’s exactly how I expect a virtual agent to interact with a user.
Hooray, we are all set! Aren’t we? Not jet. :-) In Italian “22 Agosto alle ore 9” means “22nd August at 9 AM” because we have adopted the 24-hour clock. Having said that if at 4 PM I message a friend to let her know we are meeting up at 6 PM I will write something like “vediamoci alle 6” instead of “vediamoci alle 18”. She knows we are catching up in two hours time and not tomorrow morning at 6 AM because she has context. The context here is we want to meet for dinner and not for breakfast ;-)
The online documentation of Dialogflow CX states “If there is ambiguity in end-user input due to missing date/time elements, the nearest matching future date/time is returned.”. Using the system entities @sys.date and @sys.time in a composite entity instead of the system entity @sys.date-time has the downside that we need to write some custom business logic to disambiguate whether the user actually means 9 AM or 9 PM depending on the context. Alternatively the matched time is going to depend on the current time, since Dialogflow picks the closest time in the future that matches the given input.
To summarise, Dialogflow CX composite entities provide powerful capabilities to match data. In fact many system entities are composite entities. They can also be used to overcome some of the current limitations of the system entities to extract common types from end-user expressions as system entity support differs for languages and regions.
