What is an LLM (large language model)

The adjective “large” describes scale, not quality: the volume of text used in training and the number of parameters adjusted during that process. A parameter is a numeric value inside the network. Its count gives no basis for deducing how useful the system will be on a specific task, and vendors now hardly ever publish it.

Three things that get mixed up in everyday conversation are worth separating. The model is the parameter file plus the code that runs it. The assistant is the product around it: interface, fixed instructions, conversation history, tools. And AI search is a third layer, where the assistant queries a web index before composing an answer. The same question can come out differently at all three.

The other important distinction is temporal. A model is trained on texts up to a cutoff date. Some vendors publish two dates: the one for the training material and an earlier one up to which they consider the information reliable. After that point the parameters hold nothing about your new office, your price change or your rebranding. A system with live retrieval avoids part of the problem because it queries sources at the moment of answering, and it therefore reacts to new facts differently than an isolated model.

Text enters split into units called tokens, which can be a word, a fragment of a word or a punctuation mark. From that sequence the system calculates a probability distribution over the next token, selects one, appends it to the sequence and repeats the operation. The complete answer is the accumulation of those successive decisions.

The selection does not always land on the most probable token. Sampling parameters such as temperature or top-p govern how much accumulated probability enters the draw. At temperature zero the maximum is always taken, and even so two identical calls can diverge: on inference servers the result depends on the size of the batch each request is processed in, and that batch shifts with the load at that instant. In one experiment with a thousand generations of the same text, eighty variants appeared, all identical up to token 103.

The invented statement comes from the same place. There is no query against a database, there is a calculation of a plausible continuation. If barely any material exists about a small brand, the statistically reasonable continuation can be an office, a founder or a product range that never existed, written with the same confidence as a correct detail. Work from OpenAI also points to evaluation methods: when answers are scored as right or wrong, a model that always ventures something scores better than one that flags the lack of a basis, so the procedure rewards guessing.

The first consequence concerns measurement. If the same prompt can return different answers, a single check says nothing about your brand's visibility. It takes repetition, counted frequencies and mention rates over time. Anyone showing a screenshot as proof is showing one throw.

The second concerns content. Because the answer is built by probability rather than by querying a record, company details that appear only once, inside a PDF or embedded in an image, weigh little against those repeated consistently across many citable sources. That turns consistency of name, address, product range and figures into a technical question rather than a cosmetic one.

The third concerns error correction. When a system attributes something false to your company, there is no edit button. Only the available material can be altered: publish the correct version where the system can reach it, get weighty sources to pick it up, and wait for the next training cycle or, with live retrieval, for the next indexing pass. Knowing which of the two cases you face decides whether the fix takes days or months.

• Repeat each query several times and record in how many runs the brand appears, instead of trusting a single answer.
• Record the model, the date and whether the answer carried linked sources alongside every measurement. Without those three details the later comparison is worthless.
• Publish company details as plain text and in the same format everywhere: legal name, address, product range and figures with their date.
• Distinguish in the report between systems with live retrieval and models without web access, because the time until a correction takes effect differs.
• Sample-check what the systems claim about your company and keep dated screenshots, especially before a price or location change.
• Treat every LLM statement about figures, dates or regulation as unverified until one of your own sources confirms it.

• Reading a favourable answer as a position won, when the next call may return something else.
• Comparing measurements from different moments without recording the model version, which the vendor changes without notice.
• Using the parameter count as a quality argument, when that figure says nothing without a task and a measurement method.
• Assuming that a correction published on your site today shows up tomorrow in a model without live access.
• Asking the system for the source of a statement and taking it at face value: the reference can also have been generated by probability.