Definición en una frase
Adaptación temporal del comportamiento a instrucciones y ejemplos presentes en el contexto sin actualizar los pesos del modelo.
Definición: adaptación dentro del contexto
El aprendizaje en contexto —in-context learning o ICL— es la capacidad observable de un modelo de producir una respuesta condicionada por la información que recibe en una petición: instrucciones, ejemplos y la tarea nueva. En lugar de modificar el modelo mediante un proceso de entrenamiento, se incorpora esa información a la entrada para orientar la respuesta durante esa interacción.
En una petición, el contexto puede indicar qué hacer, qué formato usar y qué ejemplos muestran la relación entre una entrada y una salida esperada. El modelo genera entonces una respuesta a partir de la entrada completa. En el uso habitual del término, «aprendizaje» describe el cambio aparente en el comportamiento ante el contexto; no significa necesariamente que el modelo haya actualizado sus parámetros ni que haya adquirido una habilidad permanente.
Esta definición se refiere a la interacción ordinaria con un modelo ya disponible. No cubre por sí sola procesos externos que una aplicación pueda ejecutar, como guardar datos, actualizar una base de conocimiento o iniciar un entrenamiento. Por eso es más preciso decir que el modelo se adapta temporalmente a la información de la petición que afirmar que aprende de forma permanente.
Cómo se presenta en una petición
Una petición con ICL suele combinar tres componentes: una instrucción que delimita la tarea, una o más demostraciones que relacionan entradas con salidas y un elemento nuevo que el modelo debe procesar. Las demostraciones no son obligatorias en todas las formas de ICL: una instrucción por sí sola también puede orientar la respuesta. Sin embargo, los ejemplos explícitos son una manera común de mostrar al modelo qué transformación se espera.
La estructura puede escribirse en lenguaje natural o mediante un formato regular. Si se piden etiquetas, conviene definirlas y mantenerlas consistentes; si se extraen campos, es útil especificar qué hacer cuando un dato no aparece. Estas decisiones son parte del diseño de la petición. No convierten automáticamente la respuesta en correcta: solo hacen explícita la tarea y permiten evaluar mejor el resultado.
El modelo procesa el contexto disponible al generar la respuesta. En una interacción normal, eso no equivale a añadir la demostración a sus parámetros de forma permanente. La información puede dejar de influir cuando se envía otra petición que no la incluye, salvo que el sistema circundante conserve o vuelva a incorporar ese contenido.
Esquema mínimo de uso
El procedimiento separa las instrucciones, las demostraciones y el caso que se quiere resolver. No garantiza el resultado; permite construir una petición que luego pueda probarse.
- 01Definir la tarea y las salidas permitidas.
- 02Añadir ejemplos representativos de entrada y salida, si hacen falta.
- 03Presentar el caso nuevo en el mismo formato.
- 04Revisar la respuesta y compararla con el resultado esperado.
Tres ejemplos aplicados
Los siguientes casos ilustran cómo estructurar una petición. Son ejemplos de diseño, no resultados de pruebas sobre un modelo concreto ni garantías de que un sistema vaya a clasificar o extraer la información correctamente. En cada ámbito hay que definir previamente las categorías, los campos y la forma de tratar la ambigüedad.
Qué significa «aprender» y qué no podemos concluir
En este nombre, «aprendizaje» alude a que el modelo parece inferir una pauta a partir del contexto y responder de acuerdo con ella. La respuesta por sí sola no revela cómo se produjo esa pauta internamente. Un modelo puede acertar una clasificación después de ver ejemplos, pero ese acierto no demuestra que haya ejecutado una actualización de parámetros, que represente la tarea de una forma determinada o que vaya a transferirla a cualquier caso nuevo.
Una formulación de investigación incluida entre las fuentes describe ICL en modelos autorregresivos como la posibilidad de resolver tareas mediante predicción del siguiente token y sin entrenamiento adicional. Esa descripción ayuda a distinguir el uso del contexto del entrenamiento, pero no debe convertirse en una explicación universal de todos los sistemas o de todos los mecanismos internos. La fuente disponible no permite afirmar que exista una explicación mecanística única y aceptada para el fenómeno.
También conviene separar el resultado observable de la explicación causal. Que una instrucción o un ejemplo influya en la salida permite decir que el comportamiento está condicionado por el contexto. No basta para identificar qué representación interna usa el modelo, por qué una demostración concreta resulta útil ni si el modelo está aplicando una regla, reconociendo una estructura familiar o combinando distintas señales.
ICL, pocos ejemplos y métodos próximos
«Aprendizaje en contexto» y «aprendizaje con pocos ejemplos» se solapan en el uso cotidiano, pero no son términos intercambiables en todos los textos técnicos. Cuando los ejemplos se incluyen en la petición para orientar la respuesta, se suele hablar de aprendizaje en contexto o de prompting con pocos ejemplos. En cambio, «few-shot learning» también puede nombrar enfoques en los que el modelo se adapta mediante entrenamiento con pocos ejemplos. Por eso importa comprobar si una fuente habla de ejemplos incluidos en la entrada o de un procedimiento de entrenamiento.
El ajuste fino es distinto del uso ordinario del ICL: implica entrenar o ajustar el modelo con datos para cambiar su comportamiento, mientras que el ICL aporta información en el contexto de la petición. La recuperación de documentos también es una operación distinta: selecciona información externa que una aplicación puede añadir al contexto. Si después el modelo responde condicionado por esa información, la generación puede usar ICL, pero la búsqueda y el aprendizaje en contexto no son el mismo paso.
Tampoco debe confundirse el ICL con el aprendizaje permanente. Incluir un ejemplo en una petición no establece que el modelo vaya a recordarlo en interacciones futuras. La persistencia depende de cómo esté construido el sistema que lo rodea y de si vuelve a proporcionar esa información.
Cómo distinguir los conceptos
La terminología varía según el contexto. Esta tabla separa los métodos por dónde se incorpora la información, no por el resultado que se espera obtener.
| Concepto | Dónde se incorpora la información | Qué no implica por sí solo |
|---|---|---|
| Aprendizaje en contexto (ICL) | En la entrada o contexto de la petición, mediante instrucciones, ejemplos u otras señales | Una actualización permanente de los pesos |
| Prompting con pocos ejemplos | En la petición, mediante demostraciones de entrada y salida | Que «few-shot learning» siempre se refiera a esta técnica |
| Ajuste fino | En un proceso de entrenamiento o ajuste del modelo | Que el modelo vaya a responder bien a toda tarea nueva |
| Recuperación de documentos | En información externa que un sistema busca y puede añadir al contexto | Que la recuperación y el ICL sean el mismo proceso |
| Aprendizaje permanente | En mecanismos que retienen o incorporan información más allá de una petición | Que un ejemplo de una interacción quede recordado automáticamente |
Límites y errores frecuentes de diseño
Los ejemplos pueden no representar la variedad de entradas reales. Si todos son claros y breves, una petición puede parecer eficaz y fallar ante mensajes ambiguos, campos ausentes o expresiones poco habituales. Aumentar el número de demostraciones no resuelve automáticamente ese problema: importa que sean pertinentes, correctas y suficientemente diversas para la tarea.
El orden y la selección de los ejemplos también pueden afectar la respuesta. No conviene interpretar un acierto aislado como prueba de robustez ni atribuir un fallo exclusivamente al modelo sin revisar la instrucción, el formato y los datos de ejemplo. Una etiqueta mal definida puede producir desacuerdos incluso entre personas; un formato de salida ambiguo puede dificultar la evaluación aunque la interpretación general sea razonable.
Entre los errores frecuentes están mezclar categorías incompatibles, dar ejemplos que contradicen la instrucción, no especificar cómo responder ante información ausente y evaluar solo casos similares a los que ya aparecen en la petición. Otro error es confundir una salida convincente con una extracción verificada: para usos operativos, los campos y clasificaciones relevantes necesitan controles adecuados al riesgo.
Cómo comprobar si los ejemplos ayudan
La forma práctica de evaluar ICL es comparar la misma tarea con y sin ejemplos, manteniendo constantes, en lo posible, el modelo, la instrucción, los casos de prueba y las demás condiciones. El conjunto de evaluación debe incluir entradas representativas y casos difíciles que no sean simples copias de las demostraciones. Hay que conservar las respuestas y registrar errores, no seleccionar solo los aciertos que confirman una impresión inicial.
La comparación puede medir la exactitud de las etiquetas, la proporción de campos omitidos o incorrectos, el cumplimiento del formato y la cantidad de casos que requieren revisión. La métrica concreta depende del objetivo: no se evalúa igual una clasificación de soporte que la extracción de importes. Si los errores de ciertas categorías tienen consecuencias distintas, deben analizarse por separado.
Una prueba pequeña sirve para detectar problemas de diseño, pero no garantiza que el comportamiento se mantenga en producción. Si cambia la distribución de las solicitudes, los documentos o el lenguaje de los clientes, pueden cambiar también los resultados. Por ello, los ejemplos deben revisarse con datos pertinentes y la evaluación debe repetirse cuando cambien la tarea o las condiciones de uso.
Prueba comparativa sencilla
El objetivo es estimar si las demostraciones mejoran el desempeño en casos no usados para redactarlas. La comparación no prueba por sí misma un mecanismo interno.
- 01Definir una tarea, una salida esperada y criterios de error antes de probar.
- 02Separar ejemplos de diseño y casos de evaluación; evitar evaluar solo los ejemplos mostrados.
- 03Ejecutar la misma instrucción sin demostraciones y con demostraciones, bajo condiciones comparables.
- 04Comparar aciertos, errores, omisiones, formato y casos que exigen revisión.
- 05Revisar ejemplos y resultados si la mejora es irregular o se concentra en casos sencillos.
Criterios prácticos y conceptos relacionados
El ICL es una opción razonable cuando la tarea puede describirse con claridad, los ejemplos caben en el contexto disponible y se puede revisar la salida. Antes de adoptarlo, comprueba que cada demostración sea correcta, que los casos nuevos se parezcan lo suficiente a la tarea prevista y que exista una respuesta aceptable para las situaciones ambiguas o fuera de alcance.
Si los ejemplos no mejoran resultados representativos, primero revisa la definición de la tarea, las etiquetas, el formato y la selección de casos. Si se necesita persistencia entre interacciones o un cambio duradero del comportamiento, añadir ejemplos a cada petición no equivale a resolver esa necesidad. La comparación entre ICL y ajuste por instrucciones aparece también en investigación sobre modelos pequeños y multilingües, pero una observación sobre esa comparación no permite establecer cuál método conviene para cualquier modelo o tarea.
Para continuar, consulta la ruta del glosario, la ficha relacionada sobre aprendizaje en contexto y la sección de comparativas. Los nombres internos corresponden a «glossary.index», «glossary:in-context-learning» y «compare.index»; la disponibilidad y el contenido de esas rutas dependen del sitio.