Evals: cambia tus flujos de trabajo documentales sin miedo
Cada flujo de trabajo de anyformat tiene ahora una pestaña Health: construye un dataset con respuestas verificadas, puntúa cualquier versión del flujo contra él y ve exactamente qué ha mejorado y qué se ha roto, antes de que lo descubra producción.
Parsear un documento es una demo. Mantener un flujo de extracción correcto en producción, mes tras mes, mientras todo lo que lo rodea cambia, es ingeniería.
Esta es la situación con la que se topa cualquier equipo. Tu flujo de facturas está en producción. Entonces aparece un proveedor nuevo con un formato que nadie había previsto. Producto pide dos campos más. Reescribes una instrucción para arreglar un documento rebelde. Cada cambio es una apuesta: ¿ha subido la precisión, o acabas de romper un caso que antes funcionaba? Si no puedes responder a eso, lo racional es no tocar nunca un flujo que funciona casi siempre. Así es como se pudren los pipelines documentales.
La mayoría de los productos de document AI se quedan en el «mira lo que hemos extraído». Nosotros creemos que lo difícil empieza justo después, así que hemos construido Evals: una superficie completa de evaluación dentro de cada flujo que convierte los cambios de apuestas en mediciones. Funciona como funcionan los tests en el código: fijas las entradas, fijas las salidas esperadas, puntúas cada versión contra ellas y comparas.
Vive en la nueva pestaña Health de cada flujo de Extract y Classify, junto a Results y Studio. Tres subpestañas: Overview, Datasets y Evaluations. (Si te fijas, en las capturas se ve una cuarta. Hablamos de ella al final.)

Empieza por documentos en los que ya confías
Una evaluación es tan honesta como sus datos de referencia, así que el dataset va primero. Cada flujo tiene el suyo, y lo rellenas de la forma que mejor encaje con dónde viven tus datos etiquetados:
- Promociona desde producción. Coge un documento que el flujo ya haya procesado, verifica cada dato en la interfaz de revisión y pulsa Add to dataset. Los valores que acabas de confirmar se convierten en la verdad de referencia (ground truth) de ese archivo: las respuestas esperadas contra las que se puntuarán las próximas ejecuciones.
- Sube datos etiquetados. ¿Ya tienes un conjunto etiquetado? Suelta los documentos junto con un archivo
.jsoncon el nombre de cada uno (invoice.pdfse empareja coninvoice.json) y los valores esperados se importan directamente. Un paso de revisión marca duplicados, JSON inválido y archivos de verdad de referencia huérfanos antes de subir nada. En este punto la verdad de referencia es opcional: puedes añadir solo los documentos y rellenar las respuestas más tarde, directamente en la tabla del dataset.
Aquí importan dos propiedades. La primera, el dataset está totalmente desacoplado de producción: añadir un archivo lo duplica, así que nada de lo que hagas en Evals toca los datos de producción, y las ejecuciones de producción nunca te mueven el benchmark bajo los pies. La segunda, la verdad de referencia es editable en el sitio: una tabla tipo hoja de cálculo, una columna por campo, doble clic para corregir un valor, tablas anidadas para listas y objetos. Los datos de referencia que no se pueden mantener se quedan obsoletos; estos están construidos para mantenerse.

Un único número de precisión nunca cuenta toda la historia
Un número global esconde justo lo que necesitas saber: dónde sufre el flujo. Por eso los datasets soportan sub-datasets: etiqueta los archivos por la distinción que te importe (proveedor, tipo de documento, una etiqueta de «casos difíciles» para los escaneos que lo rompen todo) y lee la precisión por segmento además de la global.
Esta es la diferencia entre «el flujo está al 98%» y «98% global, pero 95% en los escaneos difíciles, y hace dos versiones ahí estaba al 68%». El primer número sienta bien. El segundo te dice qué arreglar, y te permite acotar la siguiente evaluación a solo ese segmento mientras lo trabajas.

Evaluaciones: numeradas, fijadas, inmutables
Cuando quieres una medición, lanzas una evaluación: eliges un alcance (el dataset completo o un único sub-dataset) y una versión del flujo, y anyformat vuelve a extraer cada documento del alcance y puntúa cada campo contra su verdad de referencia.

