LLMStructBench: Benchmarking Large Language Model Structured Data Extraction

1. Il Problema

L'estrazione di informazioni strutturate da testo naturale è un requisito fondamentale in settori come risorse umane, finanza, logistica ed e-commerce, spesso per alimentare flussi di lavoro ETL (Extract, Transform, Load). Sebbene i Large Language Models (LLM) siano sempre più utilizzati per questo scopo, la loro affidabilità nel produrre output sintatticamente validi (JSON corretti) e semanticamente accurati (valori estratti correttamente) rimane insufficientemente compresa.
Esistono due criticità principali:

1. Validità Strutturale: Molti modelli falliscono nel generare JSON che rispettano rigorosamente uno schema predefinito, rendendo l'output inutilizzabile per sistemi downstream che richiedono dati completi al primo tentativo.
2. Accuratezza Semantica: Anche quando la struttura è corretta, i modelli possono commettere errori di allucinazione o estrazione errata dei valori.
   La ricerca attuale si concentra spesso o sulla decodifica vincolata (schema-constrained decoding) o su strategie di prompting, ma manca un benchmark olistico che valuti il compromesso tra validità strutturale e accuratezza semantica su modelli open-source in scenari realistici.

2. Metodologia

Dataset e Scenari (LLLMStructBench)

Gli autori hanno creato un dataset aperto composto da 995 campioni manualmente verificati, suddivisi in 5 casi d'uso ispirati a flussi di lavoro reali (es. ticket di supporto IT, richieste di malattia, estensioni di progetto, registrazioni a conferenze, richieste di prestito attrezzature).

• Generazione: I dati sono stati generati sinteticamente utilizzando GPT-4o per creare messaggi di testo naturale partendo da oggetti JSON strutturati, garantendo una corrispondenza uno-a-one tra testo e Ground Truth (GT).
• Complessità: Il dataset copre una gamma di complessità strutturale, da coppie chiave-valore piatte a strutture annidate con array di oggetti (fino a 4 livelli di profondità).
• Verifica: Tutti i campioni sono stati revisionati manualmente per rimuovere discrepanze tra testo e schema, assicurando che il GT contenga esattamente le informazioni presenti nel testo.

Modelli Valutati

Lo studio ha valutato 22 modelli LLM open-source (con parametri che vanno da 0.6B a 70B) appartenenti a cinque famiglie: Qwen3, Phi (3/3.5/4), Gemma3, Deepseek-R1 e Llama3.

• Per completezza, è stato incluso GPT-4o come modello proprietario di riferimento, ma non è stato incluso nel confronto diretto basato sulle dimensioni dei parametri.

Strategie di Prompting

Sono state testate 5 configurazioni di prompting per isolare l'impatto dell'enforcement a livello di API rispetto alla guida a livello di prompt:

1. J: Impostazione del parametro API format="json" (nessuna istruzione nel prompt).
2. P: Istruzione esplicita nel prompt di seguire uno schema e un esempio (nessun parametro API).
3. PJ: Combinazione di parametro API e istruzioni nel prompt.
4. J+: Impostazione dello schema JSON completo nel parametro API format.
5. PJ+: Combinazione di parametro API con schema completo e istruzioni/esempi nel prompt.

Metriche di Valutazione

Per superare le limitazioni delle metriche tradizionali, sono state introdotte due metriche combinate:

1. $F1_{micro}$ (Accuratezza a livello di token): Valuta la precisione e il richiamo delle coppie chiave-valore. Distingue tra:
   • Missing Key (MK): Chiave assente.
   • Missing Value (MV): Valore assente o nullo.
   • Wrong Value (WV): Valore errato (misurato con distanza di Levenshtein per stringhe o errori di tipo).
   • La metrica penalizza pesantemente gli errori di tipo e i valori errati, assegnando crediti parziali per mismatch coercibili.
2. $DOC_{micro}$ (Validità a livello di documento): Misura la percentuale di generazioni che sono JSON perfettamente validi e parsabili, penalizzando i fallimenti totali (output vuoto, JSON non valido, violazione dello schema).
3. Punteggio Composito: Una media ponderata ($Score = 0.5 \cdot F1_{micro} + 0.5 \cdot DOC_{micro}$) per fornire una classifica unificata.

