Zero-shot es pedirle al modelo que haga una tarea sin darle ningún ejemplo, solo la instrucción. Few-shot es darle unos cuantos ejemplos de entrada y salida antes de pedirle la tarea real. La pregunta de cuándo usar cada uno se contesta mejor mirando qué falla en zero-shot, no repitiendo de memoria la regla de "los ejemplos siempre ayudan", porque no siempre ayudan.
Cuándo zero-shot es suficiente
Para tareas de razonamiento general, resumen, traducción o preguntas sobre conocimiento que el modelo ya domina bien, dar ejemplos aporta poco y cuesta tokens en cada llamada. Los modelos actuales, entrenados con instrucciones, ya "entienden" razonablemente bien qué se les pide sin necesidad de demostración previa en estos casos.
Hay además un riesgo con few-shot que se suele pasar por alto: anclar el razonamiento del modelo al patrón de los ejemplos, incluso cuando ese patrón no encaja del todo con el caso real. Si tus ejemplos usan un tipo concreto de razonamiento y el caso nuevo necesita otro distinto, los ejemplos pueden sesgar la respuesta en la dirección equivocada en vez de ayudar. En tareas donde el razonamiento debe adaptarse caso a caso, menos ejemplos —o ninguno— a veces funciona mejor que unos cuantos mal elegidos.
Cuándo few-shot marca la diferencia
Hay casos donde los ejemplos no son un extra, son casi obligatorios para conseguir el resultado que buscas:
- Formato de salida muy específico. Si necesitas una estructura exacta —un JSON con campos concretos, un formato de tabla particular, un estilo de redacción muy definido—, describirlo en prosa deja margen de interpretación. Un ejemplo del formato exacto elimina la ambigüedad de una forma que ninguna descripción textual consigue igual de bien.
- Tareas con casos límite no obvios. Si la tarea tiene reglas de borde difíciles de explicar en abstracto pero fáciles de mostrar ("cuando pase esto, haz esto otro"), un ejemplo que cubra ese caso concreto vale más que un párrafo intentando describirlo con precisión.
- Tono o estilo particular. Pedir "escribe en un tono directo y sin relleno" es ambiguo. Mostrar dos frases escritas en ese tono deja mucho menos espacio para que el modelo interprete algo distinto a lo que quieres.
- Clasificación con categorías poco intuitivas. Cuando las categorías no se corresponden con divisiones obvias del lenguaje natural, un ejemplo por categoría ayuda a fijar el criterio de forma mucho más precisa que una definición textual, por muy cuidada que esté.
La calidad de los ejemplos importa más que la cantidad
No es "cuantos más ejemplos, mejor". Un par de ejemplos bien elegidos, que cubran casos representativos y algún caso límite, superan a media docena de ejemplos redundantes que repiten el mismo patrón una y otra vez.
Cosas a vigilar al elegir los ejemplos:
- Diversidad. Si todos tus ejemplos siguen el mismo patrón superficial —misma longitud, mismo tipo de entrada—, el modelo puede aprender ese patrón superficial en vez de la regla de fondo que quieres transmitir.
- Orden. El orden de los ejemplos puede influir en el resultado, especialmente en contextos cortos. No es tan crítico como lo era antes, pero si notas comportamiento raro o inconsistente, prueba a reordenarlos antes de descartar el enfoque por completo.
- Ejemplos incorrectos, no solo correctos. En tareas de clasificación o validación, mostrar un ejemplo de lo que NO es válido, junto con el motivo, suele fijar mejor el criterio que mostrar únicamente casos positivos.
El coste que casi nadie cuenta
Cada ejemplo que añades ocupa tokens en cada llamada, no una sola vez. Si tu prompt con ejemplos se ejecuta miles de veces en producción, ese coste se multiplica de forma directa y constante. Antes de meter cinco ejemplos "por si acaso", vale la pena probar con dos o tres bien elegidos y medir si la diferencia en calidad justifica el coste extra que vas a pagar en cada llamada, para siempre.
Esto también afecta a la latencia: más tokens de entrada es más tiempo de procesamiento antes de que empiece a salir la respuesta. En una tarea interactiva, eso se nota.
Cómo decidir en la práctica
Prueba primero en zero-shot. Si el resultado es consistente y correcto en tus casos de prueba, no añadas ejemplos: solo estarías gastando tokens sin necesidad real. Si ves que el modelo interpreta el formato de forma distinta cada vez, se equivoca sistemáticamente en un tipo de caso concreto, o el tono no es el que buscas, ahí es donde uno o dos ejemplos bien elegidos suelen resolver el problema de forma más fiable que seguir puliendo la descripción en prosa una y otra vez.
Un patrón que me funciona: empezar en zero-shot, guardar los casos donde falla, y convertir los dos o tres fallos más representativos en ejemplos few-shot. Es un proceso guiado por errores reales, no por intuición sobre qué "debería" ayudar antes de haber probado nada.
Un matiz sobre modelos con razonamiento explícito
Con modelos que dedican pasos de razonamiento explícito antes de responder, el efecto de los ejemplos cambia un poco respecto a lo que valía con generaciones anteriores. A veces basta con pedir que razone paso a paso, sin ejemplos, para conseguir lo que antes solo se lograba mostrando demostraciones completas. Esto no invalida nada de lo anterior sobre formato o tono —ahí los ejemplos siguen ayudando igual—, pero sí vale la pena volver a probar en zero-shot tareas que en su momento resolviste a base de few-shot, porque la necesidad real puede haber cambiado con el modelo que estás usando ahora.
La regla corta
Describe primero, muestra después, y solo cuando describir no haya sido suficiente. Los ejemplos son una herramienta para eliminar ambigüedad concreta que has observado, no un adorno que se añade por costumbre a todos los prompts porque "es lo que se hace".
Relacionado: Qué debe incluir un buen prompt para Cursor IDE