Docstoc

Expert Systems - DOC

Document Sample
Expert Systems - DOC Powered By Docstoc
					    Expert Systems
           Team 3
Modeling & Simulation - CS470




                Submitted By: Kyle Jefcik
                              Linesh Joseph
                              Kris Kortokrax
                              Andrea Lemkelde
                              Keith McDonald
                              Zach Nemitz
                              Jeremy Overesch
                Submitted To: Professor Gundelly
                Submitted On: May 5, 2003
Table of Contents
   Expert Systems Overview ........................................................................................... 3
   Development of Expert Systems ................................................................................. 6
     Identification ........................................................................................................... 7
     Conceptualization ................................................................................................... 8
     Formalization .......................................................................................................... 9
     Implementation ..................................................................................................... 10
     Testing................................................................................................................... 11
   Tools for Building Expert Systems ........................................................................... 12
     LISP ...................................................................................................................... 13
     PROLOG............................................................................................................... 13
     OPS5 ..................................................................................................................... 14
     EMYCIN ............................................................................................................... 14
     CLIPS .................................................................................................................... 14
   Knowledge Acquisition ............................................................................................ 15
   Dealing with Uncertainty in Expert Systems ............................................................ 17
     Monotonic vs. Nonmonotonic Reasoning............................................................. 18
     Probability Reasoning ........................................................................................... 18
     Certainty Factors ................................................................................................... 19
     Fuzzy Logic .......................................................................................................... 19
     Coherence Control ................................................................................................ 20
   Knowledge Representation and Rule Based Expert Systems ................................... 20
     Knowledge Base ................................................................................................... 21
     Inference Engine ................................................................................................... 21
     Forward and Backward Chaining ......................................................................... 21
             Examples ................................................................................................... 22
     Semantic Networks ............................................................................................... 23
     Frames ................................................................................................................... 23
     Scripts ................................................................................................................... 23
   References ................................................................................................................. 25
After a night out on the town in Las Vegas, Michael Knight drives through town early in
the day, in his trans am. The following conversation takes place:


K.I.T.T.:      Aren't you going to tell me?
MICHAEL:       There's nothing to tell.
K.I.T.T.:      According to my research, that's the first thing
               gamblers say when they lose.
MICHAEL:       Kitt, I wouldn't lie to you. I didn't lose.
K.I.T.T.:      That's the second.
MICHAEL:       I wish your 'research' had less on gambling and more on
               keys.
K.I.T.T.:      Michael, blank stock is extremely difficult to trace. (lights flash)
               April's calling.
MICHAEL:       Saved by the bell.


Having not heard of the popular television show Knight Rider, one would suspect this
conversation to have occurred between two people, perhaps a man and woman. This
conversation, however, is one between a man and his 1982 Black Pontiac Trans Am. The
trans am, KITT, could perform computerized tasks such as chemical analysis, data
processing and analysis, as well as voice recognition and synthesis. This example,
although fictional to say the least, is a good example of the aims for Expert Systems
development.

Expert Systems Overview
To understand the practicality and application of expert systems a person must know not
only the definition of an expert system, but the goals, the components, the possible
domains and example applications, the stakeholders, and finally the reasons to use expert
systems. The idea of expert systems began in the late 1960‟s and appeared in science
fiction movies as well as television series. It attracted attention along with the closely
related field of artificial intelligence. Artificial intelligence is embedded in the inference
portion of an expert system and assists in learning from mistakes or success of the
decisions made by the system. Common representations of expert systems include high-
level programs or applications modeling the knowledge of an expert or, ideally, a group
of experts.
       The definition of an expert system can be provided at a general level, but is hard
to define because of the dynamic and fast-paced nature. Edward Feigenbaum of Stanford
University first provided the definition of an expert system as “an intelligent computer
program that uses knowledge and inference procedures to solve problems that are
difficult enough to require significant human expertise for their solution.” (Castillo,
1991) More simply stated,an expert system is a computer system that simulates a human
expert‟s knowledge through facts and rules. The system stores this knowledge so that it
can draw logical conclusions, make decisions, learn from its mistakes, communicate with
other experts, both man and machine, and also explain how it arrived at decisions
(Castillo, 1991).
       The ultimate goal of an expert system is to surpass the knowledge of a human
expert (Castillo). To put the goals at a more achievable level the purpose of an expert
system would be to improve quality of knowledge, promote survival of current
knowledge, increase the accessibility of current knowledge, and lower the cost of
knowledge. To improve the quality of knowledge, samples of expertise can be taken
from multiple experts if not top experts with slightly different backgrounds. Increasing
the accessibility of current knowledge would promote training of new experts. Lowering
the cost of knowledge would benefit industries that aren‟t as attractive for experts or
where budgeting for an expert would outweigh the benefits of a project or task. With the
loss of an expert in an area the survival of knowledge could still continue through an
Expert System (Martin, 1988).
       Next we will look at the stakeholders or those involved in the production and
