Zero-shot vs Few-shot vs Chain-of-thought: estrategias de prompting para tareas complejas

Los prompts estructurados básicos (lección anterior) funcionan bien para tareas directas como "genera una función", "traducí este texto" o "formateá este JSON". Pero fallan en tres escenarios críticos.

Situación típica 1 — Clasificación ambigua: solicitás clasificar tickets de soporte en categorías (Billing, Technical, Feature Request). Un prompt básico produce resultados inconsistentes: el mismo ticket "no puedo acceder a mi cuenta" se clasifica como Technical en una ejecución y Billing en otra.

Situación típica 2 — Formato específico del dominio: necesitás generar código siguiendo los patrones exactos de tu empresa (estructura de clases, naming conventions, manejo de errores). El LLM produce código genérico que no respeta tus convenciones, obligándote a editar manualmente cada output.

Situación típica 3 — Razonamiento complejo: pedís analizar si un cambio de código introduce vulnerabilidades de seguridad. El LLM da respuestas superficiales ("parece seguro") sin explicar qué validó ni qué casos de borde consideró.

Por qué es importante: sin la técnica adecuada obtenés outputs inconsistentes que no podés automatizar, calidad baja en tareas específicas del dominio, y falta de trazabilidad en el razonamiento — no podés auditar por qué el modelo llegó a esa conclusión.

El LLM debe resolver la tarea basándose únicamente en su entrenamiento previo y tu instrucción. Es la técnica que usamos en la lección anterior.

Cuándo funciona:

• La tarea es inequívoca (traducción literal, formateo simple)
• El LLM ya conoce el dominio (tecnologías estándar, conceptos comunes)
• No necesitás formato específico más allá de JSON/markdown genérico

Cuándo falla:

• Ambigüedad en categorías ("Technical" vs "Billing" puede solaparse)
• Formato específico de tu empresa/industria
• Tareas nuevas o poco representadas en el entrenamiento

Proporcionás 2-5 ejemplos del formato o comportamiento esperado. El LLM infiere el patrón y lo aplica al input nuevo.

Estructura de ejemplos efectivos:

• Input → Output explícito: mostrá entrada y salida claramente separadas
• Diversidad: cubrí casos en el borde entre categorías
• Consistencia: mismo formato en todos los ejemplos
• Explicación opcional: añadí "Razón:" para aclarar el criterio

Número óptimo de ejemplos:

• 2-3 ejemplos: para tareas de clasificación simple o formateo
• 3-5 ejemplos: para tareas con múltiples clases o formato complejo
• 5+ ejemplos: raramente necesario; más allá de 5, considerá fine-tuning

Forzás al LLM a "pensar en voz alta" antes de dar la respuesta final. Se activa con frases como:

El LLM respondería algo como:

Chain-of-thought puede combinarse con few-shot:

Combinaciones válidas:

• Few-shot + Chain-of-thought: para tareas complejas específicas del dominio (ej: análisis de contratos legales)
• Zero-shot + CoT: cuando no tenés ejemplos pero la tarea requiere razonamiento
• Few-shot sin CoT: para clasificación simple donde el patrón es claro

Objetivo: implementar las 3 técnicas sobre el mismo problema (clasificación de commits Git) y medir diferencias en precisión y utilidad.

Contexto inicial: usá cualquier LLM (Claude, ChatGPT, GPT-4). Necesitás acceso a un repositorio Git o podés usar estos ejemplos de commits:

Categorías objetivo: fix, feat, docs, refactor, chore, test, style

Ejecutá 3 veces el mismo prompt (refrescando la conversación entre ejecuciones) y anotá los resultados: Ejecución 1: ___ · Ejecución 2: ___ · Ejecución 3: ___

// Problema esperado: probablemente obtengas variaciones como feat, refactor, o chore dependiendo de cómo el LLM interprete "updated".

Ejecutá 3 veces y anotá: Ejecución 1: ___ · Ejecución 2: ___ · Ejecución 3: ___

// Resultado esperado: mayor consistencia. Probablemente refactor o feat de manera consistente, porque los ejemplos muestran el patrón.

Ejecutá 1 vez (CoT es más determinístico) y anotá: Categoría: ___ · Razonamiento dado: ___

// Resultado esperado: respuesta con justificación explícita, probablemente refactor o feat con explicación de por qué descartó las otras categorías.

Completá esta tabla con tus resultados:

Preguntas de reflexión:

• ¿En qué técnica confiarías para automatizar clasificación de 1000 commits?
• ¿Cuál usarías si necesitás auditar las decisiones del LLM?
• ¿Cuál es suficiente si solo clasificás 10 commits manualmente?

Probá las 3 técnicas con este commit ambiguo:

Este commit tiene dos acciones (fix typo = probablemente docs, updated steps = docs o feat).

Ejecutá cada técnica: Zero-shot clasifica como: ___ · Few-shot clasifica como: ___ · CoT explica: ___

// Resultado esperado: CoT debería identificar la ambigüedad y justificar la elección (probablemente docs porque ambas acciones están en documentación).

Concepto central: zero-shot es el default, few-shot es para enseñar formato/patrón, chain-of-thought es para forzar razonamiento. Escogé según consistencia requerida y complejidad de la tarea, no según cuál suena más sofisticada.

Para recordar:

• ✓ Zero-shot primero: siempre empezá con lo simple. Solo añadí complejidad si los resultados son insuficientes
• ✓ Few-shot para consistencia: si necesitás >90% de precisión en clasificación o formato específico, usá 3-5 ejemplos
• ✓ CoT para razonamiento: si necesitás entender el "por qué" o auditar la lógica, forzá pasos explícitos
• ✓ Medí la diferencia: ejecutá las 3 técnicas sobre el mismo problema y comparás antes de decidir
• ✓ Combiná cuando sea necesario: few-shot + CoT para tareas complejas específicas del dominio
• ✗ No uses few-shot con ejemplos malos: 3 ejemplos de alta calidad > 10 ejemplos mediocres
• ✗ No uses CoT para todo: el razonamiento explícito es lento y verboso. Usalo solo cuando aporta valor.
• ✗ No asumas que más ejemplos = mejor: más allá de 5, el beneficio marginal es mínimo. Considerá fine-tuning.