KBS Lecture Notes

CSCI3006 - Fuzzy Logic and Knowledge Based Systems

Part Two :: Knowledge Based Systems

1. KBS OVERVIEWThis section addresses the development issues of Knowledge Based Systems (KBS). KBS are one of the most successful applied AI systems. They rely on maintaining knowledge rather than raw data, which is the case of databases. Many parts of this document relied on, as a main reference:

E. Turban, Expert Systems and Applied Artificial Intelligence. New York: Macmillan Publishing Company, 1992.

It is advisable to buy or view this book if possible especially chapters 4-7. Also chapter 13, which covers tools and programming languages/environments, would be useful to read.

There are four main topics to be covered here:

Knowledge acquisition Knowledge representation Inferencing Modelling uncertainty

1.1 What is AI?Artificial Intelligence is the field of computing that attempts at providing computational models of some human activities, which researchers consider intelligent activities, such as learning, acting, decision making, evolving and so on. AI, therefore, relates strongly to fields such as psychology, biology and sociology. In some cases new disciplines emerged such as bio-informatics and cybernetics.

1.2 AI applicationsAI has been used in several applications. Some of the typical AI applications can be classified as:

AI planning Diagnostic systems Data analysis and interpretation

o Machine learning o Data mining

Automated control Computer-aided design Decision support systems

The implementations of AI systems include financial systems, robotics and automated machinery, statistical packages and so on.

1 Of 32


Like most disciplines, AI covers a number of related sub-disciplines. These sub-disciplines share an essential approach to problem solving but have concerned themselves with different applications. Some of these applications are explained hereinafter.

1.2.1 Natural language processingThis area of AI is concerned with the creation of programs that are capable of reading, speaking or understanding languages as people use them every day.One of the major problems with natural language understanding is semantics. The same word may have very different meanings in different contexts. A popular story goes that when the saying

"The spirit is willing, but the flesh is weak"

was translated by a computer into Russian and back into English, it was rendered as

"The wine is good, but the meat is spoiled".

1.2.2 RoboticsRobotics is the study of the design, construction and use of robots. Within the scope of AI, robotics is principally concerned with devising software that equips robots with perception systems for vision, speech and touch. Robots already exist on many assembly lines. Researchers are, however, working on robots, which can see and find their way around factories without having to run on tracks.

1.2.3 Machine learningLearning has remained one the most difficult problems for AI researchers to tackle. A knowledge-based system may perform extensive and costly computations to solve a problem. Rather than remembering the solution, given the same or similar problem the system will perform the same sequence of computations again. Hardly the behaviour of an intelligent problem solver! Several programs have been written which suggest that machine learning is not an impossible goal. Perhaps the best example of this is AM, the Automated Mathematician. Initially given the concepts and axioms of set theory, AM was able to induce important mathematical concepts such as cardinality, integer arithmetic and many of the results of number theory. AM conjectured new theorems by modifying its current knowledge base and used rules of thumb to pursue the most "interesting" of a number of possible alternatives.

1.2.4 Artificial Neural NetworksOne of the most exciting areas of AI currently being implemented is ‘neural networks’. This approach seeks to build intelligent programs using models that parallel the structure of the brain. Neural net developers claim that their computers can synthesise knowledge from data they have not dealt with before. For example, a neural network, having been trained to recognise a human face from a few angles, can recognise it from an unfamiliar angle.

2 Of 32


1.2.5 Expert systems or Knowledge Based Systems (KBS)One major insight gained from early work in problem solving was the importance of domain - specific knowledge, a domain being a field or area of expertise. A financial advisor is not effective at drawing up personal pension plans merely because he possesses innate problem-solving skills but also because he possesses in-depth knowledge of personal pension plans.

This reliance on the knowledge of a human expert for a system's problem-solving strategies is a major feature of knowledge-based systems. It should be noted that most knowledge-based systems have been written for relatively specific domains. These domains are generally well structured and have clearly defined problem-solving strategies.

Knowledge based systems, the most commercially developed AI application, have mainly been responsible for taking AI out of the research laboratory and placing it firmly in a commercial environment.

1.3 AI as a search problemThe simplest view of AI systems is as a search problem solver. It is almost impossible to develop an expert system without implementing some search technique or another to navigate through the problem domain for the solution. Search techniques provide the base for the inference engine, which is an essential component of any expert system.

Traditional search algorithms: Depth first search Breadth first search

Simplest types of search are Depth First Search and Breadth First Search. These are known as Blind Searches.

Depth first would search in the following order:

3 Of 32


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Breadth first would be:

1 2 8 11 3 5 9 12 14 4 6 7 10 13 15 16

Depending on where the goal state is, one may reach a solution more quickly than the other.

Advantages Depth First Search: Requires less memory, only nodes on current path are stored (breadth first stores

everything) May find a solution very quickly (e.g. if solution is at end of first branch).

Advantages of Breadth First Search: Will not get trapped exploring a blind alley (i.e. if first branch goes on forever) Guaranteed to find a solution, and if there are a few solutions, the minimal one

will be found first.

Heuristic search techniques Generate and test: This is the simplest form of Search. First, list each possible

candidate solution in turn and check to see if it satisfies constraints. Then, either stop at 1st solution or keep going for next.

Hill climbing: Imagine we’re at the hospital, heading for the church. Using ‘as crow flies’ evaluation function as heuristic would opt for route to the shop rather than route to the park. Problem: can reach a dead end (local maxima).

Best first: This is like Hill Climbing but is exhaustive and will eventually search all possible paths. This therefore avoids local maxima problem of hill climbing. To do this it keeps a list of all the nodes that are still to be explored.

Problem reduction Constraint satisfaction Means-end analysis

4 Of 32


Example:

Consider the above tree. The number at each node indicates the cost to solution scores, (so lowest is best).

Breadth first – A B C D E F GDepth First - A B D E GHill Climbing – A C then gets stuck at local maximaBest First – A C B E G (this needs a good evaluation function to get the best results from using it.)

