AI Hallucinations: Why They Happen and How to Reduce Them

Parts 4 and 7 both flagged this briefly. This part covers it fully — a real, precise explanation of why hallucination happens at all, and concrete, practical techniques for reducing it in a real application, since it's genuinely one of the most important failure modes to understand before shipping anything built on an LLM.

A real, precise definition

Hallucination: a model generating text that's fluent, confident, and
  plausible-sounding, but factually incorrect or entirely fabricated

Real, illustrative example: asked about a Bright Leaf Coffee
  subscription plan that doesn't actually exist, a model without
  proper constraints might confidently describe fabricated real
  pricing and features, rather than saying it doesn't have that
  information

Why this happens: a direct consequence of part 4's mechanism

The model was never trained to verify truth against a real, external
  source at generation time — it was trained to predict the
  statistically PLAUSIBLE next token, based on patterns in its real
  training data

This is the real, honest, technical root cause — nothing about the generation process described in part 4 involves fact-checking. A fabricated, plausible-sounding plan name and price is, from the model's actual mechanism, simply a statistically reasonable continuation of the conversation, generated exactly the same way a factually correct answer is generated — the process itself has no real, built-in mechanism to distinguish the two.

Why hallucination is genuinely worse for specific, real facts

Lower real hallucination risk: broad, general knowledge well-
  represented across a model's real training data (how coffee
  roasting generally works)
Higher real hallucination risk: specific, narrow, or private real
  facts NOT actually present in training data (Bright Leaf Coffee's
  exact current subscription prices, which the model was never
  trained on at all)

This is directly why part 5's training-cutoff limitation and hallucination are closely related, real phenomena — a model has no real training data at all about a specific business's private, current information, so any confident-sounding answer about it is necessarily fabricated, not recalled, unless that real information was explicitly provided in the prompt.

Real, practical technique 1: ground the model in real, provided data

Higher-risk prompt: "What subscription plans does Bright Leaf Coffee
  offer?" (relying entirely on the model's non-existent training
  data about this specific, real business)

Lower-risk prompt: "Using ONLY the plans listed below, answer the
  customer's question: [real, actual plan data included directly]"

This directly restates part 9 and part 19's core principle, framed specifically as a hallucination countermeasure — explicitly providing the real, actual facts needed in the prompt removes the model's need to generate them from (nonexistent) training knowledge at all, which is genuinely the single most effective, practical mitigation available.

Real, practical technique 2: explicit permission to say "I don't know"

"If the provided information doesn't answer the customer's question,
say so directly and offer to connect them with a real person —
never guess or invent a real answer."

A model's fine-tuning (part 6) generally shapes it toward being helpful and providing a real, direct answer — which, without an explicit real instruction otherwise, can bias it toward generating a plausible-sounding guess rather than admitting uncertainty. Explicitly permitting (and directing) an "I don't know" response is a real, effective, testable technique for reducing confidently-wrong output.

Real, practical technique 3: lower temperature for factual tasks

Higher temperature (more random sampling, part 4): better for
  creative, open-ended real tasks
Lower temperature (closer to always picking the most likely token):
  better for factual, precise real tasks — reduces variability, and
  correlates with somewhat reduced fabrication risk

Most real APIs expose a "temperature" parameter controlling how much real randomness part 4's sampling step uses — worth setting lower for a real, factual application like Bright Leaf Coffee's support assistant, and higher for a genuinely creative use case where varied, novel output is actually desirable.

The real, honest limit: hallucination can't be fully eliminated

Every real technique in this part REDUCES hallucination risk — none
  of them, even combined, GUARANTEES it never happens

This is worth stating plainly rather than overselling any single technique: even with real, grounded data, explicit uncertainty permission, and low temperature, a production application handling anything genuinely consequential (medical, legal, financial) needs additional real, human review — a mitigation strategy, not a guarantee, which is the same honest framing this entire series takes toward AI capability generally.

Next: what an AI API actually is — the real, practical interface every technique covered so far gets sent through in actual code.