Updated QnAMaker to use v3 API #151
Conversation
| public Metadata[] MetadataBoost { get; set; } | ||
| } | ||
|
|
||
| [Serializable] |
There was a problem hiding this comment.
Please add a JSON Serialization Test around this, just to make sure the outputted JSON is of the right format.
| } | ||
|
|
||
| [Serializable] | ||
| public class Metadata |
There was a problem hiding this comment.
Perhaps a silly question, but the QnA Maker JSON element for this is "metadata" (lowercase m). When this is serialized, will that matter? I see this is covered via the JsonProperty attributes on name/value, but I'm not sure about the class name.
There was a problem hiding this comment.
Just following up on this point. We only serialise the contents of the Metadata object (hence needing the json attributes on the name / value). When building up the request for the QnA Maker we explicitly build the object using the name "metadata". If this were to change then we would need the json property on the metadata object, so I might add it for good measure in a follow up PR when I add some additional tests mentioned above.
Updated QnAMaker to use v3 API (http://bit.ly/2EA7syR) which brings optional support for metadata to filter / boost answers returned. I can't see any downsides to implementing v3, given that it works exactly like v2, but with optional metadata properties on the request and in the response. If the user does not specify any metadata on the QnAMakerOptions.
@cleemullins As mentioned on the previous pull request to split out the QnAMaker from the middleware, I tried running the QnAMaker tests, but they are commented out at the moment. I have however ran the QnA sample against my own QnA service (which has metadata against some of the items in the KB) and all seems to be working well.
@daltskin