1

IT2702 - Høst 2003, Leksjon 8

• Modellbasert resonneriong

• Casebasert resonnering

• Kombinerte resonneringsmetoder

• Planleggingsproblemer

2

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!

3

Figure 7.13: The behavior description of an adder, after Davis and

Hamscher (1988).

4

Figure 7.14: Taking advantage of direction of information flow, after Davis and

Hamscher (1988).

5

Figure 7.15: A schematic of the simplified Livingstone propulsion system, from

Williams and Nayak (1996).

6

Figure 7.16: A model-based configuration management system, from Williams and

Nayak (1996).

7

Model-Based ReasoningModel-Based Reasoning

thing

domain-objectcase

car

case#54van

electrical-faultbattery-fault

engine-test

engine

test-procedure

engine-fault

turning-of-ignition-key

test-step

battery-low

starter-motor

engine-turns

diagnostic-case

diagnosis

solved

diagnostic-hypothesis

wheel

vehicle

transportation

hsc

hp

hsc

hschsc

hsc

hsc

hi

hi

hp

hp

hphp

case-of

status-of

hd

has-status

possible-status-of

tested-by

has-function

tested-by

batteryinstance-of

has-fault

hsc

tested-by

hsc

test-for

test-for

has-fault

goal

find-faultfind-treatment

hschsc

hschsc

hsc

has-state

observed-finding

subclass-of

car-fault

fuel-system

fuel-system-fault

hsc

hp

has-fault

has-outputdescribed-in

part-of

hsc

electrical-system

broken-carburettor-membranehsc

hschas-fault

has-engine-status

hi

hd

starter-motor-turns

N-DD-234567

has-electrical-status

finding

subclass-ofsubclass-of

subclass-of

hsc

hp

- has subclass- has-instance- has-part- has-descriptor

• MBR - in the Creek context - is a technology for solving a new problem by explaining

its solution within a multi-relational model of the target system.

• MBR here involves the abductive steps of hypothesis generation and

evaluation/selection, for which methods of plausible reasoning are applied.

8

thing

domain-object

case

car

case#54

van

electrical-fault

battery-fault

engine-test

engine

test-procedure

engine-fault

turning-of

-ignition-key

test-step

battery-low

starter-motor

engine-turns

diagnostic-case

diagnosis

solved

diagnostic-hypothesis

wheel

vehicle

transportation

hsc

hp

hsc

hschsc

hsc

hsc

hi

hi

hp

hp

hphp

case-of

status-of

hd

has-status

possible-status-of

tested-by

has-function

tested-by

batteryinstance-of

has-fault

hsc

tested-by

hsc

test-for

test-for

has-fault

goal

find-faultfind-treatment

hschsc

hsc

hsc

hsc

has-state

observed-finding

subclass-of

car-fault

fuel-system

fuel-system-fault

hsc

hp

has-fault

has-outputdescribed-in

part-of

hsc

electrical

-system

broken-carburettor-membranehsc

hschas-fault

has-engine-status

hi

hd

starter-motor-turns

N-DD-234567

has-electrical-status

finding

subclass-ofsubclass-of

subclass-of

hsc

hp

- has subclass

- has-instance

- has-part

- has-descriptor

fuel-system-fault observable-state

too-rich-gas-mixture-in-cylinder

carburettor

carburettor-valve-stuck

causes

no-chamber-ignition

engine-does-not-fire

water-in-gas-mixture

water-in-gas-tank

fuel-system

carburettor-fault

enigne-turns

carburettor-valve-faultobserved-finding

causes

causes

causes

causes

hsc hschsc

hp

hi

hi

hi

causes

hsc has-fault

hsc

has-fault condensation-in-gas-tank

causes

9

Case-Based Reasoning

Motivation:

• From cognitive science:

A theory of understanding,

problem solving and learning

in human beings.

• From knowledge-based systems:

Deficiency of purely generalization-based

methods for intelligent computer

programs.

10

RE

TA

IN

Problem

General Knowledge

Past Cases

Suggested

Solution

REVISE

Tested/ Repaired Case

Confirmed

