Estrategia de prompting

Zero-shot vs few-shot prompting: cuándo usar cada enfoque y qué problema resuelve mejor

Una guía práctica para decidir cuándo basta con instrucciones limpias y cuándo conviene añadir ejemplos para mejorar precisión y consistencia.

Actualizado: 4 de abril de 202614 min de lecturaGuía de ingeniería de prompts

Contexto

Por qué importa esta guía

Uno de los errores más comunes en prompt engineering es añadir ejemplos por defecto, sin preguntarse si realmente hacen falta. En algunos casos, el few-shot mejora mucho la precisión. En otros, solo añade coste, ruido y dependencia de ejemplos mal elegidos.

La diferencia importante no es académica; es operativa. Debes saber cuándo una instrucción clara ya es suficiente y cuándo el modelo necesita ver una muestra concreta del comportamiento esperado para evitar ambigüedades.

Esta guía te ayuda a elegir entre zero-shot y few-shot de forma pragmática según la tarea, el riesgo y el nivel de control que necesitas.

Resumen

Puntos clave

  • Zero-shot suele bastar cuando la tarea está bien definida y el formato es simple.
  • Few-shot aporta valor cuando importan tono, clasificación o edge cases.
  • Los ejemplos deben ser pocos, buenos y elegidos por señal, no por cantidad.
  • Más ejemplos no siempre significan mejores resultados.
  • Revisa el coste en tokens frente a la ganancia real de precisión.
1

Bloque operativo

1) Zero-shot funciona mejor de lo que muchos creen

Si la tarea está bien acotada, con objetivo claro y formato definido, los modelos actuales resuelven muchas peticiones sin necesidad de ejemplos. Eso convierte al zero-shot en una opción más rápida, más limpia y más barata para flujos recurrentes.

Especialmente en resúmenes, síntesis estructurada, tablas comparativas y extracción simple, una buena instrucción suele bastar si el contexto es sólido.

2

Bloque operativo

2) Few-shot es útil cuando el comportamiento esperado no es obvio

Cuando pides al modelo clasificar, puntuar, mantener un tono muy concreto o tratar casos frontera, los ejemplos pueden marcar una gran diferencia. Le estás enseñando no solo la tarea, sino el estándar exacto con el que debe ejecutarla.

Eso sí: los ejemplos deben representar bien el patrón. Si son mediocres o contradictorios, arrastran el output hacia una calidad mediocre.

3

Bloque operativo

3) Usa ejemplos para calibrar, no para sustituir una mala instrucción

Muchos equipos añaden ejemplos porque la instrucción base es floja. Eso es un parche caro. Primero debes mejorar el prompt principal: definir tarea, criterios, restricciones y formato. Después, si todavía hay ambigüedad, añade pocos ejemplos de alta señal.

4

Bloque operativo

4) Evalúa la ganancia real frente al coste de tokens y mantenimiento

Cada ejemplo ocupa espacio, cuesta tokens y requiere mantenimiento cuando el estándar cambia. Por eso conviene justificar el few-shot solo donde la precisión adicional tenga impacto real en negocio o calidad del flujo.

Biblioteca de plantillas

Plantillas reutilizables

Plantilla zero-shot

Para tareas bien definidas donde el modelo no necesita ver muestras previas.

Actúa como [ROL].
Resuelve esta tarea: [TAREA].
Contexto útil:
[CONTEXTO]

Restricciones:
- [RESTRICCIÓN 1]
- [RESTRICCIÓN 2]

Devuelve la respuesta en este formato:
[FORMATO ESPERADO]

Plantilla few-shot

Para clasificación, scoring, tono o casos límite donde necesitas más control.

Quiero que sigas este patrón.

Ejemplo 1:
Input: [INPUT]
Output esperado: [OUTPUT]

Ejemplo 2:
Input: [INPUT]
Output esperado: [OUTPUT]

Ahora resuelve este caso nuevo:
Input: [INPUT REAL]

Aplica el mismo criterio de los ejemplos y explica cualquier caso ambiguo.

Control de calidad

Errores frecuentes y correcciones

Añadir ejemplos por costumbre

Problema: Se encarece el prompt sin una mejora clara de calidad.

Corrección: Empieza con zero-shot bien diseñado y solo añade ejemplos si hay una ganancia medible.

Ejemplos débiles o contradictorios

Problema: El modelo aprende un estándar confuso.

Corrección: Selecciona pocos ejemplos con señal alta y coherentes entre sí.

Usar few-shot para tapar un prompt flojo

Problema: Se compensa una mala especificación con más tokens.

Corrección: Mejora primero instrucciones, contexto y formato. Luego evalúa si hacen falta ejemplos.

FAQ

Preguntas frecuentes

¿Zero-shot es peor por definición?

No. En muchas tareas bien definidas funciona perfectamente y con menor coste. Todo depende del nivel de ambigüedad y precisión exigido.

¿Cuántos ejemplos debería usar en few-shot?

Normalmente 1 a 3 ejemplos bien elegidos bastan. Más ejemplos solo tienen sentido si cubren edge cases relevantes.

¿Qué tareas se benefician más del few-shot?

Clasificación, scoring, etiquetado, tono de marca, compliance editorial y cualquier caso donde un estándar concreto de salida sea crítico.

Fuentes

Referencias y lecturas complementarias