ARTIFICIAL INTELLIGENCE

Dr. Anand M
Assistant Professor
Department of Data Science and Business Systems
SRM Institute of Science and Technology
Planning
• We studied how to take actions in the world (search)
• We studied how to represent objects, relations, etc. (logic)
• Now we will combine the two!
Planning vs. scheduling

• Planning: given one or more goals, generate a sequence of actions to achieve

the goal(s)
• Scheduling: given a set of actions and constraints, allocate resources and assign
times to the actions so that no constraints are violated
• Traditionally, planning is done with specialized logical reasoning methods
• Traditionally, scheduling is done with constraint satisfaction, linear
programming, or OR methods
• However, planning and scheduling are closely interrelated and can’t always be
separated
State of the world (STRIPS language)
• State of the world = conjunction of positive, ground, function-free literals
• At(Home) AND IsAt(Umbrella, Home) AND CanBeCarried(Umbrella) AND
IsUmbrella(Umbrella) AND HandEmpty AND Dry
• Not OK as part of the state:
• NOT(At(Home)) (negative)
• At(x) (not ground)
• At(Bedroom(Home)) (uses the function Bedroom)
• Any literal not mentioned is assumed false
• Other languages make different assumptions, e.g., negative literals part of state,
unmentioned literals unknown
An action: TakeObject
• TakeObject(location, x)
• Preconditions:
• HandEmpty
• CanBeCarried(x)
• At(location)
• IsAt(x, location)

• Effects (“NOT something” means that that something should be

removed from state):
• Holding(x)
• NOT(HandEmpty)
• NOT(IsAt(x, location))
Another action
• WalkWithUmbrella(location1, location2, umbr)
• Preconditions:
• At(location1)
• Holding(umbr)
• IsUmbrella(umbr)
• Effects:
• At(location2)
• NOT(At(location1))
Yet another action
• WalkWithoutUmbrella(location1, location2)
• Preconditions:
• At(location1)
• Effects:
• At(location2)
• NOT(At(location1))
• NOT(Dry)
A goal and a plan
• Goal: At(Work) AND Dry
• Recall initial state:
• At(Home) AND IsAt(Umbrella, Home) AND CanBeCarried(Umbrella) AND
IsUmbrella(Umbrella) AND HandEmpty AND Dry
• TakeObject(Home, Umbrella)
• At(Home) AND CanBeCarried(Umbrella) AND IsUmbrella(Umbrella) AND Dry AND
Holding(Umbrella)
• WalkWithUmbrella(Home, Work, Umbrella)
• At(Work) AND CanBeCarried(Umbrella) AND IsUmbrella(Umbrella) AND Dry AND
Holding(Umbrella)
Planning to write a paper
• Suppose your goal is to be a co-author on an AI paper with both theorems and
experiments, within a year
ProveTheorems(x)
LearnAbout(x,y)
Preconditions: Knows(x,AI), Knows(x,Math),
Preconditions: HasTimeForStudy(x) Idea
Effects: Knows(x,y), NOT(HasTimeForStudy(x)) Effect: Theorems, Contributed(x)

PerformExperiments(x)
HaveNewIdea(x)
Preconditions: Knows(x,AI), Knows(x,Coding), Idea
Preconditions: Knows(x,AI), Creative(x)
Effect: Experiments, Contributed(x)
Effects: Idea, Contributed(x)

FindExistingOpenProblem(x)
Preconditions: Knows(x,AI)
Effects: Idea
WritePaper(x)
Preconditions: Knows(x,AI), Knows(x,Writing),
Idea, Theorems, Experiments
Effect: Paper, Contributed(x)

Name a few things that are

Goal: Paper AND Contributed(You)
missing/unrealistic…
Some start states
Start1: HasTimeForStudy(You) AND Knows(You,Math) AND Knows(You,Coding) AND Knows(You,Writing)

Start2: HasTimeForStudy(You) AND Creative(You) AND Knows(Advisor,AI) AND Knows(Advisor,Math) AND

