I recently discovered a woman named MonicaAnderson? who researches ArtificialIntelligence. She explains ideas about AI with a certain fierceness and lucidity that has really caught my attention. Many ideas resonate with things we have spoken about in CategoryReasoning.
Honestly, it would take a long time to write out all her ideas – I’ve spent a few hours watching her videos, thinking about the ideas, and reading her essays. I’ve corresponded with her a few times.
But I will attempt to explain a few of them here:
“Model Free Methods” --
This is her term (which this page is named after) for methods (practical things that can be done, steps that can be taken, “stuff that can be programed”) that do not rely on a model.
She points out that the vast majority of our software systems are model dependent. Not just our software system, but our entire process of machining, our entire process of human machining, our entire vision of education and learning, and so on and so forth. Everything is based on a paradigm of (A) figuring out what the machine or formula is, and then (B) optimizing the *$(^ out of that formula.
Her argument (which she expands in great detail) is that – with Artificial Intelligence, this can never work. Because of step A: figuring out what the machine of formula is.
And step (A) is what AI really is or should be about.
Here she reverses things and coins the term: “Artificial Intuition.”
The effort really should be to make systems that work holistically, rather than in the reductionist paradigm. Artificial Intuition is the construction of systems that work holistically and intuitively, rather than in terms of reduced structures, mechanically.
The objections she hears from people are: “Wait, that’s ridiculous. We have all these methods and tools for reduction, but there are no methods or tools for holistic systems.”
Here’s where she turns around and gets very interesting. She says, “No, actually, there are, and we do have them. We just haven’t been paying very much attention to them.”
She then goes on to enumerate several methods and ways of going about things and demonstrating with solid examples. “Why aren’t we programming like this? Hello?”
She calls the methods: “Model Free Methods.” (Per the title of this page.) That’s because these are methods that do not require a model in order to work in a domain.
For one example, she says, “Try something. Anything.”
But that’s exactly it. Very simple. She says, “In practically any situation, you can just try something, and see if it works. No matter how stupid your system is, no matter how little capacity it has, you can apply this principle.”
Now, for the programmers here – when was the last time that you wrote in your code a routine that “Tries something, anything,” just working at random. ..? I tell you, maybe it’s just me, but in my 20 years of programming, I think I may have done this just a precious few times. I am hard pressed to think of examples. Of course, there are “try: except:” blocks, but those aren’t “try anything, except everything” blocks. And those “try-except” blocks are conceived within very narrow, very model-dependent ways.
The place where we do see “try anything” though, in the software world, is in: GeneticAlgorithms?, and in: NeuralNetworks. But we don’t need to limit our explorations to just these two fields. (More on exploring the application of Model Free Methods in a section or two down.)
Another example she gives of Model Free Methods, she calls “Table Lookup.”
That is, compile a huge table of what you’re seeing, and then what you saw after it. When you’re wondering what you think is about to come up, just consult the table.
Very stupid, yes, but it works.
She says, “AN methods are very little in terms of code, but require a lot of memory.”
She describes a vision of PatternRecognition that goes like so:
She emphasizes that the patterns are the understandings of your system.
I messaged her and told her that I was trying to apply her ideas, but was having trouble trying to connect what was happening in my connectionist or pattern or memory systems, with actual usable output.
“Don’t worry about output. Rather, look for interesting formations in data.”
This message from her woke me up: The idea is not to design artificial intelligence systems, but rather, to find them, to smell them out. If you’re designing, you’re probably going in the direction of models. Rather, it is like we want to use model-free methods as fishing lures into worlds of data, and then see: where do we get tugs? Where do we get interesting responses?
She also supports the idea that we should be creating systems that are inspired by biological methods, biological systems: If it looks like a simulation of a biological process, it’s probably a good idea. If it doesn’t look like a simulation of a biological process, it probably isn’t.
I tried 3 systems in the course of a day.
The first system was a connectionist-like system. The imagination was of a network that would come to recognize the “feel” of data, the “feel” of the flow of events. The details are somewhat complex, but basically, as letters from the input stream came in, nodes would either find or assign connections that matched the input, and then groove in an etching based on the signal. I thought it would probably be over-run by spaces, and, … Well, that’s actually what happened. I thought that, with enough time, the random assignments would work out so that the system found it’s “groove” so to speak – but that didn’t actually happen. The network was just flooded with spaces, and sensible patterns never took shape. (I know, because: I brute forced a lot of complex searches to see if actual words and such showed up. They did not.)
The second system was very different. It was much, much, much simpler:
Basically, “Count up instances of random sub-samples of the text, and sort by frequency.”
The results of this actually surprised me: With just this, I found that keywords (in programming code) and frequent words (in English text) surfaced pretty quickly. There was detritus too: key words with spaces in front or behind them, and such. But I saw that it did locate a lot of pretty useful things, and by a crazy easy method. One interesting find was the recognition of “self.” (self with a period behind it) as a common pattern in Python code.
The third system was more complex, and an extension of the 2nd. I didn’t finish it, but what I wanted to do was create match objects where the match objects were found, and then make match objects that match other objects allowing for 1 variation (missing, present, repeated, alt.,) within the pattern. My day ended before I could finish, but I’m carrying the design in my head, and hope to implement it some day.
So perhaps the key ideas here are: