Lad os være ærlige. De fleste “AI‑læs mine PDF’er”-værktøjer ender i halvstruktureret tekst og en bunke regex. Datalabs nye model, lift, sigter den anden vej: Du giver et JSON Schema, modellen læser dokumentet, og output er gyldig JSON i den form. Ingen efterfølgende formatering. Det er i hvert fald løftet.
Fakta først. Ifølge Datalab er lift en open‑weights vision‑model med 9 milliarder parametre, trænet til struktureret ekstraktion fra PDF’er og billeder. Den rapporteres at klare 90,2 procent feltnøjagtighed på Datalabs eget 225‑dokuments benchmark og kører med en median på 9,5 sekunder pr. dokument. To inferencemåder følger med: lokal via HuggingFace og fjern via en vLLM‑server, som Datalab anbefaler til produktion. Koden er under Apache 2.0, vægtene under en modificeret OpenRAIL‑M licens. Alt dette er fra Datalab selv via MarkTechPost.
Sådan tvinges JSON i form
Kernen i lift er schema‑constrained decoding. Datalab beskriver en kæde: JSON Schema konverteres først til en Pydantic‑model, normaliseres til en streng JSON Schema, og kompileres så til en grammatik, som vLLM‑serveren bruger til at maskere tokens under generering. Ved hvert trin må modellen kun vælge næste token, der ikke bryder grammatikken. Derfor lander output som gyldig JSON i præcis den form, du bad om. Strukturgaranti, ikke sandhedsgaranti. Det skel er vigtigt.
I praksis: Et felt typet som number bliver et tal. Men tallet kan være forkert. Validitet er ikke korrekthed. JSON, der kan parses, er ikke det samme som rigtige værdier i felterne, og feltnøjagtighed skal stadig måles på sand data, ikke pæn struktur.
Datalab skriver også, at hver skalar “åbnes” for null. Altså: modellen kan abstain på et felt ved at udskrive null uden at bryde schemaet. Det dæmper tvivlsomme gæt, men kræver en downstream‑politik: hvad gør man, når total_amount er null i en del af tilfældene? Automatisk eskalation, manuel kø eller fallback‑regler.
Huller i schema‑støtten
Der er også guidance via feltbeskrivelser. En beskrivelse kan hjælpe modellen med at skelne mellem “total”, “subtotal” og “due”. Det er nyttigt, men ikke en kontrakt med virkeligheden. Beskrivelser er en prompt, ikke bevis.
Multi‑page i ét pass
Datalab fremhæver, at lift kan læse hele dokumenter i én omgang og samle værdier på tværs af sider. For fakturaer og kontrakter med bilag kan det være en reel gevinst: ingen side‑for‑side klip‑og‑klister, ingen gætterier om rækkefølge. Mindre limkode, mere robusthed.
Men der er en regning. Single‑pass øger kontekst og hukommelseskrav pr. anmodning. Det skubber GPU‑forbruget op og begrænser batch‑størrelser. Skalering kan derfor blive dyrere end en page‑wise pipeline, hvor man fragmenterer input og samler senere. Min vurdering: ét pass er stærkest, når felter faktisk krydser sider, eller når layoutet har globale referencer. Ellers kan sidevise pipelines være billigere og lettere at parallelisere.
Ydeevne, drift og SLA’er
Datalab angiver en median runtime på 9,5 sekunder pr. dokument. Det er fint til backoffice‑bunker og natlige batchkørsler. Stramt til live‑UI, hvis man venter på ét dokument ad gangen. Og median siger intet om halerne. Hvad sker der ved 40 sider og mange billeder? Det må man måle selv.
Pakken har to inferencemåder: lokal inferens via HuggingFace og fjern inferens via en vLLM‑server, hvor Datalab anbefaler vLLM til produktion. vLLM giver typisk bedre styring af strukturerede outputs via response_format og en effektiv scheduler. Men det flytter kompleksiteten derhen, hvor MLOps skal trives: GPU‑planlægning, kvoter, batchning, autoscaling, observability. On‑prem vLLM er et fornuftigt kompromis ved følsomme data.
I SRE‑termer: Sæt en klar latency‑SLA pr. dokumenttype, en batch‑SLA for natkørsler og et fallback for spidser. Overvej to køer: hurtig kundeoperation med stramme timeouts og en dyb kø til store dokumenter. Monitorér abstention‑rate pr. felt, ikke kun total accuracy. Og mål faktisk GPU‑udnyttelse, ikke ønsketænkning.
Licenser og hvad man må
Datalab frigiver koden under Apache 2.0, en permissiv OSS‑licens med få begrænsninger. Enterprise‑venlig. Vægtene er på en modificeret OpenRAIL‑M, normalt en ansvarlig brugslicens med vilkår ovenpå ophavsretten. “Modificeret” er nøgleordet. Før produktion bør juridisk team læse den konkrete tekst og afklare forbudte anvendelser, deling af finetunede vægte og kommerciel distribution.
Når det gælder datafortrolighed, er open‑weights en fordel: man kan køre modellen isoleret. Men verificér altid praksis i den valgte inferencestak. Ingen skjult logging til tredjepart, ingen uventet netværkstrafik fra pods. Tjek det.
Hvad betyder det i feltet
Datalab positionerer lift i et åbent felt af ekstraktionsmodeller. Nogle er formålsbyggede, som NuExtract‑familien. Andre er generelle VLM’er, som Qwen3.5‑9B, presset til ekstraktion. Ifølge Datalab topper lift den åbne gruppe på feltnøjagtighed i deres sammenligning. Lovende, men også farvet: benchmarket er deres eget, 225 dokumenter, og sammensætningen kan påvirke udfaldet. Uafhængig verifikation er ønskelig, især på støjfyldte scannede PDF’er og tværsprog.
Der er også forskellen mellem “open” og “hostede” alternativer. Hostede API’er er hurtige at starte på, men flytter dataflowet ud af egen infrastruktur. Open‑weights som lift giver kontrol og inspektion. Til gengæld flere opsætningsvalg og DevOps‑timer.
Implementering uden romantik
Skal man teste lift, så start med schema‑design. Hold jer til det støttede undersæt. Navngiv felter tæt på interne datamodeller. Giv korte, præcise beskrivelser på tvivlsomme felter. Undgå enum og oneOf i første omgang. Smalt og stabilt slår smart og skrøbeligt.
Byg en valideringspipeline, der altid JSON‑schema‑validerer output nedstrøms, også selv om constrained decoding burde holde formen. Læg dertil semantiske checks: summer, datoperiode‑logik, CVR‑format, valuta. Og log alt i et data‑kvalitetsdashboard. Felt for felt. Ellers opdager man ikke det langsomme drift.
Human‑in‑the‑loop bør være aktiv i kanten. Definér en kø, hvor poster med null, lav sikkerhed eller brud på forretningsregler lander. Mål hvor ofte mennesker retter modellen, og brug feedback til schema‑justering eller feltbeskrivelser. Lad være med at automatisere alt dag ét.
Drift og arkitekturvalg
On‑prem eller cloud. Vælg efter dataklassificering. For meget følsomme dokumenter er on‑prem vLLM oplagt. For volumener med lavere følsomhed kan en administreret GPU‑pool være nok. Uanset hvad: planlæg GPU‑kapacitet efter spidsbelastning, ikke gennemsnit. Og vær realistisk om 9,5 sekunders median. De store PDF’er dukker altid op på værste tidspunkt.
Sæt også en fallback. Simple OCR + rules til basisfelter kan tage en del af trafikken, når modellen abstainer. Det er kedeligt—og netop derfor det, der redder SLA’er, mens en manuel kø rydder resten.
Risici og failure modes
Gyldig struktur er ikke korrekthed. En klassiker er forveksling af felter, der ligner: subtotal som total, shipping som moms. Beskrivelser hjælper, men garanterer ikke. Abstention‑mønstre kan skjule problemer, hvis for mange felter ender som null uden alarm. Derfor: overvåg null‑rate pr. dokumenttype og pr. felt.
Der er også licensrisiko. OpenRAIL‑varianten kan indeholde brugsbegrænsninger, der konflikter med niche‑scenarier. Det bør ikke stoppe POC, men det kan stoppe bred udrulning i regulerede brancher, hvis man ikke har læst det med småt.
Til sidst compliance. Regnskab og kontraktmetadata kræver revisionsspor. Gem dokumentbillede, prompt\/schema‑version, model‑hash, inference‑log og det endelige JSON‑output. Ellers er efterprøvbarheden væk, når nogen spørger “hvorfor blev totalen 0 her”.
Hvem bør starte, og hvem bør vente
Hurtige gevinster: fakturaer, kvitteringer, ordrebekræftelser, simple onboarding‑skemaer. Felter er ofte klare, og en schema‑styret tilgang kan fjerne meget manuelt tastearbejde. Kontrakter med lette metadata (titel, parter, datoer, jurisdiktion) er også realistiske.
Høj risiko: komplekse semantiske opgaver som fortolkning af klausuler, compliance‑tolkning eller fritekst med domskraft. Her er en model, der “kun” garanterer struktur, ikke nok. Brug den til metadata, ikke beslutninger.
Sammenligningen i øjenhøjde
Mod NuExtract‑typen og generelle VLM’er som Qwen3.5‑9B hævder Datalab, at lift ligger i front på feltnøjagtighed i den åbne kategori. Det er plausibelt, fordi specialisering typisk vinder i ekstraktion. Men uden uafhængige benchmarks bliver det ved et plausibelt udsagn. Et retvisende billede kræver test på egne datasæt: forskellige layouts, støj, sprogvarianter, scannede kopier i dårlig opløsning. Det mangler i det offentliggjorte.
Konklusionen uden pynt
Lift er interessant, fordi schema‑constrained decoding flytter balancen: langt mindre parsingkode, færre skrøbelige regex‑løsninger og en renere integration ind i ERP og CRM. Det gør den værd at teste nu. Men den er ikke en plug‑and‑play sandhedsmaskine. Strukturgaranti er ikke lig korrekthed, multi‑page koster hukommelse, og licensen skal læses.
Hvis beslutningen skal være praktisk: kør en fire ugers POC. Definér 10–15 felter, der faktisk sparer tid, byg et støttet schema, mål feltnøjagtighed, null‑rate og end‑to‑end tid. Sæt en manuel review‑kø og en simpel fallback. Holder tallene, så skalér gradvist. Man mærker forskellen først, når man sidder med det i hænderne.
