7
including acronyms), then each
message you type in a chat gets turned into an array of 70,000 elements, most of which are zeroes, with a few ones in it corresponding to the words you happen to have used in that message.
Training your logistic regressor
Logistic regression is a fancy term which you would already be familiar with. Essentially you assign a score for how discriminating a word is – how strong it is at predicting something.
The word “password” appearing in your last message would score highly for a response for a password reset, but the word “Windows” would be a very weak predictor for a response about a password reset. Seeing the word “Linux” even in your history would be a negative strength predictor for “have you tried rebooting it yet” because it would be very rare for a human being to have given that response.
You train on your existing corpus of data, and it calculates a matrix of strengths.
It’s a big matrix: 70,000 words in four different places (the last thing the user said, the last thing the support agent said, the user’s memory, and the support agent’s memory) gives you 280,000 columns, and each step of each dialog you train it on (which may be thousands of conversations) is a row.
But that’s OK, it’s a very sparse matrix and modern computers can train on gigabytes of data without needing any special hardware. It’s a problem that has been well studied since at least the
1970s and there are plenty of libraries to implement it efficiently and well.
xx
Cheaper and surprising successful chatbot realised
And that is all you have to do, to make a surprisingly successful chatbot. You can tweak how confident the chatbot needs to be before it speaks up (e.g. don’t say anything unless you are 95% confident that you will respond the way that a support agent will).
You can dump out the matrix of strengths to see why the chatbot chose to give an answer when it gets it wrong. If it needs to learn something more or gets it wrong, you can just give it another example to work with.
It’s a much cheaper approach than hiring a team of developers and data scientists, it’s much safer than relying on any here-today-gone-tomorrow AI startup, and it’s easier to support than a system that calls web APIs run by a big-name vendor.
Interested? Come and hear me talk at the ITSMF Conference in Canberra, where I’ll talk about all the exciting developments in AI that are going to change the way we do ITSM over the next five years.
Greg Baker is the CTO at Daisee, an AI startup with offices in Sydney and Melbourne. He is the author of “A Better Practices Guide for Populating a CMDB” and 5 other technical books.
Previously working as a consultant, his clients include a who’s-who of startups, multinationals, governments and charities in Australia and overseas. He has worked with and advised ITIL and ITSM projects at DHS, Federal Parliament, Hewlett-Packard, Optus and Novartis.
About the Author
Greg Baker