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.
Related
We want to categorize patients in our system. For example, in organ transplant, we want to "tag" a Patient FHIR resource as a donor or recipient (ignoring the scenario where a living donor can later become a recipient) since these types of "patients" are stored separately in the back end system. So when someone does a PUT HTTP request with a patient resource, we need to know what kind of patient it is before we can do the update in the database.
It's hard to determine the best way to approach this. Using the meta area seems promising, combined with the UsageContextType of "focus" perhaps, taking on values of "donor" or "recipient".
It's not clear though how to actually code something like this in a Patient resource (JSON for us). Any guidance/examples would be very much appreciated.
Sadly, I think the FHIR folks are going down the same path they used with the V3 RIM....lots of impenetrable standard definitions, but very few practical examples of how to use some of these FHIR standards in the real world. But that is another issue.
Don't understand ignoring the scenario where someone can be both donor and recipient. However, if you needed to, you could add an extension that differentiated. You could also use Patient.meta.tag.
With the RIM there'd have been an esoteric modelling mechanism to define what you wanted, likely walking through 3-4 classes to get to one element (and a whole lot of fixed values along the way). With FHIR, if you're doing something esoteric, you just define an extension.
If you see something in the core specification you find impenetrable, please submit a change request asking for the language to be improved. (There's a "propose a change" link at the bottom of every page and registration is free.)
We want to create a chatbot with about 80 intents, where most of them are just questions with direct answers related to HR (benefits, payroll, etc). It could be done with QnA maker but we decided using LUIS and utterances to have the option to query entities in the future if we need to.
I have tried to create some entities to lift the score of some intents, for example, we have a benefit question about inscriptions to sports in our company:
Utterance:
How can I enroll in soccer?
What steps do I have to register in tennis lessons?
...
So I have created two entities, one for "ActivityType" (soccer, tennis, etc), and other for "Enrollment" (register, enrollment, etc). The later is more as a synonym variable so I don't have to write that many utterances.
Then the utterances translates into:
How can I {Enrollment} in {ActivityType}
What steps do I have to {Enrollment} in {ActivityType} lessons?
These are my questions:
1) "Enrollment" entity is used to avoid creating that many utterances, does it make sense here or there is something better in LUIS for that?
2) I have tested the system and in some questions, it picks up the two entities (enrollmnet and activitytype) which are only present in a specific intent, but then it assigns in the top another intent which doesn't have at all those entities. I would expect the entities to somewhat lift the probability of selecting the intents that are using it (in this case, there is only one using them, so it should be pretty obvious but is not being selected)
Any help will be greatly appreciated :)
If I have a prebuilt entity temperature.
And how can I match it to my intent AskTemperature
Because In the AskTemperature.
It can't add the prebuilt entity.
So how do I implement to make entity temperature belongs to the intent AskTemperature?
Thank you!!!
If you provide an example of the labeled utterances, the community may be better equipped to answer your question. That said... Once you train your model, the model should automatically assign the prebuilt entity to the recognized tokens (words, numbers, etc).
After training your model, if this recognition doesn't occur, you may need to train with more straight forward utterances (e.g. "Is the temperature in Redmond right now 16 celsius?").
If all of this doesn't work, then posting relevant portions of your LUIS model may aid in getting help from the SO community.
After you trained your model/intents, the prebuilt entities should be assigned to that utterances.
I have this utterance: are there room available on 12/21/2016?
When I tried to assign the 12/21/2016 to "datetimeV2" entity directly, I cannot find that prebuilt entity; but after I trained it, it shows automatically.
Click to see this image (cannot post image since reputation not reaching 10)
Hope this helps!
Can someone explain these 3 concepts and the differences between them with respect to an MVC framework along with an example. To me these appear almost equivalent, and it seems they are used interchangeably in some articles and not in others.
The terms are a bit vague I agree. I would use domain to refer to the business area you are dealing with. Like banking or insurance or what not. Then you have domain models. These are the things you deal with in that business domain, like for domain of banking you have accounts, customers, transfers etc. I would use term entity for referencing the class/POJO or the persisted / concrete version of a model.
What probably confuses you here is that in the term MVC, the model is a concrete thing, but it references the data model used to represent some presentation in a web GUI so don't get that mixed in with the above explanation.
The terms you are confused about are: "domain objects", "domain entities" and "model objects". While usually used interchangeably, the domain entities and model object can also be instances of active record pattern (basically: domain objects with added storage logic).
In ordinary domain object there is no storage logic. It gets handled by data mappers.
The term "model objects" comes from Fowler's books (read PoEAA for more details), and, IMHO, is part of the confusions MVC, because the entire model is an application layer (MVC consists of it and presentation layer), which contains those "model objects", which are usually dealt with by services (in that image, the model layer is all three concentric circles together).
I much prefer to use "domain object" term instead.
The term "domain entity" (or "entity object") is usually used when author implies that the object is a direct representation of a storage structure (more often - a database table). These are also almost always implementations of active record.
P.S.: in some articles you would also see term "models" (plural). It usually is not directly related to MVC design pattern, because it talks about Rails-like architecture, where "models" are just active records, that get directly exposed-to/created-by controller.
.. not sure whether this confused you more
For the record. In practical purpose, domain and model are the same, while entity is also a domain/object that would be used to store in the database.
Some people are tried to re-explain such topics but none of them are canon.
The difference is that, in the world of Java, Domain is more used, while in the world of C#, Model is used (and MS encourages his use) but its just convention and you can use both.
In the same, concept, Value Object (VO) is used by the people of Java, while DTO for the people of C# even when both are practically the same. Also POJO (Java) vs POCO (C#), Packages (Java) vs NameSpace (C#), Setter and Getter (Java) vs Encapsulation (C#)
Both domains and models are classes. How the class is use distinguishes if it should be classified and put in a domain or model folder. If the class is going to be used ONLY in the view, put it in the model folder. If the class is mapped to a database object, then put it in the domain folder.
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.