What is an LLM?

An LLM is a large language model: a machine-learning model trained on text to learn patterns that support language tasks. Many generative LLMs produce responses by predicting successive tokens from the input and the text already generated. The model supplies language behavior; an application supplies the surrounding data, permissions, tools and interface.

By Ai Flowi · Published

Here, LLM refers to artificial intelligence. A language model can draft, summarize, classify or help extract information, but a plausible response is not proof of truth. Its behavior depends on the selected model, the request and any evidence the application provides.

What does LLM stand for?

The initials mean large language model. “Language” identifies its text-oriented learning task, while “model” refers to the learned mathematical system used to process inputs. “Large” is a broad description, not a fixed size threshold that makes every model capable of the same work.

A chatbot is an interface for conversation, while an LLM is one possible model behind that interface. A workflow can use an LLM for a single interpretation step without becoming an autonomous agent. An application may also perform useful work through deterministic processing without calling a language model at all.

The existing agent, workflow and chatbot guide explains those product roles. This entry explains the underlying model rather than treating an interface or subscription as the definition of an LLM.

How token prediction produces text

A token is a unit of representation used by the model’s tokenizer. It can correspond to a word, part of a word or another text unit; there is no universal rule that one token equals one word. Tokenization matters when interpreting model input and output limits.

During generation, a model estimates possible next tokens based on its input and preceding generated tokens. The generation procedure selects tokens until a stopping condition applies. The resulting text can be coherent because the model has learned language patterns, yet it can include unsupported details.

A request does not automatically cause a live database lookup. Unless the application supplies retrieved content or a configured tool observation, the model cannot be assumed to have consulted a current source. Its fluent answer should not be mistaken for a report of an external operation.

Training and inference are different operations

Training changes a model’s learned parameters using data and an optimization process. Inference uses a model to process a request. Giving a model a policy passage in a prompt is ordinarily part of that inference input; it is not, by itself, a new training run.

Fine-tuning is a training process applied to a model for a narrower objective. Adding examples to a prompt is instead an in-context technique. Neither description establishes what a provider stores or uses under its service policies; those data-handling terms need their own review.

This distinction helps troubleshoot a document assistant. If a policy changed, the application may need to update the evidence supplied for inference. Rewording the prompt cannot repair a source that was never updated, and uploading a passage does not prove that the model’s learned parameters changed.

Related: Fine tuning and transfer learning: changing weights versus supplying context.

What does an LLM do?

An LLM can turn an unstructured request into a draft summary, classify its intent or propose extracted fields. Consider an invented message: “The meeting room screen stays blank after I connect the cable.” An authored task could ask for a concise problem description and any missing troubleshooting detail.

The target description should preserve the blank screen and cable connection without inventing a hardware fault. “The display needs replacing” would go beyond the supplied message. A useful response can state what is reported while leaving the cause unresolved.

These are examples of tasks and acceptance boundaries, not actual generated responses. For exact arithmetic, fixed validation or a known identifier lookup, use a deterministic operation where it fits. A language model’s flexibility is useful when interpretation is required, but unnecessary interpretation can create avoidable ambiguity.

Related: Generative AI: creating a draft is different from verifying a fact.

Separate the model, application and external data

User request
  → Application: checks access and selects task inputs
  → External data: approved records or tool observations, if needed
  → Model request: instructions plus selected context
  → Generated response
  → Application: validates and presents the result

This is a conceptual architecture diagram, not an executable Flowi graph. The application decides whether a tool is permitted and which data may be included. The model generates text from the request it receives. A reply saying an action succeeded is not evidence that the application actually performed it.

Context limits also belong to the particular model configuration. The input, examples, evidence and generated response must fit its applicable allowance. Context engineering covers selecting that material, while prompt engineering covers the task instructions.

Using a model in AI Flowi Workflow

The Language Model reference explains the component’s request settings and connection types.

For the blank-screen message, decide what the model adds before configuring it. A summary can preserve the reported symptom and identify that the screen model is missing. It cannot inspect the cable or establish a physical diagnosis. Asking for a cause instead of a symptom summary changes the evidence needed, even if the same model processes both requests.

Keep the generated draft and the original report distinguishable. If a technician later finds a loose connector, that observation belongs in a new record with its own source. It should not be retroactively attributed to the earlier model inference. This separation helps explain which statements came from a person’s observation and which came from a language task.

Embedding models serve a representation task rather than writing this summary; the text embeddings entry covers that distinction.

Choose an LLM when interpreting varied wording is useful and the result can be reviewed against the input. A fixed form already containing a symptom field may need no model at all. Changing the provider or model version calls for checking representative messages again: a familiar component name does not establish identical language behavior across configurations.

documented in the catalogue; not production-tested by Ai Flowi

Consult API Hub for access configuration; running the symptom-summary task requires your own model-provider account and API credentials, and you pay for those inference calls separately.

Common mistakes and limits

Do not equate model tokens with workflow billing units, treat a context passage as training, or assume a chat response includes a current lookup. No particular model capability, knowledge cutoff or performance figure follows from the initials LLM.

Use the Agent reference when tools enter the application, and use cases for documented starting designs. The model, its surrounding controls and its source material must each be checked; confidence in the prose cannot substitute for those checks.

Further reading

Google machine-learning resource: introduction to large language models.