Alcune parse sbagliate non sembrano sbagliate finché non esce la risposta. Una tabella che finisce in testo plausibile ma senza struttura passa i controlli deterministici, e il modello risponde da quel testo con piena sicurezza. L’ultima linea di difesa, sostiene l’articolo, è l’LLM che legge il proprio input prima che l’utente veda la risposta.
L’idea: escalation guidata
PyMuPDF analizza una pagina in circa 5 millisecondi e a costo zero; un vision LLM sulla stessa pagina può costare diecimila volte tanto e richiedere una decina di secondi. Eseguire il parser più pesante su ogni pagina è uno spreco; eseguire il più economico ovunque è sbagliato. La soluzione è partire cheap ed escalare solo quando un controllo segnala che la parse economica ha mancato la risposta, tramite una cascata di verifiche: metadati pre-parsing, output del parser, scoring del retrieval e, infine, i segnali dell’LLM in fase di generazione.
Due escalation reali
Primo caso: la Tabella 3 del paper Attention, dove il valore di h per il modello base è 8. PyMuPDF appiattisce la griglia; gpt-4.1 risponde comunque “8” con confidenza 0.99, ma marca context_structured=False, segnalando che la struttura è fragile. Il flag fa scattare l’escalation ad Azure DI (costo circa 0,003$ e quattro secondi), dopo la quale la risposta è strutturalmente affidabile. Secondo caso: la Figura 1, un diagramma dove Azure non aiuterebbe; qui l’escalation è verso un vision LLM, che restituisce una descrizione strutturata dell’architettura encoder-decoder.
Il limite del segnale LLM
La parte più interessante è uno stress test da 18 run (tre modelli, due parser, tre domande). Su quattro risposte sbagliate, tutte e quattro riportavano context_structured=True: l’unico False apparteneva a una risposta corretta. Tradotto: il verdetto binario dell’LLM sulla qualità della propria parse non è abbastanza stabile per guidare la cascata. Curiosamente, il testo della motivazione (“header spezzati su più righe”, “celle non allineate”) è invece coerente tra un run e l’altro. La lezione operativa è tenere i controlli deterministici in testa alla cascata, usare l’LLM come ultima difesa e affidare a un giudice separato (una verifica di groundedness a valle) il compito di intercettare le fabricazioni.
In sintesi
- Parsing come decisione multi-controllo ordinata dal più economico: si escala solo quando un check segnala che la parse cheap non basta.
- Su casi reali l’escalation a un parser strutturato o a un vision LLM costa pochi centesimi ma corregge risposte altrimenti sbagliate.
- Il verdetto binario dell’LLM sulla propria parse è instabile: meglio regole deterministiche più un giudizio di groundedness separato.
Fonte: Loop Engineering with Adaptive Parsing in Action: Parsing Flat Tables with Azure and Figures with a Vision LLM — https://towardsdatascience.com/loop-engineering-with-adaptive-parsing-in-action-parsing-flat-tables-with-azure-and-figures-with-a-vision-llm/
Hai qualcosa da aggiungere? Unisciti alla discussione.