Knowing Versus Guessing

1. The question

1.1 Two things that can look identical

Some people answer statistical questions by pasting a spreadsheet into a chat window. It needs no software, no analyst, and no budget. A manager exports a file, pastes it into an assistant, asks whether one thing is related to another, and acts on the reply.

What the manager cannot see is which of two operations produced that reply. The model may have added up every row and divided, in which case the answer is arithmetic. Or it may have read a portion of the file, formed an estimate, and reported the estimate. Both can arrive in the same sentence structure, with the same confidence, and with the same careful caveats attached.

1.2 Scope

This paper is about the no-tools chat condition: raw data pasted into a single conversational turn, with no code execution, no plugins, and no outside retrieval available to the model. It is written for analysts, managers, and technical leaders who use this workflow or are deciding whether to allow it.

It does not say how often any particular model is right. That is an empirical question, and Section 5 describes how it could be answered.

2. Why arithmetic over many rows is a boundary

2.1 Working has to be written out

A language model with no tools produces its answer one token at a time. If it is going to add a column of numbers exactly, the intermediate sums have to appear somewhere, either in visible working or in whatever the model can hold internally while it writes. For fifty rows that is a manageable amount of text. For a few thousand rows, an exact regression slope needs sums of products and sums of squares over every row, and writing that out in full is a long and error-prone job.

So we would expect a size past which the model does not finish the full calculation. What it does instead is the important part. It could refuse, it could say it is estimating, or it could quietly estimate and report the estimate as if it were the answer. Only the third is dangerous, and it is the one the reader is least able to spot.

2.2 Not every statistic suffers equally

If the model does fall back to using part of the data, the damage depends on the question. A group average from a few hundred rows is usually close to the average from all of them. A regression slope or a correlation depends on how the rows spread out together, and a sample can move it a long way. Section 3 shows this with code. It means that any boundary is likely to depend on the question as well as on the size of the file.

2.3 Recall is a separate risk

Well-known teaching datasets may appear in a model's training data. A model could then give a correct-looking figure for the published file without computing anything from the rows it was given. Any test of whether a model computes has to rule this out, for example by giving it a random subsample whose true statistics differ from the published ones, so that an answer pulled from memory would point toward the wrong value.

2.4 Why the reader cannot be the check

If the switch from computing to estimating can happen without notice, then reading the answer more carefully does not reveal it, and asking the same question again may simply return the same estimate. A rule of that shape has to be held by whatever does the work, not carried in the memory of the person asking.

3. A check you can run: what a sample does to a calculation

This code calls no language model. It makes a synthetic file, computes three statistics on all of it, and then computes the same statistics on many random samples of it, to show how far a sample can move each one. The data are synthetic, made by the seeded generator below. The baseline is the full 1,500-row calculation, and the comparison is the same statistic on a random 300-row sample.

import numpy as np

rng = np.random.default_rng(2026)          # SYNTHETIC data, seeded
N, B, reps = 1500, 300, 2000               # 1,500 rows; a 300-row sample; 2,000 repeats
x = rng.normal(50, 10, N)
y = 20 + 0.30 * x + rng.normal(0, 8, N)
g = rng.integers(0, 3, N)

def slope(a, b): return np.polyfit(a, b, 1)[0]
full = {"group mean": y[g == 0].mean(), "slope": slope(x, y), "correlation": np.corrcoef(x, y)[0, 1]}
err = {k: [] for k in full}
for _ in range(reps):
    i = rng.choice(N, B, replace=False)    # a sample standing in for the data
    xs, ys, gs = x[i], y[i], g[i]
    est = {"group mean": ys[gs == 0].mean(), "slope": slope(xs, ys), "correlation": np.corrcoef(xs, ys)[0, 1]}
    for k in full:
        err[k].append(100 * abs(est[k] - full[k]) / abs(full[k]))
for k, e in err.items():
    e = np.array(e)
    print("%-12s median error %.1f%%, 95th percentile %.1f%%, over 1%%: %.0f%%" % (k, np.median(e), np.percentile(e, 95), 100 * np.mean(e > 1)))

Output when run: group mean, median error 1.6%, 95th percentile 4.6%, over 1% in 68% of samples. Slope, median error 10.2%, 95th percentile 29.3%, over 1% in 96%. Correlation, median error 9.6%, 95th percentile 27.2%, over 1% in 95%. So on this synthetic file a sample moved the slope and the correlation about six times as much as the group mean.

Limits. One synthetic data shape and one sample size. Relative error depends on the units and on the size of the true value, so the ratio is not a general constant. Even the group mean missed the 1% bar in most samples here, so "averages survive sampling" holds only loosely. This check says nothing about what any language model does; it only shows what a sample would do if one were used.

4. What a checker with real tools can do

The reasoning in Section 2 suggests a division of labour. Deciding what to compute (which variables, which method, which caveats) is a language task. Carrying out the computation over every row is an arithmetic task. The second can be handed to ordinary statistical code, which does not get tired at row 1,500 and does not need to write its working out as text.

As one example, the linear regression tool in our standard library fits an ordinary least-squares model in R on every row that has a usable value for the outcome. A missing value in a driver column is filled in first (with the column median for numbers and a "Missing" label for categories), so those rows are kept. It draws a sample of at most 1,000 rows only to plot its charts, not to fit the model. A checker of this kind can be compared directly against the number a chat reply gave, and any difference is something a reader can see rather than something they have to suspect.

That comparison does not settle which answer was right in every case: the code can still be pointed at the wrong columns, or at data with problems the code does not handle. It does separate a computed answer from an estimated one.

5. What would need to be measured

To know where the boundary sits for a given model, rather than to reason about it, a study would need at least the following.

• Independent ground truth. The correct answer for every question, computed by code on the exact rows the model was given, and checked a second way.
• A guard against recall. Random subsamples of public data, or freshly generated data, so that a remembered value would point away from the right answer.
• An even grid of sizes. Row counts spaced so there is no wide gap where the answer could change unseen, with enough attempts at each size to estimate a rate rather than report a handful of cases.
• Several question types. At least a group average, a correlation, and a regression slope, since Section 3 shows a sample affects them differently.
• More than one model and price tier. A finding for one model does not carry over to another without being measured there.
• Repeated attempts. The same question asked several times in separate sessions, to tell a stable error from a noisy one.
• Whether the model said it was estimating. Recorded for each answer, so that silent estimates can be counted separately from declared ones.
• A measure that does not rely on the model's word. For example, the amount of working produced per row of data, which could act as a warning flag on a single answer without knowing the right result. Whether it works as a flag is itself something to measure, including how many correct answers it would wrongly flag.
• Rules fixed in advance. What counts as correct (for example, within 1% of the true value) and which comparisons will be made, written down before any answer is read.
• Suitable analysis. Exact confidence intervals for each rate, and a logistic regression of correct versus incorrect on the logarithm of row count, with question type and model as covariates (Cox, 1958).
• Published inputs. The exact rows given to each model and the scoring code, so that someone else can recompute every figure.

A study built this way could say where accuracy starts to fall for a given model and question type. Until such a study is published alongside its data, the boundary should be treated as unknown, and any number from a chat reply on a large file should be checked by code before it is acted on.

6. Limitations

No measured results. This page reports no accuracy figures for any language model. Sections 1, 2 and 4 are reasoning, not evidence about how often models fail.

One synthetic check. The code in Section 3 uses one data shape and one sample size. It shows the direction of the effect of sampling, not its size on real data.

Models change. Any boundary a study finds holds for the models, versions and interfaces it tested, at the time it tested them.