usage of an expert system. The obvious people involved include the user of an expert
system and the expert providing the knowledge base. The user can range from an expert
testing or improving the system to somebody who knows nothing about the domain, but
has an interest in making an educated decision. The not so obvious users include those
building the inference engine as well as the programmers organizing and representing the
system via a computer model. At a general level the interest in expert systems originates
at universities, research centers, computer manufacturers, large corporations, and
software companies (Castillo, 1991).
       Those with a vested interest in creating expert systems can provide multiple
reasons they chose to pursue the system. A few of the most popular reasons would be to
utilize non-expert personnel, to attain solutions for a problem efficiently, to lower costs,
to increase the reliability of conclusions drawn and success of solutions provided, and to
eliminate monotony an expert faces from solving similar problems over and over.
Another important concept that needs examination is the role of expertise in a fast-
changing field. This concept would require that knowledge be shared frequently and
non-discriminately to other experts. A computer model could share knowledge quickly
through software distribution or perhaps even a web-based project.
       The basic structure of an expert system helps to organize the components in a
recognizable pattern. The basic components of an expert system include a user interface,
a knowledge base, a knowledge acquisition facility, and an inference engine or
mechanism (Martin, 1988). Depending on the use of the system, either for probabilistic
or rule-based inferences, the components can include an explanation facility as well as a
self-training facility (Castillo, 1991). The user interface exists to communicate between
the system and its various users. It can accept facts about a situation, provide answers to
questions, and accept new knowledge. New knowledge, as well as original knowledge, is
stored as a knowledge base, usually in a database.
       This knowledge base can consist of facts and rules (Martin, 1988). Facts retain an
element of truth pertaining to a specific subject whereas rules provide an accepted
pattern. Rules can take on two forms. The first, a procedural rule, is well defined and
invariant and provides action in a fundamental sequence, like starting a car, or landing a
plane. A heuristic rule is a general rule referred to as a hunch, or rule of thumb. This
rule is used in a procedural fashion where a decision that has multiple choices must be
made (Rolston 1988). An example of this would be reacting in an emergency situation
such as deciding to continue on without breaks on your car, or choosing to smash into a
wall in hopes of stopping your car. The next component, a knowledge acquisition
facility, includes provisions for interaction with an expert user to attain new knowledge in
the system. The arguably most important component of an expert system is the inference
mechanism or engine. This component performs reasoning and logical calculations to
infer new ideas or solutions to the user (Martin, 1988). An optional component, the
explanation facility, is useful in rule-based systems. It can provide the means to arrive at
a solution or conclusion. A self-training facility accepts facts based on inferences the
system makes and compares them to previously stored facts to strengthen or weaken
existing knowledge of the subject.
       Expert systems can be applied to many different areas and fields of study and has
been since the early 1970‟s. Common domains applying expert systems include:
chemical, defense, education, engineering, finance, language, legal, manufacturing,
mathematical, medical, and sales. In the domain of finance, the TAXADVISOR system
was developed under Dr. Robert Michaelson at the University of Nebraska. This system
assisted in solving problems of personal finance and providing solutions for tax planning
problems. The software utilized information provided by the user ranging from health,
life insurance, tax-exempt savings, and accidents over the past year, to determine the best
way to utilize the United States tax system. This type of expert system software is
referred to as a consulting system. Similar products have been created in the medical and
environmental fields.

Development of Expert Systems
If an expert system is an appropriate solution to a problem, the approach towards the
development of the system should be done in an order of systematic steps. The process is
typically one that makes use of refinement and expansion of a prototype. The prototype
becomes the basis for further development and helps identify approaches that have the
most merit and others that should be discarded. When these decisions are made earlier in
the process, the cost of development is minimized drastically. Several approaches for
developing an expert system have been proposed, but the following is the most widely
accepted approach (Waterman 1986).


   1. Identification
   2. Conceptualization
   3. Formalization
   4. Implementation
   5. Testing


   These stages are greatly related and dependent on one another. An iterative process
continues until the software created consistently performs at an acceptable level. These
steps will be discussed further in depth throughout the rest of this section.
Identification
Identification is synonymous with the requirements analysis step carried out in most
traditional software development. This involves task analysis that will determine the
external requirements including the form of the input and output, setting where the
program will be used, and the determining the user. Participants, problems, objectives,
resources, costs, and the time frame all need to be clearly identified at this stage.
       The participants are the group of people sponsoring the creation of the system, the
domain expert and knowledge engineer. The domain expert is ideally an expert or
authority in the subject matter area that the expert system is for. This person needs to
have the time and interest to commit to the project. The use of domain experts is the
typical method of development, but sometimes-successful programs are created simply
using reference materials. This contradicts the accepted expert systems definition, but
these programs make use of programming techniques such as backward chaining to find
values for program parameters, explanation of program logic. Programs that do not
utilize an expert are known as knowledge based systems.
       To justify the time and cost of the development, the problem must be important to
