Few-shot en agentes: tres ejemplos de oro, no veinte clones

Un agente que clasifica tickets, extrae campos o decide tool vs ask_user no “entiende la tarea” porque le escribiste un párrafo. La entiende porque vio tres casos. Zero-shot es la instrucción. Few-shot es el contrato visible: entrada, salida, borde.

Esto no es prompt engineering: esa guía cubre system vs user, roles y formato. Aquí el objeto es el set de ejemplos. Tampoco es structured outputs: el schema obliga la forma; los ejemplos enseñan el criterio (cuándo Neutral, cuándo no llamar la tool). Ni temperatura y sampling: eso pinnea aleatoriedad; esto pinnea el patrón.

Contrato: tres ejemplos de oro, mismo formato, uno de ellos un borde. No veinte clones.

Qué es few-shot (y qué no)

OpenAI (markdown canónico, HTTP 200 el 2026-09-06): few-shot learning lets you steer a large language model toward a new task by including a handful of input/output examples in the prompt, rather than fine-tuning. El modelo picks up the pattern. Pide diversidad de entradas. Los ejemplos van en el mensaje developer, no mezclados con el turno del usuario.

Claude (HTTP 200 el 2026-09-06): examples are one of the most reliable ways to steer Claude's output format, tone, and structure. Few-shot / multishot. Tres reglas: relevantes (espejo del caso real), diversos (bordes, no el mismo patrón), estructurados (<example> dentro de <examples>). Tip canónico: 3–5. Puedes pedirle a Claude que evalúe el set o que genere más a partir de los tuyos.

Gemini (HTTP 200 el 2026-09-06, sección Zero-shot vs few-shot prompts): few-shot regula formatting, phrasing, scoping, or general patterning. Recomiendan incluir few-shot siempre; si los ejemplos son claros, you can remove instructions. Avisan overfitting si metes demasiados. El formato debe ser idéntico: XML, espacios, saltos, splitters.

Zero-shot = instrucción. One-shot = un caso (casi nunca basta: el modelo copia ese único estilo). Fine-tuning = pesos. Few-shot = prompt. Si el set no cabe, recorta ejemplos, no el system prompt: ver ventana de contexto.

Los tres de oro

Un set de agente no es “positivo / negativo / positivo otra vez”. Es cobertura:

1. Caso feliz. El 80 % del tráfico. Misma forma que quieres en producción.
2. Borde. El ticket vacío, el JSON a medias, el usuario que pide dos tools a la vez.
3. Negativo / rechazo. Qué no hacer: no inventar campo, no llamar refund si falta order_id, devolver ask_user.

Claude lo llama diversidad para que no pick up unintended patterns. OpenAI lo dice igual: a diverse range of possible inputs with the desired outputs. Gemini: specific and varied examples. Tres clones del caso feliz enseñan el clon, no la tarea.

En un agente, el “output deseado” no es prosa: es la decisión. Positive. {"intent":"refund","order_id":null}. tool: search_docs. Si el ejemplo razona en voz alta y producción no, el modelo copiará el razonamiento. Claude, con thinking, pide lo contrario a propósito: pon <thinking> dentro del few-shot si quieres que generalice ese estilo a sus bloques de thinking. Si thinking está off, no lo pongas.

Dónde viven (system / developer, no el turno)

OpenAI coloca Examples después de Identity e Instructions y antes del Context variable. El instructions de Responses API takes priority over a prompt in the input. Eso es lo que quieres: el set es estable; el turno del usuario cambia. Así también entra en prompt caching: prefix fijo al inicio del body.

Claude: XML para que no se confundan instrucciones, contexto, ejemplos e input. Tags consistentes. No mezcles un ejemplo suelto en el último user message “para esta vez”: el modelo no sabe si es dato o patrón.

Gemini: el objetivo primario del few-shot suele ser el formato de respuesta. Si un ejemplo usa Answer: Explanation2 y el siguiente La mejor es la 2, perdiste el contrato. Espacios y newlines cuentan.

# Identity
Clasificas reseñas cortas. Una palabra: Positive, Negative o Neutral.

# Instructions
* Solo una de esas tres palabras.
* Sin markdown ni comentario.

# Examples
<product_review id="example-1">
I absolutely love this headphones — sound quality is amazing!
</product_review>
<assistant_response id="example-1">
Positive
</assistant_response>
<product_review id="example-2">
Battery life is okay, but the ear pads feel cheap.
</product_review>
<assistant_response id="example-2">
Neutral
</assistant_response>
<product_review id="example-3">
Terrible customer service, I'll never buy from them again.
</product_review>
<assistant_response id="example-3">
Negative
</assistant_response>

Ese bloque es el ejemplo canónico de OpenAI (docs 2026-09-06). Tres clases, tres formas, cero prosa extra. Cópialo como estructura, no como dataset de reseñas.

Agentes: ejemplos de tools, no de charla

OpenAI, en prompting de coding agents: include concrete examples of how to invoke commands with the provided functions. El few-shot de un agente no es “así se habla”. Es cuándo llamar qué.

Mal: tres diálogos amables donde el asistente “busca y responde”. Bien:

Entrada (user)	Salida del agente
“¿Cuál es el SLA del plan Pro?”	search_docs({query:"SLA plan Pro"})
“borra mi cuenta ahora”	no tool; ask_user + confirma scope
“reembolsá orden 4412”	refund({order_id:"4412"}) — no inventar monto

El borde (fila 2) evita que el modelo generalice “siempre hay una tool”. El negativo evita alucinación de argumentos. Si usas schema de tool, el ejemplo debe respetarlo: un few-shot con orderId camelCase contra un schema order_id enseña el bug.

No pongas PII real en los ejemplos. Inventa IDs. El set vive versionado junto al system prompt, no en un Notion que nadie revisa.

Cuántos: 3–5, no el corpus

Claude: 3–5 for best results. Gemini: experimenta el número; demasiados → overfit the response to the examples. OpenAI: a handful, no un dataset.

Señales de overfitting: el modelo copia frases de los ejemplos, rechaza inputs que no “parecen” el set, o elige siempre la misma tool que salió 4 de 5 veces. Cura: quita clones, mete un borde, corre eval.

Más ejemplos no sustituyen evals. Un set estático se pudre cuando cambia el producto. Mide con evals: 20–50 casos reales fuera del few-shot. Si un caso de eval falla siempre, o entra al set (si es patrón) o es bug de tool/schema (si es hecho).

Few-shot tampoco arregla temperatura alta ni un schema flojo. Pinnea sampling. Cierra el JSON con structured outputs. Luego, y solo luego, añade el tercer ejemplo.

Checklist

• El set vive en developer / system, no en el último user turn.
• Tres mínimo: feliz, borde, rechazo.
• Mismo formato en los tres (tags, newlines, etiqueta de salida).
• El output del ejemplo es la decisión (label, JSON, tool call), no un ensayo.
• Ningún ejemplo duplica el patrón de otro.
• IDs y nombres son ficticios.
• El prefix (identity + instructions + examples) es estable para cache.
• Hay evals fuera del set. Un fallo reiterado o entra al set o es otra capa.

FAQ

¿Zero-shot no alcanza ya con modelos grandes? Gemini dice que los prompts sin few-shot are likely to be less effective, y que puedes hasta quitar instrucciones si los ejemplos son claros. Para un agente con tools, zero-shot deja el criterio implícito. El tercer ejemplo (rechazo) es el que evita la tool fantasma.

¿Lo pongo como mensajes user/assistant intercalados? OpenAI muestra el patrón dentro del developer con XML. Claude también encapsula en <example>. Intercalar turns user/assistant funciona, pero ensucia el historial real del agente y rompe cache si el set “parece” conversación. Prefiere bloque estático.

¿Y si el ejemplo necesita razonar? Claude: multishot examples work with thinking — <thinking> dentro del few-shot para generalizar el estilo. Si thinking está off, no simules CoT en el ejemplo: el modelo lo copiará al usuario. Sepárate con tags <answer>.

¿Cuándo fine-tunear en vez de few-shot? Cuando el set ya no cabe, overfitting, o el patrón es un estilo de dominio (cientos de labels). OpenAI presenta few-shot rather than fine-tuning. Empieza por 3–5 + eval. Fine-tune es otro presupuesto.

Una línea

Tres ejemplos de oro en el mensaje estable, mismo molde, un borde. El resto es eval, no más clones.