Few-shot prompting: enseñar con ejemplos

Few-shot prompting es incluir unos pocos ejemplos resueltos en el prompt para que el modelo siga el patrón. Cuándo sirve, cómo elegirlos y qué hacer si falla.

info Definición Rápida

Few-shot prompting es incluir en el prompt unos pocos ejemplos de entrada y salida deseada para que el modelo siga el mismo patrón con una entrada nueva. No cambia el modelo: el aprendizaje ocurre dentro de la propia petición, a partir de lo que se le muestra.

¿Qué es y de dónde viene?

El término viene del paper de OpenAI de 2020 Language Models are Few-Shot Learners (Brown et al.), que presentó GPT-3, un modelo de 175.000 millones de parámetros. Los autores mostraron que un modelo grande podía acometer tareas nuevas con solo darle demostraciones en el texto de entrada, sin actualizar sus pesos ni reentrenarlo. Distinguen tres casos:

Caso	Qué recibe el modelo
Zero-shot	Solo una instrucción en lenguaje natural
One-shot	La instrucción y un ejemplo
Few-shot	La instrucción y unos pocos ejemplos

En ese paper, el número de ejemplos suele estar entre 10 y 100, porque eran los que cabían en una ventana de contexto de 2048 tokens. Hoy las ventanas son mucho mayores, pero la idea no cambió: los ejemplos compiten por espacio con el resto del prompt. Más sobre ese límite en ventana de contexto. El mismo trabajo reconoce que few-shot sigue costando en algunos conjuntos de datos, así que no es una garantía.

Un caso simple: para clasificar comentarios de usuarios como “queja”, “sugerencia” o “elogio”, incluyes cuatro comentarios con su etiqueta. Luego escribes el comentario nuevo. El modelo responde con la misma estructura y, en general, con criterios parecidos a los que mostraste.

Este artículo se centra en los ejemplos. Para el panorama completo de instrucciones, contexto y estructura, lee prompt engineering para diseñadores.

¿Por qué le importa a un diseñador?

Porque los ejemplos son la forma más directa de definir un criterio de calidad que cuesta explicar con palabras. Anthropic los describe como una de las formas más fiables de dirigir el formato, el tono y la estructura de la salida.

Tono. Describir “cálido pero profesional” es ambiguo. Dos ejemplos aprobados lo hacen concreto.
Formato. Mostrar cómo debe verse una respuesta con sus secciones evita que cambie en cada llamada. Si el formato debe ser exacto, mira también salidas estructuradas.
Casos límite. Un ejemplo de lo que sí se debe rechazar enseña la frontera mejor que una regla abstracta.
Acceso al proceso. Un diseñador puede escribir ejemplos sin programar, lo que lo vuelve parte real del equipo que define el comportamiento.

¿Cómo elegir los ejemplos?

Las guías oficiales coinciden en lo esencial. Anthropic pide ejemplos relevantes, variados y marcados con etiquetas para distinguirlos de las instrucciones, y sugiere de 3 a 5. OpenAI pide mostrar un rango diverso de entradas. Google pide que la estructura y el formato sean idénticos entre ejemplos, y avisa de que, si incluyes demasiados, el modelo puede sobreajustar la respuesta a ellos. Un método práctico a partir de eso:

Elige casos representativos, no los más fáciles. Incluye al menos uno de cada categoría que vas a clasificar.
Varía el contenido de los ejemplos para que el modelo no aprenda un patrón que no querías, pero mantén idéntico el formato (separadores, mayúsculas, saltos de línea).
Prueba distintos órdenes. Lu et al. (2021) encontraron que el orden de los mismos ejemplos puede marcar la diferencia entre un resultado fuerte y uno casi aleatorio, y que el mejor orden no se traslada de un modelo a otro. Zhao et al. (2021) atribuyen parte de esa inestabilidad al sesgo del modelo hacia las respuestas cercanas al final del prompt.
Mantén los ejemplos aprobados en un archivo versionado, con el motivo de su selección.
Compara sin ejemplos y con ejemplos sobre el mismo conjunto de casos, para medir si realmente ayudan.

Un estudio que cambia la intuición