a funding organization and be clearly defined. Although a developer can‟t ignore
interactions between the problem and the rest of the subject matter domain, there should
be considerable effort to limit the problem domain so that the recommendations of the
program will be specific and valuable. Choosing the depth of the program rather than
complexity of the program makes it much more powerful and useful, but it is generally
more efficient to minimize the amount of information that must be obtained from a user
before recommendation can be made. Specific goals and purposes of the software needs
should be described and accepted by everyone involved. All too often developers will
simply make the objectives problem solving, completely forgetting about the needs of the
end user. It is important to remember how much a properly designed interface means to
the user and the program in general. This usually is lost in the hustle to complete the
knowledge base.
       Funding and time are major resources to be considered. Additional resources to
be identified include knowledge sources, computer hardware, and development software.
These estimates can often be difficult, as with most programming projects, but they still
need to be realistic. Budgeted costs should include the time that a programmer and
expert put into the ongoing effort of maintaining the knowledge base along with an
estimate of the savings of valuable time in the future years. A realistic appraisal of the
costs and benefits can help establish the level of program detail that can be justified.
       Hardware for the delivery of the program can greatly affect the choice of
computer used for development. The developer needs to determine the extent of help
messages, graphics, questions asked, and the extent and format of output needed to
interact with other programs and databases. Many troubleshooting and classification
problems require input based on sensory information from the environment. Also, high-
resolution graphics can be vital to some applications. This can be advantageous to reduce
potential confusions on the user‟s part in answering questions posed by the program. The
less experienced the user is with computer hardware and software, the more important
and more effort must be made by the design of the user interface. Expert systems are
beneficial because program flow can be presented to the user on demand, an ability that
should be exploited if the user is likely to be skeptical of “black box” computer output.
Conceptualization
The second stage in expert system development is conceptualization. This stage involves
designing the proposed program in order to ensure the interactions and relationships in
the problem domain are correctly understood and defined. This stage is where the key
concepts are determined, the relationships between objects and processes are formed, and
the control mechanisms are shaped. The conceptualization stage also commences the
knowledge acquisition and involves the characterization of the situation and determines
the expertise needed in order to solve the problem. There are eight key questions that are
used to fully understand what the expert does.
   1. Exactly what decisions does the expert make?
   2. What are the decision outcomes?
   3. Which outcomes require greater reflection, exploration or interaction?
   4. What resources or inputs are required to reach a decision?
   5. What conditions are present when a particular outcome is decided?
   6. How consistently do these conditions predict a given outcome?
   7. At what point after exposure to influential inputs is a decision made?
   8. Given the particulars of a specific case, will the outcome predictions of the
       knowledge engineering team be consistent with those of the expert?


   A common approach to knowledge acquisition is to characterize the questions the
end-user may have for the domain expert and the range of possible solutions. This can be
done by building a range of final recommendations and building pathways to them.
Once this stage is completed, the development process is just a refinement and addition
of detail based on the work of this step.
       The job of the knowledge expert is primarily to identify the sources required by
the domain expert when making a specific recommendation. This includes determining
the reference books to be consulted, calculations to be made, computer programs to be
executed, and what heuristics come into play. Information the user will not know should
be determined and represented by additional rules or knowledge structures. Once this is
completed, additional information needed to apply these rules can be obtained either from
the user or additional rules can be created. This structure can be created through frequent
and intensive interview sessions with the domain expert.
       The information collected forms the basis of the scenarios to be presented with
the next session with the expert. Accurately describing the expert‟s problem solving
logic is difficult since the true experts usually do not know how they reach a decision and
they are ineffective at stating their own problem solving process. The careful study of
cases often reveals consistent patterns in the solution process that are still obscure.
Needed refinements to the concepts and relationships will become apparent during in-
depth analyses.
Formalization
The next stage of the expert system development process is formalization. This stage
involves organizing the key concepts, sub problems, and information flow into formal
representations. The program logic is designed at this stage. It is useful to group the
knowledge collected, possibly attempting to display the problem solving steps
graphically. The formalization phase is difficult to separate from the conceptualization
phase, and in the majority of real world applications, these stages are performed in
parallel. The two key items in the formalization stage are refinement of the knowledge
pieces in their relationships and hierarchy and more accurately determine the expected
user interaction with the system.
       It is the job of the knowledge engineers to build a set of interrelated tree structures
to represent the knowledge base. They must decide the attributes to be determined to
solve the problem and which attribute should be asked of the user, or represented by an
internal set of decision trees. Although decision trees are appealing in their simplicity
and are a good way to commence formalizing knowledge into a knowledge representation
scheme that can be visualized, things are usually not this simple in practice, and a tree
structure is seldom satisfactory.
       The representation of knowledge is important for credibility and acceptance by
the user. The questions asked and rules examined should be in the same sequence as
used by the human expert. This can be determined by presenting the expert with several
detailed scenarios.
       The problem domain must be analyzed to find unseen behavioral and
