Expert Systems Essay, Research Paper

INDEX + What are Expert Systems? + The relationship between Expert systems and Artificial Intelligence. + Structure of Expert Systems. + Designing an Expert System. + Building Expert Systems. + Knowledge Engineering. + Tools, Shells and Skeletons. + Software and Hardware considerations in Expert Systems. + What are the uses of Expert Systems. + Advantages and Disadvantages of Expert Systems. + How Expert Systems work (Examples of Expert Systems). + The Importance and future of Expert Systems. + Putting it all Together. What are Expert Systems? Expert Systems (ESs), also called Knowledge-based systems (KBS) or simply Knowledge systems (KS), are computer programs that use expertise to assist people in performing a wide variety of functions, including diagnosis, planning, scheduling and design. Definitions of Expert Systems vary, some definitions are based on its function, others are based on its structure. Expert Systems are meant to solve real problems, which normally would require a specialized human expert. Building an expert system therefore first involves extracting the relevant Knowledge from the human expert in a way that can be used by a computer, which is generally a difficult task that requires its own expertise. ESs are derived from a branch of Computer Science research called “Artificial Intelligence” (AI). AI’s scientific goal is to understand intelligence by building computer programs that exhibit intelligent behavior. It is concerned with the concepts and methods of symbolic inference, or reasoning, by a computer, and how the Knowledge used to make those inferences will be represented inside the machine. Building an Expert System is known as Knowledge Engineering and its practitioners are called Knowledge Engineers, a Knowledge Engineer has the job of extracting this Knowledge and building the Expert System Knowledge base, he must make sure that the computer has all the Knowledge needed to solve a problem, he must also ensure that the computer can use the knowledge efficiently by selecting from a handful of reasoning methods. Expert Systems have been used to solve a wide range of problems in domains such as medicine, mathematics, engineering, geology, computer science, business, law, defense and education. Within each domain, they have been used to solve problems of different types. Types of problems involve diagnosis, design and interpretation. The appropriate problem solving technique tends to depend more on the problem type than on the domain. The Relationship between AI and Expert Systems AI is concerned with precisely the same problem that DSS is concerned with, that is, decision making, one fundamental difference is that the objective of those in the AI community is more ambitious than that of the DSS sector. The purpose of AI is not simply to support decision-making; the ultimate goal of AI is to develop an intelligent machine that will itself make decisions. The computer despite its enormous capacity for data storage simply could still not store all the knowledge necessary to simulate all facets of human intelligence. However, AI scientists decided that, at least for the time being, development and research in AI should be as follows: + More Modest. + More Focused. + Directed towards a narrow sector of expertise. And the name given to this sub-field of AI was ESs or knowledge-based systems. Structure of Expert Systems + Every Expert System consists of 2 principal parts (See Fig.1): 1. The Knowledge Base. 2. The reasoning or inference engine. The Knowledge base of expert systems contains both Factual and Heuristic Knowledge. Factual Knowledge is that Knowledge of the task domain that is widely shared, typically found in text books or journals, and commonly agreed upon by those Knowledgeable in the particular field. Heuristic Knowledge is the less rigorous, more experimental, more judgmental Knowledge of performance. Heuristic Knowledge is rarely discussed, and is largely individualistic; it is the Knowledge of good practice, good judgement, and plausible reasoning in the field. Knowledge representation formalizes and organizes the Knowledge; one widely used representation is the production rule, or simply rule. A rule consists of: IF part and THEN part (Also called a Condition). The IF part lists a set of conditions is some logical combination. The piece of knowledge represented by the production rule is relevant to the line of reasoning being developed if the IF part of the rule is satisfied, consequently, the THEN part can be concluded, or its problem-solving action taken. ESs whose knowledge is represented in rule form is called Rule-Based systems. Another widely used representation, called the unit (also known as frame, schema, or list structure) is based upon a more passive view of knowledge; the unit is an assemblage of associated symbolic knowledge about an entity to be represented. Typically, a unit consists of a list of properties of the entity and associated values for those properties. The problem-solving model, or paradigm, organizes and controls the steps taken to solve the problem. One common but powerful paradigm involves chaining of IT-THEN rules to form a line of reasoning. If the chaining starts from a set of conditions and moves toward some conclusions, the method is called “Forward Chaining”. If the conclusion is known but the path to that conclusion is not known, then reasoning backwards is called for, and the methods is “Backward Chaining”. These problem-solving methods are built into program modules called “Inference Engines” or “Inference Procedures” that manipulate and use knowledge in the knowledge base to form a line of reasoning. Knowledge is almost always incomplete and uncertain. To deal with uncertain knowledge, a rule may have associated with it a confidence factor or a weight. The set of methods for using uncertain knowledge in combination with uncertain data in the reasoning process is called “Reasoning with Uncertainty”. Designing an Expert System + Designing an ES involves the following: 1. ES Architecture. 2. Choosing a Problem. 3. Knowledge Engineering. 1. Expert System Architecture: The user interacts with the system through a user interface, which may use menus, natural language or any other style of interaction. Then an inference engine is used to reason with both the expert knowledge and data specific to the particular problem being solved. The expert knowledge will typically be in the form of a set of IF-THEN rules. The case specific data includes both data provided by the user and partial conclusions based on the data. Almost all ESs also have an explanation subsystem, which allows the program to explain its reasoning to the user. Some systems also have a “knowledge Base Editor” which helps the expert or knowledge engineer to easily update and check the knowledge Base. 2. Choosing a Problem: Writing an ES generally involves a great deal of time and money, to avoid costly failures, people have developed a set of guidelines to determine whether a problem is suitable for an ES solution or not: + The need for a solution must justify the costs involved in development. + Human expertise is not available in all situations where it is needed. + The problem may be solved using symbolic reasoning techniques. + The problem is well structured and does not require (much) common sense knowledge. + The problem cannot be easily solved using more traditional computing methods. + Cooperative and articulate experts exist. + The problem is of proper size and scope. It should be clear that only a small range of problems is appropriate for ESs technology. However, given a suitable problem, ESs can bring enormous benefits. 3. Knowledge Engineering: Having decided that your problem is suitable you need to extract the knowledge from the expert and represent it using your ES shell. This is the job of the knowledge Engineer, but involves close collaboration with the expert and the end user. The knowledge engineer should be able to select a suitable expert system shell for the project, extract the knowledge from the expert and implement the knowledge in a correct and efficient knowledge base. The knowledge engineer may initially have no knowledge of the application domain. The knowledge engineer must first become at least somewhat familiar with the problem domain. Typically experts are set a series of example problems, and will explain their reasoning in solving the problem. The knowledge engineer will abstract general rules from these explanations and check them with the expert. Development must also involve close collaboration with potential users; also the basic development cycle should involve the rapid development of an initial prototype and iterative testing and modification of that prototype with both experts and users. In order to develop the initial prototype the knowledge engineer must make provisional decisions about appropriate knowledge representation and inference methods, to test these basic design decisions; the first prototype may only solve a small part of the overall problem. Building Expert Systems + Knowledge Engineering + Tools, Shells and Skeletons. 1. Knowledge Engineering: Knowledge engineering is the art of designing and building ESs, and Knowledge engineers are its practitioners. Today there are 2 ways to build an ES. They can be built from scratch, or built using a piece of development software known as “Tool” or a “Shell”. Though different styles and methods of Knowledge engineering exists, the basic approach is the same: a Knowledge engineer interviews and observes a human expert or a group of experts and learns what the experts know, and how they reason with their Knowledge. The engineer translates the Knowledge into a computer-usable language, and designs an inference engine, reasoning structure, that uses the Knowledge appropriately. He also determines how to integrate the use of uncertain Knowledge in the reasoning process, and what kinds of explanation would be useful to the end user. Next, the inference engine and facilities for representing Knowledge and for explaining are programmed by the Knowledge engineer, and the domain Knowledge is entered into the program piece by piece. It may be that the inference engine is not just right, the form of Knowledge representation is awkward for the kind of Knowledge needed for the task, and the expert might decide the pieces of Knowledge are wrong. All these are discovered and modified as the ES gradually gains competence. 2. Tools, Shells and skeletons: Currently there is only a handful of ways in which to represent knowledge, or to make inference engines, or to generate explanations. Thus, systems can be built to contain these useful methods without any domain-specific knowledge. Such systems are known as “Skeletal Systems”, “Shells” or “AI Tools”. The shell will provide the inference engine, a user interface, an explanation system and sometimes a knowledge base Editor, Given a new kind of problem to solve, we can usually find a shell that provides the right sort of support for that problem, so all we need to do is provide the expert knowledge. There are numerous commercial ESs shells, each one appropriate for a slightly different range of problems. Using shells to write ESs generally greatly reduces the cost and time of development. Building ESs by using shells offers significant advantages. A system can be built to perform a unique task by entering into a shell all the necessary knowledge about a task domain. The inference engine that applies the knowledge to the task at hand is built into the shell. If the program is not very complicated and if an expert has had some training in the use of a shell, the expert can enter the knowledge himself. Although shells simplify programming, in general they don’t help with knowledge acquisition. Knowledge acquisition refers to the task of endowing ESs with knowledge, a task currently performed by knowledge engineers. The choice of reasoning method, or a shell, is important, but it isn’t as important as the accumulation of high-quality knowledge. The power of an expert lies in its store of knowledge about the task domain, the more knowledge a system is given, the more competent it becomes.