Solution

Solved Case

New Case

New Case

Retrieved Case

RE

US

E

The CBR Cycle

LearnedCase

RETRIEVE

11

problem solving and learning from experience

retrieve reuse retain

identify features

initially match

collect descriptors

enfer descriptors

interpret problem

calculate similarity

explain similarity

follow direct indexes

search general knowledge

search index structure

copy

revise

copy solution

modify solution method

modify solution

evaluate in real world

extract

index

integrate extract relevant descriptors

update general knowledge

extract solutions

adjust indexes

determine indexes

rerun problem

generalize indexes

extract solution method

adapt

evaluate in model

search

select

extract justifications

evaluate by teacher

evaluate solution

repair fault

case-based reasoning

use selection criteria

elaborate explanations

self- repair

user- repair

copy solution method

12

Case-based approaches

• Instance-based reasoning/learning

• Memory-based reasoning/learning

• Case-based reasoning/learning (typical)

• Analogical reasoning/learning

13

Instance-based methods

• Motivated by classical machine learning research

• Addresses classification tasks

• A concept (class) is defined by its set of exemplars:

Concept space = Instance space + Similarity metric

• Representation is attribute-value pairs

• Knowledge-poor method

• 'IBL' framework (Kibler&Aha) contains

- Similarity function

- Classification function

- Concept decsription updater

14

IBL algorithms - Experiment! ! ! ! ! ! ! ! ! (Kibler&Aha 87)

•! Three learning algorithms compared:

! !

! ! -! Proximity:

! ! ! Retain all new examples

! ! - ! Growth:

! ! ! Retain only examples that were

! ! ! not correctly classified

! ! -! Shrink:

! ! ! Start with all examples, remove

! ! ! those correctly classified by !others

! ! !

15

Test Results

16

Memory-Based Reasoning

• Motivated by parallel computer architectures

• Adds parallelity to instance-based approach

• Computes distance between input and all

exisiting instances

• Best match algorithm takes constant time

• Syntax-based: Trades knowledge for 'brute'

power

RETRIEVE:

1. Count feature occurences; this determines

relevant features.

2. Generate similarity metric from counts

3. Calculate dissimilarities

4. Find best matches

17

MBR-talk (Stanfill&Waltz 86)

• Learns to pronounce english words

• A word is represented in a 9-letter window

****file* f +

***file** A 1

**file*** l -

*file**** - -

• Compared to NET-talk

18

Experiment

- 4438 words in database

- 100 new words in test set

MBR-talk

Dictionary evaluation:

• Correct phonemes: 86 % of cases

• Correct word 43 % of cases

Human judgement of word pronounciation:

• Good: 47%

Net-talk

After 30.000 trials:

• Correct phonemes: 78 % of cases

19

Japan

•! Massive parallel computation

•! Explores memory-based reasoning

! and neural networks, aimed at integration

•! Testing of

! ! Central limit theorem:

! ! - Inaccuracy and noise in data has a ! ! ! !

! ! Gaussian distribution over large data sets

! ! Law of large numbers:

! ! - The peak in a data distribution gets narrower

! ! as the size of the data set increases

(H. Kitano et. al. 93)

20

DmDialog! -! MBR for natural language understanding

21

Analogy-based methods

• Motivated by psychological research

• Reuse of cross-domain cases

• Emphasis on Reuse, not Retrieval

• Computationally complex problem

22

Example

23

Figure 9.19: An analogical mapping.

24

Relations vs. attributes

25

Case-based methods (in a 'typical' sense)

• Motivated by learning for problem solving,

rather than for general concept definitions.

• Typically uses some background knowledge

in its Retrieval, Reuse, and/or Learning methods.

• A range of different approaches distinguished by

- task and domain type addressed

- memory organization (case storage, indexes)

- case retrieval, reuse, and learning method

26

CBR - History

Theoretical:

Schank/Abelson 77: Scripts

Rissland 80: Precedents in legal reasoning

Schank 82: Dynamic memory, MOPs

Carbonell 83: Transform./Derivational analogy

Kolodner 83: Episodic memory

