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.
Related
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.
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.
I am still a relative newcomer to Expression Engine as a developer and a user. I am faced with the problem that a lot of my knowledge is being passed to me by users who have found ways to accomplish tasks traditionally undertaken by developers (eg product libraries) by using the channels system.
What I wondered was what people's views are on when it is best to advise a client to use this and when not to.
Let me use an example, a client wants a system which had venues where events could take place. The previous developer had chosen to use the membership system for the venues and the channels system for the events and write some custom code to attempt to knit the two together, specifically because there are not enough hooks to accomplish some background automated tasks like looking up the long/lat of the address of a venue when it is created or updated.
I am picking up after someone else's work largely but its not their fault, it was the information they were given as they were also new to the system.
In any other project this would be a master-detail type setup, events belong to venues, i'd probably write 2 custom tables, editors in the admin area via modules and then use regular custom code in the pages to display and act upon the info - this way, I could control what's happening when a user hits submit.
However, the instigating party is a veteran user of Expression Engine and instructed the previous developer in the manner of "oh, just put it all in the channels and then there's this tag and that tag and so on".
So, am I missing the point or am I right that this does not fit the channels system and when should you use channels and when not?
Thanks friends.
This question is very hypothetical and every developer will give you a different answer as it all depends on the requirement and how that EE developer rolls.
Fundamentally ExpressionEngine allows you to approach builds in many ways, none are right and wrong, albeit some are easier, some harder, others just plain daft.
Basically Channels are groups of data "entries" - these can be anything. Using your example, venues could be one channel with fields created relevant to the subject (e.g. location, size, price, etc). And another channel for events with different fields (e.g. date, type, location).
Mostly anything can be slotted into a channel. But member details are best held within the native member functionality (although there is a commercial add-on that holds member data in a channel).
You reference the previous developers approach - this could be because they used a third-party add-on that required the data to be held separately to channels, or a lack of understanding on best approach. Or just because the developer decided to approach it that way! I suspect the last developer then associated a member (venue) to an entry (event) to link the event to the venue. Basic EE functionality allows for related entries which allows you to associate 1 entry with another (e.g. Event -> Venue), or using the excellent Playa add-on, so this approach is really not necessary.
Personally I would always store the data in channels, and people/members in the native membership functionality (e.g. admin, visitors to the site, customers, etc). I'd only build an add-on (utilising it's own tables/data) to store additional information if it was way outside what EE could store.
To answer your practical question (it's stretching the scope of what Stack Overflow questions are supposed be honestly): you should use a channel for Venues and channel for Events, and the Venue field in the Event entry is a "Related Entries" fieldtype linked to the Venues channel. That's the "standard" EE way, and the most similar to a traditional database schema.
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.