Automatización documental: por qué necesitas métricas de verdad (y cómo obtenerlas)

«Acierta casi siempre», «he cambiado el prompt y ahora lo saca casi todo» o «el equipo dice que ahora va muy bien» no son métricas válidas cuando hablamos de automatización documental.

Se necesitan métricas de verdad, y cuando las tienes todo cambia porque el camino pasa de ser una lotería a ser predecible: pasas del «acierta casi siempre» a saber que la fecha del señalamiento la sacas el 98 % de las veces y que fallan las de un Juzgado concreto que pone el día en números romanos, o que el hito X lo aciertas un 90 % y, cuando lo falla, un 80 % de las veces lo confunde con el hito Y.

Cómo conseguir las métricas: dos caminos

Hay un camino ideal y otro no tan ideal. Los dos son mejores que no tener métricas:

1. Recuperar parte de tu histórico documental con su extracción o interpretación ya validada. Tienes un set de documentos con su resultado correcto, los procesas con tu estrategia y comparas lo que te da la IA con lo que debería haber sido.
2. Si no lo tienes o no puedes recuperarlo, revisas los resultados a mano y obtienes la estadística así. Si ese va a ser el camino, te conviene tener un método de revisión ágil y un sistema que te permita guardar ese resultado, para que en las siguientes pruebas no tengas que volver a validar a mano.

Pero, por narices, tienes que tener un dataset con el resultado auditado. Si no tienes eso, nunca saldrás del «parece que ahora va mucho mejor».

No hagas trampas: separa entrenamiento y prueba

Y si entrenas el modelo, no hagas las pruebas con los mismos documentos con los que lo has entrenado. Eso es trampa, y si sigues el camino científico se trata precisamente de no hacerlo: dentro del set, una parte para entrenamiento y otra, distinta, para las pruebas.

El motivo es simple: si mides sobre lo que el modelo ya ha visto vas a acertar siempre, pero en producción no verás los mismos documentos, verás otros del mismo tipo, que no es lo mismo. Si te interesa el detalle de cuándo entrenar y cómo, lo desarrollamos en ¿Cuándo conviene entrenar un modelo de IA?.

Qué medir: hay más de lo que parece

Lo primero, las pruebas deben contemplar el mismo circuito que pondrás en producción. Se supone que tienes salvaguardas que destapan los resultados dudosos, o quizás un RAG, o una secuencia de prompts anidados, o lo que sea. Si mides el modelo suelto pero luego en producción lo rodeas de controles, no estás midiendo lo que vas a desplegar.

Y antes de seguir, conviene poner nombre a lo que estás midiendo, porque son cosas distintas y hay mucha confusión:

Acierto (o exactitud)

De todos los documentos o campos que evalúas, el porcentaje en que el sistema dio el resultado correcto. Es el número más intuitivo, pero por sí solo engaña, porque no distingue en qué falla.

Precisión

De todas las veces que el sistema dijo «esto es el hito X», ¿cuántas lo eran de verdad? La precisión baja cuando hay falsos positivos: marcar algo que no era. En notificaciones procesales son muy habituales: haces una prueba sobre el hito X y tienes un 100 %, sacas pecho, haces la prueba sobre el hito Y y resulta que el 50 % también te lo ha dado como X. Ups.

Exhaustividad (recall)

De todos los hitos X que había realmente en tus documentos, ¿cuántos detectó? La exhaustividad baja cuando hay falsos negativos: lo que se le escapa. Un sistema puede tener mucha precisión y poca exhaustividad, o al revés, y según tu proceso te dolerá más una cosa u otra.

Matriz de confusión

Es la tabla que cruza «lo que el documento era de verdad» con «lo que el sistema dijo que era». El ejemplo de arriba —el hito X que, cuando falla, en un 80 % lo confunde con el hito Y— es exactamente eso: una matriz de confusión, y es lo que te dice a dónde van los errores.

Pero es que además el proceso puede fallar en distintas etapas. Quizás la IA se equivoca por culpa de cómo le das el texto: porque cuando viene en una tabla pierde la relación entre sus elementos, o cuando es una imagen pegada a un PDF no envía texto. Así que hay que tener métricas por cada etapa, y contar con los falsos positivos.

Ensayo y error, pero con método

Una vez detectados los fallos, es un proceso de ensayo-error: nada dramático, utilizas las estadísticas y tu experiencia para intentar acelerarlo, pero básicamente, si no lo consigues a la primera, lo consigues a la tercera. Cambias la secuencia de prompts y repites la prueba, metes un proceso para que cuando el formato venga en una tabla depure el texto y listo, pones un traductor de números romanos y cazado ese 2 % que nos mataba…

¿Cuándo puedes desplegar en automático?

¿Ya estás en resultados? Si ese dataset es representativo de tu producción real, adelante. Y cuando en producción hayas visto tropecientosmil documentos y nunca se equivoque, o puedas convivir con los errores que existan (si has hecho bien lo anterior deberían ser mínimos), puedes desplegarlo en automático y pasar a revisar una cata diaria, en lugar de validar cada documento a mano.

En Cómo Entrenar mi Robot hemos hecho una plataforma que permite gestionar todo este proceso: preparar los dataset de entrenamiento y etiquetarlos, montar RAGs o archivos de fine-tuning, JSON de instrucciones por documento, estrategias de prompts anidados, visores para auditar los resultados en instantes, cambiar de modelo de IA con un clic, obtener el texto con una librería u otra en función del formato, lanzar lotes de prueba y obtener las estadísticas en tiempo real, y un largo etcétera que es el motivo por el que somos capaces de entrenar un modelo en muy poco tiempo y podemos comprometernos a SLAs de calidad muy altos.