¿Qué es Few-Shot Learning y por qué 3-5 ejemplos en el prompt cambian todo?
La técnica de prompt engineering con mejor ROI: añadir un puñado de ejemplos input/output al prompt para que el modelo "vea" el patrón antes de responder. Sin entrenamiento, sin fine-tuning.
Actualizado mayo 2026
Few-shot learning: aprender de pocos ejemplos sin entrenar el modelo.
Few-shot learning es la técnica de incluir un pequeño número de ejemplos input/output (típicamente 2-5) dentro del prompt para guiar la respuesta del LLM. El modelo no se reentrena: aprende el patrón "en contexto" leyendo los ejemplos y aplicándolo a la nueva entrada. Es la técnica de prompt engineering con mejor relación valor/esfuerzo.
El concepto se hizo popular con GPT-3 en 2020. Brown et al. mostraron que LLMs grandes podían realizar tareas nuevas sin entrenamiento adicional, simplemente mostrando ejemplos en el prompt. Tres modos: zero-shot (sin ejemplos, solo instrucción), one-shot (un ejemplo) y few-shot (2-5+ ejemplos). En 2026 sigue siendo la primera herramienta a probar antes de RAG o fine-tuning.
La estructura típica de un prompt few-shot: (1) instrucción/contexto/rol, (2) N ejemplos en formato "Input: X / Output: Y", (3) el caso real que quieres resolver. El modelo extrapola el patrón. Funciona especialmente bien en tareas con formato estructurado (clasificación, extracción, transformación) donde la salida tiene una forma clara.
En una pyme española en 2026, el few-shot resuelve sin más infraestructura: clasificar correos por intención, extraer datos de textos libres, traducir con tono específico, generar respuestas en formato propio. Mejora típica: pasar del 30-50% de aciertos con prompt vago al 80-90% con 3-5 ejemplos bien elegidos. Sin coste técnico adicional más allá de unos tokens extra por llamada.
Seis casos donde few-shot da mejora dramática
Donde lo hemos visto pasar de respuestas mediocres a calidad de producción.
Clasificación con categorías propias
Clasificar correos en "comercial / soporte / facturación / spam". Sin ejemplos: el modelo inventa categorías. Con 5 ejemplos por categoría: accuracy 88-95%. Mejora más grande de toda la lista.
Extracción estructurada con schema propio
Sacar campos de facturas a JSON propio. Mostrar 3 facturas reales con su JSON esperado dispara la precisión y reduce errores de formato a casi cero.
Transformación de texto con tono
Convertir notas internas en respuesta de soporte profesional. Mostrar 3-5 ejemplos del tono deseado y el modelo lo replica mejor que con cualquier descripción.
Generación con formato fijo
Generar fichas de producto con secciones específicas (descripción + ventajas + ficha técnica + CTA). Ejemplos en formato exacto evitan que el modelo se invente estructura propia.
Casos límite y excepciones
Mostrar al modelo ejemplos de casos raros (factura sin IVA, ticket sin fecha) con su respuesta correcta enseña a manejarlos. Sin esto, el modelo extrapola erróneamente.
Estilo de respuesta específico
Si quieres respuestas siempre en bullets, siempre con cita de fuente, siempre cerrando con CTA: 3 ejemplos enseñan el patrón mejor que un párrafo de descripción.
Cinco reglas para elegir los ejemplos correctos
Diversidad: cubre distintos casos
No elegir 5 ejemplos del mismo tipo. Cubre las variantes principales que verás en producción. Si clasificas correos en 6 categorías, al menos 1 ejemplo por categoría (o las 4 más comunes).
Incluye casos difíciles
Tendencia natural: elegir ejemplos donde el modelo ya acierta. Error: no aprende donde fallaba. Mejor: incluir 1-2 casos límite, ambiguos, o de excepción con la respuesta correcta.
Formato exactamente igual al output esperado
Si quieres JSON, los ejemplos en JSON con comillas correctas, indentación consistente. El modelo replica formato literal. Inconsistencia en ejemplos genera inconsistencia en salida.
Orden importa: relevantes al final
Investigación muestra que en prompts largos, los modelos prestan más atención a inicio y final. Coloca los ejemplos más representativos cerca del input real para mejor extrapolación.
Cantidad: 3-5 suele bastar
Por debajo de 3: poca señal. Por encima de 7-10: rendimientos decrecientes y coste extra de tokens. Sweet spot pyme: <strong>3-5 ejemplos bien elegidos</strong>. Para tareas muy complejas, hasta 10.
Few-shot dinámico, retrieval-augmented y chain-of-thought con ejemplos.
Few-shot estático: los mismos 3-5 ejemplos en cada llamada. Es el patrón básico. Few-shot dinámico: en cada llamada eliges los ejemplos más relevantes a la pregunta concreta (buscas en una BBDD de ejemplos por similitud con la query). Combina RAG con few-shot: cuando hay mucha variabilidad, el few-shot dinámico mejora aún más la precisión.
Combinar few-shot con chain-of-thought: en cada ejemplo, no solo mostrar input/output sino también el razonamiento intermedio. El modelo aprende a razonar paso a paso antes de responder. Especialmente útil en problemas multi-paso (cálculos, decisiones legales, diagnósticos).
Comparado con zero-shot: zero-shot es más rápido y barato pero menos preciso en tareas estructuradas. Few-shot añade tokens (más coste) pero suele justificarlo con ganancia de precisión. Prompt caching (Anthropic, OpenAI) reduce el coste extra de few-shot hasta 90% cuando los ejemplos son los mismos en cada llamada.
Frente a fine-tuning: few-shot es la primera opción siempre. Más rápido (cambios en minutos), más barato (sin entrenamiento), más flexible (cambias ejemplos sin reentrenar). Solo cuando few-shot bien hecho llega a techo y necesitas más, plantear fine-tuning. Ver fine-tuning vs RAG.
Cinco errores típicos al usar few-shot
Ejemplos contradictorios
Dos ejemplos similares con respuestas distintas (sin justificación). El modelo se confunde y elige el patrón con menor coste de razonar. Auditar consistencia de tus ejemplos.
Pocos ejemplos para tarea compleja
Una tarea con 15 sub-tipos y solo 3 ejemplos: el modelo extrapola mal. Si tu dominio tiene mucha variabilidad, sube a 6-10 ejemplos cubriendo los sub-tipos principales.
No iterar con casos reales
Diseñar few-shot a priori y no revisarlo. Mejor: deploy inicial, recoger 50 ejemplos donde falla, ajustar los ejemplos del prompt para cubrir esos casos. Iteración semanal.
Ejemplos muy largos o muy cortos
Ejemplos de 2 líneas cuando el output esperado es de 500 palabras: el modelo extrapola mal el tamaño. Ejemplos en el rango de longitud real del output esperado.
No medir el impacto
Asumir que añadir ejemplos siempre mejora. A veces no, o lo hace marginalmente. Medir contra dataset de evaluación antes/después. Ver <a href="/glosario/que-es-evaluacion-llm" class="text-magnetia-red underline">evaluación LLM</a>.
Dudas que nos hacéis llegar
¿Tus prompts dan respuestas mediocres?
Diagnóstico: revisamos prompts actuales, casos de fallo y construimos versión optimizada con few-shot. Resultado típico: paso del 50-70% al 85-95% de aciertos en tareas estructuradas.