I’m not the first person to launch a person bot — MessinaBot and EstherBot are other examples. But these are all provided by people working the bot field — personal bots don’t seem to have yet become “a thing” for consumers.
So what exactly is BotDunc and why did I decide to embark on this seemingly pointless activity?
BotDunc — what is it?
BotDunc is my personal automated bot. You can currently chat with it via Twitter Direct Messages or Facebook Messenger. BotDunc is an attempt to provide a kind of bot-generation CV and all round personal slave. Ultimately I envisage BotDunc being able to answer most questions you might have about me or my work.
But more than my personal bot, BotDunc is a public study into bot development. It’s a vehicle through which I can explore the highs and lows of creating a bot, discovering what works and what doesn’t. It allows me to engage in a conversation with you, my dear readers, helping to share my experiences. BotDunc is most definitely not designed to be a perfect bot solution. Instead, it’s very much an experiment and the spark for a conversation.
Bots are trendy — there’s lots of talk about them and just a hint of hyperbole. Because of this, it’s sometimes hard to discern facts from hype. I’m a believer that the most valuable opinions are those formed from experience. With that in mind, building and iterating a bot in public felt like a worthy exercise.
I am also conscious that, given the current bot hype, there might be a rush for bot names. So, being completely open, my timing was motivated by a desire to ensure I grabbed a great bot name in Twitter and Facebook before someone else got there before me. Who knows, bot names might just be the new domain-name gold-rush!
As I work wtih IBM Watson, I was also influenced by our launch of the Watson Conversation service — an ideal platform for aspiring bot-makers like myself. I needed a purpose to play with the new technology and BotDunc has become just that.
As a huge fan of the Lean Startup approach, I decided to first of all get a BotDunc Minimum Viable Product (MVP) launched quickly — I call this the Minimum Viable Bot (MVB). Remember this: you heard about an MVB here first!
My MVB was deliberately minimum in both its technical architecture and its training. I intend the approach to both to be a kind of agile evolution. Rather than scope-out and design the world’s perfect personal bot, I plan to evolve BotDunc incrementally. Taking this approach I hope to be able to show the value of each incremental improvement as it is made. No doubt I will also go down some blind alleys along the way. Some design decisions may end up being proven wrong and being replaced — indeed, some already have (read on for the details).
Overall my big rationale for this “launch a minimum product quickly and iterate in public” approach is very simple — nobody really knows how popular bots will be, or indeed what a personal bot needs to do. At this stage I’m just guessing — and I’m almost certainly wrong in nearly all my guesses. The only way to discover what BotDunc should do, is to get the bot out there and see what people do with it. Only by observing what real users ask of my bot and what their actual expectations are, can I ever hope to build anything useful.
Further, by collecting the questions people are asking BotDunc, I’m already building my training data for the underlying AI that supports it. There is no existing corpus of training data for a personal bot, so I’m effectively getting you to generate one by launching early and collecting what you ask BotDunc. In some senses you could view BotDunc at this stage as little more than a question collector.
Of course this approach has risks. In its version 0.1 guise BotDunc is pretty stupid. He’s already made some obvious gaffs and embarrassed me. But I’ve been careful to keep BotDunc conversations 1:1. On Twitter BotDunc doesn’t tweet publicly, preferring instead Direct Messages only. Public tweeting at this early stage would seem, to me, to be folly. BotDunc is learning and making mistakes without the full glare of publicity — in stark contrast to Microsoft’s Tay. This post, and the subsequent ones that follow, will hopefully explain what I am doing and why — perhaps you will forgive BotDunc’s stumblings a little more when you understand this. Above all, BotDunc is not a showcase — he’s an experiment.
BotDunc’s design was initially very simple — about the simplest possible in order for me to launch a Watson-powered bot on my chosen messaging platforms. That design was made up of the following components:
- BotMaster, a simple NodeJS framework for connecting a bot into messaging platforms like Twitter, Messenger and Telegram. BotMaster is engineered by my friend and colleague @jdwaurin.
- Watson Conversation, a cognitive bot platform. Conversation provides a machine learning system so that I can teach my bot by example how to understand the intent of questions that users ask of it — for example, “hello” and “hi” are both ways of expressing a greeting that share a common underlying intent. Conversation also includes a structured dialog system that allows me to configure answers to questions and conversational flows where you can have a back-and-forwards conversation with BotDunc. These major capabilities of Conversation make it an ideal base for a bot platform.
Both BotMaster and Watson Conversation are deployed into IBM’s Bluemix Cloud system. As Bluemix is a platform-as-a-service solution, I don’t need to setup any servers or configure any infrastructure — I just provisioned a NodeJS and Watson Conversation instance with a few mouse clicks and Bluemix does all the rest. Perfect for my MVB.
This was the sum total of my initial implementation. I could see questions being asked of BotDunc in Twitter and Facebook — the volume of conversations were sufficiently low that reviewing these manually was easily viable. Doing so I quickly identified things that BotDunc was struggling with and adjusted its training and dialogs appropriately. I was up and running within a couple of days and working things out as I went. No big planning here.
Iterating the Architecture
My initial architecture had some glaringly obvious restrictions. It was simple, so allowed me to launch my BotDunc MVB rapidly, but needed some attention if I was to meet the probable expectations of my users.
Two big problems I needed to address included:
- Answers to questions could only come from within Watson Conversation itself — the ability to reference other sources was absent (for example, to search in a document for an answer, to call an external API, or to reference a database). I needed a cognitive integration framework that allowed me the flexibility to reference many and varied sources of information that BotDunc might need in order to be successful.
- Reviewing conversations through Twitter and Facebook was clumsy at best and wasn’t going to scale when BotDunc went viral (well, I have to plan for success, right?!). A more structured data store of historical conversations that would allow me to extract and analyse conversations was clearly going to be needed if I was to achieve world domination.
In order to implement the technical underpinnings to address these two problems, I’ve just re-engineered BotDunc to include an additional layer between BotMaster and Watson Conversation. This inserts NodeRed into the architecture acting as the, until now, missing cognitive integration framework. NodeRed has a wonderful graphical development tool that allows me to wire together pieces of function, access databases, call APIs and generally muck about doing lots of cool stuff! Because my bot presence in Messenger and Twitter is now plumbed into NodeRed, which calls Watson Conversation, I can add additional function like:
- access a database of information
- call an external API to retrieve live data to augment a reply
- call other cognitive services — for example, Watson Retrieve & Rank looks for answers to questions within a natural-language document (maybe my CV?) and the Emotion service helps to identify if incoming questions include strong emotions.
With the just deployed architecture, a question from BotDunc passes through BotMaster, which forwards that to a simple ‘flow’ in NodeRed. That flow stores the conversational fragment in a database and then calls Watson Conversation. It’s simple, but it provides a base on which I can build. The flow also handles the conversational state. Watson Conversation is a stateless service and the calling system needs to pass a Context object between calls that handles that state. My NodeRed flow manages and stores the Context object, ensuring that once you’ve told BotDunc your name, he’ll remember it forever! It sounds complex, but is almost trivial to implement once you know how.
The inclusion of NodeRed and its role as a cognitive integration layer was a major architectural pivot. Luckily, the architecture and technology used is sufficiently light-weight that this wasn’t a problem — the change was implemented in one afternoon. I like to think of this as an ‘Agile Architecture’. This is one that doesn’t need a great deal of pre-planning and emphasises the ability to react to requirements change quickly. My over-riding non-functional requirement at this stage is agility.
If I decide later on to let BotDunc handle sensitive personal information, for example, then I’ll address the architectural requirements then. Trying to plan ahead now would just prevent me from making my first move and working out what people think BotDunc should do. Maybe BotDunc is a terrible idea and nobody will use it — in which case, it’s good to find that out now before I’ve invested time and effort in its development. Only an Agile Architecture can allow me to launch, discover and iterate.
If need be, I can throw my investment in the current design away when I discover a need for a super-secure version — for that investment is sufficiently small for that not to be an issue. Agility, iteration and experimentation are the order of the day.
I wouldn’t recommend an Agile Architecture for every situation but, given my purpose and the technologies I’m using, it’s perfect for the task.
If you were keen enough to be a user of BotDunc in its first few days, you were almost certainly unimpressed. My initial implementation was open-ended — BotDunc just invited you to ask anything you wanted. Given the total lack of cultural experience with personal bots, this was foolhardy. People had no understanding of what was a reasonable question, and so asked all sorts of random stuff. It’s pretty hard to second-guess what you might ask BotDunc, so it was equally hard to give BotDunc the training it needed in order to impress. Now that I’m getting some real user input, it’s helping me to refine my bot’s knowledge.
Nevertheless, the open-ended approach was revealing and useful — it helped me to begin to get a sense of my bot user’s expectations and improve its training. Had I implemented a more directive approach (eg “Please only ask me about these three things”) I might never have discovered some of the insights into possible requirements that I did.
But still, it seems that BotDunc can usefully set some expectations and start to guide users down a path where it’s more likely to be successful. I don’t want to remove the potential ‘random stuff’ that might come up, but I do want to gently encourage usage in areas that BotDunc is better qualified. As a result, I’m in the process of building guided options into the BotDunc conversation. Instead of “What can I do for you?” it will say “You can ask me about Duncan, about BotDunc or about Watson. What would you like to ask me?”.
Of course a user might still ask about BotDunc’s views on Brexit or Donald Trump, but hopefully the expectation is set that those are possibly topics that it isn’t so qualified on.
Having reviews the logs of conversations with my bot, I would like to make it clear that BotDunc has not yet experienced questions of “personal” nature, unlike IKEA’s experience.
Release and publicity
In hindsight, some of the questions BotDunc has been asked were predictable. For example, I should probably have guessed that questions about ‘cognitive’ technology were likely. But I didn’t. And here’s the rub — you can’t guess everything. Surprises are a certainty. In my view, you have to launch in full knowledge that your initial bot will disappoint. The trick is to follow-up rapidly and iterate the bot’s training as users expectations become clear. The alternative seems to be an awful lot of guessing and naval-gazing.
I had the obvious advantage of a soft-launch through obscurity — not being a celebrity, my user-base is fairly (OK, extremely) limited. Let’s just say I don’t have to worry about my servers being over-loaded. If your public presence is grander, a more controlled release is probably called for. Limited publicity, required registration, selected friends-and-family, cloaked branding and other such techniques can all be used to ensure your bot’s idiocy don’t make the front page of the Daily Mail. But I do think it’s critical to get any bot in the hands of real people as soon as possible — not project team members. Only then will it be exposed to the expectations and abuse that it will surely receive when you go big.
I have many other plans for the BotDunc user experience — some experiments may crash-and-burn and others might succeed. Whatever the results, it should be a fun ride! Please, check back regularly with BotDunc on either Twitter or Facebook Messenger — ask it stupid questions and give it some slack when it fails. Let me know what you find.