IBM’s Watson Plays Jeopardy!

In the 1990s IBM created Deep Blue, an AI application specifically designed to play chess. It was the latest in a series of chess-playing programs that IBM developed, and in 1997, during its second challenge match with Garry Kasparov, the world chess grandmaster, Deep Blue won the match. (Deep Blue won two games, Kasparov won one, and three games were drawn.) Those who studied the software architecture of Deep Blue know that it depended on brute force, a term computer people use to refer to the fact that the system relied on its ability to search millions of examples and evaluate millions of possibilities in a few minutes more than on its ability to reason. Specifically, Deep Blue used an approach that looked forward several moves for each reasonable “next move” and then chose the move that would yield the highest number of points. The fact that Deep Blue defeated a human grandmaster was impressive, but it didn’t immediately suggest any other applications, since the application was highly specialized to evaluate a chess board and select the next best chess move.

As the new millennium began IBM was looking around for another challenging problem, and wanted to find one with more applications than chess. IBM also wanted to explore new techniques being developed in AI labs. In 2004 IBM began to consider developing an application that could play Jeopardy!. Jeopardy! is a very popular TV game that draws large viewing audiences and offers some real challenges for a computer. In Jeopardy! contestants are given “answers” and asked to come up with the “question” that would lead to such an answer. The “questions” and “answers” used on Jeopardy! are drawn from a broad base of general knowledge on topics such as history, literature, science, politics, geography, film, art, music, and pop culture. Moreover, the game format requires that the contestants be able to consider the “answers” provided, which are often subtle, ironic, or contain riddles, and generate responses within about 3 seconds.

In essence, a Jeopardy!-playing application posed two different problems: understanding natural language so as to be able to identify the right question and then searching a huge database of general information for an answer that fits the question. Searching a huge database quickly was a more or less physical problem, but “hearing” and then “understanding” spoken English, and finally determining which of several possible answers was the right match for the question being asked, were serious cognitive problems.

In 2007 IBM established a team of 15 people, and gave them 5 years to solve it. The team in turn recruited a large staff of consultants from leading AI labs in universities and began. The first version was ready in 2008 and in February of 2010 the software application Watson proved it could beat two of the best known former Jeopardy! winners, Brad Rutter and Ken Jennings, in a widely watched TV match.

The key to Watson’s analytic functionality is DeepQA (Deep Question Analytics), a massively parallel probabilistic architecture that uses and combines more than 100 different techniques—a mixture of knowledge and neural net techniques—to analyze natural language, identify sources, find and generate hypotheses, and then evaluate evidence and merge and rank hypotheses. In essence, DeepQA can perform thousands of simultaneous tasks in seconds to provide answers to questions. Given a specific query, Watson might decompose it and seek answers by activating hundreds or thousands of threads running in parallel.

Watson maintained all its data in memory to help provide the speed it needed for Jeopardy! It had 16 terabytes of RAM. It used 90 clustered IBM Power 750 servers with 32 cores running at 3.55 GHz. The entire system runs on Linux and operates at over 80 teraflops (i.e., 80 trillion operations per second).

To sum up: IBM demonstrated that AI-based natural language analysis and generation had reached the point where a system like Watson could understand open-ended questions and respond in real time. Watson examined Jeopardy! “answers,” defined what information was needed, accessed vast databases to find the needed information, and then generated an English response in under 3 seconds. It did it faster and better than two former human Jeopardy! winners and easily won the match.

Unlike Deep Blue, which was more or less abandoned once it had shown it could win chess matches, Watson is a more generic type of application. It includes elements that allow it to listen to and respond in English. Moreover, it is capable of examining a huge database to come up with responses to questions. Today, the latest version of Watson functions as a general purpose AI tool (some would prefer to call it an AI platform) and is being used by hundreds of developers to create new AI applications.

Fukoku Mutual Life Insurance Company in Tokyo (Japan), for example, worked with IBM’s Watson to develop an application to calculate payments for medical treatments. The system considers hospital stays, medical histories, and surgical procedures. If necessary the application has the ability to “read” unstructured text notes, and “scan” medical certificates and other photographic or visual documents to gather needed data. Development of the application cost 200 million yen. It is estimated that it will cost about 15 million yen a year to maintain. It will displace approximately 34 employees, saving the company about 140 million yen each year, and thus it will pay for itself in 2 years. The new business process using the Watson application will drastically reduce the time required to generate payments, and the company estimates that the new approach will increase its productivity by 30%.

