LibreInfra Field Notes
A large language model predicts language—and that is more powerful than it sounds
An LLM does not retrieve a finished answer from a hidden encyclopedia. It calculates what language is most likely to come next, using patterns learned from enormous amounts of data.
A large language model predicts language—and that is more powerful than it sounds
An LLM does not retrieve a finished answer from a hidden encyclopedia. It calculates what language is most likely to come next, using patterns learned from enormous amounts of data.
Ask a large language model to explain a contract, write a program or compare two infrastructure designs and the response can feel deliberate.
It may define the problem, organise the evidence and end with a sensible recommendation. It can sound as though it looked up the subject, considered several possibilities and selected the best answer.
That appearance is useful. It is also misleading.
The model does not begin with a private conclusion and then translate it into words. It produces the conclusion through the act of generating those words, one small piece at a time.
The central test
To understand an LLM, separate the language it produces from the mechanism that produces it. Fluency is visible. Prediction is underneath.
What the three words actually mean
Language is the material the model processes.
Before text reaches the model, it is divided into tokens. A token might be a whole short word, part of a longer word, punctuation or another recurring fragment. The model does not receive a page in the human sense. It receives a sequence of token identifiers.
Model means a learned mathematical system.
During training, billions of adjustable numerical values—parameters—are changed so that the model becomes better at predicting missing or subsequent tokens. Those parameters do not correspond neatly to individual facts. A specific capital city, programming pattern or grammatical rule is usually represented through relationships distributed across many parts of the model.
Large refers to several forms of scale:
- the number of parameters
- the volume and variety of training data
- the computation used during training
- the infrastructure required to operate the resulting model
A large parameter count does not guarantee a good model. Training quality depends on architecture, data, optimisation and the balance between model size and training tokens. Research on compute-optimal training showed that simply making a model larger while undertraining it can waste compute; the amount of useful training data must grow alongside model capacity. (arXiv)
The Transformer changed how language could be processed
Earlier neural language systems often processed a sequence in order, carrying information from one step to the next.
That made long sequences difficult and limited how efficiently training could be distributed across hardware.
The Transformer architecture, introduced in the 2017 paper Attention Is All You Need, replaced that recurrent sequence-processing pattern with attention mechanisms. Attention allows the model to calculate which other parts of a sequence are relevant while processing a token. It also made much more of the training computation parallelisable. (arXiv)
Consider this sentence:
The server could not reach the storage system because it had lost power.
To interpret “it,” the model must estimate whether the word refers to the server or the storage system. Attention helps the model relate the token to other tokens in the sequence.
The same mechanism operates across much larger contexts. It can connect a function call to its earlier definition, a conclusion to evidence several paragraphs above or a question to relevant instructions near the beginning of the prompt.
Attention is not human attention. It is a learned numerical relationship between elements in a sequence.
But it gives the model a way to build contextual representations rather than treating every word independently.
Training is prediction repeated at enormous scale
A simplified training example looks like this:
Input:
Storage, backup and archive are different ...
Expected next token:
decisions
The model assigns probabilities to possible next tokens. If it gives a low probability to the correct token, the training system adjusts the parameters.
This happens repeatedly across vast collections of text.
The examples do not need to be labelled by hand as grammar lessons, infrastructure explanations or programming tutorials. The prediction objective creates pressure to learn whatever patterns improve the next-token estimate:
- syntax
- spelling
- common facts
- document structure
- code conventions
- rhetorical patterns
- relationships between concepts
- recurring forms of reasoning
The training process compresses regularities from the data into the model parameters.
It does not preserve a searchable copy of every document. It also does not guarantee that the model has learned every pattern correctly.
Frequent, consistent patterns are easier to learn. Rare, contradictory or badly represented material is more difficult. The model can also learn biases, mistakes and undesirable associations present in the data.
Pretraining creates capability, not a finished assistant
The first major phase is usually called pretraining.
The model learns from broad data through a language-prediction objective. A pretrained model may be capable, but it may not behave like a cooperative assistant.
It might continue a prompt instead of answering it. It may imitate an argument instead of evaluating it. It may produce unsafe, unhelpful or irrelevant output because prediction alone does not define what a user wants.
A second phase adapts the model for interaction.
Instruction tuning trains the model on examples of instructions and appropriate responses. Research such as FLAN showed that tuning models across many instruction-formatted tasks improved their ability to respond to previously unseen instructions. (arXiv)
Preference optimisation or reinforcement learning from human feedback uses comparisons between outputs to shape behaviour. The InstructGPT research showed that a smaller instruction-following model could be preferred by human evaluators over a much larger base model, illustrating that size and usefulness are different properties. (arXiv)
The assistant people interact with is therefore usually not just a pretrained model.
It is the result of several layers:
Broad pretraining
|
v
Instruction tuning
|
v
Preference or policy training
|
v
System instructions
|
v
Application controls
Each layer changes behaviour.
None makes the system infallible.
The model does not contain a fact ledger
A database stores records under explicit structures.
An LLM stores learned relationships in parameters.
That difference explains both its flexibility and its unreliability.
A database can usually identify the row from which a value was returned. A language model may produce a correct fact because the relevant pattern was strongly represented during training, but it does not ordinarily know which document established that fact.
It can also combine several learned patterns into a new explanation. This is why it can answer questions that were probably never written in exactly the same form in its training data.
But the same generative ability lets it produce plausible combinations that are wrong.
The model is rewarded for producing a likely continuation, not for attaching every statement to independently verified evidence.
Common mistake
Assuming that fluent factual language means the model retrieved a verified fact.
Better framing
Treat unsupported model output as generated analysis. Connect it to controlled sources when the answer needs evidence, currency or auditability.
Knowledge in the model is frozen and uneven
A model’s parameter knowledge reflects the data and training process used to create it.
After training, it does not automatically absorb new events. A newer runtime, application or chat interface does not update the knowledge encoded in the model weights.
The model may be connected to search, databases or organisational documents, but those are external systems. They supply current context to the model at the time of a request.
Its knowledge is also uneven.
A model may explain a widely documented programming language accurately while struggling with an obscure internal tool. It may understand a general legal concept but miss a jurisdiction-specific exception. It may reproduce a common misconception because the misconception appeared frequently in the source material.
“Does the model know this?” is therefore too binary.
Better questions are:
- Was the subject represented in training?
- Was it represented consistently?
- Is the information likely to have changed?
- Can the answer be checked against an authoritative source?
- Does the task require exact recall or useful synthesis?
Capabilities emerge from combinations of patterns
An LLM can perform tasks for which it was not trained through one dedicated example set.
It can translate, summarise, classify, write code and imitate document structures because those activities share language and reasoning patterns learned during training.
A prompt can also demonstrate a new task:
Input: failed disk
Category: hardware
Input: expired certificate
Category: identity
Input: corrupt backup catalogue
Category:
The model can infer the expected pattern and answer “recovery” or another appropriate category without changing its parameters.
This is called in-context learning.
The model has not permanently learned the new classification scheme. The examples temporarily shape its behaviour within the current context.
That distinction matters operationally.
A useful prompt can make a model perform well during one session. It does not prove that the capability is stable across other prompts, models or versions.
Reasoning models add computation at answer time
A recent development has been the rise of models trained to spend more computation on difficult problems during inference.
Instead of immediately producing a short answer, these models may generate or internally process longer intermediate work, reconsider earlier steps and test alternatives.
Research on DeepSeek-R1 showed that reinforcement learning could encourage behaviours such as self-verification and strategy revision on tasks with verifiable outcomes, including mathematics and coding. The work also showed that some of those behaviours could be transferred into smaller models through distillation. The same paper describes limitations in areas such as tool use and structured output, so its results should not be interpreted as proof of general human-like reasoning. (arXiv)
The important infrastructure change is that model capability is no longer determined only during training.
Answer-time computation becomes another design variable:
- how long the model may work
- how many tokens it may generate
- which tools it may call
- when it should stop
- how much the answer may cost
- whether the intermediate process can be verified
A difficult request may now consume far more compute than a simple one.
“Using the same model” does not necessarily mean using the same amount of infrastructure.
A model should be treated as a versioned artifact
For LibreInfra, an LLM belongs inside an infrastructure map.
The organisation should know:
| Question | Evidence |
|---|---|
| Which model is this? | Exact name, revision, checksum or provider version |
| What may we do with it? | Licence and contractual terms |
| What does it require? | Runtime, hardware, memory and software dependencies |
| What was it approved for? | Intended tasks and explicit exclusions |
| How was it evaluated? | Test set, criteria, results and accepted failures |
| What data reaches it? | Prompt, retrieval, logging and retention policy |
| Can it be replaced? | Alternative model tested against the same evaluations |
| Can it be recovered? | Model artifact, configuration and operating procedure |
This is the difference between experimenting with a model and operating an AI capability.
The model itself may be impressive.
The infrastructure determines whether the organisation can trust, govern and replace the service built around it.
One question for the next AI discussion
Do not begin by asking whether the model understands the subject.
Ask:
Which part of this answer came from learned model patterns, which part came from current evidence, and which part remains an unverified prediction expressed in convincing language?
Make the next decision with clarity