A conversation design platform
How we think it should be
In algonew we believe there is a significant gap separating the advances of human language processing technology and actual business applications. This means that the impressive advances we have witnessed in the last years are not even remotely exploited by the business community, missing opportunities of higher efficiencies and better customer service.
Covering the gap calls for bringing the technology close to the business user. And to do that we need a combination of business consultancy to identify promising use cases and the right technological platform to make them a reality. This post deals with the second element: our ideal platform to prepare and implement state-of-the-art natural language solutions
There are of course existing platforms in the market, either open source or commercial, which cover some of the requirements that follow. We do not think one single offer covers the whole set.
Zero-Code training and testing
The step to achieve a production-ready conversational system, such as a chatbot, is to configure the project, training it over a number of cases and testing it. The Data Scientist approach to this phase is very likely to rely on some custom Python code integrated with some of the latest nlp packages.
This way of working has a number of drawbacks. For starters it limits the range of potential users to those mastering both Python and whatever nlp packages are used. It would create a sort of elite guetto composed of the guys who are really qualified to do the job: those who can as opposed to those who cannot. Data Scientists need to come to terms to the hard fact that training the model is not the end of the story - if anything it is the beginning. Deployment and monitoring come right after that and need to be integrated with the training phase.
Therefore we advocated for a zero-code, GUI driven training and testing platform that can be used by both regular users and specialists. It will not only include the begginers in the loop, it will benefit the top-notch individuals as well.
Those who stand to benefit most from good UX aren't the beginners, but the very best practitioners in the world.
However we are not as naif as to think that this can be achieved with a flexible GUI over a rigid engine as the approaches and algorithms for natural language processing are all but stable - every month brings its new advances in the field.
Low code configuration
Behind the scenes the platform has to be open to the everchanging ecosystem of nlp building blocks. Tokenizers, Lemmatizers, Named entity recognition modules, word vectors, classifiers, etc. don't belong to a static, frozen world. They change often either by improving previous algorithms or specialising on specific problems or domains.
The implications for our desired platform are clear. We need a way of configuring the system so the incorporation of new algorithmic elements is easy for the configurator and the new pieces become immediately available in the GUI-driven Zero-Code training area. Even if we understand the need of a good understanding of the new pieces being incorporated, we also believe that the platform has to make it as easy as possible for the person in charge of the configuration.
Easy deployment
The transition between the various phases of the life cycle of a conversational UI has to be fast and reliable. From the moment the configuration is completed to the point where the user acceptance or production environments are engaged under the new rules we need to require minimum elapsed time possible.
At the same time we would expect a traceable, secure deployment process subject to audit and roll back. The workflow should not change significantly from one deployment platform to other, as discussed in the next topic.
Scalability
The range of use cases of conversational UIs and document classification is really wide. You can have small operations with just one chatbot in production or a global company with multiple sites and countless conversational UIs, some of them with really heavy use.
Our view is that the scale and diversity of the solution should not affect the training and testing interfaces. For the user defining the dialog this should not matter. However it is conceivable that one or more deployment engines should be made available to deliver the expected performance for the various use cases, from small redundant servers in virtualized environments to highly scalable big data architectures. But all of them whould accept the same input produced by the GUI interface that the user manages.
On premises or in the cloud? Yes
The very nature of the user organisation drives the choice between deploying the solution on premises or managed by a third party in the cloud. Some of the drivers can be:- Sensitivity and confidentiality of the information call for an on premises solution.
- Scale of the user organisation may call for a managed solution if we are considering medium and small enterprises
- An IT strategy targetting low fixed costs may lean the decision towards cloud solutions
- Outsourcing monitoring and retraining services can be better integrated in a managed solution.
Seamless feedback of production data in retraining loop
It is a cycle, not a forward-only workflow. Once in production the COnversational UI gets new inputs and produces answers in the dialog. Those answers won't be always perfect but this experience is the ground for dialgo improvements.
Our ideal platform would include a path for feeding the production data back into the training environment so that the next generation of the conversational systems benefits from both past and present real dialog experience. Once retrained, the system will be tested and deployed in no time for the client base benefit.