Google’s AlphaGo

While IBM was working on its Jeopardy!-playing application, Google acquired its own AI group and that group decided to illustrate the power of recent AI developments with its own game-playing system. Go is an ancient board game that is played on a 19 × 19 matrix. The players alternate placing black or white “stones” on the points created by the intersecting lines. The goal of the game is to end up controlling the most space on the board. Play is defined by a very precise set of rules.

When IBM’s Deep Blue beat chess grandmaster Garry Kasporov, in 1997, AI experts immediately began to think about how they could build a computer that could play and defeat a human Go player, since Go was the only game of strategy that everyone acknowledged was more difficult than chess. This can be exemplified by noting that the first move of a chess game offers 20 possibilities, whereas the first move in a Go game offers the first player a chance of placing the stone in any one of 361 intersections (Figure 17.1). The second player then responds by placing a stone in any one of the 360 remaining positions. A typical chess game lasts around 80 moves, while Go games can last for 150 turns. Both games have explicit moves and rules that theoretically would allow an analyst to create a branching diagram to explore all logical possibilities. In both cases, however, the combinations are so vast that logical analysis is impossible. Possible game states in either game are greater than the number of atoms in the universe. (The search space for chess is generally said to be 10⁴⁷, whereas the search space for Go is generally held to be 10¹⁷⁰.)

In October 2015 AlphaGo, a program developed by DeepMind (a subsidiary of Google), defeated Fan Hui, the European Go champion, five times in a five-game Go tournament. In March 2016 an improved version of AlphaGo played a tournament with the leading Go master in the world, Lee Sedol, in Seoul. AlphaGo won four games in a five-game tournament.

So, how does AlphaGo work? The first thing to say is that the core of AlphaGo was not developed as a software package to play Go. The basic neural net architecture used in AlphaGo was initially developed to play Atari software games. The Atari-playing program was designed to “look” at computer screens (matrices of pixels) and respond to them. When DeepMind subsequently decided to tackle the Go-playing problem, it simply re-purposed the Atari software package. The input that AlphaGo uses is a detailed 19 × 19 matrix of a Go board with all the stones that have been placed on it. The key point, however, is that the underlying AlphaGo platform is based on a generic software package designed to learn to play games; it’s not a specially developed Go-playing program.

AlphaGo largely depends on two deep neural nets. A neural network is an AI approach that depends on using various algorithms to analyze statistical patterns and determine which patterns are most likely to lead to a desired result.

As already noted, the basic unit being evaluated by AlphaGo is the entire Go board. Input for the neural network was a graphic representation of the entire 19 × 19 Go board with all of the black and white stones in place. In effect, AlphaGo “looks” at the actual board and state of play, and then uses that complete pattern as one unit. Winning games are boards with hundreds of stones in place. The unit that preceded the winning board was a board with all the final stones, save one, and so forth. A few years ago no computer would have been able to handle the amount of data that AlphaGo was manipulating to “consider” board states. (Much of IBM’s Watson’s usefulness is its ability to ask questions and provide answers in human language. This natural language facility isn’t really a part of the core ‘thought processes’ going on in Watson, but it adds a huge amount of utility to the overall application. In a similar way, the ability of AlphaGo to use images of actual Go boards with their pieces in place adds an immense amount of utility to AlphaGo when it’s presented as a Go-playing application.)

Note also that AlphaGo examined 100,000s of Go games as it learned to identify likely next moves or board states that lead to a win. A few decades ago, it would have been impossible to obtain detailed examples of good Go games. The games played in major tourneys have always been recorded, but most Go games were not documented. All that changed with the invention of the Internet and the Web. Today many Go players play with Go software in the Cloud, and their moves are automatically captured. Similarly, many players exchange moves online, and many sites document games. Just as business and government organizations now have huge databases that they can mine for patterns, today’s Go applications are able to draw on huge databases of Go games, and the team that developed AlphaGo was able to draw on these databases when they initially trained AlphaGo using actual examples (i.e., supervised learning).

