Last weekend (24th-25th Sept) was the second Ai.WithTheBest conference – an online conference about artificial intelligence. Over two days, speakers gave talks (often from their homes) with live Q&A.
Dennis Mortensen of x.ai kicked off this year’s conference with three frameworks for looking at AI products. He gave two frameworks for looking at the AI market and one framework for evaluating whether an AI product was good. Putting Dennis’s talk first was an excellent choice – it gave listeners of all levels of expertise a framework to place methods and products mentioned in the following talks.
(x.ai is a smart assistant (Amy or Andrew) that helps you schedule meetings. Just CC them in an email.)
I planned to include headings and my thoughts for Dennis’s entire talk but the post became too long so I’ve only included my thoughts on the first framework in this post. I will write separate posts about the second and third framework, but have included Dennis’s slides for each framework at the end of this post.
Framework 1: Three Segments of the AI Market
Segment 1: AI Platforms
Here’s my understanding: The first segment, AI platforms, includes things you build AI on top of. AI platforms constrain how your AI will be executed – e.g. through Facebook Messenger or Amazon Echo. They may be interfaces users use to communicate with little AI capacities themselves (e.g. Facebook Messenger) or, later on, Horizontal AI like Siri or Cortana (see Framework 2). But they don’t give you the AI technologies themselves. If you want to build a bot on Facebook Messenger, you have to build the models yourself. They will probably try to incorporate NLP layers into their system later on to assist your bot-building though.
Segment 2: AI as a Service (AIaaS)
Here’s where I got confused twice: differentiating between the second and third segments.
My current interpretation is that the second segment, AI as a Service, includes building-blocks type generalised predictive models that people can use to achieve reasonably good accuracies.
The first source of confusion was not knowing what AWS and Google Cloud’s AI offerings were. I know AWS and Google Cloud as hosting services, so I assumed their services would allow for more parameter-adjusting and be functionally closer to TensorFlow, where you code your own models. So I thought the differentiating factor might be ‘degree of abstraction of parameters’ (where AI software had more high-level parameters) which led to (1) my being confused as to why Tensorflow was in the ‘AI Software’ segment and (2) not knowing where to place software like Clarifai (explained below) that have few adjustable parameters but could be used as a block in a larger AI model. But it turns out Google Cloud’s APIs don’t allow for much parameter-adjusting. You just throw e.g. an image at it and it spits out results. So we’re fine there.
One example of a building-block would be clarifai, which helps you label images.
You can connect these blocks to your own services. For example, you might want to use the tags produced by Clarifai to search through your database of photos to see which would go with a user’s blog post.
Caveat: I was happy with my interpretation until I revisited the segment description, which says AIaaS ‘allows developers to build models and generate predictions in the cloud’. Clarifai allows people to generate predictions (image labels) in the cloud, but it doesn’t allow people to build models. But neither does Google Cloud Platform really, unless the differentiating factor is that Google Cloud has infrastructure through which people can combine models since they providing hosting services. I don’t buy that providing APIs AND hosting services in separate products makes for a ‘type of product’. Those are two different products Google Cloud Platform are offering. So making ‘infrastructure’ a differentiating fator would make any hosting service where people can put things together AIaaS. That seems wrong. I decided to allow for a more generous interpretation of ‘building models’ and move on. 😛
Segment 3: AI Software
How then do we differentiate between AIaaS and AI software?
The general idea behind these three segments seems to be that each subsequent segment is less constrained than the one before it, though those constraints may be in different dimensions and thus not be comparable. The first segment limits how you execute your AI agent, e.g. it has to be a Facebook Messenger chatbot. The second segment does not limit your mode of execution. The second segment places limits on the model and thus the accuracy of the model for specific applications. If AI as a Service does not provide you with models that are precise or accurate enough (say it doesn’t provide accurate enough image recognition for self-driving cars), you build your own AI software from scratch or using open source tools.
At this point I will mention my second source of confusion. From the perspective of the product team itself, many products – Facebook Messenger and Google Cloud’s Vision API included – are ‘AI software built from scratch’. This does not mean that we put them in the third segment. All this time we have been talking about segmenting from the perspective of the user because products are used by users. E.g. The user sees Clarifai as a building block, even though (obviously) the developers can change what’s in that building block.
There are two further things we need to do here. The first is clarifying the difference between AIaaS and tools like TensorFlow. The second is recognise that ‘your own AI software’ – like x.ai, which schedules meetings for you – and ‘open source tools you use to build AI software’ are characteristically very different, but both seem to fall under the same segment. We need to make sense of or resolve this tension.
Let’s first tackle the difference between AIaaS and open source tools like Tensorflow. More precisely, we are considering the distinction between (1) using a model to build a unit of AI (Tensorflow) and (2) using a block of AI to enable a service or to combine with other AI (AIaaS). The difference between the two seems to be the level of abstraction of the parameters you can alter. With clarifai, you can’t alter the parameters at all (which immediately disqualifies it from being a model), so let’s take an example like GoButler, which I argue falls within AIaaS. GoButler is a travel search assistant and can help you book flights. You can change parameters like ’this is how much I care about my flights taking a short period of time relative to them being cheap’. These parameters are ones that the user directly works with.
This is in contrast to TensorFlow, which has higher-resolution, less abstract parameters like ‘I want this to be a neural network with 5 layers and weights that are updated like this.’ If we wish to be precise, we can define AIaaS’ level of abstraction as ‘parameters non-technical users could interact with’.
The difference between TensorFlow and Google Cloud Platform’s APIs can also be visualised as the difference between (1) a module or a filter and (2) a wrapper. Tensorflow is a like a wrapper. It wraps your model. Google Cloud is like a filter or module. You put something in, you take something out. You don’t alter the things inside the module. The module is itself closed AI software possibly with ‘wires’ that allow them to be connected to other products.
It is worth noting that the difference between AIaaS and tools for building AI is NOT whether or not it can be combined with other AI. Everything should eventually be able to work with or talk to some other AI in some form. In that sense everything will be a building block in a part of a larger model. It is thus the type of involvement that is the differentiating factor.
Now for our second question: where do products that leverage AI to help you do things go? Also known as ‘Where does x.ai fall in this model?’
I think there are two coherent answers. The first is to say they don’t belong in any of the three segments because they are not used in producing AI. That would suggest that this ‘AI market’ framework is terribly incomplete – it fact, that it is leaving out most ‘AI products’ out there. That would be sad. The solution would be to add a fourth ‘everything else’ segment, which is a copout.
The second answer would be to put them in Segment 2: AI as a Service. NOT Segment 3, AI Software.
This may seem counterintuitive at first. Didn’t I say before that if AIaaS wasn’t precise enough, you should build your own AI software? And so it would be one level of precision and freedom BEYOND AIaaS and fall into the ‘AI Software’ segment? But this falls back into the perspective misperception – you are looking from the point of view of the producer, not the user.
To the user, your AI software is a building block. For x.ai, the user CCs the agent in an email and the agent processes the emails and produces output – a natural language email discussing meeting time options, or an action that schedules the meeting once the other person has confirmed their availability. The user does not actively tinker with what’s inside the module.
Moreover, that building block – your AI software – can talk to or give input to other AI. This seems particularly likely with the advent of smart assistants like Siri and Google’s Allo (horizontal AI). I’ll write more about building blocks talking with smart assistants when we discuss the next framework and also when we get to Rand Hindi’s talk about AI assistants that protect people’s privacy (Snips), so watch out for those posts.
At the end, you might ask ‘who cares’? What value is there to knowing whether a product falls into the segment ‘AI as a Service’ or ‘AI Software’?
Generally, frameworks can help you understand companies working in completely different industries. As much as people are sick of hearing about companies that are ‘Uber for X’, that expression makes it easy to understand approximately what the core function of the company is and where they fit into the general landscape.
The problem with the analogy I just used is that most companies within this framework fall into ‘AIaaS’, so this only gives a more precise character to the minority of products that are either ‘AI Platforms’ or ‘AI Software’. This might seem useless but it’s also very useful in that if we know most companies are this type of building block, the logical next step is to prepare for these blocks coming together to form more thread-like experiences. And that’s my main takeaway.
Stay tuned for the next two articles on the following frameworks: