Understanding LLM Request Components

Welcome. This course builds from the basic LLM request toward a complete RAG system: first, what an LLM receives when it answers; later, how an application finds external documents and adds them as evidence.

In this lesson, you will learn to identify the four practical parts of an LLM interaction:

1. System instructions set the behavior and constraints.
2. User input states the immediate request.
3. Context supplies additional information the model can use.
4. Model output is the generated answer.

This distinction is essential for understanding RAG: RAG does not magically change the model’s built-in knowledge. It supplies useful external information as context before the model generates its answer.

---

One LLM request is more than the text you type

When you type a question into a chatbot, it may feel as though the model receives only that question:

“What is RAG?”

But an application often sends a much larger structured request to the model. A simplified version might look like this:

System instructions:
You are a concise technical tutor. Explain terms clearly.

Conversation context:
Earlier user message: I am new to AI.
Earlier assistant message: An LLM generates text from patterns in data.

User input:
What is RAG?

The model processes the combined information, then produces an assistant response:

RAG stands for Retrieval-Augmented Generation. It is a method in which
an application retrieves relevant information from external documents and
gives that information to an LLM before the LLM writes an answer.

The model’s response is influenced by all of the available input, not just the final user sentence.

A useful mental model is:

Part	Main question it answers	Example
System instructions	“How should the assistant behave?”	“Be concise. Do not invent sources.”
User input	“What does the user want right now?”	“Explain RAG in simple terms.”
Context	“What additional information may help answer?”	Earlier chat messages, an uploaded document, retrieved passages
Model output	“What answer did the model generate?”	A paragraph explaining RAG

The labels are conceptually distinct, even though all of the input information eventually becomes text or tokens that the model processes together.

---

1. System instructions: the application’s standing directions

System instructions tell the model how to behave across a conversation. They can define:

• the assistant’s role or purpose;
• desired tone and level of detail;
• output format;
• operational constraints;
• instructions about when to admit uncertainty.

For example:

You are a support assistant for an HR policy portal.
Answer only from the supplied policy excerpts.
If the excerpts do not answer the question, say that you do not have enough information.
Use short bullet points.

This does not answer the user’s question itself. Instead, it establishes the rules under which the model should answer.

System instructions are commonly written by the developer of an application, not by the person chatting with it. In a consumer chatbot, some may be hidden from view. Custom instructions that a user sets in a product are often similar in purpose: they influence the model’s general behavior across many requests.

Importantly, system instructions are not a source of factual evidence. Saying “always be accurate” does not give the model new facts. It only tells the model what behavior is desired.

---

2. User input: the immediate task

The user input is the current question, request, or instruction supplied by the person using the application.

Examples include:

• “Summarize this meeting transcript.”
• “Write a polite reply declining the invitation.”
• “According to the employee handbook, how many vacation days do I have?”
• “What is the difference between RAG and fine-tuning?”

A good user input makes the task clear. It can specify:

• task: explain, summarize, compare, extract, draft;
• audience: beginner, manager, developer;
• format: bullets, table, email, JSON;
• constraints: word limit, tone, facts to include or exclude.

Compare these two requests:

Tell me about RAG.

Explain RAG to a beginner in three short paragraphs.
Include why it is useful for answering questions about private company documents.
Do not use unexplained jargon.

The second request gives the model a more precise target. Yet it remains the user’s immediate request, not the whole prompt sent to the model.

---

3. Context: the model’s working information for this request

Context means the additional information available to the model while it generates an answer. It is broader than user input.

Context can include:

• system instructions;
• earlier user and assistant messages;
• text from uploaded files;
• tool results, such as a database lookup;
• details provided by the application, such as the current date;
• later in this course, passages retrieved from documents by a RAG system.

The key idea is that an LLM does not automatically remember every earlier interaction forever. In many chat applications, the software maintains a conversation history and sends selected prior messages again with the new request. The apparent “memory” is often information reinserted into the current context.

Consider this exchange:

User: I am choosing between a compact car and an SUV.
Assistant: What matters most to you: price, cargo space, fuel economy, or off-road ability?
User: Fuel economy and city parking.

