GLiFormer: 91,1% F1 w ekstrakcji JSON bez generatora tokenów

Model GLiFormer-large v1 o 575,6 mln parametrów osiąga wynik 91,10% F1 w ekstrakcji JSON, eliminując ryzyko halucynacji tekstowych wartości dzięki zakotwiczeniu pól w tekście źródłowym. Rezygnacja z sekwencyjnego generowania tokenów skraca medianę opóźnienia na GPU do 69 ms, tworząc wydajną alternatywę dla modeli LLM w potokach ETL. Otwarta licencja Apache 2.0 pozwala na pełną lokalną instalację i przetwarzanie wrażliwych danych bez udziału zewnętrznych API.

Mechanizm architektoniczny i deterministyczny montaż JSON

Architektura GLiFormer rozwiązuje problem wysokich opóźnień oraz błędów składniowych w generowaniu ustrukturyzowanych danych przez autoregresywne modele językowe. Zamiast sekwencyjnego wypisywania cudzysłowów, nawiasów i kluczy, model wykorzystuje wspólny enkoder DeBERTa oraz uniwersalne wektory kotwic do równoległego rozpoznawania encji, klasyfikacji i rekonstrukcji rekordów. Taki potok eliminujący generowanie tokenów wyjściowych znacząco przyspiesza automatyzację.

Samo przetwarzanie dokumentu w architekturze Knowledgator GLiFormer przebiega w czterech precyzyjnych etapach:

  1. Ugruntowanie pól (field grounding): model identyfikuje wartości w tekście źródłowym jako bezpośrednie fragmenty znakowe (spans), przypisując im współrzędne oraz etykiety schematu.
  2. Przypisanie do rekordów (record assignment): wyekstrahowane fragmenty trafiają do nieuporządkowanych gniazd rekordów z wykorzystaniem algorytmu dopasowania węgierskiego (Hungarian matching) podczas treningu.
  3. Predykcja hierarchii (hierarchy prediction): model wyznacza skierowane relacje nadrzędności i podrzędności (parent-child links) ograniczone wyłącznie do ścieżek dozwolonych przez schemat JSON.
  4. Deterministyczny montaż (assembly): dedykowany dekoder składa wyliczone relacje i wartości w poprawny obiekt JSON bez udziału głowicy generującej tekst.

Dzięki temu wartości wyjściowe są fizycznie wycinane z dokumentu. Konstrukcja ta wyklucza zmyślanie ciągów znaków czy wprowadzanie błędnych literówek w wyekstrahowanych polach. Model GLiFormer-base opiera się na 12-warstwowym enkoderze DeBERTa o 264,2 mln parametrów, z kolei wariant GLiFormer-large v1 mieści 575,6 mln parametrów i wykorzystuje 24-warstwowy enkoder. Oba warianty zostały wytrenowane na zbiorze 100 miliardów tokenów oraz przeszły dwuetapowe dostrajanie obejmujące 1,35 mln przykładów wielozadaniowych i 372 tys. przykładów dziedzinowych.

Czym GLiFormer różni się od tradycyjnych modeli LLM?

Tradycyjne modele językowe traktują ekstrakcję ustrukturyzowaną jako zadanie zamiany tekstu na tekst, co wywołuje wysokie koszty obliczeniowe oraz ryzyko błędu wartości. Model GLiFormer separuje wykrywanie wartości w tekście od budowania hierarchii rekordów, wykonując tylko jedno kodowanie dokumentu źródłowego dla wielu schematów. Pozwala to na jednoczesne wykonywanie wielu zadań informacyjnych.

W potokach automatyzacji danych (ETL) kluczową barierą modeli generatywnych, takich jak Deepseek-R1 czy Gemma3, jest podatność na błędy nieprawidłowych wartości (Wrong Value – WV). Jak pokazują badania benchmarku LLMStructBench, błędy wartości stanowią od 97% do 100% wszystkich niepowodzeń w średnich i dużych modelach LLM. Nawet zastosowanie wymuszonego dekodowania ze schematem JSON (podejście PJ+) usuwa jedynie błędy składniowe, przesuwając całą niepewność modelu na błędne wartości merytoryczne.

Cecha architektury Enkoder Knowledgator GLiFormer-large Autoregresywny LLM (np. Gemma3-12B / GPT-5-mini)
Liczba parametrów 575,6M 12B – 120B
Formowanie wyjścia JSON Deterministyczny dekoder ze skryptu Sekwencyjna autoregresja tokenów
Generowanie tokenów 0 tokenów wyjściowych Generowanie całej struktury i tekstu
Halucynacja tekstu wartości Niemożliwa (spans z tekstu) Częsta (błędy typu Wrong Value)
Koszt operacyjny API 0 zł (wdrożenie lokalne) Opłaty za tokeny wejściowe i wyjściowe

