When working with a large language model, what does the term prompt refer to?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal: when you talk to an LLM, the thing you type—the question, the instructions, the pasted context—is the prompt. Not the transformer guts, not the training dump from last year, not the answer that comes back. Think of it like this: the model is a super-powered autocomplete engine; the prompt is the starting text that steers where it goes. Boss walks in and says, 'Make the chatbot stop rambling'—you fix the prompt (and maybe system message), you don't rebuild the architecture over lunch. Exam trap: mixing up prompt with training data or with the completion. Keep it simple: prompt in, generation out. You craft the input; the model fills in the rest. Land that, and prompt-engineering questions get a lot friendlier.
Full explanation below image
Full Explanation
In large language model (LLM) usage, a prompt is the input text—often an instruction, question, partial document, or structured template—that the user or application supplies at inference time. The model conditions its next-token predictions on that input (plus any system or developer messages in chat-style APIs), then decodes a completion. Colloquially, people also include few-shot examples and formatting constraints as part of 'the prompt,' because those strings sit in the same context window and steer behavior without changing stored weights.
This definition carefully separates several neighboring concepts that exams love to confuse. Model architecture refers to the network design: depth, attention mechanisms, embedding sizes, and related structural choices. Those decisions are made when the model is designed and trained, not when an end user asks a question. Training data is the offline corpus (and any fine-tuning sets) used to estimate parameters; it influences general capabilities and biases but is not the interactive query for a single request. The model’s output—the generated answer, code, summary, or dialogue turn—is the product of decoding after the prompt has been consumed; calling that output 'the prompt' reverses cause and effect.
Why the distinction matters in practice: prompt quality often dominates application quality for frozen models. Clear role instructions, relevant context, explicit output schemas, and carefully chosen examples can raise task success rates without retraining. Conversely, ambiguous or underspecified prompts produce hallucinations, format drift, or unsafe completions. Teams therefore invest in prompt libraries, evaluation harnesses, and sometimes retrieval-augmented context assembly—still operating on the same idea that the conditioning text is the prompt.
For certification-style questions, map vocabulary cleanly: architecture = how the model is built; training data = what taught the weights; prompt = what you feed at inference; completion = what you get back. Once that map is solid, related topics such as zero-shot versus few-shot prompting, system prompts, and prompt injection attacks all hang off the same core definition. Remember that multi-turn chat histories are effectively extended prompts: prior turns become additional context tokens. The enduring takeaway is operational: you do not retrain an LLM every time requirements shift slightly—you reshape the input the model sees, and that input is the prompt.