mathematical models that may be contained in the decision making process. The
characteristics of the information needed must be recognized. As the uncertainties are
defined and explained, the relationships involved become better understood and may
ultimately be explained using programming techniques in a more expedient manner. The
program development process functions as a knowledge gatherer that can be used to
explore poorly understood relationships.
Implementation
The next stage is implementation. This stage involves mapping or coding the formalized
knowledge into the framework of the development tool to build a working prototype.
The knowledge structures, inference rules, and control strategies developed in the
previous stages are all organized into a suitable format. Many times knowledge
engineers will use a program development tool to build a working prototype to document
and organize information collected during the formalization stage. At this point the
implementation is completed. If this has not already been accomplished, the notes from
the conceptualization and formalization stages are now coded.
          At this point, attention should be given to the long-term maintenance. It should
be anticipated that modifications to the knowledge base would be made over time. For
this reason the knowledge base should be extensively documented as it is coded. This
minimizes the potential for later misunderstandings and confusions. Detailed
explanations should be included to aid the user in fully understanding the questions asked
by the program in order to fully understand the output and show how the
recommendation was logically derived.
          The amount of help included with the program is dependent upon the end user. A
consultant will be interested in achieving the result, whereas a user who will actually
accomplish the recommendation will need to know the credibility of the response. The
end user needs to view the assumptions the recommendation is based on, along with the
justification for it.
Testing
The final stage of expert system development is testing. This is much more than just
finding syntax errors and fixing them. This includes verifying all the individual
relationships, validating the overall performance, and evaluating the utility of the
program. The testing stage guides the reformulation of concepts and redesign of the
representations. Verification and validation occur during the entire development process.
Verification proves the models are true relationships. It also ensures the knowledge is
accurately depicted by having the domain expert operate the program for all possible
contingencies.
          The most difficult task in the testing stage is accurately handling the uncertainty
that is contained in the expert system. The most common way of handling the
uncertainty is with certainty factors. Verification of the certainty factors assigned to the
knowledge base is a trial and error process. Each iteration of the process refines the
initial estimates by the domain expert until the level of certainty satisfies the expert. To
ensure the accuracy, all possible solution channels must be assessed.
There are four main areas of concern during validation
   1. Correctness, consistency, and completeness of rules
   2. Ability of the control strategy to consider information in the order that
       corresponds to the problem solving process
   3. Appropriateness of information about how conclusions are reached and why
       certain information is required, and most critical
   4. Agreement of the computer program output with the domain expert‟s
       corresponding solutions


   Allowing many people to review and recommend improvements enhances testing. A
formal project evaluation is appropriate to determine whether the entire system meets the
intended goal. This evaluation process uncovers problems with the credibility,
acceptability, and utility. This can be determined from the accuracy that is determined
from the comparisons with the real world environment.

Tools for Building Expert Systems
       Many different tools can be used to create an Expert System, but most are AI
based languages. These systems are designed to handle symbolic processing. They
range from the very broad, flexible tools, to specific, specialized tools.
       Most systems can be classified into one of three different types: High-level
languages, environments, and tools. High-level languages, such as LISP and PROLOG,
are used for creating almost any kind of expert system. Because they are much less
specific, there is a greater amount of programming required to make an expert system
using a high-level language. Environments are usually based on a specific high-level
language. However, they have prewritten “libraries” of code that can be used for specific
tasks. Using code already written and available for use saves time. A tool is used for
quick development of knowledge systems. It knows about more about a specific type of
system and addresses a specific problem class. Because it has specific strategies for
representation, control, and inference, it greatly simplifies the creation of an expert
system.
       There is a large assortment of software that can be used for creating an Expert
System. These include LISP, PROLOG, OPS 5, EMYCIN, and others. LISP and
PROLOG are high-level languages; OPS 5 is closer to an environment; while EMYCIN
is closest to a tool.
LISP
LISP is a programming language used specifically for development of AI systems,
created by John McCarthy in 1958. The language uses symbolic expressions in its
programs, rather than just numbers. This data is represented in the computer as linked
lists and uses a great deal of recursion. All programs and data are represented as lists;
therefore programs can be used as data in other programs. This allows simplified
solutions to complex situations.
        LISP uses two basic structures, the atom and the CONS node. The atom is a data
object that cannot be broken down. Each atom has a property list of information about
itself. A CONS node is a structure of two pointers to other LISP objects. They can be
linked together to create any structure desired. Because LISP has pointers, it depends on
dynamic storage allocation. However, the memory management is automatic and not
necessary for the programmer to worry about. Objects can be simply added to a structure
by creating a new node and rearranging the pointers. This provides great flexibility to the
programmer, by eliminating the burden of dynamic memory management.
        There are downfalls to this system, however. It was expensive, didn‟t integrate
