are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements,

The origins of the Soar architecture can be traced back to the seminal research of Allen Newell and Herbert Simon on symbol systems, heuristic search, goals, problem spaces, and production systems. Since its official inception in 1982, Soar has evolved through six major releases, as both an AI architecture and as the basis for a unified theory of cognition. This paper traces this evolutionary path, starting with Soar's intellectual roots, and then proceeding through the stages defined by the six major system releases. Each stage is characterized with respect to a hierarchy of four levels of analysis: the knowledge level, the problem space level, the symbolic architecture level, and the implementation level.

In its early stages, the field of artificial intelligence (AI) had as its main goal the invention of computer programs having the general problem solving abilities of humans. Along the way, there developed a major shift of emphasis from general-purpose programs toward "performance programs"---ones whose competence was highly specialized and limited to particular areas of expertise. In this paper I claim that AI is now at the beginning of another transition---one that will re-invigorate efforts to build programs of general, human-like competence. These programs will use specialized performance programs as tools, much like humans do. Keywords: autonomous agents, general problem solving, habile systems Copyright c fl1995 Nils J. Nilsson [This paper is being submitted to the AI Magazine.] 1 Diversions from the Main Goal Over forty years ago, soon after the birth of electronic computers, people began to think that human levels of intelligence might someday be realized in computer program...

Chunking, an experience based-learning mechanism, improves Soar's performance a great deal when viewed in terms of the number of subproblems required and the number of steps within a subproblem. This high-level view of the impact of chunking on performance is based on an deal computational model, which says that the time per step is constant. However, if the chunks created by chunking are expensive, then they consume a large amount of processing in the match, i.e, indexing the knowledge-base, distorting Soar*s constant time-per-stcp model. In these situations, the gain in number of steps does not reflect an improvement in performance; in fact there may be degradation in the total run time of the system. Such chunks form a major problem for the system, since absolutely 10 guarantees can be given about its behavior. I "his article presents a solution to the problem of expensive chunks. The solution is based on the notion of restricting the expressiveness of Soar's representational language to guarantee that chunks formed will require only a limited amount of matching effort. We analyze the tradeoffs involved in restricting expressiveness and present some empirical evidence to support our analysis. 1.

One view of expert system development separates the endeavor into two parts. First, a domain expert, with the aid of a knowledge engineer, articulates a procedure for performing the desired task in some external form. Next, the knowledge engineer operationalizes the external description within some computer language. This paper examines the nature of the processes that operationalize natural task descriptions. We exhibit a language based on a computational model of problem spaces for which these processes are quite simple. We describe the processes in detail, and discuss which aspects of our computational model determine the simplicity of these processes. 1 1.

Abstraction has proven to be a powerful tool for controlling the combinatorics of a problemsolving search. It is also of critical importance for learning systems. In this article we present, and evaluate experimentally, a general abstraction method — impasse-driven abstraction-which is able to provide necessary assistance to both problem solving and learning. It reduces the amount of time required to solve problems, and the time required to learn new rules. In addition, it results in the acquisition of rules that are more general than would have otherwise been learned. 1

RETE and TREAT are two well known algorithms used for performing match in production systems (rule-based systems). In this paper, we compare the performance of these two algorithms in the context of Soar programs. Using the number of tokens processed by each algorithm as the performance metric, we show that the RETE algorithm performs better than the TREAT algorithm in most cases. Our results are different than the ones shown by Miranker for OPS5. The main reasons for this difference are related to the following: (i) fraction of times no joins need to be done; (ii) the long chain effect; (iii) matching of static structures; and (iv) handling of combinatorial joins. These reasons go beyond Soar in their applicability, and are relevant to other OPS5-based production systems that share some of Soar's properties. We also discuss several implementation issues for the two algorithms. 1 Introduction Soar is a cognitive architecture that provides the foundations for building systems that exh...

: We argue that adding a requirement of evaluation and testing fundamentally changes KBS practice. In particular: (i) a fundamental change to the symbol-level representation in KBS; (ii) a rejection of certain unnecessary knowledge-level distinctions; (iii) a fundamental change to the inference engine of KBS; and (iv) a basic computational limit to the size and internal complexity of the models we create via knowledge acquisition. 1. INTRODUCTION It would be convenient if KBS evaluation was neutral with respect to KBS practice. If an evaluation module was merely a post-hoc bolt-on, then its design could be deferred until after a system was developed. However, if evaluation adds extra requirements and restrictions to the KBS process, then the design of an evaluation module must be integrated with the system it will test. This paper argues for the inconvenient latter position. Models constructed in vague domains (defined below) are possibly inaccurate. Possibly inaccurate models must b...

Abstract not found

One of the major problems in maintaining large rule-based expert system is that the functions performed by rules usually are not well specified, which makes rules difficult to comprehend and modify. Polymorphism in object-oriented programming suggests a promising approach for separating the function of a rule from its implementation details, which can be described by methods. However, there are two major difficulties in integrating methods and rules. First, methods in conventional object-oriented systems can not describe complex conditions regarding their applicability in an expert system. Second, method dispatching does not provide the flexibility of control that is often desirable for an expert system. To alleviate these difficulties, we have generalized methods in two ways. First, the situation about a method's applicability is described by a conjunctive pattern. Second, each generic operation could specify its own control strategy for the selection of methods. To enable specificity...