3. Risultati Chiave

Impatto della Strategia di Prompting

• La scelta della strategia di prompting è più importante delle dimensioni del modello.
• La strategia P (solo istruzioni nel prompt) e PJ+ (schema API + prompt completo) si sono rivelate le più efficaci.
• Trade-off: La strategia PJ+ garantisce quasi sempre una struttura JSON valida (alto $DOC_{micro}$), specialmente per modelli piccoli o meno affidabili, ma tende a spostare gli errori verso la semantica (aumenta i valori errati, WV). Al contrario, la strategia P offre un migliore equilibrio per modelli ben allineati, ma può fallire catastroficamente nella validità strutturale per alcune famiglie (es. Phi).

Relazione tra Dimensione del Modello e Prestazioni

• Non monotonicità: Non esiste una relazione strettamente monotona tra il numero di parametri e il punteggio complessivo. Modelli più piccoli e ben ottimizzati (es. Gemma3-12B e Qwen3-1.7B) hanno superato modelli molto più grandi (es. 70B) in termini di punteggio composito.
• Scalabilità: L'accuratezza semantica ($F1_{micro}$) scala generalmente con le dimensioni del modello, ma la validità del documento ($DOC_{micro}$) è molto più sensibile alla compatibilità tra modello e strategia di prompting.
• Outlier: I modelli della famiglia Phi (specialmente 3.8B) hanno mostrato prestazioni scarse con la strategia P a causa di incompatibilità strutturali, migliorando significativamente con PJ+.

Analisi degli Errori

• Errori Dominanti: L'errore più frequente e persistente in tutte le configurazioni è il Wrong Value (WV). Anche i modelli più grandi (fino a 70B) producono valori errati in circa la metà delle esecuzioni.
• Omissione di Chiavi (MK): Gli errori di omissione delle chiavi tendono a scomparire man mano che le dimensioni del modello aumentano (sopra i 7-8B parametri), ma gli errori di contenuto persistono.
• GPT-4o: Il modello proprietario ha mostrato prestazioni simili ai migliori modelli open-source (es. Gemma3-27B), confermando la competitività dei sistemi open-source per compiti di estrazione strutturata.

4. Contributi Principali

1. Dataset Aperto: Introduzione di LLMStructBench, un dataset di 995 casi di test verificati manualmente, progettato specificamente per valutare l'estrazione JSON in scenari realistici.
2. Nuove Metriche: Definizione di metriche che separano la validità sintattica ($DOC_{micro}$) dall'accuratezza semantica ($F1_{micro}$), permettendo un'analisi più granulare dei fallimenti.
3. Analisi Comparativa Estesa: Valutazione sistematica di 22 modelli open-source con 5 strategie di prompting, fornendo raccomandazioni pratiche immediate per gli sviluppatori.
4. Insight sul Trade-off: Dimostrazione che la scelta della strategia di prompting può essere più critica della dimensione del modello, e che garantire la validità strutturale (tramite PJ+) può talvolta peggiorare l'accuratezza semantica.

5. Significato e Implicazioni

Il lavoro di Tenckhoff et al. fornisce una guida cruciale per l'adozione di LLM in applicazioni ETL e di integrazione dati.

• Per la Pratica: Suggerisce che non è sufficiente affidarsi a modelli più grandi; è fondamentale selezionare la strategia di prompting adatta alla specifica famiglia di modelli (es. usare PJ+ per modelli piccoli o instabili, P per modelli ben allineati).
• Per la Ricerca: Evidenzia che la validità strutturale e l'accuratezza semantica sono problemi distinti. La ricerca futura dovrebbe concentrarsi su tecniche di validazione post-generazione o fine-tuning specifico per ridurre gli errori di valore (WV), che rimangono il collo di bottiglia principale.
• Sostenibilità: Conferma che modelli open-source di dimensioni moderate, se configurati correttamente, possono raggiungere prestazioni paragonabili a modelli proprietari costosi, favorendo soluzioni locali e privacy-preserving.

In sintesi, il paper dimostra che per l'estrazione di dati strutturati, l'ingegneria del prompt e la selezione dell'architettura sono fattori determinanti quanto, se non più, la scala dei parametri.