This could be a huge deal. Hopefully, a general purpose bot API based on JSON/etc is defined by W3C. In near future, bots will do a lot of time consuming daily tasks, that at the moment you do yourself using the web browser. I would rather not vendor-lock in myself. (sure natural language can be used, but general purpose API that allows bots to exchange each other would be more useful)
Maybe it's time the W3C was replaced by a W3CO bot.
But yes - standards for this space would be a huge benefit.
I'm pretty impressed by the new Microsoft. I'm still concerned about cost/stability/support, but it's been a while since Microsoft did something that made me think it was worth a serious look - and bots, cognitive, and Wubuntu definitely are.
I think it made for a very strong and touching point when Nadella said they want technology to bring the best of people, not the worst. So they were able to use it in a way, even if it didn't go exactly as planned.
I don't think so, at least, not exactly. I suspect that Tay is more designed to help with NLP, and specifically to improve the understanding of how younger generations are speaking and writing, and to more quickly adapt to changes in languages.
I do think that Microsoft will continue experimenting with Tay (and other bots) and will use the data to enhance both Cortana and their other ML services, which would obviously benefit this bot framework.
This is amazing news, and I'm really excited for the innovation this is going to bring to the bot space.
As an alternative to this closed approach, I've been building an MIT-licensed bot framework using Golang, enabling anyone to build advanced AI bots. The API we've built seems to be a lot more robust than what Microsoft showed today. https://github.com/itsabot/abot
It's still very early (too early for a ShowHN), but there's tons of documentation and guides if you wanted to get your hands dirty before we do a proper release.
A few key reasons, off the top of my head as to why we chose Go:
1. It's fast and resource efficient.
2. It's easy to cross-compile and deploy with a single binary and no external VM dependencies.
3. It offers static typing and compile-time checks, which massively reduce development time for me.
4. As Abot is a framework with downloadable plugins, Go's tooling handles most of the heavy lifting for us, like downloading and updating dependencies. Go's automated testing, linting, and formatting are really nice as well, and it's great to have those built into the language itself so there's standardization across an ecosystem of plugins.
While not one of the core reasons, I really like the Go community and the language (generics be damned). This is a personal, spare-time project, so my preference of working in the Go language definitely did factor in.
I very much admire and appreciate the work you've done bootstrapping Abot in your spare time. Now that Microsoft is in the game, my concern is we will see a "tower of babel" type of situation develop for bots emanating from the corporate behemoths (i.e., here come the Facebook bots, Google bots, Amazon of course, and Apple might play catch up too at WWDC). I much prefer grass roots growing from open source projects like Abot so as to no be locked in (financially, legally, cognitively) to one platform run by a large corporation seeking world domination.
Forensics specialist Jonathan Zdziarski wrote an interesting post recently titled "Free Software Always Costs Something" it is a good read -> http://www.zdziarski.com/blog/?p=5948
Perhaps Abot would benefit from having its own Foundation similar to the likes of, say, the Apache Software Foundation https://www.apache.org/ ... "The Apache Software Foundation provides support for the Apache Community of open-source software projects, which provide software products for the public good."
As Satya Nadella commented in this recent Bloomberg interview http://www.bloomberg.com/features/2016-microsoft-future-ai-c... how app stores and Facebook remind him of the walled gardens of 25 years ago (e.g., AOL and CompuServe), its what he didn't say (intentionally omitted?) in this interview which strikes me as more interesting. The rise of chat bots and Nadella's views about them remind me somewhat of the vision General Magic had precisely 25 years ago with their forward thinking ideas about personal digital agents and Telescript https://en.wikipedia.org/wiki/General_Magic ... if Nadella has indeed channeled some of the old ideas of 25 years ago and chat bots are to become the next big thing (Nadella thinks chat bots could be as big or bigger than the Internet itself, and the next logical step after app stores), and if indeed its time to break down walled gardens, then it would probably be very important for an implementation of chat bots to be a part of the global commons and available to all of humanity. Abot to the rescue?
Thank you for the interesting comment. I share Satya's belief that these bots may very well become one of the most important technological innovations in our lives.
I'm very open to building a Foundation around this. My goal for Abot is to make it self-sustainable (paying salaries for key people to enable full-time development) and owned by everyone.
I admire the Apache Software Foundation for all the work they've done and can see a similar path forward with Abot. But recall that 24 hours ago it was really just me working on this. Give me another day or two :)
Why the downvotes? The bots Microsoft demonstrated today are tied to the Skype client, which is a closed ecosystem. I'd much rather develop bots that are not locked into a closed ecosystem, and can function across any chat provider that supports XMPP.
Dunno, but I winced at "in the bot space". I hate anything that smells of marketing/management speak. Going forward/we reached out... just use normal language like a normal person.
Haven't had a chance to watch yet, was this integrating into consumer-grade Skype, or Office 365 Skype for business? The latter would be huge - I've been banging my head around the lack of openness there for years now, and at this point, anything would be an improvement on the crazy stuff I've been doing.
While the SDK is open source (in the sense that you can read the source code), Microsoft isn't actively accepting significant contributions according to their Contributing.md, which is somewhat disappointing.
Any bots you build on Microsoft's framework as far as I can tell are also locked into a closed Microsoft-controlled system. Just because it's readable on Github and pushes messages to Slack doesn't really mean that it's open-source in the way we've come to expect from Linux, etc.
Perception is important as always: being perceived as "open source" is now vogue and seems to be more of a marketing function for large corporate behemoths (most mere mortals have no idea what a "pull request" is but the term "open source" seems to have become more mainstream in recent years).
In their defense, if 100 or so Open Source projects where they (MSFT) accept PR does not convince you, I do not know what will. In this particular project, it could, that core group wants a level quality or functionality or other benchmarks before opening up for PR. It was done before, source was Open Source and incrementally when the core team felt comfortable started accepting Pull requests.
I can see your point, but this isn't the case for Microsoft. This framework may be not accepting PR's yet, but just like the other 100+ repositories that do, I'm sure this will join shortly.
Looks like Contributing.md was updated 35 minutes ago to "BotBuilder is currently accepting contributions in the form of bug fixes and new features ..." (Significant contributions still require a CLA/CYA, but that's not uncommon.)
If the license allows you to freely read, modify, and distribute the source, it's open source. If we add "upstream welcomes your contributions" as another criterion, that would disqualify a lot of open source projects including all of the abandoned projects out there.
The Linux kernel is most certainly open source but their criteria to accept contributions is no more open than this or many other projects.
The maintainer(s) get(s) PR approval. Big features that change the direction of the tool are welcome in forks but require maintainers to agree if merged upstream.
What are you talking about? It's MIT licensed and their contribution policy says they do accept features if you sign their CLA (which is exactly the same thing Google and any other big companies do)
What closed Microsoft-controlled system? You can compile that code in either Mono or coreclr.
I get you're not happy Microsoft just released something in an area you've been working in, but this is just FUD.
This is really interesting hellcow. You've done an impressive amount of work on this.
I just wanted to ask about the intelligence built into the bot. I dug through the code a bit (great documentation btw) and it seems that this is using a state machine you've written and custom plugins for different scenarios. How would one account for situations were a case keyword in a plugin is used in a different context? Say for example, I ask "What street number did you say?" to the bot with this plugin^1. It seems that these are items that would trip it up?
Also these bots would not "learn" or get better over time without direct human input correct?
I hope these don't sound like critiques. They're not. Just generally curious about how all of this is put together - particularly the state machine and then also how the plugins can be built (and improved).
Great points. The restaurants plugin you cited is using an outdated API. The new API uses triggers rather than a switch statement, which requires a combination of a Command and an Object to trigger a plugin's response (see plugin_weather for the modern API). This helps eliminate many false positive matches. But to your point, you're right, that scenario would still trip it up. I plan to add support for matching on n-grams going forward, so you could define different behavior for "street number" vs "phone number" and it would match the longest (in most cases the most specific) option when multiple matches are detected. It's actually similar to how many routers work.
You're also right that Abot plugins as they stand now do not improve or learn automatically over time. I've done some work on a training system which will enable a Facebook M or Magic-style human-aided training backend. It'll be a plugin just like any other which will eventually be hooked up to a neural net with optional centralized training (so you don't need a GPU rig or tons of data to get started). An early version of that is probably going to be ready going into June with the v0.2 release.
Thanks so much for the feedback. I'd love to continue this discussion and find ways to improve plugins and training. If you're interested, there's a mailing list here: https://groups.google.com/forum/#!forum/abot-discussion
Thank you so much for your reply. I'll have a look at the plugin_weather and see how that one works.
Regarding the neural net, I think that's an important feature because the most difficult part about guessing triggers is, well, guessing. Our language is awfully diverse and I think you'll get better results in the long run.
I've applied for membership to the mailing list. I'll keep my questions there.
Awesome. Seems everyone is doing some sort of variation on this. I did something similar at the Launch Hackathon (http://devpost.com/software/sim) where the first use case is meeting scheduling. I'm currently trying to wrap up the website so people can start poking at it and then get the SDK going.
Thanks! We'll handle speech in a very similar way to how we handle SMS today.
There's an interface (shared/interface/sms) that defines the functions any SMS driver needs to implement, like `Send(to, msg)`. Then we have a Twilio driver that implements those functions, but you could easily write a Nexmo driver or a driver for any other service in the same way.
With speech recognition, we'll design an interface and build drivers for popular services, like Google's new speech recognition API. For the end user, that means you'll be able to pick and choose which service you'd like to use, and by adding it to your plugins.json, speech will be loaded up and handled automatically.
there are a massive amount of bot & chatbot conpanies and it is a fairly recent trend. Are we on the cusp of beating the turing test? the space is exploding
IBM is already selling an automated bot that can rplace a level I support questionaire by chat or voice and saw something similar in use (but not the IBM idk how well that works) so at least you get a real, compelling case for it and it is not just up in the air
Hmm, wonder why they aren't using it internally. IBM moves a lot of their internal helpdesk support through IM, but far as I know, there's real people on the other end of it, for all but the simplest cases.
from my experience every help desk question require a team just to find that one person which has the knowledge to answer, it'd be a haunting task to find all the bits around any products and place them in an actionable knowledge base XD
As it happens, I work on the Watson dialog service which is being used to make this and similar kinds of bots. IT support is just one of the use cases that we are working on.
It's not a terrible interface, it's just one of many interfaces that has great usage scenarios. You aren't going to draw a sketch with a gamepad controller. You aren't going to play Street Fighter with a stylus. Touchscreens provide a terrible experience for a large number of scenarios. Virtual reality headsets won't be desirable for everything.
Being able to just talk is one of the least physically demanding forms of input that can possibly be used and if the language can be understood accurately enough with a wide variety of computer solutions backing the responses, people will become comfortable with asking for those types of responses.
I didn't see anyone say it would be the only interface in the future, just that it would be one of many. Microsoft is saying you can write one application solution and expose a variety of interfaces. Use the keyboard and mouse when you're sitting at the desk with Outlook, or ask Cortana to do that for you if you're across the room or busy driving across town. Whatever is convenient.
We have already beaten the turing test multiple times, each time making the test more complicated than how it was originally designed. We have now moved on to the supposedly better chinese room test.
The turing test, if performed over the Internet, is absurdly easy to solve. Just write a bot that replies in a rude way, with bad grammar and spelling and use lots of Internet slang. The tester will conclude that it's a human idiot.
What Turing meant was being able to ask the bot things, like "what do you think of Angela Merkel’s stance in the refugee debate?" or ask the bot about economics, or philosophy – and the bot would answer.
Conversing with the bot, and doing it in a way where you receive answers that are meaningful, is a required part for intelligence.
The people you mentioned – if judged just by their online interactions – would not count as intelligent life.
My armchair theory as to why this is happening: it's driven mostly by developer needs. Although there are some interesting applications for chat interfaces, I think that the excitement is mostly hype. Developers jumped on this bandwagon because:
- mobile app delivery sucks (Apple and Google are not trying to make it better, Facebook and Microsoft are but there is only so much you can do when you don't own the platform)
- the web is still subpar for mobile and is not progressing fast enough
- developers (understandably) want to get back the practices that became popular in the Web 2.0 era: continuous delivery, a/b testing, etc
- running code on your own servers is much easier to develop, test, debug, and change
- UIs are still hard to build. Things are slowly getting better but it's very expensive to hire good Frontend engineers and designers and you need to laboriously create UIs for every possible interaction
- apps are too much of a commitment for users. Whether you are looking for something or just want to use something once you have to install an app and sign up for it just to try it. This app will then live on your home screen along with hundreds of other apps that you don't really use.
The recent advances in NLP and some AI techniques made it possible to create good chat interfaces. Which is a much better developer experience. It's still unclear whether it's the best possible user experience.
It's actually really funny, because before I saw a lot of this hitting the news, I was working on my own home automation system, and trying to figure out a quick temporary solution to reach it from the outside world, without developing client apps.
And I thought of email. A well standardized message queuing platform that could easily implement a basic text command interface. So I ended up with a rudimentary chat bot. (I could've done SMS, but didn't want to find and pay for a service for that.)
And a few weeks before this announcement, I'd been thinking about how to handle queries to my chat bot my software didn't understand, and I was thinking "Hey, I wonder if I could have my bot ask Cortana stuff if it doesn't know". And Microsoft's picked up and really ran with this model with Bot Framework.
Obviously they've been working on this behind the scenes for a while, I'm not trying to take credit for the concept by any stretch, but I thought it was funny that I had been thinking along those lines myself before I heard about this.
Good UI isn't hard. Generally, it's simple and universally understood. I instantly understood where Microsoft was going here because I had the same thoughts. That being said, I want my system running mostly locally/self-hosted, so an Azure-based platform like Bot Framework probably won't work for my own system, though I might very well send requests to other bots using it.
> Good UI isn't hard. Generally, it's simple and universally understood.
I have to strongly disagree with that, it might be easy to spot good UI but it is not normally easy to make a good UI.
As for SMS Twilio is dirt cheap $0.0075/message + $1/mo for a number also combining it with something like Wit.ai [0] to parse your text and you can get pretty far.
That's a monthly fee and a per message fee I don't have to pay because I'm using email. :) Also, I get to use a open standard, which is another big plus.
Had the same thought of using email as a queue, but for playing asynchronous games. Basically play-by-email, but you give the game login access to an email account and each email has a game id and an order id and it basically treats the email like a pipe.
I felt this was one of the few ways you could insure the game could still be played in perpetuity after a company had gone away and their servers shut down, without requiring people to host a dedicated server.
Obviously this wouldn't work with real time games, and players could potentially abuse the data being sent if you're not careful and/or don't encrypt the data, but I prefer making turn-based games anyway.
Having worked for several small companies that have shut down, that's a concern to me (although you can't even download most of those games anymore since they were taken off their respective app stores).
Exactly. If you need a way to send data across a network, queue it if your partner is unavailable, ideally make sure it works on a large number of platforms out of the box... Email is already there and it works.
I found it interesting Microsoft Garage made an "IM client" that uses email in the backend recently. In some cases, I think all these new protocols we invented was reinventing the wheel, when we already had something that worked fine.
Using it for games is a really neat idea. In a plaintext format, you could even space out things like a Scrabble board, using @ and & symbols for special blanks or such, and one user could be lower case letters, and the other could use capital letters. Dots for normal blanks.
Do you really know email protocols? I don't consider them simple.
For example take a look at the RFC 5322 and try to determine what is or isn't a valid address. You have a lot of weird edge cases to take in account and it's not always obvious how you are supposed to handle them.
If you need to support every possible way email can be sent and received (aka, you are building a generic email client), there is a lot of work you have to do.
However, if you are building a piece of software that simply communicates over email, you only have to support a relatively straightforward format for email that everyone else inherently supports.
Depending on the platform you're building on, a lot of the basics of actual email sending and receiving may be handled by the platform directly as well. I didn't have to write the SMTP handling for my code, for example, because the platform I was building my app on pretty much did it for me.
Also, the great thing about figuring out weird edge cases with email, is that email is such a widely used and universal protocol, there are literally millions of places on the Internet that have code for it or talk about it. There's a lot of resources out there.
Assuming I used python, I'd just import a library for sending email, or if using C# just import System.Net.Mail. Then it should be pretty simple. I would have made sure it worked for a major email provider (like gmail) and then work on edge cases when/if they came up.
Since the game would need your email password in order to load incoming messages I would advise them to create a new email just for game communication purposes anyway, and tell them not to use certain characters if for some reason I couldn't get them to work (although the libraries should be able to handle it anyway).
In fact, that's what I did for my SMTP. :) Though sadly, System.Net.Mail has no code for :receiving: mail, which is annoying. Also, System.Net.Mail doesn't work with Outlook.com, though it does work with Gmail (weird, right?).
Marketing, buy-in, monetizing Skype, and product placement: The field of AI is ridiculously hot. A Chatbot is the least complex AI to build, but it still qualifies as AI. Hence, if you want to join the hype, a chatbot is a reasonable start. With a few regular expressions and if-then rules you too can build Tay.ai (but only MS can get the press for it). Compare to Microsoft PopFly and Silverlight with rich media. [1] It's also possible that Google releases personal assistants for Google Business in the next few months, and MS picked up on that 6 months ago.
Competition: Facebook is building "M", a personal assistant-style personal assistant. Apple has Siri. Google has Google Now. And MS has Cortana.
Technology: Some (Weasel-word, but I don't want to list names) say that computer vision is now solved. Convnets can predict 1000-class problems with the same accuracy as humans. The deep learning field is now eating away at the fields of reinforcement learning, generative art, and NLP. Recent papers show that it is now possible to create a conversational bot without any hand-crafting of rules.
Military/defense: Both the AI/ML industry and academics are in bed with the military complex. We did not study convnets, to aid the blind, no, we studied convnets, so we could detect terrorists at the border or in public transit. The people working on guided missile systems in the previous generation are now working on unmanned aerial drones. People were interested in fooling convnets, not for the hell of it, but because it is dangerous when a turret mistakes a tank for a puppy. For NLP: DARPA and IARPA want better defense and intelligence technology. The systems to suck up all these global communications are in place, but it still relies on old "dumb" tech, like keyword-matching. It is not able to detect sarcasm, 1337-speak, or code words. That is a big driver behind the attempt to evolve NLP: Terrorists do not need encryption, when they can talk about butchering goats and get lost in the noise, and no one is the wiser.
The Turing-test will forever be a moving goal-post. Mimicking intelligence does not seem to be enough to call machines intelligent.
I wrote a blog post about this, but in summary, the most natural way for humans to communicate is through real time chat and people spend a lot of time in chat these days.
The answer is Slack. Slack is booming and garnering a ton of investment. Slack has a good bot interface and a zillion integrations, which only adds to the value.
As for why Microsoft is jumping in now? They have a Slack clone in the works. This bot framework is just laying the groundwork for duplicating one of the core reasons for Slack's success.
As for the Turing test, no, none of these bots come close. The frameworks make it easy to match simple text commands, but that's about it.
Chatbots are a way to integrate other services into WhatsApp/FB, Slack, etc. China's WeChat is setting the trend here [1]. You can do things like payments, online shopping, order a pizza/taxi/whatever with just a simple text message.
WhatsApp will be offering a paid API soon that will make Chatbots available within WhatsApp and thus make all the above possible.
As a result, messengers like WhatsApp will become a platform. Instead of having to install an app for every service you just add a contact to your messenger and text him what you want.
This combined with the 3 new bot management platforms showed from the latest YC batch makes me think I should start learning a bit more about bots... seems like they're coming pretty fast.
The return of text adventures! How is typing out a request any better than tapping a button? Isn't the magic of AI in predicting a button press, rather than making us write out or speak the request?
This is a very welcome development. The Bot Framework and Connector take care of lots of plumbing that bot developers otherwise would have to develop and run themselves and would (theoretically) allow developers focus on what their bots valuable.
All of this under MIT license - thank you, Microsoft!
Wow, amazing world progress, "hello world" has finally been deprecated in favor of YAPOD (yet another pizza ordering demo). Quick, someone ping Ray Kurzweil to alert him of the rise of pizza ordering chat bots comprised of hidden Markov models, for the Singularity is surely near ;-)
I'm still not sure what these Bot frameworks provide? Here the main point might be their natural language processing, but they don't elaborate on it much. What is an example of a useful bot that one could create with it? Assuming that I already know how to program something like ELIZA?
From the bot framework FAQ: "In order to provide the I/O service, the Bot Connector collects and stores your ID from the service you used to contact the bot. In turn the Bot Connector may additionally store anonymized conversation content for service improvement purposes."
Does this mean that MSFT is collecting the chat data to improve its natural language understanding models?
If you're into bots, but you aren't too keen into programming, there's this website http://cheapbotsdonequick.com/ that allows you to set up a bot, either for text or SVG rendering, rather quickly. It uses a framework called Tracery that implements a limited language that expands upon symbols to create procedurally generated texts.
This reminds me strongly of "agents" that were going to do your bidding, as prophesied in the early 90's. Here's video of Douglas Adams and Tim Baker giving a tour of the future. https://youtube.com/watch?v=1iAJPoc23-M
This is awesome, but I wonder how useful it would actually be to use. I imagine the functionality is going to be limited to only the features shared among each platform (which is just text messaging? Unless by SMS they mean MMS also).
The other problem I see with it is that they've implemented it in two languages simultaneously, but there's no common code between the two because there's no simple way to link the two languages together. I think a better solution might be to create this as a whole API layer over the other bots where you could gain:
- A single API key to keep track of, and they automatically handle keys for the other platforms
- Less connections to handle, just read all the messages from a single queue and tell the API which one you're replying to
- Common backend code that could be shared between both C# and TypeScript/Node, as well as other languages that could be added in the future. For example, Python, Perl, or Ruby are extremely popular for IRC/Slack/Telegram bots and it would be nice to have a common API for some of those languages.
137 comments
[ 2.9 ms ] story [ 195 ms ] threadHopefully other people jump in this game.
But yes - standards for this space would be a huge benefit.
I'm pretty impressed by the new Microsoft. I'm still concerned about cost/stability/support, but it's been a while since Microsoft did something that made me think it was worth a serious look - and bots, cognitive, and Wubuntu definitely are.
I do think that Microsoft will continue experimenting with Tay (and other bots) and will use the data to enhance both Cortana and their other ML services, which would obviously benefit this bot framework.
https://github.com/Microsoft/BotBuilder
https://nic.bot
As an alternative to this closed approach, I've been building an MIT-licensed bot framework using Golang, enabling anyone to build advanced AI bots. The API we've built seems to be a lot more robust than what Microsoft showed today. https://github.com/itsabot/abot
It's still very early (too early for a ShowHN), but there's tons of documentation and guides if you wanted to get your hands dirty before we do a proper release.
I very much admire and appreciate the work you've done bootstrapping Abot in your spare time. Now that Microsoft is in the game, my concern is we will see a "tower of babel" type of situation develop for bots emanating from the corporate behemoths (i.e., here come the Facebook bots, Google bots, Amazon of course, and Apple might play catch up too at WWDC). I much prefer grass roots growing from open source projects like Abot so as to no be locked in (financially, legally, cognitively) to one platform run by a large corporation seeking world domination.
Forensics specialist Jonathan Zdziarski wrote an interesting post recently titled "Free Software Always Costs Something" it is a good read -> http://www.zdziarski.com/blog/?p=5948
Perhaps Abot would benefit from having its own Foundation similar to the likes of, say, the Apache Software Foundation https://www.apache.org/ ... "The Apache Software Foundation provides support for the Apache Community of open-source software projects, which provide software products for the public good."
As Satya Nadella commented in this recent Bloomberg interview http://www.bloomberg.com/features/2016-microsoft-future-ai-c... how app stores and Facebook remind him of the walled gardens of 25 years ago (e.g., AOL and CompuServe), its what he didn't say (intentionally omitted?) in this interview which strikes me as more interesting. The rise of chat bots and Nadella's views about them remind me somewhat of the vision General Magic had precisely 25 years ago with their forward thinking ideas about personal digital agents and Telescript https://en.wikipedia.org/wiki/General_Magic ... if Nadella has indeed channeled some of the old ideas of 25 years ago and chat bots are to become the next big thing (Nadella thinks chat bots could be as big or bigger than the Internet itself, and the next logical step after app stores), and if indeed its time to break down walled gardens, then it would probably be very important for an implementation of chat bots to be a part of the global commons and available to all of humanity. Abot to the rescue?
I'm very open to building a Foundation around this. My goal for Abot is to make it self-sustainable (paying salaries for key people to enable full-time development) and owned by everyone.
I admire the Apache Software Foundation for all the work they've done and can see a similar path forward with Abot. But recall that 24 hours ago it was really just me working on this. Give me another day or two :)
Correct me if I'm wrong, but isn't slack a closed ecosystem, akin to Skype?
Dunno, but I winced at "in the bot space". I hate anything that smells of marketing/management speak. Going forward/we reached out... just use normal language like a normal person.
Any bots you build on Microsoft's framework as far as I can tell are also locked into a closed Microsoft-controlled system. Just because it's readable on Github and pushes messages to Slack doesn't really mean that it's open-source in the way we've come to expect from Linux, etc.
I'm building a free-as-in-speech alternative.
Until/unless a community fork could gather critical mass it might not be worthwhile. That said, yes, it's certainly possible to do.
https://github.com/Microsoft/BotBuilder/commit/78e7730f49574...
Otherwise all our software would be capable of reading email.
The maintainer(s) get(s) PR approval. Big features that change the direction of the tool are welcome in forks but require maintainers to agree if merged upstream.
What closed Microsoft-controlled system? You can compile that code in either Mono or coreclr.
I get you're not happy Microsoft just released something in an area you've been working in, but this is just FUD.
Don't be a knob. That's clearly not how he feels at all.
Please don't call names in HN comments. Your comment would be good without that bit.
https://news.ycombinator.com/newsguidelines.html
I just wanted to ask about the intelligence built into the bot. I dug through the code a bit (great documentation btw) and it seems that this is using a state machine you've written and custom plugins for different scenarios. How would one account for situations were a case keyword in a plugin is used in a different context? Say for example, I ask "What street number did you say?" to the bot with this plugin^1. It seems that these are items that would trip it up?
Also these bots would not "learn" or get better over time without direct human input correct?
I hope these don't sound like critiques. They're not. Just generally curious about how all of this is put together - particularly the state machine and then also how the plugins can be built (and improved).
[1]: https://github.com/itsabot/plugin_restaurants/blob/master/re...
You're also right that Abot plugins as they stand now do not improve or learn automatically over time. I've done some work on a training system which will enable a Facebook M or Magic-style human-aided training backend. It'll be a plugin just like any other which will eventually be hooked up to a neural net with optional centralized training (so you don't need a GPU rig or tons of data to get started). An early version of that is probably going to be ready going into June with the v0.2 release.
Thanks so much for the feedback. I'd love to continue this discussion and find ways to improve plugins and training. If you're interested, there's a mailing list here: https://groups.google.com/forum/#!forum/abot-discussion
Regarding the neural net, I think that's an important feature because the most difficult part about guessing triggers is, well, guessing. Our language is awfully diverse and I think you'll get better results in the long run.
I've applied for membership to the mailing list. I'll keep my questions there.
Looks awesome though good job!
What is your approach to speech recognition and speech synthesis?
There's an interface (shared/interface/sms) that defines the functions any SMS driver needs to implement, like `Send(to, msg)`. Then we have a Twilio driver that implements those functions, but you could easily write a Nexmo driver or a driver for any other service in the same way.
With speech recognition, we'll design an interface and build drivers for popular services, like Google's new speech recognition API. For the end user, that means you'll be able to pick and choose which service you'd like to use, and by adding it to your plugins.json, speech will be loaded up and handled automatically.
- https://www.houndify.com/
- http://api.ai/
- https://wit.ai/
chatskills: A chatbot API inspired by Amazon Alexa skills and intents
https://github.com/primaryobjects/chatskills
No server required. It can run right in the console, web, slack, etc.
https://www.google.com/search?q=microsoft+tay+bot
there are a massive amount of bot & chatbot conpanies and it is a fairly recent trend. Are we on the cusp of beating the turing test? the space is exploding
Semi or fully automating realtime customer service is definitely a real use case :)
The hype will die in a few years, as people will realize that natural language is a terrible interface.
"Vaporators? Sir, my first job was programming binary loadlifters—very similar to your vaporators in most respects."
Being able to just talk is one of the least physically demanding forms of input that can possibly be used and if the language can be understood accurately enough with a wide variety of computer solutions backing the responses, people will become comfortable with asking for those types of responses.
I didn't see anyone say it would be the only interface in the future, just that it would be one of many. Microsoft is saying you can write one application solution and expose a variety of interfaces. Use the keyboard and mouse when you're sitting at the desk with Outlook, or ask Cortana to do that for you if you're across the room or busy driving across town. Whatever is convenient.
Example:
Tester> can you elaborate on the meaning of life?
Bot> wtf? u suck lolololol!!!
Tester> uhm...
Bot> r u dumb?
What Turing meant was being able to ask the bot things, like "what do you think of Angela Merkel’s stance in the refugee debate?" or ask the bot about economics, or philosophy – and the bot would answer.
Conversing with the bot, and doing it in a way where you receive answers that are meaningful, is a required part for intelligence.
The people you mentioned – if judged just by their online interactions – would not count as intelligent life.
- mobile app delivery sucks (Apple and Google are not trying to make it better, Facebook and Microsoft are but there is only so much you can do when you don't own the platform)
- the web is still subpar for mobile and is not progressing fast enough
- developers (understandably) want to get back the practices that became popular in the Web 2.0 era: continuous delivery, a/b testing, etc
- running code on your own servers is much easier to develop, test, debug, and change
- UIs are still hard to build. Things are slowly getting better but it's very expensive to hire good Frontend engineers and designers and you need to laboriously create UIs for every possible interaction
- apps are too much of a commitment for users. Whether you are looking for something or just want to use something once you have to install an app and sign up for it just to try it. This app will then live on your home screen along with hundreds of other apps that you don't really use.
The recent advances in NLP and some AI techniques made it possible to create good chat interfaces. Which is a much better developer experience. It's still unclear whether it's the best possible user experience.
And I thought of email. A well standardized message queuing platform that could easily implement a basic text command interface. So I ended up with a rudimentary chat bot. (I could've done SMS, but didn't want to find and pay for a service for that.)
And a few weeks before this announcement, I'd been thinking about how to handle queries to my chat bot my software didn't understand, and I was thinking "Hey, I wonder if I could have my bot ask Cortana stuff if it doesn't know". And Microsoft's picked up and really ran with this model with Bot Framework.
Obviously they've been working on this behind the scenes for a while, I'm not trying to take credit for the concept by any stretch, but I thought it was funny that I had been thinking along those lines myself before I heard about this.
Good UI isn't hard. Generally, it's simple and universally understood. I instantly understood where Microsoft was going here because I had the same thoughts. That being said, I want my system running mostly locally/self-hosted, so an Azure-based platform like Bot Framework probably won't work for my own system, though I might very well send requests to other bots using it.
I have to strongly disagree with that, it might be easy to spot good UI but it is not normally easy to make a good UI.
As for SMS Twilio is dirt cheap $0.0075/message + $1/mo for a number also combining it with something like Wit.ai [0] to parse your text and you can get pretty far.
[0] https://wit.ai/docs/http/20141022
I felt this was one of the few ways you could insure the game could still be played in perpetuity after a company had gone away and their servers shut down, without requiring people to host a dedicated server.
Obviously this wouldn't work with real time games, and players could potentially abuse the data being sent if you're not careful and/or don't encrypt the data, but I prefer making turn-based games anyway.
Having worked for several small companies that have shut down, that's a concern to me (although you can't even download most of those games anymore since they were taken off their respective app stores).
I found it interesting Microsoft Garage made an "IM client" that uses email in the backend recently. In some cases, I think all these new protocols we invented was reinventing the wheel, when we already had something that worked fine.
Using it for games is a really neat idea. In a plaintext format, you could even space out things like a Scrabble board, using @ and & symbols for special blanks or such, and one user could be lower case letters, and the other could use capital letters. Dots for normal blanks.
I love simple formats.
For example take a look at the RFC 5322 and try to determine what is or isn't a valid address. You have a lot of weird edge cases to take in account and it's not always obvious how you are supposed to handle them.
https://tools.ietf.org/html/rfc5322#section-3.4
However, if you are building a piece of software that simply communicates over email, you only have to support a relatively straightforward format for email that everyone else inherently supports.
Depending on the platform you're building on, a lot of the basics of actual email sending and receiving may be handled by the platform directly as well. I didn't have to write the SMTP handling for my code, for example, because the platform I was building my app on pretty much did it for me.
Also, the great thing about figuring out weird edge cases with email, is that email is such a widely used and universal protocol, there are literally millions of places on the Internet that have code for it or talk about it. There's a lot of resources out there.
Since the game would need your email password in order to load incoming messages I would advise them to create a new email just for game communication purposes anyway, and tell them not to use certain characters if for some reason I couldn't get them to work (although the libraries should be able to handle it anyway).
Competition: Facebook is building "M", a personal assistant-style personal assistant. Apple has Siri. Google has Google Now. And MS has Cortana.
Technology: Some (Weasel-word, but I don't want to list names) say that computer vision is now solved. Convnets can predict 1000-class problems with the same accuracy as humans. The deep learning field is now eating away at the fields of reinforcement learning, generative art, and NLP. Recent papers show that it is now possible to create a conversational bot without any hand-crafting of rules.
Military/defense: Both the AI/ML industry and academics are in bed with the military complex. We did not study convnets, to aid the blind, no, we studied convnets, so we could detect terrorists at the border or in public transit. The people working on guided missile systems in the previous generation are now working on unmanned aerial drones. People were interested in fooling convnets, not for the hell of it, but because it is dangerous when a turret mistakes a tank for a puppy. For NLP: DARPA and IARPA want better defense and intelligence technology. The systems to suck up all these global communications are in place, but it still relies on old "dumb" tech, like keyword-matching. It is not able to detect sarcasm, 1337-speak, or code words. That is a big driver behind the attempt to evolve NLP: Terrorists do not need encryption, when they can talk about butchering goats and get lost in the noise, and no one is the wiser.
The Turing-test will forever be a moving goal-post. Mimicking intelligence does not seem to be enough to call machines intelligent.
[1] https://en.wikipedia.org/wiki/Microsoft_Popfly
https://cloudnative.io/blog/2016/03/chatbots-will-replace-hu...
As for why Microsoft is jumping in now? They have a Slack clone in the works. This bot framework is just laying the groundwork for duplicating one of the core reasons for Slack's success.
As for the Turing test, no, none of these bots come close. The frameworks make it easy to match simple text commands, but that's about it.
Chatbots are a way to integrate other services into WhatsApp/FB, Slack, etc. China's WeChat is setting the trend here [1]. You can do things like payments, online shopping, order a pizza/taxi/whatever with just a simple text message.
WhatsApp will be offering a paid API soon that will make Chatbots available within WhatsApp and thus make all the above possible.
As a result, messengers like WhatsApp will become a platform. Instead of having to install an app for every service you just add a contact to your messenger and text him what you want.
[1] https://www.techinasia.com/wechat-social-commerce-chinaccele...
Is that a wild guess, or sourced somewhere?
Anyway, with Microsoft releasing this, and supported apps such as Telegram already having a bot API, this does put a lot of pressure on WhatsApp.
All of this under MIT license - thank you, Microsoft!
Front end integrations (Slack, Skype etc) NLP Conversation state and context management Automated knowledge/learning.
etc etc.
I'm in the middle of writing a blog post on this, but https://medium.com/point-nine-news/software-bots-c56aeedcfec... is a good piece to read
And this coming from someone who hasn't touched Windows in years and doesn't intend to.
[0] https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
It's typically prescient for Douglas, and I feel even more sorry that he's not around today to enjoy, and shape the way technology has progressed.
Now I'm melancholy... Time to re-read some Dirk Gently!
- A single API key to keep track of, and they automatically handle keys for the other platforms
- Less connections to handle, just read all the messages from a single queue and tell the API which one you're replying to
- Common backend code that could be shared between both C# and TypeScript/Node, as well as other languages that could be added in the future. For example, Python, Perl, or Ruby are extremely popular for IRC/Slack/Telegram bots and it would be nice to have a common API for some of those languages.