Datalab Rilascia lift: Un Modello Visione Aperto Da 9B Che Estrae JSON Strutturato Dai PDF Con Schemi

Datalab ha annunciato l’uscita di lift, un modello visione da 9 miliardi di parametri ideato espressamente per l’estrazione strutturata. L’utente fornisce uno schema JSON ed il modello restituisce un oggetto JSON coerente con tale schema. Il modello gestisce direttamente PDF e immagini e produce un output conforme attraverso la decodifica vincolata.

Questa è la prima volta che Datalab sviluppa un modello specifico per l’estrazione. La divisione ha già fornito strumenti OCR opensource come chandra, marker, e surya. lift estende questa esperienza introducendo l’uso di schemi JSON personalizzati, il che permette un’estrazione più accurata e precisa.

Che Cos’è Datalab lift?

Lift è un modello di visione artificiale con 9 miliardi di parametri, specializzato nell’estrazione strutturata. Accetta come input uno schema JSON standardizzato e produce il dato in formato JSON conforme all’output atteso. Il modello elabora documenti multi-pagina in una singola passata; può riconoscere campi che si estendono su diverse pagine, considerando l’intero documento in un unico processo, e non pagina per pagina.

Vengono fornite due modalità di inferenza: la prima è locale tramite HuggingFace, ideale per lo sviluppo e i test; la seconda è eseguibile su un server vLLM, che Datalab consiglia per l’utilizzo in production. Il codice del modello è pubblicato sotto licenza Apache 2.0 e i pesi sono rilasciati con una versione modificata di licenza OpenRAIL-M.

Schema-Constrained Decoding: Il Meccanismo Fondamentale

Il cuore dell’architettura è la “decodifica vincolata allo schema”, una caratteristica che garantisce che l’output del modello mantenga la struttura esata richiesta. In pratica, lo schema fornito dall’utente viene dapprima convertito in un modello Pydantic, quindi normalizzato in uno schema JSON stretto.

Questo schema viene poi utilizzato come un formato di risposta per il server vLLM. Durante la generazione, il server compila lo schema in una grammatica. Ad ogni passo, il modello assegna una probabilità ai vari token che possono seguire. L’output valido è definito da questa grammatica, bloccando i token che violerebbero la struttura. Il risultato è sempre JSON coerente con lo schema, non come risultato ulteriore, ma come parte integrante del processo.

Tuttavia, è fondamentale notare che la decodifica vincolata garantisce la struttura ma non la correttezza semantica. Il modello potrebbe, ad esempio, restituire un numero di giusto tipo, ma sbagliato in valore. La validità strutturale non implica quindi la correttezza.

Per gestire casi in cui i dati sono inesistenti, lift permette l’esclusione di un campo. Ogni campo scalare accetta tipo o null, permettendo al modello di non fornire dati non presenti. Questo comportamento non è solo una feature del vincolo, ma anche un comportamento appreso.

Supporto ai Tipi JSON

Lift supporta una vasta gamma di tipi JSON, tra cui: stringa, numero, intero, booleano, array di questi, array di oggetti, e oggetti annidati. I descrittori dei singoli campi aiutano il modello nel caso di ambiguità.

Tuttavia, alcune funzioni di JSON Schema non sono implementabili, come enum, anyOf/oneOf, $ref, e additionalProperties. Quando lift non riesce a generare la struttura desiderata, non lancia un errore. Invece, registra un’avviso e genera comunque in assenza del vincolo. Potresti quindi ottenere dati non conformi allo schema.

Per evitare questo problema, Datalab raccomanda di limitare i propri schemi al sottoinsieme supportato e di validare sempre l’output JSON rispetto allo schema richiesto. Non si deve assumere che ogni chiamata produca un risultato conforme a causa dell’applicazione vincolata.

Esempio di Schema per Fattura

Ecco uno schema semplice per l’estrazione di dati da una fattura:

{
"type": "object",
"properties": {
"invoice_number": {"type": "string", "description": "Invoice identifier"},
"total": {"type": "number", "description": "Total amount due"},
"line_items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": {"type": "string"},
"amount": {"type": "number"}
}
}
}
},
"required": ["invoice_number", "total"]
}

Abstention by Default: L’Eccellenza di Sintesi

Uno degli obiettivi principali di lift è non inventare dati. Quando un campo richiesto non è incluso nei documenti, ad esempio un ID fiscale fittizio, il modello restituisce null. Questo previene errori silenziosi che non riuscirci in downstream. Lasciare vuoti i campi mancanti, invece di immaginarli, è un comportamento appreso attraverso l’addestramento.

L’utente è incaricato di marcare come “richiesti” solo i campi che devono essere presenti assolutamente. In questo modo, lift fornisce un estrattore che può riportare chiaramente quando un attributo non è stato incluso.

Benchmark Comparativo

Datalab ha messo a prova lift in un benchmark composto da 225 documenti, che variavano da 6 a 64 pagine, con circa 11.000 campi valutati. Il dataset include casi ostici, per testare la struttura e la velocità di estrazione.

Ecco i risultati confrontandi diversi modelli:

• Datalab API: field accuracy 95.9%, full-document accuracy 44.4%, latency 30.8s
• Gemini Flash 3.5: field accuracy 91.3%, full-document accuracy 40.0%, latency 28.1s
• lift (9B): field accuracy 90.2%, full-document accuracy 20.9%, latency 9.5s
• Azure Content Understanding: field accuracy 83.4%, full-document accuracy 22.2%, latency 73.7s
• NuExtract3 (4B): field accuracy 81.5%, full-document accuracy 8.4%, latency 8.3s
• Qwen3.5-9B: field accuracy 76.32%, full-document accuracy 24.0%, latency 16.8s

Le metriche di accuratezza su singoli campi evidenziano la forza di lift, che risulta il modello più preciso nella categoria del modello auto-hostabile. Anche in termini di velocità, è nettamente più vel