One key to understanding AlphaGo, and other deep neural network–based applications, is to understand the role of reinforcement learning. When we developed expert systems in the late 1980s, and a system failed to make a prediction correctly according to a human expert, the developers and the human expert spent days or even weeks poring over the hundreds of rules in the systems to see where the system went wrong. Then rules were changed and tests were run to see if specific rule changes would solve the problem. Making even a small change in a large expert system was a very labor-intensive and time-consuming job. AlphaGo, once it understood what a win meant, was able to play with a copy of itself and learn from every game it won. At the speed AlphaGo works it can play a complete game with a copy of itself in a matter of a seconds.

As already mentioned, AlphaGo defeated the leading European Go master in October 2015. In March 2016 it played the world Go champion. Predictably, the world Go champion studied AlphaGo’s October games to learn how AlphaGo plays. Unfortunately for him, AlphaGo had played millions of additional games—playing against a version of itself—since October, and significantly increased its ability to judge board states that lead to victory. Unlike the expert system development team that was forced to figure out how their system failed and then make a specific improvement the AlphaGo team has simply put AlphaGo in learning mode, and then set it to playing games with a version of itself. Each time AlphaGo won it adjusted the connection weights of its network to develop better approximations of the patterns that lead to victory. (Every so often the version of AlphaGo that it was playing against would be updated so it was as strong as the winning version of AlphaGo. That would make subsequent games more challenging for AlphaGo and make the progress even more rapid.) AlphaGo is capable of playing a million Go games a day with itself when in Reinforcement Learning mode.

As impressive as AlphaGo’s October victory over Fan Hui was it paled by comparison with AlphaGo’s win over the Go champion Lee Sedol in March of 2016. Fan Hui, the European Go Champion, while a very good player, was only ranked a 2-dan professional (he was ranked 633rd best professional Go player in the world), while Lee was ranked a 9-dan professional and widely considered the strongest active player in the world. Experts, after examining the games that AlphaGo played against Fan Hui, were confident that Lee Sedol could easily defeat AlphaGo. (They informally ranked AlphaGo a 5-dan player.) In fact, when the match with Lee Sedol took place (4 months after the match with Fan Hui) everyone was amazed at how much better AlphaGo was. What the professional Go players failed to realize was that in the course of 4 months AlphaGo had played millions of games with itself, constantly improving its play. It was as if a human expert had managed to accumulate several additional lifetimes of experience between the October and the March matches. Lee Sedol, after he lost the second game, said that he was in shock and impressed that AlphaGo had played a near perfect game.

AlphaGo was designed to maximize the probability that it would win the game. Thus, if AlphaGo has to choose between a scenario where it will win by 20 points with an 80% probability and another where it will win by 2 points with 99% probability it will choose the second. This explains the combination of AlphaGo’s very aggressive middlegame play, but its rather conservative play during the endgame. It may also explain the difficulties that Lee Sedol seemed to have when he reached the endgame and found many of the moves he wanted to make were already precluded.

To beat Lee Sedol, AlphaGo used 1920 processors and a further 280 GPUs—specialized chips capable of performing simple calculations in staggering quantities.

In spring 2017 AlphaGo was at it again, playing Chinese Grandmaster Ke Jie, and once again winning. The AlphaGo team announced following that victory that their program would “retire” and that Google would focus on working on more pressing human problems. Their work on helping clinicians diagnose patient problems faster, for example, is getting a lot of attention.

What was impressive about these last games was not the wins, but the buzz around the innovations that AlphaGo had introduced into Go play. We are all becoming accustomed to the idea that AI systems can acquire vast amounts of knowledge and use that knowledge to solve problems. Many people, however, still imagine that the computer is doing something like a rapid search of a dictionary, looking up information as it is needed. In fact, AlphaGo learned to play Go by playing human players. Then it improved its skills by playing millions of games against itself. In the process AlphaGo developed new insights into what worked and what didn’t work. AlphaGo has now begun to develop approaches—sequences of moves—that it uses over and over again is similar situations. Students of Go have noticed these characteristic sequences of moves, given them names, and are now beginning to study and copy them.

One of the sequences is being referred to as the “early 3-3 invasion.” (Roughly, this refers to a way to capture a corner of the board by playing on the point that is three spaces in from the two sides of the corner.) Corner play has been extensively studied by Go masters and—just as openings have been studied and catalogued in chess play—experts tend to agree on what corner play works well and what is to be avoided. Thus grandmasters were shocked when AlphaGo introduced a new approach to corner play—a slight variation on an approach that was universally thought to be ineffective—and proceeded to use it several times, proving that it was powerful and useful. Indeed, following AlphaGo’s latest round of games Go masters are carefully studying a number of different, new move sequences that AlphaGo has introduced. More impressively, in games just after his loss to AlphaGo Chinese Grandmaster Ke Jie started using the early 3-3 invasion sequence in his own games.

