The AI Hype Train has left the station. You know you’re in the middle of a hype cycle when products and companies start using a term regardless of whether or not their product incorporates any of that technology. This is where we currently are with regards to the market for AI products and services. While there is a lot of great, new innovation that’s pushing the industry forward towards more intelligent systems capable of many of the challenging areas that have previously not been able to be solved due to extreme complexity or the need for human labor, there are just as many companies who are using the term AI as more of a marketing ploy or a way to raise money.

Many firms are claiming to be AI-enabled when all they have done is put some thin capability provided by a third-party library or API that doesn’t really transform their existing product into something that is inherently different with that new intelligent technology. One of the biggest offenders of this AI-as-a-buzzword is the entire Robotic Process Automation (RPA) market. While automation is they key word in this phrase, this corner of the process automation market somehow is identified not with the traditional workflow automation and Business Process automation or management (BPM) space that has existed for decades, but rather the more widely hype and strongly invested in AI space. This whole category is currently attempting to rebrand itself as intelligent and AI-enabled because they’ve added OCR or some other add-on. While automation is valuable and provides a ROI in and of itself, there’s no reason to conflate automation activities with intelligent activities. Automation is not intelligence.

What is automation?

Automation is not a bad word. The primary movement of the industrial revolution was to take much of what we were doing at the time with manual labor and automate that work so that we could achieve significantly greater productivity, quality of life, and transform society as a result. Automation is the process of applying technology to some repeatable task or process so that the task or process can be accomplished with predictable repeatability, lower total cost of operation, increased safety, and provide better efficiency. This is what we demand of most of our technology, and technology has delivered that value. In fact, technology continues to deliver increasingly greater value to enterprises and individuals, squeezing more efficiency and capabilities and increasing productivity on a daily basis. So, automation is good. There’s nothing bad about it.

Mechanization and the unleashing of power from steam and electricity, the development of the assembly line and factorization of manufacturing, and the evolution of computing and the Internet have truly revolutionized the way we work, live, and exist. However, while these are fundamentally potent and transformative technologies, they are not intelligent technologies. We can’t walk up to a steam engine and ask it to recognize who we are or answer a random question or even learn from its experiences. A web server is just a web server no matter how many times it’s served the same content to the same sort of people. Automation has provided enormous and fundamental value to society. However it is different than the value we are seeking from intelligent systems, because automation is not intelligence. Today In: Innovation

Intelligence is much more than automation

Humans demand more from intelligent systems than simply repeating or simplifying a repetitive task that requires zero cognitive skills. From the beginnings of what researchers have been attempting to do with AI, we’ve been striving for systems that can understand and comprehend their surroundings, learn from their experiences, make judgements and decisions that are based on rational thinking, handle new situations and apply their learning from previous experience, and perhaps even address bigger questions of self-awareness, consciousness, and more. These are complex problems AI researchers are trying to solve, and fundamental questions of cognition including self-awareness and reasoning.

The post Automation Is Not Intelligence appeared first on Artificial Intelligence.

Today we’ll talk about cases and solutions when Machine Learning (ML) as a Service doesn’t work. When this happens, your company shouldn’t start off with hiring a data scientist. The best option is to invest in a custom-made solution to solve your urgent business needs. Only then when you have a workable solution, can you dive into deep data science and create a proper team that can create an in-house data science solution.

Key Takeaways:

• The time when you don’t need to hire data scientists and when you should start investing into data science resources.
• Start building a comprehensive data science product not from the research, but from the end-to-end solution that solves business problems.
• People envisage a data scientist that has a balance of knowledge in relative subject matters, but in real life, you can barely find such an ideal candidate.
• Make your data scientists successful and productive. Any team that deals with data science has to be cross-functional with adjacent roles contributing to the end solution.
• Deliver end-to-end solutions that solve business problems rather than research papers.

Custom made end-to-end solution as a start

Here we should talk about classical data science, where you have data, goals and you need to build models to solve a pressing issue. The best way to do this is to jumpstart such a process by putting together bits and pieces of some ready-made services into a single workable product and show your customer a clear-cut result shortly. This can be done without any complex or global research, and you can comfortably formulate specifications taking into account all the feedback from your customer and create a more high-level data science product in the long run.

One of the biggest issues for any data science project is in formulating the specifications for it. The usual request is “create something for my company using data science. Analyze data for me.” This type of a job has lots of trials and errors. And having some custom basic end-to-end solution from the start lets you insert into it the needed extra services on the go. This allows us to provide insights and predictions into a particular business workflow much easier.

I believe that you should start to build your system from the ground up not from the data research, but for an end-to-end solution. And then bit by bit you can take out and insert the required services in the process.

How to do data science research?

