Learning in Soar
The Issue of Learning in Soar
The ability to learn in Soar is supported directly by the
architectural mechanism known as chunking. This mechanism generalizes and supports multiple learning methods which may
be implemented on top of the basic mechanism. Learning is limited to
only those things which can be produced by a subgoal; in particular, the fixed
mechanisms of the architecture -- the production matcher, the decision procedure, and chunking
itself -- are impenetrable and
thus unable to be improved by the learning mechanism.
Several problems have been identified related to the chunking
mechanism. High match cost
utility
in Soar results in expensive
chunks. Over-Specific chunks have low application
frequency. Chunk creation is normally of sufficient benefit since the
chunk represents the knowledge required to avoids the generation of an
impasse should the same general situation occur.
Over-Specific Chunks
Dependency analysis results in the
inclusion of every working memory
element accessed during impasse resolution that existed prior to
generation of the impasse. Thus, the choice of representation is critical
for avoiding these chunks. For example, in general one would want to
only test for the presence of an attribute instead of a value whenever
possible in problem solving to avoid creating chunks that were
dependent upon specific values exclusively (i.e., resulting in no generalization).
Expensive Chunks
Chunks that depend only upon attributes can match to a combinatorial
number of values (an effect resulting from multi-attribute matching).
This may cause a severe slow-down in matching, regardless of the efficiency of the matcher (assuming the
standard implementation on a serial computer). The generation of
expensive chunks may be avoided by a careful
choice of the underlying representation, resulting in the
generation of of a large (but not combinatorial) number of 'cheap'
chunks. This solution is dependent upon the continued insignificance
of the average growth effect.
Tracing through Negations
The outline of dependency analysis that was presented
in this document was necessarily superficial. One complication to the
procedure as it was presented is that Soar can test for the absence of
a particular piece of information as well as its presence. This is
called a negated condition. Negated conditions represent
defeasibility in Soar's problem solving: the addition of more
information (such as that represented by the negated condition) can
cause the generation of a different result. Several mechanisms have
been proposed for tracing these negations but no complete,
computationally-feasible procedure has been found. Thus, problem
solving that involved negated conditions is a source of over-general
chunks.
Return to the Issues Index for this Architecture.
Return to the top of this architecture.
Go to a Discussion of this
issue for multiple architectures.
Current Location: Soar-Issues-Learning