Building a chatbot on Facebook Messenger with Ruby on Rails
tutorials.botsfloor.com
tutorials.botsfloor.com
I really like Rails, but I get a bit annoyed when people use it everywhere even where it is not a good fit e.g. no need of activerecord, no server side templates or other 70% of Rails feature set, it is all just there adding to bloat without any usage.
Go is a language not an application framework. So that's not a fair comparison.
You get a lot of nice things right out of the box with Rails so it's a good choice for many projects.
Node isn't a framework or a language, it's a runtime environment. You'd still have to write a Javascript application.
With Rails you get rapid development speed and you can just use the pieces you want.
You could argue that writing this sort of app in Swift is a good choice as well.
As far as bloat.. what's the actual consequence? A slightly bigger deployment? It's negligible in terms of real world consequences and offset by the convenience of Rails conventions.
And if you're more interested in the thought process behind, we did a presentation of what led us to this architecture https://docs.google.com/presentation/d/1kGiHfMMjf-OL7ZUODttu...
If you have any question or feedback they're very welcome :-)
I've done my own Raspberry "bot" using speak synthesizer and STT and some basic plain ruby. Using regexp it handles _a_lot_ of scenarios just by simple regexp for words such as "rain", "weather" (which then is enough to understand that I'm asking for the weather). Combined with "today" or "tomorrow" it can tell weather at different times.
I was also intrigued by using api.ai in my case but It just felt overkill.
(Perhaps I've just missed the whole point here).
I keep hearing this question a lot, and I think right now the best way to teach chatbot programming seems to be by using the simplest examples and this is a little misleading (is that all?). You can use regexp to build out a chatbot, but it might be a good idea to consider some pros/cons of using a service like API.AI.
Under the hood, API.AI (and similar bot programming frameworks) allow you to go much further:
1. Their entity matching system will let you start with a few examples and then keep matching many more similar examples (remember Google Sets?) without you explicitly defining every single one of them. The best example for this seems to be the food/recipe & geographical locations stuff for now, but if they can get it right for more domains that can be quite useful.
2. There is a way to use templated definitions of "here is what the user might say" which is quite powerful. Sure, you could probably do the same yourself, but think about it: you will be handling so many corner cases with such a system that if there were a prebuilt service already doing that work for you (and which is improving quite rapidly) you could probably build it out faster with the external service.
3. There is also enough flexibility where you can add webhooks (like the author has done) and basically put a lot of business logic into your chatbot.
4. Assuming API.AI will soon be acquiring some of the ML knowledge which Google already has, it is reasonable to expect that the intent mapping (the process of figuring out what the user said) will only keep getting better.
Having said that, here are some advantages of rolling out your own:
1. You don't typically get the full picture of what is going on under the hood with an external service. Unlike the case where you write your own code, this means when things fail (and they will), you sometimes don't know what is the cause, and worse, how to get around it.
2. There is always the inherent risk that the service you rely on might shut down some day :-(
3. The current tooling around moving your chatbot from staging to production in API.AI is fraught with risk. I don't know if it is the same with the other ones too. If you roll out your own chatbot, you don't have such issues.
4. There are also some features which have been added to API.AI which are sort of all or nothing. A good example is the small-talk feature which you can import into an agent. The trouble is, you cannot really customize it much, so when it doesn't give you the behavior you expect, it can become a bit of a liability.
Hope that helps!
I feel that realizing a chatbot - in a specific programming language, - with a standard framework (Rails), - for a specific channel (Messenger), is an ERROR, in the log terms.
BTW, I realized naif, my personal micro framework just to build chatbots in Ruby (see slides: https://github.com/solyaris/naif),
Nevertheless, I decided to NOT publish the code and no more deepen that "hard-coded" way, instead I suggest to use and support a chatbot scripting (meta)language. About rationales, I wrote a bunch of articles: www.medium.com/@solyarisoftware
I support opensource great ChatScript (https://github.com/bwilcox-1234/ChatScript/) and BTW I wrote simple client in Ruby (https://github.com/solyaris/rChatScript/)
My two cents giorgio @solyarisoftware
Firstly, their libraries feel incomplete. 2 months ago I tried their nodejs one, and after some frustration, I ended up wrapping their REST calls. Last week I was working with someone new on our team, and we tried the Python one [0], again a mess, and we ended up wrapping the API around Python requests.
There is little activity on GH given that there might be other people having similar issues.
Webhooks are a take-it-all-or-leave it IMHO. When invoking a webhook call from an action, you can only respond once (i.e. no follow-up through api.ai). My conclusion from this part was that you can't build a serious (are they ever) bot relying solely on api.ai, and you have to do some heavy lifting on your server side.
What I have appreciated so far is their NLP part, it's hard (or impossible for some of us without the knowledge) to roll our own NLP solution, so I can give them props over making that part easy.
I'll keep using it as I'm training our team using api.ai, but if there are "better" solutions that other people have tried, I'd be keen on hearing their experiences.
I feel that realizing a chatbot
- in a standard programming language (Ruby),
- with a standard framework (Rails),
- for a specific channel (Messenger),
is an ERROR, in the long terms.
BTW, I realized naif, my personal micro framework just to build chatbots in Ruby (see slides: https://github.com/solyaris/naif), nevertheless, I decided to NOT publish the code and no more deepen what I call the "hard-coded" way,
instead I suggest to use and support a chatbot scripting (meta)language. About rationales, I wrote a bunch of articles: www.medium.com/@solyarisoftware
I support opensource great ChatScript (https://github.com/bwilcox-1234/ChatScript/) and BTW I wrote simple client in Ruby (https://github.com/solyaris/rChatScript/)
My two cents
giorgio @solyarisoftware
For the users the advantage is that they don't have to install anything. The disadvantage is that it's a more crude UI than a full fledged app or a modern mobile website but that can be hidden by a good design.
However a conversational UI mostly flows in time with little memory (scrolling and searching are possible but not user friendly), whilst apps/desktop/websites mostly spread in a 2D space. The design of the interaction is very different. Just try some mockup tools for chatbots and you'll find it out quickly.
There are advantages for developers too: it's easier to develop a chatbot than an app (unless you go very deep in AI), as much as it was to develop a web app than a desktop one. It costs less, it delivers earlier, it can be updated 100 times per day without app store approvals.
Edit: s/full fledged API/full fledged app/
1- Being where your customers are. If you are planning on leveraging a chatbot as opposed to a mobile app or website, having some kind of presence of Facebook messenger could increase user engagement because of the lower amount of friction from switching or downloading new apps to interact with a business. It's especially relevant when you consider that social platforms are used for customer support more and more so augmenting this channel with some kind of automated support option makes sense from an ROI perspective.
2. Simpler user experiences. Now this one is definitely idealistic, and where a lot of hype is coming from. But, the general idea is to take websites and mobile apps and create a single interface into the content/services where the hope is that users will have a lower learning curve because they can use everyday language. In reality, bots that I've seen are mostly text based IVRs that confuse the users, and don't make experiences any more enjoyable.
3. Personalization and NL analytics. Assuming your chatbot allows for free form text. You could potentially build more comprehensive profiles of users by mining their conversations and behavior. You could certainly do this today with web and app metrics, twitter posts, support emails, and transcribed voice calls, but now you have a Facebook or social profile tied to a customer which is another dimension of data you can use where in the past you may have had no linkage between your app accounts vs a users social profile.
By no means a comprehensive list, and if you incorporate voice recognition on top of a "chatbot", you can provide an easier way for users to interact with systems when they may not be able to use their hands (driving, lost an appliance remote, running)
Some example - I am using Poncho bot that sends me weather update every day in morning and evening. So that way I don't need to install other app or need to open site and check everytime.
Same way, Machaoo bot sends me match score update on a regular interval.