One-sentence definition
Adaptación temporal del comportamiento a instrucciones y ejemplos presentes en el contexto sin actualizar los pesos del modelo.
Definition: adaptation within the context
In-context learning (ICL) is the observable ability of a model to produce a response conditioned on information in a request: instructions, examples, and the new task to be performed. Rather than modifying the model through a training process, the request includes that information to guide the response during the interaction.
A request can specify what to do, which format to use, and what input-output examples illustrate the expected relationship. The model then generates a response from the complete input. In common usage, “learning” describes the apparent change in behavior in response to context; it does not necessarily mean that the model has updated its parameters or acquired a lasting skill.
This definition concerns ordinary interaction with an available model. It does not, by itself, cover external processes an application might run, such as saving data, updating a knowledge base, or starting a training job. It is therefore more precise to say that the model adapts temporarily to information in the request than to claim that it learns permanently.
How it appears in a request
An ICL request often combines three components: an instruction that defines the task, one or more demonstrations connecting inputs to outputs, and a new item for the model to process. Explicit demonstrations are not required in every form of ICL: an instruction alone can also guide the response. However, examples are a common way to show the model which transformation is expected.
The structure can be written in natural language or in a regular format. When requesting labels, define them and use them consistently; when extracting fields, explain what to do if a value is missing. These choices are part of designing the request. They do not automatically make the response correct, but they make the task explicit and the result easier to evaluate.
The model processes the available context while generating its response. In an ordinary interaction, this is not the same as permanently adding a demonstration to the model’s parameters. The information may stop influencing the model when you send another request that does not include it, unless the surrounding system retains or supplies it again.
A minimal workflow
This process separates the instructions, demonstrations, and the case to be solved. It does not guarantee a result; it provides a request structure that can then be tested.
- 01Define the task and the permitted outputs.
- 02Add representative input-output examples if they are needed.
- 03Present the new case in the same format.
- 04Review the response and compare it with the expected result.
Three applied examples
The following cases illustrate how to structure a request. They are design examples, not test results for a particular model and not guarantees that a system will classify or extract information correctly. In each domain, first define the categories, fields, and rules for handling ambiguity.
What “learning” means—and what we cannot conclude
Here, “learning” refers to the model seeming to infer a pattern from the context and respond accordingly. The response alone does not reveal how that pattern was produced internally. A model may correctly classify an item after seeing examples, but that success does not show that it performed a parameter update, represents the task in a particular way, or will transfer the behavior to every new case.
One research paper included among the sources describes ICL in autoregressive models as the ability to solve tasks through next-token prediction without additional training. That description helps distinguish the use of context from training, but it should not be turned into a universal explanation of every system or internal mechanism. The available source does not establish that there is one accepted mechanistic explanation for the phenomenon.
It is also useful to separate an observable result from a causal explanation. If an instruction or example influences an output, we can say that the behavior is conditioned by context. That is not enough to identify which internal representation the model uses, why a particular demonstration helps, or whether the model is applying a rule, recognizing a familiar structure, or combining different signals.
ICL, few-shot prompting, and related methods
“In-context learning” and “few-shot learning” overlap in everyday usage, but they are not interchangeable in every technical text. When examples are included in a request to guide the response, people often call this in-context learning or few-shot prompting. By contrast, “few-shot learning” can also refer to approaches in which a model is adapted through training on a small number of examples. It is therefore important to check whether a source means examples included in the input or a training procedure.
Fine-tuning differs from ordinary ICL: it involves training or adapting a model with data to change its behavior, whereas ICL supplies information in the context of a request. Document retrieval is also a separate operation: it selects external information that an application can add to the context. If the model then generates a response conditioned on that information, generation may use ICL, but retrieval and in-context learning are not the same step.
ICL should not be confused with continual learning, either. Including an example in a request does not establish that the model will remember it in future interactions. Persistence depends on how the surrounding system is built and whether it supplies the information again.
How to distinguish the concepts
Terminology varies by context. This table distinguishes methods by where information is introduced, not by the result they are intended to produce.
| Concept | Where the information is introduced | What it does not imply by itself |
|---|---|---|
| In-context learning (ICL) | In the input or context of a request, through instructions, examples, or other signals | A permanent update to the model’s weights |
| Few-shot prompting | In the request, through input-output demonstrations | That “few-shot learning” always refers to this technique |
| Fine-tuning | In a training or model-adaptation process | That the model will respond well to every new task |
| Document retrieval | In external information that a system finds and may add to the context | That retrieval and ICL are the same process |
| Continual learning | Through mechanisms that retain or incorporate information beyond a single request | That an example from one interaction is automatically remembered |
Limitations and common design mistakes
Examples may not represent the variety of real inputs. If every example is clear and brief, a request can appear to work well and still fail on ambiguous messages, missing fields, or unusual phrasing. Simply adding more demonstrations does not automatically solve this problem: examples need to be relevant, correct, and diverse enough for the task.
The choice and order of examples can also affect the response. Do not treat one successful answer as proof of robustness, or blame a failure exclusively on the model without reviewing the instruction, format, and example data. Poorly defined labels can lead to disagreement even among people; an ambiguous output format can make evaluation difficult even when the general interpretation is reasonable.
Common mistakes include mixing incompatible categories, giving examples that contradict the instruction, failing to specify what to do when information is missing, and evaluating only cases similar to those already shown in the request. Another mistake is confusing a convincing-looking output with a verified extraction. For operational use, important fields and classifications need checks suited to the risks involved.
How to check whether examples help
A practical way to evaluate ICL is to compare the same task with and without examples, holding the model, instruction, test cases, and other conditions constant where possible. The evaluation set should include representative inputs and difficult cases that are not simple copies of the demonstrations. Keep the responses and record errors; do not select only the successes that confirm an initial impression.
The comparison can measure label accuracy, the proportion of omitted or incorrect fields, compliance with the output format, and the number of cases requiring review. The right metric depends on the goal: a support classification task is not evaluated in the same way as extracting invoice totals. If mistakes in some categories have different consequences, analyze them separately.
A small test can reveal design problems, but it cannot guarantee that behavior will remain the same in production. If the distribution of requests, documents, or customer language changes, results may change too. Review examples against relevant data, and repeat the evaluation when the task or conditions of use change.
A simple comparative test
The goal is to estimate whether demonstrations improve performance on cases that were not used to write them. The comparison does not, by itself, prove an internal mechanism.
- 01Define the task, expected output, and error criteria before testing.
- 02Separate design examples from evaluation cases; do not evaluate only on the examples shown.
- 03Run the same instruction without demonstrations and with demonstrations under comparable conditions.
- 04Compare successes, errors, omissions, format compliance, and cases that require review.
- 05Review the examples and results if improvement is uneven or concentrated in simple cases.
Practical criteria and related concepts
ICL is a reasonable option when the task can be described clearly, the examples fit within the available context, and the output can be reviewed. Before adopting it, check that each demonstration is correct, that new cases are similar enough to the intended task, and that there is an acceptable response for ambiguous or out-of-scope situations.
If examples do not improve representative results, first review the task definition, labels, format, and case selection. If you need persistence across interactions or a lasting change in behavior, adding examples to each request does not address that need by itself. Research on small and multilingual models also examines comparisons between ICL and instruction tuning, but an observation about that comparison does not establish which method is preferable for every model or task.
To continue, see the glossary index, the related entry on in-context learning, and the comparison section. Their internal route names are “glossary.index,” “glossary:in-context-learning,” and “compare.index”; whether those routes are available and what they contain depends on the site.