well with other languages, and it only worked on a limited number of computer
architectures.
PROLOG
PROLOG implements a simplified version of predicate calculus. PROLOG stands for
PROgramming language for LOGic and was developed by A. Colmerauer and P. Roussel
in 1972. It is also designed for symbolic computation and is efficient at list processing.
In PROLOG, a person simply needs to specify facts about objects and relationships, state
rules about these objects and relationships, and then ask questions about them. It comes
up with answers to the questions though logical deduction of the rules and facts.
        PROLOG requires two different programming styles. It has a declarative style,
where the person tells the system the information it needs to know and the system
manages the procedures to get the answers. When brand new expert systems are being
built, a procedural style is used to tell the system how it should go about deducing the
proper answers. The declarative part is more common with normal users, who do not
need to know procedures, and simply give facts and ask questions.
OPS5
OPS5 is a language written in LISP during the 1970s and 1980s that aimed to pattern
human memory and cognition. Originally it was developed at Carnegie-Mellon
University to test a hypothesis that production rules were sufficient to explain human
cognitive behavior.
        OPS5 is started with no data in the working memory. The user than supplies sets
of facts into the working memory. The program then checks a set of rules against the
data in memory. These rules have two halves: a condition half LHS, and the action half
or RHS. If any of the if statements, the conditional element, are true, that rule is set to
fire. After all the rules have been checked against the memory, the ones that have been
recognized have their action half executed. After the memory has been updated, the
sequence is iterated again, until the program is halted or no more conditions can be true.
EMYCIN
EMYCIN was created from MYCIN, which was specific to medical diagnosis. The
creators of MYCIN found that there were two distinct parts to MYCIN, the knowledge
base, and the inference engine. Therefore, they removed the knowledge base, kept the
inference engine, and ended up with an “empty” MYCIN that could be used for other
MYCIN-like consultation systems. It was the first knowledge engineering tool.
        This system contains all the information for reasoning, without the knowledge
base. Because it is more specific, EMYCIN is defined more as a tool than a language. It
is a O-A-V/rule processor which uses backward chaining. This tool is a less specific tool
stemming from MYCIN. MYCIN originally came from INTERLISP, which was created
in the LISP language.
CLIPS
CLIPS is a more recent expert system development tool which was initially created in
1985 and has been updated through fall of 2002. The C Language Integrated Production
System (CLIPS) was originally started at NASA‟s Johnson Space Center. It was created
as an alternative to LISP, because C was a conventional language that was available on a
great number of platforms. As of 1991, CLIPS contains both procedural and object-
oriented programming. It currently supports C++ compilers as well as newer Windows
and Mac development interfaces. The software package now exists for the public domain
and is no longer maintained by NASA.
       Besides being public domain and easily portable, CLIPS also has the following
features. It can be used as subroutine integrated into other languages, such as Java, C,
and FORTRAN. It also boasts verification and validation features for checking newly
created expert systems.
       These are only a few of the Expert Systems created. However, each falls on a
continuum between high-level languages and specific tools. The device to use is highly
dependent on whether or not a similar system has been created before, the complexity of
the system to be created, the knowledge of the different devices available, and general
preference over certain languages. The primary AI languages, which appear to be the
base of most other systems include LISP, PROLOG, and CLIPS.

Knowledge Acquisition
Generally, knowledge acquisition is defined as "the process of eliciting and enumerating
the knowledge of an expert in a particular field (domain) so that this expertise can be
coded into an expert system" (Bride and Blount, 1989). During this stage most of the
knowledge required to create a decision support system is acquired, analyzed, and
organized.
       Knowledge acquisition is one of the most important elements in the development
of expert systems. The two important people involved for the development are the
knowledge engineer and the domain expert. This involves collecting information from an
expert, transforming the knowledge into code, testing and providing improvements.
       Knowledge acquisition is a process where the knowledge engineer gets
appropriate information out of an expert and then presents it into a manageable form.
There are three main approaches in acquiring knowledge. First the knowledge engineer
can interview the experts. This involves face-to-face interview between the knowledge
engineer and the expert. The engineer collects as much as information as he can by
asking lots of questions and through discussion. A second approach is “Learning while
being told”. Here there is a conversation or a discussion between the expert and the user-
interface. Through this the expert bases his/her representation of the knowledge from
what he/she understood. Finally the knowledge engineer can learn by observation. Here
the expert solves a sample problem or case study by applying an algorithm, a process
known as Induction.
       No matter how the knowledge engineer decides to acquire his/her information,
there are five main steps to each of the methods. First the knowledge engineer identifies
the key problems. During this stage the knowledge engineer becomes aware of the
domain, sets goals and knows to select appropriate experts and other useful materials.
Next, they define how the concepts and the relations that exist are outlined and related to
by the experts. Third, the engineer maps or organizes the tasks, relations and information
into formal representation. After formalization, the obtained knowledge is implemented.
Implementation involves putting the knowledge rules into a structured form and building
a prototype to test the design. Finally, the system is tested for its efficiency, accuracy and
also to see if it‟s functioning properly. This test is carried out as a small test problem or
scenario.
       Before the knowledge engineer acquires the knowledge, the expert should
