# Language Models Are Probability Machines By Rajdeep Mondal. Published 2024-10-21. 5 min read Canonical: https://www.rajdeepmondal.com/writing/language-model-systems-language-models-are-probability-machines Tags: ai, language-models, foundation-models, probability, history, language-modeling > Probabilities over strings, and the decoding dials that turn them into a writer. A language model assigns probabilities to strings. Temperature and top-k then decide whether those probabilities read as deterministic autocomplete or as a stochastic writer. The weights do not move between the two. That definition sounds too small to explain GPT-style behavior. The surprise is how much world structure fits inside one plain objective. ## A Language Model Assigns Probabilities To Strings A next-token distribution is a compressed map of syntax, facts, styles, tasks, and patterns in the training data. Autoregressive language modeling decomposes a sequence into conditional probabilities, one per position. Predict the next token from the tokens before it, then do it again for the position after that. Multiply or sum those probabilities across a sequence and the model scores the text. A sequence score lets you compare two candidate strings under one model. Scoring and writing run on the same conditionals. The corpus decides the shape of that distribution. Frequency in the documents becomes fluency in the output. What the documents never carried is what the model finds hard to say. The data note in this unit opens that question. ## Generation Is A Loop That Eats Its Own Output Generation runs a loop. Condition on the prefix, choose or sample a token, append it, and repeat. The model turns its own output back into its own input at every step. Each appended token joins the next prefix, so a choice made early conditions everything the model writes after it. One low-probability token sampled early becomes a premise the rest of the generation conditions on. The model assigns scores, normalization turns them into probabilities, and a sampler or a search rule chooses what appears. Change any one of those pieces and the same weights behave differently. Temperature and top-k are load-bearing settings. A small change in either one moves the visible personality of the system. Decoding is one field of the interaction contract that the capabilities note in this unit asks you to record. ![One next-token distribution feeds several decoding rules, and each rule turns the same probabilities into different visible text.](https://www.rajdeepmondal.com/static/images/blog/cs324-lecture-1-introduction/fig-01-decoding-forks-the-same-distribution.png) *The weights are identical across these outputs, and the rule that reads the distribution is what changed.* ## Sparse Counts Cannot Generalize, Learned Representations Can Shannon, entropy, n-grams, smoothing, and the early neural language models all wrestled with uncertainty over text. Modern language models inherited that problem and changed the scale, the representation, and the interface. N-gram models expose the old bottleneck. Counts are sparse, so a table of exact strings generalizes badly to a context it never saw. Neural models replace that table with learned representations. Similar contexts then share statistical strength, so an unseen context gets a probability from its neighbors. Scale changed the representation and left the prediction problem where it was. ## Every Visible Token Hides Three Questions Every visible token hides three questions, and asking them blocks a mystical reading of the output. - Distribution: which patterns the model learned from its training data - Context: what information is visible in this prompt right now - Decoding: how the system converts probabilities into text Probability is the clean abstraction and generation is a concrete process. The first question belongs to the model, and the second to the prompt. The third belongs to whoever configured the sampler, and that is usually you. Two of the three are yours to set before you send the prompt. > **Debugging frame** Ask two things of every output: which distribution the prompt created, and which rule turned it into text. ## Debug The Sampler Before You Blame The Model Treating output text as if it came from a mind with stable beliefs is the practical mistake. It came from a distribution under a decoding rule, and that is what makes it debuggable. The easy stopping point is the most fluent sample, read as a belief the model holds. Another rule on the same distribution returns a different continuation, and the uncertainty the fluent sample hid becomes visible. If the answer is too bland, inspect decoding. If it is confidently wrong, inspect retrieval and the evidence in the prompt. Instability across reruns is a different signal, and it points at prompt sensitivity and sampling. The overview note asked you to name the layer that did the work. Here the layers are the model, the context, and the sampler. Start with the sampler. It is the cheapest of the three to change. ## The Builder Test Take one prompt and run it under three decoding settings. Read the three outputs side by side and compare uncertainty, diversity, repetition, and hallucination risk. If all three come back nearly identical, the prompt is doing the constraining and the sampler has little room. Then hold decoding fixed, change one thing in the context, and run it again. That pass measures sensitivity to context. The first pass prices the sampler and the second prices the prompt. Record both settings beside the output, or you keep three samples and no explanation. ## What Carries Text generation is probabilistic conditioning plus a decoding rule. The final text is a system output rather than a property of the weights. Each layer can be tested on its own. A claim about the model that never names the context or the sampler is a claim about one draw. Keep the weights fixed and change the interface around them, and the same distribution reads as a different model.