We created dialogs with Bluemix Dialog service and now we would like to import them into the new Bluemix Conversation service.
The export-import failed.
Do you know if an transfert process exists ?
Thank you
Unfortunately the ability to migrate to Conversation from Dialog is not possible, as the two systems are very different.
Intents in Conversation are similar to NLC. So if you have an existing NLC service, you can export that and import as a CSV file.
Entities in Conversation are not at all related to the same in Dialog.
Conversation itself is stateless. All conversational state, context variables need to be maintained at the application layer. Where as Dialog would normally maintain that.
In Dialog What you would define as an INPUT + OUTPUT nodes are now a single node in Conversation.
GOTO is now Continue from. But a continue from will have different behaviours depending if you hook it to "wait for user input", "condition" or "message".
Fuzzy matching what you would normally do with Variations is now handled by coding in condition blocks, or at the application layer.
Related
Is it possible that the chatbot responds for example to node 7 taking into account an intent that was written in node 3?
Imagine that in the second question of the chatbot you say that you are a boy and then there is a jump to because there are equal questions for both genders, but then there is different information depending on having chosen a sex.
I don't want to ask that again. Then I want you to remember that attempt to decide.
With IBM Watson Assistant the dialog nodes typically react to conditions. The conditions are based on evaluating the current intent, entities or context variables. Context variables can hold a value or remember settings across the evaluation of multiple dialog steps (nodes).
In your case, you would gather information with questions and user answers, e.g. by utilizing slots. The chatbot would remember the gender, age group and more. The dialog nodes could switch to the specific question or reponse based on that context data or jump to a gender-specific subgroup of questions if needed.
I would recommend to look into some of the more complex samples (tutorials) and how the dialogs make use of context variables.
While developing and testing the conversation, IBM Watson Assistant identifies multiple intents and respond to the one with highest confidence level. Sometimes I want it to respond to second intent not the first one because it is more relevant to the current conversation context. For example, if the dialogue contains nodes to handle making transfer or payment, during the transfer scenario the user can say execute which will match both execute transfer and execute payment. So I want Watson to always respond to execute transfer which is the current context even if it identifies execute payment with higher confidence.
So users ask generic questions assuming that the bot is aware about the current context and will reply accordingly.
For example, assume that I'm developing a FAQ bot to answer inquires about 2 programs Loyalty and Saving. For simplicity I'll assume there are 4 intents
(Loyality-Define - which has examples related to what is the loyalty program)
(Loyality-Join - which has examples related to how to join loyalty program)
(Saving-Define - which has examples related to what is the saving program)
(Saving-Join - which has examples related to how to join saving program)
so users can start the conversation by utterance like "tell me about the loyalty program". then they will ask "how to join" (without mentioning the program assuming that the bot is aware). In that case Watson will identify 2 intents (Loyalty-Join, Saving-Join) and Saving-Join intent may have a higher confidence.
so I need to intercept the dialogue (may be be creating a parent node to check the context and based on that will filter-about the wrong intents).
I couldn't find a way to write code in the dialogue to check the context and modify the intents array so I want to ask about the best practice to do that.
You can't edit the intents object, so it makes what you want to do tricky but not impossible.
In your answer node, add a context variable like $topic. You fill this with a term that will denote the topic.
Then if the users question is not answered, you can check for the topic context and add that to a new context variable. This new variable is then picked up by the application layer to re-ask the question.
Example:
User: tell me about the loyalty program
WA-> Found #Loyality-Define
Set $topic to "loyalty"
Return answer.
User: how to join
WA-> No intent found.
$topic is not blank.
Set $reask to "$topic !! how to join"
APP-> $reask is set.
Ask question "loyalty !! how to join"
Clear $reask and $topic
WA-> Found #Loyalty-join
$topic set to "loyalty"
Return answer
Now in the last situation, if even with the loaded question it is not found, clearing the $topic stops it looping.
The other thing to be aware is that if a user changes topic you must either set the topic or clear it. To prevent it picking the old topics.
NOTE: The question was changed so it is technically a different question. Leaving previous answer below
You can use the intents[] object to analyse the returning the results.
So you can check the confidence difference between the first intent and second intent. If they fall inside a certain range, then you can take action.
Example condition:
intents[0] > 0.24 && intents.[1] - intents[0] > 0.05
This checks if two intents are within 5% of each other. The threshold of 0.24 is to ignore the second intent as it will likely fall below 0.2 which normally means the intent should not be actioned on.
You may want to play with this threshold.
Just to explain why you do this. Look at these two charts. The first one it's clear there is only one question asked. The second chart shows that the two intents are close together.
To take actual action, it's best to have a closed folder (condition = false). In that folder you look for matching intents[1]. This will lower the complexity within the dialog.
If you want something more complex, you can do k-means at the application layer. Then pass back the second intent at the application layer to have the dialog logic take action. There is an example here.
Watson Assistant Plus also does this automatically with the Disambiguation feature.
You can train Watson Assistant to respond accordingly. In the tool where you work on the skill click on the User conversations page in the navigation bar. In the message overview you would need to identify those that have been answered incorrectly and then specify the correct intent. Watson Assistant will pick that up, retrain and then hopefully answer correctly.
In addition, you could revisit how you define the intents. Are the examples like the real user messages? Could you provide more variations? What are the conflicts that make Watson Assistant pick the one, but not the other intent?
Added:
If you want Watson Assistant to "know" about the context, you could extract the current intent and store it as topic in a context variable. Then, if the "join" intent is detected, switch to the dialog node based on intent "join" and the specific topic. For that I would recommend to either have only one intent for "join program" or if really needed, put details about the specifics into the intent. Likely there is not much difference and you end up with just one intent.
This is a question related to designing command handling with Axon 4.
Let say I've a domain that model the concept of a Payment.
The actual payment will be done by an external Partner. I want to track it in my system via the following events: a Payment Request Was Issued followed by either
Partner Agreed the Payment or Partner Declined the Payment.
Every events issued by the command should be enrolled in the same database transaction.
What would be the best practice to actually call my partner in Axon 4 ?
Here's what I've done so far:
Have one command named RequestPaymentCommand
This command will be handled by a Payment Aggregate like this:
do some checks
apply the event PaymentRequestWasIssued
and then, call the external partner and given the result it will apply either PaymentAccepted or PaymentRefused
In this answer from stackoverflow, it is said that
All the data that you need to apply the event should normally be available in the command
With this statement in mind, I understand that I should create as much Commands as Events ? But In this case, what is the point of all theses commands ? Should I end up with something like:
My command RequestPaymentCommand will generate the PaymentRequestWasIssued event.
Then from somewhere I call my partner and then send another command (how to name it ?) that will generate the event given the result from the partner ?
The actual payment will be done by an external Partner
This means that your application is not the source of truth and it should not try to behave like one. This means that it should only observe what is happening in the remote system and possible react to remote events. To "observe" could mean to duplicate/copy the remote events in local databases, without modifications, just for cache reasons or for display reasons. Your system should not directly give other interpretations to these events, other than those given by their source.
After the remote events are copied locally, your system could react to them. This could mean that a Saga, after receives the Partner Agreed the Payment it sends a UnlockFeature command to a local Aggregate (see DDD).
With this statement in mind, I understand that I should create as much Commands as Events ? But In this case, what is the point of all theses commands ?
This is an indication that those are not your events: you should not emit them from your code; in the worst case you store them and react to them (in a Saga/Process manager). This means that you should discover the local business processes and model them as such: they react to events by sending commands.
I'm designing a MVVM application that does not use WPF or Silverlight. It will simply present web pages in HTML5, styled with CSS3.
The domain is a perfect case for using WF because it involves a number of activities in a long-running process. Specifically, I am tracking the progress of interactions with a customer over a 30 day period and that involves filling out various forms at points along the way, getting approvals from a supervisor at certain times, and making certain that the designated order of activities is followed and is executed correctly.
Each activity will normally be represented by a form on a view designed to capture the desired information at that step. Stated differently, the view that a user sees will be determined by where she is in the workflow at that moment.
My research so far has turned up examples where the workflow is used to execute business logic in accordance with the flowchart that defines it.
In my situation, I need for a user to login then pick up where she left off in the workflow (for example, some new external event has occurred and she needs to fill out the form for that or move forward in the workflow to that step.)
And I need to support the case where the supervisor logs in and can basically be presented with activities that need approval at that time.
So... it seems to me that a WF solution might be appropriate, but maybe the way I want to use it is inverted - like the cart pulling the horse so to speak.
I'd appreciate any insight that anyone here can offer.
Thanks - Steve
I have designed an app similar to yours, actually based on WPF, but the screens shown by the application are actually driven by workflows.
I use a task-based approach. I have some custom activities that create user tasks on a DB. There are different type of tasks, one for every different form type that the application supports. When the workflow reaches one of these special activities, the task is saved to DB and the WF goes idle (bookmark).
Once the user submits the form, the wf is resumed up to the point where another user task is reached and so on.
Tasks can be assigned to different users along the way (final user, supervisor, ..) and they have a pending tasks list where they can resume previous wf instances, etc.
Then, to generate user views (HTML5 forms in your case) you have to read the pending task and translate that into the corresponding form.
Hope you find it useful
We have a workflow based application where a given process move from one state to another state based on User action.Currently our requirement is to have UI displayed its current state and allow user to take next action steps.So my question is does generally server tells UI the next actions that can be taken or the UI should decide based on current action? This application is designed using RESTful webservices.
The server should provide the client the next allowed actions, also known as state transfers, using links. Those links should, at least, contain two pieces of information: URL and relationship. The relationship tells the client the meaning of the state transition, allowing to recognize what it will do. The URL only says where to locate the service.
Typically, a REST web service should be ignorant of client state. It should only provide the ability to retrieve and update data based on a specific url (you may want to read up on REST). If you are following these guidelines, then the UI should drive any logic regarding the state of a workflow or record.
The hypertext returned provides the next "possible" transitions in the form of 'links' to the "resources". The client/user selects the next transition.
REST APIs must be hypertext-driven may be a good read!