Schank 86: Explanation patterns

Richter 90: Similarity and uncertainty

Some systems:

Lebowitz 80: IPP - nat. language

Kolodner 83: CYRUS - info retrieval

Simpson 85: MEDIATOR - negotiation

Hammon 86: CHEF - cooking planning

Sycara 87: PERSUADER - negotiation

Ashley/Rissland 87: HYPO - law interpret.

Bareiss/Porter 88: PROTOS - medicaldiagnosis

Koton 89: CASEY - medical diagnosis

Goel/Chandra 89: KRITIK - mechanical design

Hinrichs/Kolodner 91: JULIA - meal planning

Aamodt 91: CREEK - mud diagnosis

Leake/Schank 92: ACCEPTER - explaining

Lopez/Plaza 93: BOLERO - medical diagnosis

Althoff/Wess/Richter 93 : PATDEX - technical diagnosis

Oehlmann/Sleeman94: IULIAN - discovery, planning

Esprit-project -95 INRECA - CBR and induction

excerpt

27

Transformational and Derivational ”analogy”(J. Carbonell 83)

- Transformational

28

- Derivational

29

Figure 7.17: Transformational analogy, adapted from Carbonell (1983).

30

Problem areas

• Memory organization

- case structure

- index structure

- integration of general domain knowledge

• Retrieval - use of indexes

- feature relevance

- similarity assessment

- use of general knowledge

- use of previous cases

• Reuse

- transfer of solution

- adaptation of solution

- transfer (and adaptation) of solution method

• Learning

- feature extraction

- as separate cases vs. splitted up

- index learning

- generalization

- forgetting

31

Kolodner (1993) offers a set of possible preference heuristics to help

organize the storage and retrieval of cases. These include:

1. Goal-directed preference. Organize cases, at least in part, by

goal descriptions. Retrieve cases that have the same goal as the

current situation.

2. Salient-feature preference. Prefer cases that match the most

important features or those matching the largest number of

important features.

3. Specify preference. Look for as exact as possible matches of

features before considering more general matches.

4. Frequency preference. Check first the most frequently matched

cases.

5. Recency preference. Prefer cases used most recently.

6. Ease of adaptation preference. Use first cases most easily

adapted to the current situation.

32

! Data intensive - Knowledge poor

- A case is a data record

- Similarity asessment based on simple metric

! Knowledge intensive - Data Poor

- A case is a user experience

- Similarity asessment is an explanation process

! Both knowledge and data intensive

- Multiple case contents

- Multiple similarity asessment methods

CBR methods

The Data-- Knowledge Dimension

33

CREEK

• Case-based reasoning in open and

weak theory domains; diagnosis problems

(appl.: oil-well drilling, medicine)

• Problem description is problem solving goal,

solution constraints, and list of findings

Solution is (one or more) diagnoses and

repairs

• Knowledge types are

- case memory of findings to

solutions, indexed by relevant findings;

cross-case indexes to neighbouring cases

and between diagnosis and treatments

- general domain knowledge as deep

relationships or heuristiv rules

- all knowledge integrated into a single

semantic network of concepts and relations

- each concept and each relation explicitly

represented as frames

34

thing

case039

case112

case76

generic concepts

cases

domain conceptsgenera

CreekL Knowledge Types

l

35

thing

domain-object

case

car

case#54

van

electrical-fault

battery-fault

engine-test

engine

test-procedure

engine-fault

turning-of

-ignition-key

test-step

battery-low

starter-motor

engine-turns

diagnostic-case

diagnosis

solved

diagnostic-hypothesis

wheel

vehicle

transportation

hsc

hp

hsc

hschsc

hsc

hsc

hi

hi

hp

hp

hphp

case-of

status-of

hd

has-status

possible-status-of

tested-by

has-function

tested-by

batteryinstance-of

has-fault

hsc

tested-by

hsc

test-for

test-for

has-fault

goal

find-faultfind-treatment

hschsc

hsc

hsc

hsc

has-state

observed-finding

subclass-of

car-fault

fuel-system

fuel-system-fault

hsc

hp

has-fault

has-outputdescribed-in

part-of

hsc

electrical

-system

broken-carburettor-membranehsc

hschas-fault

has-engine-status

hi

hd

starter-motor-turns

N-DD-234567

has-electrical-status

finding

subclass-ofsubclass-of

subclass-of

hsc

hp

- has subclass

- has-instance- has-part- has-descriptor

Tangled CreekL Network

36

case#54instance-of value car-starting-case diagnostic-case

has-task value find-car-starting-fault

has-status value solvedof-car value N-DD-234567

has-fault value carburettor-valve-stuck

has-fault-explanation value

has-repair value replace-carburettor-membrane

has-electrical-status value battery-low starter-motor-turns

has-engine-status value engine-turns engine-does-not firehas-ignition-status value spark-plugs-ok

has-weather-condition value low-temperature sunny

has-driving-history value hard-driving

carburettor-valve-stuck causes too-rich-gas-mixture-in-sylinder causes no-chamber-ignition causes engine-does-not-fire

37

fuel-system-faultobservable-state

too-rich-gas-mixture-in-cylinder

carburettor

carburettor-valve-stuck

no-chamber-ignition

engine-does-not-fire

water-in-gas-mixture

water-in-gas-tank

fuel-system

carburettor -fault

enigne-turns

carburettor-valve-faultobserved-finding

hschsc

hp

hi

hi

hi

causes

hschas-fault

hsc

has-fault condensation-in-gas-tank

Explanation Structure

hsc = has-subclass

hi = has-instance

hsc

causescauses

causes

causes

causes

causes+bni

hi

38

Creek Top Level Ontology

39 40

41

• Retrieve

- context focusing by spreading activation in

the semantic netowrk, followed by

- index retrieval of possible cases, followed by

- explanation-driven selection of best match

• Reuse

- attempts to copy solution from matched case

- explanation-driven adaptation, by combining

explanantion of retrieved case with general

domain model

• Revise

- user evaluates and gives feedback

- case status info kept and used in case

selection and reuse

• Retain

- attempts to merge the two cases

- stores relevant findings, sucessful and failed

solutions, and their explanations

- updating the strength of indexes

CREEK

42

CBR systems development

• Two basic approaches:

- bottom-up from data

- top-down knowledge modeling

How to combine the two is the big issue.

• For a particular application, a breakdown of

knowledge and information into case-

specific and general is needed.

There has to be a number of cases available.

• Knowledge acquisition problem is in

general still hard.

KA methodologies needs to incorporate

the 'case view'.

43

Help Desk Applications

• General help and advice, fault finding,

maintenance, manual browsing, ...

• Primary CBR application type so far

• Facilitates the retrieval of similar past cases,

and leaves the reuse of cases to the user

• Data and information get grouped according

to the problem situations where they

occurred.

• Market potential due to service costs,

complexity of equipment, job instability,

training of personell, ...

• Learing ability in CBR enables capturing

of new experience as a 'rutine operation'.

44

Potential problems

• Capturing expertise is difficult. CBR helps solving

some problems but also introduces some.

• Building case bases from exisiting data bases is

difficult. Data mining methods may help.

• Methods for sustained learning are not welll

developed yet.

• Many cases are often needed for sufficient

coverage of domain. General knowledge

may help here.

• Development tools are only 1. generation

45

A stepwise approach

• Start by viewing cases as information, i.e. to

be interpreted and reasoned with by the user.

This enables information that normally is

scattered and fragmented to be retrieved on the

basis of previous situations where it was created

or used.

• Once the manual reuse of cases has been

tested, additional reasoning and learning

capabilities should be added.

46

Some applications

• CLAVIER (Lockheed)

- Autoclave loading

• CaseLine (British Airways)

- Aircraft maintenance and fault finding

• PRISM (Chase Manhattan Bank)

- Telex classifier and router

• 'Valve assistant' (General Dynamics)

- Pipeline valve selection

• SMART (Compaq)

- Compaq products diagnosis

• SQUAD (NEC Corp)

- Management of SW quality control knowledge

• QDES (Nippon Steel)

