[[http://cadia.ru.is/wiki/public:t-720-atai:atai-18:main|T-720-ATAI-2018 Main]] \\
[[http://cadia.ru.is/wiki/public:t-720-atai:atai-18:Lecture_Notes|Links to Lecture Notes]]
=====T-720-ATAI-2018=====
====Lecture Notes, W9: AI Architectures====
\\
\\
\\
---------------
\\
\\
====System Architecture====
| What it is | In CS: the organization of the software that implements a system. \\ In AI: The total system that has direct and independent control of the behavior of an Agent via its sensors and effectors. |
| Why it's important | The system architecture determines what kind of information processing can be done, and what the system as a whole is capable of in a particular Task-Environemnt. |
| Key concepts | process types; process initiation; information storage; information flow. |
| Graph representation | Common way to represent processes as nodes, information flow as edges. |
| \\ Relation to AI | The term "system" not only includes the processing components, the functions these implement, their input and output, and relationships, but also temporal aspects of the system's behavior as a whole. This is important in AI because any controller of an agent is supposed to control it in such a way that its behavior can be classified as being "intelligent". But what are the necessary and sufficient components of that behavior set? |
| \\ Rationality | The "rationality hypothesis" models an intelligent agent as a "rational" agent: An agent that would always do the most "sensible" thing at any point in time. \\ The problem with the rationality hypothesis is that given insufficient resources, including time, the concept of rationality doesn't hold up, because it assumes you have time to weigh all alternatives (or, if you have limited time, that you can choose to evaluate the most relevant options and choose among those). But since such decisions are always about the future, and we cannot predict the future perfectly, for most decisions that we get a choice in how to proceed there is no such thing as a rational choice. |
| Satisficing | Herbert Simon proposed the concept of "satisficing" to replace the concept of "optimizing" when talking about intelligent action in a complex task-environment. Actions that meet a particular minimum requirement in light of a particular goal 'satisfy' and 'suffice' for the purposes of that goal. |
| Intelligence is in part a systemic phenomenon | Thought experiment: Take any system we deem intelligent, e.g. a 10-year old human, and isolate any of his/her skills and features. A machine that implements any //single// one of these is unlikely to seem worthy of being called "intelligent" (viz chess programs), without further qualification (e.g. "a limited expert in a sub-field"). \\ //"The intelligence **is** the architecture."// - KRTh |
\\
\\
====CS Architecture Building Blocks====
| \\ Pipes & filters | Extension of functions. \\ Component: Each component has a set of inputs and a set of outputs. A component reads streams of data on its inputs and produces streams of data on its outputs, delivering a complete instance of the result in a standard order. \\ Pipes: Connectors in a system of such components transmit outputs of one filter to inputs of others. |
| Object-orientation | Abstract compound data types with associated operations. |
| Event-based invocation | Pre-defined event types trigger particular computation sequences in pre-defined ways. |
| Layered systems | System is deliberately separated into layers, a layer being a grouping of one or more sub-functions. |
| Hierarchical systems | System is deliberately organized into a hierarchy, where the position in the hierarchy represents one or more important (key system) parameters. |
| Blackboards | System employs a common data store, accessible by more than a single a sub-process of the system (often all). |
| Hybrid architectures | Take two or more of the above and mix together to suit your tastes. |
\\
\\
====Network Topologies====
| Point-to-Point | Dedicated connection between nodes, shared only by a node at each end. |
| Bus | A message medium, shared by all nodes (or a subset). |
| Star | Central node serves as a conduit, forwarding to others; full structure of nodes forming a kind of star. |
| Ring | All nodes are connected to only two other nodes. |
| Mesh | All nodes are connected to all other nodes (fully connected graph); can be relaxed to partially-connected graph. |
| Tree | Node connections forms a hierarchical tree structure. |
| Pub-Sub | In publish-subscribe architectures one or more "post offices" receive requests to get certain information from nodes. |
| reference | [[https://en.wikipedia.org/wiki/Network_topology|Network topology on Wikipedia]] |
\\
\\
====Coordination Hierarchies====
| {{ public:t-720-atai:coordinationhierarchies.png?500 }} |
| A functional hierarchy organizes the execution of tasks according to their functions. A product hierarchy organizes production in little units, each focused on a particular product. \\ Several types of markets exist - here two idealized versions are show, without and with brokers. De-centralized markets require more intelligence to be present in the nodes, which can be aleviated by brokers. Brokers, however, present weak points in the system: If you have a system with only 2 brokers mediating between processors and consumers/buyers, failure in these 2 points will render the system useless. \\ Notice that in a basic program written in C++ every single character is such a potential point of failure, which is why bugs are so common in standard software. |
\\
\\
====Reactive Agent Architecture====
| Architecture | Largely fixed for the entire lifetime of the agent. \\ Agent may learn but acts only in reaction to experience (no prediction). |
| Super-simple | Sensors connected directly to motors. \\ Example: Braitenberg Vehicles. |
| Simple | Deterministic connections between components with small memory. \\ Examples: Chess engines, Roomba vacuum cleaner. |
| Complex | Grossly modular architecture (< 30 modules) with multiple relationships at more than one level of control detail (LoC). \\ Examples: Speech-controlled dialogue systems like Siri and Alexa. |
| Super-Complex | Large number of modules (> 30) at various sizes, each with multiple relationships to others, at more than one LoC. \\ Example: Subsumption architecture. |
| \\ \\ Bottom Line | Most architectures are of this kind - towards the higher end of this spectrum very few exists. \\ What about complex control systems for power plants, manufacturing plants, etc - don't they contain an equal level of complexity (or greater) than the complex or super-complex end of this spectrum? Answer is: Perhaps so (depending on how it's measured), but bear in mind that none of them learn or adapt (except in some extremely trivial ways that are highly localized and specific). \\ Relying exclusively on constructionist methodologies, it is difficult to put learning into architectures at the high end of this spectrum, and when it's done it's difficult to keep the side effects securely within safe limits. |
\\
\\
====Subsumption Examples====
| {{ :public:t-720-atai:subsumption-arch-module-1.gif?450 }} |
| Subsumption control architecture building block. |
| {{ :public:t-720-atai:subsumption-arch-2.jpg?450 }} |
| Example subsumption architecture for robot. |
| {{ :public:t-720-atai:subsump-level0.png?450 }} |
| Subsumption architecture example, level 0. |
| {{ :public:t-720-atai:subsump-level1.png?450 }} |
| Subsumption architecture example, level 1. |
| {{ :public:t-720-atai:subsump-level2.png?450 }} |
| Subsumption architecture example, level 2. |
\\
\\
====Predictive Agent Architecture====
| Architecture | Largely fixed for the entire lifetime of the agent. \\ Subsumes the reactive agent architecture, adding that the agent may learn to predict and can use predictions to steer its actions. |
| Super-simple | These are above the complexity of super-simple architectures. |
| Simple | Deterministic connections between components with small memory, where the memory makes learning and prediction possible. Example: Nest "intelligent" thermostat. |
| Complex | Grossly modular architecture (< 30 modules) with multiple relationships at more than one level of control detail (LoC). \\ Examples: No obvious ones come to mind. |
| Super-Complex | Large number of modules (> 30) at various sizes, each with multiple relationships to others, at more than one LoC. \\ Examples: No obvious ones come to mind. |
| Bottom Line | It is difficult but possible to integrate predictive learning and behavior control into complex agent architectures using constructionist approaches (hand-coding); better methodologies are needed. |
\\
\\
====Reflective Agent Architecture====
| Architecture | Architecture changes over the history of the agent. \\ Subsumes features of reactive and predictive architectures, adding introspection (reflection) and some form of reasoning (as necessary for managing the introspection). |
| Super-simple | These are above the complexity of super-simple architectures. |
| Simple | These are above the complexity of simple architectures. |
| Complex | Complexity stems from interaction among parts, many of which are generated by the system at runtime and whose complexity may mirror some parts of the task-environment (if task-environment is complex, and lifetime is long, the resulting control structures are likely to be complex as well). \\ Examples: NARS, AERA. |
| Super-Complex | Complexity stems from two-level (or more) systems of the complex kind, where a meta-control layer is in charge of changing the lower level (self-rewriting architecture). \\ Examples: AERA (in theory - not experimentally validated). |
\\
\\
\\
\\
====Inferred AGI Architectural Features ====
| \\ Large architecture | An architecture that is considerably more complex than systems being built in most AI labs today is likely unavoidable. In a complex architecture the issue of concurrency of processes must be addressed, a problem that has not yet been sufficiently resolved in present software and hardware. This scaling problem cannot be addressed by the usual “we’ll wait for Moore’s law to catch up” because the issue does not primarily revolve around //speed of execution// but around the //nature of the architectural principles of the system and their runtime operation//. ||
| \\ Predictable Robustness in Novel Circumstances | The system must have a robustness in light of all kinds of task-environment and embodiment perturbations, otherwise no reliable plans can be made, and thus no reliable execution of tasks can ever be reached, no matter how powerful the learning capacity. This robustness must be predictable a-priori at some level of abstraction -- for a wide range of novel circumstances it cannot be a complete surprise that the system "holds up". (If this were the case then the system itself would not be able to predict its chances of success in face of novel circumstances, thus eliminating an important part of the "G" from its "AGI" label.) ||
| \\ Graceful Degradation | Part of the robustness requirement is that the system be constructed in a way as to minimize potential for catastrophic (and upredictable) failure. A programmer forgets to delimit a command in a compiled program and the whole application crashes; this kind of brittleness is not an option for cognitive systems operating in partially stochastic environments, where perturbations may come in any form at any time (and perfect prediction is impossible). ||
| Transversal Functions | The system must have pan-architectural characteristics that enable it to operate consistently as a whole, to be highly adaptive (yet robust) in its own operation across the board, including metacognitive abilities. Some functions likely to be needed to achieve this include attention, learning, analogy-making capabilities, and self-inspection. ||
| | \\ Transversal Time | Ignoring (general) temporal constraints is not an option if we want AGI. Move over Turing! Time is a semantic property, and the system must be able to understand – and be able to //learn to understand// – time as a real-world phenomenon in relation to its own skills and architectural operation. Time is everywhere, and is different from other resources in that there is a global clock which cannot, for many task-environments, be turned backwards. Energy must also be addressed, but may not be as fundamentally detrimental to ignore as time while we are in the early stages of exploring methods for developing auto-catalytic knowledge acquisition and cognitive growth mechanisms. \\ Time must be a tightly integrated phenomenon in any AGI architecture - managing and understanding time cannot be retrofitted to a complex architecture! |
| | \\ Transversal Learning | The system should be able to learn anything and everything, which means learning probably not best located in a particular "module" or "modules" in the architecture. \\ Learning must be a tightly integrated phenomenon in any AGI architecture, and must be part of the design from the beginning - implementing general learning into an existing architecture is out of the question: Learning cannot be retrofitted to a complex architecture! |
| | Transversal Resource Management | Resource management - //attention// - must be tightly integrated.\\ Attention must be part of the system design from the beginning - retrofitting resource management into a architecture that didn't include this from the beginning is next to impossible! |
| | Transversal Analogies | Analogies must be included in the system design from the beginning - retrofitting the ability to make general analogies between anything and everything is impossible! |
| | \\ Transversal Self-Inspection | Reflectivity, as it is known, is a fundamental property of knowledge representation. The fact that we humans can talk about the stuff that we think about, and can talk about the fact that we talk about the fact that we can talk about it, is a strong implication that reflectivity is a key property of AGI systems. \\ Reflectivity must be part of the architecture from the beginning - retrofitting this ability into any architecture is virtually impossible! |
| | Transversal Integration | A general-purpose system must tightly and finely coordinate a host of skills, including their acquisition, transitions between skills at runtime, how to combine two or more skills, and transfer of learning between them over time at many levels of temporal and topical detail. |
\\
\\
====High-Level View of AERA====
| AERA | The Auto-Catalytic Endogenous Reflective Architecture is an AGI-aspiring self-programming system that combines feedback and feed-forward control in a model-based and model-driven system that is programmed with a seed. |
| {{/public:t-720-atai:aera-high-level-2018.png?700}} ||
| High-level view of the three main functions at work in a running AERA system and their interaction with its knowledge store. ||
| \\ Models | All models are stored in a central //memory//, and the three processes of //planning//, //attention// (resource management) and //learning// happen as a result of programs that operate on models by matching, activating, and scoring them. Models that predict correctly -- not just "what happens next?" but also "what will happen if I do X?" -- get a success point. Every time a model 'fires' like that it gets counted, so the ratio of success over counts gives you the "goodness" of a model. \\ Models that have the lowest scores are deleted, models with a good score that suddenly fail result in the generation of new versions of itself (think of it as hypotheses for why it failed this time), and this process over time increases the quality and utility of the knowledge of the controller, in other words it //learns//. |
| \\ Attention | Attention is nothing more than resource management, in the case of cognitive controllers it typically involves management of knowledge, time, energy, and computing power. Attention in AERA is the set of functions that decides how the controller uses its compute time, how long it "mulls things over", and how far into the future it allows itself to "think". It also involves which models the system works with at any point in time, how much it explores models outside of the obvious candidate set at any point in time. |
| \\ Planning | Planning is the set of operations involved with looking at alternative ways of proceeding, based on predictions into the future and the quality of the solutions found so far, at any point in time. The plans produced by AERA are of a mixed opportunistic (short time horizon)/firm commitment (long time horizon) kind, and their stability (subject to change drastically over their course) depend solely on the dependability of the models involved -- i.e. how well the models represent what is actually going on in the world (including the controllers "mind"). |
| Learning | Learning happens as a result of the accumulation of models; as they increasingly describe "reality" better (i.e. their target phenomenon) they get better for planning and attention, which in turn improves the learning. |
| Memory | AREA's "global knowledge base" is in some ways similar to the idea of blackboards: AERA stores all its knowledge in a "global workspace" or memory. Unlike (Selfridge's idea of) blackboards, the blackboard contains executive functions that manage the knowledge dynamically, in addition to "the experts", which in AERA's case are very tiny and better thought of as "models with codelet helpers". |
| Pervasive Use of Codelets | A //codelet// is a piece of code that is smaller than a typical self-contained program, typically a few lines long, and can only be executed in particular contexts. Programs are constructed on the fly by the operation of the whole system selecting which codelets to run when, based on the knowledge of the system, the active goals, and the state it finds itself in at any point in time. |
| \\ No "Modules" | Note that the diagram above may imply the false impression that AERA consists of these four software "modules", or "classes", or the like. Nothing could be further from the truth: All of AERA's mechanism above are a set of functions that are "welded in with" the operation of the whole system, distributed in a myriad of mechanisms and actions. \\ Does this mean that AERA is spaghetti code, or a mess of a design? On the contrary, the integration and overlap of various mechanisms to achieve the high-level functions depicted in the diagram are surprisingly clean, simple, and coherent in their implementation and operation. \\ This does not mean, however, that AERA is easy to understand -- mainly because it uses concepts and implements mechanisms and relies on concepts that are //very different// from most traditional software systems commonly recognized in computer science. |
\\
\\
====Autonomous Model Acquisition====
| What it is | The ability to create a model of some target phenomenon //automatically//. |
| Challenge | Unless we know beforehand which signals cause perturbations in o and can hard-wire these from the get-go in the controller, the controller must search for these signals. \\ In task-domains where the number of available signals is vastly greater than the controller's resources available to do such search, it may take an unacceptable time for the controller to find good predictive variables to create models with. \\ V_te >> V_mem, where the former is the total number of potentially observable and manipulatable variables in the task-environment and the latter is the number of variables that the agent can hold in its memory at any point in time. |
\\
\\
====Model Acquisition Function====
| {{public:t-720-atai:agent-with-model-gen-function1.png?300}} ||
| The agent has a model generation function P_M implemented in its controller. The role of the function is to take observed chains of events and produce models intended to capture the events' causal relationships. ||
| {{public:t-720-atai:causal-chain_agent1.png?400}} ||
| A learning agent is situated so as to perceive the effects of the relationships between variables. \\ The agent observes the interaction between the variables for a while, rendering some data about their relations (but not enough to be certain about it, and certainly not enough to create a complete model of it). \\ This generates hypotheses about the relation between variables, in the form of candidate relational models of the observed events. ||
\\
\\
==== Model Generation & Evaluation ====
| {{public:t-720-atai:three-models-1.png?400}} |
| Based on prior observations, of the variables and their temporal execution in some context, the controller's model generation function P_M may have captured their causal relationship in three alternative models, M_1, M_2, M_3, each slightly but measurably different from the others. Each can be considered a //hypothesis of the actual relationship between the included variables//, when in the context provided by V_5, V_6. |
| {{public:t-720-atai:agent-with-models-1.png?300}} |
| The agent's model generation mechanisms allow it to produce models of events it sees. Here it creates models (a) M_1 and (b) M_2. The usefulness / utility of these models can be tested by performing an operation on the world (c ) as prescribed by the models. (Ideally, when one wants to find on which one is best, the most efficient method is an (energy-preserving) intervention that can only leave one as the winner.) |
| {{public:t-720-atai:model-m2-prime-1.png?150}} |
| The result of feedback (reinforcement) may result in the deletion, rewriting, or some other modification of the original model selected for prediction. Here the feedback has resulted in a modified model M{prime}_2. |
\\
\\
\\
\\
====Demo Of AERA In Action====
| Demos | The most complex demo of an AERA system was the S1 agent learning to do an interview (in the EU-funded HUMANOBS research project). [[http://www.mindmakers.org/projects/humanobs/wiki/HUMANOBS_Videos|Main HUMANOBS page]] |
| TV Interview | In the style of a TV interview, the agent S1 watched two humans engaged in a "TV-style" interview about the recycling of six everyday objects made out of various materials. |
| Data | S1 received realtime timestamped data from the 3D movement of the humans (digitized via appropriate tracking methods at 20 Hz), words generated by a speech recognizer, and prosody (fundamental pitch of voice at 60 Hz, along with timestamped starts and stops). |
| Seed | The seed consisted of a handful of top-level goals for each agent in the interview (interviewer and interviewee), and a small knowledge base about entities in the scene. |
| What Was Given | * actions: grab, release, point-at, look-at (defined as event types constrained by geometric relationships) \\ * stopping the interview clock ends the session \\ * objects: glass-bottle, plastic-bottle, cardboard-box, wodden-cube, newspaper, wooden-cube \\ * objects have properties (e.g. made-of) \\ * interviewee-role \\ * interviewer-role \\ * Model for interviewer \\ * top-level goal of interviewer: prompt interviewee to communicate \\ * in interruption case: an imposed interview duration time limit \\ * Models for interviewee \\ * top-level goal of interviewee: to communicate \\ * never communicate unless prompted \\ * communicate about properties of objects being asked about, for as long as there still are properties available \\ * don’t communicate about properties that have already been mentioned |
| What Had To Be Learned | GENERAL INTERVIEW PRINCIPLES \\ * word order in sentences (with no a-priori grammar) \\ * disambiguation via co-verbal deictic references \\ * role of interviewer and interviewee \\ * interview involves serialization of joint actions (a series of Qs and As by each participant) \\ \\ MULTIMODAL COORDINATION & JOINT ACTION \\ * take turns speaking \\ * co-verbal deictic reference \\ * manipulation as deictic reference \\ * looking as deictic reference \\ * pointing as deictic reference \\ \\ INTERVIEWER \\ * to ask a series of questions, not repeating questions about objects already addressed \\ * “thank you” stops the interview clock \\ * interruption condition: using “hold on, let’s go to the next question” can be used to keep interview within time limits \\ \\ INTERVIEWEE \\ * what to answer based on what is asked \\ * an object property is not spoken of if it is not asked for \\ * a silence from the interviewer means “go on” \\ * a nod from the interviewer means “go on” |
| Result | After having observed two humans interact in a simulated TV interview for some time, the AERA agent S1 takes the role of interviewee, continuing the interview in precisely the same fasion as before, answering the questions of the human interviewer (see videos HH.no_interrupt.mp4 and HH.no_interrupt.mp4 for the human-human interaction that S1 observed; see HM.no_interrupt_mp4 and HM_interrupt_mp4 for other examples of the skills that S1 has acquired by observation). In the "interrupt" scenario S1 has learned to use interruption as a method to keep the interview from going over a pre-defined time limit. \\ \\ The results are recorded in a set of three videos: \\ [[https://www.youtube.com/watch?v=SH6tQ4fgWA4|Human-human interaction]] (what S1 observes) \\ [[https://www.youtube.com/watch?v=SH6tQ4fgWA4|Human-S1 interaction]] (S1 interviewing a human) \\ [[https://www.youtube.com/watch?v=x96HXLPLORg|S1-Human Interaction]] (S1 being interviewed by a human) |
\\
\\
2018(c)K. R. Thórisson
\\
\\
//EOF//