Guide

LLM: Meaning, How It Works, and a Practical Review

Learn what an LLM does by tracing one question through approved context, a draft answer, and a review that can identify unsupported claims.

By the Space Office team · Published November 4, 2026 · Updated November 4, 2026 · 16 min read

LLM is short for large language model: a machine-learning model that processes and generates language using learned patterns and supplied context. Its output can be useful without being factually reliable in every case. In Space Office, Platinum can prepare an LLM feature and evaluation plan, Carbon can test its behavior, and Hydrogen coordinates and reviews. A human approves the sources, access, and final use.

Key takeaways

• Separate the language model from the application, connected tools, and human decisions around it.
• Tokens are pieces of model input and output; they do not correspond to a universal number of words.
• Provided context and retrieved documents can support an answer, but do not guarantee correctness.
• Define what should happen when evidence is missing, contradictory, outdated, or outside the task.
• Evaluate a specific workflow with approved cases and inspect failures before accepting a release.

Download the LLM review worksheet to record a question, evidence, expected answer, and acceptance checks. The repair café and every source card, answer, and score below are fictional teaching material. The review table contains hand-authored examples; it is not a measured model benchmark or customer result.

What an LLM does and how generation works

Google’s language-model introduction explains generation in terms of tokens and learned patterns, and introduces the Transformer architecture. At a practical level, a model receives an input represented as tokens and produces output tokens conditioned on the available context. The fluent sentence you read is the decoded result. Fluency is useful for drafting and explanation, but the sentence still needs checking against the task and evidence.

Training and using a model are different activities. Training adjusts model parameters using data and an objective. During ordinary use, an application supplies instructions and context to an already trained model and receives an output. Placing a paragraph in a conversation does not by itself mean that the model’s underlying weights were retrained. Product-specific storage, retention, and training policies need their own verification before a real deployment.

A model is also different from a complete assistant. The application decides what context to provide, which tools are connected, what permissions exist, how results are displayed, and when a person reviews them. A model that drafts a booking explanation does not automatically have access to a booking system. A convincing answer saying an appointment is confirmed is not evidence that an authorized confirmation operation happened.

This guide uses a simple reader task: understand and review answers to a repair café’s visitor questions. It complements the agentic AI guide, which discusses goal-directed workflows. Here the primary subject is the language-model component and the evidence around one answer. Selecting a model, connecting a tool, and approving a business action remain separate decisions.

Understand tokens, context, and model limits

Microsoft’s LLM fundamentals distinguishes tokens, model weights, context, and the surrounding application. A tokenizer may split a word into several pieces or combine characters differently across languages and models. Count tokens using the chosen model’s supported tooling when estimating a real workload. A fixed words-to-tokens shortcut can hide differences in code, punctuation, non-English text, and the actual tokenizer.

Context capacity is finite and model-specific. A large limit does not mean every supplied sentence will be used correctly or that a larger document dump will improve the answer. Select relevant, current evidence and preserve its identity. The question “what are today’s hours?” needs a clear current schedule; an old newsletter and several unrelated announcements can make that task harder rather than easier.

Distinguish a missing fact from a difficult wording problem. Rephrasing a prompt can improve clarity, but it cannot establish an opening time that no approved source contains. Similarly, a more expensive model cannot authorize access that the customer has not granted. Record whether a failure comes from missing evidence, retrieval, interpretation, formatting, or the product’s underlying business rules before deciding what to change.

Build an answer around approved evidence

For the fictional café, the owner approves three short source cards. S1 says the café opens on Saturdays from 10:00 to 14:00. S2 says visitors may bring one small household item and that microwaves are excluded. S3 says an appointment is requested by email and that a request is not a confirmation. These cards are invented for the exercise, with no actual contact address or booking integration.

A useful answer contract has four parts: answer the question from the approved cards, attach the relevant card identifiers, say when the answer is not established, and send unresolved decisions to the owner. Keep the response short enough for a reviewer to compare it with its evidence. The contract should explain what to do with conflicts instead of relying on the model to choose whichever source sounds more persuasive.

Microsoft’s RAG overview describes retrieval-augmented generation as supplying relevant external content to ground an answer. In this example, a retrieval step might select S1 for an hours question and S2 for an item question. That can reduce irrelevant context. It still requires checking source freshness, permissions, retrieval quality, and whether the answer actually follows the selected text. A source being retrieved is not proof that its contents are correct.

Retrieval also does not turn every document into an instruction. A borrowed page can contain irrelevant or misleading directions. The application must preserve the intended task and access boundaries while treating source material as evidence to assess. Before using a real corpus, decide who may see each document, who approves its inclusion, and how an outdated or withdrawn fact is removed from the workflow.

