| |
| public:t_720_atai:atai-18:lecture_notes_methodologies [2018/10/06 16:51] – [Lecture Notes, W8: AI Methodologies & Architectures] thorisson | public:t_720_atai:atai-18:lecture_notes_methodologies [2024/04/29 13:33] (current) – external edit 127.0.0.1 |
|---|
| | Reductionism | The method of isolating parts of a complex phenomenon or system in order to simplify and speed up our understanding of it. See also [[https://en.wikipedia.org/wiki/Reductionism|Reductionism]] on Wikipedia. | | | Reductionism | The method of isolating parts of a complex phenomenon or system in order to simplify and speed up our understanding of it. See also [[https://en.wikipedia.org/wiki/Reductionism|Reductionism]] on Wikipedia. | |
| | Occam's Razor | Key principle of reductionism. See also [[https://en.wikipedia.org/wiki/Occam%27s_razor|Occam's Razor]]. | | | Occam's Razor | Key principle of reductionism. See also [[https://en.wikipedia.org/wiki/Occam%27s_razor|Occam's Razor]]. | |
| | HeLD | Cannot be studied by the standard application of reductionism/Occam's Razor, because the emergent properties are lost. Instead, corollaries of the system -- while ensuring some commonality to the original system //in toto// -- must be studied to gain insights into the target system. | | | \\ HeLD | Cannot be studied by the standard application of reductionism/Occam's Razor, because the emergent properties are lost. Instead, corollaries of the system -- while ensuring some commonality to the original system //in toto// -- must be studied to gain insights into the target system. | |
| | Agent & Environment | We try to characterize the agent and its task-environment as two interacting complex systems. If we keep the task-environment constant, the remaining system to study is the agent and its controller. | | | Agent & Environment | We try to characterize the agent and its task-environment as two interacting complex systems. If we keep the task-environment constant, the remaining system to study is the agent and its controller. | |
| |
| | Why it's important | Virtually all methodologies we have for creating software are of this kind. | | | Why it's important | Virtually all methodologies we have for creating software are of this kind. | |
| | Fundamental CS methodology | On the theory side, for the most part mathematical methodologies (not natural science). On the practical side, hand-coding programs and manual invention and implementation of algorithms. Systems creation in CS is "co-owned" by the field of engineering. | | | Fundamental CS methodology | On the theory side, for the most part mathematical methodologies (not natural science). On the practical side, hand-coding programs and manual invention and implementation of algorithms. Systems creation in CS is "co-owned" by the field of engineering. | |
| | The main methodology/ies in CS | Constructionist. | | | The main methodology/ies in CS | \\ Constructionist. | |
| |
| |
| | What it is | Refers to AI system development methodologies that require an intelligent designer -- the software programmer as "construction worker". | | | What it is | Refers to AI system development methodologies that require an intelligent designer -- the software programmer as "construction worker". | |
| | Why it's important | All traditional software development methodologies, and by extension all traditional AI methodologies, are constructionist methodologies. | | | Why it's important | All traditional software development methodologies, and by extension all traditional AI methodologies, are constructionist methodologies. | |
| | What it's good for | Works well for constructing //controllers// of Closed Problems where (a) the Solution Space can be defined fully or largely before the controller is constructed, (b) there clearly definable Goal hierarchies and measurements that, when used, fully implement the main purpose of the AI system, and ( c) the Task assigned to the controller will not change throughout its lifetime (i.e. the controller does not have to generate novel sub-Goals). | | | \\ What it's good for | Works well for constructing //controllers// of Closed Problems where (a) the Solution Space can be defined fully or largely before the controller is constructed, (b) there exist clearly definable Goal hierarchies and measurements that, when used, fully implement the main purpose of the AI system, and ( c) the Task assigned to the controller will not change throughout its lifetime (i.e. the controller does not have to generate novel sub-Goals). | |
| | Key Implementation Method | Hand-coding using programming language and methods created to be used by human-level intelligences. | | | Key Implementation Method | Hand-coding using programming language and methods created to be used by human-level intelligences. | |
| |
| | The AFSMs are arranged in "layers" | Layers separate functional parts of the architecture from each other | | | The AFSMs are arranged in "layers" | Layers separate functional parts of the architecture from each other | |
| | | | | | | | |
| | | {{/public:t-720-atai:subsumption-arch-2.jpg}} | | || {{/public:t-720-atai:subsumption-arch-2.jpg?700}} || |
| | | Example subsumption architecture with layers. | | || Example subsumption architecture with layers. || |
| |
| \\ | \\ |
| \\ | \\ |
| \\ | \\ |
| ====Key Limitations of Constructionist Methodologies)==== | ====Key Limitations of Constructionist Methodologies==== |
| | Static | System components that are fairly static. Manual construction limits the complexity that can be built into each component. | | | Static | System components that are fairly static. Manual construction limits the complexity that can be built into each component. | |
| | Size | The sheer number of components that can form a single architecture is limited by what a designer or team can handle. | | | Size | The sheer number of components that can form a single architecture is limited by what a designer or team can handle. | |
| | | von Glasersfeld | "...‘empirical teleology’ ... is based on the empirical fact that human subjects abstract ‘efficient’ causal connections from their experience and formulate them as rules which can be projected into the future." [[http://www.univie.ac.at/constructivism/EvG/papers/225.pdf|REF]] \\ CAIM was developed in tandem with this architecture/architectural blueprint. | | | | von Glasersfeld | "...‘empirical teleology’ ... is based on the empirical fact that human subjects abstract ‘efficient’ causal connections from their experience and formulate them as rules which can be projected into the future." [[http://www.univie.ac.at/constructivism/EvG/papers/225.pdf|REF]] \\ CAIM was developed in tandem with this architecture/architectural blueprint. | |
| | Architectures built using CAIM | AERA | Autocatalytic, Endogenous, Reflective Architecture [[http://cadia.ru.is/wiki/_media/public:publications:aera-rutr-scs13002.pdf|REF]] \\ Built before CAIM emerged, but based on many of the assumptions consolidated in CAIM. | | | Architectures built using CAIM | AERA | Autocatalytic, Endogenous, Reflective Architecture [[http://cadia.ru.is/wiki/_media/public:publications:aera-rutr-scs13002.pdf|REF]] \\ Built before CAIM emerged, but based on many of the assumptions consolidated in CAIM. | |
| | | NARS | Non-Axiomatic Reasoning System [[https://sites.google.com/site/narswang/|REF]] | | | | NARS | Non-Axiomatic Reasoning System [[https://sites.google.com/site/narswang/|REF]] \\ //“If the existing domain-specific AI techniques are seen as tools, each of which is designed to solve a special problem, then to get a general-purpose intelligent system, it is not enough to put these tools into a toolbox. What we need here is a hand. To build an integrated system that is self-consistent, it is crucial to build the system around a general and flexible core, as the hand that uses the tools [assuming] different forms and shapes.”// -- Wang, 2004 | |
| | Limitations | As a young methodology very little hard data is available to its effectiveness. What does exist, however, is more promising than constructionist methodologies for achieving AGI. || | | Limitations | As a young methodology very little hard data is available to its effectiveness. What does exist, however, is more promising than constructionist methodologies for achieving AGI. || |
| |
| \\ | \\ |
| \\ | \\ |
| |
| ==== Constructivist AI ==== | ==== Constructivist AI ==== |
| | Foundation | Constructivist AI is concerned with the operational characteristics that the system we aim to build – the architecture – must have. | | | Foundation | Constructivist AI is concerned with the operational characteristics that the system we aim to build – the architecture – must have. | |
| |
| ====Examples of Task-Environments Targeted by Constructivist AI==== | ====Examples of Task-Environments Targeted by Constructivist AI==== |
| | Diversity | Earth offers great diversity. This is in large part why intelligence is even needed at all. | | | Diversity | Earth offers great diversity. This is in large part why intelligence is even needed at all. | |
| | | Desert | | | | Desert | |
| | | Ocean floor | | | | Ocean floor | |
| |
| ====Architectural Principles of AGI Systems / CAIM==== | ====Architectural Principles of AGI Systems / CAIM==== |
| | Self-Construction | It is assumed that a system must amass the vast majority of its knowledge autonomously. This is partly due to the fact that it is (practically) impossible for any human or team(s) of humans to construct by hand the knowledge needed for an AGI system, and even this were possible it would still leave unanswered the question of how the system will acquire knowledge of truly novel things, which we consider a fundamental requirement for a system to be called an AGI system. | | | Self-Construction | It is assumed that a system must amass the vast majority of its knowledge autonomously. This is partly due to the fact that it is (practically) impossible for any human or team(s) of humans to construct by hand the knowledge needed for an AGI system, and even if this were possible it would still leave unanswered the question of how the system will acquire knowledge of truly novel things, which we consider a fundamental requirement for a system to be called an AGI system. | |
| | Semiotic Opaqueness | No communication between two agents / components in a system can take place unless they share a common language, or encoding-decoding principles. Without this they are semantically opaque to each other. Without communication, no coordination can take place. | | | Semiotic Opaqueness | No communication between two agents / components in a system can take place unless they share a common language, or encoding-decoding principles. Without this they are semantically opaque to each other. Without communication, no coordination can take place. | |
| | Systems Engineering | Due to the complexity of building a large system (picture, e.g. an airplane), a clear and concise bookkeeping of each part, and which parts it interacts with, must be kept so as to ensure the holistic operation of the resulting system. In a (cognitively) growing system in a dynamic world, where the system is auto-generating models of the phenomena that it sees, each which must be tightly integrated yet easily manipulatable and clearly separable, the system must itself ensure the semiotic transparency of its constituents parts. This can only be achieved by automatic mechanisms residing in the system itself, it cannot be ensured manually by a human engineer, or even a large team of them. | | | Systems Engineering | Due to the complexity of building a large system (picture, e.g. an airplane), a clear and concise bookkeeping of each part, and which parts it interacts with, must be kept so as to ensure the holistic operation of the resulting system. In a (cognitively) growing system in a dynamic world, where the system is auto-generating models of the phenomena that it sees, each which must be tightly integrated yet easily manipulatable and clearly separable, the system must itself ensure the semiotic transparency of its constituents parts. This can only be achieved by automatic mechanisms residing in the system itself, it cannot be ensured manually by a human engineer, or even a large team of them. | |
| \\ | \\ |
| \\ | \\ |
| |
| ====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 <m>o</m> 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. \\ <m>V_te >> V_mem</m>, 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 <m>P_M</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 <m>P_M</m> may have captured their causal relationship in three alternative models, <m>M_1, M_2, M_3</m>, 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 <m>V_5, V_6</m>. | | |
| | {{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>M_1</m> and (b) <m>M_2</m>. 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>M{prime}_2</m>. | | |
| |
| \\ | |
| \\ | |
| |
| |
| |
| \\ | |
| \\ | |
| |
| ====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. | | |
| |
| \\ | |
| \\ | |
| |
| ====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) | | |
| |
| |
| \\ | \\ |
