Batch Processing y Multi-Pass Review
Batch Processing y Multi-Pass Review
Anterior: Validación y Retry · Índice · Siguiente: Gestión de Contexto
Message Batches API
La Batches API permite enviar múltiples requests en un solo batch con 50% de ahorro en costos a cambio de mayor latency.
Características clave
| Aspecto | Detalle |
|---|---|
| Ahorro | 50% sobre precio estándar |
| Ventana | 24 horas para completar el batch |
| SLA de latency | Ninguno — puede tomar minutos u horas |
| Límite de requests | Hasta 100,000 por batch |
| Multi-turn | No soporta tool calling multi-turn en un solo request |
custom_id para correlación
Cada request en un batch lleva un custom_id que se retorna en la respuesta, permitiendo correlacionar request/response pairs:
{
"custom_id": "invoice-2024-0742",
"params": {
"model": "claude-sonnet-4-20250514",
"messages": [{ "role": "user", "content": "..." }]
}
}
El response incluirá "custom_id": "invoice-2024-0742" para saber qué invoice generó qué resultado.
Cuándo usar batch vs real-time
Batch apropiado
- Overnight reports: Análisis de código nocturno sobre todo el repo
- Weekly audits: Revisión semanal de compliance/security
- Nightly test generation: Generar tests para código nuevo del día
- Document processing backlog: Procesar lote de facturas acumuladas
- Training data generation: Crear datasets sintéticos
Batch NO apropiado
- Pre-merge checks: Developers esperan feedback en minutos, no horas
- Chat/conversación: Requiere respuesta inmediata
- Real-time extraction: Cuando el usuario espera resultados
- Tool calling multi-turn: Batch no soporta loops agentic
Para el examen: Si un escenario pregunta por reducir costos de un proceso nocturno o semanal, batch es la respuesta. Si pregunta por pre-merge reviews, batch es la respuesta incorrecta.
Optimización de batch submissions
Prompt refinement antes del batch
Antes de lanzar un batch de 10,000 documentos:
- Seleccionar sample set (~50-100 documentos representativos)
- Iterar el prompt sobre el sample set en real-time
- Medir accuracy en el sample
- Ajustar criterios, few-shot examples, schema
- Lanzar batch solo cuando el sample alcance accuracy target
Lanzar un batch sin probar el prompt primero desperdicia el 50% de ahorro si hay que re-procesar todo.
Calcular frequency según SLA
Si SLA = "resultados antes de las 9am":
→ Submit batch a las 9pm (12h de margen)
→ Ventana de 24h del batch: suficiente
Si SLA = "resultados en 2 horas":
→ Batch no es apropiado (sin SLA de latency)
→ Usar real-time API
Limitaciones de self-review
Por qué self-review es débil
Cuando le pides a Claude que revise su propio output en la misma conversación, el modelo retiene el reasoning context de su decisión original. Esto lo hace menos likely a cuestionar sus propias decisiones.
Es similar al sesgo de confirmación en humanos: ya “sabe” por qué tomó cada decisión y tiende a justificarlas en lugar de evaluarlas críticamente.
Independent review es más efectivo
Una instancia de revisión sin el reasoning context previo es más objetiva:
| Approach | Sesgo | Efectividad |
|---|---|---|
| Self-review (misma conversación) | Alto — retiene reasoning | Baja |
| Independent review (nueva instancia) | Bajo — evalúa sin contexto previo | Alta |
| Multi-pass (instancias separadas) | Bajo por instancia | Más alta |
Para el examen: Cuando el escenario describe que un agente no detecta sus propios errores, la solución es usar una instancia independiente para review, no “pedir que revise más cuidadosamente”.
Multi-Pass Review
El patrón multi-pass divide la revisión en passes especializados con instancias independientes:
Pass 1: Análisis local (per-file)
- Cada archivo revisado independientemente
- Focus: bugs, security, correctness dentro del archivo
- Paralelizable: todos los archivos pueden revisarse simultáneamente
- Output: lista de findings por archivo con confidence score
Pass 2: Análisis de integración (cross-file)
- Recibe los findings del Pass 1 + estructura del proyecto
- Focus: inconsistencias entre archivos, breaking changes, API contracts
- Identifica: imports rotos, type mismatches entre módulos, missing error handling en boundaries
Pass 3: Verificación con confidence
- Revisa findings de passes anteriores
- Cada finding recibe un confidence self-report
- Filtra findings de baja confianza
- Agrupa findings relacionados
Cuándo usar multi-pass
- Code reviews complejos (10+ archivos modificados)
- Auditorías de seguridad (local vulnerabilities + attack chains)
- Document extraction (extract + validate + enrich)
- NO para: tareas simples donde un solo pass es suficiente
Verification passes con confidence
Pedir a Claude que reporte su confidence por finding mejora la señal:
{
"finding": "Potential SQL injection in user_query param",
"category": "security",
"confidence": "high",
"evidence": "User input concatenated directly into SQL string at line 42",
"false_positive_risk": "low"
}
Campos útiles para filtrado:
- confidence: high/medium/low — filtra low en producción
- evidence: texto específico que soporta el finding
- false_positive_risk: estimación de riesgo de falso positivo
Los findings con confidence: "high" + false_positive_risk: "low" van directo al developer. Los de confidence: "medium" pueden pasar por un segundo review pass.
Batch + Multi-Pass combinados
Para auditorías nocturnas de gran escala:
- Batch Pass 1: Análisis local de cada archivo (batch, paralelizado)
- Agregación: Recopilar findings programáticamente
- Batch Pass 2: Análisis cross-file por módulo (batch)
- Filtering: Aplicar threshold de confidence programáticamente
- Report: Generar reporte consolidado para el equipo
Cada pass es un batch separado. El ahorro de 50% aplica a cada batch.
Resumen
- Batches API: 50% ahorro, 24h ventana, sin SLA de latency
- Batch para procesos nocturnos/semanales; NO para pre-merge checks
- custom_id correlaciona requests y responses en batch
- Batch no soporta multi-turn tool calling
- Self-review en misma conversación es débil (sesgo de reasoning context)
- Independent review instances son más efectivas
- Multi-pass: local analysis + cross-file integration + verification
- Probar prompt en sample set antes de batch masivo
Anterior: Validación y Retry · Índice · Siguiente: Gestión de Contexto