Lift – otwarty model AI do ekstrakcji danych z PDF i obrazów

Wyciąganie danych z plików PDF i skanów obrazów to jeden z najbardziej czasochłonnych, a zarazem kluczowych procesów w wielu firmach. Do tej pory rozwiązania oparte na sztucznej inteligencji często wymagały kosztownych API lub dawały wyniki o ograniczonej wiarygodności. Datalab, znany z otwartych narzędzi OCR takich jak chandra, marker czy surya, postanowił pójść o krok dalej. Zespół wypuścił lift – model wizyjny o 9 miliardach parametrów, który został zaprojektowany specjalnie do ekstrakcji strukturalnej. Przyjmuje schemat w formacie JSON i zwraca dane dopasowane do tego wzorca, od razu gotowe do dalszego przetwarzania.

Czym właściwie jest model lift?

To pierwszy model Datalab stworzony wyłącznie z myślą o ekstrakcji danych. Lift bazuje na architekturze wizyjno-językowej, ale wyróżnia go kluczowa cecha: od razu generuje wynik w formacie zdefiniowanym przez użytkownika. Przekazujesz mu plik PDF lub obraz oraz schemat JSON, a on zwraca obiekt JSON o dokładnie takim kształcie, jaki określiłeś. Co ważne, model radzi sobie z wielostronicowymi dokumentami w jednym przebiegu – potrafi odczytać wartości rozciągające się na kilka stron, bez konieczności dzielenia pliku na osobne części.

Lift występuje w dwóch trybach inferencji. Lokalnie można go uruchomić przez HuggingFace, natomiast do zastosowań produkcyjnych Datalab rekomenduje zdalny serwer vLLM. Cały kod modelu jest dostępny na licencji Apache 2.0, a wagi podlegają zmodyfikowanej licencji OpenRAIL-M – to oznacza, że komercyjne wykorzystanie wymaga akceptacji warunków, ale badania, projekty osobiste oraz startupy z finansowaniem poniżej 5 milionów dolarów mogą korzystać z niego bezpłatnie.

Jak wypada na tle innych modeli?

Segment otwartych modeli ekstrakcji dopiero się rozwija. Są wyspecjalizowane narzędzia jak rodzina NuExtract, ale też ogólne modele wizyjno-językowe, które czasem próbuje się wykorzystać do tego zadania – przykładem jest Qwen3.5-9B. Na własnym benchmarku Datalab (225 dokumentów, około 11 000 ocenianych pól) lift osiągnął 90,2% dokładności na poziomie pojedynczych pól, wyprzedzając zarówno NuExtract3 (81,5%), jak i Qwen3.5-9B (76,3%). Co więcej, medianowy czas przetwarzania dokumentu wynosi 9,5 sekundy – to około trzy razy szybciej niż model Gemini Flash 3.5.

Mechanizm ograniczonego dekodowania schematem

Najważniejszą innowacją w lift jest tak zwane schema-constrained decoding – dekodowanie ograniczone schematem. Zamiast najpierw generować dowolny tekst, a potem próbować go dopasować, model od razu wie, jaką strukturę ma przyjąć wynik. Działa to w ten sposób: twój schemat JSON jest przekształcany w model Pydantic, a następnie normalizowany do ścisłego schematu. Ten schemat trafia do serwera vLLM jako ograniczenie formatu odpowiedzi.

Podczas generowania serwer kompiluje schemat do gramatyki. W każdym kroku model oblicza prawdopodobieństwo dla wszystkich możliwych tokenów, ale gramatyka definiuje, które z nich są dozwolone na danym etapie. Tokeny, które złamałyby strukturę schematu, są maskowane – model może wybierać tylko spośród pozostałych. Dzięki temu wynik jest zawsze poprawnym JSON-em o wymaganym kształcie, już na poziomie pojedynczych tokenów.

Gwarancja struktury a poprawność znaczeniowa

Trzeba jednak pamiętać o istotnym ograniczeniu: to ograniczenie dotyczy wyłącznie formy, a nie treści. Jeśli pole jest zdefiniowane jako liczba, faktycznie będzie zawierać liczbę – ale niekoniecznie prawidłową wartość. Model może wygenerować poprawny strukturalnie JSON, który jest po prostu błędny merytorycznie. Innymi słowy, poprawność struktury nie jest równoznaczna z poprawnością danych. Datalab podkreśla, że konieczne jest walidowanie wyniku względem oryginalnego schematu po stronie użytkownika, na przykład sprawdzając, czy wymagany identyfikator faktury faktycznie został zwrócony w oczekiwanym formacie.

Abstencja – model, który woli milczeć niż kłamać

Kolejną cechą lift jest trenowana abstencja. W praktyce oznacza to, że każdemu polu w wyjściowym schemacie dodawana jest możliwość przyjęcia wartości null. Model został nauczony, aby nie wymyślać danych tam, gdzie ich nie ma – jeżeli dokument nie zawiera jakiegoś elementu, zwraca puste pole. To ogromna zaleta: halucynacja w postaci zmyślonego numeru NIP lub kwoty jest znacznie groźniejsza niż zwykłe stwierdzenie braku. Datalab zaleca, aby oznaczać jako wymagane tylko te pola, które muszą się pojawić w każdym dokumencie – w przeciwnym razie model uzna, że brak wartości jest dopuszczalny i zwróci null.

Wyniki benchmarku – co mówią liczby?

