Tables and Numbers

Tessa pastes last month's bookings into the chat box — fourteen tours, guest counts, revenue per tour — and asks which tour earned the most per guest. Back comes a clear answer, a sensible-looking ranking, and a set of figures that are wrong. Not wildly wrong. Wrong by the amount that survives a glance and reaches a client.

Numbers are where fluent text and correct computation part company, and this is the page that draws the line. The model produces plausible digits the same way it produces plausible words, and knowing that changes what you hand it and what you keep for yourself.

Treat it as a brilliant intern who eyeballs sums. Their "that's roughly sixteen hundred" is genuinely useful, arrives instantly, and saves you from starting at zero. You still put the invoice total through a calculator before it goes out, and you do not feel bad about it.

Why the Arithmetic Wobbles

Chapter 1 said the model predicts the next token, over and over. That is still all that is happening when a sum appears. Given the text "118 times 14 equals", the model continues with a number that fits — one that looks like the right kind of answer in that context. There is no calculation step in the plain model. There is no calculator inside it, and nothing anywhere that checks the result.

This is why the errors look the way they do. Small, familiar sums usually come out right, because those patterns are everywhere in the text it learned from. Long multiplications, columns of a dozen figures, percentages of percentages — those drift, and they drift into numbers of the right size and shape, which is the dangerous kind of wrong. A total that was obviously absurd would be harmless.

Note that this is a different failure from the ones in Chapter 3. A hallucinated hotel is an invented fact. A wrong total is an invented result — arrived at by the same mechanism, and just as fluent about it.

Make It Show Its Work

One request improves this measurably: ask for the arithmetic step by step, one line per step, before the conclusion. Working through the intermediate steps in text genuinely produces better answers than jumping to a total — the steps become part of what the next token is predicted from.

The second benefit is yours. Visible steps give you something to check, and you rarely have to check them all. Find the step the decision rests on — the load-bearing fact from Chapter 3, wearing a number — and verify that one. A ranking built on "revenue divided by guests" needs one division checked to know whether the ranking stands.

There is a wrinkle worth knowing. Some products can run real code to do the arithmetic and show you the computation rather than a prediction of it. When that happens the numbers are as reliable as a calculator's, because a calculator did them. The lesson is Chapter 1's: know which mode you are in. If you cannot tell whether a product computed or predicted, treat it as predicted.

Getting a Table In

Before any of that, the table has to arrive intact, and tables are the most fragile thing you can hand a model. A pasted table survives as text with whatever alignment the paste preserved; an attached spreadsheet or PDF goes through extraction (the first page of this chapter), where columns can smear together and a number can end up in the wrong row.

So run the echo-back check. Ask the model to repeat the first three rows back, with the column headings, before asking it to do anything. Ten seconds, and it tells you exactly what it received. A misread table produces an answer that is confidently wrong for a reason that has nothing to do with the model's reasoning, and the echo-back is the only cheap way to rule that out.

Where the Boundary Sits

The useful split is not "trust it" or "do not trust it" — it is which half of the work belongs to which tool.

Give the model the reading and the writing. Which tours are complained about together, what the pattern across a quarter looks like, how to phrase the finding for a board memo, what the outliers might mean — the model reads tables well and describes them well, and that is real work that used to take an afternoon.

Keep the arithmetic in a spreadsheet. Sums, averages, percentages, anything that will appear in a quote or a report: computed by a tool that computes. Tessa's winning arrangement is both together — the spreadsheet owns the figures, the model drafts the analysis around them, and the two never swap jobs.

That split is the first clean example of a bigger idea. There are tasks this machine is good at and tasks a duller tool does perfectly, and choosing well between them is a skill in its own right. Chapter 10 turns that into a framework; here it starts with a sentence Tessa can hold on to: the model may talk about the numbers, but the spreadsheet owns them.