Intelligent systems

Lecture 10

Development of Expert Systems

20.10.2005 2

Structure of Expert System

Knowledge Acquisitionsubsystem

Knowledge Base,

heuristics

Inference engine,

Reasoningwith uncertainty

Explanationsubsystem

User interface

Base of facts

Expert Knowledge engineer

User

20.10.2005 3

Structure of Expert System

1. Knowledge base: A store of factual and heuristic knowledge. An ES tool providesone or more knowledge representation schemes for expressing knowledge about theapplication domain. Some tools use both frames (objects) and IF-THEN rules. InPROLOG the knowledge is represented as logical statements.2. Reasoning engine: Inference mechanisms for manipulating the symbolicinformation and knowledge in the knowledge base to form a line of reasoning insolving a problem. The inference mechanism can range from simple modus ponensbackward chaining of IF-THEN rules to case-based reasoning.3. Knowledge acquisition subsystem: A subsystem to help experts build knowledgebases. Collecting knowledge needed to solve problems and build the knowledge basecontinues to be the biggest bottleneck in building expert systems.4. Explanation subsystem: A subsystem that explains the system's actions. Theexplanation can range from how the final or intermediate solutions were arrived at tojustifying the need for additional data.5. User interface: The means of communication with the user. The user interface isgenerally not a part of the ES technology, and was not given much attention in thepast. However, it is now widely accepted that the user interface can make a criticaldifference in the perceived utility of a system regardless of the system'sperformance.

20.10.2005 4

Main characteristics of experts system• Class of solving tasks

– Diagnostics– Identification– Monitoring– Control– Forecasting

• Kind of application area• Knowledge representation method(s)• Method of solving of tasks

– Backward chaining– Forward chaining– Probabilistic reasoning– Marching – Argumentation – Fuzzy or deterministic inference– Using of linguistic variables or not– Using of non-monotonic reasoning or not

20.10.2005 5

Main characteristics of experts system (2)• Kind of user interface

– Menu– Dialog on Natural language

• Speech or text

• Is any other sources of facts besides user– Data bases– Any hardware– Internet– Documents

• Kind of explanation subsystem– Tracing– Embedded expert system for explanation

• Features of knowledge acquisition subsystem– Intelligent editor of KB– Learning

• Features of learning (methods, models)

20.10.2005 6

When to Use Expert Systems

• Development of ES is possible

• Development of ES is necessary

• Methods of knowledge engineering is corresponding to features of task

20.10.2005 7

Development of ES is possible

• There are experts in this area

• The experts must to agree between them during solving of task

• The experts must to able to explain solving and using methods by natural language

• The area must be enough structured

• The solving don’t must be based on common sense

20.10.2005 8

Development of ES is necessary

• The solving will make significant effect• Using of human-expert is impossible

because solving is needed concurrently in many different places or small number of experts

• During transfer to expert of information significant loss or distortion of one is possible

• It is needed to solve task in hostile area for human

20.10.2005 9

Methods of knowledge engineering is corresponding to features of task• The task may be solved by manipulation of

symbols but not numbers• The task has heuristic nature, i.e. the task which

may be warranty solved by formal procedures is unsuitable

• The task must be enough complex to excuse spending during development of ES

• The task must be enough narrow but really significant

20.10.2005 10

ES Development Stages

• Identification

• Conceptualization

• Formalization

• Implementation

• Testing

20.10.2005 11

Identification

• The determining of participants and them roles– The customer or end-user – target setting,

acceptance of work, agreements during work– The knowledge engineer – development of

architecture of Expert Systems, choice of tools, formalization of knowledge, interaction with experts

– The experts – sources of special knowledge– The programmers – for development of programs if it

is needed (whole expert system or additional parts)– The testers – testing of expert systems and its parts– The supervisor of project – coordination and

supervising of development, interaction with customer

20.10.2005 12

Identification (2)• Determination of problem

– Kind of tasks– How this task may be determined or described– Which subtasks may be extracted from task– What data must be used for solving of task– Which concepts are used for solving of task and links

between them– What is decision of task (view and concepts)– Which aspects of experience of expert is essential for

solving of task– What is nature and value of knowledge– What are obstacles for solving of task

