Building an Expert System.

Necessary Requirement for Expert System Development:

AND
Task does not
require common
sense
Task is not too
difficult
Task requires
only cognitive
skills
Experts can
articulate their
methods
Genuine experts
exist
Experts agree on
solutions
Task is not
poorly
understood
Expert System
development
Possible
Justification of Expert System:
OR
Task solution
has a high
payoff
Human Expertise
being lost
Human
Expertise scarce
Expertise
needed in many
locations
Expertise
needed in
hostile
environment
Expert System
development
Justified
When is Expert System development appropriate?
AND
Task requires
symbol
manipulation
Task requires
heuristic
solution
Task is not too
easy
Task has
practical value
Task is of
manageable
size
Expert
System
Approach
Appropriate
Nature
Complexity
Scope
Choosing a tool for building expert systems:
Does the tool provide the development team with the
power and sophistication they need?

Are the tools support facilities adequate considering
the time frame for development?
Is the tool reliable?
Is the tool maintained?
Does the tool have the features suggested by the needs
of the problem?

Does the tool have the features suggested by the needs
of the application?

Development Constraints:
Support Facilities: Pick a tool with adequate support
facilities.

Reliability: Dont build an expert system with a tool still
under development.

Maintainability: Pick a tool you will not have to
maintain yourself during expert system development.

Task Characteristics: Pick a tool with features
suggested by the problem and its application.
Basis of Selecting Expert System Tool:
What is nature of
the ES being built?
How will the ES be
used?
What is the nature of the
problem to be solved by
the ES?
What type of solutions
are suggested by the
problem characteristics?
What features are
needed in the ES itself?
What features are
needed in ES building
tool?
Which tool should I select
for a particular
application?
TASK CHARACTERISTICS
Problem Features
Application Features
Solution Features
System Features
Tool Features
Expert System Tools
Suggest Suggest
Suggest
Suggest
Require
Acquiring Knowledge from the experts:
DOMAIN
EXPERT
KNOWLEDG
E ENGINEER
Data, Problems, Questions
Knowledge, Concepts,
Solutions
Formalized,
Structured
knowledge
Knowledge
Base
Knowledge Engineering Paradox:
The more competent domain expert become, the less able
they are to describe the knowledge they use to solve
problems!

Dont be your own expert!!
Dont believe everything expert say!!
Problem solving by an expert in a familiar
and novel situation.
Interviewing the expert.
observational and intuitive approach.
Techniques for extracting knowledge from a domain
expert:
On-site observation: Watch the expert solving real
problems on the job.
Problem Discussion: Explore the kinds of data,
knowledge, and procedures needed to solve specific
problem.
Problem Description: Have the expert describe a
prototypical problem for each category of answer in the
domain.
Problem Analysis: Present the expert with a series of
realistic problems to solve aloud.
System Refinement: Have the expert give you a series of
problems to solve using the rules acquired from the
interviews.
System Examination: Have the expert examine
and critique the prototype systems rules and
control structure.

System Validation: Present the cases solved by
the expert and prototype system to other
outside experts.
Techniques for extracting knowledge from a domain
expert:
Difficulties in Developing an Expert System:
RESOURCES
PERSONNEL
EXPERT
SYSTEM
TOOLS
Knowledge
Engineers
Expert System
tool builders
Development
tools
Support
environments
Limitations of Expert Systems:
EXPERT SYSTEMS
ARE NOT
GOOD AT:
Representing
Temporal
Knowledge
Representing
Spatial
Knowledge
Performing
Commonsens
e reasoning
Recognizing
the limits of
their ability
Handling
Inconsistent
knowledge
Person Years Required:
Problem Area
P
e
r
s
o
n
a
l

Y
e
a
r
s

Common Pitfalls in planning an Expert System:
Choosing an appropriate problem:
I. Pitfall: The expert system development effort is addressing a
problem so difficult that it cant be solved within the constraints
set by the available resources.
How to avoid:

II. Pitfalls: The problem that the expert system is designed to solve will
not significantly alleviate the difficulty that motivated the
development effort.
How to avoid:

III. Pitfalls: The problem that the expert system addresses is so general or
complex that an excessive number of rules and database objects are
needed to describe the expertise adequately. Either it will take too long to
accumulate all the rules or the resulting system will run too slowly.

How to avoid:
Resources for building the systems:
IV. Pitfall: Only a limited amount of time exists in which to
build the expert system. Therefore it is decided to provide
the personnel necessary to build it in the allotted time
period.
How to avoid:

V. Pitfall: Management believes that an expert system is just
a computer program to perform some task. Therefore any
experienced programming staff can build one. All the staff
needs is the problem specification and the right
programming environment.
How to avoid:
Choosing the Expert-System building tools:
VI. Pitfall: Using the chosen tool, the development team finds it difficult to represent
the domain concepts and control structures needed to solve the problem.
How to avoid:

VII. Pitfall: The knowledge engineer picks the most familiar tool even though other
tool are better suited to the problem domain. If the tool is obviously ill-suited, the
knowledge engineer reworks the problem so that it fits the capabilities of the
chosen tool.
How to avoid:

VIII. Pitfalls: It is decided to develop the expert system in FORTRAN, PASCAL, C or some
other general purpose programming languages because the resulting system will
be smaller, faster and more portable. Unfortunately, this increases the
development time to some unacceptable length.
How to avoid:
IX. Pitfall: The tool chosen to build the expert system is found to contain
programming errors that prevent the use of many of the tools features. As a
result, the development team must spend a large portion of time tracking down
and correcting errors.

How to avoid:


Common Pitfalls in Dealing with the Domain Expert
Choosing the Domain Expert
I. Pitfall: The knowledge engineer has great difficulty
extracting high quality rules from the expert. Interaction
with the experts are laborious and seem to provide small
payoff.
How to avoid:

II. Pitfalls: The domain expert chosen for development work
cannot find enough time for the project.
How to avoid:
Interacting with the Expert:
III. Pitfall: Both in-house experts and outside experts who
interact with the prototype system during development have
trouble in correcting and modifying the systems rules. They just
are not sure what the rules mean.
How to avoid:

IV. Pitfalls: The rules generated by the expert are so short and
simple that they dont provide a high degree of accuracy
when used in complex situation.

How to avoid:
V. Pitfall: The expert no longer seems excited about helping
develop expert system and find the work somewhat
uninteresting and routine. The time that the expert makes
available for meeting with the knowledge engineer is steadily
decreasing.

How to avoid:
VI. Pitfall: The expert is not familiar with computers and doubts
that an approach using computers will be of any use.

How to avoid:

VII. Pitfalls: So many different experts are being used that the KE
does not have time to explore the reasoning process and one
or two experts in great depth. The result is a shallow analysis
of their problem solving techniques.
How to avoid:

Pitfalls during the Development Process
System Implementation:
I. Pitfall: During the system development, the knowledge of
the expert has become so entwined in the program that its
difficult to tell the experts knowledge from general
problem-solving knowledge and control or search
strategies.
How to avoid:

II. Pitfalls: After many months of interactions with the expert,
the KE has extracted hundreds of rules and has represented
them in high level KE language. However in implementing
the prototype ES and starting to test it, the KE finds that
many fundamental concepts were omitted from the rules.
How to avoid:
III. Pitfall: The ES is developed in a language that does not
provide built-in explanation facilities. After the system performs
well, the development team attempts to add mechanisms for
allowing the system to explain and justify its operations . The
team has difficulty in doing this.
How to avoid:

IV. Pitfalls: The ES has very large number of highly specific
rules. This slows system execution and makes the system
complex and unwieldy.

How to avoid:
System Testing and Evaluation:
V. Pitfall: When the ES is tested and evaluated, the users find its
performance disappointing in terms of both quality and utility of
answers produced.
How to avoid:
VI. Pitfalls: The users find it difficult to interact with the ES. The
dont understand the error messages when things go wrong, slow
response time frustrate them, and they keep forgetting how to
use the editing system to change or add new rules.
VII. Pitfalls: As the ES begins to execute few hundreds rules,
corrections or additions to the rules tend to introduce as many as
or more errors than they fix. Debugging seems like an endless
chore.

How to avoid: