Large Long Term Declarative Memory: Issues and Ideas

1. Thinking… …inside the box Large Long Term Declarative Memory: Issues and Ideas Soar Workshop Presentation Presented on 10 June 2004 by Jacob Crossman

2. Outline • Purpose: • Understand current thinking with regard to long term declarative memory • Understand possible “engineering solutions” • Understand where current research on the Soar architecture might be applicable • Motivation: three projects at SoarTech • CIANC – ontology integration • HLSR – type system and compiler “bookkeeping” • BINAH – spatio-temporal reasoning • Explore the issues • Propose some solutions • Allow some time for discussion • This is probably a good topic for a breakout session

3. Issue Summary • In practice, many types of knowledge • Are easiest to represent declaratively • Are easiest to maintain in declarative form • Can be generated and used in large quantities • Examples • Ontological and Type information • Auto-generated knowledge • Temporal knowledge • In Soar, encoding large quantities of declarative knowledge tends to be • Time consuming and difficult to get right OR • Inefficient • Technical issues: • How to store declarative knowledge • How to retrieve declarative knowledge • How to integrate learning with declarative knowledge

4. Problem I: Ontology Integration • Description: Integrate knowledge from an ontology (e.g. Standard Upper Merged Ontology) into Soar so the agent can reason over it • Motivation: • Make it easier to modify declarative information (e.g. the types of targets an agent may see in a mission) • Structure declarative information so that it may be more easily reasoned over • Example Projects: • CIANC (this workshop) • Related Examples: HLSR, BINAH • Issues: • Ontologies can be very large, and can overwhelm agent memory (e.g. 200MB) • Current Solution: • Store data in working memory • Write operators to reason over the ontology on demand • Still a work in progress

5. Problem II: Compiled Knowledge • Description: Knowledge is encoded in an abstraction higher than Soar code and compiled into Soar code • Motivation: Speed development by • Reducing the details a developer must encode • Reducing the expertise a developer must have to build agents • In some cases, allowing experts to encode knowledge • Example Projects: • HLSR (this workshop) • Related Examples: TAQL, AGILE, BINAH, HERBAL, Redux • Issues: • Ontological/type information can become very large • Many high-level language structures require some declarative representation to track their state (e.g. goals) • Meta-reasoning structures • Current Solution: • Store data in working memory • Manage declarative memory context with productions – compiler hides details • Still work in progress

6. Problem III: Temporal Reasoning • Description: memory is continuously updated with knowledge about previous beliefs • Motivation: Allow reasoning over time; in particular, let an agent reason over what it believed and did in the past • Example Projects: • BINAH (this workshop) • Related Examples: Episodic Memory, AGILE, HLSR • Issues: • Chunking seems awkward for this process • Declarative memory grows quickly and linearly as the time the agent executes • The best way to access this knowledge is not yet clear • Current Solution: • Store data in working memory • Encode Soar-based “compacting” and “forgetting” algorithms • Build language to query this knowledge (e.g. BINAH, HLSR) • Still a work in progress

7. Categorization/Evaluation of Possible Solutions • Architecture Integration • Integrated • External • Interaction Mechanism • Passive Retrieval • Active Retrieval • Programmability • Fast/Easy • Slow/Difficult • Maintainability • Easy • Difficult • Compatibility • Backward Compatible • Not Backward Comp. • Theory • Computer Science • Psychologically Plausible • Efficiency • Fast • Slow • Memory Size • Small • Large • Solution Form • Long-term solution • “Engineering” solution (aka “hack”) • Scalability • Limited • Unlimited

8. Typical Soar Technology, Inc. Priorities • Programmability • How fast can we build the system? • Result of project time constraints • Architecture Integration • External integration is time consuming • Internal solutions require only Soar developer • Efficiency • Load time  debug time  development time • Sometimes execution time is important • Memory Size • We have agents that are 200MB large! • Typical – 10-20MB • Maintainability

9. Typical Solution: Use Working Memory • Store everything in working memory (aka, treat WM as LT declarative memory) • Use elaboration productions to load data OR • Use input link • Characteristics • Integrated solution • Passive retrieval • Engineering solution (“Hack”) • Advantages • Easy to program and debug • Fairly efficient (to a point) • Easily maintained • Backward Compatible • Disadvantages • No compelling theory (in CS or Cognition) • Not scalable • Large (sometimes very large) memory sizes

10. Soar Solution: Productions and Data Chunking • “Listen to the architecture” and store all long term memory as productions • Encode productions such that declarative knowledge is available based on cues • Use data chunking to learn more declarative knowledge • Characteristics • Integrated Solution • Mixed passive/active retrieval • Long-term solution • Advantages • Theoretically sound (from Soar standpoint) • Efficient • Scalable (because of RETE) • Backward compatible • Disadvantages • Hard to program • Difficult to maintain and debug • Large memory sizes

11. Idea I: Integrate with a Database • Store long term declarative knowledge in an external database • Use operators to cue retrieval • Use I/O links to interact with DB • Characteristics • External solution • Active retrieval • Mixed engineering/long-term solution • Advantages • Moderately easy to program • Easy to maintain • Better managed memory sizes • Scalable • Backward compatible • Disadvantages • Really has nothing to do with psychological or Soar theory • Inefficient

12. Idea II: Use “virtual” working memory • Still store everything in working memory, but modify kernel to create “tiered” memory like an OS • Store rarely accessed WM on disk • Store often accessed WM in RAM • Characteristics • Integrated solution • Passive retrieval • Engineering solution (“Hack”) • Advantages • Easy to program • Easy to maintain • Better managed memory sizes • Scalable • Probably backward compatible • Disadvantages • Not psychologically plausible • Less efficient

13. Idea IIIa: Engineering Driven LT Declarative Memory • Develop a new LT declarative memory for Soar focusing on engineering issues such as efficiency, accuracy, programmability • Characteristics • Internal to architecture • Passive/active retrieval (depends on approach) • Long-term solution • Advantages (anticipated) • Easy to program • Easy to maintain • Better managed memory sizes • Scalable • Efficient • Disadvantages • Probably not psychologically plausible • Might not be backward compatible • Key Impact: Shift Soar further toward an AI architecture vs. a cognitive architecture

14. Idea IIIb: Cognition Driven LT Declarative Memory • Develop a new LT declarative memory for Soar focusing on issues of cognition such as retrieval timing, interference, and failures (e.g. similar to ACT-R) • Characteristics • Internal to architecture • Passive/active retrieval (depends on approach) • Long-term solution • Advantages (anticipated) • Easy to program • Easy to maintain • Better managed memory sizes • Scalable • Efficient • Disadvantages • Probably psychologically implausible • Might not be backward compatible • Key Impact: Shift Soar further toward a cognitive architecture vs. an AI architecture

15. Conclusions • For Soar Technology, the issue of large declarative memory in Soar • Impacts many of our projects • Grows more important every year • We believe that this issue has a broad impact on anyone building knowledge-rich agents • We would like to leverage what others are doing in the Soar community, if applicable • We (at SoarTech) will seek solutions • Short term: engineering solutions such as integration with a database • Long term: search for more permanent integrated solutions – but will the result still be Soar? • Important: If a solution is hard to program or maintain, it won’t get used (at least, not broadly) • Therefore, any complex solutions should be abstracted through some higher level representation or process

16. Questions/Comments