Implementing an AI multicloud broker

Holger Kyas details the AI multicloud broker, which is triggered by Amazon Alexa and mediates between AWS Comprehend (Amazon), Azure Text Analytics (Microsoft), GCP Natural Language (Google), and Watson Tone Analyzer (IBM) to compare and analyze sentiment. The extended AI part generates new sentences (e.g., marketing slogans) with a recurrent neural network (RNN).

The AI multicloud broker is triggered by Amazon Alexa and mediates between AWS Comprehend (Amazon), Azure Text Analytics (Microsoft), GCP Natural Language (Google), and Watson Tone Analyzer (IBM) to compare and analyze sentiment. The extended AI part generates new sentences (e.g., marketing slogans) with an RNN using long short-term memory (LSTM). Finding those sentences with very positive sentiment is the primary goal. The idea of the AI multicloud broker evolved from a prototype built in 2017 to integrate Amazon Alexa with IBM Watson. This was a lot of fun, though through some API changes in the cloud it came back to me as a surprise. Nevertheless, the idea to extend this scenario with stronger AI capabilities was born. After the ambiguous messages around the possibility to capture free speech with Amazon Alexa and its usage for marketing, I concentrated on the technical possibilities of doing so within multicloud scenarios. As I built the prototype in 2017, integrating Alexa with cognitive services from IBM to analyze emotions from the Big 5 model the way to do this was tricky. The AWS API supported the type AMAZON.Literal to capture free text beyond given intents. But it was deprecated once in 2017, reactivated again due to developer protests and finally deprecated in October 2018. So any app using the AMAZON.Literal type didn’t work anymore and had to be migrated. Welcome to the cloud…even though this happens on-premises as well. The recommendation was to migrate to custom slot types, but that wasn’t as easy as it sounded. Free speech wasn’t captured the same way it had been before, and the documentation didn’t explain why. So searching for options to make that work, I found another built-in type, namely AMAZON.SearchQuery. The specification in the section “samples” may look like this: “Capture {Query}”. So when your skill has been invoked by, for example, saying “tone analyzer,” if you say “capture” and then “I feel happy” the captured {Query} is “I feel happy.” So this seems to work, but as always, not easy going to find out if you have many other things to manage in your life. Why capture free speech out of the Alexa API anyway? To engineer the multicloud scenario where you can consume the free speech via a broker component that can call API services from different clouds. For sentiment this would be AWS Comprehend (Amazon), Azure Text Analytics (Microsoft), GCP Natural Language (Google), and Watson Tone Analyzer (IBM). Obviously, the AWS Comprehend service can be called directly by the Alexa Skill, but it’s interesting to see the comparison between those calls from the broker. So the cloud broker component is handling the incoming and outgoing service calls from and to Alexa. But it also manages the service calls to the four different cloud services. My experiences show that there are some major differences and it feels proprietary. After overcoming those the core of the AI part was the generation of possible new sentences, like marketing slogans. For this, my first choice was an RNN using LSTM as neurons. This works well so far, but the more difficult part is to generate sentences with perfect sense. The area of creative AI is thrilling, but guidance of how to inject domain context in a way that generated assets fit well is just about to evolve. So: Productivity for the AI multicloud broker is realistic after mastering some hurdles.