Why do we limit the list of cities in the Early Beta for the LeovaTravel Chrome Extension?

If you've gotten here, you're wondering why we kept the list of cities on the Early Beta of our LeovaTravel Chrome Extension down; and this post attempts to explain why in as simple terms as possible.

[Of course, if any of this sounds too complex at any point of time, feel free to write to me at nikolai [a.t.] leova.io and I'd be happy to share some of the AI / ML love around]

This blog post is from a reddit post I made earlier today:

If you look closely at the speech transcription in the demo (and our other demoes on leova.io and onesevene.com), you will see a lot of the spoken language is mis-transcribed. Ordinarily, that would break any natural language processing system like Siri / Cortana / jut about everybody else. So how do we solve this problem?

Our secret weapon is a machine learning layer sitting just behind the speech recognizer. The machine learning layer trains on people's accents, the names of products, cities, how those city / product names are pronounced. And the net result of this is an accuracy even greater than Google's 92%. With the machine learner, the AI is now able to structure casual conversation at levels of complexity never seen before.

 The machine learning allows us to offer outstanding accuracy for even complex product names that might often be mispronounced (most speech recognition fails miserably at this). Ever go to a fancy restaurant and mispronounce the name of a dish? Or have the guy next to you at the mall mispronounce versace as ver-say-ce? Yep - that happens a lot. And our ML helps fix this in real-time.

Ordinarily a reliable level of machine training for the set of 10,000+ worldwide destinations would take us about two more months, and we'd have to put off the early beta release for 60 - 90 days. Instead, we took a wee bit of risk and released Leova with MT for about 291 of the world's most popular cities, counting on adding additional cities as people asked for them.

As and when our beta users ask for destinations that aren't in the system, we update the geo-database and the machine training with them on a priority basis. Soon, we will have all destinations built-in and trained for. If you're a beta user and want to speed up the process, just email me a broad range of of cities / destinations you travel to (or want to go to). And I'll have it sorted out in next 12 hours.

A small downside to using the machine learning system is that with a small beta test group, the risk of having someone teach the system something wrong is too great. (you've probably seen instances where Google messes up and says something hilariously inappropriate due to training sets that are too small: 

http://searchengineland.com/when-google-gets-it-wrong-direct-answers-with-debatable-incorrect-weird-content-223073 

http://www.telegraph.co.uk/technology/google/6161567/The-20-funniest-suggestions-from-Google-Suggest.html

http://www.searchenginepeople.com/blog/google-ads-fail.html)

To avoid this horrifying scenario, the machine learner batches "learnings" for us to approve on a nightly basis. The learnings scale exponentially, so human intervention goes down rapidly. But for the time being, our early beta users are gonna be put through the process of helping the machine learn.

For reference, here's a list of cities that are currently in the geo-database: https://onesevene.com/leova/cities.html If you wanna add to this list, let me know and I will get it done asap :-)

The Conversational Funnel

One of the things that annoys me the most about contemporary voice AI is what I call the ‘Conversational Funnel’. If you’ve ever used a mobile app with voice, it’s that situation where you say something (yes, with your voice) to an app and then the app asks a question back and then you provide it with a little more information and it says something back again. Like the following stilted conversation on an app I used recently:

Isn’t this just painful? Having a voice interface that prompts you constantly is not how human conversation happens. And even worse is the voice interface that doesn’t understand anything other than the response to the question it is asking.

Now, a conversational funnel is super easy to build. The system knows what it's listening for because it is aware of what it is prompting the user.


But, as human beings, we’re prone to changing our minds. And a part of what makes us human is that choices make us happy. And customer happiness is what makes us happy (corny, but true).

Building a system that replicates this conversational funnel is easy and reeks of lazy or incompetent programming. At 17E Tech, we've focused on modeling Leova's (https://www.leova.io) interactions on real human interactions. And just like you'd never end up in a conversational funnel except at the DMV, we wouldn't dare to put our users through something like that.

Building a system that allows and accounts for forks in a conversation, that is able to handle modifications mid-process is the closest that machines can come to an inter-personal interaction and we're proud to have been able to build artificial intelligence that comes so close to this model.

I plan to cover this topic in more depth at a later stage, but for now, I shall bid you adieu and have a great weekend!

Natural Language Theory for Mobile Apps. And why it should be Abstracted

I’m going to be honest – I’ve looked at a couple of my competitors’ solutions and I must say that the final result they’ve got in their demos looks really awesome. But like any great dish, the final product appears to rely a lot on the chef.

Now, if only I could understand how to use their many different objects, entities, actions, interactions and extensibility and whatnot. After playing around on their site for a little, I begin to wonder if there’s some kind of pre-usage workshop I could attend, because the YouTube ‘getting started’ video is clearly useful for few other applications than the one the demo was being put together for. I’m sure that their tech has a WHOLE LOT of applications, but that’d require me to learn their proprietary way of interacting with their proprietary objects. And that’s a whole lot of new stuff for apps to learn. But why?

While building Leova, we had one single consideration in mind - the awesome app developer out there. An app developer is one of the brightest bulbs in the box, and they do a TON of work to enhance and constantly upgrade their skillset. And it’s a lot of work, I’ve got to be honest (we know because we tried building a couple of apps and we suck at it)!

So while designing a workflow, we asked ourselves, “how do we allow app developers to build better apps with voice, without having to learn ANYTHING about Natural Language Processing (NLP), but continue to deliver outstanding experiences to their users?”’

Now that’s a tough question. And it’s one that many very smart people around the world are trying to solve. While most of the solutions are being crafted using big data, we took a different, higher-speed approach – we looked at how people speak to each other, in great detail. We studied the structure of conversations and what constituted a fully-formed conversation vis-à-vis conversations that appeared to be stilted, dysfunctional and just plain unnatural sounding. And this was hard: English is full of exceptions and variations from standard rules, especially in modern day usage.

While building Leova we took the hybrid approach of supplementing textbook natural language analysis, of Bayes and Markov, with technology that we built ourselves. Our focus has been on not just building technology that can understand human language, but also building an expertise-base (narrow AI of sorts) in certain specific sectors, to emulate the experience of talking to an expert in that field (much like having a conversation with an experienced travel agent). This explains why we’ve been staggering our releases – travel, next food and early next year, IoT.

If this sounds interesting, we urge you to come visit the Leova page: https://www.leova.io, it takes nothing more than 2 minutes to get an implementation up and running. And another minute or so to personalize the LeovaTravel implementation with destinations.