From: Ben Goertzel (firstname.lastname@example.org)
Date: Sun Mar 03 2002 - 15:31:27 MST
> (Referring to a transactional paradigm for AI)
> This is same conclusion I came to when 'playing' with AI designs. Once I
> got down to actually imagining how I was going to monitor, to debug, to
> adjust the parameters on-the-fly, to recover-from-failure, etc.
> ... well, a
> lot of unworkable 'mind' ideas got tossed out. What was left had an - how
> can I say it - unglamorous overhead. But I thought it was *doable*.
Yup. So one winds up with a multilayered design approach. An unglamorous,
contemporary-software-engineering-ish layer, and then on top of that, a
layer that does implement the structures and dynamics of mind. For us to
get the relationship and interaction between these layers "right" (for our
AI design) took a long time.
> > Of course, the transaction architecture is just a start, right?
> Yeah... but an important start. Without that start, you would
> just have to
> backtrack and retrofit everything once you tried to 'go distributed'.
Yes, because of our past experience building a distributed Webmind, now we
have built our 1-machine Novamente in such a way that only a very small
number of objects will need to be modified when Novamente goes the way of
Webmind and gets distributed...
> > The bottom line seems to be: No one is going to supply an off-the-shelf
> > testing/monitoring package suitable for distributed Real AI
> purposes. We
> > will have to build one ourselves.
> Yep. A "Console" for Real AI. Gotta have it.
I agree that an AIConsole or something like it is a must-have, and we had a
graphical tool like this for use with the Webmind AI Engine. It was very
cool, and made playing with the system much easier. ("Webmind Explorer", we
What we have now isn't exactly a AIConsole but serves a similar purpose. We
call it wmshell (should be nmshell I guess, but the name is historical ;).
It's a Linux shell customized for experimenting with Novamente. So you can
send commands to a Novamente instance in real-time, get information back,
In our architecture, one would implement a graphical AIConsole by having it
issue and receive wmshell commands, I suppose.
> It would be a good idea to make this as 'general' a solution as
> possible, to
> allow flexibility in adapting as our AI theories of 'what works'
> get tested
> (and thrown out 8D).
Well, my main point in this regard is: The first version of a tool like this
is inevitably going to be only half-usable.
It's *interaction with the developers using the tool in the context of
creating and running and debugging an AI system* that will allow the second
version to be really good.
So, a *general* tool of this type will only be creatable if, while creating
it, there are *teams associated with more than one AI project* actively
using the tool.
Another way to say this is: The detailed requirements for such a tool are
hard to articulate. They're essentially *impossible* to articulate until
one has a largely-designed, partially-completed AI system on one's hands,
demanding the tool for its development. And even so, one will always fail
in articulating them completely at first; new and important requirements
will always come out in the course of using the tool's first version.
If it were possible to coordinate the development of an AIConsole between
two Real AI projects ... well, that might be a bigger miracle than actually
creating Real AI ;) ... but who knows!!
On a less nitty-gritty level, Eliezer and I have talked before about
creating a series of "IQ tests" for different phases of seed AI development,
which would be applicable to both of our AI systems. I've also talked to
Shane Legg, currently involved with Peter Voss's Adaptive Intelligence
project, about this. This seems to me more likely to happen than the
development of a general-purpose testing tool, but... who knows... ;>
> Not to mention it being easier to start a commercial
> off-shoot of the product if it is coded fairly generally.
Well, I have enough painful business experience to know that making a
commercial product to be broadly marketed is a whole different task from
building a tool for use within 1 or 2 or 3 particular projects....
However, I agree that if a specialized AIConsole tool is well-built, it may
be possible to take core components of it, and use them to fill out the back
end of a subsequent product, whose overall design is based on an analysis of
the requirements of a broader range of customers.
Generally, though, starting a business based on a technology rather than a
concretely observed pressing customer need is a recipe for trouble (of a
type with which I'm very familiar!)
> > Hence, it seems likely that each would-be Real AI project, as it goes
> > distributed, will have to tackle this problem on its own!
> The sooner we tackle it the better IMO. You mentioned many times, when
> recounting the difficulties/fun of the Webmind project, that 'parameter
> tuning' was difficult and time-consuming. The Console concept is
> just-the-thing to make this easy(ier). You could also use it to
> at the models with thousands of test scenarios. And as a
> debugging tool: to
I agree, this stuff is important. Our wmshell tool is a start, for our
specialized purposes, but we're well aware that it's only a start!
-- Ben G
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:37 MDT