partition it. Partitioning involves dividing up the expert system knowledge base. Varioius
approaches include development utilizing several separate knowledge bases, using rule
sets or separating the control plan from the domain knowledge. Partitioning the
knowledge base will also make the information easier to maintain and understand thus
increasing flexibility. After obtaining knowledge, the engineer should document it. This
is very important, as it requires planning, obtaining rules from sessions and addition to
the knowledge base. It contains descriptions and relationships. An up-to-date
documentation includes printed information, which is useful for future reference and
modifications.
       When gathering knowledge, knowledge is usually categorized in the following
way. First, there is procedural knowledge. This type of knowledge is sequential which
causes us to perform automatically. It involves a response to stimuli and we know how to
perform. E.g.: While riding a bicycle, as we approach a bend we automatically make a
sharp turn. Secondly there is declarative knowledge. This type of knowledge can be
expressed in words or in a manner that cannot be done at a procedural level. Here the
expert is able to verbalize the surface-level knowledge e.g. making a sharp turn or ties a
shoelace. There is also semantic knowledge. This knowledge determines if the expert
does the given job. This is the knowledge that accounts for facts, vocabulary, concepts
and definitions that are organized as: words & symbols, meanings & rules, and
relationships such as algorithms. Episodic knowledge is the knowledge encompassing
organized information along with the time and place of each event. The information is
grouped into chunks E.g.: trying to recall the speed limit and the choice of lane while
driving to work is a difficult task. The only way it could be recalled is by videotape or
written notes.
       A way in which knowledge engineers should gather their information is by
“chunking” it. When information is chunked, information is organized into groups or
bulks of items, which are known as "chunks". These are processed individually, but are
recalled together. Chunking is useful in knowledge acquisition because it increases the
efficiency of storage. As experts process meaningful chunks the recall performance is
improved.
       A major problem occurring during knowledge acquisition is the fact that many
knowledge engineers are lacking in management and organization. Large systems
projects require highly structured management and organization. Within the organization
a lack of communication between the team members results from varying amounts of
time spent on systems and because of oral communication instead of written documents
or files. Another problem of large projects is that they are very time consuming and
expensive. These side effects reduce the ability to track the knowledge source for coding
or lead to: irrelevant or incorrect information gathering, an inadequate level of
knowledge obtained, poor documentation, or under-trained knowledge engineers. It is
very important that knowledge engineers are trained in all aspects of the knowledge
acquisition methods. An inexperienced person will not be able to obtain, classify and
represent the types of knowledge from the expert and therefore he/she would perform
very ineffectively.

Dealing with Uncertainty in Expert Systems
In most systems, one of the only certain things is uncertainty. Most statements are not
true or false, black or white, right or wrong. Decisions must be made based on
information that, along with having its own uncertainty, may also be incomplete or
random. Castillo and Alvarez put it best when speaking on uncertainty in a system: “…
Statements must be understood as possible rather than certain. (97)” In order to
understand uncertainty in an expert system, we will analyze the various measures of
uncertainty and the reasoning behind the use of each.
Monotonic vs. Nonmonotonic Reasoning
Monotonic, or one-directional, reasoning involves continuously adding truth to the
accumulated knowledge that has already been obtained. As a truth is discovered, it is
added to the list of truths that have been discovered previously, and the number of truths
is always increased. While this provides a consistent basis for reasoning, it must be
understood that in many systems, information that is discovered at any given time may be
incomplete or revised later. It must also be recognized that conditions for a system may
change, thus changing the truth-value of previously collected information. A monotonic
reasoning system makes uncertainty and change in a system difficult to account for.
       Nonmonotonic reasoning is adapted for a system with information that may be
continuously updated and revised. As explained by David W. Rolston, “A nonmonotonic
reasoning system tracks a set of tentative beliefs and revises those beliefs when new
knowledge is observed or derived. (91)” With a default assumption made, tentative
beliefs can be formed from this based on the default assumption and information that has
been acquired to that point. As new information is gathered, the default assumption and
tentative beliefs that have been built can be updated to reflect the truth that has been
gained. It is possible in a nonmonotonic reasoning system to add new truths to the system
that will cause a tentative belief to become negated, and therefore change the validity of
other beliefs in the system that were dependent on the initially changed belief. This
allows for greater flexibility that a monotonic reasoning system and is better suited for
human systems.
Probability Reasoning
It is believed by some that probability is the only way to effectively describe uncertainty
in a system and that other methods are simply unnecessary. While there are both
supporters and disbelievers of this notion, probability provides a definite solution to
quantifying uncertainty in a given system.
       For every event in a system, there is a probability that the event will occur and
