Knowledge acquisition

This is the chief difficulty in developing expert systems. It's difficult and time consuming.

Some issues:

• They use heurisitcs (rules of thumb) ordinarily not included in other sources.
• Exercise: Identify some that apply to decisions you are involved with.

• Memory for facts is very fallible.
• It's worse for procedures
• We don't work from "first principles" (like physics equations) even if they apply
• Knowledge gets "complied," meaning that lots of knowledge is reduced to simple rules in ways that are hard to explain

• Remeber: it's a phase in a cycle:
• Identitify a good problem (3 P's)
• Pick the "right" expert (if you have serveral candidates)
• Loop until satisfied
• acquire knowledge (pick expert's brain)
• encode (as rules, objects)
• test
• Tape record and transcribe, if possible
• Always: paraphrase, reflect back when you THINK you hear
• Start general, work toward details
• General discussions about domain
• Goal rules
• Segment large problem into separate "goal activities"
• Unstructured interviews are appropriate here
• Read pamphlets, articles, too.
• Later, strive to be more specific
• More focused discussions (you identify issues to explore at outset)
• Non-goal rules elicited
• More specific objects included, if needed
• Structured interviews appropriate
• Use "cases" to test your system/observe your expert at work
• Cases from memory are worst (memory is fallible) but can be useful
• Cases described in written notes are better
• esp useful in intermediate stages of development
• cover: retrospective, familiar, common situations
• "Live" cases are best for late stages of development
• cover: observational, new, uncommon situations
• if you can interrupt expert during live case, you'll learn a lot
• useful when your system is fairly well developed (as a test or to extend your ES)
• Carefully understand your expert's vocabulary
• oject-attribute-value "score cards"