You are on page 1of 16

EXPERT SYSTEMS

CONTENTS

➢ History of Expert Systems


➢ Basic Concepts of Expert Systems
➢ Knowledge Representations
➢ Basic Architecture of an Expert System
➢ Other Architectures of Expert Systems
➢ Reasoning with Uncertainty
➢ Tools for Building Expert Systems
➢ Application Areas of Expert Systems
➢ Benefits, Problems and Limitations of Expert Systems
Introduction
An expert system is a computer program conceived to simulate some forms of human
reasoning (by the intermediary of an inference engine) and capable to manage an important
quantity of specialized knowledge.
A system that uses human knowledge captured in a computer to solve problems that ordinarily
require human expertise (Turban & Aronson, 2001).
A computer program designed to model the problem solving ability of a human expert (Durkin,
1994).
An intelligent computer program that uses knowledge and inference procedures to solve problems
that was difficult enough to acquire significant human expertise for their solutions (Feigenbaum).
An expert system is a computer application that solves complicated problems that would otherwise
require extensive human expertise. To do so, it simulates the human reasoning process by applying
specific knowledge and interfaces. This report explained on the expert system for decision making
of giving the best solution to solve the PDA’s (Personal Digital Assistant) problems.
These capacities for reasoning and management allow the system to target a small number of
relevant hypotheses in the mass of potential diagnoses and being able to find a satisfactory
diagnostic conclusion. Two characteristics of the expert system are essential to accomplish this task:
• the aptitude to process an important mass of specialized knowledge and
• the aptitude to simulate the human reasoning (in an imperfect manner).
There are many well known advantages to using computerised tools and expert systems:
• reduction of missing data,
• better collection of data,
• no omission of questions,
• no data transcription,
• broader coverage of diagnoses
The idea to develop this system has arises base on the capabilities and the potential of the expert
system as described above. It can be use mainly for giving appropriate countermeasures according
to the accurate and consistent diagnosis of PDA’s (Personal Digital Assistant) troubleshoots. It is
called PDAMum.
PDAMum is essential since the emergence of handheld devices, and now it is rapidly owned by
various levels of peoples, there is somehow a need of a system that able to help them to manage
their devices whenever necessary. PDAMum is making its decision during the interview, looking
for the optimal way to reach their conclusions: to make a diagnosis.
ROUGH IDIEA
Example

• General Electric's (GE)


Top locomotive field service engineer was nearing retirement

• Traditional Solution: apprenticeship


• Good short-term solution

• But GE wanted
• A more effective and dependable way to disseminate expertise.
• To prevent valuable knowledge from retiring.
• To minimize extensive travel or moving the locomotives.
• The expert system solution
• To model the way a human troubleshooter works
Months of knowledge acquisition
3 years of prototyping
• A novice engineer or technician can perform at an expert’s level
On a personal computer
Installed at every railroad repair shop served by GE

History of Expert Systems

1. General Purpose Problem Solver (mid-1960s)


A. Newell and H.Simon
few laws of reasoning
+
powerful computers
=
expertise performance
initial situation desired goal
set of operators
2. Early Expert Systems (1970s)
• DENDRAL infers molecular structure from the unknown compounds
• MYCIN medical diagnosing (bacterial infections of the blood)
• E.Feigenbaum (Stanford University)
"The expert knowledge provides the key to expert performance, while the knowledge
representation and inference schemes provide the mechanism for its use."
Conclusions:
• General problem solvers are too weak.
• Human problem solvers are good only if they operate in a very narrow domain.
• Expert systems must be constantly updated with new information.
• The complexity of problems requires a considerable amount of knowledge about the
problem area.

3. Development of Commercial Expert Systems (1980)


XCON - VAX System configuration (Digital Equipment Corporation)
YES/MVS - helps the computer operator monitor and control the MVS operating system
(IBM)
CATS-1 (Delta) - helps diagnose and repair malfunctions in diesel electric locomotives
(General Electric Company)
Expert systems development tools:
EMYCIN, EXPERT, META-DENDRAL, OPS5, ROSIE,
CRYSTAL, GOLDWORKS II, etc.

An expert system (ES) is a computer program that uses knowledge and inference procedures of an
expert to solve problems.
• Expertise is the extensive, task-specific knowledge acquired from training, reading, and
experience.
Includes:
• theories about the problem area
• rules and procedures
• heuristics
• global strategies
• meta-knowledge
• facts
• Heuristics are rules of experience that characterise expert-level decision making in the field.
Basic Concepts of Expert Systems
Knowledge engineering - the task of eliciting and modelling the knowledge and building a
computer system

• Transferring expertise:
expert computer non-expert
• knowledge acquisition (from experts and other sources)
• knowledge representation (in the computer)
• knowledge inferencing
• knowledge transfer to the user

• The human elements in expert systems:
• expert
• knowledge engineer
• user