1.4 KBS development stages and life cycleAny computer software development has a 'life cycle'. That is, there are distinct phases through which a project develops. We have taken the view that expert systems should be developed in a similar manner to that of a conventional system - with some differences. We make no apologies for this as conventional system development techniques are needed to ensure that the finished system will be:

Built within deadlines Meet certain programming standards Easily maintained Meet user requirements Satisfy the functional description

For the above reasons we have separated the Project into the following sections: Project Selection Feasibility Study Knowledge Acquisition Requirements Analysis Prototype Tool Selection System Design

5 Of 32


Coding Testing Acceptance/Implementation

Feasibility StudyThis phase of the project will produce a document that will describe whether an expert system solution to the problem is attainable.

Need/BenefitsThe document will investigate clearly the need for an expert system and the possible benefits that could accrue from such a system. The knowledge engineer will discuss with various levels of management why they need a system. This will often interact heavily with the issues of the benefits such a system may bring. The benefits should be tied down as tightly as possible at this stage.

Discuss with expertThe knowledge engineer should discuss with potential expert(s) the proposed system. It is important that the knowledge engineer is familiar with some of the terminology the expert employs and so relevant background reading should take place prior to these discussions. The knowledge engineer will need to have a clear understanding of the type of knowledge. Questions that should be asked include:How much of the knowledge is

Common sense? Written down? Based on experience? How complex is the knowledge? How much knowledge is there?

This will be discussed more in the section on knowledge acquisition.

Involve the end userThe end user should be consulted. This will mean discussing with them the potential functionality of the system, what type of user interface should be employed and where they might use it.

It is very important in all the discussions at this stage not to 'turn off' the management, potential expert or users. In fact this is an ideal opportunity for the knowledge engineer to instil enthusiasm in all involved to make the whole project a success.

Requirements AnalysisThis is a very similar document to that produced in a more conventional system development. That is, it is a document that details some of the components of the feasibility study. It will be used as the base document for the systems design document. There are particular things relating to expert systems that need to be considered at this point in the life cycle.

6 Of 32


The End UserA more detailed description of the end user of the system is important as, particularly for expert systems, the range of users computer capabilities and understanding of the domain can be enormous.

FunctionalityParticular attention should be paid to 3 areas in the functionality of the final system:

The User InterfaceCare should be taken to discuss clearly what is required in this area. This is discussed in more detail later.

Target MachinesAt this point we should define as clearly as possible what constraints will be placed on hardware for the finished system.

Speed of ResponseA notorious problem with expert systems is the performance of the system from a users point of view. The knowledge engineer should ascertain clearly what will be acceptable as a maximum delay time.

EnvironmentExpert systems are often not employed in back offices but, for example, in public eye or at a control desk. This can impact significantly on the user interface and care should be taken, in discussion with the users, to ascertain exactly the environment the finished system will be run in. Questions that should be asked include:

Will there be more than one person using the system on the same machine?Are there printers attached? What quality? Are there issues of suitable colours? etc.

Development ResourcesA detailed analysis of the resources required to develop the expert system. This covers 3 aspects - hardware, software and personnel.

HardwareA detailed description of the hardware required for development. If the delivery machine is different from that of the development one there may be a requirement for access to a machine of the delivery type and any request should be made at this stage. If any purchases are required they should be itemised.

SoftwareAny development s/w that needs to be purchased should be itemised here. This should also include implications of maintenance and support costs and where a delivery system is required that also should be noted. A discussion on this topic takes place later.

7 Of 32


Personnel Management will require, at this stage, a clear statement of the amount of time that management, experts, users and knowledge engineers will have to make available for the development of the system. In particular, experts are very expensive and so will be of particular interest. There are no guidelines that we can give at this stage - suffice to say the time required to build an expert system is more than one might think!

System DesignThis document will contain a detailed design of the whole system. It will include:

A detailed data analysis outlining all the data to be used by the system, its format and its location.

All the rules and knowledge contained in the system. See the knowledge representation section for more detail.

A full design of the user interface. This should cover layout, colours, key strokes, letter sizes.

Interfaces to external software. Any interfaces to other languages or programs should be covered in detail.

These are only a few of the key points to be covered.

CodingThis is the section where the actual code is produced. Similar techniques and style should be adopted to that of conventional systems and descriptions of these are beyond the scope of this course. There are, however, some particular problems that relate to the coding of expert systems:

Efficiency. If the system is being developed using an expert systems shall or AI language then there are techniques for taking advantage of the way the system does its Inferencing to improve the speed of compilation and at run time. These techniques will vary from tool to tool and are ideally learnt by experience and discussion with people experienced in developing large systems using that particular tool. If such expertise is not available attendance of courses are a good second best with practice following on.

Control. If the system is of an advisory nature it is very important that the order in which advice and questions supplied to the user are given is correct. This can often be one of the most difficult problems when developing expert systems and a good deal of thought should be given as to the best way to facilitate this.

Change Control. Because building expert systems can become very interactive and the expert is usually heavily involved it is very easy to 'just' change a rule as soon as a problem is noticed . This should be avoided at all costs as it can lead to problems later. It can mean that this one change could have impacts on other rules or an impact on the system that will be unexpected. Unless changes like this are made in a controlled manner the knowledge base will become an untidy mess.

8 Of 32


Testing And AcceptanceThe testing and acceptance of an expert system are covered in detail later in the course. Because of the nature of expertise and knowledge the testing of an expert system can be very difficult and deserves special treatment.

ImplementationThe installation or implementation of a finished, tested expert system is very similar to that of a conventional system. The nature of consultative expert systems and the intended user(s) is such that there are 2 areas that have to be covered extremely carefully - training and the user guide.

TrainingExpert systems are often used by none computer literate people and are often consulted only on a irregular basis. The irregular use of any computer system means that it is very important the user attends a thorough and comprehensive course which is mainly 'hands-on'. This should have the added effect of instilling confidence in the system.

Because of the problems mentioned above it is important that a well-written user guide with examples, is given to all users.

