Los tres casos que tienen nombre
- Zero-shot — solo instrucción, sin ejemplo. «Clasifica este correo.»
- One-shot — una muestra. «Así es una buena clasificación: …»
- Few-shot — varias muestras, normalmente de tres a cinco.
La cuenta no es un capricho: el modelo no aprende una regla de los ejemplos, capta un patrón. Con un solo ejemplo todavía no puede saber qué es esencial y qué es casual. Con varios, sí.
¿Cuándo vale más que una instrucción?
Cuando la regla es más difícil de escribir que de reconocer.
- Tono. «Sé cercano pero no colega» significa cinco cosas distintas para cinco personas. Dos correos tuyos anteriores no dejan lugar a dudas.
- Una forma fija. Describir una plantilla estricta ocupa media página; una muestra rellenada, tres líneas.
- Casos límite. «¿Qué cuenta como urgente?» — un ejemplo de algo urgente y otro de algo que casi lo es dicen más que cualquier definición.
- Vuestro propio vocabulario. Cómo llamáis a las cosas en la empresa. Eso no puede adivinarlo, solo verlo.
Donde la regla sí se puede formular con precisión — «150 palabras como máximo», «el formato de fecha es AAAA-MM-DD» —, escríbela como regla. Es más corta y más fiable que un ejemplo.
¿Cuántos ejemplos y cómo?
La recomendación de los propios proveedores es de tres a cinco. Con menos no cuaja el patrón; con más gastas context window más deprisa de lo que mejora el resultado.
Más importante que la cantidad es que se diferencien entre sí. Que haya uno fácil, uno típico y uno de los que nunca han salido bien. Un conjunto de ejemplos es bueno cuando cubre el rango en el que se mueven las tareas reales.
La trampa de la que se habla poco
El modelo se queda con todo lo que los ejemplos tienen en común — también con aquello que tú desconoces.
Si tus cuatro correos de muestra van dirigidos por casualidad a hombres, son cortos y son de un viernes por la tarde, el modelo también tomará eso como patrón. Si todos tienen tres párrafos, no te extrañe que nunca salgan cuatro. Si en todos hay una disculpa, se disculpará incluso cuando no haya pasado nada.
De ahí salen dos reglas prácticas:
- Mira tus ejemplos y pregúntate qué tienen en común que no pusiste a propósito. Son cinco minutos y atrapan la mitad de los errores.
- Cualquier rasgo presente en todos se convierte en regla. Si es lo que quieres, perfecto. Si no, cambia un ejemplo.
¿Dónde van los ejemplos?
Separados de la instrucción. Si los ejemplos se funden con el texto, el modelo puede tomarlos por parte de la tarea e intentar responder a la muestra en lugar de seguirla.
La solución que funciona es un marcado sencillo — una etiqueta, una línea separadora o una marca al estilo XML:
<ejemplo>
Entrada: El envío llegó con tres días de retraso.
Salida: categoria=envio, urgencia=2
</ejemplo>
Esto lo desarrolla con más detalle Delimitadores y secciones, en un artículo aparte. Aquí lo único importante es esto: que haya un límite visible entre donde acaba la muestra y donde empieza la tarea real.
Un ejemplo que muestra la diferencia
La tarea: hay que clasificar los correos entrantes en una sola línea.
Solo con instrucción:
Clasifica el correo. Categorías posibles: facturación, envío, reclamación, otros. Indica también la urgencia del 1 al 3.
Esto funcionará — más o menos. En los casos límite dudará: ¿un correo enfadado por un envío tardío es reclamación o envío? ¿Y qué significa exactamente tu escala de urgencia?
Con tres ejemplos:
[la misma instrucción]
<ejemplo> «Es la tercera vez que pido la factura de febrero.» → facturación, 2 </ejemplo> <ejemplo> «El paquete llegó con tres días de retraso, pero llegó.» → envío, 1 </ejemplo> <ejemplo> «Por el retraso se nos fue al traste el evento, esto no lo dejo así.» → reclamación, 3 </ejemplo>
El tercer ejemplo es lo que hizo que mereciera la pena: muestra que decide la consecuencia, no el tema. Eso habría sido difícil de escribir como regla.
Cuando ni los ejemplos bastan
Si ni con veinte ejemplos respeta el formato de forma fiable, o si hay que dar tantos ejemplos por petición que sale caro, se te ha quedado pequeño el prompting. Ahí entra el entrenamiento adicional — Fine-tuning, RAG o mejor prompt te dice cuál es tu caso.
Qué llevarte
Un ejemplo no es adorno, es la forma corta de una especificación. De tres a cinco muestras distintas entre sí, separadas de la instrucción, y una pregunta de control para ti: ¿qué tienen en común que yo no pretendía?