Expert Systems
|
||||||||||||||
 | |
 |
 |
|
|
 | |
Neural Networks
AI today can be broadly split into two categories. One is "neural networks," which attempt to duplicate the neuronal activity of the brain to solve problems more esoteric intellectual qualities, such as speech, patterns, inductive reasoning and intuition. The second category is expert systems, which make the knowledge of experts readily available for solving problems.
Anyone who has worked with computers knows that they will not duplicate human neural networks in our lifetimes. Emulating just some of the activities of human intellectual behavior with a computer is a daunting task. Nevertheless, our insatiable curiosity combined with common sense will continue to produce useful expert systems.
Compare expert systems to "ordinary" computer systems or programs (refer to figure 1). The main components are a knowledge base, an inference mechanism and a user interface. The knowledge base is comparable to a data base; the inference mechanism to an algorithm. The user interface is self-explanatory.
Data Base versus Knowledge Base
One of the keys to understanding expert systems is understanding the difference between data and knowledge.
A data base contains data, which consists of facts, definitions and assumptions. With the popularity of programs like Excel, we're familiar with what goes into a data base.
A knowledge base contains knowledge, which may include everything that makes up a data base plus the relationships among the data plus the ability to update itself through usage. In other words, knowledge is not simply the ability to spew out a stream of data, but the ability to know and use the relationships of the data in a meaningful way, to be able to add to existing knowledge through learning experiences. There's no magic to bridging the gap from a data base to a knowledge base, just the demanding work of assembling the knowledge and the clever job of programming that holds it all together.
Algorithm versus Inference Mechanism
Another key to understanding expert systems is knowing the difference between an algorithm and an inference mechanism.
An algorithm consists of the equations, as well as the logic, relating data. According to a programming colleague, once you've got the algorithm, the programming is "straightforward." What often makes life difficult is that the task of programming usually includes defining the algorithm. This is partly because the jobs of system analyst and programmer have become less distant with the increased use of personal computers.
An inference mechanism consists of algorithms and the rules that relate the knowledge in a knowledge base. In reality, an inference mechanism or its twin brother, the inference engine, is an intimidating illusion that has emerged from the world of computer jargon. An inference mechanism is just a higher level programming language used to facilitate the development of an expert system in the same way that Lotus 1-2-3 and QuattroPro were higher level languages used to develop sophisticated spreadsheets. Today, one would never think of creating a spreadsheet without using a spreadsheet program. Similarly, one would not contemplate building a expert system without using an inference mechanism.
User Interface - No Deception Here
In ordinary computer systems, one sees user interfaces consisting of keyboards, track balls, mice, icons, digitizing boards, touch screens, and speech digitizers and synthesizers. Any of these may be used in expert systems. The only difference is the sophistication of the interaction.
An expert system may require a more complex entry and retrieval of information. For example, in BERT, (Bank expERT), an expert system used by the US Comptroller of Currency to check on the fiscal health of US banks, financial information is downloaded from a data base before the system is used by an investigator. An expert-system interface may also require the user to enter new relationships as it probes deeper into a problem. Complex graphic interfaces may be used in solving problems with spatial relationships.
The main reason for an expert system is to improve an existing operation by improving its profits, quality and/or security. This is done in three principal ways. First, an expert system can make the knowledge of a small number of experts available to many. Second, it can add uniformity to procedures and results where previously there may have been inconsistencies. Finally, expert systems can offer an active form of training - learning by doing.
Building an Expert System
The steps involved in building an expert system are illustrated in figure 2. As in any problem-solving endeavor, the first step is to identify and define the problem. It seems obvious, but one must go through the step for two reasons. First, it may reveal that there really isn't a problem (maybe technology addicts just want to feed their habit.) Second, defining a problem often points to a straightforward solution (for example, simply dumping an unprofitable product line rather than optimizing its production.)
Once a problem has been identified, the next step is to confirm the validity of the expert-system approach. Why go to what may be a lot of trouble and expense to build your own expert system when a close approximation already exists that can do the job as well as it needs to be done? On the other hand, if it's clear that an expert system is the right tool to use, then plunge in!
Taking that plunge brings one into the deep, dark and murky waters of building the knowledge base. This step is generally acknowledged as being the bottleneck in developing expert systems. As shown in detail later, this is because of the difficulty of the task and the lack of people qualified in the many disciplines that can apply.
The next step is to select the appropriate inference mechanism. The inference mechanism may be part of a high-powered programming language such as LISP (introduced in 1958 by the same John McCarthy who first spoke the words artificial intelligence.) LISP stands for LISt Processing language, which helps organize and process knowledge in terms of lists of inter-related items.
Another type of inference mechanism may exist as part of an expert-system shell, like EMYCIN, which is an expert system with the knowledge removed. In general, one could say that the languages would be more open-ended but more difficult to use, while the shells would be easier to use but more restricted in application, usually by the number of rules that are used in solving any but the simplest problem. Not only do some experts find it difficult to verbalize their expertise, but they often use data which lack certainty. For example, how does one concretize expressions such as "very," "almost" or "large percentage," which humans use quite naturally as they describe something that is not easily quantified but that is needed to solve a problem? Translating such fuzzy knowledge into data and rules that can be manipulated by a computer is the task of the knowledge engineer.
Characteristics of a Knowledge Engineer
The ideal knowledge engineer has good communications skills, intelligence, self-confidence and knowledge.
Good communications skills are needed to elicit knowledge from an expert. One has to listen well, but also stimulate the conversation when it gets slow or when the expert is distracted by other things, including his own profound thoughts. Tact may be needed to draw out some experts' thoughts on controversial or sensitive issues. And a tactful knowledge engineer will never suggest that the expert be replaced by the expert system.
Intelligence is a trait that is difficult to quantify. It has fuzziness. Suffice it to say that the knowledge engineer has to be a logical thinker, for the knowledge he gathers must be well structured before any thought is given to using it in an expert system. He must also be a lateral thinker, coming up with inventive ways of representing the knowledge being gathered. One sees this characteristic in people that are outspoken and good contributors in brainstorming sessions.
Self-confidence is needed in large doses to avoid being overwhelmed by an expert's knowledge or personality. The knowledge engineer has to forge ahead boldly with persistence and patience.
Finally, the knowledge engineer must know what he's talking about. He cannot properly interview an expert unless he has boned up on the subject beforehand - enough to be respected by the expert. He also requires a knowledge of programming, because the expert's knowledge will have to be organized to conform to whatever expert-system language or shell is used.
To complicate matters, the program used may depend greatly on the nature of the knowledge gathered. For example, a domain that has more data than rules might be better handled by a shell rather than a language. A domain requiring a lot of rules (hundreds and even thousands, to be less fuzzy about it) may be better handled by an open-ended language.
Commercial Opportunities
Opportunities to make money in the field of expert systems can be roughly grouped into selling support software, selling expert systems themselves and selling a service.
Support software falls into two categories: languages and shells. Turbo Prolog is a popular language that is readily available and costs less than $100. LISP is the best-known language, but one has to look far beyond the dealer's display case to find it. Expert system shells include VP Expert and EMYCIN. VP Expert, like Prolog, is commercially available at an affordable price and is reputed to be the best-selling expert system software on the market. EMYCIN is the shell that was left when the knowledge was stripped from MYCIN, an expert system developed in 1975 by physician and Stanford computer scientist, Edward Shortcliffe, to diagnose infections on the basis of symptoms.
Expert systems per se can be ready-made or custom-built. Some expert systems have been developed to solve specific problems and are now commercially available from the authors. Space History, at $199 is an example. This system helps one locate the 2000-plus satellites launched since Sputnik. One would have to have a special interest in astronomy to rush out and buy this product. On the other hand, there is Prospector, an expert system designed to facilitate the identification of probable sites for good deposits of mineral ore. On the more familiar front are programs like Q&A and Paradox. Although not called expert systems, both use ideas coming from research in AI. Q&A uses AI for its natural language interface, which facilitates data base entries. Paradox employs AI technology to help program users develop useful data relationships.
Custom-built systems consist mainly of military and financial applications. More applications are being found though, in areas such as process control where expert systems are ideally suited because the problem can be more clearly defined. For example, at the Maitland, Ontario-based DuPont plant, two employees took a couple of weeks to build an expert system to optimize the performance of two distillation columns. The result is annual savings of $200,000. In the more traditional financial field, Peat-Marwick developed its own loan-risk-assessment system, which can now be purchased from them. It's called Loan Probe and it comes in three modules at $8,000 each. Custom-building expert systems as a third-party developer is the primary business of firms such as Syntelligence Corp. of Sunnyvale, CA. The proliferation of expert systems may spur some growth in this area.
Selling a service represents another commercial opportunity. The service may include any or all of project management, knowledge engineering and programming. Since expert systems really are nothing more than a high-level-language approach to solving problems, many people familiar with the traditional computer industry should be able to make a fairly bumpless transition to the field of expert systems. Even hardware dealers not interested in selling such a service can take advantage by becoming more knowledgeable in the field even if it's only to recommend the right person to a customer in need.
Author
Donald A. Coggan, PE, is recognized internationally as an expert in the field of control systems design and training. In addition to consulting directly to clients in the United States and Canada, he has addressed groups throughout North America as well and in Europe and Asia. He is the originator of a design evaluation technique called "Specifying for Maximum Value" based on principles set out by the Society of American Value Engineers (SAVE). Mr. Coggan has authored numerous technical publications including a training system and accompanying software for instrumentation technician evaluation for the Instrument Society of America (ISA). He has also co-edited Fundamentals of Industrial Control, the flagship volume of the ISA's Practical Guide Series.
Return from this expert systems page
to the value engineering page.