SummaryIt is intended that this section has given an overview of the Key players in developing an expert system, the main stages of the lifecycle of an expert system and what roles those Key players play at each stage. All expert systems developments will be difficult and it is only intended that these are treated as good guidelines for a well controlled successful expert system project.

1.5 Some famous expert systemsDENDRAL (Late 60s) Stanford University. Inferred structure of organic molecules 1960s from their chemical formulas. Applied heuristic knowledge of expert chemist to the structure elucidation problem. Found correct structure out of millions of possibilities after only a few trials. DENDRAL is one of the first systems to effectively use domain-specific knowledge to achieve expert problem-solving performance.

MYCIN (Mid 1970s) Stanford University. Diagnoses and prescribes treatment for 1970s spinal meningitis and bacterial infections of the blood. Addressed problems of reasoning with uncertain or incomplete information. Provided clear and logical explanations of its reasoning. MYCIN has become an established methodology of contemporary expert systems.

PROSPECTOR (1980s) S.R.I. Acts as a consultant to aid exploration geologists in their search for ore deposits. Given data about a geological region, it estimates likelihood of finding particular mineral types there. Bases inferences on use of certainty factors and

9 Of 32


propagation of probabilities associated with data. PROSPECTOR is one of the first commercially successful expert system programs.

R1/XCON (1980s) C.M.U/DEC. Configures VAX 11/780 Computer systems for Digital Equipment Corp. (DEC). From a customer's order, it decides what components must be added to produce a complete operational system determines spatial relationship among all components. One of the largest and most mature rule-based expert systems in operation.

Health Service (1980s) Coopers & Lybrand. Measures NHS throughout; efficiency and expenditure based on Performance Indicators (PIs). System reads data from Symphony worksheets, calculates the PIs, uses its rules to evaluate performance and produces a final report. Built using the shell "Crystal", the system contains over 11,500 rules. Analyses which used to take 12 person-hours, now takes 9 minutes on a PC.

Reference: a good reference that covers several existing expert systems is:P. Jackson, Introduction to Expert Systems, Second Edition ed. UK: Addison Wesley Publishing Company, 1990.

1.6 Expert system shellsAn expert system shell is a tool that has been specifically designed to enable speedy development of expert systems. Leonardo is an example of a fairly sophisticated PC based shell (or environment).

Key features of expert systems shells are: The knowledge base and inference mechanism are totally separate. Shells offer a high level easy to use language for encoding the knowledge. The knowledge engineer does not have to write the inference engine since this is

supplied with the tool. The development of a sophisticated user interface is usually facilitated by

providing good screen designers. Most modern shells have tools such as editors, file handling facilities, debugging

facilities and so on.

The high level languageThe fact that there is a easy to use high level language for developing expert systems provides many advantages for knowledge engineers, experts and users. These can be summarised as:-

The syntax of these languages usually mean that not only can the knowledge engineer write code quicker but he/she will be able to show it to the expert and user for verification.

It frees up time for the knowledge engineer to concentrate on the difficult tasks of knowledge acquisition and knowledge refinement.

The languages are usually rule-based:if antecedentthen consequent

10 Of 32


The User InterfaceSince the user interface of expert systems is so important most shells offer facilities for developing an effective user interface.

Facilities are usually available for developing good explanation and help facilities Leonardo: F3 - Why, Expansion: slot F7, AVExpansion'How' and 'Why' facilities are usually built into the shellThere are, usually, many different ways of asking a question

Leonardo: menus(single and multiple), graphical, numbers, text

SummaryExpert System Shells are the way many applications are developed. They, for instance, are specially useful for small applications or where a company is just beginning to use this technology. They are also used for many serious, large applications and, indeed, the most well known systems in this country have been developed using shells such as Leonardo or Crystal. However, they do have certain drawbacks which often means that large, complicated applications are often prototyped in a shell and re-written in another language.

The advantages of shells can be summarised as:

Short Learning Curve . It doesn't take very long to learn how to get started with most shells. However, be warned, it can often be difficult to produce a system that is big and/or complicated

Fast Development Time . Systems can usually be developed fairly quickly using shells.

Inference Engine included . This is a major advantage as writing the software to inference on knowledge is not very easy at all and is very time consuming.

Easy Syntax . The language in most shells is easy to read and use. Cheap (on a PC)

The disadvantages of shells can be summarised as:

Inflexible . This is the main disadvantage. The limits of the language and the inferencing mechanism are often a great hindrance. Common practice is to use a shell to 'prototype' the ideas and knowledge representation and then write the final system in a another language such as 'C'.

Integration problems . Many modern day applications require a combination of different technologies or approaches. For example, it might be appropriate to want to link expert systems and databases. If you had an expert system that gave financial advice information may be required at certain points that can best be

11 Of 32


gained from a database. Expert System Shells are usually not particularly good at this.

Some Examples

There are literally hundreds of expert system shells available. Some examples are:

For the Mainframe: Application Expert(Cullinet) ESE (IBM) KBMS (AI Corp)

For the PC: Crystal (Intelligent Environments) KES (Software A&E) Leonardo (Bezant) Level 5

12 Of 32


2. KNOWLEDGE ACQUISITION

Definition - The process of acquiring, organizing, & studying knowledge.