shallow knowledge (experience)


consists of all the peculiar heuristics and shortcuts
e.g. IF it rains
THEN the vegetables will grow faster
• deep knowledge (theoretical)
first principles, axioms, laws
e.g. IF it rains
THEN the vegetables will grow faster
BECAUSE the soil will become more moist
• Expert systems are tailored-made for specific and narrowly-defined problem domains.
• Second generation expert system employ both:
shallow + deep knowledge
Expert systems tasks:

• interpretation - inferring situation descriptions from sensor data


• prediction - inferring likely consequences of given situations
• diagnosis - inferring malfunctions from observations
• prescription - prescribing remedies for malfunctions
• design - configuring objects under constraints
• planning - designing actions
• monitoring - comparing observations to expected outcomes
• control - governing overall system behaviour
• instruction - diagnosing, prescribing and guiding users' behaviour

An ES has two main functions:


• to draw conclusions
• to explain its reasoning

• Explanation:
• HOW was a particular conclusion reached?
• WHY the program asks the user a particular question?
• TRACE displays all rules that are tried (not only those that are executed).
• WHAT-IF explains what will happen if a certain value or rule is changed.
Production Systems

production: condition-action pair


condition specifies data patterns
action specifies what to do
example
IF person A is the mother of person B
and person B is the mother of person C
THEN person A is the grandmother of person C

example
The Water Jug Problem
two jugs: 4 gallon, 3 gallon
task: to get exactly 2 gallons of water in the 4 gallon jug
State space
(x, y) where x =0, 1, 2, 3, 4
y=0, 1, 2, 3
initial state: (0, 0)
goal state (2, y)
production rule:
IF there are less than 4 gallons in the 4 gallon jug
THEN fill the 4 gallon jug
IF (x, y) where x < 4 THEN (4, y)

(P1) IF (x, y) where x < 4 THEN (4, y)


(P2) IF (x, y) where y < 3 THEN (x, 3)
(P3) IF (x, y) where x > 0 THEN (0, y)
(P4) IF (x, y) where y > 0 THEN (x, 0)
(P5) IF (x, y) where x+y > 4 and y > 0 and x < 4 THEN (4, y-(4-x))
(P6) IF (x, y) where x+y > 3 and x > 0 and y < 3 THEN (x-(3-y), 3)
(P7) IF (x, y) where x+y ? 4 and y > 0 THEN (x+y, 0)
(P8) IF (x, y) where x+y ? 3 and y > 0 THEN (0, x+y)
The components of the production system:

(1) Working memory holds the symbol structure which represents the states of the problem
space.
(2) Production memory (long-term memory) holds the production rules.
(3) Control strategy selects the rules to be applied.
Conflict resolution
principles:
• ordering of the rules
• recency
• specificity
SUMMARY

• Expert systems imitate the reasoning process of experts.


• ES predecessor: the General-purpose Problem Solver (GPS).
Failed - ignored the importance of specific knowledge.
• The power of an ES is derived from its specific knowledge.
Not from its particular knowledge representation or inference scheme.
• Expertise is a task-specific knowledge acquired from training, reading, and experience.
• Experts can make fast and good decisions regarding complex situations.
• Expert system technology attempts to transfer knowledge from experts and documented
sources to the computer and make it available to nonexperts.
• Expert systems provide limited explanation capabilities.
Phase 1: Problem Assessment
Most organizations when considering any new technology will ask the very practical questions
‘Will it work?’ and ‘Why should we try it?’ Since PDAMum is relatively new, answers to these
questions are at best educated guesses. However, it is important that a serious effort be made to
answer these questions before the project begins. Failure to do so can result in undertaking a project
that has a small chance to succeed or will offer little benefit to the organization.
Then, this is a methodology for assessing the applicability of PDAMum to a given problem.
It’s structured according to the following tasks:
Task 1: Determine motivation of organization
Task 2: Identify candidate problems
Task 3: Performs feasibility study
Task 4: Perform cost/ benefit analysis
Task 5: Select the best project
Task 6: Write the project proposal

Phase 2: Knowledge Acquisition & Analysis


This task is the most difficult challenge in the development of an expert system. Knowledge
acquisition is inherently a cyclical process. PDAMum used these tasks of knowledge collection, its
interpretation and analysis, and the design of methods for collecting additional knowledge. An
expert system gains its power from the knowledge it contains (Durkin, 1994). One of the most
difficult aspects of the KE’s task is helping the expert to structure the domain knowledge, to
identify and formalize the domain concepts (Hayes-Roth, Waterman and Lenat).

Phase 3: Design and Implementation


