Los few-shot examples son una de las formas más efectivas de mejorar la calidad de un modelo sin fine-tuning — pero también una de las formas más fáciles de duplicar tu factura si los metes sin criterio en cada request.
El error común es pensar que el problema de los few-shot examples es "cuántos poner". El problema real es que, sin caching, cada ejemplo se factura a precio completo en cada request — así sea el mismo bloque de 3,000 tokens que enviaste hace un segundo. Si tu prompt tiene 10 ejemplos bien elegidos que ocupan 4,000 tokens, y haces 1,000 requests al día sin cachear, estás pagando 4 millones de tokens de input solo en ejemplos que no cambiaron.
La solución de mayor impacto es la más simple: pon el bloque de ejemplos en una posición estable del prompt y márcalo con `cache_control`.
Con esto, solo pagas precio completo por los ejemplos en el primer request de cada ventana de caché (5 minutos por defecto); el resto se sirve a ~10% del costo.
Antes de optimizar el caching, optimiza la cantidad. La intuición de "más ejemplos = mejor" no se sostiene después de cierto punto — y cada ejemplo extra diluye la atención del modelo hacia el patrón real que quieres enseñar. En la práctica:
- **3-5 ejemplos bien elegidos** que cubran los casos límite reales suelen superar a 15 ejemplos genéricos. - Prioriza ejemplos que cubran **el caso que el modelo suele fallar**, no el caso trivial que ya resuelve bien sin ayuda. - Un ejemplo de un caso ambiguo con su resolución correcta vale más que tres ejemplos del caso obvio.
Si estás usando 15+ ejemplos y todavía tienes errores, el problema probablemente no es cantidad de ejemplos — es que la tarea necesita una instrucción explícita que ningún ejemplo va a comunicar por sí solo (criterios de desambiguación, formato exacto, restricciones de negocio).
Si tienes una librería grande de ejemplos (50, 100, varios cientos) cubriendo distintos subtipos de tarea, mandarlos todos en cada request es tanto caro como contraproducente. La alternativa es recuperar dinámicamente solo los ejemplos más relevantes al input actual — el mismo principio de retrieval que usarías para RAG, aplicado a tu banco de ejemplos.
El trade-off: la selección dinámica rompe el caching de ese bloque específico, porque cambia por request. La estrategia correcta suele ser híbrida: un núcleo pequeño y fijo de ejemplos cacheado (los 2-3 casos universales), más un puñado dinámico y no cacheado para el caso específico.
Muchas veces el ejemplo original viene de una conversación real completa (con saludo, contexto de negocio, ida y vuelta). El modelo no necesita esa conversación completa — necesita el patrón input→output limpio.
Comprimir ejemplos reales a su patrón esencial suele reducir el tamaño del bloque de few-shot en 60-80% sin perder la señal que el modelo necesita.
Si te encuentras necesitando docenas de ejemplos para cubrir la variedad de casos, y aun así el modelo falla en casos nuevos fuera de esa distribución, es la señal de que el problema no es de contexto — es de tarea. En ese punto hay dos caminos mejores que seguir apilando ejemplos:
- **Fine-tuning**, si el patrón es lo suficientemente estable y de alto volumen para justificar el costo de entrenar. - **Descomponer la tarea** en subtareas más simples con sus propios prompts especializados, en vez de intentar que un solo prompt con 30 ejemplos cubra toda la variedad.
- ¿Este ejemplo cubre un caso que el modelo realmente falla, o es redundante con uno que ya tienes? - ¿Está en la posición cacheable del prompt, o se está regenerando en cada request? - ¿Está comprimido al patrón esencial, o arrastra contexto conversacional innecesario? - ¿El problema que este ejemplo intenta resolver es realmente de "no vio suficientes casos", o es de instrucción ambigua que ningún ejemplo va a arreglar?
La combinación de menos-pero-mejores ejemplos, caching agresivo del bloque estable, y selección dinámica solo cuando el volumen de variantes lo justifica, es lo que separa un pipeline de few-shot que escala de uno que se vuelve impagable en producción.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel