I'm currently training a chatbot to recognize intents and provide fulfillment based on these. It is working fine when the query passed to it resembles what it has been trained on.
However, I'd like to train my chatbot to handle out of scope requests. The idea here is to capture the "confidence" value and use it in an "if/else" statement to provide a standard response if the value is too low.
Is there a way to capture this "confidence" value? Is there a tracker for it similar to slots? See snippet below for confidence value I'm trying to extract.
Received user message 'show me Brazilian steak houses'with intent '{'name': 'restaurant_search', 'confidence': 0.4830598338322177}'
this is currently not returned as part of the payload, but it is printed if you have logging level set to debug, see https://github.com/RasaHQ/rasa_core/blob/4adf5914f25bff9d59dfc1a5492a18e14f7acba7/rasa_core/policies/ensemble.py#L68
we can certainly look into returning that as part of the payload, but possibly your best approach is to create a custom policy which checks this number and overrides it with a fallback action. We should add some documentation on how to do this.
Related
I am developing a small application to test the change stream functionality in MongoDB.
I have found that if one uses a client session, that information is included in the change stream output (change event)
For instance, here is the output when I insert a document:
{"txnNumber"=>1, "lsid"=>{"id"=><BSON::Binary:0x70310118878160 type=uuid data=0x05d30a0fa4db4f24...>, "uid"=><BSON::Binary:0x70310118878040 type=generic data=0x08e97261f57b1617...>}, "_id"=>{"_data"=>"8262D407C4000000022B022C0100296E5A100483BECD0AF46146E4A271EDAC0922356946645F6964006462D407C48C187B092534BD050004"}, "operationType"=>"insert", "clusterTime"=>#<BSON::Timestamp:0x00007fe4b351d4f8 #seconds=1658062788, #increment=2>, "fullDocument"=>{"_id"=>BSON::ObjectId('62d407c48c187b092534bd05'), "one"=>"one"}, "ns"=>{"db"=>"change_stream_testing", "coll"=>"testing"}, "documentKey"=>{"_id"=>BSON::ObjectId('62d407c48c187b092534bd05')}}
The "lsid"-field contains information about the session from which the write originated. After taking a closer look at this i found that it contains base64 encoded data (just doing a json.parse() on the id and uid fields)
ID IS
{"$binary":{"base64":"BdMKD6TbTySICrHNHE6GBA==","subType":"04"}}
UID IS
{"$binary":{"base64":"COlyYfV7FhdDV8hhDrSY7+10/NVCs/fLwkGrKMztex4=","subType":"00"}}
Now, the problem/question is that i can't decode that base64 string to something readable. Using an online decoder i get
У
¤ЫO$€
±НN†**
and **éraõ{CWÈa´˜ïítüÕB³÷ËÂA«(Ìí{
respectively - when using the "auto detect" feature or UTF-8 which MongoDB uses internally (according to a quick google search)
The reason I ask is that I have a use case where, in some cases, I would like to be able to identify where an event in the change stream originated from ie. and what client issued the write. The only way I've been able to sort of accomplishing that without using the mutateFields operator to actually change the documents themselves and adding some kind of marker I could inspect in the change stream code (which I ideally don't want to do) is to use explicit client sessions which at least lets me know that whatever was writing the document was using an explicit session. But I would like to be able to go further and actually decipher this session information to, if possible, get some kind of unique identifier.
I have the resource /contracts with the following structure:
{
name: "Contract name",
signedAt: 123213231,
// etc.
}
While basic CRUD operations are well clear (GET /contracts, GET /contracts/{id}, POST /contracts, etc.) some doubts come when I have to do some concrete actions on the resource.
One of these actions is the following:
sign: means the contract is signed, so the signedAt date will need to be updated with the moment (date-time) the contract was signed.
So far I've been thinking about these different approaches:
PATCH-ing the resource
This approach will mean having the following endpoint method:
PATCH /contracts/{id}
and just posting the signedAt date { signedAt: 123213231 } meaning that after this the contract will be signed.
What I don't like about this approach is that the signature date comes from the client, I was thinking that having this date initialized on the backend side whenever a contract is signed could be better and more consistent.
Totally discarded, as the signedAt date should be set on the server
side exactly at the moment the sign is done.
POST-ing a new resource
This approach will mean having the signature action as a resource:
POST /contracts/{id}/sign
with an empty body in this case as we don't need to pass anything else so, once it is posted, the backend side would be the responsible for having the signature date initialized.
POST-ing the resource using 'action'
Similar to the previous approach, in this case I would use a query parameter called action on the contract resource:
POST /contracts/{idContract}?action=sign
also with an empty body where ?action=sign. Like in the previous approach, once posted the backend side would be the responsible for having the signature date initialized.
Questions
What would be the proper way to have this designed at a REST API level?
Is any of the approaches above close to a good design or not?
Would I need to modify any of the approaches?
Is there any better alternative?
I have designed a few rest APIs myself but I am not a restful evangelist so my answer might not be the best. I would suggest some of the following:
Create a custom converter for date values in your rest service that accepts date AND other specific fields. If you checkGoogle reporting APIs for example they allow you to use specific date range and also CURRENT_WEEK, CURRENT_MONTH etc. So you can add such specific value and use it. For example PATCH signedAt=CURRENT_DATE and the API handles that properly.
Add a boolean signed field to the resource. Do a POST or PATCH with signed=true. This way you will be able to eventually query only signed resources easily ;) Also it might be the case that people care only about if it is signed than when it was signed
I wouldn't use ?action=sign or /contracts/{id}/sign because these are not RESTFUL and even if you do use GET and POST you would use them in a way to create a workaround in order to implement actions in your design which shouldn't have actions
just posting the signedAt date { signedAt: 123213231 } meaning that after this the contract will be signed.
On HTTP Patch
The set of changes is represented in a format called a "patch document" identified by a media type.
Rather than rolling your own bespoke media type, you might want to consider whether one of the standard formats is suitable.
For example: JSON Patch.
Content-Type: application/json-patch+json
[ { "op": "replace", "path": "signedAt", "value": 123213231 }
JSON Merge Patch is another reasonable option
Content-Type: application/merge-patch+json
{ signedAt: 123213231 }
From what I can see, the primary difference is that JSON Patch provides a test operation which gives you finer grain control than simply relying upon validators
But you are absolutely right - PATCH gives the client code authority to specify the time value. If that's not appropriate for your use case, then PATCH is the wrong tool in the box.
POST /contracts/{id}/sign
POST /contracts/{idContract}?action=sign
As far as REST/HTTP are concerned, these two choices are equivalent -- you are updating the state of one resource by sending an unsafe request to a different resource. There are some mild differences in how these spellings act when resolving references, but as request-targets, it doesn't make a difference to the client.
An option that you seem to have overlooked:
POST /contracts/{id}
action=sign
This has the advantage that, when successful, you get cache invalidation for free.
In a hypermedia API, the flow might go something like this: the client would GET the resource; because the resource hasn't been signed yet, the representation could include a form, with a "sign" button on it. The action on the form would be /contracts/{id}. The consumer "signs" the contract by submitting the form -- the agent gathers up the information described by the form, encodes it into the request body, and then posts the request to the server. The server responds success, and the client's cache knows to invalidate the previously fetched copy of the resource.
We want to work with timezones in the Watson Assistant responses.
Basically we want to implement the "good morning" sample as described here:
https://console.bluemix.net/docs/services/conversation/dialog-methods.html#date-time
When we post to this URL
https://gateway.watsonplatform.net/assistant/api/v1/workspaces/<workspaceid>/message?version=2018-02-16
using this payload (first call in the conversation)
{"context":{"$timezone":"Europe/Amsterdam"}}
We keep getting greetings based on the UTC.
When we add the now() output to the response we also do see the time according to the UTC.
The strange thing is, when we try this out in the try-out panel of the Watson Assistance workbench (browser) the output behaves as expected ?
The value should be, without the dollar sign:
{"context":{"timezone":"Europe/Amsterdam"}}
The $ is used to denote (context) variables for the short syntax, but in the payload you are working with the regular context struture and key/value pairs.
I have a need to pass data from one system to another, during SSO using PingFederate.
Currently my link looks like this:
https://pingfederate.myexample.org/startSSO.ping?TargetResource=https%3A%2F%2Fwebapp.othercompany.org%3FkeepParam%3DkeepThisOnURLparamOne%3DvalueOne%26paramTwo%3DvalueTwo
TargetResource, decoded, looks like this:
https://webapp.othercompany.org?
keepParam=keepThisOnURL
¶mOne=valueOne
¶mTwo=valueTwo
After pingfederate processes the request, it ends up making a post to othercompany, copying the entire TargetResource into RelayState, params and all:
POST https://sso.othercompany.org
SAMLResponse: {paramOne: valueOne; paramTwo: valueTwo} //(in actual saml format)
RelayState: https://webapp.othercompany.org?keepParam=keepThisOnURL¶mOne=valueOne¶mTwo=valueTwo
My goal is to pass paramOne and paramTwo into SAML attributes somehow, but NOT carry those params over onto RelayState, keeping only keepParam=keepThisOnURL:
POST https://sso.othercompany.org
SAMLResponse: {paramOne: valueOne; paramTwo: valueTwo} //(in actual saml format)
RelayState: https://webapp.othercompany.org?keepParam=keepThisOnURL
Is this possible to do with PingFederate?
E.g., is there any other way to pass data into startSSO.ping from a browser request besides sneaking them into TargetResource?
Or if they can only be appended to TargetResource, can the value be modified (strip off most params) before copying into RelayState?
The reason that the parameters were tacked into the Relay State is because you URLEncoded them, So PingFed thought they were just part of the TargetResource.
Instead, you would do something like this:
https://pingfederate.myexample.org/idp/startSSO.ping?
paramOne=valueOne&
paramTwo=valueTwo&
TargetResource=https%3A%2F%2Fwebapp.othercompany.org%3FkeepParam%3DkeepThisOnURL
I should point out two things, the first being a showstopper:
fulfilling attributes via parameters passed in the startSSO.ping calls is not supported and won't work properly until at least one of two current feature requests are fulfilled, PPQ-1141 and PPQ-2815. Neither of these are currently scheduled (low request volume) in the development trains, so if this is critical to your work, get in touch with your Ping account executive to have your needs communicated.
I should point out that this overall methodology probably doesn't make a whole lot of sense from an operational standpoint, simply because it means that you will be dependent on an IdP initiated transaction because you have no way of fulfilling this with an SP-initiated transaction.
Based on those, I would recommend trying to architect another solution by which you could set those attributes, which I recognize may be difficult - especially if they are only derived at runtime, rather than via query to a datastore.
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api