- Design reuse

47

Some commercial tools

• KATE-CBR (Acknosoft)

• ART-Enterprise (Brightware)

• ESTEEM (Esteem Software Inc.)

• Easy Reasoner (Haley Enterprise)

• CasePower (Inductive Solutions)

• ReMind (Intelligent Appl. /Cognitive Systems)

• CasePoint (Inference)

• ReCall (ISoft)

• CBR-Works (TechInno)

• ...

48

Integrated systemes (e.g. SOAR, THEO, META-AQUA, CREEK)

Knowledge-Based Methods- Combining different reasoning methods

Control Knowledge

Heuristic

rules

Specific

cases

Deep knowledge

-> Architectures for intelligence

49 50

51 52

53 54

55 56

57

Planlegging i blokk-verdenen

•! Blokk-verdenen er en enkel modell, ofte benyttet for å !! diskutere generelle prinsipper for problemløsning i ! !! interaksjon med den 'utenforliggende' verden.

•! Vanlig representasjon: En form for predikatlogikk!! !

! - ofte referert til som STRIPS deklarasjoner og ! ! !

! operatorer.

•! Planlegging betraktes som tilstandsrom-søking:

! - Det fins en beskrivelse av mulige tilstander!! ! !

! - Det fins et sett av operatorer som er istand til å ! !

! produsere nye tilstander! ! ! ! ! ! ! !

! - Operatorene benyttes for å søke etter en vei fra ! !

! start- til slutt-tilstanden (mål-tilstanden)!! ! ! !

! - En plan er settet av operatorer langs en slik vei.

!58

Figure 7.18: The blocks world.

59

Planlegging, generelt

•! En plan er en sekvens av aksjoner

•! Søkeromeet kan bli meget komplekst

! - en aksjon kan være avhengig av at en annen er ! !

! eller ikke er utført

! - må ta med endrindringer aksjoner medfører i den ! !! virkelig verden

•! "The frame problem"! ! ! ! ! ! ! ! !

! er problemet med å ta hensyn til ting som ikkeendres !! etter at en aksjon (et trinn i en plan) er utført

! - et hovedproblem innen AI planlegging, og spesielt i !! forbindelse med planlegging av robot-aksjoner

!60

The blocks world of Figure 7.18 may now be represented by the following set of

predicates.

61

A number of truth relations or rules for performance are created for

clear(X), ontable(X), and gripping():

62

Figure 7.19: Portion of the search space or the blocks world example.

63

Using blocks example, the four operators pickup, putdown, stack, and unstack are

represented as triples of descriptions.

64

STRIPS

•! Planleggingssystem utviklet for enkle robot-aksjoner

•! Operatorer lagres som

! - et sett av forhåndsbetingelser! ! ! ! ! ! !

! - en add liste som beskriver nye tilstander etter at ! !

! operatoren er anvendt! ! ! ! ! ! ! ! !

! - en delete liste som beskriver tilstander som ikke ! !

! lenger holder etter at operatoren er anvendt

•! Lærer ved å forme makro-operatorer

•! Løser konflikterende del-mål ved hjelp av ! ! ! !

! en triangel-tabell

!

65

Figure 7.20: Goal state for the blocks world.

66

Figure 7.21: Triangle table.

67

Figure 7.22: A simple TR tree showing condition action rules supporting a top-level

goal, from Klein et al. (2000).

68

Figure 7.23: Model-based reactive configuration management, from Williams and

Nayak (1996a).

69

Figure 7.24: The transition system model of a valve, from Williams and Nayak

(1996a).

70

Figure 7.25: Mode estimation (ME), from Williams and Nayak (1996a).

71

Figure 7.26: Mode reconfiguration (MR), from Williams and Nayak (1996a).

72

Planleggingsproblemer, i tillegg:

•! Generering av mulig planer

•! Rette opp igjen en mislykket plan, spesielt hvis noe ! !! uforutsett inntreffer

•! Lære av å ha løst et planleggingsproblem

! - generalisere en plan

! - lage makro-operatorer

! - lagre og gjenbruke tidligere konkrete planer

!