Oltre la Demo: le complessità nascoste nell’addestrare e validare VLMs per la Document AI

La “trappola della demo”: dal notebook all’ambiente di produzione

Nel mondo dell’Intelligenza Artificiale, è facile cadere in quella che possiamo definire la "trappola della demo". Oggi, grazie alla vasta disponibilità di framework open-source e tutorial online, è diventato particolarmente semplice creare un notebook che effettua il fine-tuning di uno Small Vision Language Model (SVLM) per adattarlo ad un task specifico (come, ad esempio, l’estrazione di dati strutturati da un set di documenti).

Tuttavia, passare da un semplice notebook che addestra il modello su un set limitato di documenti, a un ambiente di produzione enterprise, capace di gestire su larga scala l'imprevedibilità dei documenti reali, è un processo estremamente complicato. 

Di fatto, creare il modello rappresenta solo il 20% del lavoro totale. Il restante 80% del lavoro effettivo è la vera sfida, in quanto richiede tutta una serie di operazioni:

• Creare e curare un dataset multimodale, con un numero significativo di elementi e che rappresenti in maniera adeguata il task per il quale si vuole far specializzare il modello.
• Ingegnerizzare la giusta pipeline per addestrare il modello senza incorrere in complicati errori tecnici.
• Valutare gli output generati dal modello, una volta completato il fine-tuning, in maniera completa e rigorosa.

Oltre ciò, va anche menzionato che non sempre il VLM più moderno e potente rappresenta la scelta migliore. La soluzione più adeguata varia notevolmente tra i diversi casi d’uso e, spesso, modelli più vecchi ma allo stesso tempo molto più leggeri e veloci rappresentano la scelta più sensata in determinate situazioni, ottimizzando risorse e tempi di risposta.

La necessità di un dataset multimodale

Come già accennato, il primo grande ostacolo ingegneristico riguarda la natura dei dati. 

Addestrare un Vision Language Model (VLM) è profondamente diverso dall’addestrare un Large Language Model (LLM) puramente testuale e richiede un dataset multimodale. Un VLM deve imparare a fondere e interpretare simultaneamente testo, layout, coordinate spaziali e componenti visive (come timbri, loghi o firme).

Creare, annotare e gestire un dataset di questo tipo è in genere molto complesso e costoso in termini di tempo. In aggiunta, addestrare un modello (anche relativamente piccolo, come uno small VLM) su grandi quantità di immagini ad alta risoluzione richiede enormi risorse computazionali che, se non gestite in maniera opportuna, si traducono automaticamente in elevati costi monetari. 

Diventa perciò essenziale (ma al tempo stesso complicato) trovare il trade-off ottimale tra diversi aspetti tecnici, come la dimensione delle immagini in input, il consumo di memoria GPU (VRAM) e le performance desiderate.

In ogni caso, va comunque specificato che non sempre è strettamente necessario fare il fine-tuning di un modello per farlo specializzare in un settore. Infatti, se il task che il modello dovrà svolgere non è particolarmente ostico (e più nello specifico, in un contesto di Document AI, se i documenti non sono eccessivamente complessi o strutturati), si potrebbe utilizzare direttamente il modello di base pre-addestrato. 

Ciò che invece non cambia, è la necessità di un dataset multimodale (più nel dettaglio, un dataset di validazione, con le stesse caratteristiche di quello di training, ma separato da esso) che possa essere utilizzato per valutare in maniera profonda le performance del modello nel task di riferimento, sia nel caso in cui esso sia utilizzato dopo un fine-tuning, sia quando è utilizzato in maniera diretta.

Le complessità del fine-tuning

Una volta costruito un dataset adeguato, è necessario capire come processarlo e passarlo al modello affinchè, una volta completato il fine-tuning, esso sia in grado di restituire le informazioni richieste nel formato più opportuno.

Ad esempio, in ambito Document AI, il modello dovrà restituire i dati estratti in un formato strutturato e pronto per essere integrato nei sistemi aziendali (come ERP o CRM).

Addestrare un modello a produrre in output le informazioni in uno specifico formato rigido (ad esempio uno schema JSON prestabilito) può essere molto complesso, in quanto tali modelli tendono naturalmente a generare testo libero o ad allucinare chiavi sintattiche, "rompendo" l'integrazione.

Un altro problema, riguarda il cosiddetto catastrophic forgetting: se il fine-tuning non è eseguito in maniera corretta, il modello potrebbe concentrarsi eccessivamente sul nuovo task specifico, dimenticando parte delle sue capacità generali di comprensione e ragionamento acquisite durante la fase di pre-training e diventando di conseguenza fragile e incapace di generalizzare.

Le complessità nel validare un modello post fine-tuning

Se già soltanto progettare e addestrare un modello è un processo estremamente complesso, misurarne il reale successo lo è ancor di più. 

Infatti, pur esistendo tutta una serie di tecniche e di metriche che sono comunemente utilizzate per valutare le capacità di un modello su task relativi al settore della Document AI, nessuna di esse è perfetta e, nella maggior parte dei casi, è necessario utilizzarne diverse in combinazione per ottenere una panoramica delle reali capacità del modello.

Inizialmente, la metrica più utilizzata era l’exact match, la quale restituiva un valore positivo soltanto nel caso in cui la predizione generata dal modello fosse identica alla ground truth.

Ciò ovviamente costituisce un problema in tutti quei casi in cui la predizione è semanticamente equivalente alla ground truth, pur essendo sintatticamente diversa (es. "10/05/2024" invece di "10 Maggio 2024"), in quanto il modello classificherebbe erroneamente la predizione come errata, generando un numero potenzialmente elevato di falsi negativi.

Successivamente, considerando che i VLMs sono pur sempre di base modelli linguistici, si è pensato di utilizzare metriche popolari in ambito NLP, come ROUGE e BLEU. Tuttavia, tali metriche sono pensate per valutare la fluidità di traduzioni o riassunti e risultano dunque inutili in un contesto di information extraction, dove ciò che conta è il recupero preciso del dato e non la parafrasi linguistica.

Attualmente, nella ricerca accademica il focus è su metriche come l'ANLS (Average Normalized Levenshtein Similarity). Pur essendo tali metriche molto più adatte a compiti di Document AI, in quanto tollerano leggeri "rumori" (come piccoli errori OCR), esse presentano comunque dei limiti nel valutare la correttezza logica complessiva del dato estratto.

Infine, un approccio moderno consiste nell’utilizzare la tecnica LLM-as-a-judge per catturare le sfumature semantiche. Tale approccio, consiste nell’utilizzare un LLM separato (in genere di dimensioni molto più elevate e con una potenza maggiore, rispetto al modello principale) per valutare le risposte generate dal VLM principale. Pur essendo tale metodo sempre più utilizzato ed effettivamente efficace e generalizzabile a diversi compiti, esso comporta costi computazionali e tempi di esecuzione molto elevati, che crescono in modo quasi insostenibile all’aumentare del numero di documenti nel dataset di test.

La soluzione: una valutazione eterogenea

Per uscire da questo labirinto di colli di bottiglia, l'approccio vincente si traduce in una valutazione eterogenea.

Non bisogna affidarsi ad una singola metrica, ma bisogna combinare il giusto set di tecniche di valutazione in maniera corretta e ponderata: validazioni logiche e sintattiche sul JSON, uso dell'ANLS per tollerare piccole variazioni testuali, e chiamate selettive LLM-as-a-judge solo per i campi semanticamente ambigui. Implementare un sistema di validazione automatizzato di questo livello richiede competenze di software engineering specifiche molto elevate.

Oltre il Modello: L'Automazione dell'Intero Processo

Arrivati a questo punto, diviene fondamentale specificare un dettaglio importante: l'obiettivo reale di una pipeline IDP non dovrebbe mai essere confinato alla sola estrazione di informazioni; il traguardo è automatizzare l'intero processo di gestione del documento dall'inizio alla fine.

In questa visione sistemica, il "modello" stesso (con il relativo fine-tuning e validazione) rappresenta solo una piccola parte dell'intera pipeline, la quale è costituita invece da tutta una serie di step complessi e interconnessi, che spaziano dall'ingestione del file all'integrazione del dato strutturato finale.

Nota: La progettazione di una pipeline IDP completa, le relative complessità infrastrutturali e un'analisi su quando possa avere senso affidarsi a degli esperti, piuttosto che avventurarsi nel costruire una pipeline di questo tipo "in casa", sarà il tema centrale che esploreremo nel dettaglio nel nostro prossimo articolo.

Conclusione

La Document AI ha il potenziale di rivoluzionare i flussi aziendali, ma la tecnologia da sola non basta. Senza una pipeline costruita specificamente per il caso d’uso richiesto, addestrata su dati di qualità e validata opportunamente tramite metriche eterogenee, anche il modello più potente e performante fallirà nel compito assegnatogli appena fuori dal contesto della "demo".

Progettare e mantenere una pipeline robusta di questo tipo richiede tempo e competenze specifiche, sia in ambito Machine Learning che in ambito Software Engineering. 

Per tutte queste ragioni e per tutta una serie di complessità aggiuntive non menzionate in questo articolo in quanto relative ai casi d’uso specifici, le aziende che desiderano automatizzare con successo i propri processi documentali dovrebbero sempre affidarsi a degli esperti nel settore dell'Intelligent Document Processing.

Vuoi capire come implementare ed integrare una piattaforma IDP adatta ai tuoi flussi documentali in modo robusto e scalabile? Contattaci o prenota una demo per scoprire le soluzioni enterprise sviluppate dagli esperti di myBiros.

‍