Factuality on Programmer.ie: Modern AI programming

When Models Make Things Up

Sat, 29 Aug 2026 22:10:00 +0100

A language model can produce an answer that is fluent, grammatical, detailed, confident, and wrong.

That combination is what makes hallucination interesting.

Ordinary software failures usually leave evidence. A parser throws an exception. A database rejects an invalid constraint. A test fails. A network call times out. The failure changes the shape of the result.

A hallucinating language model can do something more difficult to handle: it can fail without looking broken.

Hallucination Is Not One Thing

Sat, 29 Aug 2026 22:45:00 +0100

Chapter 1 began with a familiar failure: a language model says something fluent that it cannot justify.

That description is useful until we try to build a detector.

Consider six outputs:

A. The model invents a person who does not exist.

B. The model names two real companies but reverses which acquired which.

C. The model cites a real paper that does not support the claim.

D. The model says it inspected a file that it never received.

E. The model answers a question even though the available evidence is insufficient.

F. The model gives the same generic recommendation after the decisive facts
   of the problem have been reversed.

All six can produce plausible text.

Evidence, Truth, and Verifiability

Sat, 29 Aug 2026 23:20:00 +0100

Chapter 2 gave us a rule for talking about hallucination precisely:

Relative to what reference did the output fail?

That question immediately creates another one.

What counts as a reference strong enough to constrain the answer?

Suppose a model says:

Company A acquired Company B in 2024.

There are several different things we might mean when we ask whether this is acceptable:

What exact proposition has been asserted?

Is that proposition true at the relevant time?

Do we possess evidence for it?

Does that evidence actually support this exact relationship?

Can we identify the source and passage that support it?

Where did that source come from?

Is the source sufficiently reliable and current for this claim?

Is the evidence package sufficient for the action we want to authorize?

Could the claim be verified by this system now?

Has the verification actually been performed?

Would the active policy allow the claim to be published or acted upon?

Those questions are related.

How Do You Measure a Hallucination?

Sat, 29 Aug 2026 23:14:00 +0100

The first three chapters deliberately avoided building a detector.

Before designing one, we needed to define exactly what it would be expected to detect.

Chapter 1 established that fluent generation can continue after evidential support has weakened or disappeared.

Chapter 2 showed that hallucination covers several different failure relationships.

Chapter 3 then separated the objects a reliability system must not collapse:

truth
≠
evidence
≠
support
≠
attribution
≠
provenance
≠
verification
≠
policy acceptance

Now we can finally ask the engineering question: