On the Measure of Intelligence

Chollet starts from a history. AI has long measured progress as skill on specific tasks, and psychology has long argued about whether intelligence is a collection of skills or a general ability to learn. When AI systems beat people at chess or a video game, little general ability came with it, because the skill came from the system's builders (priors) or from vast practice (experience). Either, in unlimited supply, can buy any level of skill while showing nothing about handling the unfamiliar.

So he proposes measuring the conversion rate instead. "The intelligence of a system is a measure of its skill-acquisition efficiency over a scope of tasks, with respect to priors, experience, and generalization difficulty." Two systems with the same priors and the same practice on tasks not known in advance can be compared by the skill they end up with. The paper then defines each term with algorithmic information theory. Generalization difficulty is how much of the shortest solution that works on new situations is not explained by the shortest solution that fits the training situations. Priors are how much of the solution the system already contains. Experience is the new, relevant information the system absorbs during training. Intelligence averages skill times generalization difficulty, divided by priors plus experience, over a scope of tasks.

The third part is a benchmark built to that definition: the Abstraction and Reasoning Corpus. Each ARC task shows a few input and output grids and asks for the output for a new input. Tasks rely only on core knowledge humans have from early childhood: objects, counting small numbers, basic geometry, and goal-directed behavior. There are 400 training tasks and 600 evaluation tasks (400 public, 200 private), each new and hand-made, with about 3.3 demonstrations each. A test-taker gets three attempts per test input. Humans solve most tasks without practice.

Ask what a score cost to produce. A model that scores well on a customer's task after fine-tuning on 100,000 examples, or after a prompt that encodes most of the solution, has bought that skill. That is often exactly what the customer wants. It does not tell you how the system will handle next quarter's new document type, and the proposal should say so.

Test on what the system has not seen. Chollet's distinction between local generalization (new examples of a known task) and broad generalization (new tasks within a domain) is the difference between a held-out test set and a test of new categories. Plan both when the customer expects the system to adapt.

Count your priors honestly. In a deployment, priors are the rules, templates, tools and prompts the team writes. Our toy shows the trade: the right primitives let a solver learn from one example; a missing primitive caps performance no matter how many examples arrive. Adding the right tool often beats collecting more data.

Treat benchmark claims of reasoning skeptically. ARC exists because high scores on knowledge-heavy benchmarks can come from memorized patterns. When a vendor claims reasoning, ask for results on tasks built to be new, with a private test set.

Keep a private evaluation set. ARC's private 200 tasks make it impossible for developers to tune to the test. A customer's golden set should be private for the same reason.