One way to increase the intelligence of a robot might be to train it with a series of missions, analogous to the missions or levels in a video game.
In a developmental robot, the training would not be simply learning—its “brain” structure would actually change.
Biological development shows some extremes that a robot could go through, like starting with a small seed that constructs itself, or creating too many neural connections and then in a later phase deleting a whole bunch of them.
As another example of development vs. learning, a simple artificial neural network is trained when the weights have been changed after a series of training inputs (and error correction if it is supervised). In contradistinction, a developmental system changes itself structurally. It would be like growing completely new nodes, network layers, or new networks entirely during each training level.
Or you can imagine the difference between decorating a skyscraper (learning) and building a skyscraper (development).
The definition of “learning” you choose for a context obviously will impact whether these statements are true—a non-computer-science notion of learning may include much of “development.”
I mentioned neural nets as not developmental. Some might argue that’s not true especially in deep learning. In my opinion modern machine learning techniques are not biomimetic. But ML does have an analogical problem—how to update a trained model to learn something extra without ruining what it’s good at.
And there’s an overlapping problem called concept drift in which the real world data input to a deployed model changes over time making the model suck more and more.
Anyway, back to the video game style missions…
What Happens to the Robot Mind in these Missions?
Inside a robotic mental development mission or stage, almost anything could go on depending on the mad scientist who made it.
It could be a series of timed, purely internal structural changes. For instance:
- Grow set A[] of mental modules
- Grow mental module B
- Connect B to some of A[]
- Activate dormant function f() in all modules
- Add in pre-made module C and connect it to all other modules
- And so on…
Instead of (or in addition to) pre-planned timed changes, the stages could be based on environmental interactions. And I think that is actually a more useful tactic to make a robot adjust to its own morphology and the particular range of environments that it must operate and survive in. And that makes the stages more like the aforementioned missions as one has in computer games.
Note that learning is most likely going to be happening at the same time (unless learning abilities are turned off as part of a developmental level). In the space of all possible developmental robots, one would expect some mental change gray areas somewhere between development and learning.
Given the input and triggering roles of the environment, each development level may require a special sandbox world. The body of the robot may also undergo changes during each level.
The ordering of the levels / sandboxes would depend on what mental structures are necessary going in to each one.
A Problem
One problem is how to prevent cross-contamination of mental changes. One mission might nullify a previous mission.
For example, let’s say that a robot can now survive in Sandbox A after making it through Mission A. Now the robot proceeds through Mission B in Sandbox B. You would expect the robot to be able to survive in a bigger new sandbox that has elements of both Sandbox A and Sandbox B (or requires the mental structures developed during A and B). But B might have messed up A. And now you have a robot that’s good at B but not A, or even worse not good at anything.
Imagine some unstructured cookie dough. You can form a blob of it into a special shape with a cookie cutter. But applying several cookie cutters in a row might result in an unrecognizable shape, maybe even no better than the original blob.
As a mathematical example, take a four stage developmental sequence where each stage is a different function, numbered 1-4. This could be represented as:
y = f1(f2(f3(f4(x))))
where x is the starting cognitive system and y is the final resulting cognitive system.
But this function composition is not commutative:
f4(f3(f2(f1(x)))) ≠ f1(f2(f3(f4(x))))
I.e., different order of stages, different final system.
A Commutative Approach
There is a way to make an architecture that’s commutative. You might think that will solve our problem, however it only works with certain constraints that we might not want. Here’s an example:
We could require all the development stages to have a minimal required integration program. So f1(), f2(), etc. are all sub-types of m(), the master function. Or in object oriented terms:
The example here would have each mission result in a new mental module. The required default program would automatically connect this module with the same protocol to all other modules. The interface transforms the new development or learning so it will play nicely with the existing system.
So in this case it is commutative:
f4(f3(f2(f1(x)))) = f1(f2(f3(f4(x))))
But if this was the only approach it might severely limit the cognitive architecture in terms of modules acting as layers, dependencies and building blocks emerging that enable other structures to be constructed.
This might allow missions to be done in different orders, so even if the initial development worlds are in a strict order, after that it would allow more of an open world game for training. However, even though the robot’s mind might be the same for different orders of training, that doesn’t necessarily mean it’s the best architecture—I haven’t provided a way to guarantee that whatever set of modules are “grown” will not negatively affect each other.
A Pattern Solution
A non-commutative solution might reside in integration patterns. These would preserve the functionality from previous stages as the structure is changed.
For instance, one pattern might be to add a switching mechanism. The resulting robot mind would be partially modal—in a given context, it would activate the most appropriate developed part of its mind but not all of parts at the same time.
A similar pattern could be used for developing or learning new skills—a new skill doesn’t overwrite previous skills, it is instead added to the relevant set of skills which are triggered or selected by other mechanisms.
But this is a bit of hand-waving that assumes this architectural base is already there and I haven’t explained it in sufficient detail.
Afterword
I originally wrote this about seven years ago, inspired by an idea I had back in 2004 called “Growing Pains” 1S. Kenyon (2021). “Biomimetic Emotional Learning Agents,” MetaDevo blog. https://metadevo.com/biomimetic-emotional-learning-agents/. And there’s a couple more essays from that period I’m updating and posting soon. And these little cognitive architecture ideas are described by me in ways that seem like they’re still in the realm of traditional representational computational mind theory—but at some point I want to try to tackle how to tie them together with philosophical / cogsci approaches that remove dependence on traditional representations.
Anyway…a Medium article by Carlos E. Perez I saw recently provides a good quote to end on2C.E. Perez (2021). “Embodied Learning is Essential to Artificial Intelligence,” https://medium.com/intuitionmachine/embodied-learning-is-essential-to-artificial-intelligence-ad1e27425972:
The current conventional thinking is, “how do I design better architectures and algorithms?”, however, the more promising question is “how do I design better learning environments to teach intuition machines?”
