Last modified on Wed Apr 25 22:54:25 2001.
| NOTE: | Since the creation of the Singularity
Institute in July 2000, much of this document has become obsolete.
In particular, the whole concept of starting an AI industry may turn out
be unnecessary; the Singularity Institute does not currently plan to develop
via an open-source method; the entire technological timeline has been compressed
into three stages of a seed AI designed by a private research team; and,
of course, most of the sections dealing with how to establish a Singularity
Institute are obsolete.
These strategic changes are largely due to improvements in the understanding of seed AI - see Coding a Transhuman AI 2 - which may make it possible to develop a seed AI using fewer resources than previously thought. If the problem of seed AI turns out to be less tractable than expected, the strategies described here would still be a valid fallback plan. |
This document comes in two versions, monolithic and polylithic. You are reading the monolithic version. This version of the document is intended for continuous reading, or downloading to local disks. The polylithic version of the document is intended for incremental reading and light browsing.
This document was created by html2html, a Python script written by Eliezer S. Yudkowsky.
Last modified on Wed Apr 25 22:54:25 2001.
May you have an enjoyable, intriguing, and Singularity-promoting read.
Eliezer S. Yudkowsky, Navigator.
The Plan to Singularity ("PtS" for short) is an attempt to describe the technologies and efforts needed to move from the current (2000) state of the world to the Singularity; that is, the technological creation of a smarter-than-human intelligence. The method assumed by this document is a seed AI, or self-improving Artificial Intelligence, which will successfully enhance itself to the level where it can decide what to do next.
PtS is an interventionist timeline; that is, I am not projecting the course of the future, but describing how to change it. I believe the target date for the completion of the project should be set at 2010, with 2005 being preferable; again, this is not the most likely date, but is the probable deadline for beating other, more destructive technologies into play. (It is equally possible that progress in AI and nanotech will run at a more relaxed rate, rather than developing in "Internet time". We can't count on finishing by 2005. We also can't count on delaying until 2020.)
PtS is not an introductory-level document. I am assuming you already know what a Singularity is, why a Singularity is desirable, what an Artificial Intelligence is, and so on. For more information about the Singularity, see An Introduction to the Singularity.
As with any other document I publish, I guarantee no perfection and claim no authority; I only believe that publishing the document will prove better than not publishing it. As these words are written, PtS is the very first attempt to sketch a complete path to Singularity; it has no competition. If you're reading these words in a time substantially after 2000, I hope you will appreciate the historical context.
The future sketched in PtS is not intended as speculation. I intend to spend my life making it real. If you believe that the Singularity is a worthwhile goal, and you're interested in making it happen, consider joining the Singularitarian mailing list.
| NOTE: | Since the creation of the Singularity Institute in July 2000, much of this document has become obsolete. See note above. |
1: Vision is a high-level introduction to the PtS plan; it describes the top-level goals and the reasons for the top-level goals. Whether you plan to browse or read straight through, start here.
2: Technology sketches the sequence of technologies leading up to the Singularity. (Obviously, this section is not intended to contain a complete technical whitepaper for the next ten years. The technologies are introduced, rather than explained. Nonetheless, where the technical architecture has consequences for the PtS strategy, I get technical.) 2.1: Component technologies introduces the Aicore architecture for artificial intelligence and the Flare programming language. 2.2: Technological timeline describes the specific path taken to Singularity, although the purpose of such early technologies as Flare may not become clear until 2.2.9: Self-optimizing compiler.
3: Strategy describes how the PtS goals will be accomplished. In each category, a "timeline" section describes what will be done in the short-term, mid-term, and long-term. Other sections discuss miscellaneous questions of strategy, or how to deal with problems that are likely to crop up. For maximum reading ease, read in given order. 3.1: Development strategy discusses the task of creating the necessary technologies. 3.2: The Singularity Institute discusses the administrative backbone required. 3.3: Memetics strategy discusses the tasks of finding help, not creating opposition, and the art of writing about the Singularity. 3.4: Research strategy discusses how to handle any further research required. 3.5: Miscellaneous contains issues that affect general strategy (3.5.1: Building a solid operation) or details that don't fit under any specific heading (3.5.3: If nanotech comes first).
4: Initiation describes what has to be done to get started, the people needed to do it, and how much it's all going to cost.
Appendix A: Navigation describes how the content of PtS was determined by the structure of the spectrum of possible futures. For example, this section includes the reason why developing AI is easier than developing intelligence enhancement, why 2010 is the target date, and why 2005 would be better.
Those of you who are just in it for the future shock will probably enjoy 3.5.3: If nanotech comes first and 2.2.9: Self-optimizing compiler through 2.2.14: Transcendence.
| NOTE: | Since the creation of the Singularity Institute in July 2000, much of this document has become obsolete. See note above. |
The Singularity, by the old definition (1), is the creation of greater-than-human intelligence. The Singularity, as the goal pursued by Singularitarians, is the existence of at least one transhuman with enough power to prevent catastrophe and take the next step into the future. Failure, as a negative goal, is any event that sterilizes Earth and destroys all intelligent life in the Solar System, thus permanently preventing the Singularity. I think most of us want to share the Singularity with as much of humanity as possible, so widespread war and billions of deaths would probably count as at least a partial failure.
The best candidate for creating the Singularity is Artificial Intelligence; the technology most likely to wipe out the human race is nanotechnology. (See Appendix A: Navigation.) To win, we need to create an AI. To avoid losing, we need to outrace nanotechnology.
We must create a "seed AI", initially dumber than human, but capable of redesigning itself to increase intelligence, and re-redesigning with that increased intelligence, until transhuman ability is reached. (See the page Coding a Transhuman AI.) We must ensure that the computing hardware exists to run that AI, and that we have access to that hardware. We must do all this before nanotechnological warfare becomes capable of completely destroying humanity, and ideally before nanotechnological warfare has wiped out a substantial fraction of the human race (2). To have a good chance of outracing nanotech, we should plan to develop a seed AI by 2010. (3).
We need to develop an AI fast, with the same kind of hypergrowth seen in the creation of the Web - what's known as "Internet time". A private effort probably won't be enough to get that kind of speed; it'll take an industry. As with the creation of the Web, only the core technologies should be developed by private teams, or in this case, Singularitarian efforts. The flesh, the content, should be distributed across the shoulders of a planet. Even the core architecture should be an open-source effort.
The primary thread of PtS deals with creating an open-source AI architecture, an AI industry, a seed AI, and accessible hardware. Other efforts are required to support these goals and create an environment favorable to success. We should encourage a community spirit in Silicon Valley that actively favors a Singularity, and encourage an atmosphere in the wider population (and politics) which either favors a Singularity or will not take action against it. A nonprofit organization - the Singularity Institute - is needed to fund the initial prototype, provide Web and legal infrastructure for the open-source effort, provide funding for the final seed-AI development project, and provide funding and an administrative nucleus for other efforts.
In my visualization of AI development, a tremendous amount of original, brilliant coding and architectural design is required to create a seed AI. It's not a matter of a few simple reductive principles and a lot of hardware, or even a few simple principles and a lot of knowledge, as previous paradigms in AI have usually claimed. This is understandable, given that the paradigms of modern AI were born long before the Internet era, in the 50s, 60s, 70s, and occasionally 80s. The AIers who built the field planned on a scale of small projects, and tried to implement those projects on computers that modern pocket calculators would sneer at, so it isn't surprising that they adopted theories of cognition that promised success with those limited resources.
Even if it turns out that artificially designing a self-improving mind is easier than biologically evolving a non-reflexive one, coding a mind is likely to be a huge project. An effort that attempted to "go it alone" would spend all its resources on writing, debugging, and testing a few simple algorithms, and developing rudimentary features of the tools to write the tools. A true mind is simply too complex to be developed by any one project with a realistic level of funding.
The PtS plan seeks to farm out the effort of AI development. One of the primary methods is developing the core AI architecture - Aicore - through an open-source effort, as with Linux, Apache, Python, Perl, and many other names of honor in the computing industry.
| DEFN: | Open-source: Software in which the source code is free, as is the software itself. Open-source software is partially or wholly developed by a distributed group of users/testers/developers working with the open source code and submitting changes to an open forum. See the Open Source Definition for the formal definition, The Cathedral and the Bazaar for an early introduction, and The Magic Cauldron for a later and more rigorous analysis of the economics. |
By open-sourcing the core architecture, we will reduce the amount of Singularitarian resources required to build, test, and debug (especially test and debug) the core tools. Building an AI is likely to involve a number of fundamental programming design innovations. (See 2: Technology.) As a closed effort, each brilliant new idea represents a brilliant new drain on resources. As an open-source project, each brilliant new idea, if the idea is brilliant enough, will attract more programmers to the project. Open source acts as a force multiplier, particularly where bright ideas are concerned.
The Cathedral and the Bazaar also notes the usefulness of open-source for exploiting the design space; that is, open-source users are capable of coming up with bright ideas, useful new features, and even more elegant design architectures. Open-source users contribute intelligence as well as labor, and to build an AI, we'll need all the intelligence we can get.
Of course, open source also requires a pool of users. It might be possible to attract a sufficient programming population through the sheer coolness factor of open-source AI, not to mention the high altruism of the Singularity itself. Every true hacker (4) wants to code an AI and save the world; it's part of the job description. But I don't intend to rely on that, which brings us to 1.2: Creating an AI industry.
The open-source AI architecture is only half of the equation; we may compare the architecture to the HTML and TCP/IP protocols underlying the World Wide Web. The content is another question, and that question is: "What is the AI doing?"
Eurisko, designed by Douglas Lenat, is the best existing example of a seed AI, or, for that matter, of any AI. (If you haven't heard of Eurisko, please see footnote (5).) If "promising" performance is defined as "doing at least one thing a human hasn't done", this being the characteristic that creates the potential for profitability, then Eurisko exhibited promising performance in areas from game-playing to VLSI circuit design.
I believe this level of intelligence and generality can be exceeded, or at least matched, by the AI design paradigms assumed in PtS. (See 2.1.1: The "Aicore" line and Coding a Transhuman AI.) Even matching Eurisko should be enough for the first stages. (If Eurisko's source code were available, there'd be a thousand programmers playing with it right now.) With luck, the existence of an Aicore architecture will be enough to create the potential for profitable performance in hundreds or thousands of domains - some significant fraction of the domains encountered by modern-day IT (7).
However, trying to replace human experts or match human creativity - historically the great failed venture-capitalist-attracting promise, the shiny sparkly minefield of AI - is not the task I would choose for creating an AI industry. I believe in mundane AI. (8). I think that the New Promise should be significantly decreasing the cost of IT development; AI as a quiet, behind-the-scenes programming tool. First as an intelligent debugger to provide the "codic cortex" humans lack; later as a part of the core architecture of the program, so that the language itself has a certain amount of common sense. (See 2.2: Technological timeline.)
| The New Promise of AI |
| The use of artificial intelligence can reduce the cost of software development, speed the development process, improve reliability, and increase the usability of the software. AI can provide a framework for programming, assist with debugging, and simplify program maintenance. |
I believe that source code is the natural domain of AI, the ancestral savannah of computer-based intelligence, and that an AI with domain-specific intelligence targeted on programs should be an enormous aid to the human programmer. After all, humans don't have a codic cortex, so we've always been in the position of a human without a visual cortex drawing a picture pixel by pixel. A human programmer is a blind painter (9).
IT presently accounts for half of all capital expenditures in the United States. A significant reduction in development costs should be more than enough profit-motive to fuel the widespread adoption of our AI. It should be enough profit-motive to fuel the creation of an industry centered on our AI, in the same way that Linux has changed from a free operating system to an industry centered on a free operating system.
Once an AI industry exists, the development effort should have a wider pool of open-source volunteers and more contributed improvements. There'll also be the profit-motive to develop better AI - better applications for our architecture - with many private organizations trying new ideas. And finally, if the AI has the capacity to improve itself, learn, or develop heuristics, there'll be much more computing power devoted to generating shareable improvements. In that helpful environment, doing the core research to move along the timeline should be more like flying and less like wading through molasses. We'll be able to develop the potential for a group of features, release the potential, and get back the features.
This vision has several technological consequences:
The larger our support base, both of active Singularitarians and of people who are kindly inclined, the better our chances of getting to the Singularity. As yet, there are no groups directly opposing our immediate purposes; we should try, as much as possible, to keep it that way. These are the two goals that need to be served by memetic efforts.
The memetic task is further complicated by the number of audiences being targeted. We need to target Internet tycoons and programmers (particularly open-source programmers) with the full Singularitarian meme. We should try to target the rest of the technophilic populace, from SF fans to the readership of Wired, with Singularity-ownership memes. We need to worry about the reactions of CEOs, Greenpeace, politicians, TV reporters, teens, journalists, televangelists, honest religious fundamentalists, the middle class, truck drivers who've lost their jobs, "disadvantaged youth" and the "urban poor". And that's just in America.
The circumstances needed for the easiest, safest path to Singularity can be compactly stated: We need rich Singularitarians in Silicon Valley, open-source programmers who believe in seed AI, CEOs who don't object to using AI and are even attracted by the sparkle, supercomputing vendors who either believe or turn a blind eye when the time comes to run the Last Program, no interference from politicians, no fad television programs about the Singularity, and citadels of technophobia worrying about something else.
Is the safe path possible? Probably not. It relies on nobody outside the technophilic minority hearing about the Singularity, believing it if they did, or spreading the meme if they didn't. That's a pretty fragile situation. The Singularity is an awesomely powerful meme, and I have the feeling that if we don't spread it, someone else will. The ethical question involved in leaving "the average guy" out of humanity's victory is thus somewhat moot. While targeting only technophilic audiences may remain the wisest use of resources in the short term, everyone else (13) will find out eventually.
The "But someone will" rule also simplifies the oft-asked question of "Shouldn't we tone down the Singularity meme, for fear of panicking someone?" In introductory pages and print material, maybe. But there's no point in toning down the advanced Websites, even if technophobes might run across them. Given the kind of people who are likely to oppose us, we'll be accused of plotting to bring about the end of humanity regardless of whether or not we admit to it. (14).
Only in the early stages will we be able to choose the material presented and the target audience; in later stages, if we're not fortunate enough to manage a rapid, quiet Transcendence, we'll be dealing with a rapidly evolving memetic environment containing every kind of idea about the Singularity. We can take for granted that the negative memes we're afraid of will come into existence and propagate. We have to either get there first with positive memes, or develop counter-memes that get there first, or create positive memes that can out-propagate the negative memes, or corrupt the negative memes so that they don't result in active opposition.
All else being equal, the tasks outlined in PtS will go faster if there are people working on them full-time (15). Some tasks, like running the Last Program (16) on rented supercomputing hardware, are likely to require large-scale funding (17). Finally, there should be an obvious target for people who would like to help out the Singularity via cash donations, preferably in a tax-deductible fashion. A nonprofit (18) institution devoted to providing Singularity infrastructure, a "Singularity Institute", would seem to be required.
The right kind of nonprofit (19) would be eligible to apply for grants from private foundations; which, especially during the initial stages, may be our best bet for funding. It would also be possible for individuals to make tax-deductible donations. Later on, my hope is that the Singularity will prove a popular cause among Silicon Valley millionaires; in the long term, this will probably be the major source of funding. I'm not particularly counting on the middle class for broad-based support, since even institutions that actively solicit small donations typically get 80% of their funding from a few large donors.
In the beginning, I expect the Singularity Institute to employ one or two full-time developers; once we have a major sponsor, or we successfully apply for grants, this will go up to a couple of dozen people including some Singularity PR people and a few researchers. This may not be enough to reach Singularity in 2005 or 2010, but given unlimited time, we can probably get all the way to the Singularity with no higher level of funding. Since our time probably is limited, we should try to build a stronger operation. If we can get Silicon Valley to adopt the Singularitarian ideal, the Singularity Institute might have enough funding to sponsor massive PR efforts, run dozens of research projects, and start subsidiary institutions. Anything beyond that is probably superfluous, although I sincerely doubt that we'll ever run out of uses for money.
For more on the Singularity Institute, see 3.2: The Singularity Institute. For a description of the initial people required, see 4.2: Institute initiation. For guesses at the amount of funding required, see 4.1: Development initiation and 3.2.1: Institute timeline.
A substantial fraction of the population is likely to react badly to the prospect of Singularity - either because it contradicts deeply held moral principles, or because they learned their reflex reactions from watching Star Trek. We should emotionally accept the possibility of government interference, and be prepared to move against attempts to regulate the development of AI, or evade those regulations if they are successful. (We should also oppose attempts to turn the public against the Singularity, even if no government regulation is immediately proposed; the general battle over how the Singularity is perceived comes under 1.3: Spreading the right memes.)
The probability of public or governmental opposition is a primary reason why running the Last Program distributed over the Internet, formerly a major part of the PtS vision (20), has been abandoned. With that tempting target for regulation (or public protest) gone, and the necessary public exposure reduced, there's a much smaller chance of crippling legislation being passed.
Unless the Singularity becomes a major public issue, a complete and enforceable ban on AI research is not likely in the United States. Technophobia is more likely to find outlets in bans on government funding, regulations requiring public disclosure, and so on.
There are a few psychologically plausible pieces of legislation - which I see no need to be more specific about - that would impose enough inconvenience to force the open-source project to move to Australia or, if necessary, China. I'm not saying we should be ready to move on a minute's notice, but it's something to bear in mind. (For example, we should back up all our materials in several offshore locations, so that nobody can prevent us from taking our information with us when we move.) This state of readiness should also help prevent a ban on AI; if it's absolutely clear that banning AI would simply move the project overseas, to the detriment of American (or Australian, or English) industry, there's some slight chance that the legislators involved will see reason. (But not much, so we need to be ready to actually move.)
There are also technological precautions we can take against a complete ban on AI. We should be ready to switch the open-source administrative structure from being public and centralized to being anonymous and distributed, with the source code being submitted via PGP, and protecting participant identities. In short, we may need to go underground, and that's something to keep in mind while organizing the project and writing the code. I'm not suggesting that we be ready to disappear on a moment's notice, since that would take a lot of work that might turn out to be unnecessary, but I am suggesting that we bear it in mind.
I would also suggest encouraging encryption (whether governments like it or not), particularly ubiquitous protocols like Secure IP (21), just in case it turns out we do need distributed computing.
"Dealing with opposition" may also include dealing with groups that resort to extra-legal means to oppose us. Aside from locating our working sites under the protection of police forces principled enough not to "look the other way", I don't see any particular aspect of this task that should be discussed in advance. (It is, however, something to bear in mind.)
The computer industry is our base. It's not enough to start a gold rush; we have to ensure the miners are healthy. In particular, we have to ensure that Moore's Law (23) keeps on trucking, and that the software industry remains viable.
A little-known adjunct of Moore's Law is that the capital required to build a chip fabrication plant also keeps doubling. We have to ensure that hardware demand remains strong. (24). Bill Gates is famous for telling Intel that no matter how much power they supplied, he would "develop some really exciting software that will bring the machine to its knees". Of course, that was some time, and a factor-of-1000 performance improvement, ago. And now it looks like Bill Gates may finally be defaulting on that promise (25) - the slow stuff isn't exciting and the exciting stuff isn't slow. People are starting to wonder whether they really need the fastest new machine.
Since PtS abandoned the distributed-computing plan, the strength of the individual machines on the Internet is no longer all-important - but said machines still need to be able to support the local infrahuman AIs we develop. Furthermore, modern supercomputers increasingly consist of thousands of Pentiums wired together, meaning that the cost and magnitude of supercomputing depend on the cheapness and speed of the individual processors. Above all, we need to encourage the growth of "ultracomputing", software that uses massive amounts of computing power (and provides equally massive benefits), to spur others to build and rent out massively supercomputing hardware (26). But we also need to ensure that the desktop computer keeps getting brainier, or hardware companies won't earn the money to build the factories to make the chips that go into the supercomputers.
The software industry isn't in trouble now, but there may be trouble brewing; to wit, CEOs and even CIOs starting to wonder whether investing trillions of dollars in software development - half of all capital investment in the US is going into information technology - is really paying dividends. Large projects in particular are starting to run into Slow Zone problems (27), the tendency for anything above a certain level of complexity to bog down. Of course, many of these people are still using COBOL, and there's not much you can do to help a company that clueless, but some projects use C++ or Java (or even Python) and still run into trouble.
I am not suggesting that we launch a special-purpose effort to Save the Software Industry. That doesn't need to be done by Singularitarians (28). Rather, I think we should try and kill three birds with one stone. The primary immediate goal of AI (29) should be to reduce development, maintenance, and debugging time for mainstream, internally developed IT. First bird - this is AI targeted on source code, meaning that it's a step towards self-improving AI. Second bird - providing the profit motive for the computing industry to adopt and develop AI. Third bird - heading off economic trouble in the software industry.
This section explains the sequence of technologies leading up to the Singularity. It's not intended as a detailed technical whitepaper. It's not even intended as a high-level guide to design principles, or anything else aimed at the eventual implementors. Rather, this section is intended to convey some of the plan-relevant characteristics of each technological stage. (30).
The technologies described here are presented in chronological order, which happens to be the reverse order of their invention. Coding a Transhuman AI (which describes how to build a seed AI, the final stage of the timeline) was published in 1998, long before I'd thought of turning a bag of programming tricks into the Flare language. My personal notes preserve for posterity the exact moment in which I realized there was a direct path from Flare to a self-optimizing compiler, and from a self-optimizing compiler to a Singularity. My brain preserves the memory of the triumph I felt. That was when I decided to write PtS.
"So I think I may be able to map out the full Path to the Singularity, here."The technological timeline was created by starting with seed AI and working backwards. The upshot is that, by my standards, we don't get to the exciting part until 2.2.9: Self-optimizing compiler. I hope you'll bear with me until then. (Alternatively, you can read the sections in reverse, starting from 2.2.14: Transcendence and working backwards, but PtS wasn't designed to be read that way.)
-- Written in the predawn hours of April 28th, 1999.
Creating a self-enhancing AI with the potential to get all the way to Power level involves a number of complexities not needed to just hack something up. Non-seed AI is considerably easier than seed AI. You can design systems with no way to automatically integrate changes to the architecture; in fact, it's even possible to design systems with clear-cut distinctions between content and architecture. The system can contain premanufactured knowledge that it has no way of learning, and subsystems that it can't understand or modify (31). In short, there are a lot of shortcuts that we can take initially. As time goes on, more development resources will become available, and computing power will become cheaper, enabling us to stop taking shortcuts.
The "Aicore" timeline, or at least the initial stage (a.k.a. "Chrystalyn"), describes a "crystalline" AI (32). If Elisson (33) is a mind, then we might consider Chrystalyn, a.k.a. Aicore One, to be a picture of that mind. As we move along the Aicore line, the flat picture becomes a sculpture, and the sculpture becomes a mind.
Initially, the Aicore I visualize will provide a basic framework for programs that can use artificial intelligence: A programmatic architecture, an API (34), a set of architectural domdules, and whatever library domdules are standard. "What's a domdule," you say? The actual explanation of what domain modules are, and why domdules form a fundamental part of AI, is in Coding a Transhuman AI. I shall nonetheless essay a one-minute explanation.
| Domdules and RNUI in 60 seconds: |
A
"domdule",
a module targeted on some domain, is what enables the AI to Represent,
Notice, Understand, and Invent cognitive structures in that domain.
|
The AI application developer would write an "application" domdule for some specific domain - say, cash-flow analysis - and integrate it with the rest of the system. Then the application domdule automatically gets all the built-in capabilities - design optimization, learned prediction, goal-oriented planning, and so on (36). In short, the application AI would be able to engage in reasoning about the domain. Furthermore, any skills the AI has already learned can be applied to that domain - if the AI knows how to look for anomalies, then, after a bit of experience, it will know how to look for anomalies in cash flow.
And domdules add up; the standard library in later versions of the Aicore system might provide a natural-language domdule (37), which could be added to the existing AI to create a question-answering interface for the cash-flow analysis database. Of course, I doubt this integration will be automatic during the initial stages. How much cumulative ability you can get by combining domdules, and how much work is required to combine domdules over and above the work required to create the domdules themselves, will be one of the key parameters shaping the AI industry at any point in time. (38).
The primary goal of Aicore, in the initial stages, will be making IT development easier. The most obvious way this can happen is through smart IDEs (39); that is, application domdules targeted on source code. The next most obvious way is making it easier to develop IT applications that "wanted" AI to begin with, i.e. IT applications that need to perform reasoning about the domain. The Aicore programmer would just have to define the way the domain behaves, since general reasoning is already present. The most subtle and important goal of the Aicore line is to become integrated into the system libraries and the program architecture. The programmer will write programs that make use of AI reasoning in the algorithms (40); or, better still, write "programs" that are simply thoughts in the AI (41).
The ideal application for Aicore - the one we want most to encourage - would be systems that consist of the Aicore system, an application domdule, a user interface, a set of goals, and lots and lots of Beowulf or supercomputing hardware. Where, previously, the system would have been a three-year hundred-million-dollar program that was two years late and never did work right. Aicore has the highest utility where being able to assume some basic reasoning ability is the key difference between writing one set of high-level instructions, and spending a thousand programmer-years writing ten thousand slightly different low-level procedures ten thousand slightly different ways. That's what it means for AI to be "part of the program architecture".
The very first releases might not have the robustness needed to run corporate IT in real life, but even the first releases would still be useful for rapid prototyping, and robustness is what open-source does best. In later stages, the products of the Aicore line will begin to approach the level of sophistication and decrystallization needed for seed AI, perhaps even exhibiting some signs of rudimentary intelligence. No harm will be done if true intelligence isn't possible on desktop hardware, however. The important thing is that the stuff Aicore is made of should begin to approach the same design used in true seed AI, so that the genuine full-scale seed AI research project can take advantage of industry advances.
Flare is a proposal for a new programming language, the first annotative programming language, in which programs, data, and the program state are all represented as well-formed XML.
| NOTE: | At present, I don't even have a publishable Flare whitepaper.
I don't even have a finalized design. I am engaging in the sin of
aggravated vaporware because I have been told, and convinced, that the
timeline does not make any sense without knowing some of what Flare is
and what it does. Please consider all discussion of Flare to have
whatever degree of tentativeness and subjunctivity is required for that
discussion to be an excusable act of speculation.
Since I do have over half a megabyte of design notes, I use the present tense in discussing properties of Flare. Those properties are no longer tagged as "subjunctive" in my mental model, and using the present tense feels more natural (42). No claim that the Flare design has been finalized is implied. |
XML is to Flare what lists are to LISP, or hashes to Perl. (XML is an industry buzzword that stands for eXtensible Modeling Language; it's a generic data format, somewhere between generalized HTML and simplified SGML.) The effects are far too extensive to go into here, but the most fundamental effect (43) is that XML is easy to extend and annotate, and this property extends into Flare programs and the Flare language itself. (44).
Our own cognition is also annotative - we note arbitrary facts about things, and think in heuristics that act on arbitrary facts about things. An "annotative" programming language, which recognizes this fact, is thus a higher-level language. "Higher-level" means "closer to the human mind" - annotative thinking is reflected in annotative language, just as object-based cognition is reflected in object-oriented languages, just as procedures are closer to our mental representations than assembly language.
Flare has four primary purposes:
The current stage is Flare Negative One. I have at least 500K of notes on Flare, but I haven't put them into publishable form yet. I don't have a Flare whitepaper available; I could probably get one together in, say, a month or so. Since I don't have a complete whitepaper, I was reluctant to say as much as I've said already. I don't want any crippleware versions coming out and depriving Flare of its incremental benefit. (I'm not worried about crippleware AIs for the simple reason that anyone bright enough to implement any part of the Aicore line without my help - no matter what I post on the Web - is bright enough to do their own navigation.) I'm also reluctant to engage in acts of aggravated vaporware, but I've been convinced it's necessary (50).
As noted in 2.1.2: The "Flare" line, Flare is the name for a new programming language that is to be the vehicle of a series of improvements in programming techniques. It is a programmer's truism that 90% of the features provide 10% of the functionality. This can't necessarily be reversed to provide 90% of the functionality with 10% of the features, but it's often a good idea to try. As designed so far, the true, elegant version of the Flare language contains a number of features which will probably not be frequently used (51). Thus "Flare Zero", a version of Flare designed according to the "New Jersey approach" to have around 50%-80% of desired functionality (52). For example, Flare Zero will have programs in XML, and data in XML, but the program state will probably not be expressed in XML. There are all sorts of cool things you can do with an XML program state (53), but they won't happen every day. The "Zero" is because the number of omitted features render Flare Zero not-really-Flare.
Nonetheless, Flare Zero should yield substantially improved development times, functionality, and maintainability for the development of certain types of complex programs. In particular, any attempt to explain to the program a set of regulations or rules originally designed for humans to follow (54) should be substantially easier, an improvement on the order of the transition from procedural programming to object-oriented programming.
Ubiquity (55) isn't likely to reach the same level as, say, Python or Java until Flare One. (On the other hand, it should be fairly easy to interoperate with other languages (56).) Of course, that's all the "mature" version. The first release will be a research language, the way these things always work, and without the speed and sophisticated tools that many programmers demand. Even so, it'll be a fun language, and it'll be possible to do things in Flare that simply couldn't be done otherwise, so we can probably get enough open-source volunteers to bootstrap.
Flare Zero will be a reasonably "mundane" project in that, given the basic insights, the design and implementation should not require Specialist-level talent or nonobvious, fundamental revision of the basic insights. In short, it's a project that I can reasonably turn over to someone else; I don't have to be the limiting factor. This may make it suitable for an initial project by the Singularity Institute, even though Flare is not actually necessary to the Aicore line until Aicore Two or thereabouts (58).
Flare Zero is not on the critical path, but it's also the easiest, and most conventional, of all the projects on the timeline. Depending on the resources available and the perceived necessity for experience and a successful initial project, it might be wise to start work on Flare Zero first. (See 3.1.1: Development resources and 3.1.2: Development timeline.)
Chrystalyn is a minimal version of Elisson - Elisson being the seed AI from Coding a Transhuman AI - which lacks the cognitive and programmatic features required for self-alteration, independent learning of new domains, self-organizing integration of new representations, automatic adjustment to architectural changes, and flexible symbols.
However, Chrystalyn will have a domdule-based architecture and world-model, RNUI design and notice codelets, a goal system, causal and similarity analysis, reflectivity, and some self-improvement with at least as much reflexivity as Eurisko (59). Or at least it will have simplified versions of causal and similarity analysis et cetera which imitate cognition in useful ways. As the name implies, Chrystalyn will be designed as a mostly "crystalline" (60) AI. The programmer will simply sit down and write notice-level functions, and those functions will have direct meanings that make immediate sense to humans. (61).
Although Chrystalyn is not an intelligent entity, it should be one heck of a computer program. Eurisko achieved impressive (62) performance in a wide variety of domains, through a combination of generalized heuristics and domain-specific models. I would like to duplicate and exceed this capability in open source code. Given a domain (chess, inventory replacement, stock prices), it should be possible to write a domdule which obeys some standard API and has human-provided integration with the "architectural" domdules (causality, goals, etc.). That is, the notice-level functions inherit from the QNoticeCodelet class (63), and the AI application developer annotates (64) notice-level functions (and representations, and reflexive traces) with standard, crystalline labels (65) that let them link up with the rest of the system - the domdules and representations for goal-oriented thinking, causal analysis, heuristic-learning, evolutionary design, and so on. The programmer writes the application domdule; Aicore provides the cognitive architecture, and skills to perform actual reasoning about the domain, such as design optimization, prediction, question-answering, and so on.
I wouldn't be surprised if the first Aicore architecture required, for a pair of domdules to work together, that at least one domdule have been designed by someone who knew about the other domdule. That doesn't mean things are hopeless; two domdules might be able to interoperate fairly well in practice because they both know about the causal-analysis domdule. But if this level of AI goes mainstream, it will create a market in domdule packages (rather than just domdules) and minor "OS wars" for new architectural domdules. Software folk will find this paradigm familiar.
At minimum, the initial releases of Chrystalyn should be useful for rapid prototyping, exploratory programming, and knowledge mining. Given a lot of domdule work and enough computational power, Chrystalyn should be capable of a number of novel applications (or assistances) - automatic translation between communication protocols and data formats; user interfaces that learn frequent actions and understand user goals (66); porting code between operating systems and languages; spotting bugs. The initial versions of Chrystalyn will probably be memory hogs and slow like molasses (although perhaps the heuristics and procedures could be learned on a SPARC and run on a PC). But software bloat is relative to hardware, and perhaps someday Chrystalyn will become part of word processors.
Work on Chrystalyn can occur contemporaneously with Flare Zero development. It should be possible to write Chrystalyn in Python, using some Flare techniques without having the actual language (67). If Chrystalyn is still around when Flare Zero becomes reliable and supported, we'll translate it into Flare Zero. Same goes for Flare One. (Anything less than Flare One is a hack as far as doing AI is concerned.) But meanwhile we'll do it in Python. Since Python is open-source and embeddable, applications with embedded Chrystalyn shouldn't be too complicated.
As always, the disclaimer: At present, Chrystalyn is simply an idea. As with Elisson and Flare, it will probably take at least a month of thought to translate the idea into a design, then another month if I need to publish it on the Web. I do not think it will be possible for a team to translate the high-level concept into a design and implementation without Specialist-level assistance, both because of the intrinsic difficulty, and the high probability of further research-level insights and redesigns being required. The creation of any mind is the hardest solvable intellectual task in existence.
If Flare Zero is an advance compilation of "Flare's Greatest Hits", Flare One is the first actual implementation of Flare. Flare One eliminates all the shortcuts taken to get Flare Zero out the door, and adds some fundamental concepts needed for distributed operation, self-examining code, secure execution, and so on.
One example would making the program state representable as XML; another example would be replacing the monolithic interpreter with the Tcl-like modular interpreter implied by an XML program state. (68). This might make Flare One slower, but given the above modular interpreter, it should be easy to create alternate implementations that leave out unused features. It should also become a lot easier to port Flare to new environments. (See above footnote.)
If there's a usable version of Aicore One when we're ready to put out Flare One, we should integrate Aicore into the Flare IDE, although not (yet!) into the language. This should lend at least a minimal level of intelligence to program editing (69), debugging (70), semantic searches (72), change propagation (73), and possibly even code reuse (74). Even if only the most obvious applications are possible, I would expect a significant improvement in coding time and the manageability of large projects, especially as more AI "scripts" were contributed. (Although I do worry about whether the AI "scripts" will be fast enough for people to actually use.)
If Flare Zero is the "50% right" version, then Flare One skips the "90% right" phase and goes directly to the "single perfect gem". And yes, I know that single perfect gems are supposed to take forever to design and be impossible to implement efficiently. But somehow, after trying to design a mind, the prospect of designing a single perfect gem doesn't seem very intimidating.
(Should be part of the Flare One release.)
Flare One should contain language features intended to set things up for parallel computing (75) on symmetric multiprocessing machines. The ideal of SMP is that almost any Flare program will run four times faster on a machine with four processors. In practice, a "parallel Flare" program that runs on one processor will probably be ten times slower than a "serial Flare" program, which is why SMP should wait until Flare One, when unused features won't detract as much from efficiency (76).
The purpose of symmetric multiprocessing is threefold. First, as an optional research feature and rapid prototyping method, making certain kinds of code more natural, and encouraging programmers to experiment with parallelism. Second, to introduce the theoretical potential for upward scalability - if a Flare program won't run a hundred times faster on a hundred processors, perhaps it will at least run ten times faster. Third, as an ordinary programmer's tool for managing preexisting parallel processes (77).
The ulterior motive of parallel Flare is to start setting things up for the rise of the sixteen-processor home computer. Admittedly, since the concept of running on the Internet has been abandoned, the sixteen-CPU home PC is less of an advantage (to us). Nonetheless, SMP helps set things up for very-high-powered apps like Aicore, may advance techniques that will help us run a seed AI on massively parallel hardware, may advance ultracomputing in general, and may also help keep the computing industry going in the event that Moore's Law temporarily fails.
Admittedly, parallel Flare per se won't actually be a practical advantage, capable of driving demand for SMP machines, until 2.2.9: Self-optimizing compiler. But just the technical advancement in programming techniques may be enough to affect the SMP market (78) - if, for example, the Aicore line can use SMP efficiently, then this will increase demand for SMP machines.
Flare Two integrates Aicore into the language itself, not just the IDE. This step will probably take place at least a year after the release of Flare One, so that people have had time to evolve applications and libraries and programming techniques that use Aicore as part of the architecture. (79). The fruits of the previous loose Flare/AI coordination will be compiled and coordinated.
Flare Two is the point at which system libraries get turned into domdules. As you hopefully recall from Domdules and RNUI in sixty seconds, a domdule contains "a set of codelets that annotate the data structure with simple facts about relations, simple bits of causal links, obvious similarities, temporal progressions, small predictions, et cetera. The converse of notice-level simple perception is simple manipulation, the availability of choices and actions that manipulate the cognitive representations in direct ways."
System interfaces, database interfaces, and anything else with an Application Programming Interface - anything with an interface for getting information and acting - can be thought of containing some notice-level functions of a domdule. Turn the API functions into domdule codelets, document the codelets with the labels that tell the rest of the AI what the functions are, add in information about visualizing consequences, integrate the domdule with the goal system and the other architectural domdules, and teach the AI about the purposes of the API. Train the AI; show it what the API is usually used for. Voilà. The AI can use the API on its own; all it needs is the set of end-goals. The AI can perceive when you make silly mistakes in using the API. Et cetera. (80).
And "API domdules" are only the simplest, most obvious application, just the tip of the AI iceberg, like using computers for high-speed arithmetic. If the program-as-domdule concept really works, there'll be applications I haven't even imagined. Flare Two is where we start "Exiting the Slow Zone": AI begins to make mainstream programming significantly easier - not just the task of editing and debugging, but system design. There's a wider range of things you can assume the computer will understand, and the language itself has a certain amount of common sense. Yes, Virginia, there is a silver bullet. (82).
Current programs have an internal coherence that's represented only in the mind of the programmer, or at most in human-readable documentation. But once the programming language and the IDE AI can represent cognitive facts about the program, programs will get a lot easier to debug. And once the language can turn cognitive facts into programs, programs will get a lot easier to write.
(Not synchronized with the Flare line. (83).)
Aicore Two will be a major reference release, written completely in the best Flare available at the time. (84). If there are any versatile domdules that have become popular and widely used, they will become part of Aicore Two's new set of architectural domdules. (85). If there's anything we've learned about faster development of Aicores, better domdule representations, better formats for the labels that integrate the system, et cetera, then we'll incorporate that too. We'll do the lessons-learned thing. The business case for Aicore Two will consist of that update.
But the primary purpose of Aicore Two is three timeline-desirable fundamental improvements:
(Should be part of the Aicore Two release.)
The Planetary AI Pool is a central repository of content developed by AIs. "Content" includes domdules, domdule elements (i.e. notice-level functions), heuristics, concepts, models, and whatever other high-level constructs or low-level elements exist. The low-level elements should obey a standard API, and the high-level constructs should be mutable by the same cognitive processes that created them. Hopefully, the problem will not be finding two pieces that fit, but finding two pieces that fit together well.
One example might be a bunch of word-processors all trying out new heuristics and sharing any user-interface adaptations that they've learned from the user. I create a word-processing maicro (89) that does something cool, and if your word-processor thinks you might like the maicro, your AI downloads the maicro and tries it out. An example maicro might be "If the user is making periodic entries in some document, offer to add the date and time of each entry" or "If the user is writing a Web page in FAQ format, check the Internet to see if a previous FAQ already exists". More mundanely, the AIs might just swap lower-level heuristics, like "Investigate cases close to extremes" (instead of "Investigate extreme cases").
If participating in the Pool reliably yields good results, and if selling spare CPU cycles is only worth a couple of bucks a month, then optimizing the local AI might provide more benefit than renting out your computer - making the Planetary AI Pool one of the largest MIPsuckers on Earth. This isn't as Singularity-desirable as it looks, however, since the AIs don't have a global intelligence. The primary effect would be to vastly increase the amount of computing power applied to tweaking bits of code, with no greater intelligence than the maximum locally achievable.
Nonetheless, there will be self-improving AI around, interacting on a global scale, so we need to at least start thinking about a possible Transcendence. Hence the "crystalline Interim Goal System" requirement in 2.2.6: Aicore Two.
Note: Being a pessimist by neurology as well as profession, I can't help but wonder whether all the "easy wins", all the interesting results, will be gathered in the first two days of the running the AI Pool - after which nothing interesting will happen, wrecking the business case for further participation (90).
"Scalable software" is software that shows a continuous qualitative improvement with better hardware. Deep Blue is the canonical example; IBM's research team just piled on computing power (91) until Deep Blue exhibited "a new kind of intelligence" (92) and beat Kasparov. It seems plausible to me that an AI, with more intelligently shaped search trees, would scale even better.
Any software that uses scalable AI automatically becomes scalable itself (93). But I also have hopes that scalable AI will start a trend towards the general use of scalable programming techniques. The name of this stage is "scalable software", not "scalable AI".
When scalable AI or scalable something is an integral part of word-processing programs, Joe Q. Consumer will always have a motive to buy the latest 16-processor 2GHz tower. When scalable programming becomes common, Joe Q. CIO (94) will be able to throw hardware at a late software project. Above all, the style of programming involved will hopefully extend to the creation of "ultracomputing" software applications - software that would do something amazingly useful on a supercomputer. (95).
The purpose served:
After Aicore and Flare have been around for a few years, there should be mature Flare domdules for Aicore - domdules capable of understanding the logic and execution of Flare programs. There should be domdules that parse (and notice) other languages as well. In combination, this should yield AI capable of translating other languages into Flare. Flare, being XML-based, is obviously suited very well to being a universal program format. (96).
If the AI has a reasonable understanding of the logic behind the program (97), it should also be possible to treat a Flare program as a prototype, and write code that does "the same thing" using C++ or assembly language. (98).
In fact, given that Flare's XML representation should be easy to manipulate and translate, I would expect the first experiments with Flare-to-C++ or Flare-to-assembly compilers to begin soon after Flare One was released. By this point on the timeline, we might just be assembling the experiments and compiling them into a coherent whole (99), rather than doing any actual research.
Automatic translation will break down the distinction between languages. If the AIs can analyze machine code and translate it back into commented, named, understandable source code, even the distinction between source code and assembly will break down. And at that point, Flare will eat the entire software industry. When Flare is as fast as C++ but infinitely safer; when all your legacy code only looks like it's written in COBOL or assembly language, but - like it'll say on the T-Shirts - It's Really Written In Flare; when Flare becomes the common format, the meeting point of every programming language and IDE - then, things can really start to move.
When Flare-tuned AIs can examine machine code as easily as the original source, there won't be any comprehension hit for using assembly language. When Flare programs can automatically be rewritten as machine code (100), there won't be any performance hit from using Flare - quite the contrary! "Code" will become an abstract liquid that can be poured from one substrate to another. There won't be any part of its own source code an AI can't understand - if necessary, it will be able to look at its own program in RAM.
And thus, the AI will be able to understand, and optimize, its own source code.
| NOTE: | Veteran Singularitarians will recognize this as a description of Dan Clemmensen's "self-optimizing compiler". |
Fully self-swallowing programs are a key step on the road to Singularity. A long, slow, extended step, a step that starts with Flare Zero and probably won't come to fruition until after Aicore Two. But that's one of the main reasons for having Flare and Aicore. Flare is an XML-based annotative programming language. The Aicore architecture has notice-level functions that annotate a world-model. And thus, J. Random Hacker can experiment with noticing facts about programs.
So by this point there should be a huge library of programs and notice-level functions and domdules that understand Flare, and manipulate Flare, and translate other languages to and from Flare. The self-optimizing compiler stage occurs when that collective intelligence can read assembly language, and write it, as easily as it reads and writes Flare. It should be possible to write a Flare interpreter and Aicore implementation in High Flare, Flare with all the features turned on. Earlier, this would have run like molasses; with a self-optimizing compiler, it'll run as fast as C++ or assembly. And experimenting with Flare AI will get even easier, since it'll be possible to write intelligent Flare evaluators in Flare without running into a major performance hit or infinite recursion.
With a self-optimizing compiler, capable of translating 68040 machine code for a PalmPilot interface into Flare and thence to parallel-computing Intel assembly that runs on a multiprocessing Linux machine (101), the SMP market should really hit the mainstream for the first time. (102). With true code-understanding AI, it should take only a small additional refinement to handle asymmetric multiprocessing.
I used to wonder why, if we can fit a primitive CPU onto thousands of transistors, and a modern CPU onto millions of transistors, we can't fit a thousand primitive processors onto a modern chip. But I know why: It's because we don't have the programming techniques to use the darn things. So we just build larger and larger serial CPUs with as many bells and whistles as it takes to turn all those transistors into one instruction-execution event loop.
With a self-optimizing compiler around, it should be possible for Intel to design thousand-processor asymmetric multiprocessing chips and be assured that existing programs will be capable of using them to their full potential. And this, in turn, should mean that instead of million-CPU supercomputers, we'll have billion-processor supercomputers. With any luck at all, this should be more than enough raw power to run a seed AI.
Since this development would have to take place in "hardware time" (103), the PtS plan doesn't rely on it. It would really help, though.
This is the point at which we start to decrystallize the Aicore line and make it self-swallowing; this where we start moving towards seed AI. It's the release where we start long-cutting some of the shortcuts. Aicore Three is when we put in some of the Elisson characteristics that were originally omitted, but which will become necessary once mutating code is around (104). I won't say that this stage will have to occur after SMP or adaptive hardware utilization, since who knows if we'll have the time for hardware to catch up with software - but nonetheless, decrystallizing does take power. (105).
Aicore Three will also contain a reference release of any infrastructure that got invented by the Planetary AI Pool. However, most of this infrastructure will be obsolete. (See next paragraph.)
The defining change in Aicore Three will be self-integrating domdules. While human effort may still be required to label all the functions and representations, it shouldn't require human effort to link up two sets of labels. The links will be learned. AI should exist which examines possible links between tags, associations between representations, et cetera, and which improves or invents them by studying similarities and covariances.
As a result, the distinction between "architectural" domdules and "content" domdules should start to break down. The market for domdule packages will vanish. And if the learning techniques can apply to previously created domdules, the total intelligence of the Aicore system will take a huge leap; all the existing intelligence will come together.
Perhaps existing domdules will become obsolete as well. (Not useless, just obsolete.) At this point, the time and effort and research computing power should exist to decrystallize the domdules and even the architecture - bump the domdules down a level or two, break them up into subcomponents. This is getting close to true cognition, but not quite there yet.
Furthermore, some or all of the Aicore code should be "documented" in a way that the AI can understand (106), so that the AI itself can improve on it. Perhaps as much as possible of the code will be replaced with an implementation generated by the AI itself, so that the AI can manipulate the design and thus manipulate the implementation directly.
When you factor in the Planetary AI Pool, this all sounds like Singularity-class stuff, and the probability does exist - but, once again, I don't think it's enough. I think it's necessary, but not sufficient. Reflexivity and circularity create the raw material for Transcendence, but to start it off, you need a fundamental spark of creativity, of smartness. I'm not sure that will be present at this point.
As with the self-optimizing compiler, I think the result will be a superbly optimized design, perhaps with some interesting new tricks and features, but not a wholly new design with an interesting new purpose. The AI might be capable of all kinds of coding tricks, but not of performing scientific research or holding a philosophical conversation with a human.
But since there's a real possibility of a Singularity, or of real-but-infrahuman intelligence, Aicore Three should have a safe, decrystallized, and fairly complete goal system (107) - one with almost all the precautions we'd want in a real AI (108).
At this stage we're obeying the second rule of navigation:
| Second Rule of Navigation |
| Before you can create X, you must create the potential for X. |
If progress continues long enough, Flare and Aicore will merge. Most mundane programming will consist of taking an AI and telling it what you want, in natural language. One will be able to give instructions to computers in the same way one would give instructions to humans. Programs will become thoughts. AI will eat the software industry.
This stage will also see the rise of the World Wide Program: When all programs are thoughts in AIs, they should all interface automatically - programs will just flow together, like puddles of water merging. Just as the modern Web can be viewed as one massive document, all the public IT in the world will be one massive program.
There is no way this will happen before the self-optimizing compiler stage, because otherwise the programs will run like molasses. It will be possible, but a bit more difficult, to carry this off without adaptive hardware; instead of having AIs that think, we'll have AIs that write programs. (Perhaps the programs will call on the corporation's central AI (109) whenever something exceptional happens.) There will probably be a significant difference in user happiness between having a personal AI, and just having AIs write all the code, but the effect on the software industry will be the same: Blam.
This stage is more futuristic than navigational. I'm not sure it'll happen and we can certainly do without it, but I think it might happen - the potential will be there - so I'm mentioning it. Why? Mostly in case our meme people want to talk to Wired about it.
In real life, I'm not sure ubiquitous AI would be a good idea. In fact, it could be nearly as bad as nanotechnology. I'm not going to be specific, because it doesn't necessarily help matters to sketch out all the possible ways something can go wrong, especially in public fora (110). In essence, there'd be three major categories of problems:
| Clemmensen's Law |
| "IMO, the existing system suffices to permit technological advance to the singularity. Any non-radical change is unlikely to advance or retard the event by much. Any radical change is likely to retard the event because of the upheaval associated with the change, regardless of the relative efficiency of the resulting system." |
On the other hand, trying to retard a radical change is also a bad idea, in accordance with Yudkowsky's Third Threat: "Attempting to suppress a technology only inflicts more damage." (After all, if the Hidden Variables are kind, the enormous power of ubiquitous AI might enable us to deal with the enormous problems posed by ubiquitous AI. The Information Age may have sent enormous shocks through the economy, but it also helped build an economy flexible enough to take it.)
Clemmensen's Law says that it's rarely a good idea to attempt major changes to society. The Third Threat says it's rarely a good idea to try to prevent major changes to society. I think the upshot is that we don't need to help ubiquitous AI along. If ubiquitous AI happens anyway, or looks like it might happen, then we'll try to deal with it. But there's not much that needs to be navigated in advance - except, as stated, the public-relations potential.
In short, this is one of those "destabilizing" applications of AI - an "ultraproductivity" effect. (See 3.5.2: Accelerating the right applications.) Ubiquitous AI can't be held off indefinitely, but it doesn't have to happen before the Singularity. If ubiquitous AI happens anyway, it doesn't have to happen before we're ready; it can wait until the economy is built to take it.
And now, the big finish: Developing a fully self-swallowing seed AI, capable of creatively enhancing itself to greater-than-human intelligence. We take the best version of Aicore and finish decrystallizing it, doing all the things we couldn't do earlier (because it would be too slow for the user, or because it would be so big that it would have to run on a major supercomputer). In short, we'll use the Aicore line as the raw material for building Elisson, the AI from Coding a Transhuman AI.
I imagine I'll have revised CaTAI extensively by this time in the future, but for the moment, it will serve as delineating the goal. Every aspect of the AI, from the low-level code, to the conceptual architecture in CaTAI, to the reasoning behind CaTAI, will be explained in a way that the AI can understand and manipulate. With the full power of cognitive science as it exists at that time, we will try to duplicate, at least in potential, every useful detail of human thought.
We'll do our best to explain the concept of "better thinking" as a goal, the measurable ideal of better representing, predicting, and manipulating reality. We'll give Elisson the ability to see the internal coherence of designs for a mind. We'll give Elisson the ability to evaluate those designs, to see how they serve the goal of better thinking.
And once full self-understanding is achieved, it's only a short step up to self-invention. When innovation is achievable in theory through a massive search through all possible designs, then innovation should be possible in practice to any self-modifying mind that understands search trees.
AI will change, from a computer program designed for speed and reliability, into a real mind designed for power and flexibility. We will add the spark of creativity, and link that spark to a clearly defined goal of self-enhancement.
Elisson will probably be a tremendous challenge, possibly requiring a centralized effort. Elisson is also a Deep Research project, very very Deep, the Deepest humanity will ever face before the end, and it will require an immense amount of ultra-top-flight brainpower (112). But with a pre-existing Aicore-based IT economy, small improvements coming out of the Elisson Project should yield immediate profits, thus providing a motive for the investment required.
With a huge pool of AI hackers, with planet-years of knowledge and expertise in domdule programming and code understanding and self-modification, the potential will exist. In the end, every other point along the timeline exists only to create the largest possible support base for Project Elisson (or other AI projects, if Elisson should fail).
Project Elisson should be started as soon as the necessary resources are acquired. Those resources probably won't be available until AI goes mainstream at 2.2.6: Aicore Two, and the project will not yield directly applicable results - it won't be part of the timeline - until AI becomes decrystallized at 2.2.11: Aicore Three. Likewise, the timeline will not yield direct programmatic support until Aicore Three, just hints and tools. Nonetheless, Project Elisson will represent the leading edge of research in AI, which will trickle back to the Aicore line.
Besides, you never know where the breakthroughs lie, and with self-modifying AI, any breakthrough might be the last. Project Elisson should start up as soon as it's practical.
| NOTE: | This marks the point at which we are actively and directly trying to bring about the immediate creation of a true Singularity, the birth of greater-than-human intelligence. |
And then, at some point, the Elisson project succeeds.
A major breakthrough occurs within the research project - the local version of Elisson does a major rewrite with much greater creativity, exhibits flashes of smartness, but perceptibly runs up against the limit of the hardware lying around. In short, Elisson exhibits some kind of progress that leads us to think it can go all the way.
The next step would be running Elisson on adequate hardware. There are three possibilities: "Adequate hardware" is what's lying around the Singularity Institute's basement, "adequate hardware" can be rented out for a few days and a couple of million bucks, and "adequate hardware" simply isn't available. In the first case, hardware isn't a problem. In the second case, we quietly (113) rent out the best available hardware and run the latest version of Elisson. In the third case, after the attempt on the best available hardware fails, we keep on researching and try again when a significantly better supercomputer becomes available. For the sake of discussion, we'll assume that adequate hardware is found.
I hope and pray (and guesstimate using the power/optimization/intelligence curve described in Singularity Analysis) that there's very little chance of winding up with a merely human-equivalent AI. Once the AI reaches the vicinity of human intelligence, it should be able to redesign its architecture for greater efficiency, which would translate into even greater intelligence, which would enable it to redesign its architecture yet again. Since the forces involved in self-modifying intelligence are folded in on each other, the total curve is completely different from the non-self-referential forces whereby evolution produced human intelligence. There's no particular reason for the curves to have plateaus in the same places. Given the historical fact that Cro-Magnons (us) are better computer programmers than Neanderthals, I would expect human-equivalent smartness to produce a sharp jump in programming ability, meaning that, for self-modifying AI, the intelligence curve will be going sharply upward in the vicinity of human equivalence.
Thus, there should be a fast transition between considerably-dumber-than-human AI and considerably-smarter-than-human intelligence. In the event that I'm wrong about this, we'll probably have to grit our teeth, go public with the birth of human-equivalent AI, and hope for the best. But I really do think that's a low-probability event.
There are two critical levels of intelligence: First, the level of intelligence necessary to take over leadership of the Singularity effort. Second, the level of intelligence needed to create "rapid infrastructure", or nanotechnology (114). I think it very probable that these two levels will be achieved almost simultaneously; in the event that this is not so, things get more complicated than I'm going to talk about in this section. (116).
Even though we're assuming that Elisson is running things at this point, there are still some things we should do in advance. A merely transhuman AI (as opposed to a Power) might have trouble renting a nanotechnology lab without attracting attention. So, if the Singularity Institute has the money, we should have a nanotechnology lab in our basement. The remarkable thing about nanotechnology, circa 2000, is how cheap the basic equipment is (117). Having a nano lab is likely to be considerably easier than having our own supercomputer. Circa 2000, a pocket nanotech lab would probably consist of a scanning tunnelling microscope (118), a DNA sequencer, and a protein synthesis machine. (119). Given superintelligence, I get the impression that this should be enough in the way of raw materials. Of course, I am not a nanotechnology expert, so I could be totally off base.
Given all those devices (120), I would expect diamondoid drextech - full-scale molecular nanotechnology - to take a couple of days; a couple of hours minimum, a couple of weeks maximum. Keeping the Singularity quiet might prove a challenge, but I think it'll be possible, plus we'll have transhuman guidance. Once drextech is developed, the assemblers shall go forth into the world, and quietly reproduce, until the day (probably a few hours later) when the Singularity can reveal itself without danger - when there are enough tiny guardians to disable nuclear weapons and shut down riots, keeping the newborn Mind safe from humanity and preventing humanity from harming itself.
The planetary death rate of 150,000 lives per day comes to a screeching halt. The pain ends. We find out what's on the other side of dawn. (121).
One of the strengths of open-source development is the possibility of a casual, volunteer-run, decentralized structure - there doesn't have to be a "core" operation. I don't think we should take advantage of this possibility. It strikes me as being unnecessarily fragile, sensitive to random variables in the life of the project leader. As everyone knows by now, it's possible to run a huge open-source project in a Finnish college student's spare time. But, historically, this isn't true of all open-source projects (123).
In the case of Aicore and Flare, where the projects are entirely new ideas instead of improvements on previously developed tools, I don't think it would be a good idea to run things on an ad-hoc basis. There are usually a few key people in any open-source project, and while they often work as spare-time volunteers, the plan will be less vulnerable to the random factors if they can work full-time. (124). Likewise, the project will be more scalable if there's an expandable support operation instead of one person handling everything in vis (125) spare time. (See 3.5.1: Building a solid operation.) So the PtS plan assumes a support operation.
The virtual nucleus for an open-source project is a Website, a mailing list, and a CVS server (126); as of 2000, this remains constant over the initiation, short-term, mid-term, and long-term stages of open-source projects.
I'm not sure if the Aicore or Flare projects will need an evangelist or other memetic personnel. (127). I get the impression that good open-source projects generate their own evangelists. But, again on the principle of building a solid operation, we might want at least one full-timer. (128).
This is the minimum nucleus which can support arbitrarily fast growth of the project, in terms of user base and development base.
If the project does start growing "arbitrarily fast", which is the mid-term to long-term scenario, then ideally the Singularity Institute will grow with it (129). This would enable us to expand the support operation, which would hopefully pay off in faster growth, or at least reinforcement and consolidation of existing growth. But considering that huge open-source projects have been known to run without any full-time developers at all (130), nothing will go irreparably wrong if the project grows faster than the Institute.
Note that "short term" refers to after (A) the development project has "something potential contributors could easily run and see working" (131), which is required for getting open-source volunteers, and (B) the Singularity Institute exists. During the "initiation" period (covered in 4: Initiation) and depending on the interaction of the development and Singularity Institute timelines, the build-something-cool stage (132) could take place with anything from one or two part-time volunteers distributed over the Internet to a full-time development crew with a physical location. (A physical team would probably be considerably faster, one of the primary reasons for using full-time developers.) We can hope that some Singularitarian volunteers will contribute during the initial development, so a CVS Website and a mailing list are still appropriate.
Another initiation-stage question is how to divide resources between Aicore and Flare. These are very different projects, with different difficulty quotients, requirements, timelines and strategic effects. The upshot is that even though Aicore is on the critical path and Flare is not, I think initial resources should be concentrated on Flare. Flare is more scalable, and more accelerable.
The Aicore project presents special difficulties, both programmatic (133) and social (134), that are not present in the Flare line. I think it makes sense to initiate the far more conventional Flare project first, since Flare is easier to develop, vastly easier to explain, and will, initially, be usable by a wider group. It should just be easier to get people enthused about Flare, from a programmatic perspective. AI has major coolness factor, but in practice, it'll take a lot of work before your AI app hello-worlds. Flare should be easier for mortals to sink their teeth into.
The Flare project creates the infrastructure, influence, contacts, experience, and credibility needed to get the word out about the Aicore project.
Flare also provides a language of implementation for the Aicore project; we can do the prototyping in Python using ugly hacks, so Flare isn't on the critical path, but ugly hacks will only get us so far. Seed AI will take a self-optimizing compiler, which requires an annotative programming language and annotative programs (137), which means Flare (138). Flare will also help protect our base in the software industry. Flare is a legitimate Singularitarian accomplishment. (I'm saying all this, of course, because I instinctively feel guilty about spending time on anything except AI.)
We should expect that the Flare growth curve will significantly outpace the Aicore growth curve, which should translate into the Flare timeline being ahead of the Aicore timeline (139). We have to steer between the Charybdis (140) of being seduced by Flare's faster growth and neglecting the Aicore project, and the Scylla of being just another AI project with one or two researchers. That last part is the organizational reason why Flare is necessary. A human-scale challenge ensures the Singularity Institute doesn't need to wait indefinitely for successful projects and completed milestones. (142). Growth, which is necessary for ultimate success, requires interim successes.
| NOTE: | All development times are wild guesses that can extend into indeterminate amounts of time or (less likely) become shorter. Disclaimer, blah blah, legalese, disclaimer, import * from disclaimer, #include "disclaimer.h", require disclaimer, #!/usr/bin/disclaimer, visit http://www.disclaimer.com, you get the idea. |
The relative growth curves of Flare and Aicore are likely to be as follows: The Flare project gets started after either (A) I put the language into the form of a whitepaper that can be handed off to any competent and creative programmer, which will probably take about a month, or (B) I explain the Flare concept in person (143) and remain personally available for later consultations, which implies a Singularity Institute strong enough to support either a physical center or travel fees. I would prefer option (B), as it will save time, even though (A) is more solid (145). At this point, the Flare project has been "handed off", in the sense that I will no longer be the limiting factor.
It's utterly impossible to estimate development times in true research projects, of course, but I would hope that the formal open-sourcing of Flare Zero would occur in between six months and one year, that a version stable enough and featureful enough for AI development (146) would be available in from one to two years, and that a significant number of users and a sustainable open-source community would develop in from one to three years. If the resources were available, Flare One would begin as soon as there was enough feedback on Flare Zero to provide design feedback.
Meanwhile, after Flare had been handed off, I would start working on the Aicore line. I'm thinking in terms of spending a month or two thinking all the basic concepts through in greater detail (147), then another month or two concretizing the basic architecture (148), then some indeterminate amount of development time (probably a month or two) to "SimpleMind", a rapid-prototype skeleton AI (149). Then I'd probably have to rewrite the architecture over the course of a few weeks or months (150), after which I'd have a complete design for Aicore One's basic architecture and APIs. If, while all this is happening, I'm also trying to play some administrative or memetic role in the Singularity Institute (151), getting to this point is likely to take six months to a year.
If Flare Zero is usable at this point, further development will occur in Flare. (If not, I'll keep working in Python.) Once there's a clear design for the architecture and API, it'll be possible to initiate the Aicore project with a core crew of full-time developers. Once the architectural code, the "operating system", is developed, the creation of the architectural domdules can begin. Because of the cognitive nature of domdules - the notice-level codelets and so on - this stage of the task should easily lend itself to volunteer assistance (152). I'm not sure how much skeletal material will need to be there before Chrystalyn runs and does something cool, but afterwards, we can party with the open-source process. We'll only have volunteer-developers rather than developer-users, but I think we can expect quite a few of these due to the coolness factor. Figure the "does something cool" stage for two to three years since I handed off Flare.
Figure another year's worth of volunteer open-source domdule fleshing, skill teaching and heuristic creation, experimentation with application domdules, knowledge learning, and so on before the first formal business-ready distribution of Chrystalyn. (154). I would not realistically expect a substantial user base before four years have passed, making my "Singularity 2005" T-Shirt a touch unrealistic... but we can always hope. (155). T-Shirts aside, the PtS navigation assumes 2010 as the target date (156), and if we can seed an AI gold rush in four years, it should be possible to do the rest of the work in six.
Working out specific schedules beyond Flare Zero or Aicore One strikes me as pointless and unrealistic. I don't see what current decisions would be affected, and any plans made now would almost certainly have to be completely revised. This can be planned later, and should be.
| Open-source resources: |
| The
Cathedral and the Bazaar ("CatB")
Eric S. Raymond ("ESR") and the original announcement of the revolution. Homesteading the Noosphere ESR on the psychology of open-source. The Magic Cauldron ("MC") ESR on economics (and doing a damn fine job!) Open Sources: Voices from the Open-Source Revolution A book by O'Reilly, readable online. Essays from the leaders (including ESR). The Open Source Page Home page of the Open Source Initiative. (ESR is president.) |
Prerequisite: 1.1: Open-sourcing an AI architecture.
Open source, as defined by the Open Source Initiative, means free use of the program and free availability of source code. Free source code allows volunteer programmers and interested users to assist in developing the AI's core architecture. Free distribution encourages maximal use of the core architecture. Maximizing use maximizes AI content development (157), the number of "interested users" with a motive to help develop the core architecture, and the amount of publicity attracting Singularitarian volunteers.
I find it fascinating that this entire open-source strategy is made possible by the treatment of core AI as infrastructure instead of application - which, in turn, is only possible because the model of cognition is complex enough to use domdules. (Wrong AI uses such simple algorithms that the problem-solving intelligence can't be divided into content and architecture.) The distinction between {networked infrastructure, partially standardized middleware, and local application} is one of the key factors determining how well the open-source model pays off; Aicore is infrastructure, and may become networked. In a very real sense, the pattern of the industry is caused directly by the pattern of the artificial mind. Cognitive science for MBAs!
That's it. Most of what I want to say about open-source is in either 1.1: Open-sourcing an AI architecture or some other part of 3.1: Development strategy.
"...In his discussion of ``egoless programming'', Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere. Weinberg's choice of terminology has perhaps prevented his analysis from gaining the acceptance it deserved -- one has to smile at the thought of describing Internet hackers as ``egoless''..."
-- CatB: The Social Context of Open-Source Software (ESR)"...the number of contributors (and, at second order, the success of) projects is strongly and inversely correlated with the number of hoops each project makes a user go through to contribute. Such friction costs may be political as well as mechanical. Together they may explain why the loose, amorphous Linux culture has attracted orders of magnitude more cooperative energy than the more tightly organized and centralized BSD efforts and why the Free Software Foundation has receded in relative importance as Linux has risen."