Cada ejecución cae en un historial numerado: #1, #2, #3, cada una fijada a su versión, alcance, fecha y precisión. Y cada ejecución es inmutable. Editar la verdad de referencia o refinar el flujo nunca reescribe una evaluación pasada; lanzas una nueva para medir el efecto. Esa regla es lo que convierte la diferencia entre dos ejecuciones en señal real y no en ruido, y es lo que hace que la lista de ejecuciones se lea como el historial de CI de tu flujo: línea base, cambio, nueva ejecución, comparación.

Una nota honesta: una evaluación lanza extracciones reales, una por documento del alcance, y consume créditos en consecuencia. Es otra razón por la que existe el alcance por sub-dataset: itera barato sobre el segmento que estás arreglando y lanza el dataset completo cuando estés listo para dar el visto bueno.
Depura el número, no te limites a leerlo
Un porcentaje de precisión te dice si debes preocuparte. La página de detalle de la evaluación te dice por qué. Abre cualquier ejecución y tienes los números de cabecera (la precisión con su delta frente a la ejecución anterior, documentos aprobados, campos puntuados) y dos desgloses:
- Por archivo: qué documentos arrastran el número hacia abajo, y qué campos han fallado en cada uno.
- Por campo: qué campos fallan de forma consistente entre documentos. Un campo que falla en todas partes es un problema de instrucción; un campo que falla en un solo segmento es un problema de documento.
Desde un archivo que falla entras directo a una comparación lado a lado de resultado frente a esperado, que muestra solo los valores que difieren. Sin exportar JSON, sin comparar dos blobs a ojo en una herramienta de diff. Ves exactamente qué ha dicho el flujo y exactamente qué debería haber dicho, y entonces vas, afinas la definición del campo, guardas una versión nueva y lanzas la siguiente evaluación.

Eso es una sesión de depuración real en una sola pantalla: la factura escaneada leyó la empresa destinataria como el proveedor, interpretó las fechas día-mes al estilo americano y truncó el número de factura. Cada uno de esos fallos se convirtió en una instrucción de campo más afinada en la versión siguiente.

Después, vigila producción contra tu benchmark
Evals sería media funcionalidad si los números se quedaran en un laboratorio. El Overview de Health pone tu benchmark del dataset junto a las métricas de producción en vivo para la misma versión: precisión en producción (a partir de la verificación humana), confianza, through rate (la proporción de extracciones totalmente revisadas y aceptadas sin una sola edición) y la brecha de precisión: benchmark menos producción.

Esos números hacen trabajos distintos. La confianza te dice dónde mirar primero. La precisión en producción te dice con qué frecuencia acierta el flujo con el tráfico real. El benchmark te dice de qué es capaz la versión con documentos que has verificado de principio a fin. Cuando producción y benchmark divergen, ya no es un misterio, es una señal: tus documentos reales se han alejado de tu dataset, y probablemente toca promocionar unos cuantos recientes y volver a evaluar.
El control es la funcionalidad
A los proveedores de extracción documental les encanta la demo del antes y el después: PDF caótico dentro, JSON limpio fuera. Bien, a nosotros también nos encanta. Pero una demo es un único punto en el tiempo, y tu flujo no lo es: cambiará veinte veces en su primer año, porque tus documentos cambiarán, tu esquema cambiará y los modelos de debajo cambiarán.
Evals es lo que hace segura esa evolución. Un dataset fijo que producción no puede mover. Una verdad de referencia que puedes mantener. Una puntuación reproducible. Un historial inmutable. Segmentos que anclan la precisión a los documentos que de verdad son difíciles, no a una media halagadora. Eso es lo que hace falta para operar procesamiento documental en producción sin miedo, y se entrega con cada flujo, en la pestaña Health, hoy.
Construye un dataset, lanza la evaluación #1 y haz tu próximo cambio de flujo sabiendo exactamente qué ha hecho.
Y el dataset que construyas aquí está a punto de empezar a trabajar más duro por ti: Optimizer llega pronto. Permitirá que un flujo se optimice a sí mismo contra su propio dataset, usando tus evaluaciones como objetivo. Pronto contaremos más.
Docs: Datasets y evaluaciones · Construir un dataset · Lanzar evaluaciones