All this may seem trivial stuff, but the bottom line is AlphaGo introduced serious innovations in its Go play. It isn’t just doing what human grandmasters have been doing; it’s going beyond them and introducing new ways of playing Go. In essence, AlphaGo is an innovative player! What this means for the rest of us is really important. It means that when Google develops a patient-diagnostic assistant, and after that assistant has studied the data on thousands or millions of patients it will begin to suggest insights that are beyond or better than those currently achieved by human doctors.

The deep learning neural network technology that underlies today’s newest AI systems is considerably more powerful than the kinds of AI technologies we have used in the recent past. It can learn and it can generalize, try variations, and identify the variations that are even more powerful than those it was already using. These systems promise us not only automation of performance, but automation of innovation. This is both exciting and challenging. Organizations that move quickly and introduce these systems are going to be well placed to gain insights that will give them serious competitive advantages over their more staid competitors.

Knowledge-Based Approaches

Knowledge-based systems represent knowledge in explicit ways and use the knowledge so represented to reason about problems. Different knowledge-based systems use different kinds of logical inferencing techniques to manipulate the knowledge to reason and draw conclusion.

To better understand the problem it’s important to have a basic idea of how a knowledge-based system was architected and created. A knowledge-based system traditionally consisted of three main elements: (1) a knowledge base, (2) an inference engine, and (3) working memory. In essence, early knowledge bases were composed of rules, each independent of all the others. Thus a single Mycin rule might be something like this:

• If    the site of the culture is blood, and
•          the morphology of the organism is rod, and
•          the gram stain of the organism is gramneg, and
•          the patient is a compromised-host,
• Then there is suggestive evidence (0.6) that the identity of the organism is Pseudomonas aeruginosa.

An inference engine is an algorithm that responds to input by examining all the rules in the knowledge base to see if it could arrive at any conclusions. In essence, the inference engine relied on the principles of logic (e.g., if A = B, and B = C, then A = C). If it could reach any conclusions it stored them in working memory. Then the algorithm began again, treating the information in working memory as new input and checked to see if it could reach any other conclusions. At various points the application would fire rules that would ask the user questions and use the answers, which it placed in working memory, to drive still more analysis. To make things more complex the rules were associated with confidence factors (e.g., 0.6) that allowed the system to reach conclusions in which it was more or less confident. (Keep in mind that most of these rules were derived from human experts, and a lack of complete confidence is very typical of the knowledge used by many human experts.)

In the sample rule given above, if the inference engine sought to evaluate the rule it would consider one If clause at a time. It would begin by seeking to determine if the site of the culture was blood. If it could find this information in working memory it would assume it as a fact and proceed. If it didn’t find this fact it might ask the physician what the site of the culture was, and so forth. Without going into more detail it’s possible to see that an expert system depended on explicit statements of knowledge in the form of rules. These rules are complex and require careful testing. A large expert system might rely on a knowledge base with hundreds or even thousands of rules.

To build an expert system a developer needed to sit down with a human expert and work with the expert to elicit the rules. The expert and the developer would consider cases, examine scenarios, and systematically develop rules that an expert might use to analyze a case and prescribe one or more responses. Together they would estimate the confidence that each rule should express, and then they would test the resulting rule base against dozens of cases to refine it. The development of a knowledge base for a significant expert system was a very time-consuming and expensive process—just the opportunity costs of having a world-class human expert focus on the development of software, rather than on using his or her expertise to focus on problems the company actually faced, cost a great deal. The development of an expert system could take months or even years.

Unfortunately, once built, tested, and found to work, most expert systems began to degrade as knowledge of the particular domain continued to evolve and the knowledge base of rules became dated. Human experts are constantly attending conferences, discussing new cases and new technologies, and reading books and journals to stay up to date, while the new expert system was forced to wait until new rules could be added before it could use the latest knowledge. By the late 1980s most companies began to abandon the quest for expert systems as they found that maintaining the systems they had built was proving too expensive to justify the effort. Even more to the point, there weren’t that many human experts waiting to be turned into expert systems.

