160 likes | 277 Vues
This paper presents a novel programming paradigm tailored for control systems with high levels of existential autonomy. It contrasts natural intelligence with manageable complexity, advocating a constructivist approach where systems have the capability to delegate aspects of their own construction. The authors detail the characteristics of Replicode, a state-based language focused on data-driven computation, concurrent execution, and model hierarchy, essential for effective operation in autonomous systems. Applications of this paradigm are illustrated through the HUMANOBS project, which involves sociocommunicative skill learning in machines.
E N D
HUMANOBS Toward a programming paradigm for control systems with high levels of existential autonomy Eric Nivel, Kristinn R. Thorisson Reykjavik University / Icelandic Institute for Intelligent Machines AGI 2013 - Beijing – August 2013
Overview > A G I: domain independence scalability (in terms of complexity) > Natural intelligence vs manageable complexity > Constructivist approach: delegate to the system (some of) its own construction > Used for S1, an AERA based system, that learns socio- Communicative skills by observing people (HUMANOBS EU-funded FP7 project)
Overview > Main characteristics of Replicode: - Based on a non-axiomatic logic: real-valued and time constrained. - Data-driven, computation based on pattern-matching. - Stateless executable code (models, composite states, programs). - No explicit ifs, loops, OR, AND. - All executable code run concurrently: massively parallel - Code can be an input for some other code. - Code can be active or inactive.
Overview > Main characteristics of Replicode: - A kind of functional language, LISP-like syntax, not typed. - Data can be salient or not. - Data and code (objects) have a limited life time (resilience). • Once produced, objects cannot be modified. • Objects live in workspaces (groups), possibly in several of them. • Groups control the lifecycle and state of objects at various frequencies. - Extensible set of operators; hooks for custom C++ code (icpp_pgm).
Dynamic Model Hierarchy > A model captures a causal relationship (deduction, i.e. prediction). > A model can thus be used to perform abductions (ex: sub-goaling). > A model is bidirectional and performs deductions and abductions concurrently. A(X,Z,W) B(X,Y,Z) M0 Forward: a predicted b and iM0(x,z,w,y); Y can be a function of X, Z and W. Backward: goal b sub-goal a; W can be a function of X, Y and Z Predicted b and sub-goal a are monitored, success of M0 is assessed in due time
Dynamic Model Hierarchy > Indirect coupling / pattern affordances. M0: [A B] M1: [B C] M2: [C D] M0 M1 M2 M3: [E C] M4: [C F] M5: [|G C] M3 M4 M5 Forward: a predicted b predicted c predicted d Backward: goal d sub-goal c sub-goal b sub-goal a sub-goal e sub-goal |g
Dynamic Model Hierarchy > Pre-conditions. iM0 = instance of M0, NOT M0 itself IF M0 fires (at some time), it will succeed M0: [A B] M2 M1: [C iM0] Pre-conditions (weak) - OR M1 M2: [|D iM0] M0 M3: [E |iM0] Pre-conditions (strong) - AND M3 M4: [|F |iM0] M4 IF M0 fires (at some time), it will fail Execution of a model, success/failure thereof ARE REGULAR (INTERNAL) INPUTS.
Dynamic Model Hierarchy > Post-conditions. M0: [A B] WHEN M0 has fired (at some time) M6 M5: [iM0 C] M0 M6: [|iM0 D] WHEN M0 has not fired (at some time) M5 M15 M7: [iM12 iM0] M12 M10 M8: [iM13 |iM0] M7 Combinations M9: [|iM14 iM0] M0 M8 M10: [|iM15 |iM0] M9 M13 M14
Dynamic Model Hierarchy • > Control hierarchy > Dynamic: models are built/deleted dynamically. predictions I/O goals
Dynamic Model Hierarchy > Dynamic: models are activated accordingly to their success rate: under a threshold, no execution. > Inputs hold a confidence value (saliency): under a threshold, no input. > pred.cfd=input.cfd*modl.sr (likelyhood for the pred to be true). > goal.cfd=super-goal.cfd*model.sr (likelyhood for a goal to succeed).
Dynamic Model Hierarchy > Given limited resources, only the paths consisting of the best models will be followed. I/O
Dynamic Model Hierarchy > Drives and top-level models are hand-coded. > Drives are non-observable states. > Drives are re-generated dynamically (defined by the programmer). > Top-level models are given ways to satisfy drives. I/O drives top-level models learned models
Dynamic Model Hierarchy > States: atomic or composite; constitute the patterns found in models. > States can be composed of other states state hierarchy. > Reflectivity: internal operations are reflected as states. Composite states can encode concepts in an operational fashion. > In addition to a control hierarchy (procedural) we also have a concept (structural) hierarchy. A(X,Z,W) B(X,Y,Z) C(X,T) S0 A, B and C are synchronous states synchronous: hold within a common time interval
Dynamic Model Hierarchy > Indirect coupling: models are not hardwired to each other. They are coupled via events in the workspace. > Pattern affordance. > Control hierarchy: affordances, pre- and post-conditions. > Dynamicity: models are added/deleted/activated continuouslsy. > Concept hierarchy: states encode concepts at different levels of specification.
Logic > Real valued: confidence (not a probability) in [0,1]. > Time constrained: time interval [after, before[; bounds in µs. > Inference rules govern: - Deduction (forward chaining) - Abduction (backward chaining) - Induction - Commitment (resolution of simulation)