You start with employing a data scientist that matches your company’s needs. You can use the standard data scientist chart: this employee should have a firm footing in the application environment, mathematics, and programming. Their business skills are essential to success. I believe that an understanding of the topical area is critical here because we are solving business issues. And the data scientist that solves more academic problems will be more focused on winning a Kaggle competition than addressing the business needs. It is important that this person understands the product development cycle. This way he builds up models and analyses data in such a way that it would be possible to be deployed in production.

For example, if a person is using R (language and framework for data scientists) we should note that it is more aimed at research and it is not production ready. Correspondingly the results of such research cannot be deployed in any end-to-end solution. Therefore, he should take note of this and work in pair with a programmer. Although in the above diagram we see that the data scientist should have hacking skills, in reality, this is not the case. In their vast majority, data scientists are not able to write quality code. And if you need not just the research but a solution then process-wise you need to have a data scientist working together with a data engineer.

CAP theory as analogy

It is impossible to have three database properties at once: consistency, availability, and partition-tolerance. This is the basic rule know to all developers. And this applies to a data scientist as well, as people envisage a data scientist on the overlap of these subjects, but in real life, you cannot find such an ideal candidate. Usually, people tend to lean one or another way in their work and keeping a balance is not always a priority.

In principle one of the solutions that we use ourselves is that a data scientist should have business insights, understand the math behind it and work together in tandem with a skilled developer. Of course, a proper data scientist should be able to write any semblance of code. But a data scientist should work with a data engineer, write and realize code being both responsible for the quality and sustainability of this solution.

The classic tragedy of a company that decides to initiate any data science research is in when a data scientist says “I’ve got 40000 lines of Python code on my PC, can you make it work in production?” And, of course, this is virtually impossible to do. So you have an issue at hand that all of the research is simply wasted.

Cross-functional teams

Any team that deals with data science has to be cross-functional i.e. it has to cover a whole stack of the solutions it writes. In a common infrastructure, there should be present a DevOps engineer, data scientist, data engineer, and a product developer writing the web app and/or mobile app. And this is a single team that is responsible for the result. They should work together and solve related tasks that are interconnected in their interactions.

All of this means that the whole team is responsible for the business result. This applies also to the transitionary research done by a data scientist which is impossible to use in production on its own.

Old-school vs. Vertical teams

To dig in deeper, let’s take a classic old-school layered company organization structure when you have a department of data scientists, operations, UI developers, big data department, QA engineers and so on. In this case, we have every project penetrating most of these teams. And the classic problem is that tickets and tasks are being thrown around by one team to another, and the real business goals are being watered down along the way and not solved in the end. So instead of this horizontal division, we have divided the teams vertically. This allowed us to create teams that see a clear-cut goal they need to achieve. And at the same time, they can improve their cross-skills, and boost their responsibility levels.

As a result, such teams began to deliver, Scrum and Agile started to work properly. It is not directly related to data science, but nevertheless, there is a standard mistake of many companies where data scientists work somewhere at a university and write mostly academic papers. It is a topic for a whole new article, but for now, you need to distinguish that there is a data scientist and a production data scientist. And you should aim at employing the latter one within your teams, and not let a data scientist work alone remotely.

The post How to Build a Better Data Science Team appeared first on Artificial Intelligence.

Signifying the growing popularity of Artificial Intelligence (AI), global research firm Gartner has predicted that AI will be virtually pervasive in almost every new software product and service by 2020.

Owing to its market hype, almost all established software vendors are working to introduce AI into their product strategies which is creating considerable confusion in the process.

The term ‘artificial intelligence’ was not even in the top 100 search terms on gartner.com in January 2016 but by May 2017, it ranked at number 7, indicating the popularity of the topic.

“As AI accelerates up the ‘Hype Cycle’, many software providers are looking to stake their claim in the biggest gold rush in recent years,” said Jim Hare, Research Vice-President, Gartner, in a statement.

“AI offers exciting possibilities, but unfortunately, most vendors are focused on the goal of simply building and marketing an AI-based product rather than first identifying needs, potential uses and the business value to customers,” he added.

Instead of using cutting-edge AI techniques for every solution, Gartner recommends vendors to use the simplest approach that can do the job.

“Software vendors need to focus on offering solutions to business problems rather than just cutting-edge technology. Highlight how your AI solution helps address the skills shortage and how it can deliver value faster than trying to build a custom AI solution in-house,” suggested Hare.

The survey also indicated that lack of necessary staff skills was the top challenge in adopting AI in the organisations.

Gartner said that AI can greatly augment human capabilities and the combination of machines and humans can accomplish more together.

The post Artificial Intelligence Will Power Almost Every Software by 2020: Gartner appeared first on Artificial Intelligence.