Software and Hardware Considerations in ESs It in not necessarily the case that the same type of software and/or hardware used in Prototype development will be used in the final implementation of an Expert System. However, even when the software and hardware for development coincide with the choice for implementation, there are considerations that must be considered, these include: 1. The decision of whether to use a mainframe computer, minicomputer, microcomputers, dedicated workstations, or some combinations of these. 2. The number and types of microcomputers or workstations to use. 3. The networking of such computers. 4. The provisions for direct access to supporting database or other external programs. 5. The potential for using the computers for other tasks either than ESs. 6. The useful life of the software and hardware, and their potential for upgrading. In light of the rapidly changing status of supporting hardware and software, one should design the knowledge base with portability in mind, and this is just another way of saying that the knowledge engineer should, in general, avoid designing his or her rule-base solely about any specific set of hardware and software. What are the uses of ESs While ESs have considerable room for improvement, we should note that they are not just academic nations, rather, ESs have already been constructed and are being sold and/or implemented in diverse areas as follows: 1. Stock market advisors. 2. Commodity trading. 3. Financial planning. 4. Tax preparation and planning. 5. Granting of loans and determination of credit limits. 6. Diagnosis and treatment of various diseases. 7. Determination of the chemical properties of unknown compounds. 8. Scheduling and control of the automated factory. 9. Configuration and design of computers. 10. Diagnosis and maintenance of complex machinery. Advantages and Disadvantages of Expert Systems 1. Advantages of Expert Systems + Permanence – Expert systems do not forget, but human experts may. + Reproducibility – Many copies of an expert system can be made, but training new human experts is time-consuming and expensive. + Efficiency – can increase throughput and decrease personnel costs Although expert systems are expensive to build and maintain, they are inexpensive to operate. + Consistency – With expert systems similar transactions handled in the same way. The system will make comparable recommendations for like situations. + Documentation – An expert system can provide permanent documentation of the decision process. + Completeness – An expert system can review all the transactions, a human expert can only review a sample. + Timeliness – Fraud and/or errors can be prevented. Information is available sooner for decision making. + Breadth – The knowledge of multiple human experts can be combined to give a system more breadth that a single person is likely to achieve. + Entry barriers – Expert systems can help a firm create entry barriers for potential competitors. + Differentiation – In some cases, an expert system can differentiate a product or can be related to the focus of the firm (XCON) Computer programs are best in those situations where there is a structure that is noted as previously existing or can be elicited. 2. Disadvantages of Rule-Based Expert Systems: + Common sense – In addition to a great deal of technical knowledge, human experts have common sense. + Creativity – Human experts can respond creatively to unusual situations, expert systems cannot. + Learning – Human experts automatically adapt to changing environments; expert systems must be explicitly updated. + Sensory Experience – Human experts have available to them a wide range of sensory experience; expert systems are currently dependent on symbolic input. + Degradation – Expert systems are not good at recognizing when no answer exists or when the problem is outside their area of expertise. How Expert Systems Work We will show how ESs based on IF-THEN rules work by presenting: + A Simple Example. + Explanation Facilities + A Simple Example: Suppose that we have the following rules: 1- IF engine_getting_petrol AND engine_turns_over THEN problem_with_spark_plugs 2- IF NOT engine_turns_over AND NOT light_come_on THEN problem_with_battery 3- IF NOT engine_turns _over AND light_come_on THEN problem_with_starter 4- IF petrol_in_fuel_tank THEN engine_getting_petrol Our problem is to work out what’s wrong with our car given some observable symptoms. These are thress possible problems with the car: problem_with_spark_plugs, problem_with_battery, problem_with_starter. In the simplest goal-directed system we would try to prove each hypothesized problem in turn. Trying to prove the first of these 4 rules, the system will ask the user: + Is it true that there’s petrol in the fuel tank? If the answer is yes, this answer will be recorded, so that the user doesn’t get asked the same question again, the system now wants to find out if the engine turns over so the user will be asked: + Is it true that the engine turns over? If the answer is no, so the system will conclude that this is not the solution to the problem, and will consider the next hypothesis: Problem_with_battery. It will ask the user: + Is it true that the lights come on? If the answer is no, it has now proved that the problem is with the battery, so the system will conclude that the problem is with the battery. Note that in general, solving problems using Backward Chaining involves searching through all the possible ways of proving the hypothesis, systematically checking each of them. + Explanation Facilities: Most expert systems have explanation facilities that allow the user to ask why it asked some question, and how it reached some conclusion. These questions are answered by referring to the system goals, the rules being used, and any existing problem data. To illustrate the sorts of facilities commonly provided, we’ll elaborate on our simple example above, starting with a simple example dialogueInvolving why and how questions and explanations. System: Is there gas in the fuel tank? User: Yes. System: Is it true that the engine turns over? User: No. System: Is it true that the lights come on? User: Why? System: I am trying to prove: problem with battery. It has been established that it is not the case that the engine turns over. Therefore if it is not the case that the lights come on then there is a problem with battery. Is it true that the lights come on? User: No. System: I conclude that there is a problem with the battery. User: How? System: This follows from Rule 2: IF NOT engine_turns_overAND … NOT engine_turns_over was given by the user. NOT lights_come_on was given by the user. Providing such an explanation facility involves, at least, recording what rules are used in drawing conclusions, and using these records to compose explanations like the ones above. Giving simple explanations like those above is not very difficult (the answers always have a simple set form), and is sometimes quite useful. However, explanation facilities in expert systems are often not widely used, and where used not viewed as acceptable by their users. There are a whole lot of reasons for this, motivating current research in the area. One reason is that the explanations just reference the “surface” knowledge encoded in the rules, rather than the “deep” knowledge about the domain which originallymotivated the rules (but which is usually not represented). So, the system will say that it concluded X because of rule23, but not explain what rule23 is all about. (In the above example, maybe the user needs to understand that both the lights and the starter use the battery, which is the underlying rationale for the second rule in our example). Another stated reason for the frequent failure ofexplanation facilities is the fact that, if the user fails to understand or accept the explanation, the system can’t re-explain in another way (as people can). Explanation generation is a fairly large (and fascinating) area of research, concerned with effective communication: how to we present things sothat people are really satisfied with the explanation, and what implications does this have for how we represent the underlying knowledge. The Importance and Future of ESs The methodology of ESs is definitely here to stay, and it will play an increasingly important role in future decision making. When the population of the earth had reached five billion it might seem strange to point out that one particularly scarce resource is that of human experts. However, this is indeed the case and is most certainly a result of the increasing size and complexity of human endeavors. Most of the Expert Systems developed now are “stand-alone” Systems. However, in the very near future it is likely that a large portion (if not the majority) of the expert systems that are developed will be embedded systems, that is, systems that form only a part of the overall software package. Another form of the embedded expert systems is that of the so-called “intelligent interface”. Intelligent interfaces shall rely, more and more, on expert systems to better achieve user friendliness in software. Such a system will immediately determine whether or not the user is a “novice” or expert, and tailor its actions accordingly. That is, the novice will require more help, support and guidance, while the more experienced user will need minimal assistance. Another trend that we expect to continue is the increased development of smaller expert systems (expert systems having 200 or fewer rules), this particular prediction is, However, somewhat at odds with a commonly held belief of the AI community as expert systems developers believe that only large-scale expert systems are worth considering. However, with the advent of powerful, inexpensive expert system shells and with implementation on the personal computers, the development of small expert systems are highly cost effective. Putting it all Together In Fig.2, we have attempted to summarize the elements and their relationships, as they pertain to the phases of ESs development and implementation. Initially, we must identify the problem at hand. For example, just what is the problem? Where does it exist? Whom or what does it affect? once this has been accomplished, our next step is to document the problem through a detailed problem statement including the goals, objectives, constraints and variables associated with the problem. The problem statement should be placed into the form of a mathematical model. With a complete problem statement in hand, we should next try to match the problem with an appropriate solution methodology, if the most appropriate and cost-effective methodology is that of ESs, we have found a match that justified the use of the ESs approach. If we are able to justify the use of an ESs approach, we should next determine if a human expert exists and if so whether or not he or she may be utilized in the knowledge acquisition phase, if not we will have to resort to some other way to acquire the knowledge base. Then we may proceed to the prototype development phase, which consists of 2 interrelated efforts: knowledge acquisition, and knowledge representation, then we should begin to develop a firm plan for the ultimate validation and implementation of the Expert System. Finally, when we are satisfied that prototype development has been completed, we may proceed to the implementation phase, while implementation it may be necessary to perform some revisions even during this phase. Ultimately, if all of the previous steps are conducted properly, they should lead to the implementation of a working, successful Expert system. REFERENCES: 1. Books: + The development and Implementation of Rule-Based Expert Systems, James P. Ignizio. + Analysis and Design of Information Systems, Graham Curtis. 2. Internet: + Expert Systems and AI, Robert S. Engelmore & Edward Feigenbaum (http://itri.loyola.edu/kb/c1_s1.htm) + Introduction to AI and Expert Systems, Carol E. Brown and Daniel E. O’leary (http://www.bus.orst.edu/faculty/brown/es_tutor/es_tutor.htm) + An overview of Expert Systems, Dan Peak (http:///www.istis.unomaha.edu/dpeak/ISQA4350/Expertsys/index.htm) + Databases and Artificial Intelligence, Alison Cawsey. (http://www.cee.hw.ac.uk/ alison/ai3notes/all.html)