there is a defined set of outcomes that may result. Associated with each of these
outcomes is a probability that it will occur given the event happens. The probability
associated with each outcome must be a value between 0 and 1, and the sum of the
probability of all outcomes must total 1 for the event. Each probability states the
likelihood of the specific outcome, and defines the level of uncertainty that is associated
with it: lower probability means more uncertainty in the outcome and vice versa.
       Expert systems typically result in many pieces of truth being used in conjunction
with one another, each with its own probability, and so probabilities must be combined
together to form overall probabilities for linked events and outcomes.
Certainty Factors
The concept of certainty factors was developed to avoid using probabilistic reasoning and
is applied to rule-based systems. Many times it can be difficult in an expert system to
accurately estimate initial and conditional probabilities of the system events and certainty
factors were developed to avoid this potentially inaccurate use of probability. A certainty
factor is a numerical value that ranges between –1 and 1, and expresses the extent to
which a given conclusion should be accepted based on acquired evidence. As the
certainty factor approaches 1, there is a higher level of belief in the conclusion, and as it
approaches –1, a higher level of disbelief. All certainty factors are based on a domain
expert‟s knowledge and experience. In a system that uses certainty factors, each rule of
the system must either add to belief of the conclusion or add to disbelief of the
conclusion. The overall calculated certainty factor is then equal to the total measure of
belief from the system minus the total measure of disbelief seen in the system.
Fuzzy Logic
Fuzzy logic is used in systems that deal with a large amount of inexactness and loosely
defined boundaries. In many human systems, it is nearly impossible to develop exact
definitions and classifications for all elements of the system. It is easier to develop sets
with loosely defined boundaries and associate elements based on the extent to which the
element fits those loose definitions.
       Instead of defining a probability, fuzzy logic defines a possibility. By developing
a “fuzzy set”, or a set of elements with loosely defined limits, elements can be placed into
the set by using a grading system, indicating the possibility of the element falling into the
set. The grading system, much like a probability, falls between 0 and 1, where 0 means
the element is definitely not within the set and 1 means the element is definitely within
the set. Fuzzy logic then allows for the creation of a membership function where the
transition of grades for an element can be gradual and not distinct. Essentially, fuzzy
logic is used to create a system with uncertainty that is described solely by human
concept and cannot be exactly defined.
Coherence Control
In any system with uncertainty, it is necessary to have coherence control in place. One of
the largest problems that can occur in an expert system is incoherence between collected
data in the system. When there are many sets of a system interacting, it can be very easy
for inconsistent and incoherent data to be placed in the system if there are no guards.
Before any information is acquired, all possible areas of incoherence between sets should
be noted and the proper safeguards should be implemented to be sure that incoherent data
is not accepted in the system.

Knowledge Representation and Rule Based Expert Systems
Another important aspects of an expert system is the knowledge it holds, and how that
knowledge is represented. Since an expert system is used to answer questions or solve
problems in a particular area of expertise, the knowledge the system holds needs to have
high integrity and organization. The knowledge of a system is possessed by its
knowledge base. This knowledge base characterizes a human expert‟s representation of
something existing in the world around us. The knowledge base is kept in computerized
form to allow a user to access this knowledge. The knowledge can be accessed in a few
different ways, but one of the most popular forms of accessing the data is through a set of
rules. Some human experts may have experiences where „rules of thumb‟ can be applied.
It is these types of rules, which allow an inference engine to separate knowledge in the
base into data that might be useful to the user, and data that is irrelevant. There are many
different types of expert systems that revolve around this type of structure. Some
examples are listed later as to how these components interact.
Knowledge Base
When discussing knowledge base it‟s important to categorize knowledge into data and
rules. Data is simply information, which may be stored in a database. A database may
hold this information in categories, but typically does not have any complex relationships
between the information that it holds. Data can be used in an expert system to describe
facts that would result from a series of questions, but not necessarily provide a solution.
All of this information collectively can be considered knowledge because there are
specific relationships holding this knowledge together. All aspects rely upon each other
to acquire results applicable to a user. A database simply sends out streams of data, but
the knowledge base can deduce things based on what it knows, and what results because
of that. In the end everything is just data, but knowledge is stored with the relationships.
An example of how a knowledge base might work with an inference engine is provided
later.
Inference Engine
An inference engine is a tool used to develop and maintain the relationships in an expert
system. This can be thought of like many other tools for developing and managing
computerized data such as spreadsheets or databases. Spreadsheets may contain
formulas, which allow some cells to be dependant on others. The inference engine can
make certain rules dependant on others so that the end result of all of the rules will be the
correct solution or answer that the user is looking for. The inference engine is also
responsible for gathering necessary information from the user to compare answers to the
knowledge base and find a path to the solution they are looking for based on
dependencies of the knowledge. Named inference engine, it infers data collected from
the user to knowledge in the base. One note to make about inference engines is that they
may not use boolean values to represent results within if statements. Most things in this
world are not 100%, so often percentages distinguish odds determined by the engine to
provide a probabilistic solution.
Forward and Backward Chaining
Inference engines are a key component of rule-based systems and may use forward or
backward chaining systems to determine a result. The knowledge base contains many
if/then rules and facts that are based on the results of the rules. The type of chaining
comes in when we desire certain information and have limited information to offer. An
example may be at the doctor‟s office. If we have symptoms, we could list these
symptoms to the doctor (an expert in his field), and he/she could take those symptoms to
determine what kind of illness we have. This would be an example of forward chaining.
He/she would look on a symptom-by-symptom basis until the illness had emerged. We
also may go to the doctor knowing what we have, and may be interested in learning how
we obtained this illness. We could give the doctor our illness, and then ask us questions
pertaining to our events in the previous days/weeks, and possibly determine the cause.
This would be an example of backward chaining, because we take the effect to find the
cause.
Examples
An example1 of the knowledge base and the inference engine in a rule-based system is
given below in an expert system for house repair. A plumber was interviewed to obtain
the information listed in the rules and outcomes.


