AI, part two!
Jan. 2nd, 2013 11:15 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
davvAlright, so that's a completely impractical General Optimizer. How may one make it more effective?
This is where I spent a few days thinking, and I eventually came up with the idea of something I called an "unreasonably effective memoizer", or cache. Even on a miracle computer that could solve the compression problem I mentioned, the computer would take a very long time finding a good predictor; and then, once it has found it, would repeat that work all over again on the next cycle.
Like evolution, the predictor-generator is blind. It's a part that is very slow but sure to eventually arrive at a good result (assuming computability, etc)... again, like evolution.
So I thought that a more practical General Optimizer would have:
- A baseline that is very slow but eventually finds the right answer,
- A system that replaces slow parts with nearly as accurate much faster parts,
- A generator and store for those actual faster parts (unreasonably effective memoizer).
And though I was thinking of this in terms of general optimizers, this looked a lot like what life, in the context of evolution, ends up being. The search provided by mutation and crossover constitutes the first part. The inherent storage of past progress by genes and the selection done by, well, selection, constitute the second and third parts. As species evolve in complexity, some of the faster parts become search systems of their own. Evolution with selection cache results from blind search. Instincts cache results from evolution with selection. The mind, or at least the unconscious part of it (I'll get to that later) constitutes both faster parts (all the pattern matching stuff we've got going) and generators for such (since the mind can learn).
I spent a lot of time thinking about how the system above might be made in a computer sense. The system that replaces slow parts with nearly as accurate much faster parts seem to yield to vote logic. If some system A gets results as often as B and only sometimes errs, if we have a metasystem that assigns weights to these, A's weight will increase pretty quickly because it gets more done faster than does B. The tradeoff is that A might only be effective on what we've seen so far and break utterly when reality is shown not to be as simple as thought; then B will have to catch up before the system gets back to thinking correctly.
I also thought that to roll time up into the thing, one would make each predictor of the type that you can keep running as long as you wish and after a while, you just say "okay, what's your best guess so far?" - sort of like a computer chess player. If the computer has time to hang around, which would probably be specified in the fitness function, then the accurate module wins, but if it doesn't, then the early termination favors the faster part.
However, there's still the devil in the details of "nearly as accurate". How much time should the General Optimizer sacrifice for accuracy? Given some fast module that may or may not be accurate, it can't be certain of how accurate it is without running both the fast and slow module, which would defeat the purpose of the memoizer in the first place!
I think there's a solution (multi-armed bandit sampling) to this, but as I was exploring, I found someone else had beat me to it with a more self-consistent logic.
This is where I spent a few days thinking, and I eventually came up with the idea of something I called an "unreasonably effective memoizer", or cache. Even on a miracle computer that could solve the compression problem I mentioned, the computer would take a very long time finding a good predictor; and then, once it has found it, would repeat that work all over again on the next cycle.
Like evolution, the predictor-generator is blind. It's a part that is very slow but sure to eventually arrive at a good result (assuming computability, etc)... again, like evolution.
So I thought that a more practical General Optimizer would have:
- A baseline that is very slow but eventually finds the right answer,
- A system that replaces slow parts with nearly as accurate much faster parts,
- A generator and store for those actual faster parts (unreasonably effective memoizer).
And though I was thinking of this in terms of general optimizers, this looked a lot like what life, in the context of evolution, ends up being. The search provided by mutation and crossover constitutes the first part. The inherent storage of past progress by genes and the selection done by, well, selection, constitute the second and third parts. As species evolve in complexity, some of the faster parts become search systems of their own. Evolution with selection cache results from blind search. Instincts cache results from evolution with selection. The mind, or at least the unconscious part of it (I'll get to that later) constitutes both faster parts (all the pattern matching stuff we've got going) and generators for such (since the mind can learn).
I spent a lot of time thinking about how the system above might be made in a computer sense. The system that replaces slow parts with nearly as accurate much faster parts seem to yield to vote logic. If some system A gets results as often as B and only sometimes errs, if we have a metasystem that assigns weights to these, A's weight will increase pretty quickly because it gets more done faster than does B. The tradeoff is that A might only be effective on what we've seen so far and break utterly when reality is shown not to be as simple as thought; then B will have to catch up before the system gets back to thinking correctly.
I also thought that to roll time up into the thing, one would make each predictor of the type that you can keep running as long as you wish and after a while, you just say "okay, what's your best guess so far?" - sort of like a computer chess player. If the computer has time to hang around, which would probably be specified in the fitness function, then the accurate module wins, but if it doesn't, then the early termination favors the faster part.
However, there's still the devil in the details of "nearly as accurate". How much time should the General Optimizer sacrifice for accuracy? Given some fast module that may or may not be accurate, it can't be certain of how accurate it is without running both the fast and slow module, which would defeat the purpose of the memoizer in the first place!
I think there's a solution (multi-armed bandit sampling) to this, but as I was exploring, I found someone else had beat me to it with a more self-consistent logic.