In essence, the rule-based systems developed in the 1980s were too fragile, limited, and too slow. The existing technology could capture the expertise, but it couldn’t automatically learn new things or update its knowledge. By the end of the 1980s most AI researchers in universities had stopped focusing on developing rule-based applications and had begun to explore new approaches that seemed to offer better chances for learning and more flexible ways of storing knowledge.

As an aside, when we discussed AI in the 1980s we often said that academic AI research was focused on a variety of techniques, including not only knowledge use but also natural language applications and robotics. At the time, however, there were no commercial examples of natural language or intelligent robotic applications.

As a second aside, as a consultant who specialized in teaching IT people about AI in the 1980s I can report on the profound change that the brief focus on AI in the 1980s produced. Commercial computing had begun in the 1960s when most large companies began to acquire mainframes to help with their data storage, bookkeeping, inventory, and payroll. The rapid growth of computing meant that many companies hired and trained programmers to use specific software languages (e.g., COBOL) and to develop specific types of applications (e.g., bank payroll systems). There weren’t any computer science courses in most colleges in the 1960s. Many of these people thought of computing rather narrowly. For many, when they first began to learn about expert systems they learned more about the underlying theory of computer science than they had before. Many were intrigued with the idea that computer systems didn’t need to follow a specific set of steps, but could use an inference engine to interrogate users and modify its activities as its working knowledge changed. Others found confidence techniques fascinating. Mycin, just like a human expert, usually didn’t decide that a patient had a specific type of infection. Instead, it concluded that the patient might have any of three or four different kinds of meningitis, with different degrees of confidence. Since some infections can quickly prove fatal, Mycin often recommended more than one drug to treat three or four different possibilities. Programmers had come to think that software systems always generated a correct answer and had to adjust to the fact that computers could also provide multiple estimates or guesses. The whole approach used to develop knowledge systems ended up fascinating IT developers. Instead of laying out a path knowledge engineers acquired rules one at a time, put them in a systems knowledge base, and then tested the system to see if it could solve a problem. As they added knowledge the system became smarter. The idea of developing a system incrementally, and testing and revising it to improve the system, had a profound impact on IT development practices in the 1990s. Expert systems development was the ultimate example of Agile software development. Similarly, although more technical, the AI systems in the 1980s introduced software developers to the ideas behind object-oriented programming that led to extensive changes in how software is engineered today.

Although the interest in commercial AI faded in the late 1980s, and disappeared by the mid-1990s, the people who had done the exploration remained and went on to other jobs. (Most advanced computer games and a lot of sophisticated Internet and web techniques are applications of AI techniques.) The specific technologies that had been explored and commercialized in the course of that decade also remained. The companies that had developed software tools for expert systems development, for example, looked for other tasks they could assist with. Many of the expert systems–building tools were repurposed to assist business people who were focused on capturing business rules. Instead of trying to capture the rules used by human experts, rule-based tool vendors sought to position their tools to capture modest sets of rules that were used to describe business policies. These applications proved valuable in efforts to help organizations comply with laws and policy requirements of various kinds.

Other commercial developers saw an opportunity to help their organizations by providing tools to help extract patterns and advice from the large databases that organizations began to struggle with in the late 1990s. AI commercial activity in the 1980s provided most IT people with their first taste of AI techniques, and provided a clear understanding of some of the practical problems that AI systems would have to overcome if they were to prove commercially viable.

Neural Networks

In the early 1980s, when expert systems were all the rage, most of the attention in the AI world was focused on knowledge-based systems. There had been an early period of interest in neural network systems, but funding for the neural network approach had largely dried up when networks had failed to achieve results in tests of natural language processing. In the 1990s, with more powerful computers available, neural networks because the focus on most AI research.

Connectionist machines, adaptive systems, self-organizing systems, artificial neural systems, and statistically based mapping systems are all terms occasionally used to describe what we will refer to here as neural networks. Neural networks are said to be based on biological neural networks, but in fact they only resemble a biological network in a rather limited way.

Neural networks are systems of nodes, “neurons,” or processing elements that are arranged in multiple layers. The nodes are connected by links that at any given moment either pass information or don’t pass information from one node to the next. As information is passed certain connections become stronger. As specific outcomes or results are reinforced, pathways become stronger and the network comes to identify specific pathways with particular outcomes. This process is termed training. As the network is exposed to more data and reinforced it continues to modify its outcomes and is said to learn.