Rule 1:
If you have a leaky faucet
And
If the faucet is a compression faucet
And
If the leak is in the handle
Then tighten the packing nut.


Rule 2:
If you've tightened the packing nut
And
If the leak persists
Then replace the packing.




1
    This example referenced from http://gise.org/JISE/Vol1-5/EXPERTSY.htm
This information would be stored in the knowledge base with the if/then, and/or
relationships as shown above. The inference engine may process through these rules
using backward chaining if it starts with the solution of replacing the packing, and then
verify that solution by asking the user questions to verify the results. The user questions
are only for information, which isn‟t in the knowledge base. The inference engine may
use forward chaining by asking the user for all of the information first. The inference
engine then takes this information and tries to apply it to different rules and see if it fits
any of the previously described problems. If it may fit, then it would relay the possible
solution to the user.
Semantic Networks
A semantic network is often used as a way to represent the knowledge in a knowledge
base. These networks are directed graphs that have vertices or nodes. These nodes are
considered concepts, and the lines connecting the nodes are relationships, which would
normally be directional. Semantic networks are somewhat of a standard when it comes to
machine-readable dictionaries. This is what makes it so effective for representing
relationships and concepts in a knowledge base.
Frames
A frame is an older more traditional way of representing knowledge in a knowledge base.
The frames hold a number of slots, which are like attributes of the frame. A frame may
have a general name like book, and its slots would contain title, author, color, etc. The
frames are very similar to object oriented programming. They can have relationships like
that of objects in a program like inherency some others. The largest problem with frames
is what‟s called the frame problem. This is the difficulty of managing different slots in a
changing world. Imagine having inherent objects in a program with data members and
member functions that wouldn‟t always be there. This becomes a lot of overhead when
relating different slots and frames.
Scripts
Scripts are similar to that of frames, but they are more generic, thus allowing more
flexibility. A script uses templates to achieve it‟s objective of representing the
knowledge in the knowledge base. The slots or tags used in scripts are set up more like a
template with fields rather than specific concepts. For scripts, you would take one thing
that can be generalized such as going to the library, and then the slots of the template
would contain the things, which happen almost every time you go there. These slots may
be look up a book, find the book, check out the book, or something of this nature.
References

Rolston, David. (1988). Principles of Artificial Intelligence and Expert Systems
       Development. New York: McGraw-Hill, Inc.

Castillo, E. & Alverez, E.. (1991). Expert System: Uncertainty and Learning.
        London: The Alden Press

Martin, James & Oxman, Steven. (1988). Building Expert Systems: A Tutorial.
       New Jersey: Prentice Hall

Harmon, Paul and King, David. (1985). Expert Systems: Artificial Intelligence in
     Business. New York: John Wiley & Sons, Inc.

Hayes-Roth, Frederick and Waterman, Donald A. (1983). Building Expert Systems.
      Reading, Massachusetts: Addison-Wesley Publishing Co., Inc.

Waterman, D.A. (1986). A guide to expert systems. Reading, MA.:
      Addison-Wesley Publishing Co., Inc.

Schmuler, Dr. Joseph. (1992). Expert Systems: A Quick Tutorial.
      Journal of IS Education, 4(3). Retrieved April 25, 2003,
      from http://gise.org/JISE/Vol1-5/EXPERTSY.htm

Riley, Gary. (1997). What are Expert Systems? Retrieved April 25, 2003 from
       http://www.ghg.net/clips/ExpertSystems.html

Alison. (1994). Rule-Based Systems. Retrieved April 25, 2003 from
       http://www.cee.hw.ac.uk/~alison/ai3notes/section2_4_4.html

Hartley, Roger. (Unknown). Representation of Procedural Knowledge for Expert
       Systems. Retrieved April 25, 2003 from
       http://www.cs.nmsu.edu/~rth/publications/RepProc.pdf

				
DOCUMENT INFO