Siempre Listo Escuela
← Volver al listado de tecnologías ← Índice de Claude Certified Architect

Validación, Retry y Feedback Loops

Por: Artiko
claudecertificacionvalidacionretryfeedback-loop

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

TipoEliminado por schemaRequiere validación
JSON mal formadoSí—
Campo faltanteSí—
Tipo incorrectoSí—
Valor en campo equivocadoNoSí
Suma inconsistenteNoSí
Dato inventadoNoSí

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

← Volver al listado de tecnologías ← Índice de Claude Certified Architect