How would you approach a problem where a user can order multiple objects which each can have entities associated
For example with a user utterance
"I want to order a large pizza with pepperoni and a small pizza with ham and pineapple"
I would want to
Recognise two distinct pizzas
The different size for each pizza
The topping associated with each pizza
I know Rasa has an option called entity groups which can handle this but does dialogflow cx? Or is it better to design a conversation flow that manages the conversation in a way that doesn't allow this sort of input?
You would have to use a form parameter in your page collecting your pizza order. You can see in the form parameter documentation that there's a boolean option for each parameter of the form named isList that collects multiple instances of a particular entity type you specify, which in your case I assume it would be the entity pizza.
For the example your provided ("I want to order a large pizza with pepperoni and a small pizza with ham and pineapple"), you can use numerical indexes in the intent parameter names in the training phrase annotations.
The annotations may look like this:
Numerical indexes will allow you to understand how many pizzas were ordered.
Extracted parameter values for this annotation will look like this:
For this proof of concept, the fulfillment is defined as conditional response:
You can define more sophisticated dynamic responses in your webhook.
Note that if you opt for this approach, you will need to add multiple diverse training phrases and annotated all of them consistently. Check out agent design best practices.
An alternative approach – collecting parameter values one by one via required form parameters – has various advantages:
you don't need to add and annotate training phrases
parameter value extraction may be more accurate.
In form parameter prompts, you may need to instruct the end-user to responds with only one piece of information at a time.
Related
On fhir.epic.com I see a lot of different information you can add to a "patient chart". For example like allergy intolerances and conditions. Through the Create route you can add such info onto the patient's chart. However, is there a way where developers can add a custom create route. So, for example, I know a patients daily protein intake, but because the API doesn't have a protein.create I can't add it to the patient chart. Is there a work around for this?
No. The whole point of the interface is to use standard resources. Epic must map the data to their existing data. If implementers passed in custom data structures, there'd be no way for Epic to map that to their standard data structures.
The specific element you mentioned would typically be captured using Observation.
In the v3 api for building LUIS apps I notice an emphasis on Machined learned entities. When working with them I notice something that concerns me and I was hoping to get more insight into the matter.
The idea is that when using a machined learned entity you can bind it to descriptors of phrase lists or other entities or list entities as a constraint on that machined learned entity. Why not just aim to extract the list entity by itself? What is the purpose of wrapping it in a machined learnt object?
I ask this because I have always had great success with lists. It very controllable albeit you need to watch for spelling mistakes and variations to assure accuracy. However, when I use machined learnt entities I notice you have to be more careful with word order. If there is a variation it could not pick up that machined learnt entity.
Now training would fix this but in reality if I know I have the intent I want and I just need entities from that what really does the machine learnt entity provide?
It seems you need to be more careful with it.
Now I say this with this suspicion. Would the answer lie in the fact that a machine learnt entity would increase intent detection where a list entity would only serve to increase entity detection. If that is the answer that most fits I think I can see the solution to what it is I am looking for.
EDITED:
I haven't been keeping up with LUIS ever since I went on maternity leave, and lo and behold, it's moving from V2 to V3!
The following shows an email conversation from a writer of the LUIS team's documentation.
LUIS is moving away from different types of entities toward a single ML entity to encapsulate a concept. The ML entity can have children which are ML entities themselves. An ML entity can have a feature directly connected to it, instead of acting as a global feature.
This feature can be a phrase list, or it can be another model such as a prebuilt entity, reg ex entity, or list entity.
So a year ago a customer might have built a composite entity and thrown features into the app. Now they should create an ML entity with children, and these children should have features.
Now (before //MS Build Conference) any non-phrase-list feature can be a constraint (required) so a child entity with a constrained regex entity won’t fire until the regex matches.
At/after //Build, this concept has been reworked in the UI to be a required feature – same idea but different terminology.
...
This is about understanding a whole concept that has parts, so an address is a typical example. An address has street number, street name, street type (street/court/blvd), city, state/province, country, postal code.
Each of the subparts is a feature (strong indicator) that an address is in the utterance.
If you used a list entity but not as a required feature to the address, yes it would trigger, but that wouldn’t help the address entity which is what you are really trying to get.
If however, you really just want to match a list, go head. But when the customer says the app isn’t predicting as well as they thought, the team will come back to this concept of the ML entity parent and its parts and suggest changes to the entities.
Suppose I have a intent "findStuff" that takes things of the form
find xxx
list xxx where something = somevalue
find xxx where something = somevalue
Getting the LUIS to understand that "xxx" is any word seems hard. I defined a "plainWord" entity, and defined a pattern feature with the same name & value "\w+". I thought that that used to work, but doesn't seem to be doing it any more. Some words that it has seen it recognizes, but it can never seem to deal with "find junk" -- "junk" is never recognized as any entity.
The system for which this is intended is open-ended. Users can add there own types of things that we may "find."...
How extensively trained is your model? You should update your model by labeling users' utterances. I recommend against using generalized entities like a "plainWord" entity, from your description it sounds like this entity is supposed to just be applied to words that occur after "find" and "list". If an entity has not been labeled/applied to many utterances, your model will not catch the words you want it to catch.
If you post your LUIS model I might be able to better help you. You can export the JSON model or provide your application ID to share it.
It is a common practice for Restful resources to support field selectors in the query string. For example, if a resource has fields A,B,C and D but the client is interested only in a subset of fields (say A and B) then the Url might look like
.../resource/1/?fields=A,B // only A and B are 'selected'
Now supposed we add another property to the resource. The thing with this property is that it does not have any physical storage. It is a computed value. Also suppose that this computation is very expensive.
Now obviously, Rest does not care about such things, whether data comes from a file a DB or a fancy algorithm.
But here comes a dilemma: the 'fields' query parameter is always optional. In my case, omitting 'fields' means "bring all the fields" (much like '*' in SQL):
.../resource/1 // A,B,C,D and E(xpensive) are 'selected'
I am positive that there are many existing clients that are using the naive approach (not bothering to specify an explicit list of fields). This means that adding this new heavy property will unintentionally create a performance break (possibly a very severe one).
What are the common techniques to cope with these situations?
Alternatives I considered:
Add a special notion to the system that says that querying with '*' semantics will not necessarily return ALL the fields (heavy fields will be omitted by default). If a client wants them- he must ask for them explicitly
Not to model these extra properties as fields on the resource. Instead expose a dedicated endpoint that will carry out the computation, thus eliminating possible confusion but introducing Rest-RPC style into the system.
Make it the cilent's problem: if he did not bother to be explicit in the first place, tough for him. That is not really an option- don't have this privilege.
I like option 1 best. I'd consider representing these fields as referenced object, and then you could get to them HATEOAS style, through separate calls for the heavy fields. This is similar to how web-pages behave -- return the framework and some content, then force extra calls if the user wants the images, videos, etc. –
Take a look at this: spring.io/understanding/HATEOAS, this: timelessrepo.com/haters-gonna-hateoas, and this: stackoverflow.com/questions/tagged/hateoas
How do you apply validation in an MVP/domain environment ?
Let me clearify with an example:
Domain entity:
class Customer
{
string Name;
etc.
}
MVP-model
class CustomerModel
{
string Name;
etc.
}
I want to apply validation on my domain entities but the MVP model has it's own model/class
apart from the domain entity, does that mean I have to copy the validation code
to also work on the MVP-model?
One solution I came up with is to drop the MVP-model and use the domain entity as MVP-Model,
but I don't want to set data to the entities that isn't validated yet.
And second problem that rises is that if the entity has notify-events,
other parts of the application will be affected with faulty data.
A third thing with that approach is if the user edits some data and then cancels the edit, how do I revert to the old values ? (The entity might not come from a DB so reloading the entity is't possible in all cases).
Another solution is to make some sort of copy/clone of the entity in question and use the copy as MVP-model, but then it might get troublesome if the entity has a large object graph.
Anyone has some tips about these problems?
Constraining something like the name of a person probably does not rightfully belong in the domain model, unless in the client's company there is actually a rule that they don't do business with customers whose names exceed 96 characters.
String length and the like are not concerns of the domain -- two different applications employing the same model could have different requirements, depending on the UI, persistence constraints, and use cases.
On the one hand, you want to be sure that your model of a person is complete and accurate, but consider the "real world" person you are modeling. There are no rules about length and no logical corollary to "oops, there was a problem trying to give this person a name." A person just has a name, so I'd argue that it is the responsibility of the presenter to validate what the user enters before populating the domain model, because the format of the data is a concern of the application moreso than the domain.
Furthermore, as Udi Dahan explains in his article, Employing the Domain Model Pattern, we use the domain model pattern to encapsulate rules that are subject to change. That a person should not a have a null name is not a requirement that is likely ever to change.
I might consider using Debug.Assert() in the domain entity just for an added layer of protection through integration and/or manual testing, if I was really concerned about a null name sneaking in, but something like length, again, doesn't belong there.
Don't use your domain entities directly -- keep that presentation layer; you're going to need it. You laid out three very real problems with using entities directly (I think Udi Dahan's article touches on this as well).
Your domain model should not acquiesce to the needs of the application, and soon enough your UI is going to need an event or collection filter that you're just going to have to stick into that entity. Let the presentation layer serve as the adapter instead and each layer will be able to maintain its integrity.
Let me be clear that the domain model does not have to be devoid of validation, but the validation that it contains should be domain-specific. For example, when attempting to give someone a pay raise, there may be a requirement that no raise can be awarded within 6 months of the last one so you'd need to validate the effective date of the raise. This is a business rule, is subject to change, and absolutely belongs in the domain model.