Como automatizar a lectura e clasificación de documentos con IA

Ler, clasificar e extraer son tarefas diferentes

O OCR recoñece caracteres nunha imaxe. A clasificación propón que tipo de documento temos. A extracción identifica valores como número, data ou total. A validación comproba que eses valores cumpren regras e concordan co contexto. Acertar nunha fase non garante acertar nas seguintes.

Un PDF dixital pode ofrecer texto sen OCR, pero tamén pode ter unha orde de lectura problemática. Unha factura electrónica estruturada pode permitir unha integración máis directa. Non ten sentido converter en imaxe un dato estruturado fiable para volver interpretalo cun modelo.

Un fluxo completo: do correo á cola de revisión

A recepción debe limitar formatos e tamaños e aplicar os controis de seguridade do contorno. Un documento non fiable non debe executar código polo feito de entrar nunha cola. A mensaxe e o adxunto necesitan identificadores que permitan localizar a orixe sen copiar datos innecesarios por todos os sistemas.

A detección de duplicados combina evidencias. Un hash detecta ficheiros idénticos; a clave provedor, número e exercicio pode detectar unha factura reenviada cun nome ou formato diferente. Os criterios concretos dependen do proceso e deben permitir revisión para non bloquear documentos lexítimos.

Definir a saída antes de escoller o modelo

O ERP necesita un contrato de datos: campos, tipos, obrigatoriedade e estados posibles. Un JSON ben formado só comproba a estrutura, non a veracidade. Un valor ausente debe representarse de forma explícita e non substituírse por cero ou pola data actual.

{
  "documento": "exemplo-001",
  "tipo": "factura",
  "numero": null,
  "total": null,
  "estado": "pendente_revision",
  "motivos": ["numero_non_localizado"]
}

A procedencia de cada campo pode incluír páxina, rexión ou fragmento. A interface de revisión debería mostrar esa evidencia xunto ao valor proposto. Deste xeito, a persoa non ten que volver buscar todos os datos desde o principio.

Na integración, unha operación debe ter un identificador estable e unha resposta verificable. Se o ERP tarda e a conexión se corta, antes de repetir a creación hai que comprobar se o borrador xa existe. Un reintento sen ese control pode duplicar rexistros.

Regras de negocio e confianza do modelo

As validacións deben comprobar formatos, obrigatoriedade, sumas, moeda, duplicidade e correspondencia cos datos mestres. Un cambio de conta bancaria ou un provedor descoñecido pode necesitar unha revisión específica, aínda que a lectura teña unha puntuación de confianza alta.

Os sistemas documentais poden devolver puntuacións de confianza, como explica Microsoft na súa documentación. Non se deben interpretar como unha garantía universal nin comparar sen máis entre modelos e campos. O limiar útil depende dos erros observados e das consecuencias da acción.

Para facturas, os cálculos deben realizalos funcións deterministas. O modelo pode propoñer que texto corresponde á base ou ao imposto; unha regra calcula e compara. As diferenzas por arredondamento deben tratarse segundo as regras acordadas, sen corrixir importes silenciosamente.

Deseñar a revisión como parte do produto

Unha cola útil agrupa casos por motivo: campo ausente, provedor ambiguo, duplicado posible ou fallo de integración. A persoa revisora debe poder corrixir, rexeitar ou devolver á entrada, e coñecer o efecto de cada acción. Non todos os erros se resolven editando un campo.

Os cambios deben deixar un historial proporcionado. A corrección dunha persoa non debe utilizarse automaticamente para adestrar un modelo: antes hai que definir finalidade, permisos, calidade e condicións dese uso. Si pode servir para detectar patróns recorrentes que orienten unha mellora das regras.

Tamén hai que coñecer a capacidade de revisión. Se a cola medra máis rápido do que o equipo pode atendela, o proceso pode empeorar aínda que a lectura automática sexa rápida. Unha alerta de antigüidade e unha saída manual son máis útiles ca unha animación de documentos procesados.

Un piloto que inclúa os documentos difíciles

1. Separar mostras de preparación e de avaliación; evitar probar só cos documentos usados para axustar o sistema.
2. Incluír formatos, provedores e idiomas presentes no traballo real, ademais de páxinas torcidas, anexos múltiples e campos ausentes.
3. Medir exactitude por campo e erros críticos por documento, non só unha media global.
4. Contabilizar tempo de revisión, reintentos e rexistros duplicados ou perdidos.
5. Probar o que sucede se cae o ERP, se se revoga un permiso ou se chega un formato novo.

Os criterios de aceptación deben reflectir o risco. Un erro nunha descrición interna non ten a mesma consecuencia ca asociar unha factura a outro provedor. Primeiro pódese traballar en paralelo ao proceso actual, sen crear rexistros definitivos. A ampliación de permisos vén despois da avaliación.

A combinación de regras e IA debe poder cambiar: ás veces compensa engadir un parser para un formato frecuente; outras, revisar a calidade do escaneado. O modelo máis potente non compensa unha fonte incompleta nin unha integración sen control de duplicados.

Que preparar para estudar o teu fluxo

Para unha primeira análise abondan un mapa do proceso, unha relación de tipos documentais, os campos que necesita a aplicación de destino e unha descrición das excepcións. Calquera mostra real debe compartirse por unha canle e cunhas condicións acordadas; non é necesario enviar documentación confidencial no formulario público.

A guía dos dez procesos automatizables sitúa este fluxo entre outras oportunidades. Se o problema principal é localizar respostas en documentos xa arquivados, consulta a guía de RAG. Para levar a lectura e validación a unha aplicación, o servizo relacionado é intelixencia documental.