CCAR-F · Gestión de contexto
Revisión humana y confianza calibrada
Un sistema extrae datos de formularios con 97% de precisión. El equipo propone dejar de revisar todo lo que el modelo marca con confianza alta. Suena razonable, pero ese 97% puede esconder un tipo de documento que anda en 70% o un campo crítico que falla una de cada diez veces.
El promedio esconde segmentos
La precisión global (aggregate accuracy) mezcla todo. Si el 90% de los documentos son facturas simples, pueden tapar a las declaraciones de aduana que salen mal. Antes de reducir la revisión humana:
- medí la precisión por tipo de documento y por campo;
- automatizá solo los segmentos que ya son confiables.
Ejemplo: formularios de admisión con 98,5% global, pero el código de diagnóstico acierta 89%. Se automatizan los cuatro campos confiables y el código de diagnóstico sigue con revisión humana por ahora.
Seguir midiendo lo que se automatizó
Una vez que el grupo de confianza alta pasa sin revisión, ¿cómo sabés si empezó a fallar? Con una muestra de ese mismo grupo. Revisar solo lo dudoso nunca mide los errores que la automatización deja pasar con seguridad, que son justo los que importan.
El muestreo aleatorio estratificado (stratified random sampling) toma la muestra al azar dentro de cada tipo de documento. Con un muestreo uniforme del 1%, un tipo de documento poco frecuente casi no aparece, y un cambio en su formato pasa desapercibido. Estratificando, cada segmento recibe suficientes revisiones con el mismo presupuesto, y además se detectan patrones de error nuevos.
Si un proveedor cambia el formato de sus facturas y la precisión de ese tipo cae, pausá la automatización de ese tipo, medí con una muestra etiquetada del formato nuevo y recién ahí decidí.
Confianza por campo, calibrada
El modelo puede devolver una confianza por campo (field-level confidence) junto con cada valor. Pero un número no sirve hasta que lo comparás con la verdad. La calibración (calibration) se comprueba contra un conjunto de validación etiquetado (labelled validation set): documentos con los valores correctos verificados por personas. Si está calibrada, de los campos marcados con 0,9, alrededor del 90% están bien.
Los puntajes no significan lo mismo en todos los campos. Por ejemplo, en formularios bancarios, un IBAN con 0,90 puede acertar el 71% de las veces y un email con 0,70 el 98%. Por eso los umbrales se fijan por campo, con el conjunto etiquetado y según el costo del error: el IBAN necesita un umbral mucho más exigente.
Que dos corridas den el mismo valor mide consistencia, no precisión: el modelo puede equivocarse igual dos veces.
A quién le toca la revisión
Con poca capacidad de revisión (cuatro personas para 600 de 2.000 declaraciones diarias), revisar en orden de llegada desperdicia el tiempo. Priorizá:
- campos con confianza baja en la escala calibrada;
- documentos ambiguos o que se contradicen (dos pesos brutos distintos en dos páginas).
Y el aviso al revisor tiene que permitir decidir rápido: el campo, el valor extraído, el pasaje de origen y el motivo del aviso.
Las trampas típicas
- Automatizar por la precisión global.
- Muestrear solo lo de confianza baja.
- Un muestreo uniforme que ignora los tipos de documento raros.
- Un umbral único para todos los campos, o confiar en puntajes que nunca se compararon con datos etiquetados.
En el examen
Si el escenario da un porcentaje global alto y propone sacar la revisión, la respuesta pide medir por tipo y por campo. Si pregunta cómo seguir controlando, muestreo estratificado incluyendo la confianza alta. Si pregunta si los puntajes sirven, compararlos con un conjunto etiquetado.
Pregunta rápida
Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.
A legal research platform has a coordinator agent that sends search subagents to several case-law databases. When a query fails, the subagent returns a plain string: 'Error: search failed'. Nothing else is included.
The failures have different causes. Some are timeouts on a busy database that succeed if repeated a minute later; some are queries the database rejects because it does not support their syntax; and some are databases the platform has no licence for in a given jurisdiction. Because every failure looks identical, the coordinator cannot tell whether a retry is worth it or whether another source should be tried, so at the moment it simply gives up on the source every time.
The platform team has recently added two new jurisdictions and is planning to add a third.
Which change best fixes this?