Let’s be a bit more specific—that is one important point of the article, that as soon as the “Tool AI” definition becomes more specific, the problems start to appear.
We don’t want just a system that finds a route between points A and B. We have Google Maps already. By speaking about AGI we want a system that can answer “any question”. (Not literally, but it means a wide range of possible question types.) So we don’t need an algorithm to find the shortest way between A and B, but we need an algorithm to answer “any question” (or admit that it cannot find an answer), and of course to answer that question correctly.
So could you be just a bit more specific about the algorithm that provides a correct answer to any question? (“I don’t know” is also a correct answer, if the system does not know.) Because that is the moment when the problems become visible.
Don’t talk about what the Tool AI doesn’t do, say what it does. And with a high probability there will be a problem. Of course until you tell what exactly the Tool AI will do, I can’t tell you how exactly that problem will happen.
This is relevant:
Marcus Hutter is a rare exception who specified his AGI in such unambiguous mathematical terms that he actually succeeded at realizing, after some discussion with SIAI personnel, that AIXI would kill off its users and seize control of its reward button.
Please note that AIXI with outputs connected only to a monitor seems like an instance of the Tool AI.
Please note that AIXI with outputs connected only to a monitor seems like an instance of the Tool AI.
As I read Holden, and on my proposed way of making “agent” precise, this would be an agent rather than a tool. The crucial thing is that this version of AIXI selects actions on the basis of how well they serve certain goals without user approval. If you had a variation on AIXI that identified the action that would maximize a utility function and displayed the action to a user (where the method of display was not done in an open-ended goal-directed way), that would count as a tool.
Let’s be a bit more specific—that is one important point of the article, that as soon as the “Tool AI” definition becomes more specific, the problems start to appear.
Sure, but part of my point is that there are multiple options for a Tool AI definition. The one I prefer is narrow AIs that can answer particular questions well- and so to answer any question, you need a Tool that decides which Tools to call on the question, each of those Tools, and then a Tool that selects which answers to present to the user.
What would be awesome is if we could write an AI that would write those Tools itself. But that requires general intelligence, because it needs to understand the questions to write the Tools. (This is what the Oracle in a box looks like to me.) But that’s also really difficult and dangerous, for reasons that we don’t need to go over again. Notice Holden’s claim- that his Tools don’t need to gather data because they’ve already been supplied with a dataset- couldn’t be a reasonable limitation for an Oracle in a box (unless it’s a really big box).
I think the discussion would be improved by making more distinctions like that, and trying to identify the risk and reward of particular features. That would be demonstrating what FAI thinkers are good at.
Let’s be a bit more specific—that is one important point of the article, that as soon as the “Tool AI” definition becomes more specific, the problems start to appear.
We don’t want just a system that finds a route between points A and B. We have Google Maps already. By speaking about AGI we want a system that can answer “any question”. (Not literally, but it means a wide range of possible question types.) So we don’t need an algorithm to find the shortest way between A and B, but we need an algorithm to answer “any question” (or admit that it cannot find an answer), and of course to answer that question correctly.
So could you be just a bit more specific about the algorithm that provides a correct answer to any question? (“I don’t know” is also a correct answer, if the system does not know.) Because that is the moment when the problems become visible.
Don’t talk about what the Tool AI doesn’t do, say what it does. And with a high probability there will be a problem. Of course until you tell what exactly the Tool AI will do, I can’t tell you how exactly that problem will happen.
This is relevant:
Please note that AIXI with outputs connected only to a monitor seems like an instance of the Tool AI.
As I read Holden, and on my proposed way of making “agent” precise, this would be an agent rather than a tool. The crucial thing is that this version of AIXI selects actions on the basis of how well they serve certain goals without user approval. If you had a variation on AIXI that identified the action that would maximize a utility function and displayed the action to a user (where the method of display was not done in an open-ended goal-directed way), that would count as a tool.
Sure, but part of my point is that there are multiple options for a Tool AI definition. The one I prefer is narrow AIs that can answer particular questions well- and so to answer any question, you need a Tool that decides which Tools to call on the question, each of those Tools, and then a Tool that selects which answers to present to the user.
What would be awesome is if we could write an AI that would write those Tools itself. But that requires general intelligence, because it needs to understand the questions to write the Tools. (This is what the Oracle in a box looks like to me.) But that’s also really difficult and dangerous, for reasons that we don’t need to go over again. Notice Holden’s claim- that his Tools don’t need to gather data because they’ve already been supplied with a dataset- couldn’t be a reasonable limitation for an Oracle in a box (unless it’s a really big box).
I think the discussion would be improved by making more distinctions like that, and trying to identify the risk and reward of particular features. That would be demonstrating what FAI thinkers are good at.