Batch Processing y Multi-Pass Review

Por: Artiko
claudecertificacionbatchmulti-passreview

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

AspectoDetalle
Ahorro50% sobre precio estándar
Ventana24 horas para completar el batch
SLA de latencyNinguno — puede tomar minutos u horas
Límite de requestsHasta 100,000 por batch
Multi-turnNo 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

Batch NO apropiado

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:

  1. Seleccionar sample set (~50-100 documentos representativos)
  2. Iterar el prompt sobre el sample set en real-time
  3. Medir accuracy en el sample
  4. Ajustar criterios, few-shot examples, schema
  5. 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:

ApproachSesgoEfectividad
Self-review (misma conversación)Alto — retiene reasoningBaja
Independent review (nueva instancia)Bajo — evalúa sin contexto previoAlta
Multi-pass (instancias separadas)Bajo por instanciaMá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)

Pass 2: Análisis de integración (cross-file)

Pass 3: Verificación con confidence

Cuándo usar multi-pass


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:

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:

  1. Batch Pass 1: Análisis local de cada archivo (batch, paralelizado)
  2. Agregación: Recopilar findings programáticamente
  3. Batch Pass 2: Análisis cross-file por módulo (batch)
  4. Filtering: Aplicar threshold de confidence programáticamente
  5. Report: Generar reporte consolidado para el equipo

Cada pass es un batch separado. El ahorro de 50% aplica a cada batch.


Resumen


Anterior: Validación y Retry · Índice · Siguiente: Gestión de Contexto