This phase begin with the selection of the knowledge representation technique and control strategy.
This is followed with the selection of a software tool that best meets the needs of the problem. A
small prototype of PDAMum is then built to both validate the project and to provide guidance for
future work. PDAMum is then further developed and refined to meet the project objectives.
This process is structured according to the following task:
Task 1: Select rules as Knowledge representation technique
Task 2: Select control technique
Task 3: Select Kawa as PDAMum development software
Task 4: Develop the prototype, interface, and product
A rule-based approach is suitable because PDAMum discusses the problem primarily using IF/
THEN type statements. This discussion will usually lack an in-depth description of the problem’s
objects, which would justify the need for a frame-based approach. Classification problems are
typical of this situation where the expert tries to classify the state of some issue according to
available information.
The keys to effective interface design are consistency, clarify and control. Consistency is consistent
on screen format. Various types of materials are presented on screen such as title, questions,
answer, explanation and control functions. When presenting these materials, it supposes to be that
the similar material is place in the same location. Clarify is to clarify of presented materials.
PDAMum used screen to ask questions, provide explanation on the system’s reasoning and display
intermediate or final results. These materials presented in a clear manner for two reasons; two
ensure the user will be receptive to the system and to enhance the reliability of exchanging
information between the user and the system. And lastly is to the screen control. It’s to ensure the
user always feel in control when using the system, to convince the user that any mistake user might
make couldn’t lead to disastrous consequences.

Phase 4: Testing
As the PDAMum will need to be periodically tested and evaluated to assure that its performance is
converging toward established goals. It is important that these decisions be made early, at a time
when the original project goals are established.
These are the evolution of testing or evaluation of testing for PDAMum:
Stage 1: Preliminary Testing
• Study the complete knowledge base
• Uncover deficiencies in the knowledge and reasoning strategies
• Validate knowledge representation and inference approach
Stage 2: Demonstration Testing
• Choose a problem of limited scope within the capabilities of PDAMum
• Use demonstration to validate the expert system approach
• Show off major PDAMum features
• Design interface to accommodate of the user
Stage 3: Informal Validation Testing
• Select typical past test cases
• Evaluate PDAMum’s ability in solving typical cases and
• Identify PDAMum deficiencies and obtain comments from user on the interface
Stage 4: Refinement Testing
• Select unusual past test cases
• Evaluate PDAMum’s ability in solving unusual cases
• Uncover deficiencies in PDAMum’s knowledge and control
• Identify PDAMum deficiencies
Stage 5: Formal Testing
• Select past test cases and define test criteria
• Run the PDAMum for each test case and ask evaluators to judge system’s performance for
each test case
• Obtain comments on the interface
• Identify PDAMum strength and deficiencies
Stage 6: Field Testing
• Define test criteria for the field test
• Determine if PDAMum meets its original goals when applied to real problems
Phase 5: Documentation
This documentation serves as a personal diary of the project. It contains all the material collected
during the project that needs to be reference for developing the system. If properly designed, it will
also serve the later tasks of maintaining PDAMum and writing the PDAMum’s final report.
Phase 6: Maintenance
After finished all of the designing, implementing, testing and documentation, PDAMum may need
to be refined or updated to meet current needs. It is extremely important to keep good records on
any changes made to PDAMum. If this isn’t done, it is very easy to lose track of the PDAMum’s
knowledge. And each time PDAMum is modified; the following critical pieces of information
should be documented:
• What was modified and who performed the modification
• When the modification was made
• Why the modification was made

References
Aamodt, A., & Plaza, E., Case-Based Reasoning: Foundational issues, methodological variations,
and system approaches, AICommunications, IOS Press,
http://www.iiia.csic.es/People/enric/AICom.pdf
Cawsey A., “The Essence of Artificial Intelligence”, Prentice Hall Europe, 1998.
“Computerize Prescription Reduce Errors”, Electronic Medical Records, Expert System
Application, Inc.
[online: www.emrs.com/PrescriptionWritingReducedErrors.htm ]
Durkin, J., “Expert System Design and Development”, New Jersey: Prentice-Hall. 1994.
George, F. Luger & William, A. Stubblefield, “Artificial Intelligence: Structures and Strategies for
Complex Problem Solving”, Addison Wesley Longman, Inc., 1998.
H. Basri, “An Expert System for Planning Landfill Restoration”, Water Science and Technology,
1998.
Hevner, et al., “Design Research in Information System”, 2004, http:// www.isworld.org
Richard E. Plant, Nicholas D. Stave, “Knowledge based systems in Agriculture”, McGraw-
Hill, 1991.
R. L. Hoskinson, J. R. Hess, R. K. Fink, “A Decision Support System for Optimum Use of
Fertilizers”, 1992.
Rule-Based ES's in Medicine, http://alpha.cbmi.upmc.edu/courses/fall97/Sep25/ index.htm

ARTIFICIAL INTELLIGENCE

REPORT ON EXPERT SYSTEMS

UNDER GUIDANCE OF :- SUBMITED BY :-


Y.N SINGH SHUJA KHAN
(0605213030)

You might also like