Rozdzielenie ugruntowania pól od składni JSON sprawia, że model GLiFormer wykonuje operację macierzową na ustalonym buforze 100 kotwic rekordowych oraz oknie rozpiętości do 12 wyrazów. Zamiast tworzyć struktury danych od zera, model dopasowuje kontekst wejściowy do zdefiniowanego schematu Pydantic lub słownika Python.

Wydajność obliczeniowa, opóźnienia i koszty infrastruktury

Przetwarzanie dokumentów biznesowych w czasie rzeczywistym wymaga niskich opóźnień oraz przewidywalnego zużycia zasobów sprzętowych. Model GLiFormer-base osiąga medianę czasu odpowiedzi na poziomie 69 ms na karcie graficznej GPU oraz 547 ms na ośmiowątkowym procesorze CPU. Taka wydajność umożliwia przeniesienie obciążeń z kosztownych chmurowych interfejsów API do lokalnej infrastruktury firmowej.

Pomiary czasu wykonania przeprowadzone na stanowisku z kartą NVIDIA RTX PRO 6000 Blackwell (FP16) oraz procesorem AMD EPYC 9B45 (FP32) pokazują skalowanie opóźnień w zależności od głębokości struktury JSON:

  • Głębokość JSON 3 (175 tokenów wyjściowych): 64,3 ms na GPU oraz 374,1 ms na CPU.
  • Głębokość JSON 4 (243 tokeny wyjściowe): 56,7 ms na GPU oraz 488,4 ms na CPU.
  • Głębokość JSON 5 (522 tokeny wyjściowe): 108,6 ms na GPU oraz 709,8 ms na CPU.
  • Głębokość JSON 6 (778 tokenów wyjściowych): 140,3 ms na GPU oraz 890,4 ms na CPU.
  • Średnia całkowita: 92,5 ms na GPU oraz 615,7 ms na CPU.

Analityczne szacunki narzutu modeli autoregresywnych przy założeniu przepustowości 2000 tokenów/s dla prefiksu i 60 tokenów/s dla generowania pokazują, że potok GLiFormer na GPU działa do 95,8 razy szybciej od tradycyjnego generowania tekstu. Ograniczenie wydatków na infrastrukturę idzie w parze z bezpieczeństwem danych: biblioteka instaliwalna komendą pip install gliformer uruchamia się w pełni na lokalnym sprzęcie bez wysyłania treści do zewnętrznych chmur.

Ocena dokładności w benchmarkach NER, klasyfikacji i relacji

Wszechstronność modelu GLiFormer pozwala na realizację pięciu osobnych zadań w ramach jednego przesunięcia enkodera, jednak jego skuteczność różni się w zależności od domeny. W benchmarku ustrukturyzowanym model GLiFormer-large osiąga wynik 91,10% F1, zbliżając się do komercyjnego GPT-5.6-luna z wynikiem 91,96% F1. Z kolei w ekstrakcji relacji i wybranych domenach NER model wykazuje istotne ograniczenia.

W teście hierarchicznej ekstrakcji JSON na próbie 500 złożonych dokumentów warianty GLiFormer wykazują wysoką odporność na poziom zagłębienia schematu:

  • GLiFormer-large v1: średni wynik 91,10% F1 (89,94% dla głębokości 3; 95,11% dla głębokości 4; 91,69% dla głębokości 5; 92,80% dla głębokości 6+).
  • GLiFormer-base v1: średni wynik 87,20% F1.
  • GPT-5.6-luna: średni wynik 91,96% F1.
  • GPT-5-mini: średni wynik 82,56% F1.
  • Qwen3.5 9B: średni wynik 78,50% F1.

W wielozadaniowych testach klasyfikacji (13 zbiorów danych, 79 828 przykładów) GLiFormer-large uzyskuje średni wynik 75,03% macro-F1, przewyższając model GLiNER2.5 z wynikiem 64,89%. Model wyróżnia się w wykrywaniu spamu Enron (97,95% macro-F1) oraz analizie tekstu finansowego Financial Phrasebank (96,77% macro-F1). Traci jednak skuteczność przy wieloklasowym badaniu emocji Emotion (48,07% macro-F1) czy sprawozdaniach politycznych SOTU (49,00% macro-F1).

W klasycznym rozpoznawaniu encji nazwanych (26 zbiorów NER, 131 156 przykładów) model GLiFormer-large osiąga średnią ścisłą F1 na poziomie 50,91%. Wyniki wahają się od 80,16% F1 na zbiorze WikiNeural i 71,48% F1 na CrossNER politics do zaledwie 13,81% F1 na zbiorze medycznym HarveyNER. Najsłabszym punktem architektury pozostaje ekstrakcja relacji, gdzie średni wynik micro-F1 na czterech benchmarkach wynosi 21,33% (DocRED: 12,78%, CrossRE: 12,61%, FewRel: 24,08%).

Ograniczenia techniczne, podatności i ryzyka architektoniczne

Integracja architektury GLiFormer w produkcyjnym stosie technologicznym wymaga uwzględnienia sztywnych limitów sprzętowych oraz specyfiki oceniania. Choć model tworzy bezbłędną składnię JSON, nie gwarantuje prawidłowego przypisania rekordów ani bezbłędnej identyfikacji granic fraz w skomplikowanych dokumentach. Wykorzystanie sztywnych buforów kotwic nakłada również fizyczne ograniczenia na złożoność przetwarzanych formularzy.

Inżynierowie wdrożeniowi muszą zwrócić uwagę na cztery kluczowe ryzyka techniczne:

  1. Interpretacja wyników ustrukturyzowanych: wysoki wskaźnik 91,10% F1 opiera się na metryce bezporządkowego dopasowania ścieżek z tolerancją graniczną (order-free, boundary-tolerant matching), a nie na dokładnym odzwierciedleniu całego obiektu (exact JSON match).
  2. Fizyczne limity enkodera: punkty kontrolne v1 posiadają sztywno skonfigurowane maks. 100 kotwic rekordowych (record anchors) oraz maksymalną szerokość rozpiętości frazy wynoszącą 12 wyrazów (max_span_width). Przekroczenie tych wartości prowadzi do bezpowrotnego odrzucenia nadmiarowych encji.
  3. Kontekst trenowania i brak generowania: chociaż architektura wspiera kontekst do 16 384 tokenów, model nie posiada zdolności generowania swobodnego tekstu (np. pisania podsumowań, wyjaśnień czy syntezy wniosków).
  4. Wymóg interfejsu relacji: w punktach kontrolnych v1 brakuje otwartej głowicy relacyjnej, co wymusza stosowanie metody wywołania joint_relations łączącej nazwy encji i relacji zamiast funkcji predict_relations.

Walidacja klasami Pydantic w bibliotece GLiFormer weryfikuje wyłącznie poprawność typu i typową strukturę drzewa JSON. Nie stanowi ona jednak merytorycznego potwierdzenia prawdy – błędy w przypisaniu węzła nadrzędnego mogą nadal generować błędne przypisania w bazach relacyjnych.

Wnioski praktyczne i rekomendacje

  • Skonfiguruj lokalne środowisko uruchomieniowe w systemie Linux z wykorzystaniem biblioteki gliformer (pip install gliformer -U) oraz opcjonalnych jąder CUDA [flash], aby wyeliminować koszty zewnętrznych API i zabezpieczyć poufne dokumenty.
  • Zmierz czas przetwarzania oraz zużycie pamięci VRAM/RAM dla firmowych formularzy, sprawdzając, czy stały limit 100 kotwic rekordowych oraz 12-wyrazowe okno wycinania fraz odpowiadają gęstości danych w Twoich potokach.
  • Zweryfikuj dokładność wyekstrahowanych wartości za pomocą zewnętrznych reguł biznesowych lub hybrydowego weryfikatora, mając na uwadze, że walidacja Pydantic sprawdza jedynie typy i obecność pól, a nie poprawność faktów.
  • Wdróż funkcję joint_relations w miejsce otwartych metod wykrywania relacji, przekazując etykiety encji i połączeń w jednym wywołaniu schema-driven dla potoków ekstrakcji grafów wiedzy.

Źródła

Przemysław Majdak

Przemysław Majdak · AI Automation Engineer

Założyciel Baluarte i wydawca BitBiz.pl. Członek ISSA Polska. Ekspert z 18-letnim stażem w branży IT — wdraża bezpieczne automatyzacje AI, systemy full-stack i zaawansowane procedury cyberbezpieczeństwa dla firm. Wszystkie artykuły autora →

2 odpowiedzi

💬 Kliknij tutaj, aby dodać komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

  1. Awatar KasiaZpodlasia
    KasiaZpodlasia

    Ekstrakcja danych bez LLM to świetna optymalizacja kosztów, ale co się stanie, gdy struktura wejściowa choć trochę odbiegnie od sztywnego schematu, do którego wytrenowano model? Czy nie zamieniamy elastyczności, którą daje generatywna sztuczna inteligencja, na konieczność kosztownego douczania modelu przy każdej zmianie w formacie danych?

  2. Awatar prof.Andrzej
    prof.Andrzej

    Automatyzacja ekstrakcji danych bez udziału LLM to powrót do deterministycznych silników regułowych opakowanych w nowocześniejszą architekturę neuronową. To dokładnie ten sam proces, który w latach dziewięćdziesiątych wyparł próby zastąpienia statystyki systemami ekspertowymi.