Zero-shot, few-shot o razonamiento paso a paso, cuál usar según dónde falla

Un emisor de tarjetas clasifica reclamos en cinco motivos con un prompt que solo lista cada código y una definición de una línea. La precisión general es buena, pero casi todos los errores vienen de un par: “mercadería no recibida” contra “mercadería distinta a la descripta”, cuando el cliente escribe “llegó la caja vacía”. Un analista propone 40 reglas si-entonces; otro, pasar ya al modelo más grande. Ninguna de las dos mira dónde falla.

La técnica sale del error

Las tres técnicas del objetivo no son niveles de sofisticación: cada una arregla un tipo de falla distinto.

Lo que muestra la evaluación	Técnica que conviene
La tarea es clara y el modelo la resuelve bien con instrucciones	Sin ejemplos (zero-shot): no sumes nada
Confunde dos categorías vecinas, o el formato y el tono no salen parejos	Con pocos ejemplos (few-shot) que muestren la frontera o el formato
Falla en tareas de varios pasos: cálculos encadenados, comparar varias fuentes, aplicar reglas en orden	Razonamiento paso a paso (chain-of-thought) o más pensamiento del modelo
Falla aunque el prompt sea bueno, y otro modelo lo resuelve con el mismo prompt	No es prompting: es modelo inadecuado (lección 1)

Fijate que todo arranca con un set de evaluación que te diga dónde están los errores. “Anda más o menos” no alcanza para elegir.

Few-shot bien hecho

Los ejemplos son de lo más confiable para guiar el criterio, el formato y el tono. Para que funcionen:

• Pocos y variados: entre tres y cinco suele alcanzar, cubriendo los casos borde (edge cases) y con redacciones distintas para que el modelo no copie un patrón que no buscabas.
• Representativos: sacados de casos reales, no inventados para que sean fáciles.
• Separados: dentro de etiquetas <ejemplo> (y varios en <ejemplos>), para que no se confundan con las instrucciones.

Contra la lista de 40 reglas: los ejemplos enseñan el criterio y generalizan a la próxima redacción; las reglas cubren lo ya visto, son frágiles y vuelven el prompt imposible de mantener.

Razonamiento paso a paso: cuándo paga

Pedirle al modelo que razone antes de responder mejora las tareas con varios pasos, a cambio de más tokens de salida y más latencia. Por eso depende del camino:

• En un proceso nocturno, un razonamiento breve antes de la etiqueta es un costo aceptable.
• En un camino interactivo con meta de latencia, usalo solo donde la evaluación muestra que mejora.
• Si el razonamiento tiene que procesarse aparte de la respuesta, pedilo en etiquetas propias (por ejemplo, <analisis> y después <respuesta>).

En los modelos actuales, el pensamiento adaptativo (adaptive thinking) decide cuánto pensar según la complejidad del pedido y el parámetro de esfuerzo. Ese parámetro es la palanca para subir o bajar el razonamiento sin reescribir el prompt.

Lo que no es razonamiento: pedirle al modelo un puntaje de confianza y descartar en silencio lo que puntúa bajo. El puntaje autoinformado no es una medida confiable, y descartar sin avisar pierde casos reales.

Las trampas típicas

• Una lista interminable de reglas para cubrir cada redacción vista.
• Saltar al modelo más grande sin probar antes el ajuste más barato.
• Ejemplos todos iguales, que el modelo imita al pie de la letra.
• Ejemplos sueltos en el texto de las instrucciones, sin etiquetas.
• Razonamiento paso a paso en todos los caminos, incluido el que tiene meta de latencia.
• Confiar en la confianza que el modelo dice tener.

En el examen

Buscá en el escenario la descripción del error. Si se concentra en una frontera entre dos categorías o en un formato inconsistente, la respuesta es few-shot con pocos ejemplos variados en etiquetas. Si falla en tareas de varios pasos y hay margen de latencia, es razonamiento paso a paso o más esfuerzo. Si el escenario dice que el proceso es nocturno o que la latencia no importa, es una pista para sumar razonamiento. Descartá las listas de reglas y los cambios de modelo como primer paso.