Datalab opublikował wyniki testów na swoim zestawie 225 dokumentów o długości od 6 do 64 stron. Zestaw zawierał przypadki wymagające odczytu między stronami, wyczerpujące listy, a także pola, które celowo pozostawiono puste, by sprawdzić, czy model nie zacznie halucynować. Każdy model działał na tych samych renderowanych obrazach stron i przetwarzał dokumenty w jednym przebiegu.

Oto kluczowe porównanie:

Dokładność na poziomie pól: lift – 90,2% (najlepszy wśród modeli do samodzielnego hostowania), Gemini Flash 3.5 – 91,3%, Azure Content Understanding – 83,4%, NuExtract3 – 81,5%, Qwen3.5-9B – 76,3%.
Dokładność pełnokumentowa (gdzie wszystkie pola są poprawne): Datalab API – 44,4%, Gemini Flash 3.5 – 40,0%, lift – 20,9%, Qwen3.5-9B – 24,0%, NuExtract3 – 8,4%, Azure – 22,2%.
Mediana czasu przetwarzania: lift – 9,5 s, Gemini Flash 3.5 – 28,1 s, Azure – 73,7 s, Qwen3.5-9B – 16,8 s, NuExtract3 – 8,3 s.

Warto podkreślić, że pełnokumentowa dokładność jest dla wszystkich modeli niska – nawet liderzy sięgają 44%. To pokazuje, jak trudne jest wyodrębnienie każdego pola bezbłędnie w jednym przebiegu, szczególnie przy długich dokumentach. Lift sprawdza się więc doskonale przy ekstrakcji na poziomie pól, która trafia potem do recenzji człowieka lub agregacji statystycznej. Do automatyzacji zero-touch, gdzie każdy błąd jest niedopuszczalny, lepiej sprawdza się API Datalab z dodatkowymi mechanizmami weryfikacji i cytowaniem źródła.

Jak zacząć używać lift w praktyce?

Datalab proponuje konkretny workflow, który prowadzi od definicji schematu do gotowego, zweryfikowanego zestawu danych. Na przykład przy przetwarzaniu faktur definiujesz pola: invoice_number, total, due_date i opcjonalnie line_items – brakujący tax_id będzie zwrócony jako null. Następnie uruchamiasz ekstrakcję, a jeśli wynik zawiera błąd lub puste wymagane pole, dokument trafia do kolejki recenzji. Na końcu walidujesz wyjściowy JSON względem swojego schematu – to pozwala wykryć przypadek, gdy schemat nie został skompilowany (np. z powodu użycia nieobsługiwanych konstrukcji jak enum czy anyOf), a model wygenerował dane bez ograniczeń.

Kilka praktycznych wskazówek od twórców:

Dodawaj description do pól, których nazwa może być niejednoznaczna – to twoja główna dźwignia na dokładność.
Trzymaj się obsługiwanego podzbioru schematu (obsługiwane typy: string, number, integer, boolean, tablice prostych typów i obiektów, obiekty zagnieżdżone). Unikaj enum, anyOf/oneOf, $ref i additionalProperties.
Preferuj płaskie, płytkie schematy – głębokie zagnieżdżenia są trudniejsze do poprawnej ekstrakcji.
Oznaczaj pola jako wymagane oszczędnie, aby model mógł zwrócić null tam, gdzie dane są faktycznie nieobecne.
Ograniczaj długie PDFy parametrem –page-range (w CLI) lub page_range (w Pythonie).
Przy wielokrotnych wywołaniach używaj jednej instancji InferenceManager, by uniknąć wielokrotnego ładowania modelu.

Najszybszą drogą do testów jest interfejs CLI. Instalujesz pakiet lift-pdf (wymaga Pythona 3.12+), uruchamiasz serwer vLLM poleceniem lift_vllm, a następnie wykonujesz ekstrakcję: lift_extract input.pdf ./output –schema schema.json. Każdy plik generuje dwa wyniki – plik JSON z danymi oraz plik metadanych do debugowania. Dostępna jest też aplikacja Streamlit (Schema Studio), która pozwala wizualnie budować i testować schematy na własnych dokumentach.

Kiedy hostować samodzielnie, a kiedy skorzystać z API?

Wybór między samodzielnym hostowaniem a gotową usługą Datalab zależy od konkretnych potrzeb. Model z otwartymi wagami sprawdzi się, gdy musisz zachować dane w swojej infrastrukturze (wymogi prawne, polityka bezpieczeństwa), potrzebujesz kontroli kosztów przy dużej skali lub pracujesz offline. Z kolei API Datalab oferuje dodatkowe funkcje – weryfikację poszczególnych pól, cytowanie źródła (citations) i wskaźniki pewności – co przekłada się na wyższą dokładność przy mniejszym nakładzie na zarządzanie infrastrukturą. Dla małych lub nieregularnych wolumenów API jest wygodniejszym rozwiązaniem.

Podsumowując, lift to solidne narzędzie dla każdego, kto potrzebuje wyciągać dane z PDF-ów w sposób strukturalny, z kontrolą nad formatem i z minimalizacją halucynacji. Nie jest to srebrna kula do pełnej automatyzacji – wciąż wymaga nadzoru i walidacji – ale stanowi ważny krok w stronę otwartych, samodzielnie hostowanych systemów ekstrakcji. Warto śledzić rozwój tego segmentu, bo z każdą wersją takie modele będą coraz bliżej poziomu komercyjnych API.