Validación, Retry y Feedback Loops

Anterior: Structured Output · Índice · Siguiente: Batch Processing

---

Retry con feedback de errores

El patrón más efectivo de retry no es simplemente reintentar — es append los errores de validación específicos al prompt antes de reintentar.

Patrón básico

1. Claude produce output (via tool_use)
2. Validación detecta errores específicos
3. Se crea un follow-up request con: documento original + output fallido + errores de validación
4. Claude corrige basándose en el feedback concreto

Qué incluir en el feedback

Efectivo: Errores específicos con contexto

Validation failed:
- total (1,250.00) does not equal sum of line_items (1,150.00)
- date "2024-13-01" is not a valid date
- vendor_name is empty but document header shows "Acme Corp"

Inefectivo: Mensajes genéricos

Validation failed. Please try again.

El feedback específico le dice a Claude exactamente qué corregir y dónde buscar la información correcta.

---

Cuándo los retries funcionarán vs cuándo no

Esta es una distinción crítica para el examen:

Retries efectivos (format mismatch)

• El dato está en el documento pero Claude lo extrajo mal
• Claude puso el valor en el campo equivocado
• El formato no coincide (fecha en formato incorrecto)
• Claude truncó un valor largo

Retries inefectivos (información ausente)

• El campo no existe en el documento fuente
• El documento está corrupto o ilegible en esa sección
• Se pide un dato que requiere cálculo externo no disponible

Para el examen: Si un escenario describe retries fallidos repetidamente para un campo, la respuesta correcta suele ser “la información no está en el source” — no “agregar más retries” ni “usar un modelo más grande”.

Límites de retry

Establecer un máximo de 2-3 retries. Si después de 3 intentos el error persiste:

• Para campos faltantes: marcar como null con extraction_note: "not found in document"
• Para inconsistencias: escalar a human review
• Para errores de formato: aplicar transformación programática post-extracción

---

Validación semántica

La validación semántica verifica relaciones lógicas que JSON schemas no pueden expresar:

Cross-field validation

• total == sum(line_items) — consistencia aritmética
• end_date >= start_date — orden temporal
• quantity * unit_price == line_total — cálculos por línea
• shipping_address.country matches currency — consistencia geográfica

Self-correction con campos de validación

Un patrón poderoso es incluir campos de auto-verificación en el schema:

{
  "calculated_total": { "type": "number" },
  "stated_total": { "type": ["number", "null"] },
  "totals_match": { "type": "boolean" },
  "conflict_note": { "type": ["string", "null"] }
}

Claude calcula la suma de line items (calculated_total), extrae el total declarado (stated_total), y reporta si coinciden. Esto hace que Claude verifique su propia extracción como parte del proceso.

Validación vs errores de sintaxis

Tipo	Eliminado por schema	Requiere validación
JSON mal formado	Sí	—
Campo faltante	Sí	—
Tipo incorrecto	Sí	—
Valor en campo equivocado	No	Sí
Suma inconsistente	No	Sí
Dato inventado	No	Sí

---

Feedback loops para mejora continua

detected_pattern field

Agregar un campo en el output de revisión para que Claude reporte patrones de dismissal:

{
  "finding": "...",
  "category": "comment_accuracy",
  "detected_pattern": "stale_comment_non_contradicting"
}

Cuando developers dismissan findings, el campo detected_pattern permite analizar qué tipo de findings se rechazan consistentemente. Si el 80% de dismissals en una categoría tienen el mismo pattern, ese pattern debería convertirse en una regla de exclusión.

Loop de refinamiento

1. Producción: Claude genera findings con detected_pattern
2. Análisis: Agregar dismissal data por pattern
3. Refinamiento: Convertir patterns de alto dismissal en reglas de exclusión
4. Deploy: Actualizar criterios en el prompt
5. Monitorear: Verificar que el recall no bajó (no se perdieron bugs reales)

---

Follow-up requests estructurados

Para retries efectivos, el follow-up request debe contener:

1. Documento original (completo, no resumido)
2. Output fallido (para que Claude vea qué hizo mal)
3. Errores de validación (específicos y accionables)
4. Instrucción de corrección: “Correct only the flagged fields, keep valid extractions unchanged”

La instrucción de corrección parcial es importante — sin ella, Claude podría re-extraer todo y potencialmente romper campos que estaban correctos.

---

Patrones de validación por pipeline stage

Pre-extraction

• Verificar que el documento no está vacío
• Detectar idioma si es relevante
• Estimar si el documento es del tipo esperado

Post-extraction (single document)

• Cross-field validation (sumas, fechas, consistencia)
• Format validation (regex para IDs, fechas, phones)
• Completeness check (campos required que no deberían ser null)

Post-batch (múltiples documentos)

• Outlier detection (un monto 100x mayor que el promedio)
• Duplicate detection (mismo invoice number en dos documentos)
• Cross-document consistency (vendor names normalizados)

---

Resumen

• Retry con error feedback específico es mucho más efectivo que retry ciego
• Los retries funcionan para format mismatch, no para información ausente
• Limitar a 2-3 retries; después escalar o marcar como null
• Self-correction fields (calculated vs stated) hacen que Claude verifique su trabajo
• Feedback loops con detected_pattern permiten mejora continua de criterios
• Follow-up requests deben incluir documento + output fallido + errores específicos

---

Anterior: Structured Output · Índice · Siguiente: Batch Processing