On Mon, 2002-11-11 at 14:11, Charles Hixson wrote: > > Personally, I believe that the most effective AI will have a core > general intelligence, that may be rather primitive, and a huge number of > specialized intelligence modules. The tricky part of this architecture > is designing the various modules so that they can communicate. It isn't > clear that this is always reasonable (consider the interfaces between > chess and cooking), but if the problem can be handled in a general > manner (there's that word again!), then one of the intelligences could > be specialized for "message passing". In this model the "core general > intelligence" will be for use when none of the hueristics fit the > problem. And it's attempts will be watched by another module whose > specialty is generating new hueristics.
This is essentially what we do, but it works a little differently than you are suggesting. The machinery and representation underneath the modules is identical, where each module is its own machine which has become optimized for its task. In other words, if you were making a module on chess and a module on cooking you would start with the same blank module machinery and they would be trained for their respective tasks. If you looked at the internals of the module machinery after the training period, you would notice marked macro-level structural differences between the two that relate to how the machinery self-optimizes for its task. The computational machines, which are really just generic Turing virtual machines that you could program any type of software on, use a pretty foreign notion of "computation/processing" -- the processor model looks nothing like a von Neumann-variant architecture. Despite notable differences in structure, it is really just two modules of the same machine that have automatically conformed structurally to their data environment. The interesting part is the integration of the modules. There are actually a number of ways to do it, all of which have advantages and disadvantages. One advantage of having simple underlying machinery controlling the representation of data is that all modules already deeply "understand" the data of any other module. You COULD do a "hard merge" of the cooking module with the chess module into one module, and automatically discover the relations and abstract similarities between the two (whatever those might be) without any special code, but there are lots of reasons why this is bad in practice. In implementation, we typically do what we would call a "soft merge", where the machines are fully integrated for most purposes and can use each others space, but where external data feeds are localized to specific modules within the cluster (even though these modules have access to every other module for the purposes of processing the data feed). From the perspective of external data streams it looks like a bunch of independent machines working together, but from the perspective of the machine the entire cluster is a single machine image. There are good theoretical reasons for doing things this way which I won't go into here. In short, we mostly do what you are talking about, but you've actually over-estimated the difficulty of integration of domain-specific modules (using our architecture, at least). Actually building modules is more difficult, mostly because the computing architecture uses assumptions that are very strange; I think my programmer's mind works against me some days, and teaching/training modules by example is easier than programming them directly most times. Once they are done, you pretty much can do plug-n-play on-the-fly integration, even on a "hot"/active cluster of modules (resource permitting, of course). An analogy would be how they learned new skills on-the-fly in "The Matrix". The integration is a freebie that comes with the underlying architecture, not something that I spent much effort designing. Cheers, -James Rogers [EMAIL PROTECTED] ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/
