Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | kibo-jefferson |
View: | 29 times |
Download: | 0 times |
IT-2702 Kunstig intelligens - høst 2004Forelesning 5.
Emner:
• Kunnskapsintensiv problemløsning - ekspertsystemer
• Regelbaserte systemer
• Modellbaserte systemer
• Kunnskapsakkvisisjon og -modellering
• Casebaserte systemer
Expert system = Knowledge-based decision support system
• A knowledge-based computer program designed to model the problem-solving ability of a human expert. • An expert system performs like a human expert within a limited domain.
- Knowledge is acquired from various sources (e.g., primarily a human expert, but also books, reports,
drawings, visual inspections).
- Expert systems do not (necessarily) attempt to simulate human mental architecture, but to emulate human expert performance.
RULE BASED
SYSTEMS
EXPERT
• Rule-based systems were the first expert systems.
• For historical reasons, rule-based systems and expert systems are sometimes used as synonyms - and to some extent also in Luger’s book, unfortunately.
• The term expert system now actually covers model-based and case-based methods as well - and this is the view we will stick to in this course.
Kontroll-kunnskap
Heuristiskeregler
Spesifikke case
Dyp kunnskap
KUNNSKAPSBASERTE METODER- Kunnskapstyper
Expert system application areas:
Control: control systems adaptively govern the behaviour of a given system to meet specifications(e.g., manufacturing process, treatment of a patient)
Prediction: inferring likely consequences of a given situation (e.g., predicting the expected damage to a crop from an invading insect).
Diagnosis: infer system malfunctions or faults from observable information ( finding the disease of a patient from her symptoms.)
Design: configures objects under a set of problem constraints(e.g., design of electronic circuits)
Planning: form actions to achieve a given goal under problem constraints (e.g., (a robot's accomplishment of a given work function).
Monitoring: compare observable information on the behaviour of a system with system states that are considered important to its operation (e.g., interpretation of signals from sensors).
Debugging and repair: proposing and implementing remedies for malfunctions.
Instruction: guides the education of students in a given topic.
Interpretation: produce an understanding of a situation from available information (e.g., interpretation of speech analysis results).
Guidelines to determine whether a problem is appropriate for expert system solution:
1. The need for the solution justifies the cost and effort of building an expert system.
2. Human expertise is not available in all situations where it is needed.
3. The problem may be solved using symbolic reasoning.
4. The problem domain is well structured and does not require commonsense reasoning.
5. The problem may not be solved using traditional computing methods.
6. Cooperative and articulate experts exist.
7. The problem is of proper size and scope.
Important aspects of expert systems:
- separation of control from knowledge.- modularity of knowledge- ease of expansion- ability of explanation- utilization of heuristic knowledge- utilization of uncertain knowledge
Figure 7.1: Architecture of a typical expert system for a particular problem domain.
Figure 7.1: Architecture of a typical expert system for a particular problem domain.
The Knowledge Engineering Process
- The main players on an expert system project are the domain expert, the knowledge engineer, and the end user.
- Knowledge engineer designs, builds, and tests the expert system.
- The major tasks of an knowledge engineer:
- selecting the software and hardware tools - knowledge acquisition - organisation of this knowledge - problem-solving method identification - coding the system - testing the sytem
- Domain expert possess the skill and knowledge to solve a specific problem in a manner superior the others.
- End user: The final expert system should meet the needs of the end user. These needs concern:
- user interface - level of explanation - information entry - form of final results
- Expert System development, is a highly iterative process.
- The designer partially builds the system, tests it, then modifies the system's knowledge.
- This process is repeated throughout the project where the system's knowledge grow with each test.
Phases in expert sytem development - Exploratory developmnet cycle:
Assesment
Knowledge acquisition
Design & Imp.
Documentation
Maintenance
Test
Refinements
Explorations
Requirements
Knowledge
Structure
Evaluation
Product
Learning
Assesment:
- determination of feasibility and justification of the candidate problem.
- definition of the overall goal of the project. - specification of important features and the scope of the project.
- establishment of the needed resources, including project personel.
Knowledge Acquisition:
- ’extraction’ of knowledge from the domain expert, analysis and modelling of the knowledge
Design:
- methods for processing the knowledge is determined.
- a software tool is chosen to represent and reason with the sytem's knowledge
- design of user interface - an initial prototype is built.
- most often a constructive process, in which the domain expert and nowledge eningeer cooperate
Testing:
- this is not a separate phase, but rather a continual process throughout the project. - each time new knowledge is added to the sytem, the system is tested.
- the major objective of testing is to validate the overall structure of the system and its knowledge. - studies the acceptability of the system by the user.
Documentation
- all the project's knowledge is documented such as to meet the requirements of both the user and the developer of the system.
Conceptual models and their role in Knowledge Acquisition:
- the knowledge of domain expert is often vague and incomplete
- the knowledge engineer translates this knowledge into a formal language
- knowledge acquision is the bottlenect of expert system development because:
- human expertise is often not explicitely retrievable,
- human expertise has often the form of knowing how, rather than knowing what,
- human expertise is subjective
- expertise changes.
- is not a formal or executable model
- is a bridge between human expertise and its implementation, serves an intermediate role in formalization of knowledge
- is a knowledge level model of the systems and its interaction with the world
- Conceptual model
The old view of building an expert system.
Figure 7.4: The role of mental or conceptual models in problem solving.
KNOWLEDGE ENGINEERING AS MODELING
Task Reality
Model ofTaskReality
Modeling
(Sub)Problem Description
(Partial)Solution to Problem
Task reality : The entire spatial and temporal extensionof the world which is relevant for accomplishinga real-world task.
Task: What is to be accomplished(goal, purpose).
Method: How a task is accomplished(procedure, control).
Domain knowledge (Object knowledge):Possessed by agents and used within methods
Agent: The physical entity who accomplishes a task(human, machine).
LEVELS OF SYSTEM DESCRIPTION
Knowledge Level
Functional Level
Physical Level
A Conceptual Model is a Knowledge Level model of the systems and its interaction with the world
THE KNOWLEDGE LEVEL IN AI:
A. Newell: "There exists a distinct computer system level,lying immediately above the symbol level, which ischaracterized by knowledge as the medium and theprinciple of rationality as the law of behavior."
Knowledge levelMedium: KnowledgeBh. laws: Principle of Rationality
Symbol levelMedium: Programs, data structuresBh. laws: Sequential interpretation of programs
Register-transfer levelMedium: Bit vectorsBh. laws: Paralell logic
Logic circuit levelMedium: BitsBh. laws: Boolean algebra
Electrical circuit levelMedium: Voltage/currentBh. laws: Ohm's law, Kirchhoff's law
Electronic device levelMedium: ElectronsBh. laws: Electron physics
OPERATIONALIZING THE KL:
• KL in Newell's sense is purely intentional, and assuch it contains no structure.
• A current trend in Knowledge Acquisition andModeling is to develop knowledge engineeringmethodologies based on an 'operationalization' ofthe KL
- by providing high-level structuresand structuring means
- by viewing rationality as bounded.
EXAMPLES:
KADS, COMMET, GTs, RLMs, MTA, ...
Tools:KPT, KREST, MDX, SFB, PROTEGE, ...
• A growing number of Knowledge Modelling Libraries are currently being developed
KADS (KADS-I)
FOUR-LAYER STRUCTURE
strategic layer
task layer
inference layer
domain layer
plans, meta-rules, repairs, impasses
goals, tasks
meta-classes, knowledge sources
concepts, relations and structures
process structure
task structure
inference structure
axiomatic structure
describes
applies
controls
layer relation objects organization
Examples of knowledge modelling methodologies coupled with libraries of knowledge modelling components
1)
INFERENCE STRUCTURE , TASK STRUCTURE
select
decompose
specify
compare
observables data complaint
conclusion
norm
difference
set of hypotehses
parameter-value
select
system-model
FIND (DIAGNOSIS)
SELECT (SYSTEM-MODEL)
WHILE (NOT CONCLUSION)
DECOMPOSE (SYSTEM MODEL)
WHILE (NUMBER-OF HYPOTHESES > 1)
SELECT (PARAMETER-VALUE)
SPECIFY (NORM)
COMPARE (PARAMETER-VALUE, NORM)
Inference structure: Task structure:
CommonKADS (KADS-II) KNOWLEDGE CATEGORIES
Application
Knowledge
Epistemological
Categories
Problem Solving
Knowledge
Domain
Knowledge
Inference
Knowledge
Task
Knowledge
Problem Solving
Methods
Strategic
Knowledge
2)
COMMET (CONSTRUCT)COMPONENTS OF EXPERTISE
MODELS
METHODS
TASKS
3)
- goal/subgoals- the “what”
- knowledge needed by methods to accomplish tasks (achieve goals)
- problem solving steps- the “how”
TASK STRUCTURES,MODEL DEPENDENCIES,METHOD TYPES
domainmodel-1
userdomainmodel-2
casemodel-1
casemodel-2
model constructionactivity
Task Decomposition Model Dependency Diagram Control Diagram
Methods:• Decompose tasks• Execute tasks• Assign tasks to model construction ativities• Impose control over tasks
Task-1 Task-2 Task-3
c1
c2
Rule-based systems
Example:A small rule-based expert system for analysis of automotive problems.
- Production system- Goal driven- User querying
Figure 7.5: The production system at the start of a consultation in the car diagnostic example.
Figure 7.6: The production system after Rule 1 has fired.
Figure 7.7: The system after Rule 4 has fired. Note the stack-based approach to goal reduction.
Figure 7.8: The and/or graph searched in the car diagnosis example, with the conclusion of Rule 4 matching the first premise of Rule 1.
The following dialogue begins with the computer asking the user about the goals present in working memory.
Figure 7.9: The production system at the start of a consultation fordata-driven reasoning.
Rule-based systems - Data-driven reasoning
Figure 7.10: The production system after evaluating the first premise ofRule 2, which then fails.
Figure 7.11: The data-driven production system after considering Rule 4, beginning its second pass through the rules.
Figure 7.12: The search graph as described by the contents of working memory (WM) for the data-driven breadth-first search of the rule set of Section 7.2.1.
Model-Based Reasoning
• Reasoning: Based on ”deeper” knowledge than rules
Typical models:- causal- functional- behaviourial-> a combination of several submodels
• Representation
Different relations than rule-based’s ”if-then” relation:- taxonomical (”has-subclass”, ”has-instance”)- ”has-part”-”causes”- ...
Often multiple relations combined!
Figure 7.13: The behavior description of an adder, after Davis andHamscher (1988).
Figure 7.14: Taking advantage of direction of information flow, after Davis and Hamscher (1988).
Figure 7.15: A schematic of the simplified Livingstone propulsion system, from Williams and Nayak (1996).
Figure 7.16: A model-based configuration management system, from Williams and Nayak (1996).
Kontroll-kunnskap
Heuristiskeregler
Spesifikke case
Dyp kunnskap
KUNNSKAPSBASERTE METODER- UTVIKLINGSTRENDER
Integrerte systemer (f.eks. SOAR, CREEK, META-AQUA) - totalarkitekturer for intelligent problemløsning