Figure 17.2 shows three process elements stacked to form a parallel structure or layer. Note that inputs may be distributed among processing elements and that each processing element produces at least one output.

Figure 17.3 pictures a multilayer network composed of 14 processing elements arranged in an input layer, two hidden layers, and an output layer. Inputs are shown feeding into processing elements in the first layer, each of which is connected to processing elements in the next layer. The final layer is called the output layer. Hidden layers are so termed because their outputs are internal to the network. This simple network has weighted connections going from input-processing elements in the first hidden layer to processing elements in the second hidden layer, which in turn has weighted connections leading to the output layer. In other words, each output from a processing element in one layer becomes the input for processing elements in a subsequent layer, and so on. Theoretically, any number of processing elements may be arranged into any number of layers. The limitation is simply the actual computing power available and the functionality of the net.

We’ve already gone into more detail than any business manager will need to know. One way to think of neural networks is as a collection of algorithms, each particularly suited (but not restricted) to a different application domain. In neural network terminology the terms algorithm and network are often used interchangeably. The term network can be used in a generic way (i.e., not referring to any specific type of network) or it can be used to refer to a specific algorithm (or learning rule), such as a back propagation network.

Any book on neural networks at this point would begin considering various types of neural network algorithms and what each was best suited to analyze. For our purposes, suffice it to say that there are a lot of algorithms, that they involve very technical considerations, and that knowledge of these algorithms is growing very rapidly. Most business managers will never need to understand the specific algorithms, but most large companies will want an IT employee, or a consultant, who does understand them and can help figure out which ones are appropriate to the problems your company faces.

Neural networks are said to be intelligent because of their ability to “learn” in response to input data and to adjust the connection weights of multiple nodes throughout the network.

Combined Approaches

Today there is a growing emphasis on combining the two approaches. Neural networks provide an excellent way to develop a powerful system. Moreover, the system can learn and become more powerful. Unfortunately, if someone asks how the system is making a decision the developer can only fall back on an algorithm and statistical data, which isn’t very satisfactory. Rule- or knowledge-based systems are hard to develop and maintain, but they offer explicit statements of the knowledge used and the logical path followed. Increasingly, the trick is to do all of visual, auditory, and nonlogical processing with neural networks, and to supplement those systems with small knowledge-based systems that can provide explicit explanations for just those tasks or subtasks where humans are likely to want an explanation.

Let’s consider developing AI systems to manage a self-driving auto. You can use explicit algorithms to compare the auto’s GPS location and the coordinates of the destination. Then you use a mapping systems to plot a course. You use neural network– based visual systems to actually “look” at the environment as the car proceeds along its route. You will also need a system that combines rules and neural networks if you are going to include a natural language system to talk with the rider. And you will probably use a rule-based system to apply legal rules to assure that the car stops at stop signs and follows other rules of the road. Increasingly, AI development involves knowing when to combine various AI techniques.

The Analysis and Redesign Phases of a Project

As process analysts move from the understanding phase of a redesign effort and begin to carry out in-depth analysis, AI will generally function like any other technology that you use to automate a process. Specific business activities will usually remain, but will switch from being done by humans to being done by AI systems. In the example pictured in Figure 17.7, which we assume was prepared during the redesign phase, we assume that problems with the reserve car activity will be solved by replacing the existing phone-answering operation with a neural network application that will answer phones, talk to customers as they seek to establish reservations, agree to reservations, and record this information. Normally, we don’t show IT applications supporting core processes when we prepare diagrams like this, but we do in this case to focus attention on the fact that one of the subprocesses is an AI application.

If we continued to play out this example the process redesign team, probably made up of business managers and employees, business analysts, and perhaps an IT and AI specialist would develop software requirements for the AI reservation system to be developed and then pass those requirements on to an appropriate IT group during the implementation phase of the overall effort. The IT group would use a neural network development methodology to develop the actual software application required and then work with the process team to test and ultimately implement the new neural network application. The process group and the IT group would also need to establish plans with the day-to-day process management team to monitor and oversee changes in the neural network application. One would assume that, no matter how much advanced training the application received, once it started talking with customers online, began booking reservations, and so forth the system would modify its behavior and might even develop new approaches to some specific types of situations. The managers of the process and IT would want to be prepared to support the system to assure that everything ran smoothly and that useful innovations were captured and used elsewhere if appropriate.

A Quick Review

Earlier we suggested that commercial attention focused on rule-based AI technologies in the 1980s was stimulated in part by the success of two expert systems, Dendral and Mycin. It’s probably fair to say that the current round of commercial interest in AI is being driven by the popular successes of two cognitive game-playing applications: IBM’s Watson, which won Jeopardy!, and Google’s AlphaGo, which defeated the world’s leading professional Go player.

These victories in themselves aren’t of too much value, but the capabilities demonstrated in the course of these two victories are hugely impressive. In the case of Watson it’s now clear that applications can be provided with natural language interfaces that can query and respond to users in more or less open-ended conversations. At the same time Watson is capable of examining huge databases and organizing the knowledge there to answer complex, open-ended questions. In the case of AlphaGo it’s equally clear that an application capable of expert performance can continue to learn by examining huge online databases of journals and news stories, or by working against itself to perform a task faster, better, or cheaper, and can improve very rapidly.

We’ve looked at recent advances in several ways. We’ve contrasted them with the rule-based approaches used in the 1980s. We’ve briefly considered the role of large databases and machine learning, and how pattern-matching algorithms have advanced the state of the art. We’ve also considered the basics of neural networks and recent advances in deep neural networks and reinforcement learning that have made today’s neural networks much more powerful than earlier versions. We specifically considered two demonstration applications: IBM’s Watson, which won at Jeopardy!, and Google’s AlphaGo, a cognitive system that just beat the world champion Go player. Each of these topics has emphasized some basic themes.

There have been no major technological breakthroughs. All the basic technologies being used have been around for at least two decades. There have, however, been minor technological breakthroughs, and these in turn have forced researchers to review older techniques and reevaluate their power. Thus deep neural networks, various types of feedback techniques, and reinforcement learning have been combined with techniques for searching massive databases and the steady growth of computing power to generate a powerful new generation of AI applications.

New applications are being designed around architectures that combine lots of different techniques (sometimes the same technique used in multiple different ways) running on multiple machines, which results in lots of different problem-solving approaches leading to exciting new solutions.

AI does not describe a specific technology or even a well-defined approach to computing. The term is not being used in the rather focused way that expert systems was used in the 1980s. Instead, the term is being used to describe a broad approach to application development that combines a wide variety of different techniques. The applications being developed combine AI and non-AI techniques in complex architectures that include not only knowledge capture and knowledge analysis capabilities, but natural language, visual front ends, and large-scale database search capabilities.

One feature of AI applications that is very significant is the proved ability of some applications to rapidly learn and improve on their own in at least some circumstances. It was the heavy cost of development and the rigidity and the rapid obsolescence of completed expert systems that doomed the second round of AI commercialization. AlphaGo suggests that the third round of AI may enjoy a lot more success. One imagines future AI applications linked to the Internet and constantly reading journals, newsfeeds, and conference proceedings and then updating their knowledge and simultaneously improving their problem-solving capabilities.

Although we haven’t gone into much technical detail it’s clear that most of the developers working at commercial organizations today will have to work very hard to ascend the steep learning curve that the use of the latest cognitive computing applications will require. The development of cognitive applications relies on integrating a variety of complex algorithms embedded in a variety of different neural networks and using rather esoteric techniques to train and improve the resulting applications. No one who has ever begun to explore the technologies and the knowledge bases that are required for the creation of a powerful natural language program will imagine that most companies could successfully hire people to develop a proprietary natural language application. Similarly, the effort required to build a powerful learning application, like AlphaGo, requires a very thorough knowledge of a vast number of new and complex learning algorithms that only a few corporate software developers currently know. This means that the growth and utilization of new, cognitive computing techniques and tools will depend on commercial organizations obtaining packaged modules to provide these capabilities, and then tailoring them for specific needs.

What is important for the readers of this book to know is that AI techniques will increasingly dominate software development and that computer systems will increasingly prove capable of duplicating what were previously thought to be human tasks. This in turn will require business process developers to reconsider what processes can be automated and to become more skilled in their analysis of tasks that humans currently perform. The techniques described in this book should enable process analysts to conceptualize the overall challenges implicit in AI-based business processes. At the same time, predictably, new process analysis techniques will be developed and will need to be mastered by developers who will increasingly have to analyze cognitive and decision management tasks of all kinds.