Are AI algorithms capable of self-repair?

Question

Do AI algorithms exist which are capable of healing themselves or regenerating a hurt area when they detect so?

For example: In humans if a certain part of brain gets hurt or removed, neighbouring parts take up the job. This happens probably because we are biologically unable to grow nerve cells. Whereas some other body parts (liver, skin) will regenerate most kinds of damage.

Now my question is does AI algorithms exist which take care of this i.e. regenerating a damaged area? From my understanding this can be achieved in a NN using dropout (probably). Is it correct? Do additional algorithms (for both AI/NN) or measures exist to make sure healing happens if there is some damage to the algorithm itself?

This can be particularly useful in cases where say there is a burnout in a processor cell processing some information about the environment. The other processing nodes have to take care to compensate or fully take-over the functions of the damaged cell.

(Intuitionally this can mean 2 things:

• We were not using the system of processors to its full capability.
• The performance of the system will take a hit due to other nodes taking over functionality of the damaged node)

Does this happen in the case of brain damage also? Or is my inferences wrong? (Kindly throw some light).

NOTE : I am not looking for hardware compensations like re- routing, I am asking for non-tangible healing. Adjusting the behavior or some parameters of the algorithm.

Answer 1

Good question. It is related to the genetic algorithm concept, automated bug detection, and continuous integration.

Early Genetically Inspired Algorithms

Some of the Cambridge LISP code in the 1990s worked deliberately toward self-improvement, which is not the same as self-repair, but the two are conceptual siblings.

Some of those early LISP algorithms were genetically inspired but not pure simulations of DNA mutation with natural selection through sexual reproduction. A few of these evolution-like algorithms evaluated their own effectiveness based on a fixed effectiveness model. The effectiveness model would accept reported objective metrics at run time and analyze them. When the analysis returned an assessment of effectiveness below a minimum threshold, the LISP code would perform this procedure.

• Copy itself (which is easy in LISP)
• Mutate the algorithm in the copy according to some meta-rules
• Run the mutation in parallel as a production simulation for a while
• Check of the effectiveness of mutation out performed its own

If the mutation was gauged as more effective, it would perform four more selfless steps.

• Make a record of itself
• Attach its own performance for later meta-rule use
• Load the mutation it created in its own place
• Perform apoptosis

Unlike biological apoptosis, apoptosis in these algorithms simply pass computational resources and run time control to the mutation that was loaded.

This procedure was and probably still is easier in LISP than in other languages, although lovers of other languages would argue endlessly that point.

Extensions of Continuous Integration

This is also the closed loop continuous improvement strategy intended when bug reporting is integrated with continuous integration development platforms and tools. We see extensions of continuous integration in the feeding of bug lists from automated detection, especially for crashes, in many applications, frameworks, libraries, drivers, and operating system today. Many of the elements of closed loop self-repair are already in general practice among the most progressive development teams.

The bug fixes themselves are not yet automated in the way researchers were attempting in the LISP code above. Developers and team leaders are following a process similar to this.

• Developer or team lead associates (assigns) bug to developer
• Developer attempts to replicate the bug with the corresponding version of the code
• If replicated, the root cause is found
• A design for a fix occurs at some level
• The fix is implemented

If continuous integration and proper configuration management is in place, at the point when a commit of the change to the team repository occurs, it is applied to the correct branches and the test suite of unit, integration, and functional tests is run to detect any breakage that the fix may have caused inadvertently.

Several Pieces of Full Automation are Already in Use

As one can see, many of the pieces are in place for automatic algorithm, configuration, and deployment package self-repair. There are even projects underway in several corporations to automatically create functional tests by recording user behavior and user answers to questions like, "Was this helpful?"

What is Missing

What needs further development to more completely see full life cycle self-improving and self-repairing software?

• Automatic bug replication
• Automatic unit test creation
• Automatic repair design
• Automatic creation of code from design

Next Steps

I suggest that the next steps to be done are these.

• Assess work already done on the four missing automations above
• Review the LISP procedure that was perhaps shelved in the 1990s, or perhaps not, since we cannot see (and should not see) what was classified or made company confidential)
• Consider how the machine learning building blocks that have emerged within the last two decades may help
• Find stakeholders to provide project resources
• Get working

A Note on Demand, Ethics, and Technological Displacement

Truth be told, the quality of software was a problem in the 1980s, 1990s, 2000s, and 2010s. Just today, I found over a dozen bugs in software that is considered a stable release, when performing some of the most basic functions the software was designed to do.

Given bug list sizes, just as accidents make the question of whether humans should be driving cars questionable, whether humans should maintain software quality is questionable.

Humanity has survived replacement in a number of things already.

• Arithmetic with a pencil and eraser is gone
• Professional farming with garage tools is gone
• Creating advertising mechanicals with Exacto knives is gone
• Sorting mail by hand is gone
• Communicating by horse-back courier is gone

Few software engineers are happy just fixing bugs. They seem to be happiest creating new software filled with bugs that someone else is supposed to fix. Why not let that someone else be artificial?

Answer 2

Yes, this was an active area of research in a number of different AI fields.

Probably the most directly related work is Bongard, Zykov & Lipson's self-repairing robots from the early 2000's.

There's some more recent work from Mark Yim that you can see here too.

There are lots of different ways to do this, but Bongard et al's approach was probably the most elegant. The basic idea was to frame it as a learning problem: the robot is able to learn the shape of its body by performing controlled experiments. When the body is damaged, the robot can detect that it's body has changed shape (sensors don't report the expected values when it tries to move), perform new experiments to determine the extent of the damage, and then generate new movements that work around the damaged area. Lipson covers the basics of this system very briefly in this video.

The more modern system uses a similar approach, but tries to repair its body, rather than working around the damage. It's got an internal model of what it's body should look like, and then a set of cameras that help it locate the various pieces and move them to reassemble.

Dropout is sort of a similar idea, but dropout is usually done to encourage redundancy during training, which can help a model avoid overfitting. It's usually not done explicitly to heal a damaged system, although it would make a system more resistant to damage in the first place.

Answer 3

The question and the example are a few contradictory.

The example is about a physical brain damage. Computer systems with the ability to self-repair exists from 1970's. They can repair a damaged disk (RAID), replace a CPU by an idle one (active/passive), mark faulty memory blocks, redirect network traffic from broken links to available ones, ... nowadays near than all hardware failures are covered.

However, the question is about "algorithms capable of healing themselves", that has a parallelism in "persons capable of healing from a psychological problem".

Like in the case of persons, it depends of the problem, and the amount of recovery expected.

Some easier cases are:

• Lots of non-AI systems has the ability to re-synchronize, auto-calibration, ...

• Any minimal intelligent system can "stop" if it detects it is producing continuous wrong results.

Going a step forward, thinking in ML (Neural Nets, ..) we can remark that all unsupervised learning machines can recover from a misalignment of their parameters, just re-executing the learning process (or continuously executing it).

Finally, we could ask "can a machine recover from an error in his reward function" ? And, at this point, my answer is "I do not known any system able of that, because they have no common sense".