Construir una muestra representativa y una línea base

Una demostración con documentos elegidos a mano puede confirmar que el pipeline funciona en sus mejores condiciones y, a la vez, ocultar que falla en el trabajo real. Fotografías inclinadas, proveedores nuevos, tablas largas, anexos inesperados y campos ausentes suelen aparecer después de la demo, no antes.

Por eso la muestra no es un trámite de preparación. Es el instrumento que permite decidir si una mejora es real, detectar qué segmentos fallan y comparar versiones sin cambiar la regla de evaluación a mitad del proyecto.

Define primero el universo que quieres representar

Describe de dónde provienen los documentos y qué periodo cubren. Si el alcance son facturas recibidas por correo durante los últimos seis meses, no mezcles silenciosamente contratos, escaneos históricos o documentos generados por otro canal.

Segmenta por variables que puedan cambiar el resultado:

• clase documental;
• emisor o familia de plantilla;
• canal de entrada;
• texto digital, escaneo o fotografía;
• calidad visual;
• idioma;
• número de páginas;
• presencia de tablas, sellos o manuscrito;
• periodo;
• caso habitual, límite o excepción;
• nivel de impacto si un campo se interpreta mal.

El NIST AI RMF recomienda que las mediciones de exactitud se acompañen de conjuntos de prueba claramente definidos y realistas, representativos de las condiciones esperadas de uso. No convierte eso en una cifra universal de tamaño: la representatividad depende del caso y de su variabilidad.

Evita el muestreo cómodo

Una muestra formada por «los documentos que teníamos a mano» tiende a favorecer plantillas conocidas, entradas limpias y casos exitosos. Documenta cómo seleccionas los ejemplos y fuerza la presencia de los segmentos que sabes que son difíciles.

Incluye frecuencia e impacto. Un caso raro puede merecer presencia deliberada si su error sería crítico. Esto no significa manipular la distribución para reportar una media peor o mejor, sino crear vistas separadas: comportamiento global y comportamiento en grupos de riesgo.

Construye una referencia verificable

Para cada documento registra la verdad esperada que vas a utilizar para evaluar. Según el pipeline puede incluir:

• clase correcta;
• límites entre documentos dentro de un paquete;
• páginas relevantes;
• campos esperados;
• valor observado en el documento;
• valor normalizado;
• coordenada o fragmento que sirve de evidencia;
• validaciones que deberían pasar o fallar;
• ruta operativa final.

Cuando una etiqueta sea ambigua, no la resuelvas individualmente sin dejar criterio. Añade una guía de anotación. Si dos revisores competentes no pueden ponerse de acuerdo sobre qué valor es correcto, el problema no se arregla con un modelo más potente: necesitas definir la regla de negocio o aceptar que existe ambigüedad.

Separa desarrollo de evaluación

Como mínimo, distingue documentos utilizados para diseñar o corregir del conjunto que utilizarás para medir una versión candidata. En proyectos que justifican más rigor, reserva además una prueba final que no se use para ajustar umbrales o seleccionar proveedor.

Evita fugas entre conjuntos. Páginas del mismo expediente o plantillas prácticamente idénticas pueden hacer que el resultado parezca generalizar cuando solo reconoce patrones repetidos. Documenta las reglas de separación y conserva las versiones de cada conjunto.

Si incorporas después una plantilla nueva, crea una nueva versión del benchmark. No sobrescribas la anterior: necesitas poder comparar cómo se comportaba el sistema antes y después del cambio.

Mide la línea base manual completa

La automatización solo puede valorarse contra el trabajo que sustituye o modifica. Registra el proceso manual actual por etapa:

• tiempo activo de lectura y captura;
• tiempo de espera;
• porcentaje que requiere corrección;
• errores descubiertos posteriormente;
• búsquedas en sistemas externos;
• retrabajo;
• documentos abandonados o incompletos;
• coste y capacidad de la revisión;
• consecuencias de errores críticos.

Separa captura, validación, búsqueda, escritura y archivo. Una solución puede ahorrar entrada manual y crear una cola de revisión que consume el mismo tiempo en otro punto. La línea base debe permitir detectar ese desplazamiento.

Protege documentos y minimiza exposición

Trabaja solo con documentos cuyo uso esté autorizado para el propósito de evaluación. Limita accesos y conserva únicamente lo necesario. Cuando sea posible, utiliza documentos sintéticos para probar estructura o errores de formato y reserva los reales para comprobar variabilidad y calidad.

No asumas que sustituir el nombre por CLIENTE_01 anonimiza todo el documento. Fechas, direcciones, importes, identificadores y combinaciones singulares pueden seguir revelando información. La protección concreta dependerá de los datos y del entorno, por lo que debe revisarse como requisito del proyecto y no como una limpieza cosmética.

Crea etiquetas de dificultad y riesgo

Marca los ejemplos por dificultad visual y por impacto operativo. Esto permite detectar que una media global oculta un problema grave.

Por ejemplo, el sistema puede extraer correctamente el 98 % de campos porque los textos descriptivos son fáciles, mientras falla con mayor frecuencia en el total de factura. La evaluación por campo crítico y segmento ofrece una lectura mucho más útil que una única tasa agregada.

No uses la «confidence» del proveedor como verdad de referencia. Es una señal producida por el sistema y debe compararse con errores observados en tu propia muestra.

Ejercicio: crea el primer benchmark

Entrega:

1. descripción del universo;
2. criterios de inclusión y exclusión;
3. estrategia de muestreo;
4. inventario de ejemplos;
5. guía de etiquetado;
6. referencia esperada por documento;
7. separación desarrollo/evaluación/prueba, si aplica;
8. línea base manual;
9. segmentos de dificultad y riesgo;
10. limitaciones de cobertura;
11. versión y fecha del conjunto;
12. política de acceso y conservación.

Decisión resultante

No necesitas demostrar que tu conjunto es «perfectamente representativo» de todo el futuro. Necesitas saber qué cubre, qué no cubre y utilizarlo de forma consistente. A partir de esta referencia podrás comprobar si OCR, clasificación, extracción y revisión mejoran de verdad el proceso o solo producen una demo convincente.