There's a crucial part in the process that says, the best place for the chatbot to learn is from real users, what if I already have that data, and would like to test the model on it.
Think of Interactive Learning, but in scale and possibly automated. Does such a feature already exist within RASA?
Think of Interactive Learning, but in scale and possibly automated.
Are you referring to something like reinforcement learning? Unfortunately something like that currently doesn't exist. Measuring the success of conversations is a tough problem (e.g. some users might give you positive feedback when the bot solved their problem, while others would simply leave the conversation). Something like external business metrics could do the trick (e.g. whether the user turned out buying something from you within the next 24h), but it's still hard. Another problem is that you probably want to have some degree of control over how your chatbot interacts with your users. Training the bot on user conversations without any double checking could potentially lead to problems (e.g. Microsoft once had an AI trained on Twitter data, which didn't turn out well).
Rasa is offering Rasa X for learning from real conversations. The community edition is a free, closed source product which helps you monitor and annotate real user conversations quickly.
Disclaimer: I am a software engineer working at Rasa.
Related
In context of my bachelor thesis it is my task to create a chatbot that will act as some kind of helpdesk. This means the chatbot will have to be able to interact with some external layers of code/API's. I hope this is enough context to answer my question.
Until now I've pretty much been working on the NLU component of my chatbot, which is now working pretty fine already. I'm ready for the next step which would be connecting this NLU to the next layer in the system that will further the process the intent and entities, do some auxillary stuff, and formulate a response base on what the original intent/entities were and what it got back from doing the auxillary stuff (which will be interacting with the API).
I've read up on RASA Core and I know what it does. It'll train a model given some example conversations and use that model to guess which actions it should perform or which response it should give based on the intent/entities it receives. To me this seems like something I would like to use, however my professor advised against this but he's not entirly sure. His opinion is that RASA core doesn't give us enough freedom to make the chatbot interact with those additional software layers/API's. This is where my questions come in:
Does using RASA Core make it more difficult to interact with other software layers/API's?
Is RASA Core essential to creating a chatbot or can you in a realistic fashion create one without using RASA Core (or another similar framework)? Especially since RASA Core seems to offer a lot of functionallity, mainly the fact it provides you with a framework that will make the chatbot know what to do and when. It seems difficult to do this by myself.
If I decide to not use it, what is best starting point to continue my project?
Since this is my first question on this forum I hope I didn't make my questions too long or confusion, if so let me know!
Hopefully someone will be able to shine some light on this situation.
Does using RASA Core make it more difficult to interact with other software layers/API's?
No. Rasa Core also follows an "API first" approach, which means everything should be accessible through the API.
Is RASA Core essential to creating a chatbot
If you are building a FAQ bot (question-answer pairs) then you might not need Core. But if actually want to build a bot which understands some context, and acts differently based on the history of the conversation, then you should use Rasa Core. Also, Rasa Core includes support for several channels (Slack, Socket.io, Telegram, ...) out of the box, which should make it even easier to hook up your bot which different endpoints.
If I decide to not use it, what is best starting point to continue my project?
Probably the HTTP API of Rasa NLU, so that you can integrate the queries in your application. The Rasa blog also contains a lot of blog posts about NLU, e.g. the Rasa NLU in Depth series which might help you to understand the Rasa NLU better (link to part 1 of the series).
I am working on a family networking app for Android that enables family members to share their location and track location of others simultaneously. You can suppose that this app is similar with Life360 or Sygic Family Locator. At first, I determined to use a MBaaS and then I completed its coding by using Parse. However, I realized that although a user read and write geolocation data per minute (of course, in some cases geolocation data is sent less frequently), the request traffic exceeds my forward-looking expectations. For this reason, I want to develop a well-grounded system but I have some doubts about whether Parse can still do its duty if number of users increases to 100-500k.
Considering all these, I am looking for an alternative method/service to set such a system. I think using a backend service like Parse is a moderate solution but not the best one. What are the possible ways to achieve this from bad to good? To exemplify, one of my friends say that I can use Sinch which is an instant messaging service in background between users that set the price considering number of active users. Nevertheless, it sounds weird to me, I have never seen such a usage of an instant messaging service as he said.
Your comments and suggestions will be highly appreciated. Thank you in advance.
Well sinch wouldn't handle location updates or storing of location data, that would be parse you are asking about.
And since you implied that the requests would be to much for your username maybe I wrongly assumed price was the problem with parse.
But to answer your question about sending location data I would probably throttle it if I where you to aile or so. No need for family members to know down to the feet in realtime. if there is a need for that I would probably inement a request method instead and ask the user for location when someone is interested.
Recently I have been looking into the development of social networks and I often find references to pump.io. There is however very limited information available on what pump.io actually is. The official website says nothing more than: "It's a stream server that does most of what people really want from a social network." I found some more information on this website (http://slid.es/evanp/understanding-pumpio/fullscreen#/) but that still doesn't say a lot to me.
Could someone please provide an elaborate discussion on what pump.io actually is (and does) to someone who does not know anything about (activity) stream servers? Maybe the better question is: "What is an activity stream server?"
Yeah, the term is one a lot of people are unfamiliar with and it makes a couple of distinctions that aren't immediately obvious even if you use and post to a pump.io site.
pump.io, as it is distributed, is really two programs with different sets of functions. One is the Activity Stream Server and the other is the Web Client.
At the risk of being pedantic, let me define each of the words. I know you know what the words mean, but I hope the specific contexts/usage will help:
Server: a program which distributes information (usually) across a
network.
Stream: a (usually) chronological series of some sorts of pieces of information.
Activity: a description or depiction of something someone is doing.
The Activity Stream Server is a program which distributes (server) a chronological series (stream) of posts about stuff people do (activities).
The distinction is important because the website part of a pump.io website is a client for the pump server—essentially no different from a desktop or smartphone pump.io client. It listens to the pump's stream of posts and sends new posts to the pump using the same API and data formats that standalone applications—or other pumps—do.
You could actually totally decouple the Web Client and have a fully-functioning pump.io instance without any website. Users on other pump sites could see your posts and you could see theirs, and you could comment back and forth. It would make no difference.
ActivityStream is a JSON-based data format to describe "activities". The specification of ActivityStream 2.0 can be found at https://www.w3.org/TR/activitystreams-core/ and the vocabulary of activities at https://www.w3.org/TR/activitystreams-vocabulary/. To get the feeling of how the data format looks like you can have a look at the few examples at https://www.w3.org/TR/activitystreams-core/#examples. More examples can be found throughout the two specifications.
pump.io is an activity stream server that does most of what people
really want a social network server to do.
That's a pretty packed sentence, I understand, but I can try to unwind
it a little.
"Activities" are the things we do in our on-line or off-line
life—waking up in the morning, going for a run, tasting a beer,
uploading a photo, adding a friend, eating a burrito, joining a group,
liking a blog post.
pump.io uses a simple JSON format to represent all these kinds of
activities and many more. It organizes activities into streams—time
ordered lists of activities, with the newest first. Most streams are
organized by theme, like: all the things that my friends did, or all
the things that I did, or all the things anyone has done to this
picture.
Programmers use a simple API to connect to a pump.io server and add
new activities. pump.io automatically organizes the activities into
streams and makes sure the activities get to the people who are
interested in them.
And, really, that's what we want from a social network
Behrenshausen, B. (2013). 'Interview with Evan Prodromou, lead developer of pump.io'. Retrieved from: https://opensource.com/life/13/7/pump-io
If you peer a few centimeters down the page on the official website, you'll see:
What's it for? I post something and my followers see it. That's the
rough idea behind the pump.
There's an API defined in the API.md file. It uses activitystrea.ms
JSON as the main data and command format.
You can post almost anything that can be represented with activity
streams -- short or long text, bookmarks, images, video, audio,
events, geo checkins. You can follow friends, create lists of people,
and so on.
The software is useful for at least these scenarios:
Mobile-first social networking
Activity stream functionality for an existing app
Experimenting with social software
Those last 3 items hopefully answer your question.
Currently, you can:
install the nodejs-based pump.io server
(or) sign up for an account on a public service
post notes and pictures with configurable permissions
log in to web and client applications using your webfinger ID
At the risk of sounding misinformed, I'm under the belief that this is basically useful for RAD and fast sketching of an application.
It feels somewhat Ruby-esque in the sense that it scaffolds pretty much everything you need from a CRUD application. Easier work for us, right; and most people are none the wiser.
I'm fairly green in the workplace, I just start working at an actual job as a developer (cubicles and free coffee) so my opinions might be a bit on the green side, but I'd love some comments from more senior people.
Is this somewhere between MVC2(basic scaffolding) and Microsoft Lightswitch(wizard-driven development)? Is it worth ivesting in?
Personally I like to use Dynamic Data for admin pages, those pages that nobody actually gets to see but need to be there in a usable way for some admin user. In the past those used to take quite some effort on the dev team to craft together but with Dynamic Data it's an almost out of the box experience.
I suggest you take a look at Tailspin travel which is an application in MVC 2 but uses Dynamic Data, integrated in the same UI project, for the admin side.
I was skeptical at first, but now I use Dynamic Data almost as much as I do "standard" ASP.NET sites. Out of the box, it's pretty generic, but it's customizable, and you can include standard ASP.NET pages in it.
At first, I would use it as a separate Admin site when I needed a "back door" into the data from a "standard" app. Lately, however, my approach has been to do some more planning, and decide which of the tables I would like users to access via the Dynamic Data mechanisms, and which data I want more fine control over. You can scaffold only the table you want, and this works good for "lookup" tables where you want an end user to be able to add/delete. An example would be in our email coupon program, where customers can sign up to receive coupons via email. They can choose their coupon categories - hot foods, beverages, gas, produce, etc. The administrator of the overall coupon program needs to be able to add and remove categories, and Dynamic Data is WONDERFUL for this sort of thing.
Dynamic data takes care of the data validation (a huge plus for security AND usability), mapping our relationships (a HUGE time saver) and just "does it right". In the business environment, security and productivity are two very real concerns that are handled poorly by most developers, and Dynamic Data seems to handle the basics well.
So yes, I do think it's worth it. It's very powerful and an excellent tool to have in your toolbox, but one that should be wielded with skill, which takes time and practice. And it should not be the only tool in your toolbox.
One of the best uses I've heard for Dynamic Data was to quickly build up an Django-like admin section for a site. It doesn't have to be "perfect" since it isn't aimed at users, but it does give you some nice usability quickly and easily.
I know very little about it but it doesn't sounds like something I would consider. Whenever I work on a an application we tend to follow some basic architectural guidelines such as layering/reusability etc. Typically I tend to get away from shortcut tools/frameworks as this one. There are a lot of "neat" tools that are available in the .NET world that have their place in certain small business/internal app space perhaps, but are not a great idea for a well designed application. For example embedding SQL into the datasource controls that can be bound directly to GridViews, etc.
I am looking to get some outside eyes to do black-box testing on a simple webform-based experiment/game I made. uTest looks very good, but it's aimed at companies with lots of cash, whereas my app is just a small-time academic research project. I want to make sure that my app won't break easily, and that it's resistant against basic reverse engineering/manipulation. This is not a mission critical project, since there are no financial transactions or exchanges of confidential data taking place. However, I might eventually give out small prizes to people based on their scores, and I don't want cheaters to come out ahead.
Any suggestions for affordable black box testing?
You could try Chorizo. It's free for one host. It's primarily aimed at PHP apps but you can use it to test any kind of website for XSS and similar vulnerabilities. Just requires you to verify that you are the owner and then you setup a proxy and start browsing.