Why Expert Systems die ... and how to prevent them dying PROBLEM AREAS Many are the problems facing the builder of Expert Systems, Šandmuch effort and money has been wasted on failures. This set of Šlectureslooks at some of the reasons for these failures, and then Šoffers someguidelines for reducing the failure rate. (Because few organisations speak about their failures, there Šwillbe few references. Some references will be made to AB's Špersonalexperience.) Expert Systems can die (ie. be failures) for a number of Šreasons,and the most common have to do with one or more of the aspects Šshown onthe slide. We will look at each in turn. PROJECT MANAGEMENT Slow development Some ESs die because they take too long Štobuild, and the project is abandoned. Often this is due to a number Šofother reasons concerned with the management of the project. Prototyping taken too far Prototyping, or Šincrementaldevelopment, is a method of developing an ES (or any other Šcomputersystem) by continually refining it. It avoids having to do a Šthree)monthanalysis period, and usually allows the client to see some Š'tangible'results within a few weeks, or even days, of starting. But Šin many ESprojects, prototyping has been taken too far, and there is Šno discipline. Time is taken to make small amendments to the system Šthat are not reallynecessary, while important changes can be ignored. ŠThis problem has beenexacerbated by the advent of easy)to)use AI Šworkstations, which encourageone to do everything at the screen, Šrather than go away and think aboutit. Purpose/roles not clear In particular, is it now all too easy Štogo straight into coding of knowledge, without clarifying what the Špurposeand roles of the ES are to be. So the ES may end up not Šreallyfulfilling any useful purpose. Poor client commitment Some ES die because the client is Šnottruly committed to the project. Perhaps they have been 'leant on' Šbyhigher management to 'develop an Expert System'. If there is poor Šclientcommitment, then it is likely that the necessary experts and Štesters willnot be fully available; see below. Unspoken objectives In any project, where there are Šunspokenobjectives, the project is in jeopardy, since those working on Štheproject will be pulling in different directions. Harmony of the Šproject,or its cost)effectiveness are then in danger. One example of Šan unspokenobjective is that the knowledge engineers want to get their Šhands onexpensive AI kit, and so they will tend to justify what is not Šreallyneeded. They betray their position of trust as ES experts. Solution looking for a problem There has too often, in ESs, Šbeenthe tendency to push the technology for its own sake. This tends Što leadto real benefits not being given enough consideration. When Šthe actualbenefits are found to be few, the ES is abandoned. KNOWLEDGE ELICITATION Spatial/sensory knowledge If the area of problem solving thatthe ŠES is being applied in relies on a lot of spatial or sensoryknowledge Šthen ES technology cannot handle it. Common)sense knowledge This also applies to Šcommon)senseknowledge ) that kind of wide knowledge of the world, that Šis the basisof everybody's experience, and which we all take for Šgranted. eg. Thatit is a good thing to reduce cost, or that people Štend to have certainmoral or social or physical characteristics. If Šsuch knowledge isrelevant to the problem)solving in which the ES is Šdesigned to fit, thenit must be explicitly encoded, and none of it Šmust be missing. Nobodyhas yet been able to encode such wide)ranging Šknowledge. Similarity recognition This is a third feature of human Šthinkingthat cannot as yet be emulated by ESs with any success. We so Šoften makedecisions, not by performing precise reasoning, but by Šlooking for'similar' cases in the past. Where these three features of human thinking or knowledge Šareimportant in the problem solving area to which the ES is being Šapplied,then the ES is likely to fail, since it will either take too Šlong tobuild, or it will be too cumbersome to use, or it will too Šoften givemisleading result. Aim to emulate the expert Experts are highly subjective, Šandoften have their quirks and areas of error. If the aim of the ŠESproject is to emulate the particular expert from which the expertise Šisbeing elicited, then it is likely to emulate all his/her failings Štoo,but without the nimble thinking or social graces by which the Šexpert getsround them. The aim of an ES should not be to emulate an Šexpert, but toencapsulate knowledge that will be useful in given Šproblem solvingsituations. Difficult to express knowledge Some knowledge is difficult Štoexpress. This has been covered in Part A. Disagreement among experts This has been covered in Part A. Incomplete knowledge Especially contextual assumptions, if Štheyare lacking, will make the ES fragile, and fall over if outside Šitsoriginal context. No true expert This has been covered in Part A. Unco)operative expert This has been covered in Part A. EMBEDDING THE EXPERT SYSTEM By embedding the ES, we mean getting it to those who will use Šit,and getting it into use there. Poor sales or take)up If the ES is not 'sold' properly )remember Šthat this is market)creation ) then few people are likely to useit. ŠThis effect may only happen after an initial rush of enthusiasm forthe Šnew technology has died away. In particular, it is important tosell Šthe 'effect' that the ES will have rather than the 'product', Šnamelythat this is an ES. People don't trust it If people will not trust the ES to Šeithergive them right results, or real benefits, then they are Šunlikely totake it up and use it. Poor training Users need to be trained to use the ES. Not Šonlyin the mechanics of which key to press to get which operation, but Šinwhich operations they need to try. They may also need to 'get the Šfeel'for the ES. Incompatibilities If the ES is incompatible with either Štheusers' current software, or more important, with their current ways Šofworking, then it is unlikely to be used, except by force. HOW IT PERFORMS Doesn't work If the ES is found to have given wrong results Štoooften, then it will fall into disuse. Cumbersome If the ES is cumbersome to use, eg. by asking toomany Š'trivial' questions, or by requiring the user to leave his/her Šdesk,then it may fall into disuse. Poor MMI If the ES has a poor man)machine interface, then it Šmayfall into disuse. Fragile Fragility refers to the ES giving bad results Šwhenapplied to a context different from, but not too different, from Šthat inwhich it was built. Since most ESs will be used in slightly Šdifferentcontexts, fragility can be disastrous. The opposite of Šfragility is'degrading gracefully' ) just as human experts do. No benefits to those affected If those affected by the ES )those Šwho have to feed it with information, or who have to use Šitsinformation, or who are otherwise indirectly affected ) do not see Šanybenefits for themselves, then they are unlikely to be happy. They Šmayeither feed it poor quality information, or otherwise resist its Šuse. Itmay then fall into disuse. The old ways are easiest or best This is a form of the Špreviouspoint, but if the ES is more cumbersome than the old ways ) Šoften becausethey made use of the human being's capacity for sensory Šor common)sensethinking ) then it may fall into disuse. Answers questions that nobody is asking It is usually better Šiftechnology is applied to do new things, rather than just Š'replacepeople'. But this can be taken too far. Built for wrong part of business cycle; out of date An ES Šofreasonable size usually takes a year or two to build, and the Šknowledgeof the experts may well stem from a year of two before that, Šsince themost recent experiences may not have been assimilated into Šhis/her storeof expertise as anything other than specific examples. ŠSo, when the ESis first made available, it contains knowledge that is, Šsay, three yearsold. In many areas, it will take a couple of years or Šmore beforemaximum uptake is obtained. So, by the time the ES is Šbeing heavilyused, its knowledge may be five years out of date. This Šcould bedisastrous. COSTS Not cost)effective The development costs are unlikely to Šberecouped. The running costs exceed the benefits. But remember Štoinclude the intangible benefits, such as public image, in Šthesecalculations. Not really needed Is the ES really needed? Would other, Šcheaperways, be as good? Maintenance too costly Knowledge changes. So not only Šmustmaintenance be concerned with bugs, but also with this Šchangingknowledge. Maintenance (or 'continual development' as some Šcall it) islikely to be higher for ESs than for conventional systems. ŠIs it worthit? ENVIRONMENT/ORGANISATION Pawn of empire)builder Is the ES project part of some Šschemewhereby one person tries to build his/her empire within an Šorganisation? If so, the success of the ES will be tied too closely to Šthe currentpopularity of the empire)builder. Pawn of career developer Similar to the previous case, but Šoftenthe career developer is the knowledge engineer, who is using this Šprojectjust to increase his/her reputation or as a step up the ladder. ŠS/he hasno real commitment to the project as such. Inter)department wrangling Has the ES project been given the Šgo*ahead in order to put one in the eye of another department? A Šdangerousposition to be in. Swept away in re)organisations If the ES is tied too closely Štothe work of one department ) and especially if it were part of Štheprevious case ) then when that department is wound up or absorbed, Šthe ESmay die. 'Rationalisation' of computer systems, of ways of Šworking, etc.sweeps it away. The ES should be designed for maximum Šbenefits, not onlyfor the immediate client's department, but also for Šthe organisation as awhole. Didn't plan for the required organisational changes As was Šsaidin Part A (Interface levels), using an ES may lead to, or require, Šachange to the organisation. Perhaps people's jobs change. Perhaps Šawhole new section is needed, to provide the type of information that ŠtheES needs. It is too late to discover this after the ES is built Šand inuse. It should be considered and planned for in good time. HOW TO PREVENT THEM DYING We now look at a number of ways of reducing the risk that ŠanExpert System will 'die'. We will cover those areas shown on the slide. We are thinking about ESs to be used in real)life problemsolving, Šrather than those used merely for a demonstration of feasibilityof the Štechnology. We here present a staged development process, whichhas Šsome of the advantages both of rapid prototyping and of Štheconventional staged approach. STAGES IN DEVELOPMENT OF AN ES Stage 1. Start In this stage, which is often two weeks inlength, Šthose involved in the project get to know each other, and suchthings Šas purpose of the ES, the roles it must fulfil, who the users areto Šbe, the benefits expected, the likely change on the organisation, Šarethought out. However, these things will not find their final form Šduringthis period; some aspects are likely to alter as the ES develops Šthroughat least the next two stages. Also, the knowledge engineers Šmeet theexpert(s), and are introduced to the knowledge. From a Šknowledge of thepurpose and benefits to be expected, they can design a Š... Stage 2. Skeleton system This is a system that behaves as Šthefinal ES might, but on a macro level. It may ask a couple of Šdummyquestion, give a couple of screens of text as dummy results, and Šallowthe user to seek dummy explanations. There is no knowledge in Šit, exceptfor high)level control knowledge. It serves two purposes. ŠIt allows theexperts to gain some feel for what ES technology might be Šable to do,and it acts as a sounding board for clarifying what the Špurpose of the ESis. Then the knowledge elicitation can start for Šreal, to produce,after, say, three months, a ... Stage 3. Demonstration system This has real knowledge in it, Šbutthe knowledge is far from complete or correct. It behaves roughly Šasthe final system would, and gives reasonable results in a few cases. ŠThis system can be shown to the client, to enable them to see what Šisemerging. It gives them an opportunity to re)evaluate the project, Šandabandon it if necessary ) as part of a feasibility study. Then Šanother,say, 6 months' of knowledge elicitation produces the ... Stage 4. Working system By this time the knowledge Šissubstantially complete and correct (though perhaps not 100%). The ŠES hasundergone some validation. It gives correct results, and many ŠESprojects stop here and think they have done a good job. But it may Šbecumbersome to use for real. So we have to go further to a ... Stage 5. Usable system This is less cumbersome to use, Šallowingthe user to link to a database, or to perform what)if Šanalyses, etc. This is the time to design the explanation facilities. ŠTo produce ausable system, there has to knowledge elicitation from Šusers as well asexperts. Stage 6. Saleable system The usable system may be untidy, Špoorlyworded, or have no User Manual. Those who have been involved Šwith theproject, or are otherwise sympathetic to it, will be inclined Što use it,but not other people. There is usually a need to transform Ša usablesystem into a saleable one. Stage 7. Embedded in use Here the ES is in regular use. ŠLittleis known of this stage, since few ESs have got here. In practice, the stages overlap. Discuss: cf. 5 steps in Part A. THE FIVE HURDLES We now look at some of the things to consider during the ŠStartstage. First we have to decide whether or not an ES should be Šdeveloped. Only if we can get over five hurdles is it wise to develop Šan ES in thisapplication. They are here presented as yes/no questions. In practice, Štheirpurpose is to generate systematic thought, about how to arrange Šthings sothat we get over the hurdles. Is expertise available? HOw can we ensure the required Šexpertsare available, and willing to co)operate? This has been Šcovered in PartA. Do we need ES? Or would conventional computing technology, Šwhichis better known, be just as good? In particular, would a Šspreadsheet besufficient? Is ES 'man' enough? Or is there too much sensory or Šcommon)senseknowledge? If so, can we define a sub)set of the Šapplication in which EStechnology would be useful, while leaving such Šthinking to the user? The above two concern the two limits of the applicability of ŠESshown on the next slide. Is it worth it? Here we have to enumerate the benefits(including Šthe intangible ones) and compare them with the costs ofdeveloping and Šrunning and maintaining the ES. To help predict the rangeof benefits Šlikely, it is useful to consider the Roles of ESs; see later. Also, to Šanswer this question properly, we have to have a clear idea ofthe Špurpose of the ES. Is it acceptable? With users, with experts, with those who Šmayhave to do extra work to provide information, with those who have Što makeuse of the information it will provide, etc. These have been Šcovered inPart A (Interface Levels). This is more a question of Šplanning how tomake acceptable to all, rather than a simple yes/no Šanswer. SPECTRUM OF KNOWLEDGE We can see knowledge as forming a spectrum, from Šstructuredknowledge, which is highly ordered and classified and often Šnumerical, tounstructured knowledge. Conventional computing has Štraditionally beenrestricted to the structured end, and human thinking Šis needed for theunstructured knowledge. ES technology allows computers to move a little more towards Štheunstructured end. In particular, it can handle the twin problems Šofcomplexity and judgement, though perhaps not perfectly. So, as a Šroughrule of thumb, we can say that ESs are best for domains that Šhavecomplexity and/or judgement. But common)sense reasoning, and the intuitive knowing the Špropercontext of things, is still the preserve of human thinking. The question for any ES project is where the boundaries lie. ROLES, USERS AND BENEFITS Some of the Five Hurdles are linked in the way shown on theslide. ŠBut the slide also shows what needs to be taken into account inorder Što get over the 'Worth it?' hurdle. The potential benefits we can expect from the ES in Štheapplication are determined by the roles it should fulfil in Štheapplication and the users. If we then add the objectives of the Šsystem,this then determines what benefits are relevant to us. Whether Šthesebenefits become actual or not then depends on our ability to Šencapsulatethe knowledge )first three hurdles) and on the system's Šacceptability(fifth hurdle). Owing to the importance of roles and benefits, we will look Šatthem now. TYPES OF USER Much ES literature speaks about 'the user', sometimes in Štheplural. In fact, there are several types of user (or Š'stakeholder'). Each type of user can expect a different set of Šbenefits and/orconstraints. The knowledge engineer should attempt to Šensure that allstakeholders feel benefits from the ES; this is the Šessence of ensuringacceptability of the ES. ROLES OF EXPERT SYSTEMS Traditionally, ESs have been seen as mini)consultants. You go Štothem for advice, they ask you a number of question, and give Šyou(hopefully) good advice. Like a human consultant, they can explain Štheirreasoning. But there are at least seven other roles that ESs can Švalidlyfulfil. The slide shows them. It is too easy to be Šdisparaging aboutthe ES being 'merely' a glorified checklist. If that Šis where thebenefits lie, then the Checklist role is a very valid one Šfor the ES. In each role, there are certain benefits that are important, Šandthere are differences in the type of knowledge required in the ES. ŠTheuser, expert and client will see different benefits. (Note that Šbenefitsare relative, not absolute. So some of those mentioned are Šrelative toemploying conventional computing techniques, but most are Šrelative tohaving no computer techniques.) We will go through the roles one by one. In practice, an ES may fulfil several roles, eg. consultancy Šandtraining. Roles are discussed at greater length in 'On the application ŠofExpert Systems', by A. Basden, International Journal of Man ŠMachineStudies, 1983. CONSULTANCY ROLE This has been described above. The system gives advice and,where Šnecessary, explanations. Since the advice will be used by the userfor Šreal)life decision)making, the knowledge in the KB must be reliable. BENEFITS IN THE CONSULTANCY ROLE These will be explained during the lecture. CHECKLIST ROLE This is a cut)down version of the consultancy role. Here Štheimportant thing is that all the right questions are asked of the Šuser, sothat s/he will not overlook some vital fact. The ES may give Šadvice andexplanations, but these are of less importance. So it is Šless importantthat the knowledge itself is reliable, just so long as Šthe systemreliably asks all the right questions. Think of the checklist role ES as a questionnaire. It comes Šintoits own when the number of potentially relevant questions is high, Šbutthere is a need to weed out those that are not relevant in any Šgivensituation. The backward)chaining facility of ESs can be put to Šgood usehere. Since it is less important that the knowledge itself is Šcorrect,the ESs can fulfil a checklist role in domains where the Šknowledge iswide and shallow, or difficult to obtain, or where true Šexpertise is justnot available. Here the full consultancy role may be Šinfeasible, but achecklist role may still give some benefits. BENEFITS IN CHECKLIST ROLE These will be explained during the lecture. MONITORING ROLE Here the ES is monitoring some process continually, such Šaschemical plant or a computer Operating System, and its knowledge is Šofthings like what constitutes error conditions and what to about Šthem. The user (the plant operator, perhaps) may not have much Šinteraction withthe ES, unless something goes wrong. The input Šinformation comes fromthe process that is being monitored. Explanations become important, since the user will want Štoinvestigate what lies behind the reported faults etc. The knowledge held by the ES in its KB must be very thorough Šandwell tested. BENEFITS IN THE MONITORING ROLE These will be explained during the lecture. PROGRAM ROLE Here the ES is treated as though it were merely a program. ŠInteraction with the user may be less important, depending on what Šthe'program' must do, and explanations are unlikely to of any Šimportance atall. The reason ES technology is used, over conventional Šcomputingtechnology, is the ease with which complex knowledge can be Šencoded. The DEC XCON system is an ES used in the program role. So areESs Šthat are used as front)ends to Databases and other complex Šsoftwarepackages. BENEFITS IN THE PROGRAM ROLE These will be explained during the lecture. TRAINING ROLE There is much interest in using ESs in training. They add Šsome'intelligence' to conventional CBT etc. But most that are Šdesigned totrain novice people are still in the research stage. But ŠESs can be usedvery effectively to sharpen up the skills and Šunderstanding ofpractitioners in the field. In this role, the user will be asked questions and will be Šgivensome advice. But explanations are the important factor here. ŠAlso, theability to encode complex knowledge in the ES allows the Šsession with theuser to be tailored to his/her needs. Obviously the knowledge in the KB must be reliable and correct. BENEFITS IN THE TRAINING ROLE These will be explained during the lecture. COMMUNICATION ROLE In the Training role, the purpose of the ES is to Šcommunicateknowledge rather than to give advice. This can be taken Šfurther, to theCommunication role. Here there knowledge is not Šimparted to a lessexpert person, the trainee, but to someone of about Šthe same level ofexpertise. The purpose may be to allow comparison of Šexpertise, ordiscussion about a particular problem. The KB of the ES Šis used simplyas a communication medium for ideas and concepts that Šallows some degreeof standardisation. For this reason, it is not necessary that the knowledge in the ŠKBbe reliable and complete, but rather that the language (pictorial Šortextual) in which the knowledge is expressed be easy and natural to Šuse. (Note that explanations are like de)compiling the internal Šknowledge.) So validation assumes lesser importance. In this role the ES is a glorified pencil and paper. But it Šhasthe advantage of having software with which to 'exercise' the Šknowledge. It can also be used to document expertise. BENEFITS IN THE COMMUNICATION ROLE These will be explained during the lecture. KNOWLEDGE REFINEMENT ROLE It has been found that the very process of building an ES helpsto Šclarify and thus refine the knowledge of the expert. It makes Šclearwhere there are gaps in his/her knowledge (and thus helps a ŠResearchManager set a research strategy). ENEFITS IN THE KNOWLEDGE REFINEMENT ROLE These will be explained during the lecture. DEMONSTRATION ROLE In practice, at least at this early stage in the application ofES Štechnology, many ESs have a role of demonstrating the capabilities Šofthe technology, whatever other roles they may also have. The first ŠES inan organisation will be scrutinised by other departments, when Štheyconsider using ESs. In this role the important thing is to so design the ES Šthatnothing about it looks clumsy. But demonstrating the capabilities Šof ESsconsists of far more than just showing that a given area of Šknowledge canbe encapsulated in a slick form (with the emphasis during Šthe projectbeing on hardware, software, knowledge representation and Šscreen design). Many of the Alvey Community CLub projects stopped Šhere. A much moreimportant aspect is demonstrate how true business Šbenefits, of a varietyof kinds, can be obtained, and how these can Šobtained easily by using EStechnology. (We do not discuss benefits in the demonstration role.) THE KNOWLEDGE ENGINEER The knowledge engineer must have certain skills, and attitudes to Šmaximize success of an ES. Systems analysis skills Much of the skill in knowledge Šengineering is akin to that in conventional systems analysis. But the Šknowledge engineer must have more .. Intimate relationship with expert It is no good merely obtaining Šsuperficial knowledge from the expert; full and deep knowledge must be Šobtained. Knowledge engineering is more than just asking coldly and Šobjectively about 'requirements'. This requires that the expert is Šencouraged to express his/her knowledge and make it clear. This can Šbe a very personal experience for the expert, and the knowledge Šengineer forms a fairly intimate relationship with him/her. Attitude to expert The knowledge engineer must hold the expert Šin respect. But s/he must be able to question the expert, to remain Šsomewhat distant from the expertise that is being elicited. S/he must Šbe alert to possible inconsistencies in what the experts say; these Šcan be a valuable source of new knowledge. Attitude to knowledge The aim should be to gather enough Šknowledge to build an ES that is useful for the defined problem- Šsolving purpose and roles. So some of expert's knowledge may be Širrelevant, or may require transformation into another form. Also, Šsome of the expert's knowledge may be wrong or misleading. The KE Šshould not always assume that the currently)used strategies, concept Šclasses, etc. are those which should be included in the ES ) Šespecially if the ES is designed to fulfil a slightly different role Šthan that which the expert fulfills at the moment. But the KE should Šhave a respect for well-established conventions. Attitude to ES technology This is the subject of the next slide. THE GRAIN OF WHEAT This illustrates, in parable form, two types of attitudes we Šcantake to ESs. All will be explained during the lecture. THE KNOWLEDGE ACQUISITION STAGES So far we have been discussing aspects that should be Šconsideredthroughout the whole of an ES project, but especially during Šthe first,Start, stage. We now turn our attention to knowledge Šacquisition, whichwill form the bulk of activity during the next few Šstages, when we buildthe demonstration, working and usable systems. During these stages there is a continuous cycle of events, Šeachcycle having components of analyse, design, implement, test or, as Šwe sayin the ES community, knowledge elicitation, knowledge Šrepresentation,validation. Validation has been dealt with in Part A. The important thing Šisthat it be seen as part of Evaluation, not just seeing whether the Šsystemconforms to specification. Q: "Does it conform to spec?" A: Š"Whatspec?" STAGES IN ELICITATION But not all cycles are the same. While all have a measure Šofknowledge elicitation, design activities feature more in early Šcycles,while test activities feature more in later cycles. There tend to be three knowledge acquisition activities, eachwith Šits own slightly different type of cycle. During the initialstages, Šacquisition concentrates on global or macro issues, and onoverall Šdesign. This stage is called Domain conceptualisation. Afterthis has Šbeen done, acquisition concentrates more on the details of Štheknowledge. Then usually, at some stage, there will be a re)hash of Štheoverall framework, to a greater or lesser extent, as it becomes Šclearwith a better grasp of the knowledge, that the original framework Šis notentirely appropriate. DOMAIN CONCEPTUALISATION Domain conceptualisation has to do with finding the Šoverallstructure and strategies of the domain. The term was coined in Šthe KEATSproject. It covers such things as those shown on the slide Š(which willbe explained during the lecture). KEATS ) KNOWLEDGE ENGINEERS' ASSISTANT The KEATS system (Open University) is one research project Šamongmany that is seeking to give computer)based help to the process Šofknowledge acquisition. It runs on a Symbolics machine, on top ŠofZetalisp. The slides will be explained during the lecture. KEATS makes Šanassumption about the stages involved in knowledge acquisition, and Šinparticular, that we start with a transcript of a conversation with Šanexpert, analyse this, determine the domain conceptualisation, and Šthenimplement it. It is interesting that the KEATS team are now bringing CREF ŠandGIS together, since they see the two activities of data analysis Šanddomain conceptualisation as being performed in parallel, not in Šsequence. The assumption seems to be that the conversation with the Šexpertwill be performed separately from any analysis. This is not Šalways true. Also, the KEATS system gives little support to those Šprocessesthat take place during the first, Start, stage. (Note that Šthe KEATSteam do not recognise the seven stages explicitly.) WHY I LIKE PAPER Here is a personal reaction to KEATS and other such systems. ŠI,Ned Ludd, prefer to use good old paper and pencil. I find that Šmyknowledge elicitation process is not structured in the way assumed Šby theKEATS system. (Though it is interesting that some of the Šbarriers arenow being broken down within KEATS.) Paper is much more versatile. It can allow the stages to bemixed Šas necessary. It allows analysis and conceptualisation to becarried Šout with the expert, rather than distant from him/her. So theexpert Šis involved in the process of building the ES, and not just Šinsupplying knowledge. This helps to increase their co)operativeness. I tend to make a lot of use of Inference Net Diagrams, both ŠforDomain Conceptualisation and for the detailed knowledge. I find Šthatmost experts and other lay people understand them easily. (With Štheexception of a few who have been heavily into Flow)charts and ŠDecisionTrees.) I draw them on the fly, and this act of drawing, with Šitsanimation, conveys useful information between us. I find paper is cheap, convenient, portable, and gives apermanent Šrecord. Moreover, I find that I can remember roughly where apiece of Šknowledge is (somewhere on the top)right of a page, in theconversation Šwith Expert No. 2). Also, it allows me to combinedocumentation that Šthe expert gives me into my folder of knowledge. These expensive systems that are on offer only support Štheprocesses of knowledge elicitation. They do not, as a rule, Šsupport theprocesses of deciding about roles, benefits, purposes, etc. ŠThey do nothelp us to decide whether we should be building an ES in Šthe first place. And it is these that are the more important issues. ŠSo, these expensivesystems, though interesting, are not for me. They Šsmack to me of asolution looking for a problem, and of a desire to Šgain researchreputations, rather than provide real benefits. INFERENCE NET DIAGRAMS Inference Net Diagrams (INDs) are composed of boxes and arrows. ŠEach box represents a concept that is meaningful to the expert and Šthearrows show, for any given concept, which other concepts are needed Šinorder to establish it. There are two uses of INDs, for top)level, and for Šdetailed,analysis and documentation. In top)level INDs, the boxes Šrepresentclasses of individual concepts, and the arrows show the Šmajorinterrelationships among the classes. Thus, for instance, the Šqualityfactors are determined by Client Needs, but not be Site and ŠLocation. This slide shows the top)level IND for the Budget Module of ŠtheRICS/Alvey ES. INFERENCE NET DIAGRAMS During the lecture a detailed IND will be shown for part of ŠtheRICS/Alvey Budget Module. Notice that this is not simply an Šexpansion ofthe top)level IND, since it contains instances of several Šof the top*level classes. MODEL OF EXPERTISE We now turn to one important topic of knowledge elicitation, Šwhich is often neglected, that of the types of knowledge that form an Šexpert's expertise. Often KEs simply seek the expert's heuristics, as Šan expression of his/her 'real' expertise. But there is more to Šexpertise than heuristics. While a skilled practitioner in the domain may have experience, Šand the raw graduate may have understanding, the expert has both. Šhis/her understanding (U) is enriched by experience (E) and his/her Šexperience is informed by understanding. It is experience that allow Šsefficient problem)solving in the domain, while it is understanding Šthat allows him/her to tackle different problems in different Šcontexts. The diagram shows a relationship between U and E. U comes from a Šprocess of theory formation (TF), with E as its input, while E comes Šfrom a process of context)dependent problem solving (CPS), which has U Šas its input. These terms are explained in the following slides. It is important to bear in mind that this is a model, not of the Šexpertise of only a single expert, but of a community of experts. ŠThus, for instance, some of the U may have been discovered by TF Šcarried out by other workers, and this may even have been done a Šcentury ago. Our aim,in building an ES for a given purpose, should be Što acquire the whole community's expertise rather than just that of a Šsingle expert. However, each individual expert will have elements of U, E, CPS Šand TF. And the KE will usually be interacting with one expert at a Štime. What we have to do is elicit these elements from individuals, Šand then bring them together. After describing the four elements in Šmore detail, we will look at a simple method for doing this. Disclaimer: This model only handles knowledge that can Š(potentially) be expressed in some verbal form. It therefore does not Šcover sensory knowledge. But no attempt should normally be made to Šinclude such knowledge in an ES anyway. PROBLEMS WITH HEURISTICS There are a number of problems with an ES that is built from Šheuristics ) and traditionally, most ES have been so built. Indeed, Šthese problems have been so severe that knowledge elicitation has Šbecome known as the 'Feigenbaum bottleneck', after the person who Šfirst coined the concept. But, this does not always need to be the Šcase. As we shall see, if we build an ES out of U the bottleneck all Šbut disappears. Disagreement among experts This was mentioned in Part A. Fragility The ES falls over when used in a different context, as Šdiscussed above. This is due to incompleteness of the KB, especially Šin the realm of contextual knowledge. Poor explanations The much vaunted 'explanation facilities' of Šmany ESs turn out to be a meaningless list of rules that have fired. ŠWhat the user really wants is something more meaningful, and often Šbased on an understanding (Note the term used) of the causality in the Šdomain. Poor understandability of KB The KB may well be readable, in the Šsense that the lay person can read the rules and understand what each Šrule does, but s/he cannot usually understand it in terms that relate Što his/her business needs. EXPERIENCE E (Experience) is largely of two kinds, heuristics and observed Šfacts. (Cf. the 'Facts and Rules' which are seen by many to be the Šconstituents of knowledge.) Heuristics (or rules of thumb) are statements that are generally Štrue, but which usually have exceptions. They are of at least two Škinds: IF .. THEN .. rules, and^T^ Approximate statements of value.^T^ An example of each is given on the slide. Observed facts are individual facts that are remembered, such as Šthe costs of individual cars. Often heuristics are derived directly Šfrom observed facts. (This is mirrored in AI by the process of Šmachine induction.) There are two important things about Experience, and heuristics Šin particular. First, it is subjective. That is, the E element Šdepends on the individual expert (or perhaps a closely)knit group of Šexperts) and on the context. If the context changes, for instance, Šthen the E element may no longer be valid; this is discussed below. ŠThis is because E is formed from CPS. This means that ESs that are built out of heuristics are likely Što be fragile. And there is likely to be problems with disagreements Šamong experts when the knowledge elicitation takes place. Second, as mentioned above, it is efficient knowledge. It has Šthe CPS 'compiled' into it, and so can be applied directly, as long as Šthe context is appropriate. UNDERSTANDING U (Understanding), on the other hand, is objective. That is, U Šis that element of expertise that is generally agreed to be true Šacross the community of experts and across all contexts. (Note that we only talk in relative terms. When we say 'all Šcontexts', we mean 'all contexts that the ES is likely to be used in', Šrather than all possible contexts, including use on Mars.) This means that if U is included in an ES then it is less likely Što be fragile (because it will apply across all contexts in which it Šis likely to be used), and there will be less problem with Šdisagreement among experts (since they will usually agree about the Šbasic U). So, to say that the cost of a car is aa4000 is highly context- Šdependent, while to say that the cost of a car is the sum of the Šfactors shown on the slide is less so. But the U element is less immediately useful than the E element. ŠTo make use of the car cost function, for instance, we need three Špieces of contextual information (and in real life, we will need Šmore), and then we must perform some calculation or deduction, which Štakes time. So E tends to be used by experts in normal problem Šsolving, but they have U available for use in novel contexts. Also U is used when explanations are being sought. It is usually Šthe answer to the question 'Why?'. (As shown below, this is a pointer Što how we can elicit U.) But it means that ESs built using with U Šrather than E can often give better quality explanations, and be more Šunderstandable. A very common form of U is causality. But there are other forms, Šsuch as structure and, as our car cost example shows, simple Šarithmetic. DEEP KNOWLEDGE There is currently much interest in what has become known as Š'Deep Knowledge', which has arisen out of a disillusionment with the Šfailures of heuristic-based ESs. It is very much a vogue topic. What is called 'Deep knowledge' is part of U. How much of U is Šcovered depends on whom you speak to. The area seems to be being Štaken over by those with an interest in the fields of Naive Physics, ŠQualitative Physics and Economics, probably best summed up by the Šphrase, Qualitative Modelling. But U goes beyond these. Qualitative Modelling is rather like conventional causal Šmodelling (in setting up a representation of concepts and variables Šand the relationships among them) but it avoids using the precise Šmathematical algorithms. It deals with true/false concepts (perhaps Šprobabilistic) and approximate quantities, and the relationships are Šof the form, 'causes an increase in' or 'makes more likely'. Its sub- Šbranch, Naive Physics, claims to model how the man-in-the-street Šreasons about physics, such as 'If I push this, then it will move, and Šit will cause that to move, etc.' It started when Pat Hayes published Ša paper,'The Naive Physics Manifesto' (Machine Intelligence, Vol ?< Šapprox 1980.) We will not cover it in this course, but merely make reference to Šwhat is a very interesting topic, in case you come across it at some Šstage. CONTEXT DEPENDENT PROBLEM SOLVING CPS (Context dependent Problem Solving) is the process whereby U Šis transformed into E. There are three main aspects of CPS, as shown on the slide. It Šinvolves a knowledge about the context in which the problem solving is Štaking place. Ask a person in Manchester about car costs, and they Šmay well say aa4000. Ask a price)setter in the car factory, and they Šmay well give something like the algorithmic version. It involves a problem solving strategy. To find car costs most Špeople would ring up Car Sales or look in a catalogue. But there are Šalternative methods, such as working out the cost, or asking people Šwhat they actually paid for their cars. Lastly, CPS involves knowing who the problem solver is. aa4000 Šmay be the cost of a car to most people, but ask a company director Š'What is the rough cost of cars these days?' and s/he may say aa10,000 Š(or whatever it is!). All these factors will affect the heuristics that are produced Šand which are used for problem solving. The problem about CPS is that much of it is in the form of Šassumptions. And assumptions are notoriously difficult to elicit from Šthe expert. So, when an expert is asked for an heuristic about the Šcost of cars, s/he may well say "aa4000" But in practice, s/he will Šprobably take a look at who is asking the question and say "10,000" in Šcertain circumstances. When asked for an heuristic, most of the Šassumptions (eg. that you should give a different answer to company Šdirectors) are forgotten. The method described below helps to winkle Šout these assumptions. (This process may not actually happen in the mind of the Šindividual expert we are talking to, but perhaps in the mind of Šothers. Indeed, it may not actually have happened at all. In the case Šof heuristics that are directly induced from observed facts, this does Šnot happen explicitly. But one can say that the observed facts have Šcome about by some process that could be understood, and in some Šcontext that could be expressed; so we can say that such heuristics Šcontain latent CPS and U.) THEORY FORMATION TF (theory formation) is the process by which U is derived from ŠE. The best-known form is the scientific method, but in everyday Šlife, people use less formal methods. TF is usually not included in the KBs of ESs. Indeed, it is an Šarea where research has so far yielded little fruit; the new area of ŠExplanation Based Learning is concerned with following the TF arrow. Since much TF is from scientific method, we emphasise here that Šthe model is of corporate, not individual, expertise. METHODOLOGY FOR BUILDING EXPERT SYSTEMS We now take a brief look at a methodology for building ESs or at Šleast the knowledge elicitation process. In short, we start by finding heuristics (either by asking the Šexpert, by machine induction or by repertory grids; these and other Štechniques have been covered in Part A). This is E. While many KEs Šstop there, we go further, and seek to determine the U that lies Šbehind it, and make the CPS explicit. The problem is that it sometimes happens that the U and CPS is Šjust not available. That is, the E is such as to have been derived Šsimply from associations among observed facts by the 'experts', and Šthere is no available expert who can give a true picture of the U. ŠBut such cases are not so common as at first might appear. Often the Šexpert may claim at first that s/he does not know the U, but with a Šbit of probing may be able to remember the U. (The problem of false U should always be borne in mind. How do Šwe know when the expert's explanation is correct? This is less a Šproblem than it might seem, since all that is necessary is that the Šshape of the U rather than the precise terminology is correct.) THREE QUESTIONS The basic methodology consists of three questions. With these, Šwe can obtain much of the U and CPS behind the E. They are: Why? What else? When Not? The next sequence of slides shows this in operation. LEVEL OF DETAIL ) 1 We will start from the heuristic that regular mowing gives a good Šlawn. We first ask 'Why?' (that is, 'Why does regular mowing lead to Ša good lawn?' (Remember the statement above that U can be seen as anything that Šis the answer to the question, 'Why?') LEVEL OF DETAIL ) 2 The answer (no claims to correct knowledge here) is that regular Šmowing keeps the coarser grasses down and it helps make turf more Šspringy. Note that the concepts of 'springy turf' and 'fewer coarse Šgrasses' are simply two different definitions of what 'good lawn' Šmeans; So some U is definitional, rather than causal. We have gone down one level of detail. We now ask 'Why?' again Šfor one of the links, to go down another level. LEVEL OF DETAIL ) 3 This shows an elongation of the link into a chain of concepts. ŠHere we have elicited some causal U. We can ask 'Why?' again. LEVEL OF DETAIL ) 4 The understanding behind the why cutting the leaves promotes Šbranching involves biochemistry etc. We could continue asking 'Why?' for each link, going down a level Šof detail every time, until we end, presumably, with the sub-nuclear Šphysics. But that would not be very helpful to the user of the ES in Šsolving grass-cutting problems. So to which level of detail should we Šgo? There is no foolproof rule about this, but a good guide is to go Šone level deeper than most users' knowledge. In this case, it might Šbe to the level of cutting leaves promotes branching. The ES can give Šexplanations at whatever level we go to, and this level of explanation Šwould presumably be useful to, and understood by, the users. FINDING CPS - 1 We can now try to make CPS more explicit. We will concentrate on Šcontextual assumptions here. To do this, we can ask 'What else?' for Šone of the concepts. We are seeking to find what other arrows lead Šinto this box or leave from this box. So we could ask, 'What else Šmight cut leaves?', to find other antecedents, and 'What else results Šfrom cutting the leaves?', to find other consequents. Before turning the page, try to think of what else might cut the Šleaves. FINDING CPS - 2 One answer is sheep grazing. So we could include this in our KB. But we have to ask ourselves whether it should be included. Is Šthe ES likely to be used in contexts in which sheep grazing may be a Špossibility? If not, then we do not need to include. But, what we Šhave done is to make the CPS explicit here, and then make a decision Što reject - which is very much better than not considering it at all. Note that to make such decisions we have to know the purpose, Šroles and users of the ES. Indeed, the act of making such decisions Šmay help to clarify such issues. Note how relatively easy it was to make explicit the assumption Šthat we are not dealing with sheep)grazing situations, by this method. ŠIt is because this method helps the expert concentrate on one relevant Šissue at a time, in such as way as to make the most use of his/her Špsychological hooks. Note also that the KE's common sense can often prove helpful Šhere. The expert may not think of the possibility of sheep grazing, Šbut the KE might. LIMITS OF THE METHODOLOGY The methodology has been found to work in a number of ES Šprojects. But it has limitations. These are shown on the slide, and Šhave been discussed above. Ś MAXIM To end this series of lectures, we offer a well)known, but very Šrelevant maxim.