Two main types of sources of knowledge – Documented (which can take many forms) and Undocumented (usually in the expert's mind).

There are two types of knowledge: shallow knowledge and deep knowledge.

Shallow knowledge: An expert has a base understanding of the subject, some of which could be described as general. For example a pensions expert will know that a pension is a source of income after retirement. Now, obviously a great many non-experts know this. It is, however, central to the understanding of the pensions domain. Other general knowledge could be the general strategy that the expert employs when solving a problem, the general class of problem that the expert is tackling and some typical problem solutions. This is sometimes referred to as meta-knowledge.

Example: surface level information might be represented as: If the weather is bad then stay in bed.

Deep Knowledge: This is the knowledge that has been acquired by years of experience and study and is the detailed `core` of the knowledge base. This knowledge covers such items as:

Relationships between data Rules/concepts How important each item is What order he/she performs tasks The detailed strategies for arriving at solutions

Example: if we take the weather example again, we may ask: for instance what do we class as bad weather, why does bad weather cause us not to want to go out, what's so good about staying in bed etc. Frames & semantic networks enable us to represent deeper knowledge.

Categories of Knowledge (three main ones): Declarative - i.e. descriptive knowledge, facts. Procedural - how things are done, how to use the declarative knowledge. Semantics - consider words & symbols & what they mean, how they are related &

manipulated. Reflects cognitive structure.

Why is it difficult to transfer knowledge? Hard to get experts to express how they solve problems Representation on machine requires detailed expression i.e. at a very low level.

Must be represented in a structured way.

13 Of 32


Bringing together the ideas of all those involved in the knowledge transfer process.

Various attempts have been made at overcoming these difficulties. This forms an important and active research area. One approach is the use of natural language interfaces so that experts can communicate directly. Computer aided knowledge acquisition tools are an alternative automated solution.

Difficulties with acquiring knowledge- discussion:1. The expert often finds it very difficult to articulate how he/she performs the tasks.

When asked why they do something an expert will often reply "because it works", or "I've always done it that way". This is obviously of little use to the knowledge engineer when trying to represent the knowledge for use by the computer.

2. A good deal of the information is vague. The knowledge engineer has to be able to cope with phrases like "usually" or "reasonably certain". This is usually referred to as fuzzy or uncertain knowledge. Probabilities or fuzzy sets are usually deployed to tackle this problem

3. The knowledge of one expert is not necessarily complete. There may be an, albeit small, area of the domain that the expert is not sufficiently conversant with. This will require the knowledge engineer to discuss with another expert who will, almost inevitably, want to offer an opinion on other areas that could conflict with the main expert. More than one expert being involved in developing an expert system is to be avoided if at all possible. Unfortunately it is often the case that multiple experts do have to be involved for a variety of reasons. Other than the problems with the knowledge there are issues that relate to inter personal relationships that can cause difficulties for the knowledge engineer. Experts, by their nature, are often very forceful personalities. That is, they believe that because they do their job very well that other people should do theirs` equally as effectively. They can also be quite eccentric, for example working strange hours. So, the knowledge engineer has to be able to acquire knowledge from this often irascible individual.

Key PlayersThe people involved in developing an expert system are:

The Knowledge Engineer(s) The Expert(s) The User(s) Programmers Management.

The above are involved in various stages of the development process and interact heavily. It should be noted here that one person can fulfil more than one role. For instance, an expert might also build the expert system and, indeed, is a member of the Management team. For reasons which will become clearer later, this is not usually an ideal situation.

14 Of 32


The Knowledge Engineer: The Knowledge Engineer is the name given to a person who actually develops expert systems. This person requires skills and expertise that are peculiar to the world of expert systems. Obviously a knowledge engineer needs to have a good technical grasp of expert systems software. This entails understanding the intricacies of particular software as well as experience in programming in a different 'style' to that of more conventional programming. This can obviously, to a large degree, be taught but a high level of skill is only acquired by experience.

The job of the knowledge engineer involves very high interaction with people - the experts, users and management. This means that he or she requires very good communication skills. The ability to talk at the right level using tact and diplomacy is a very rare skill. It can be compared to a systems analyst/programmer role with extra requirements of communication that extend beyond a systems analyst.

The Expert: The expert (or experts) is the person who provides most of the knowledge that is to be encapsulated in the expert system. He or she will be the final arbiter on the correctness of the finished system. The expert has experience or knowledge about a particular subject area. This is known as the domain and the expert is chiefly responsible for providing domain knowledge.

The ideal expert is one who is Articulate Enthusiastic Computer - literate

If an expert is not both articulate and enthusiastic there will be serious problems acquiring the knowledge for the system. Computer literacy is ideal but not necessary as if he/she has an understanding of what computers can and cannot do it will greatly enhance the discussions.

The User: The User (or, more usually, users) is the person who is actually going to use the finished system. If the expert system is a consultative or advisory system he/she will interact heavily with the finished system. If the system is not primarily consultative (e.g. plant control) the user will play less of a role in development but will still need to be consulted at various stages. Problems occur when individuals in a group of users have different skills and capabilities and care should be taken to ensure that the target user is well defined.

Management: Any expert system development that is to be successful has to have full support of management at all levels. Expert systems technology is a relatively new one. A good deal of ignorance and misinformation regarding their capabilities can lead to a wariness amongst management to commit scarce resources to an expert systems project. Therefore, management should be aware of expert systems their potential benefits and

15 Of 32


realistic costs. The development team may, therefore, consider giving a one day course or a day seminar to keep the management informed and maintain support and resources.

1.7 Basics of Knowledge acquisitionThere are different steps that the knowledge engineer has to take in acquiring knowledge. The knowledge engineers may use different tools and techniques to assist them in their jobs. In this section we cover the process of knowledge acquisition and the tools that may be used.

1.7.1 Preliminary WorkWhen acquiring knowledge about a domain it is absolutely crucial that the knowledge engineer can converse with the expert using the experts terminology. The knowledge engineer has to have a good grasp of the domain to be able to ask intelligent questions. The expert will soon become irritable and lose enthusiasm for the project very quickly if he/she finds he/she has to explain every tiny detail to the knowledge engineer. The knowledge engineer must therefore do some preliminary work before the first interview with the expert.

Reading. The knowledge engineer should get a list of the basic textbooks or other reading in the domain and read and understand sufficient of them to feel comfortable with the subject matter. Some useful sources for reading include manuals, handbooks, job procedures and of course textbooks.

Observation. If relevant the knowledge engineer should try to observe an expert in action. This gives a good feel for the way the exert works. This also allows for cross-referencing by the knowledge engineer of what the expert actually does with what he/she says they do.

Discussion. If possible discussions should take place with `nearly` experts. That is, in most domains, there are people who are very proficient but would not be deemed experts. The knowledge engineer can thus acquire a good amount of the knowledge from these people without using the experts` time.

1.7.2 The Knowledge HandbookOne of the functions of the knowledge engineer during the knowledge acquisition phase is to document the knowledge that has been acquired. One idea suggested (Wolfgram et al 1987 and others) is that of building a knowledge handbook. Wolfgram et al describe the contents of the handbook as follows:

1. The general problem description.2. Who the users are and their expectations of the system.3. A breakdown of the sub-problems and sub-domains for future knowledge

acquisition.4. A detailed description of the domain or sub-domain to be used for the prototype.5. A bibliography of reference documents.6. A list of vocabulary, concepts, terms, phrases and acronyms in the domain.7. A list of experts for the prototype.8. Some reasonable performance standards for the system, based on consultation with

the experts and users.

16 Of 32


9. Descriptions of typical reasoning scenarios gained from the knowledge acquisition.

Experience has shown that the above is not necessarily a complete list and it may be that not all sections are relevant. However, it is a good structure for organising and documenting the knowledge for the expert system.

1.7.3 Some Techniques for Knowledge AcquisitionIn this section we investigate some of the techniques available for knowledge acquisition. We discuss interviews, observation, protocol analysis, walkthroughs and repertory grids as some of the most practised forms and then finish it with a short discussion on the use of computers for automating the knowledge acquisition process.

Interviews-GeneralThe use of the interview for acquiring the knowledge from the expert is the most widely used technique. To begin this section there are some general pieces of advice that can be given when conducting interviews with experts.

Preparation. It is extremely important that the knowledge engineer has clearly in his/her mind specific expectations of the interview. The first interview can often be to get a clearer understanding of some of the terminology. At a later interview a goal could be, for instance, to discuss some of the specific rules that have been previously ascertained so as to clarify the knowledge engineers thoughts.

Keeping the expert `on track`. Assuming the preparation has been done properly with a set of specific requirements the knowledge engineer must keep a control of the interview by always keeping these requirements in mind. It is very easy for the interview to `wander`. The knowledge engineers interpersonal skills will be needed to try and bring the expert back to the point in question.

Explain yourself. The expert is in partnership with the knowledge engineer in developing the expert system. As such the expert should be fully briefed as to what the interview will cover, the main topics of discussion, how long the interview is going to take and so on.

Documentation. No matter how successful an interview has been it will be to no avail unless the contents of the interview are well documented. To achieve this the knowledge engineer will need, as well as pen and paper, a tape recorder. The less intrusive it is the better so the hand held types are ideal. Even though the interview is being recorded it helps to write notes as the interview progresses. These notes will include things to ask later in the interview, some key points, issues that have to be discussed etc.

After the interview, which should be kept as short as possible (an hour is the ideal length of time), the tape should be transcribed. If the interview is taking too long then it should be halted and a date set when the discussion can be continued. Sometimes this is not possible for various reasons. There is an alternative technique for analysing the interview.

17 Of 32


The knowledge engineer uses a tape recorder that has a counter. He/she plays through the tape making notes at the point where a main topic occurs with a note of the counter number. The tape is then listened to in more detail, making more copious notes. It is inevitable that out of each meeting with the expert there will be raised further questions and points. When these are taken back to the expert it can be useful to play the tape back to the expert to get clarification at that point.

Interviewing an expert is a skill that can be taught to a degree but at the end of the day it is down to the knowledge engineer adopting the techniques mentioned above combined with good interpersonal skills that will make for successful knowledge acquisition.

Some Interviewing TechniquesThere are two specific types of interviews that are important for effective knowledge acquisition. When each is to be used depends very much on the domain and how helpful and responsive the expert is.

Focused Interview. For this type of interview the knowledge engineer decides before the interview exactly the questions to be asked. It may even be appropriate to provide questions to the expert beforehand. When would this be most appropriate? It is usually most useful in early interviews for gaining a better understanding of the domain.

Structured Interview. In this case the knowledge engineer will use subject headings to control the order in the interview. These subject headings should be agreed with the expert at the beginning of the interview. The expert should ask the expert to give an overview of the topic but the knowledge engineer should expect to interrupt the expert where appropriate for clarification.

ObservationIt can often be very difficult for an expert to explain what he/she does and indeed the interpretation of what he/she actually does may not be totally accurate.

It can be very useful for the knowledge engineer to observe the expert in action. The way the expert actually solves the problem can have nuances that will not come across when the expert is interviewed. For example, an investment adviser when giving advice often recaps on what has been said, confirms accuracy with the person asking for advice, chats about their family and so on. An interactive system that modelled this process might well have to include some of these features if it is to be accepted by users.

It is important that you: Do not interrupt the expert You are as unobtrusive as possible You record what is happening other on video or audiotape.

18 Of 32


Protocol AnalysisProtocol analysis, typically, is the process by where the expert is asked to "think aloud" throughout the solving of the problem. The thinking is tape recorded, transcribed and analysed. The advantage of this approach is that the situation is a good deal more realistic than a, fairly false, interview situation.

The chief disadvantage of this approach is the problem of selecting the cases for the expert to talk through. The expert is the best person to make that decision.

It is not recommended that protocol analysis is used on its own but in conjunction with interviews and/or repertory grids etc.

WalkthroughsA walkthrough is where the knowledge engineer asks the expert to "walk" through the job they do. This is different from protocol analysis in that its not the thought process that is being considered but is the steps through which the expert has to be able to do his/her job. Because of this the knowledge engineer has the capability to interrupt the expert and probe as to why or how he/she is doing something. In protocol analysis interruptions should be avoided at all costs. Walkthroughs have the advantage of taking place in the experts environment, represent a real problem and do not present the, by comparison, false situation of an interview. The disadvantage is that it is not `real-time` because the knowledge engineer is, by necessity interrupting the process, the expert will often digress and get diverted by questions from the knowledge engineer. As with protocol analysis, walkthroughs should only be used in a complementary manner with interviews.

Repertory GridsRepertory grids are used to identify traits and attributes and to describe objects in terms of those traits and values. The idea is that you attempt to define features that distinguish selections with each feature having an opposite and make selections by considering characteristic traits and 'score' them in some way by attaching values.

Computer Aided Knowledge AcquisitionMost KA techniques are VERY time consuming. The experts are often inarticulate. The knowledge engineers are inexperienced and/or not sufficiently conversant with the domain. It is suggested that computers could be used effectively in this process and this should:

Increase productivity De-skill the KA process Eliminate the need for an expert?

The use of computers for KA is rapidly expanding and this section just considers a technique called rule induction and mentions some of the tools available.

Automated Rule InductionThis technique takes a set of examples to try and generate general rules.

19 Of 32


Advantages of rule induction If the knowledge is very complex and/or the domain is large then it may

not be possible to develop expert systems. If there is a 'bank' of old cases then rule induction may allow development of a system.

The developer of a system does not have to have all the skills of a knowledge engineer.

This approach may well allow for new knowledge to be acquired. Once a base set of rules have been developed using rule induction these

can be modified by the knowledge engineer and expert together.

Disadvantages/Problems with rule induction How are the attributes chosen? Algorithms are inefficient. Only suitable for rule based systems How do we choose the training set? The algorithms cannot usually deal with exceptions

Other Automatic Knowledge Acquisition Tools Auto-Intelligence - A PC based tool that allows interactive KA with some rule

induction Various Hybrid Approaches - Use of automatic tools and tools to aid the

knowledge engineer. The Knacq - A methodology for KA 'by exception' that provides a tool for

entering the knowledge and automatic code generation for various shells.

20 Of 32


3. KNOWLEDGE REPRESENTATION

1.8 Logic Representation and Prolog based systemsLogic representation may be the oldest knowledge representation form. The typical logical process consists of inputs that represent facts or premises and outputs that represent inferences or conclusions. The logical process is often referred to as logic proof. There are different techniques to provide logic proof, which is usually covered under Inferencing [refer to one of the references and the Inferencing section of this document]. There are several logic systems but few are proven to be computably possible. Thus, there are two main logical systems used: Propositional logic and Predicate logic (calculus).

Propositional PredicateNot v. useful for AI

Propositions – either TRUE or FALSE

Uses logic operators & symbols

Provides insight into higher representation techniques

Useful for AI

An extension of prepositional logic

Enhances representation by allowing use of variables & functions

e.g. Colour (Ball, Red)

Likes (John, Mary)

Likes & Colour are predicates;

Ball, Red, John Mary are constants.

Can also use variables:

e.g. Likes(X,Y)

Logic uses symbols to represent logical propositions and statements. The following table shows the widely used symbols.

Symbol AlternativesAND nOR uNOT IMPLIES EQUIVALENT

21 Of 32


Example:Given the following:xy: father(x,y) mother(x,y) parent (x,y)father (jeff, kim)father(jeff, alan)

We can derive:parent (jeff, kim)parent (jeff, alan)

Prolog, or Programming Logic, is a programming language/shell developed especially to enable the implementation of logic-based systems. It is often used to develop automated proof systems and automated problem solvers.

Advantages of PrologProlog, by the nature of being logical, can be very powerful. It is flexible, especially compared to shells, and because it includes a control strategy there is no need to write an inference mechanism.

Disadvantages of PrologProlog is difficult! It can take a while to become proficient in its use. The other major drawback of Prolog is that it can be very difficult to develop a good user interface.

1.9 Semantic NetworksOne of the oldest and easiest-to-understand knowledge representation schemes is the semantic network, or semantic net, which is composed of nodes and links. Semantic nets are basically graphic depictions of knowledge that show hierarchical relationships between objects and their attributes, concepts, events or actions.

Semantic networks are made of a number of circles, which are referred to as nodes, and links, which are referred to as arcs or relationships. Each node can represent an object, attribute, concept, event or action. These nodes are also interconnected by links, or arcs. These arcs show the relationships between the various objects and descriptive factors, i.e. attributes. Some of the most common arcs are of the is-a (class relation) or has-a (attribute relation) type. One of the most interesting and useful facts about a semantic network is that it can show inheritance supported by is-a links type. Since the semantic network is basically a hierarchy the various characteristics of some nodes actually inherit the characteristics of others. Can you think of an example?

[Please also refer to the handouts.]

22 Of 32


1.10 Scripts and Frames based systemsScripts and frames are two of the most commonly used knowledge representation forms and they are often used in software engineering and system analysis and design, perhaps under names.

A frame is a relatively large block or chunk of knowledge about a particular object, event, location, situation, or other element. The frame describes that object in great detail. The detail is given in the form of slots which describe the various attributes and characteristics of the object or situation. Each frame describes one object. To describe what frames are and how the knowledge is organized in a frame we need to use a special terminology. The relation between frames and object-oriented technology can be easily detected here.

[The terminology and more about frames pleas refer to the handout.]

A script as a knowledge representation scheme is similar to a frame, but instead of describing an object, the script describes a sequence of events. Like the frame, the script portrays a stereotyped situation. Unlike the frame, it is usually presented in a particular context. To describe a sequence of events, the script uses a series of slots containing information about the people, objects, and actions that are involved in the events. Some of the elements of a typical script include entry conditions, props, roles, tracks, and scenes. The entry conditions describe situations that must be satisfied before events in this script can occur or be valid. Props refer to objects that are used in the sequence of events that occur. Roles refer to the people involved in the script. The result is conditions that exist after the events in the script have occurred. Track refers to variations that might occur in a particular script. And finally, scenes describe the actual sequence of events that occur. [Hand out reference]

1.11 Lists and decision trees and Lisp based systemsLists and trees are simple structures used for representing hierarchical knowledge.

A list is a written series of related items. It can be a list of names of people you know, things to buy at the grocery store, things to do this week, or products in a catalog. Lists are normally used to represent knowledge in which objects are grouped, categorized, or graded according to rank or relationship. Objects are first divided into groups or dasses of similar items. Then, their relationships

Another method of knowledge representation is the decision table, which is organized in a spreadsheet format, using columns and rows. The table is divided into two parts. First, a list of attributes is developed and for each attribute all possible values are listed, then a list of conclusions is developed. Finally, the different configurations of attributes are matched against the conclusion.

Decision trees are related to tables and are used frequently in system analysis (in non-AI systems). They couple search strategy with knowledge relationships. They are composed

23 Of 32


of nodes representing goals and links representing decisions. AI1 terminal nodes except the root node are instances of a primary goal.

[Please refer to handouts]

Lisp, or list programming, is a programming language/shell to manipulate lists and symbolic data. It is very popular in what is known as symbolic AI, where symbols are used to represent qualitative, rather than quantitive, features of objects, events or concepts.

Much of the AI work carried out in the States is done in LISP and it is also popular in UK. It has similar advantages and disadvantages as Prolog.

1.12 Rule-based production systemsRule-based production systems are probably the most popular and commonly used form of knowledge representation in AI. For example, CLIPS is an expert system shell developed especially for developing rule-based systems. The production systems are modular knowledge representation schemes that are finding increasing popularity in many AI applications. The basic idea of these systems is that knowledge is presented as production rules in the form of condition-action pairs: "IF this condition (or premise or antecedent) occurs, THEN some action (or result, or conclusion, or consequence) will (or should) occur.

There are three major types of rules to be used in rule-based production systems. The first type is Knowledge Declarative Rules, which state all the facts and relationships about a problem. Inference Procedural Rules, on the other hand, advise on how to solve a problem given that certain facts are known. The third type of rules is known as Metarules, which are rules about rules. They pertain to other rules (or even to themselves).

[Please refer to the handouts]

24 Of 32


4. INFERENCINGInferencing is often linked to reasoning. It is the process of deriving answers of problems from knowledge that is maintained in a KBS. There are different types of Inferencing. In this section we cover some of the most popular and commonly used types of Inferencing.

1.13 Basic ComponentsTo understand Inferencing we have to understand the basic components of an expert system that to be used during Inferencing. Some of these components were covered earlier while some relate more to Inferencing problem in particular.

The knowledge base The knowledge base contains the know-how of the human experts in a particular field. Such know-how is of two types:-

Facts: also known as "deep knowledge". These are based on generalised learning from School and books and are well known and widely accepted by experts in the field.

Heuristics: known as "surface knowledge". Heuristics consist of "rules of thumb", ie. knowledge attained through experience.

Knowledge base is derived and implemented from our knowledge analysis and representation. It is the result of knowledge acquisition and representation, which we have already covered, and will be implemented within our expert system. For example, if we are using CLIPS to develop a rule-based production system, the knowledge base will be presented in the form of production rules.

The inference engineThe inference engine, which has two primary tasks:

Inference: the inference engine employs reasoning to examine existing facts and rules. Updates stored knowledge and draws conclusions.

Control: the inference engine's mechanism for controlling the search of the knowledge base. A time consuming task if the knowledge base is large and complex.

Working memory: An area of the Computer's RAM reserved for storing information regarding the current status of the problem e.g. conclusions reached so far, data input by the user and details of items within the knowledge base which have been checked.

External data source: Some expert systems receive input data from external sources other than the user. Common forms of this data - known as sensor data - include X rays, audible sounds and visual images. The system interprets the data and makes inferences based on that data. Consider a medical system used to monitor a patient's blood pressure. If the blood pressure reaches a certain critical level the system will automatically take some action, perhaps sending an alarm signal to the user (the nurse).

25 Of 32


1.14 Backward and Forward ChainingBackward chaining is a goal-driven approach in which you start from an expectation of what is to happen (hypothesis), then seek evidence that supports (or contradicts) your expectation. Often this entails formulating and testing intermediate hypotheses (or subhypotheses. To simplified, assume you have the following set of rules:

RULE 1

IF Customer wants comfort and Customer has enough_money THEN

Salesperson recommends Rolls Royce

And assume you are the sales person, and your question is ‘do I recommend Rolls Royce to this customer or not?’ In other words, you start from the conclusion (goal) and derive towards the explanation.

Backward chaining may use either depth first and breadth first search algorithms. Try to work out the Inferencing tree of both depth first and breadth first backward chaining inference engines using an ersatz set of rules.

Forward chaining is data-driven approach. In this approach we start from available information as it comes in, or from a basic idea, then try to draw conclusions. The computer analyzes the problem by looking for the facts that match the IF portion of its IF-THEN rules. If we take the sales person example again, forward chaining would be the approach to use if the question was ‘ the customer wants comfort and has enough money, what shall I recommend to him?’

Both techniques have their advantages and disadvantages and are often used in permutations. When this happens, a technique that is called opportunistic Inferencing is used. The idea behind opportunistic Inferencing is that some asserted facts in the working memory might lead to the firing of set of rules, which leads to speed up the Inferencing process. For example, Leonardo is principally backward chaining with 'opportunistic' forward chaining. Find out how the Inferencing engine in FUZZYCLIPS works.

[There is a handout to accompany this section]

1.15 Logic InferencingLogical Inferencing, which is sometimes referred to as problem solver or automated proof system, uses the logical rules that define the knowledge model [see knowledge representation] and try to derive or entail the conclusions. In its simplified version, logic Inferencing may look like forward and backward chaining, but it is usually more complicated than that. As a result, there are several assumptions to be used with logic Inferencing. The most famous assumption that is often used in logic-based models and systems is Closed World Assumption (CWA). CWA assumes that the logical system is closed and therefore there are no possible external effects to change the composition of

26 Of 32


this system. As a result anything that cannot be proved to be true in the model we can assume it to be false. In this case the system will treat not knowing as knowledge of the contrary. This sometimes leads to difficulties, for an example, missing symptoms of an illness does not necessary that the patient does not have that illness. However, that is exactly what the system may conclude using the closed world assumption.

There are several logic-based models and systems developed such as default logic, non-monotonic logic and situation calculus. The logic-models are often very complicated to be translated into computable models. We always seek that our models are sound and complete. What do you think we mean by soundness and completeness?

One of the weaknesses, beside complexity, is that the logic-based systems suffer from is usually Logical Contradiction. Logical contradiction happens when the system, for example, allows us to entail X and not X at the same time. Sometimes logical contradiction is defined within the context of KBS to be the case in which the system reaches a conclusion that is known by the user to be false.

1.16 Other Inferencing techniquesThere are several Inferencing techniques may be used depending on the system domain. Here are some of the commonly used techniques:

Model-based reasoning. Case-based reasoning. Monotonic and non-monotonic reasoning. Truth maintenance systems.

Also you may find: Hypothetical reasoning. Analogical reasoning. Procedural reasoning. Hierarchial reasoning. Inductive and deductive reasoning. Pattern matching.

27 Of 32


5. KBS APPLICATIONS

1.17 Conventional programs versus expert systemsNumerous managers ask, ‘isn’t any computer program that does a job formerly done by a human an expert system?’ A spreadsheet package and an expert system could both be used to aid the decision making process of a financial institution. Why then is a spreadsheet not considered to be an expert system? There is, perhaps truthfully, no precise answer to these questions. However, the difference may be one of emphasis. Ultimately, the revolutionary ideas posed by expert systems are primarily concerned with new conceptual insights into how people can use computers to help solve problems

Conventional Programs Expert Systems

Often primarily numeric processing Primarily symbolic processing Problems solved by application of algorithms

Problems solved by application of heuristics

Numerically addressed data base Symbolically structured knowledge base in working memory

Information and control integrated together

Control structure usually separate from domain knowledge

Difficult to modify Usually easy to modify, update and enlargeBest possible solution usually sought Satisfactory answers usually acceptable Mid-run explanation very difficult Mid-run explanation easy

1.18 Potential applications of expert systemsExpert systems have been developed for a variety of reasons. Some of which are listed below:

Rare skills archiving e.g. preserving the expertise of an ageing employee who is about to retire.

To draw together existing knowledge and then extend it. This may occur where there is no single expert in a particular field.

Expertise is not available when and where it is needed. This may be because the expertise is scarce or because it is required in a hostile environment.

To provide training for new members of staff. To analyse, examine and interpret complex data, regulations or procedures which

would be a very time-consuming and error-prone exercise for humans to undertake.

To release experts from the more mundane problem solving tasks so that they can concentrate on more complex and unusual problems.

Real-time monitoring tasks e.g. patient respiration where constant checks need to be carried out and where an instant response is required if the situation reaches a certain critical level.

To increase productivity/profits or decrease costs.

28 Of 32


Expert systems have been applied to a wide variety of problems, some of which are:

Function Domain SystemPlanning Robotics NOAH

Job Shop Scheduling ISIS - II Planetary flybys DEVISER

Diagnosis Medicine MYCIN Computer Faults IDT Nuclear Reactor Accidents REACTOR

Data Analysis and Interpretation

Chemistry DENDRAL

Geology PROSPECTOR Protein Crystallography CRYSALIS

Analysis Electrical Circuits EL Earthquake Damage Assessment

SPERIL

Design Computer System Configuration

XCON

Automatic Programming PECOS Signal Interpretation Speech Understanding HEARSAY II

Ocean Surveillance HASP Medicine-Left Ventrical Performance

ALVEN

Monitoring Patient Respiration VM Computer Aided Instruction Medical Diagnosis GUIDON

Mathematics EXCHECK Causes of Rainfall WHY

Consultation/Intelligent Assistant

Radiology RAYDEX

Computer Sales XCEL Prompting Reconsider

1.19 The Limitations of expert systemsAlthough expert systems offer great potential, developers should be aware of a number of potential problems. Current deficiencies in the technology available include:

Difficulty in capturing "deep knowledge". For example, MYCIN, the medical expert system, lacks any real knowledge of human physiology. It does not know what blood does or the functions of the spinal cord.

Inability to provide deep explanations. Because expert systems lack deep knowledge, their explanations are generally restricted to a description of the steps taken in finding a solution. They cannot tell why a certain approach was taken.

Fragility and rigidity. Expert systems tend to be very "fragile" at the boundaries of their knowledge domain. If humans are presented with a problem that they cannot immediately solve, they can return to an examination of first principles

29 Of 32


and come up with a strategy for attacking the problem. Expert systems lack this broad base of common sense.

Difficulties in verification. The correctness of any large computer system is difficult to prove. The verification of knowledge based systems, with such large numbers of potential paths through a knowledge base particularly difficult.

Little learning from experience. Once an expert system is complete, its performance will not improve without further attention from its programmers.

Dealing with uncertainty. Many problems, such as medical diagnosis, involve a considerable degree of uncertainty. Most expert systems are unable to adequately deal with uncertainty.

Inability to deal with temporal or spatial knowledge. Expert systems have not proved successful at dealing with knowledge of a temporary nature or with interpretation of 3-D problems.

30 Of 32


6. MODELING UNCERTAINTY

It is often the case that the Inferencing of conclusions from given evidences is not exact. Instead, it depends on some uncertain factors. For example, in the case of having cold or flu we may not be certain in our diagnostic, instead we give a probability. This uncertainty in knowledge and Inferencing is a strong challenge for expert systems. There are several techniques developed to deal with uncertainty in KBS. The main two approaches to these solutions are fuzzy logic and probability theory (e.g. Belief Networks). [There is a handout that covers this topic].

31 Of 32


7. REFERENCES

[1] P. Jackson, Introduction to Expert Systems, Second Edition ed. UK: Addison Wesley Publishing Company, 1990.[2] E. Turban, Expert Systems and Applied Artificial Intelligence. New York: Macmillan Publishing Company, 1992.[3] T. Dean, J. Allen, and Y. Aloimonos, Artificial Intelligence: Theory and Practice: The Benjamin/Cummings Publishing Company, Inc., 1995.

32 Of 32

KBS Lecture Notes

Documents

Transcript of KBS Lecture Notes