Few-shot en LLMs: cuántos ejemplos son el punto óptimo antes de que la calidad caiga (por tarea)
La mayoría de las guías de prompt engineering coinciden en una regla razonable: “cuantos más ejemplos few-shot, mejor”. La seguí un buen tiempo hasta que decidí medirla en un experimento controlado. Los resultados no coincidieron.
Corrí tres tareas independientes (clasificación de sentimiento, extracción estructurada de datos y traducción PT→EN técnica) con 2, 4, 8, 16 y 32 ejemplos few-shot en el mismo modelo. La conclusión fue clara: cada tarea tiene un punto óptimo distinto de ejemplos, y pasarlo baja la calidad y multiplica el costo de tokens.
Este artículo es una guía práctica basada en 3.000 llamadas medidas, pensada para que puedas encontrar el punto óptimo de tu propia tarea sin necesidad de montar un proyecto de investigación.
Qué es un punto óptimo en few-shot y por qué existe
En prompt engineering, few-shot significa mostrar al modelo algunos ejemplos de entrada y salida esperada antes de enviarle la consulta real. La intuición común es que más ejemplos ayudan al modelo a “aprender” mejor el patrón. Ese aprendizaje tiene un techo.
Este fenómeno se llama context poisoning por few-shot: a partir de cierto número de ejemplos, el modelo copia detalles superficiales de esos ejemplos (longitud típica de la respuesta, palabras específicas, estructura sintáctica) en vez de generalizar el patrón. La calidad medida por F1 o métrica equivalente cae, y el costo en tokens sigue subiendo.
Este comportamiento está documentado en la guía oficial de prompt engineering de Anthropic, que recomienda entre 3 y 5 ejemplos como referencia general. La medición que verás confirma esa referencia, pero también muestra que el número exacto varía por tarea.
Configuración del experimento
- Modelo: Claude Haiku 3.5 (precio público de Anthropic vigente al momento de esta medición: 1M tokens de entrada ≈ USD 0,80, 1M tokens de salida ≈ USD 4,00)
- Tareas: (1) clasificación de sentimiento en reseñas, (2) extracción estructurada de recibos (razón social, monto, fecha), (3) traducción PT-BR → EN técnico
- Valores de N probados: 2, 4, 8, 16, 32 ejemplos
- Volumen: 200 muestras por tarea × 5 configuraciones × 3 tareas = 3.000 llamadas
- Métrica primaria: F1 macro (clasificación/extracción), chrF (traducción)
- Métricas secundarias: tokens consumidos por respuesta, latencia promedio
Los ejemplos se seleccionaron al azar de un pool de 100 por tarea. El mismo pool se usó para todos los valores de N, cambiando únicamente el número tomado.
Resultados por tarea
Empiezo con la tabla resumen y después analizo cada caso.
| Tarea | Mejor N | Métrica en punto óptimo | Métrica en N=32 | Costo N=32 vs punto óptimo |
|---|---|---|---|---|
| Clasificación sentimiento | 4 | F1 0,89 | F1 0,86 | 3,2x |
| Extracción de recibos | 16 | F1 0,94 | F1 0,93 | 1,9x |
| Traducción PT→EN | 8 | chrF 62,4 | chrF 60,1 | 3,8x |
Tres tareas, tres puntos óptimos: 4, 16 y 8 respectivamente. Ninguno coincide con N=32. En los tres casos, subir a 32 ejemplos empeoró la métrica de calidad y multiplicó el costo entre 2 y 4 veces.
Clasificación de sentimiento: N=4 es suficiente
La clasificación de sentimiento es una decisión binaria o ternaria (positivo, neutro, negativo). El modelo necesita aprender dos cosas de los ejemplos: el formato exacto de la respuesta (una palabra, sin explicación) y el criterio de clasificación (por ejemplo, cómo tratar el sarcasmo o los casos realmente neutros).
Con dos ejemplos el modelo aprende el formato pero no el criterio. Con cuatro aprende ambos. A partir del quinto, se fija en detalles irrelevantes de los ejemplos mostrados y su desempeño baja.
Extracción estructurada: N=16 cubre la variedad de formatos
La extracción de datos estructurados es una tarea más rica que la clasificación. Los recibos vienen en muchos formatos visuales, y cada ejemplo few-shot enseña al modelo a manejar una variación específica. Con menos de 16 ejemplos quedan formatos fuera que el modelo no reconocerá. Con más de 16, el modelo mezcla campos entre líneas porque asocia patrones que en realidad son coincidencias.
Es la tarea que más se beneficia de un N alto, y aún así N=32 no supera a N=16. Más ejemplos ayudan hasta que empiezan a meter ruido.
Traducción técnica: N=8 marca el punto de inflexión
La traducción técnica requiere vocabulario específico del dominio (“acceso” → “access” en contexto de sistemas, no “log in”; “aplicación” → “app”; “usuario” → “user”). Ocho ejemplos cubren los patrones principales de vocabulario técnico.
Al pasar de N=8, el modelo copia la construcción sintáctica exacta de los ejemplos en vez de traducir la consulta con fluidez. El chrF cae porque el resultado se vuelve rígido y calcado en el estilo de los ejemplos.
El costo en tokens que suele ignorarse
El deterioro de la métrica es solo la mitad del problema. La otra mitad es el costo de tokens que crece sin devolver valor.
| Tarea | Costo promedio por llamada en N óptimo | Costo en N=32 | Delta mensual (10k llamadas) |
|---|---|---|---|
| Sentimiento (N=4) | USD 0,0006 | USD 0,0020 | +USD 14 |
| Extracción (N=16) | USD 0,0036 | USD 0,0068 | +USD 32 |
| Traducción (N=8) | USD 0,0024 | USD 0,0092 | +USD 68 |
En un flujo de 10.000 llamadas mensuales, la diferencia ronda los USD 114. Con 100.000 llamadas mensuales, sube a USD 1.140. Para lectores en México eso equivale a MXN ≈ 22.500; en Argentina, ARS ≈ 1.050.000 (al tipo de cambio de agosto 2026); en Chile, CLP ≈ 1.070.000.
Estos números pesan más en LatAm porque el costo relativo respecto al salario técnico es mayor. Optimizar el prompt se traduce en un ahorro medible en la línea de infraestructura.
Cómo encontrar tu punto óptimo sin sobredimensionar el experimento
No hace falta ejecutar 3.000 llamadas para tomar una decisión de diseño de prompt. Este es el protocolo mínimo que uso ahora en mis proyectos.
Paso 1: parte de N=3. Tres ejemplos cubren formato más una variación mínima, y es la base realista para la mayoría de las tareas de LLM.
Paso 2: compara N=3 contra N=8 con 50 muestras. Si N=8 mejora la métrica más de 5 puntos porcentuales, la tarea se beneficia de más ejemplos y vale la pena probar N=16. Si N=8 empata o pierde contra N=3, tu punto óptimo cae entre 3 y 8. Ahí frena.
Paso 3: mide el costo por llamada en cada valor de N. Si subir N mejora 0,3 puntos de F1 y triplica el costo, ese ajuste ya es una decisión de negocio y conviene tratarla como tal.
Paso 4: acepta que no existe un “mejor N universal”. El punto óptimo depende de la tarea, del modelo (Haiku no se comporta igual que Sonnet en este experimento) y de la distribución de tu dataset. Un valor fijo en el prompt envejecerá mal cuando cambies el modelo o crezca el volumen.
Errores frecuentes que este experimento me hizo corregir
Tras esta medición, revisé los prompts de mi harness de revisión de PRs y encontré tres patrones que estaba usando por costumbre, sin base empírica:
- Clasificación “bloqueante o menor” en revisiones: tenía N=10 por defecto. Bajé a N=3 y el desempeño mejoró marginalmente
- Extracción “qué archivos toca el PR”: venía con N=15. Con N=8 no perdí calidad
- Resumen breve de PR: tenía N=12. Con N=4 el resumen se volvió más natural
El costo total del bloque de prompts del harness cayó 42%. La calidad medida por mi evaluación interna subió un poco (no significativamente, pero al menos no bajó).
Conclusión práctica
Few-shot es de los pocos parámetros de prompt engineering con un punto óptimo medible. Conviene hacer el experimento antes de fijar un número por intuición. La referencia general de la documentación de Anthropic (“3 a 5 ejemplos suelen ser suficientes”) quedó bien calibrada para tareas simples; para tareas más ricas como extracción estructurada, N puede subir hasta 16, pero rara vez más allá.
Si estás empezando en prompt engineering, complementa este análisis con dos artículos previos sobre el ecosistema: Context engineering vs prompt engineering: benchmark 4.6x muestra dónde encaja few-shot dentro del campo más amplio, y Modelo pequeño con buen contexto gana con 70% menos costo explica cómo el diseño del contexto puede reemplazar a modelos más grandes.
La regla que me llevo de este experimento es simple: mide antes de suponer, y ajusta cuando cambies de modelo. Es un hábito barato que reduce la factura.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev
Libro relacionado Convirtiendo LLMs de Mentirosos en Expertos Ingeniería de Contexto desde cero — RAG, MCP, CLAUDE.md y Agentic RAG, con benchmarks que muestran hasta 4,6× de mejora Ver la página del libro → ¿Te resultó útil este artículo?