A maintained reference library, not a glossary.

A large language model is a neural network trained on very large volumes of text to predict the next token in a sequence. That single objective, applied at scale, produces a system that can summarise, translate, answer questions, write code and follow instructions. The model stores no database of facts and performs no lookup at answer time unless it is connected to external tools. It produces the continuation its training makes most probable, which is why output quality varies with how a request is framed.

Last reviewed 2026-09-16

Inference is the act of running a trained model to produce an output. Training is a one-off capital cost; inference is the recurring operating cost, charged per token or per request and repeated every time a user interacts with the system. For most production deployments inference, not training, dominates the bill. Inference cost is driven by model size, input length, output length, hardware utilisation and whether requests can be batched.

Last reviewed 2026-09-16

Fine-tuning continues training an existing model on a smaller, task-specific dataset so that it adopts a particular format, tone, vocabulary or decision pattern. It is well suited to teaching behaviour and poorly suited to teaching facts, which change and are better supplied at request time through retrieval. Modern practice usually uses parameter-efficient methods such as low-rank adaptation, which train a small number of additional weights rather than the whole network.

Last reviewed 2026-09-16

Retrieval-augmented generation is the practice of fetching relevant documents at request time and placing them in the model's context so the answer is grounded in current, verifiable material. It separates knowledge, which lives in a searchable store and can be updated instantly, from reasoning and language, which live in the model. Because the retrieved passages can be cited, retrieval is the standard architecture wherever an answer must be traceable to a source.

Last reviewed 2026-09-16

An AI agent is a system in which a model is given a goal, a set of tools it can call, and permission to run multiple steps without a human approving each one. The model decides which tool to use, reads the result, and decides what to do next until it judges the task complete or a stopping condition is reached. The defining property is not intelligence but delegated control over a sequence of actions.

Last reviewed 2026-09-16

Context engineering is the discipline of deciding what information enters a model's context window on each request, in what order, and in what form. It covers system instructions, retrieved passages, tool definitions, conversation history and output schemas. It matters because a model's behaviour is determined almost entirely by what it can see at that moment, and because every token in the window carries both a cost and a distraction risk.

Last reviewed 2026-09-16

An embedding is a list of numbers that represents a piece of text, an image or another object in a way that places similar items close together. Similarity is measured by the distance or angle between vectors, which allows a system to find related material without matching exact words. Embeddings underpin semantic search, clustering, deduplication, recommendation and the retrieval stage of most grounded AI applications.

Last reviewed 2026-09-16

An evaluation is a repeatable procedure for measuring whether a system does what it is supposed to do. It requires a fixed dataset of cases, a scoring method, a defined number of repetitions and a record of the model version used. Without those four elements a reported number cannot be compared to anything. Useful evaluations are task-specific: general leaderboard scores rarely predict performance on a particular organisation's work.

Last reviewed 2026-09-16

Most enterprise AI pilots fail for organisational rather than technical reasons. The common pattern is a pilot that demonstrates capability without being attached to a process owner, a budget line, an integration path or a measurement plan. When the pilot ends there is no operational home for the system, no agreed definition of success, and no one accountable for monitoring it. Model quality is rarely the binding constraint.

Last reviewed 2026-09-16

Credible measurement compares a defined process before and after deployment, using a baseline captured in advance and a cost figure that includes inference, integration, review labour and monitoring. The strongest evidence comes from holdout groups, where comparable teams continue without the tool. Weaker but common approaches rely on self-reported time savings, which consistently overstate benefit because they measure perception rather than throughput.

Last reviewed 2026-09-16

The model bill is usually a minority of total cost. A realistic budget covers inference, retries and evaluation runs, data preparation and access work, integration engineering, human review, monitoring and incident response, plus the internal time spent on governance and security review. Organisations that budget only for tokens are commonly surprised by a total two to five times larger, most of it labour.

Last reviewed 2026-09-16

Mature buyers run a structured evaluation on their own data rather than accepting a demonstration. The core elements are a representative test set, a written scoring rubric, questions about data handling and retention, evidence of evaluation methodology, an exit path, and clarity on which model versions sit underneath and what happens when they change. Price is compared per unit of completed work, not per token.

