TMS acts as substrate to inference engine
advertisement
Putting the JTMS to Work Outline • Interface between a JTMS and a rule engine • Chronological Search versus Dependency Directed Search: A Playoff • Using a TMS in a problem solver: JSAINT design issues TMS acts as substrate to inference engine Problem Solver Rules and assertions Inferred assertions Inference Engine TMS The dependency-network of the TMS provides a substrate for the inference engine, making it more efficient. Let’s take a closer look... Inference Engine services • Provides reference mechanism – e.g., assertions, pattern matching • Provides procedures – e.g., rules • Provides control strategy TMS services • Provides cache for inferences – Nodes for assertions, justifications for relationships between beliefs • Maintains consistent set of beliefs – Derives consequences of assumptions & premises based on dependency network – When assumptions are retracted, their consequences are retracted • Provides explanations for belief – e.g., chains of well-founded support • Detects contradictory beliefs – Based on contradiction nodes, explicit dependencies Each engine datum is mapped to a particular TMS node referent Datum datum-tms-node datum-lisp-form (HUMAN ROBBIE) tms-node-datum get-tms-node TMS Node view-node Storing facts in the JTRE requires more bookkeeping • To store a fact in the JTRE – Index it under DBClass (just like FTRE) – Also: Find or create link between lisp form of assertion and TMS node • Datum class struct – Lisp form – Link to TMS node – Backpointer to DBClass FTRE -> JTRE • FTRE’s assert! – Place facts directly in the database of facts (local or global) • JTRE’s assert! – Place facts in database, and set up appropriate node in TMS – Mark as assumption if needed. • In fact, assert! becomes family of related functions Justifying assertions in terms of other beliefs • (assert! <fact> (<informant> . <antecedents>)) installs a justification • (assert! <fact> <Anything else>) makes a premise • (assume! <fact> <reason>) makes an assumption • rassume!, rassert! as before • retract! disables an assumption • (contradiction <fact>) installs a contradiction Create datum & tms node JTRE assert! (defun assert! (fact just &optional (*JTRE* *JTRE*) &aux datum node) "Assert fact into the JTRE." (setq datum (referent fact t) ;; Create datum if needed, node (datum-tms-node datum));; with corresponding node. (unless (listp just) (setq just (list just))) (debugging-jtre "~% Asserting ~A via ~A." fact just) (justify-node (car just) node (mapcar #'(lambda (f) (datum-tms-node (referent f t))) (cdr just))) datum) Handle bookkeeping of dependencies, based on justification Justification structure • • • • ID, a unique number Informant, a symbol description Consequent, node it supports Antecedents, nodes that support it. TMS Node TMS Node TMS Node TMS Node Justify-node • Build a justification object linking the given antecedent nodes to the consequent node. • Check justification links – If consequent now IN, label IN – Propagate IN-ness Queries concerning Belief States • in? • out? • why? • assumptions-of • fetch • wfs Tying rule execution to belief states • (rule <list of triggers> <body>) • Triggers are (<condition> <pattern>) • Types of conditions – :IN – :OUT – :INTERN • Trigger options – :VAR – :TEST Examples of rules (rule ((:in (implies ?p ?q) :var ?f1) (:in ?p)) (rassert! ?q (CE ?f1 ?p))) (rule ((:in (show ?p) :var ?f1) :test (not (logical-connective? ?p))) (rassert! ((show ?p) Indirect-Proof :PRIORITY Low) (BC-IP ?f1))) When do rules fire? • Normally, when triggers match, body is queued and executed • What if trigger becomes OUT after body is queued? • Solution: local execution queues on each TMS node Node structure (defstruct (tms-node (:PRINT-FUNCTION print-tms-node)) (index 0) ;; Unique identifier for node. (datum nil) ;; Pointer to fact node represents (label :OUT) ;; :IN=believed, :OUT=disbelieved (support nil) ;; Current justification (justs nil) ;; Possible justifications (consequences nil) ;; Justifications it supports. (contradictory? nil) ;; Flag marking it as contradictory (assumption? nil) ;; Flag marking it as an assumption. (in-rules nil) ;; Rules triggered when node goes in (out-rules nil) ;; Rules triggered when node goes out (jtms nil)) ;; The JTMS in which node appears. • When node becomes :IN or :OUT, items on local queue are eval’ed Handling Contradictions • (with-contradiction-handler <jtms> <handler> . <body>) • We’ll see example with N-queens problem Search Example: The N-Queens problem Good solution Bad solution Chronological Search solution • Given NxN board – Create a choice set for placing a queen in each column – Unleash rules that detect captures – Systematically search all combinations of choices Dependency Directed Search Solution • Like chronological search solution, but – When inconsistent combination found, assert negation of queen statement. (Creating a nogood) – When searching, check for a nogood before trying an assumption. Dependency-driven search • Requirements – Choice sets, as before – Use dependency network to create nogoods, which should allow us to detect bad choices faster • How about dependency-driven backtracking? – Not yet, but soon... Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? Choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) Basic algorithm Record the solution (defun dds (choice-sets) when choice sets (cond ((null choice-sets) exhausted. (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) Basic algorithm (defun dds (choice-sets) Iterate through (cond ((null choice-sets) choices in the (record-solution)) choice set (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) the Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) If nogood is (record-nogood choice))))))) retrieved first, don’t attempt... Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) Otherwise, try assuming each choice and calling dds recursively to get rest. Inconsistent entries saved as nogood. Real version of ddsearch more complex • Creates specialized contradiction handler for each assumption which stores the value of that assumption – Probably slows down the system • Still, faster than FTRE for large problems Chronological Search: Time required • IBM RT, Model 125, 16MB RAM, Lucid CL 100 90 80 70 60 50 40 30 20 10 0 4 5 6 7 8 Chronological Search: Assumptions Explored 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 4 5 6 7 8 Dependency Directed Search: Time used 180 160 140 120 100 80 60 40 20 0 4 5 6 7 8 Dependency-Directed Search: Assumptions Explored 3000 2500 2000 1500 1000 500 0 4 5 6 7 8 Comparing the results Time in seconds 180 160 140 120 100 80 60 40 20 0 Chrono DDS 4 5 6 7 8 Comparing the results Assumptions Explored 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 Chrono DDS 4 5 6 7 8 Implications • Neither strategy changes the exponential nature of the problem • Dependency-directed search requires extra overhead per state explored • The overhead of dependency-directed search pays off on large problems when the cost of exploring a set of assumptions is high Justification-based Truth Maintenance Systems Building JSAINT JSAINT: Its task • Input: An indefinite integration problem • Output: An expression representing the answer 4xe x2 3.2 sin( 1.7 x) 0.63 dx JSAINT returns x2 2e 1.88cos(1.7x) 0.63x How SAINT Worked 1. Is problem a standard form? If so, substitute & return answer 2. Find potentially applicable transformations. For each transformation, create the subproblem of solving the transformed problem. • SAINT used 26 standard forms, 18 transformations • Also used many special-purpose procedures Knowledge about Integration • Standard forms 1 2 vdv v 2 Transformations cg(v)dv c g(v)dv Integration Operators • Provide direct solutions to simple problems (analogously to SAINT’s standard forms ) • Suggests ways of decomposing problems into simpler problems Representations • Mathematics is the easy part (x 5)dx is represented as (integral (+ x 5) x) Issues in JSAINT design • • • • Explicit representation of control knowledge Suggestions Architecture Special-purpose higher-level languages Explanation generation Issue 1: Explicit representation of control knowledge • The use of show assertions in KM* is only the beginning! • Recording control decisions as assertions enables – – – – Control knowledge to be expressed via rules keeping track of what is still interesting via the TMS Explaining control decisions Provides grist for debugging and learning • Key part of JSAINT design is a control vocabulary The natural history of a problem New problem P P expanded (expanded P) (open P) (relevant P) Parent no longer open P failed (expanded P) (open P) (relevant P) (failed P) P solved (expanded P) (open P) (relevant P) (expanded P) (open P) (relevant P) (solved P) (solution-of P solution) Representing Goals • JSAINT uses the form of the goal itself (integrate (integral (+ x 5) x)) • Advantage: Easy to recognize recurring subproblems – Actually an AND/OR graph rather than an AND/OR tree • Alternative: Reify goals (goal GOAL86) (GOAL86 form-of (try (risch-algorithm (integrate (integral foo))))) Success or failure of problems (solved <P>) is believed exactly when problem P has been solved (failed <P>)is believed exactly when P cannot be solved by JSAINT given what it knows. (solution-of <P> <A>)holds exactly when A is the result of solving problem P Representing progress (expanded P)is believed exactly when work has begun on P (open P) is believed exactly when P has been expanded but is not yet solved or known to be unsolvable. (relevant P) is believed exactly when P is still potentially relevant to solving the original problem. Issue 2: Control via suggestions • Problem: Local methods cannot detect loops, combinatorial explosions • Solution: Decompose problem-solving operations into two kinds: – Local operations for “obvious” tasks, making relevant suggestions – Global operations for choosing what to do • Suggestions Architecture is a very useful way to organize problem solvers Homework 4 • Chapter 8 (page 258): Problem 1. (a) Problem 4 • Submit as :ASN 4 • Due: Feb. 1, 2001 before class
