Language Models 101

This closing post is the field guide to language-model misconceptions, and its framing is deliberate: almost every misunderstanding comes from importing the wrong mental model. People treat a language model like a search engine that retrieves facts, or like a person who knows, remembers, and reasons. It is neither. It is a next-token predictor.

The power of this single corrective is that it explains every quirk at once. Hallucinations, confident wrong answers, fumbled arithmetic, stale knowledge, and inconsistent outputs all become predictable consequences rather than mysterious failures. The five myths here are the ones that most often lead people to trust the wrong things.

The first and most fundamental myth is that a language model knows facts the way a database does. It does not. It learned the statistical patterns of text, so it reliably reproduces facts that were frequent and consistent in its training data — and just as confidently fabricates ones that were rare, contested, or absent. There is no lookup, no record, no source.

The practical consequence is that fluency is not evidence of accuracy. The model is optimized to produce likely-sounding text, and a smooth, authoritative sentence is exactly what 'likely' looks like whether or not it is true. Treating the model as a fluent guesser rather than an oracle is the foundational mindset that the rest of this post builds on.

This comparison lays the misconception bare by putting what the model actually optimizes next to what users assume it delivers. On the left, the real objective: plausible-sounding, fluent text that matches training patterns and has high probability. On the right, the assumption: verified facts, correct answers, grounded in reality, with high accuracy.

The gap between these two columns is the source of nearly every disappointment with language models. When the two happen to coincide — common, well-documented facts — the model looks like an oracle. When they diverge — niche facts, fresh events, precise reasoning — it confidently delivers the left column while the user expected the right. Keeping this gap in view is the single best defense against being misled.

Hallucination is the most talked-about failure and the most misunderstood. It is not a bug or a malfunction — it is the model functioning exactly as designed. When the model lacks a strong learned pattern for a correct answer, it does not stop or say 'I don't know'; it produces the most probable-looking continuation, which can be an invented citation, a fake API, or a confident falsehood.

The danger is amplified by fluency: a fabricated answer is rendered in the same authoritative tone as a true one, so there is no surface signal that it is made up. This is why factual claims from a model must be verified, and why grounding the model in real retrieved documents is the standard mitigation rather than hoping it 'knows better'.

This snippet illustrates why a hallucination looks so convincing. Asked to cite a paper on a nonsense topic, the model completes the pattern of a citation — author names, a year, a plausible journal — because it has seen thousands of real citations and learned their shape. The format is perfect; the content is pure fabrication.

The comment lines spell out the mechanism and the fix. The model is pattern-completing, not retrieving, so it has no way to know the paper does not exist. The reliable remedies are to give it real sources to work from, as in retrieval-augmented generation, or to verify any factual output against an external source. Never accept a model-generated citation, statistic, or quote at face value.

The third myth is that bigger models are simply smarter, full stop. Scale genuinely helps — post 2 made that case — but it is not the whole story, and treating parameter count as a proxy for reliability leads to bad decisions. A smaller model that has been instruction-tuned, fine-tuned on your domain, or supplied with good retrieved context routinely outperforms a larger raw model on a specific task.

Data quality, alignment training, and prompting often matter as much as raw size. The practical lesson is to choose a model by how well it fits your task and constraints — latency, cost, controllability — not by chasing the largest parameter count. Bigger is a lever, not a guarantee.

The fourth myth is that the model remembers you between interactions. A base language model is stateless: each forward pass depends only on the tokens in the current prompt, and nothing persists afterward. The model does not store your previous questions, learn from your corrections within a session, or carry anything from one API call to the next.

The convincing illusion of memory in chat products comes entirely from the application layer, which stores the conversation and resends the relevant history inside every new prompt. Understanding this is practically important: if you want the model to 'remember' something, you must include it in the context you send. Memory is an engineering feature built around the model, not a property of the model.

This flow diagram shows where 'memory' actually lives in a chat application. The app stores the conversation history, resends it as part of the prompt on every turn, the model reads that prompt and produces a reply, and then the model forgets everything — it keeps no state of its own. The next turn works only because the app sends the history again.

Tracing the loop dispels the intuition that you are talking to something that accumulates knowledge of you over time. Everything the model 'knows' about your conversation is whatever currently fits in the context window being sent. This is why long conversations eventually lose early details: once history is trimmed to fit the window, the model has no other copy to fall back on.

The final myth is that a given prompt has one fixed output. In reality, the same prompt can produce different answers run to run, because sampling is stochastic and temperature controls how much randomness is injected. Users often blame the model for being 'inconsistent' when they themselves set a high temperature, or expect creative variety while running at temperature zero.

The corrective is to recognize that decoding settings shape the output as much as the prompt content. If you need reproducibility, use greedy decoding or fix the random seed and lower the temperature. If you need variety, raise it deliberately. Inconsistency is usually a configuration choice, not a defect, and treating it that way puts you back in control.

This snippet shows how to make generation reproducible, the practical answer to the output-is-not-fixed myth. Setting torch.manual_seed fixes the random number generator, so sampling makes the same 'random' choices every run. Combined with identical decoding settings — same temperature, same top_k, same max_new_tokens — the model produces the exact same output each time.

This is essential for debugging, testing, and any situation where you need deterministic behavior from a sampling setup. It also reinforces the core point: the variability people attribute to the model is really controlled randomness in the decoding step. Pin the seed and the settings, and the 'unpredictable' model becomes perfectly repeatable.

This final list consolidates the fixes for every myth in the post. Verify facts, because the model predicts rather than knows. Expect hallucinations and ground the model with real sources. Choose models by task fit, not just by size. Send the context you want it to use, because the model has no memory of its own. And control temperature and seeds to get the consistency your use case needs.

Five rules, each mapping to one misconception. Internalize them and you stop trusting a language model for the things it cannot do, while fully exploiting the one thing it does brilliantly — generating fluent, plausible text on demand.

This wraps the five-post arc on Language Models 101: the concept, why the simple objective matters, how the pipeline works, hands-on code, and now the misconceptions. The recurring theme is that a language model is a next-token predictor, and almost everything about its behavior follows from that single fact.

Day 60 builds directly on this foundation, moving to how you steer these predictions: prompting techniques and decoding strategies that shape what the model produces. Once you accept that the model predicts the next token, the natural next skill is learning to guide those predictions toward what you actually want.