Last reviewed 2026-09-16

The recurring risks are prompt injection through untrusted content, excessive tool permissions, data leakage through logs and context, insecure handling of model output that is executed or rendered downstream, and supply chain exposure through third-party models, plugins and connectors. Nearly all serious incidents combine two of these: untrusted input reaching a model that holds credentials broader than the task requires.

Last reviewed 2026-09-16

Answer engines generally run a retrieval step over a search index or a live crawl, select a handful of passages, and generate an answer that cites the documents actually used. Selection therefore depends on conventional retrieval signals, on whether the page states an answer in extractable form, and on crawler access. Published details are limited, and behaviour differs between systems and changes without notice.

Last reviewed 2026-09-16

Recommendations reflect what a model absorbed during training and what its retrieval step surfaces at answer time. Brands that appear consistently across many independent, well-indexed sources in association with a category are more likely to be named. There is no submission process and no verified mechanism to purchase placement in organic answers. Results also vary between runs, so a single observation is not evidence of a stable position.

Last reviewed 2026-09-16

Less stable than search rankings. The same question asked repeatedly within a single session can return different names, because generation samples from a probability distribution and retrieval results change. Across weeks, model updates and index changes add further movement. Any claim about a position in an answer engine should state how many runs it is based on and when they were collected.

Last reviewed 2026-09-16

Answer-engine optimisation is the practice of structuring content so that AI answer systems can find, parse, extract and attribute it. In practice it overlaps heavily with sound technical publishing: crawlable pages, direct answers stated early, clear headings, explicit dates, named authorship, cited sources and machine-readable structure. It is not a separate ranking system and there is no verified mechanism for paying to appear in organic answers.

Last reviewed 2026-09-16

Systems differ in how many sources they cite, whether citations are attached to individual sentences or to the answer as a whole, how heavily they favour large reference domains, and whether they cite at all when answering from parameters. Some surface links prominently, others attach them behind an interface element. Comparisons therefore require identical prompts, recorded dates and per-system counting rules.

Last reviewed 2026-09-16

The Model Context Protocol is an open specification for connecting AI applications to external tools, data and prompts through a common interface. A server exposes capabilities; a client, typically an assistant or agent runtime, discovers and calls them. Its purpose is to remove bespoke integration code so that the same connector works across different applications, in the way a common driver interface serves many programs.

Last reviewed 2026-09-16

Tool calling is the mechanism by which a model requests that the application run a named function with structured arguments. The model does not execute anything itself; it emits a call, the application validates and runs it, and the result is returned into the context for the model to use. It is the foundation of agents, retrieval-on-demand and any workflow where a model must act on live systems.

Last reviewed 2026-09-16

Agent orchestration is the layer that decides what runs, in what order, with what state, and what happens when a step fails. It covers routing between models, managing shared memory, enforcing step and cost budgets, handling retries and approvals, and recording a trace for audit. As deployments move from single calls to multi-step work, orchestration becomes the part of the system most likely to determine reliability.

Last reviewed 2026-09-16

A vector database stores embeddings alongside metadata and supports fast approximate nearest-neighbour search over them. It answers the question which stored items are most similar to this one. Dedicated products exist, but vector indexes are now also available inside mainstream relational and search engines, so the choice is increasingly about operational fit rather than capability.

Last reviewed 2026-09-16

An inference provider runs models on its own hardware and sells access by request or token. Providers fall into three groups: model developers serving their own models, cloud platforms reselling several families, and independent hosts specialising in open-weight models. They differ in price, latency, throughput guarantees, data handling terms, region availability and how much notice they give before a model version changes.

Last reviewed 2026-09-16

Errors compound. If each step in a chain succeeds independently with high probability, overall success falls multiplicatively with the number of steps, so a chain of twenty steps is far less reliable than a chain of four even at a high per-step rate. Long chains also accumulate context, which dilutes attention to the original instruction, and early mistakes are rarely detected because later steps treat prior output as given.

Last reviewed 2026-09-16