Criterios Explícitos y Few-Shot Prompting
Criterios Explícitos y Few-Shot Prompting
Anterior: Agent Teams y Worktrees · Índice · Siguiente: Structured Output
Por qué los criterios vagos fallan
Una instrucción como “check that comments are accurate” es ambigua. Claude interpreta “accurate” de forma amplia y termina flaggeando comentarios que simplemente no están actualizados, incluso si no causan confusión real.
La alternativa efectiva es un criterio categórico: “flag comments only when the claimed behavior directly contradicts what the code does”. Esto reduce drásticamente los falsos positivos porque Claude tiene un umbral claro para decidir qué reportar.
Instrucciones generales vs criterios categóricos
| Tipo | Ejemplo | Problema |
|---|---|---|
| Vago | ”Be conservative with flagging issues” | Claude no sabe qué significa “conservative” |
| General | ”Check comments are accurate” | Flaggea cualquier discrepancia menor |
| Categórico | ”Flag only when claimed behavior contradicts code” | Umbral claro y reproducible |
Las instrucciones generales como “be conservative” fallan porque Claude no tiene una definición operativa de qué tan conservador ser. Los criterios categóricos eliminan la ambigüedad.
El impacto de los falsos positivos
Los falsos positivos no solo son molestos — destruyen la confianza en categorías que sí son precisas. Si un code review tool flaggea 10 issues y 7 son falsos positivos de comentarios, el desarrollador aprende a ignorar TODO el output, incluyendo los 3 bugs reales.
Estrategia de restauración de confianza
- Identificar categorías con alta tasa de falsos positivos
- Deshabilitar temporalmente esas categorías
- Refinar los criterios con ejemplos específicos
- Re-habilitar gradualmente con criterios categóricos
- Monitorear la tasa de dismissal por categoría
Para el examen: Si un escenario describe que developers ignoran findings de un review tool, la respuesta correcta involucra refinar criterios específicos o deshabilitar categorías problemáticas — no “mejorar el modelo” ni “agregar más contexto general”.
Escribir criterios de revisión específicos
Un buen set de criterios define explícitamente qué reportar y qué ignorar:
Reportar:
- Bugs donde el código produce resultados incorrectos
- Vulnerabilidades de seguridad (SQL injection, XSS, path traversal)
- Race conditions en código concurrente
- Null pointer dereferences no manejados
Ignorar:
- Preferencias de estilo menores (trailing commas, bracket placement)
- Nombres de variables que son legibles aunque no ideales
- Comentarios desactualizados que no contradicen el código
- TODOs sin fecha límite
Esta separación explícita le da a Claude un framework de decisión binario para cada finding.
Few-Shot Prompting
Few-shot es la técnica más efectiva cuando instrucciones detalladas producen output inconsistente. En lugar de describir qué hacer, muestras qué hacer con ejemplos concretos.
Cuándo usar few-shot
- Instrucciones detalladas producen output variable entre invocaciones
- La tarea requiere juicio contextual (no solo pattern matching)
- Necesitas que Claude generalice a casos nuevos similares
- Hay ambigüedad inherente en la selección de herramientas o categorías
Estructura de un few-shot example
Cada ejemplo debe incluir:
- Input: El caso concreto
- Output esperado: La acción o decisión correcta
- Reasoning: Por qué se eligió esa acción (esto es clave para generalización)
Few-shot para tool selection
Cuando Claude debe elegir entre múltiples herramientas disponibles, few-shot examples resuelven la ambigüedad mejor que descripciones largas de cada tool.
Ejemplo 1:
User: "What's the weather in Tokyo?"
Reasoning: User wants current real-time data → use weather_api tool
Action: weather_api(city="Tokyo")
Ejemplo 2:
User: "What's the capital of Japan?"
Reasoning: Static factual knowledge → no tool needed, answer directly
Action: Respond with "Tokyo"Few-shot para reducir alucinaciones en extracción
Cuando se extraen datos de documentos con formatos variados (facturas, reportes, mediciones informales), few-shot examples anclan a Claude en qué datos realmente están presentes vs qué podría inferir.
Sin few-shot, Claude tiende a “completar” campos faltantes con valores plausibles. Con 2-4 examples que muestren campos marcados como null cuando la información no está, Claude aprende a dejar vacío lo que no encuentra.
Crear examples efectivos
Cantidad óptima: 2-4 examples
- 1 example: Insuficiente para establecer un patrón
- 2-4 examples: Punto óptimo entre cobertura y eficiencia de tokens
- 5+ examples: Rendimientos decrecientes, consume contexto valioso
Selección de examples
Los examples deben cubrir:
- El caso típico (baseline de cómo manejar inputs normales)
- El edge case ambiguo (donde la decisión no es obvia)
- El caso de “no hacer nada” (cuándo no actuar o dejar un campo vacío)
Few-shot para branch coverage gaps
Cuando un code review debe identificar paths no testeados, un ejemplo que muestre “este if/else tiene test para true pero no para false → flag missing branch coverage” es más efectivo que una instrucción larga sobre qué constituye cobertura adecuada.
Few-shot vs instrucciones detalladas
| Aspecto | Instrucciones detalladas | Few-shot |
|---|---|---|
| Consistencia | Variable entre invocaciones | Alta reproducibilidad |
| Generalización | Buena si las reglas son claras | Excelente con reasoning |
| Tokens | Menos tokens | Más tokens por example |
| Mantenimiento | Fácil de editar reglas | Requiere curar examples |
| Mejor para | Reglas binarias claras | Juicio contextual |
Para el examen: Few-shot prompting es la respuesta correcta cuando el escenario describe output inconsistente a pesar de instrucciones detalladas, o cuando se necesita manejar ambigüedad en tool selection.
Combinando criterios explícitos con few-shot
La combinación más poderosa es:
- Criterios categóricos para definir el scope (qué reportar/ignorar)
- Few-shot examples para calibrar el juicio dentro del scope
- Reasoning en los examples para que Claude generalice correctamente
Esta combinación reduce falsos positivos manteniendo alta cobertura de issues reales.
Resumen
- Criterios categóricos (“flag X only when Y”) superan a instrucciones vagas (“be conservative”)
- Los falsos positivos destruyen confianza incluso en categorías precisas
- Deshabilitar temporalmente categorías con alto FP es una estrategia válida
- Few-shot (2-4 examples con reasoning) es la técnica más efectiva para output consistente
- Los examples deben incluir el caso típico, el edge case y el caso de “no actuar”
- Combinar criterios explícitos + few-shot examples maximiza precisión
Anterior: Agent Teams y Worktrees · Índice · Siguiente: Structured Output