Bots, bots, bots. A word which has, for the past couple of months at least, been thrown around like a hot potato. For the most part I've not paid much attention. However, when Microsoft announced it's Bot Framework at the //Build conference I decided it was time to have a play.
At Microsoft, one of our ambitions is to build the 'Intelligent Cloud'. This ambition encapsulates a truly monumental scope - from developing new infrastructure, to democratising Artificial Intelligence. However, one aspect of the cloud that I don't think really gets enough coverage is the way in which we interface with it.
Sure, we have built a beautifully crafted - yet overly engineered - web portal for users. In fact we built two! We also provided REST APIs, cross platform command line tools and PowerShell cmdlets. These are all traditional interfaces which work with discrete commands.
I want to build a stateful intelligent interface, bringing some of the innovation we have in the consumer facing space into the IT space. Including new input mechanisms such as voice and natural language. 'Wait, backup. Isn't Azure all about automation?'. Absolutely, but that doesn't mean that we don't need to interact with it. Developers need to spin VMs up on the fly, admins need to query costs and resource usage, and data analysts need to query... well data. In order to achieve this I am building the AzureBot.
n.b. This is only a POC and will not be production ready!
Yesterday I spent sometime setting up the authentication flow to allow the AzureBot to talk to Azure on behalf of a user's tenancy. I will eventually make the AzureBot multi-tenant but for now I'm just working with my own tenancy. My colleague Pete had come up with a nifty solution for accessing the MS-Health APIs for his project. I modified a few bits of this authentication flow and managed to get it working the Azure ARM Rest API.
After I had the authentication flow working I needed to allow the user to perform some operations. In order to parse the natural language input form the user I leveraged the Language Understanding Intelligent Service (LUIS for short).
Once I had created a new LUIS application - I needed to think about how the Bot would understand the user's input. I decided to break down the sentence as follows.
Where Action, ResourceType and SubscriptionId are Entites. This then maps to a sentence as follows:
Where 'get' is the action, and 'subs' is the resource type. By mapping the intent to many variations of the sentence you build a stronger model. The subscription id is optional as if it is not defined, the bot will use a default one from your tenancy.
Once you enter an utterance - LUIS tries to match that to an intent. It provides a confidence level for each of the intents you have defined.
Once I had trained the model on the couple of intents I wanted for now, I published the model as a web API.
I then added a simple function that sends the text input captured by the Bot to this LUIS web API. It then returns the matching intents which I can act on.
The current state of conversation is a follows (I've redacted my subscription id and tenancy id using red blocks):
As I've only been developing the Bot for a few hours the functionality is pretty basic. However, the foundation is now there to add further LUIS intents and hook up more operations on the Bot. The project is open source so please feel free to contribue - the LUIS account will not be accessible so I will roll out new intents by myself.
If this has sparked an interest in the Bot Framework - please do go and take a look at how to build your own Bot at https://dev.botframework.com/