The final user message alone is incomplete. “Fuel economy and city parking” only makes sense if the model also receives the previous conversation as context. With that context, it can infer that the user is answering a question about compact cars versus SUVs.

Context is not the same as permanent knowledge

A model’s learned knowledge is encoded in its trained parameters. Context is temporary information supplied during a particular request.

For example, suppose an internal company policy says:

Employees may carry forward up to five unused vacation days.

If this policy is placed in the request context, the model can use it in that answer. But the model has not thereby been permanently retrained on the policy. A later request will need the policy supplied again if it is still relevant.

This temporary, request-time use of outside information is the bridge to RAG.

---

The context window: a limited working-memory budget

Every model has a finite context window: a maximum amount of information it can process in one request. This capacity is shared among the instructions, prior conversation, user message, attached or retrieved material, and the response being generated.

A simplified view is:

[system instructions] [conversation history] [extra context] [user input] [generated output]

Long documents and long conversations consume this budget quickly. If important information is absent from the current context, the model cannot directly use it for that response.

A practical consequence follows: more context is not automatically better. Relevant, well-organized context helps. Irrelevant, contradictory, or overly long context can distract the model or push out useful information.

---

4. Model output: generated text, not a database lookup

The model output is the response the LLM generates after processing the input information. In a chat interface, it is usually labeled with the assistant role.

The output might be:

• an answer;
• a summary;
• code;
• a structured object;
• a question asking for clarification;
• an admission that the provided material is insufficient.

The model does not normally retrieve a finished answer from a hidden database. Instead, it generates its response piece by piece, choosing the next token based on the information currently in the request and patterns learned during training.

For this lesson, you do not need to master token prediction yet. The important consequence is straightforward:

Change the instructions, context, or user request, and the output can change—even when using the same model.

For instance, imagine the same user question:

What is the vacation carryover limit?

With no company policy in context, the model may give a generic answer or incorrectly guess. With a policy excerpt in context, it can produce a specific, grounded answer:

Employees may carry forward up to five unused vacation days.

The model output is only as reliable as the combination of its instructions, its available evidence, and its ability to use that evidence correctly.

---

Putting all four roles together

Here is a full example of a request for a hypothetical internal-policy assistant.

Component	Content
System instructions	“Answer only using the supplied policy excerpts. Cite the excerpt label. If evidence is missing, say so.”
Context	[Policy A] Employees may carry forward up to five unused vacation days.
User input	“How many vacation days can I carry into next year?”
Model output	“You may carry forward up to five unused vacation days into the next year. [Policy A]”

Notice the division of labor:

• The system instructions control the assistant’s method and constraints.
• The context provides the evidence.
• The user input states what information is wanted.
• The output communicates the resulting answer.

In a RAG application, the application will retrieve the relevant policy excerpt automatically and place it into context before asking the LLM to answer. We will examine that lifecycle later; for now, recognize that retrieval supplies context, not a new model brain.

---

Common confusions to avoid

“The user prompt is the whole prompt.”

Usually, no. The user prompt is one part of the full request. The application may add instructions, conversation history, files, search results, or tool outputs.

“Context means the model permanently learned something.”

No. Context is temporary, request-specific working information. Training changes the model’s parameters; providing context changes what the model can consider for this response.

“A system instruction guarantees correctness.”

No. It can tell a model to be careful, cite sources, or refuse to guess. But it does not itself supply reliable facts. Grounding requires relevant evidence in context.

“The output is already part of the input.”

At the beginning of a request, no. The output is what the model creates. In a later turn, the application may include that earlier assistant response as conversation context.

“The model remembers the entire conversation.”

Only information that fits and is included in the active context is available to the model. Interfaces may summarize, omit, or truncate earlier turns when conversations become long.

---

Key takeaways

An LLM request is best understood as a structured package, not merely as the sentence a user types:

• System instructions establish behavior, format, and constraints.
• User input communicates the current task.
• Context is the temporary supporting information available for the task, including earlier messages and documents.
• Model output is the text generated in response to the complete request.

The model’s apparent memory and knowledge during a conversation depend heavily on what the application places in its context window.

Next, you will look below the level of words: how a short user message is split into tokens, the units an LLM actually processes.