lift: Datalab slipper åpen 9B-modell som gjør PDF om til strukturert JSON

Har du noen gang hatt en haug med PDF-fakturaer, rapporter eller skjemaer som du bare ønsket fantes som strukturert data? Datalab slapp i går en open-weights modell kalt lift som gjør akkurat det: du gir den et JSON-schema, og den returnerer matchende JSON-data fra dokumentet – uten å fylle inn felt den ikke finner.

Det siste er faktisk det interessante her. De fleste modeller som trekker ut data fra dokumenter har en tendens til å fylle inn noe – selv om feltet er tomt eller tvetydig. lift er trent til å returnere null for manglende felt. Det høres enkelt ut, men det er en viktig egenskap hvis du skal bruke output i en automatisert pipeline der stille feil er vanskelig å oppdage.

Modellen er på 9 milliarder parametere, er bygget på en vision-arkitektur som forstår layout og struktur i sider, og håndterer både PDF-er og bilder. Den kan kjøres lokalt via vLLM. Kildekoden er Apache 2.0 og tilgjengelig på GitHub. Vektene har en modifisert OpenRAIL-M-lisens – gratis for forskning, personlig bruk og startups med under 5 millioner dollar i finansiering eller inntekt. Liker du å kjøre ting selv slik jeg gjør, er dette samme sjanger som open source-verktøyene som lar deg kjøre inferens lokalt uten å sende data ut av huset.

Hva er schema-constrained decoding?

Den tekniske mekanismen bak lift er noe som heter schema-constrained decoding. I korte trekk: du gir modellen et JSON-schema, og under generering maskeres tokens som ville bryte strukturen. Det betyr at modellen rett og slett ikke kan produsere ugyldig JSON – strukturen håndheves token for token, ikke sjekket etterpå. Under panseret oversettes schema-et til Pydantic-modeller.

Rent praktisk betyr det at du aldri trenger å skrive kode som parser eller validerer output-formatet. Strukturen er alltid som forventet. Innholdet er en annen sak – schema-constrained decoding styrer form og typer, ikke meningsinnhold. En numerisk verdi kan fremdeles være feil, selv om den er syntaktisk korrekt.

Lifts eget eksempel er en faktura-parser der schema definerer felter som invoice_number, total og en array med linjeposter. Modellen leser PDF-en og returnerer et ferdig JSON-objekt. Ingen regex, ingen rule-basert parsing, ingen brittle post-processing.

Slik installerer og bruker du lift

Installasjon er rett frem via pip og krever Python 3.12 eller nyere, samt at du har vLLM tilgjengelig. Med en lokal GPU kan du kjøre hele pipelinen selv:

pip install lift-pdf
lift_vllm            # starter vLLM-server
lift_extract input.pdf ./output --schema schema.json

Det finnes også et Python-API:

from lift import extract
result = extract("document.pdf", "schema.json")

Datalab anbefaler å skrive gode beskrivelser for felt som kan være tvetydige – det er det viktigste enkeltgrepet for å øke nøyaktigheten. Hold schema-et flatt og grunt der det er mulig, og marker felt som required sparsomt. Output bør valideres i pipeline-en etterpå, siden modellen garanterer struktur men ikke semantisk korrekthet.

Modellen er tilgjengelig på HuggingFace og Datalab har bygget en playground du kan bruke for å teste mot egne dokumenter uten å sette opp noe lokalt.

Hvem passer lift for?

Datalab trekker frem tre bruksscenarioer der selvhosting av lift gir mening: data-residency-krav (dokumenter som ikke kan forlate egne servere), høyt volum der API-kostnader begynner å bite, og situasjoner der du trenger forutsigbar latens uten nettverksavhengigheter.

Jeg tenker lift er interessant for alle som jobber med dokumentautomatisering – fakturabehandling, kontraktsanalyse, skjemaparsing, rapportekstraksjon. Det er den typen ting mange SMB-er gjør manuelt i dag, og som egentlig burde vært automatisert for lenge siden. Hvis du har en haug med PDF-er som ser noenlunde like ut, er dette en god kandidat for automatisering.

Vil du ha høyere nøyaktighet og ikke har GPU tilgjengelig, er Datalabs hostede API et alternativ. Det inkluderer per-felt verifikasjon, sitasjoner og tillitsscorer – og scorer ifølge Datalab litt høyere enn selvhostet lift. Valget mellom cloud-API og selvhosting avhenger mer av kravene dine enn av modellen i seg selv.

Hvordan står lift mot lignende verktøy?

Dokumentekstraksjon er et felt med en del konkurrenter. NuExtract3 – den open source VLM-en for strukturert dokumentekstraksjon – er en 4B-modell fra NumInd som gjør mye av det samme. Den er mindre og lettere, mens lift legger seg høyere på Datalabs egen nøyaktighetsmåling. Som alltid med slike interne benchmarks: ta tallene med en klype salt og test mot dine egne dokumenter før du konkluderer.

Mistral OCR 4 er en annen tilnærming, men det er primært et verktøy for layout-bevart tekstekstraksjon og Markdown-konvertering, ikke JSON-strukturering basert på ditt eget schema. De to adresserer litt forskjellige problemer – vil du sammenligne flere vision-modeller, har jeg også sett på hvordan Qwen 3 VL og Gemma 4 gjør det på vision-oppgaver.

Datalab sammenligner også lift mot Gemini Flash 3.5 og sin egen cloud-API. Selvhostet lift ligger litt under Gemini Flash 3.5 på felt-nøyaktighet, men poenget Datalab vil frem til er at du får en lokal modell du eier selv, uten å sende dokumentene til en skytjeneste. For mange brukstilfeller – særlig der personopplysninger er involvert – er det en fornuftig avveining.

Ofte stilte spørsmål