Link
AI Forecasting Dictionary

This site uses Just the Docs, a documentation theme for Jekyll.

Search

Open Problems

We’re still in the early stages of experimenting with forecasting dictionaries, and intend to learn as we go and stay receptive to the needs of the forecasting community.

This page lists some current open problems we’re thinking about.

Table of contents

  1. How we should we deal with big, vague, important terms?
  2. How should we deal with terms with free variables?
  3. What is the right long-term data structure for storing the dictionary?

How we should we deal with big, vague, important terms?

Discuss this problem in this GitHub issue.

A key example here is “AGI”, which can be interpreted in many different ways. Approaches include:

Option 1

Using some kind of more granular naming, e.g.

AGI.d1
AGI.d2
AGI.d3

Option 2

Decide on one single definition.

Option 3

Getting rid of big, ambiguous words like “AGI” entirely, replacing them with a larger range of smaller words (e.g. “high-level machine intelligence”, “human-level machine intelligence”, “superintelligence”, etc.)

Option 4

Allowing a tree structure of terms with classes and inheritance, as is done in object-oriented programming.

How should we deal with terms with free variables?

Discuss this problem in this GitHub issue.

Consider the Open Philanthropy Project’s sample definition of “high-level machine intelligence” (HLMI):

A computer system can outperform the median-skilled employee…

  • …for 95% of occupations listed by the U.S. Bureau of Labor Statistics…
  • …with 6 months of training or less…
  • …at 10,000x the cost of the median employee or less

Different choices of input parameters (95%, 6 months, 10000x) can capture very different things,

Option 1

Restrict all future use cases to a particular parameterization.

Option 2

Allow functions in the dictionary, e.g. listing the term as: HLMI(percentage, months, cost-multiple) and writing questions as: By 2029, will we have HLMI(0.95, 6, 10000)? [ai-dict-v1] ___

What is the right long-term data structure for storing the dictionary?

We’re currently using a markdown file as an MVP, but this is very limited in terms of e.g. database functionality.