AI glossary

A model trained on large volumes of text to predict the next token in a sequence. That single capability, applied at scale, produces summarisation, classification, extraction, code generation, and conversation.

The model is rarely the hard part of a project. The systems around it are.

The unit a language model reads and writes. A token is roughly three quarters of an English word. Pricing, rate limits, and context windows are all measured in tokens.

Token counts drive both your latency and your bill.

The maximum number of tokens a model can consider at once, covering the prompt, any retrieved documents, the conversation so far, and the response.

A large context window is not a substitute for retrieval. Filling it with marginally relevant text usually lowers answer quality and raises cost.

A numeric vector representing the meaning of a piece of text, so that texts with similar meaning sit close together in vector space. Embeddings are what make semantic search possible.

Continuing training of a base model on your own examples so it adopts a specific format, tone, or narrow task behaviour.

Fine-tuning teaches behaviour, not facts. If the goal is for a model to know your documents, retrieval is usually the cheaper and more maintainable answer.

See also: Prompting, RAG, or fine-tuning?

Designing the instructions, examples, and output format given to a model so it produces reliable results. In production this means version-controlled, tested prompts, not text pasted into a chat box.

Constraining a model to return data in a defined shape, usually JSON matching a schema, so downstream code can consume it without parsing prose.

Most integration bugs in LLM features come from free-text responses that code has to guess at.

A fluent, confident model output that is not supported by any source or by fact. It is a property of how these models generate text, not a bug that gets patched out.

You do not eliminate hallucination. You constrain it with retrieval, citation, confidence thresholds, and human review on the paths where being wrong is expensive.

A setting controlling randomness in a model's output. Lower values make responses more deterministic and repeatable, higher values more varied.

A model that accepts more than one kind of input, typically text plus images, and sometimes audio, video, or documents.

A pattern where the system searches your own content for passages relevant to a question, then gives those passages to a language model to answer from. The model supplies the language, your data supplies the facts.

RAG is how most enterprises get an AI system that answers from their documents without retraining a model.

See also: RAG systems and knowledge AI, RAG evaluation metrics that matter

Splitting source documents into passages small enough to retrieve precisely and large enough to stay meaningful on their own.

Chunking strategy affects answer quality more than the choice of model in most RAG builds.

A database that stores embeddings and retrieves the nearest matches to a query vector, enabling search by meaning rather than by keyword.

Search that matches on meaning rather than exact words, so a query for 'time off policy' can find a document titled 'annual leave entitlement'.

Combining keyword search with semantic search, then merging the results. Keyword search catches exact identifiers and codes that embeddings often miss.

A second pass that reorders retrieved passages by relevance to the specific question, usually with a model built for scoring rather than generation.

Reranking is often the cheapest single improvement available to a RAG system that returns roughly right but not quite right answers.

Tying every claim in a generated answer to a retrieved source, so the answer can be checked rather than trusted.

Designing a system so that each statement it produces carries a link to the source document, section, or record it came from.

In regulated work, an uncited answer is unusable regardless of whether it happens to be correct.

A system where a language model chooses actions, calls tools or APIs, observes the results, and repeats until a goal is met or it stops. The distinguishing feature is that the model decides what to do next, rather than following a fixed script.

See also: AI agents and automation, Agentic AI vs AI agents, explained

A broader description of systems that pursue goals over multiple steps with some autonomy, usually coordinating several agents, tools, and checkpoints. Agentic AI describes the overall approach, an AI agent is a component within it.

See also: Why agentic AI fails in production

Giving a model a set of functions it can invoke, with defined inputs and outputs, so it can query a database, call an API, or trigger a workflow instead of only producing text. Also called function calling.

The layer that controls how a multi-step AI process runs: what happens in what order, what state carries between steps, what to do on failure, and when to stop.

Most production agent incidents trace back to orchestration and tool failure handling, not to the model.

An architecture where several specialised agents handle different parts of a task and pass work between them, often with a coordinator.

More agents means more failure surface. It is worth it when tasks genuinely differ, and costly when a single well-scoped agent would do.

See also: Multi-agent systems that survive production

A design where a person approves, edits, or overrides an AI decision before it takes effect, usually on the actions that are expensive or irreversible.

