I am developing a bot with Dialogflow. Sometimes, the user may diverge from conversation and ask small talk. However, when this activates a small talk intent, some contexts may expire. How can I activate a small intent, but keep the previous activated intents at their same lifespan?
Thank you
each context has a lifespan which determines after how many matched intents the context disappears. The default value is 5.
A possible solution is to set the context lifespan to a higher value, it does not seem possible to make a given context lifespan independent from the others.
You can set the lifespan in the DialogFlow UI or via the webhook, but be aware that it will anyway expire after 20 min.
Related
Newer developer here. I'm creating a Nodejs application with MongoDB. When do you write user inputs to the database? Is it immediately when they want to perform a CRUD action? Or do you wait until they end their session to update their changes (showing them a "fake" updated view during the meantime)? I would think writing to the database every time would be less than ideal, but I also wouldn't want to make the user think their changes were saved to the database, and then some error occurs where it didn't actually happen. How's this handled in the real world?
The user inputs should be written to the database as soon as the user wants to perform the CRUD operations.
If they are not, and you wait for the user to terminate their session, there may be other parts of the application that try and change the data that was supposed to be updated. Or you may want to take certain action in your application based on the current user data from the database, but your database reflects older data, and your application may behave incorrectly.
One may argue that you can maintain the current state of your application, but in case of backend code, the database should always be your single source of thruth.
This is what's known in the "real world" (as you referred to) as a design decision. It's not something for which there's anything even remotely resembling a rule-of-thumb or a hard-and-fast rule.
Instead, it's important to consider all possible factors relating to this design prior to committing to it:
User expectations - will the users of this application expect that their input is stored immediately? When they click the "Save" button? Do they expect their input to be destroyed?
Data retention - are there requirements to retain user input prior to its formal submission? (This is useful in applications for which
Infrastructure - can the underlying infrastructure handle the increased workload? When this application is scaled, will the infrastructure demands exceed capacity?
Cost/benefit - will the addition of this feature trigger development/testing times that exceed acceptable levels for the benefit the feature provides?
These are just some of the considerations you might have. I'm sure with additional time most people could come up with at least ten more.
I'm using Google Dialogflow (former API.ai) with one agent, and I would like to be able to handle queries for many different customers with one agent.
The reason behind this is that I simply can't create one new GCD project / agent for each customer, due to the overhead and the quota limits on GCD projects.
I am looking for suggestions on tackling this. I am afraid that Dialogflow's algorithm will be cluttered and start confusing intents if I add too many of them that are closely related. I would like the agent to only go through the customer's list of intents and not the whole list of intents.
At the same time, I have common Small Talk intents that should be shared between clients. This means that setting the context as the client's ID may not be a fully viable solution, because the common pool of intents will not be used then.
To sum up, there are:
Common intents, shared between all clients (small talk for instance)
Client-specific intents (for instance, "What is [client-specific acronym]?")
How can I identify my user's (attached to one client) intent (ideally in a single request) given this set-up?
Thank you.
What you're doing is probably sufficient for simple agents.
For more complicated agents, you might want to identify the client in the webhook for the first Intent (which you certainly have to do anyway) and then set a long-lived context for just that client. Then you can have other Intents which are tailored for the client and only get triggered if the context is present. To be clear, and quoting the documentation:
Input contexts limit intents to be matched only when certain contexts are set.
If you have components of the conversation that apply to all of them (small talk, common questions about using the service, etc) then you could make those versions not require a Context. If you have fulfillment for them, you'll still get any Contexts (and their parameters) that are active, so you can handle with client-specific information still.
Finally, however - you shouldn't worry too much about how many projects you have. If you get close to the limit, you can request a higher quota.
Can wit.ai, api.ai etc. generate its own conversations by training or are every conversation static structured by stories the "bot" owner created ?
Im in the search for a botting tool that can generate conversations based on what it has learned, and the more conversations it has the better it gets to replying to users, where human-like hour long conversations could be a possibility.
I've looked at wit.ai, api.ai and others like it, but they seem to be based upon stories which typically ends up into some command-like stuff, like ordering a pizza. Though they can be made to remember who they speak to and other entity information.
Do i have to structure a hundred of stories or is it possible to just make a base and make it learn from there, and perhaps add more stories in the future based upon old conversations to make it smarter. ?
There are many parts to the answer.
On the one hand, there is Mitsuku, which probably comes closest to what you are aspiring to. From what I understand, Mitsuku has been built over a long time using plenty of hand coded rules - a bit like the hundreds of stories you are talking about. There isn't a Mitsuku-as-a-service that I know of, at least not yet.
On the other hand, there are bot building frameworks like api.ai, wit.ai and others which are using machine learning to effectively do two main things - intent mapping (what is the subject the user is talking about) and entity extraction (mentions of proper nouns). In combination, it can be quite helpful for task oriented chatbots but not sufficient for the kind of truly conversational chatbots you are trying to build.
I would also encourage you to check out the following YouTube video, specifically the segment where the presenter talks about generative vs retrieval based chatbots.
https://youtu.be/SvV57fuL_M0?t=202
Also, api.ai also has something called "prebuilt domains", which have knowledge about a few domains. There is a "small talk" domain included, but if you look under the hood, it basically expects the bot programmer to fill out a questionnaire which goes from 0% to 100% complete based on usual expected questions.
You also ask about using history to make your bot smarter. If you are prepared to go through the chat logs, bot building frameworks such as API.AI allow you to start with something narrow and go on to make a pretty interesting bot by doing training (hard to explain, take a look at their interface). But this also means a) you are willing to spend a good amount of time improving the bot and b) you can actually drive enough traffic to your bot to field a wide range of questions.
Its my view that there is quite a lot of hype as to what chatbots can do. I think they are quite useful, but they are hardly conversational in the way humans think of conversations.
I am making a game with Google Hangout where I need to control which participant could communicate with others.
I want to be sure that players could not change the list of participant he could see by calling a javascript function. Because from what I understand each participant could change his visibility of other participants, and I want to block that.
So I wonder if it is possible to control the visibility between participants at server-side.
Short answer: No.
Medium answer: It really depends exactly what you need, but probably not.
Much longer answer:
It sounds like you want finer grained control over both visibility and message sending/state sharing than the Hangout API allows for. The Hangout API reflects what participants can see in the actual hangout today - everyone else who is in the hangout. The shared state is shared with all other members of the hangout running the same app, and the visibility is for all users in the hangout or the same app.
If you want to restrict or limit this (for example, if people are divided into teams and you want a "team chat"), you would need to use your own server to coordinate this communication, on at least some level. Your server would either need to actually do the communication between team members, or distribute a shared secret that each team would use as a cypher for their shared state.
One possible trickier solution might be to have each team run a different app. Since each app only shares state with the same app running on another participants machine, and can list only the other members who are running the same app, this might be a valid solution in some cases.
In my domain, I have 2 bounded contexts that are relevant to this question:
Purchasing - where the customer orders services
Fulfillment - where services are assigned to vendors to be completed
It's a requirement that an order is editable by the customer at any given time throughout the life of the order.
If a customer removes a service from an order (i.e. within the purchasing context), if that service has already been assigned to a vendor to be performed (but has not already been performed) that service must also be removed in the fulfillment context.
There's a couple of options here, and I'd like the community's opinion:
I have my contexts wrong because this will create a cross-context transaction.
I may not need transactional consistency here. Of course, that's for the business stakeholder to decide, which begs 2 questions: What are the implementation options? How do I pose this question to the business stakeholder?
This is an acceptable violation of the "no cross-context transactions" rule.
EDIT
This is all happening within a single process, so the likelihood of mid-transaction failure is very low.
Here's the question to ask your stakeholder, re: an order being editable at all times - what does it mean for an order to be edited after it has already been fulfilled?
Why is it necessary that when an order is edited, this impacts the fulfillment service?
This, in my mind, crosses the bounded contexts. An order, while being edited, should not leave its domain unless there is good reason to. Why would any order information be propagated to the fulfillment service before it is complete?
Based on my obviously very limited understanding of your domain, I would think that you would complete the order first, then send a creation event to the service bus, where it is picked up by the fulfillment service. Therefore, no transactions are taking place that cross contexts.