20.10.2005 13

Identification (3)

• Determining of needed resources – humans, time, money

• Determining of goals:– Improve of quality of decision– Increase of speed of making of decision– Replace of human-expert– Replication and distribution of experience of

experts

20.10.2005 14

Conceptualization.The following questions may be used by the knowledge

engineer to help understand what the expert does:

• Exactly what decisions does the expert make? • What are the decision outcomes? • Which outcomes require greater reflection,

exploration or interaction? • What resources or inputs are required to reach a

decision? • What conditions are present when a particular

outcome is decided? • How consistently do these conditions predict a given

outcome? • At what point after exposure to influential inputs is a

decision made? • Given the particulars of a specific case, will the

outcome predictions of the knowledge engineering team be consistent with those of the expert?

20.10.2005 15

Conceptualization (2)• A typical approach would be to characterize the questions the end-

user might pose to the domain expert and the range of possible solutions.

• One method of getting started is to begin with a range of final recommendations, and then build pathways to these

• For example, in ES development to troubleshoot environmental problems in animal production facilities (simplified for the example), the top level of programming might involve the following typical

symptoms and recommendations:– animals too cold == > add insulation and/or space

heater – high humidity == > add space heater and/or increase

ventilation rate – animals too hot == > increase ventilation and/or add

insulation and/or decrease animal density

20.10.2005 16

Conceptualization (3)• The development process beyond this point is mainly

one of refinement and addition of detail once this top level is in place. For instance, in number one above, additional information would be added to help determine whether the hypothesis "animals too cold" is true. This is not as simple as it might seem on the surface, since the temperature of the building alone is not an accurate index of animal comfort. Other considerations include whether the floor is dry and well bedded, the flooring material in use, whether the building is drafty, where in the pen the animals tend to stay, whether all animals in the building have similar symptoms or if the problem is an isolated occurrence, whether animals are stretched out or huddled next to one another, if their hair is laid back or on end, or if they are noticeably shivering

20.10.2005 17

Conceptualization (4)• The final recommendation in item number one will

depend on the answers to questions that prove or disprove the hypothesis that the animals are too cold, and if they are cold, what is the cause. For example, if it is established that there are low insulation levels in the building, final recommendations will depend on the type and age of animal housed, climatic conditions in summer and winter for the building location, whether the animals will be in physical contact with the wall containing the insulation material, and on state and local building regulations and fire codes. Similarly, the type of heater recommended depends on the type and age of animals housed, the type and condition of building, local regulations, type and cost of fuel available, climatic conditions, type of ventilation system used, etc. As can be seen, the knowledge base evolves during this refining process to provide a recommendation as accurate as that made by the human expert

20.10.2005 18

Formalization

• Developers deal with description (formalization) of space of hypothesis, models of processes and characteristics of data

20.10.2005 19

Formalization (2)• To understand of structure of space of

hypothesis it is needed to formalize concepts and links between them during forming hypothesis– Is needed to describe of concepts as structures or

simple concepts– Is needed to describe of causal links between

concepts evidently– Is space of hypothesis finite or infinite– The space of hypothesis consist of determined

classes or must be generated by any procedures– Is suitable to view of hypothesis as hierarchies– Is any uncertainty in hypothesis– Is needed different levels of abstraction

20.10.2005 20

Implementation • The formalized knowledge is mapped or coded into the

framework of the development tool to build a working prototype

• The knowledge base should be extensively documented as it is coded. The potential for later misunderstanding and confusion should be minimized wherever possible

• Extensive justifications and explanations should be included to assist the end-user in fully understanding questions posed to them by the program, so that the user can effectively use the program output, and to show the user, on demand, how the recommendation was logically derived

• If capabilities of framework is not enough, it is needed to develop new framework or additional components

20.10.2005 21

Testing

• verification of individual relationships

• validation of program performance

• evaluation of the utility of the software package

Testing guides reformulation of concepts, redesign of representations and other refinements.

20.10.2005 22

Validation• correctness, consistency and

completeness of the rules • ability of the control strategy to consider

information in the order that corresponds to the problem solving process

• appropriateness of information about how conclusions are reached and why certain information is required

• agreement of the computer program output with the domain expert's corresponding solutions