See also: Designing human-in-the-loop workflows

The defined route an AI system takes when it is not confident enough to act, handing the case to a person with the context already assembled.

An agent without an escalation path does not fail safely. It guesses.

How much an AI system is permitted to do without approval, ranging from drafting a suggestion, to acting with review, to acting unattended within set limits.

A repeatable test suite for an AI system: a fixed set of inputs, expected properties of a good answer, and scoring that runs automatically whenever anything changes.

Without one, you cannot tell whether a prompt change or model upgrade improved the system or quietly broke it.

A curated set of representative inputs with reviewed, correct outputs, used as the benchmark an AI system is measured against over time.

Using a language model to score another model's outputs against written criteria. Useful for grading qualities that are hard to check with exact matching, provided the judge is itself validated against human ratings.

See also: LLM-as-a-judge in practice

A measure of whether the claims in an answer are actually supported by the retrieved sources, as distinct from whether the answer sounds right.

A measure of whether a response actually addresses the question asked, independent of whether the underlying facts are correct.

The set of cases re-run before every release to confirm that behaviour which used to work still works.

Attaching a calibrated score to a system's output so low-confidence cases can be routed to a human instead of returned to a user.

The operational practice of running language-model systems in production: versioning prompts and models, evaluating continuously, tracing requests, monitoring quality and cost, and managing rollout and rollback.

See also: AI integration and LLMOps

Being able to see what an AI system did and why: the prompt, the retrieved context, the tool calls, the response, the latency, and the cost, for any individual request.

When a user reports a bad answer, observability is the difference between diagnosing it and guessing.

Recording each step of a multi-step AI request as a linked trace, so a failure can be attributed to the specific retrieval, tool call, or generation that caused it.

Checks applied to what goes into and comes out of a model: input validation, output schema enforcement, content filtering, and refusal handling.

An attack where instructions hidden in content the model reads, such as a web page, document, or email, cause it to ignore its original task and follow the attacker instead.

Any system where a model reads untrusted content and can also take actions needs to be designed against this from the start.

See also: Prompt-injection defense checklist

Deliberately attacking your own AI system before release to find the inputs that make it behave unsafely, leak data, or produce unacceptable output.

Detecting and removing personally identifiable information from text before it is sent to a model or stored in logs.

A decline in system quality over time as real inputs move away from what the system was built and tested against, or as an underlying model version changes.

The all-in token and infrastructure cost of answering one request. Tracking it per feature is what keeps an AI product economically viable at scale.

See also: Cost optimisation for LLM workloads

The requirement that data be stored and processed in a specific country or region, which constrains where models can run and which providers can be used.

An audit standard covering how a service organisation handles security, availability, processing integrity, confidentiality, and privacy. Type I assesses the design of controls at a point in time, Type II assesses their operation over a period.

See also: Trust and security

The smallest deployed version of a product that real users can use and that produces real signal about whether the idea works.

An MVP is deployed and used. A prototype that never leaves staging tells you very little.

See also: MVP in 24 hours

A narrow build whose only job is to answer a specific technical question, such as whether retrieval over a document set is accurate enough to be useful.

A limited production deployment with a real but bounded user group, used to measure impact before committing to a full rollout.

See also: Evaluating AI pilots before you scale

A project scoped in detail up front and delivered for a fixed price or against an agreed ceiling, with change control for anything outside the original definition.

A recurring monthly engagement where a dedicated team continues to build and operate your product, rather than delivering once and leaving.

Placing senior engineers inside your existing team, working in your processes, your repository, and your standups, under your technical direction.

It suits teams that have direction and need capacity. Teams that need someone to own an outcome are usually better served by a scoped project.

See also: Staffing

The contractual assignment of ownership of everything built during an engagement to the client, including source code, models, and documentation.

See also: Trust and security

The document defining what will be delivered, on what timeline, at what price, with what assumptions, and how changes are handled.

The structured transfer of a delivered system to the client team: documentation, runbooks, infrastructure access, and a working session so the team can operate it without the original builders.

The part of the working day when a distributed team and its client are both online for real-time collaboration, with the rest of the work handed off asynchronously.

See also: How we work