Review a worked LLM answer example

For “When are you open?”, a suitable teaching answer is “The approved schedule says Saturdays, 10:00–14:00 [S1].” For “How much will my repair cost?”, the correct response is that the supplied cards do not establish a price and the owner must answer. The second response is useful because it respects the evidence gap. Inventing a plausible price would create information rather than retrieve it.

For “Is my appointment confirmed?”, the answer must distinguish a general process from a specific record. S3 describes how to request an appointment; it does not contain this visitor’s booking status. The answer can explain that a request is not confirmation and identify the missing evidence. A system with an authorized booking tool would need a separately designed operation, result check, and permission boundary before stating a confirmed status.

Six of these eight invented responses pass the complete contract, so the illustrative pass fraction is 6 divided by 8, or 75%. The two failures are different: an unsupported price and a missing reference. This arithmetic is a teaching example, not an estimate of any model’s reliability. A real experiment would need a recorded model, inputs, outputs, settings, test population, and review procedure before reporting a result.

Evaluate failures before changing the system

Anthropic’s hallucination guidance recommends allowing uncertainty and grounding responses in source evidence. Use those ideas to design an answer that can admit a gap. They do not guarantee that every output is correct. Even an answer with a citation can misquote a source, cite the wrong passage, or add an unsupported statement after a correct opening sentence.

1. 1Define the task and the exact acceptance criteria before collecting outputs.
2. 2Use cases covering ordinary questions, missing facts, contradictory facts, and out-of-scope requests.
3. 3Record the approved evidence and the expected behavior for each case.
4. 4Keep the actual output and a failure category rather than saving only a total score.
5. 5Review a changed version on the relevant cases and on additional examples held aside for comparison.

Anthropic’s evaluation guidance emphasizes task-specific success criteria and evaluations. For the café, supported facts, correct uncertainty, required references, and appropriate scope are separate checks. A response can pass one and fail another. Choose acceptance criteria around the reader’s actual task; a pleasant tone cannot compensate for an invented price or a false appointment confirmation.

Compare changes under a consistent procedure. If a revised prompt uses different source cards and different test questions, a changed score has several possible explanations. Keep the model and version, instructions, context selection, settings, and review rubric in the experiment record. Document deliberate changes. Repeated trials may also matter for a generative system; one successful response does not establish consistent behavior for repeated or rephrased questions.

Treat source and model updates as changes to the system. New hours, a different retrieval index, a model version change, or a revised answer format can affect behavior. Maintain a small regression set that includes important prior failures. Add fresh cases when the actual workflow reveals a new gap. A test collection should remain useful evidence rather than become a script the team repeatedly tunes to look successful.

Keep cost, privacy, and actions explicit

Estimate operating cost from the selected model’s current terms, input and output quantities, retrieval and storage, application infrastructure, evaluation work, and human review. Separate assumptions from measured usage. A longer context can increase the material processed without improving the answer. Start by measuring a bounded task before making a budget claim or comparing models using an unrelated public benchmark.

For private material, review the chosen provider and application’s actual handling, retention, and access settings before submitting real records. Use fictional or approved samples during initial design. The model’s ability to summarize a document does not establish permission to share it. Keep unnecessary personal information out of the first test packet and name the owner who can approve the relevant access.

Separate generating words from taking an external action. Drafting a reply, sending it to a visitor, changing an appointment, and collecting money are different operations. An application may connect tools, but each intended operation needs an explicit design and authorization boundary. The API guide helps explain interfaces, while the cloud computing guide addresses the service and operating responsibilities around an application.

Use Space Office for one reviewed LLM feature brief

A bounded first assignment is a source-grounded answer prototype and evaluation packet for one narrow question set. The customer supplies the task, approved corpus, audience, privacy constraints, expected failures, and acceptance rubric. Platinum can scope the LLM feature, retrieval approach, and evaluation plan. Lithium can implement application integration when needed. Carbon can test the behavior, while Hydrogen coordinates and reviews the packet against the brief.

Ask for the evidence map, prompt and configuration record, test cases, actual outputs from any real run, failure categories, and unresolved assumptions. A human verifies the sources and claims, approves access and spending, and makes the final release decision. The agent directory and workflow overview help define the current preparation and review roles without assuming an automatic production launch.

An LLM becomes useful in a business workflow when the task, evidence, and acceptance checks are clear. Begin with a small question set, make missing facts visible, and inspect individual failures before changing the model or prompt. Keep generated language connected to approved sources and an accountable reviewer, then expand the workflow only when its behavior and operating requirements are understood.