Un trabajo de 2022 de Min y colaboradores encontró que reemplazar al azar las etiquetas de los ejemplos reducía poco el rendimiento en varias tareas de clasificación y elección múltiple, y que esto se repetía en 12 modelos, entre ellos GPT-3. Su conclusión es que los ejemplos enseñan sobre todo el espacio de etiquetas, la distribución del texto de entrada y el formato general de la secuencia.

La lección práctica no es que los ejemplos no importen, sino que gran parte de su valor está en mostrar el formato y el tipo de caso. El estudio cubre tareas de clasificación y elección múltiple; no lo generalices a tareas donde el ejemplo define un criterio sutil, como un tono de marca. Ahí, un ejemplo mal etiquetado enseña un criterio equivocado. Trata el estudio como una razón para no obsesionarte con cada etiqueta, no como permiso para dejar ejemplos sin revisar.

¿Cuándo NO conviene?

Cuando la tarea es simple y el modelo ya la hace bien sin ejemplos: más ejemplos solo agregan costo en tokens en cada petición.
Cuando los ejemplos ocupan la mayor parte de la ventana y dejan poco espacio para la información real.
Cuando el patrón cambia mucho entre casos, porque el modelo puede copiar un ejemplo que no corresponde.
Cuando el problema es de conocimiento, no de formato. Si el modelo no tiene el dato, los ejemplos no se lo dan; usa RAG.

Si tienes cientos de ejemplos y necesitas un comportamiento estable a gran volumen, evalúa fine-tuning.

¿Y si los ejemplos no ayudan?

Revisa en este orden: primero, que el formato de los ejemplos sea idéntico; segundo, que cubran los casos donde el modelo falla y no solo los fáciles; tercero, que el orden no sea el problema; cuarto, que la instrucción no contradiga a los ejemplos. Si tras eso no hay mejora, el obstáculo probablemente no es de ejemplos. Para tareas de varios pasos, mira chain of thought; para medir cada cambio con rigor, qué son los evals.

Ejemplo

Ejemplo ilustrativo: un equipo de producto necesita que un asistente convierta notas de reunión en tareas con responsable y fecha. Con cero ejemplos, el formato cambia en cada respuesta. Con tres ejemplos aprobados, incluyendo uno sin fecha explícita donde la salida correcta es pedir la fecha, el asistente deja de inventarla. El equipo prueba con 30 notas reales, cambia el orden de los ejemplos para ver si el resultado varía y registra los casos donde falla, para agregar ejemplos solo cuando un patrón se repite.

Errores comunes

Incluir ejemplos que el equipo no revisó.
Usar solo casos fáciles, y luego sorprenderse con los difíciles.
Poner decenas de ejemplos sin medir si ayudan.
Variar el formato entre ejemplos y esperar una salida consistente.
Olvidar que los ejemplos también cuestan tokens en cada petición.
Dar ejemplos casi idénticos: el modelo puede aprender patrones que no querías.
Mezclar en los ejemplos estilos que el producto no quiere mostrar.

Fuentes

Preguntas frecuentes

¿Qué es few-shot prompting?

Es incluir en el prompt unos pocos ejemplos de entrada y salida deseada, para que el modelo siga el mismo patrón con la nueva entrada, sin reentrenarlo.

¿Cuántos ejemplos debo incluir?

No hay un número fijo. Anthropic recomienda de 3 a 5 ejemplos relevantes y variados; Google aconseja experimentar con la cantidad porque demasiados pueden provocar sobreajuste a los ejemplos. Prueba con tus propios casos.

¿Los ejemplos deben ser correctos?

Conviene que lo sean. Un estudio de 2022 (Min et al.) halló que cambiar las etiquetas al azar bajaba poco el rendimiento en tareas de clasificación y elección múltiple, porque los ejemplos aportan sobre todo formato y tipo de caso. Eso no los vuelve irrelevantes: si quieres enseñar un criterio, el ejemplo debe reflejarlo.

¿El orden de los ejemplos importa?

Puede importar mucho. Lu et al. (2021) mostraron que reordenar los mismos ejemplos puede llevar de un rendimiento alto a uno cercano al azar, y que un buen orden en un modelo no sirve necesariamente en otro.

¿Few-shot es mejor que fine-tuning?

Para tareas con pocos casos y cambios frecuentes, suele ser más rápido y barato. Si necesitas un comportamiento estable a gran volumen, el fine-tuning puede compensar.