Knows(Advisor,Coding) AND Knows(Advisor,Writing)
(Good luck with that plan…)

Start3: Knows(You,AI) AND Knows(You,Coding) AND Knows(OfficeMate,Math) AND HasTimeForStudy(OfficeMate) AND

Knows(Advisor,AI) AND Knows(Advisor,Writing)

Start4: HasTimeForStudy(You) AND Knows(Advisor,AI) AND Knows(Advisor,Math) AND Knows(Advisor,Coding) AND

Knows(Advisor,Writing)

We’ll use these as examples…

 Forward state-space search (progression planning)
• Successors: all states that can be reached with an action whose preconditions are
satisfied in current state
At(Home) WalkWithUmbrella(Home, At(Work)
Holding(Umbrella)
Work, Umbrella) Holding(Umbrella)
TakeObject(Home, Umbrella)
CanBeCarried(Umbrella) CanBeCarried(Umbrella)
IsUmbrella(Umbrella) WalkWithoutUmbrella IsUmbrella(Umbrella)
At(Home) (Home, Work)
Dry Dry
IsAt(Umbrella, Home)
GOAL!
CanBeCarried(Umbrella)
IsUmbrella(Umbrella) At(Work) WalkWithoutUmbr
HandEmpty IsAt(Umbrella, Home) ella(Work, Home) At(Home)

Dry CanBeCarried(Umbrella) IsAt(Umbrella, Home)

IsUmbrella(Umbrella) CanBeCarried(Umbrella)
WalkWithoutUmbrella
(Home, Work) HandEmpty IsUmbrella(Umbrella)
HandEmpty

WalkWithoutUmbrella(Home,
Umbrella) (!)
 Backward state-space search (regression planning)
• Predecessors: for every action that accomplishes one of the literals (and does not
undo another literal), remove that literal and add all the preconditions

WalkWithUmbrella(locatio
TakeObject(location2, umbr)
n1, Work, umbr)
At(location1) At(location1)
At(location2) Holding(umbr) At(Work)
IsAt(umbr, location2) IsUmbrella(umbr) Dry
CanBeCarried(umbr) Dry
GOAL
IsUmbrella(umbr)
HandEmpty
WalkWithUmbrella(location2, location1)
Dry

This is accomplished in the start state,

by substituting
location1=location2=Home, WalkWithoutUmbrella can never be used, because it undoes Dry
umbr=Umbrella
(this is good)
Heuristic to Speed up Search
• We can use A*, but we need an admissible heuristic
1. Divide-and-conquer: sub-goal independence assumption
• Problem relaxation by removing
2. … all preconditions
3. … all preconditions and negative effects
4. … negative effects only: Empty-Delete-List
1. Subgoal Independence Assumption

• The cost of solving a conjunction of subgoals is the sum of the costs of solving
each subgoal independently
• Optimistic
• Where subplans interact negatively
• Example: one action in a subplan delete goal achieved by an action in another subplan
• Pessimistic (not admissible)
• Redundant actions in subplans can be replaced by a single action in merged plan
2. Problem Relaxation: Removing Preconditions

• Remove preconditions from action descriptions

• All actions are applicable
• Every literal in the goal is achievable in one step
• Number of steps to achieve the conjunction of literals in the goal is
equal to the number of unsatisfied literals
• Alert
• Some actions may achieve several literals
• Some action may remove the effect of another action
3. Remove Preconditions & Negative Effects

• Considers only positive interactions among actions to achieve

multiple subgoals
• The minimum number of actions required is the sum of the union of
the actions’ positive effects that satisfy the goal
• The problem is reduced to a set cover problem, which is NP-hard
• Approximation by a greedy algorithm cannot guarantee an admissible
heuristic
4. Removing Negative Effects (Only)

• Remove all negative effects of actions (no action may destroy the
effects of another)
• Known as the Empty-Delete-List heuristic
• Requires running a simple planning algorithm
• Quick & effective
• Usable in progression or regression planning
Blocks world
B D
A C

• On(B, A), On(A, Table), On(D, C), On(C, Table), Clear(B), Clear(D)
Blocks world: Move action
B D
A C

• Move(x,y,z)
• Preconditions:
• On(x,y), Clear(x), Clear(z)
• Effects:
• On(x,z), Clear(y), NOT(On(x,y)), NOT(Clear(z))
Blocks world: MoveToTable action
B D
A C

• MoveToTable(x,y)
• Preconditions:
• On(x,y), Clear(x)
• Effects:
• On(x,Table), Clear(y), NOT(On(x,y))
Partial Order Planning (POP)
• State-space search
• Yields totally ordered plans (linear plans)
• POP
• Works on subproblems independently, then combines subplans
• Example
• Goal(RightShoeOn  LeftShoeOn)
• Init()
• Action(RightShoe, PRECOND: RightSockOn, EFFECT: RightShoeOn)
• Action(RightSock, EFFECT: RightSockOn)
• Action(LeftShoe, PRECOND: LeftSockOn, EFFECT: LeftShoeOn)
• Action(LeftSock, EFFECT: LeftSockOn)

21
POP Example & its linearization

22
 Components of a Plan
1. A set of actions
2. A set of ordering constraints
• A p B reads “A before B” but not necessarily immediately before B
• Alert: caution to cycles A p B and B p A
3. A set of causal links (protection intervals) between actions
• A B preads “A achieves p for B” and p must remain true from the time A is applied to the time B is
applied
• Example “RightSock RightShoe
RightSockOn

4. A set of open preconditions

• Planners work to reduce the set of open preconditions to the empty set w/o introducing contradictions

23
Consistent Plan (POP)
• Consistent plan is a plan that has
• No cycle in the ordering constraints
• No conflicts with the causal links
• Solution p
• Is a consistent plan with no open preconditions
• To solve a conflict between a causal link A B and an action C (that clobbers,
threatens the causal link), we force C to occur outside the “protection interval”
by adding
• the constraint C p A (demoting C) or
• the constraint B p C (promoting C)

24
Setting up the PoP Start
Literala, Literalb, …

• Add dummy states

Literal1, Literal2, …
• Start
• Has no preconditions Finish
• Its effects are the literals of the initial state
• Finish
• Its preconditions are the literals of the goal state
• Has no effects Start
• Initial Plan:
LeftShoeOn, RightShoeOn
• Actions: {Start, Finish}
Finish
• Ordering constraints: {Start p Finish}
• Causal links: {}
• Open Preconditions: {LeftShoeOn,RightShoeOn}

25
POP as a Search Problem
• The successor function arbitrarily picks one open precondition p on an action B
• For every possible consistent action A that achieves p p
• It generates a successor plan adding the causal link A B and the ordering constraint A p
B
• If A was not in the plan, it adds Start p A and A p Finish
• It resolves all conflicts between
• the new causal link and all existing actions
• between A and all existing causal links
• Then it adds the successor states for combination of resolved conflicts
• It repeats until no open precondition exists

26
Planning graphs
On(C, A) On(C, A)
• Each level has literals that “could be
Move(C,A,B)
true” at that level
On(A, Table) On(A, Table)
• Mutex (mutual exclusion) relations
Clear(C) indicate incompatible actions/literals
Clear(C)
MoveToTable(C,A)

On(B, Table) On(B, Table)

Clear(B) Clear(B)
Move(B,Table,C) Clear(A) … continued on board

On(C, B)

On(C, Table)

On(B, C)
 Reasons for mutex relations…
• … between actions:
• Inconsistent effects: one action negates effect of the other
• Interference: effect of one action negates precondition of the other
• Competing needs: the actions have preconditions that are mutex
• … between literals:
• Inconsistent support: any pair of actions that can achieve these literals is
mutex
 A problematic case for planning graphs
• FeedWith(x, y)
• Preconditions: Edible(y)
• Effects: NOT(Edible(y)), Fed(x)
• Start: Edible(Bread1), Edible(Bread2)
• Goal: Fed(Person1), Fed(Person2), Fed(Person3)
Planning graph for feeding
Edible(Bread1) Edible(Bread1)
FeedWith(Person1, • Any two of these could simultaneously be
Bread1)
true at time 1, so no mutex relations
• Really need 3-way mutex relations, but
FeedWith(Person2, experimentally this is computationally not
Bread1) worthwhile
Fed(Person1)

FeedWith(Person3,
Bread1)
Fed(Person2)

FeedWith(Person1,
Bread2)
Fed(Person3)

FeedWith(Person2,
Bread2)

FeedWith(Person3,
Edible(Bread2) Bread2) Edible(Bread2)
 Uses of planning graphs
• If the goal literals do not all appear at a level (or have mutex relations) then
we know we need another level
• Converse does not hold
• Useful heuristic: first time that all goal literals appear at a level, with no
mutex relations
• Graphplan algorithm: once all goal literals appear, try to extract solution
from graph
• Can use CSP techniques by labeling each action as “in the plan” or “out of the plan”
• In case of failure, generate another level
Expert Systems
• Capture knowledge of an expert.
• Represent Knowledge as a
• rule base
• if then rules
• semantic net
• hierarchy
• frames
• shared characteristics, IS-A relationships
Expert System
Expert System Successes
• XCON - configures systems for DEC
• Prospector - an mining expert
• MYCIN - infectious blood diseases
• EMYCIN - Empty MYCIN
Expert Systems
• Knowledge intensive method
• Expert systems take advantage of expertise of human domain experts
• Human expertise as heuristics
• Support inspection of reasoning processes, presenting intermediate steps and
answering questions about the solution process
• Allow easy modification in adding and deleting skills from KB
• Reason heuristically, using knowledge to get useful solutions
Elements of Expert System Shell
• Knowledge Base
• rules
• Working Memory
• facts of current case
• Inference Engine
• applies rules using current set of facts
• Explanation Facility
• CLIPS
 Expert System Features
• Rich KB and easy modification
• Open reasoning process
• Explanation of reasoning
• Exploratory prototyping
• Heuristic reasoning (problem-solving)
• Wide range applications
• Interpretation – from raw data to conclusion
• Prediction – weather
• Diagnosis – medical, mechanical
• Design – CAD, Civil
• Planning – scheduling, Robot
• Monitoring – Inspector
• Instruction – CAE, online learning
• Control – production line control
 Architecture of Expert Systems
Architecture of a typical expert system for a particular problem domain.
Modules of Expert Systems
• User interface
• simplify communication and hide much of the complexity, such as the internal structure of the
knowledge base
• Knowledge base
• Domain knowledge
• General knowledge and case-specific information
• Optional KB editor
• Inference engine
• Reasoning mechanism to apply the knowledge to the solution of problems
• E.g. recognize-act control cycle in production systems
• Explanation subsystem
• Allow the program to explain its reasoning to the user, to justify the conclusion
• Respond to why and how queries
Separation Knowledge Base from Inference Engine
• Represent knowledge in a more natural fashion
• Builders can focus on capturing and organizing domain knowledge
• Modularization, easy to maintain – modification, addition, removal,
etc
• Build expert system shell that can be provided with different domain
knowledge to form different ES
 Selecting Problems for ES
Guidelines to determine whether a problem is appropriate for expert system solution:

1. The need for the solution justifies the cost and effort of building an expert
system.
2. Human expertise is not available in all situations where it is needed.
3. The problem may be solved using symbolic reasoning.
4. The problem domain is well structured and does not require commonsense
reasoning.
5. The problem may not be solved using traditional computing methods.
6. Cooperative and articulate experts exist.
7. The problem is of proper size and scope.
Roles in Building ES
• Knowledge engineer
• AI language and representation expert
• Select software and hardware, acquire and organize knowledge in specific
form
• Domain expert
• Professionals
• Provide knowledge of application area
• End user
• Specify requirement and constraints
• Test and verify the product
ES Exploratory Development Cycle

ES Programming
– Prototyping development
– Unlimited maintenance
 Knowledge Acquisition
• Acquire expertise (domain knowledge) from domain experts
• Characteristics of domain expertise
• Inaccessible -- Perceptible but non-describable
• Free format
• Vague, imprecise, and bias
• Dynamic (change)
 Knowledge Engineering
• Engineering process
• Knowledge acquisition
• Knowledge representation
• System implementation
• System maintenance
• Conceptual Model
• Intermediate representation of
domain knowledge, like ER
diagram in DB design
Rule-Based Expert Systems
• Features
• Knowledge base organized as a set of if … then … rules
• Lead to the ES architecture
• Natural
• Widely used
• Production system vs. Rule-based ES
• Similarity: both use rules
• Production system is a special case of rule-based systems: production Condition  Action can be
considered as if Condition then Action
• Differences: Production systems implement graph search with either goal-driven or data-driven
strategy, while rule-based ES implements logic reasoning
 A Production System
A small expert system for analysis of automotive problems.
Rule 1: Rule 3:
if the engine is getting gas, If the engine does not turn over,
and and
the engine will turn over, the lights do come on
then then
the problem is spark plugs. the problem is the starter motor.

Rule 2: Rule 4:
If the engine does not turn over, If there is gas in the fuel tank,
and and
the lights do not come on there is gas in the carburetor
then then
the problem is battery or the engine is getting gas.
cables.
Goal-Driven Problem Solving

1. The production system at the start

2. The production system after Rule 1 has fired.
3. The system after Rule 4 has fired.
 Note the stack-based approach to goal reduction
 Depth-first search
The and/or graph searched in the car diagnosis example, with the conclusion of Rule 4
matching the first premise of Rule 1.
Data--Driven Problem Solving
Data

1. The production system at the start.

2. The production system after evaluating the first
premise of Rule 2, which then fails.
3. The data-driven production system after considering
Rule 4, beginning its second pass through the rules.
 Breadth-first search
Explanations in ES
• Two general questions to be answered by rule-based ESs: Why and How
• Explanation in goal-driven reasoning
• Why
• When the system asks the user for information and the user responds “why to ask”
• The answer is the current rule
• How
• When the system conclude a solution and the user asks “how to conclude”
• The answer is the sequence of rules that have been used
• Explanation in data-driven reasoning
• Less-focused on search
• Limited explanation
Explanation in Goal-Driven Reasoning
Gas in fuel tank?
The following dialogue begins Yes
with the computer asking the user Gas in carburetor?
Yes
about the goals present in working Engine will turn over?
memory. Why

It has been established that:

1. The engine is getting gas,
2. The engine will turn over,
Then the problem is the spark plugs.

How the engine is getting gas

This follows from rule 4:

if
gas in fuel tank, and
gas in carburetor
then
engine is getting gas.
gas in fuel tank was given by the user
gas in carburetor was given by the user
Demonstration of Rule-Based Expert Systems
• Command & Conquer Generals
My own Expert System in Wargus
Rules in Wargus
{ id = 1,
name = "build townhall",
preconditions = {hasTownhall(),hasBarracks()},
actions = {
function() return AiNeed(AiCityCenter()) end,
function() return AiSet(AiWorker(), 1) end,
function() return AiWait(AiCityCenter()) end,
function() return AiSet(AiWorker(), 15) end,
function() return AiNeed(AiBarracks()) end,
}
},
{ id = 2,
name = "build blacksmith",
preconditions = {hasTownhall(),hasBarracks()},
etc.
Question: how would you encode domain
knowledge for Wargus?

• ‘Study’ strategy guides for Warcraft 2 (manual)

• Run machine learning experiments to discover new strong rules
(automatic)
• Allow experts (i.e., hardcore gamers) to add rules (semi-automatic)