Przewodnik po NER 2026: GLiNER, spaCy, Transformers i LLMs
Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.
Aktualizacja artykułu
Pierwotnie opublikowano 2 kwietnia 2026 r. Przegląd i aktualizację przeprowadzono 6 września 2026 r. Aktualizacja obejmuje nowsze modele GLiNER, strumieniowe wykrywanie PII, API do ekstrakcji ustrukturyzowanych danych oraz interpretację benchmarków.
Rozpoznawanie nazwanych encji (NER) zamienia tekst na oznaczone fragmenty, których może używać program. Dla zdania „Bill Gates founded Microsoft on April 4, 1975” może zwrócić spójne fragmenty tekstu Bill Gates, Microsoft i April 4, 1975 o typach osoba, organizacja i data. W encoderze opartym na spanach, takim jak GLiNER, model odczytuje tekst raz i ocenia kandydackie spany względem dostarczonych etykiet. Wybór systemu NER oznacza decyzję, jakiego poziomu opóźnienia, kosztu, elastyczności etykiet i rozumowania wymaga dana ekstrakcja.
Repozytorium towarzyszące zawiera przykłady smoke testów dla GLiNER, eksportu do ONNX, generowania adnotacji i ekstrakcji ustrukturyzowanych danych. Porównanie oparte na trzech zdaniach nie jest rankingiem modeli: scorer scala powtarzające się pary tekst/typ i może pomijać końcowe dokumenty gold, gdy brakuje predykcji. Skrypt nauczyciela nie zawiera też zademonstrowanej konwersji do zweryfikowanych spanów treningowych. Używaj tych przykładów do analizy API, a nie do twierdzenia, że przedstawiają kompletny workflow treningu lub ewaluacji. W workloadach zdominowanych przez jawne spany kompaktowe encodery są zwykle szybszą i tańszą opcją. LLM-y nadal są przydatne do generowania danych treningowych oraz obsługi przypadków wymagających inferencji lub normalizacji. Sekcje dotyczące benchmarków wyjaśniają opublikowane porównania i ich ograniczenia; żaden z nich nie jest nowym uruchomieniem benchmarku na potrzeby tego przewodnika.
W przypadku pipeline’u wyszukiwania lub prywatności najpierw zadałbym pytanie, czy dane wyjściowe muszą być dosłowną wzmianką z tekstu. Ta decyzja rozdziela recognizer spanów od systemów, które dodatkowo normalizują wartości, łączą rekordy lub wyciągają fakty.
Repozytorium towarzyszące: ner-field-guide z uruchamialnymi demonstracjami GLiNER, eksportu do ONNX, pipeline’u LLM-as-teacher oraz ekstrakcji ustrukturyzowanych danych z użyciem Instructor.
Krótkie porównanie modeli znajdziesz tutaj: Najlepsze modele NER w 2026 r..
Czym jest rozpoznawanie nazwanych encji?
Rozpoznawanie nazwanych encji wyszukuje spany w tekście i przypisuje im typy, takie jak osoba, organizacja, data, produkt lub etykiety specyficzne dla domeny. Span to spójny fragment oryginalnego tekstu. NER identyfikuje wzmiankę; entity linking jest osobnym krokiem, który przypisuje ją do kanonicznego rekordu lub pojęcia z ontologii.
| Obciążenie | Pierwszy model do przetestowania | Eskaluj, gdy |
|---|---|---|
| Identyfikatory lub kontrolowane słowniki | Reguły lub spaCy EntityRuler | Istotny jest recall poza znanymi wzorcami. |
| Stabilne etykiety i dużo danych treningowych | spaCy lub fine-tuned encoder | Zestaw etykiet się zmienia albo recall dla rzadkich typów stoi w miejscu. |
| Zmienne etykiety; mały zbiór typów | GLiNER cross-encoder | Zbiór typów rośnie albo etykiety są ponownie wykorzystywane w wielu dokumentach. |
| Duży, wielokrotnego użytku zbiór typów | GLiNER bi-encoder | Zbiór domenowy wykazuje regresję jakości lub kalibracji. |
| Kilka zadań ekstrakcji w jednym pipeline’ie tekstowym | GLiNER2.5 | Jakość dla zadań łączonych nie osiąga celu określonego dla poszczególnych zadań. |
| Fakty niejawne lub rozumowanie nad schematem | Structured LLM extraction | Opóźnienie, koszt lub niepoparte twierdzenia przekraczają budżet produktu. |
Gdzie współczesne systemy wykorzystują NER
NER nadal wyszukuje fragmenty tekstu i przypisuje im etykiety. Zmieniła się natomiast jego pozycja w systemie. Obecnie dostarcza filtrów dla RAG, ustrukturyzowanych argumentów dla narzędzi agentów oraz pól dla pipeline’ów przetwarzania dokumentów. Zastosowania te sprawiają, że równie ważne jak dokładność benchmarkowa są opóźnienie, koszt i elastyczność schematu.
RAG: lepsze wyszukiwanie dzięki ekstrakcji encji
Samo wyszukiwanie podobieństwa ma problemy, gdy pytanie zawiera dokładne encje. W przypadku pytania „co Anthropic powiedział o bezpieczeństwie modeli w 4. kwartale 2024 roku?” ekstrakcja encji może zaproponować „Anthropic” i „4. kwartał 2024” jako filtry. Twardy filtr stosuj tylko wtedy, gdy indeksowane metadane i semantyka dat to obsługują; w przeciwnym razie użyj go jako sygnału rankingowego albo zachowaj ścieżkę wyszukiwania bez filtrów. Pominięty alias lub nieprawidłowo wywnioskowany zakres dat może wykluczyć odpowiedź.
Podczas indeksowania wyodrębniasz encje z każdego fragmentu i zapisujesz je jako metadane: {"organizations": ["Anthropic"], "dates": ["Q4 2024"], ...}. Umożliwia to filtrowanie po encji przed uruchomieniem wyszukiwania wektorowego. Knowledge graph RAG (GraphRAG, grafy właściwości LlamaIndex) dodaje nazwane relacje, za którymi wyszukiwanie może podążać przez kilka poziomów. Porównaj to podejście z powtarzanymi wyszukiwaniami wektorowymi na pytaniach i korpusie, które musisz obsługiwać.
W czasie obsługi zapytania encje wyodrębnione z pytania użytkownika sterują routingiem. Pytanie zawierające nazwę firmy trafia do indeksu finansowego, a pytanie zawierające nazwy leków — do klinicznej bazy wiedzy. GLiNER jest przydatny, gdy zmienia się schemat lub typy encji w czasie zapytania. Same nieznane nazwy firm lub leków nie wymagają etykiet open-vocabulary; model z zamkniętym zestawem etykiet nadal może rozpoznawać nowe wzmianki o znanych typach.
Agenci AI: przekształcanie tekstu w ustrukturyzowane fakty
Agenci otrzymują nieustrukturyzowany tekst, taki jak strony internetowe, odpowiedzi API i wiadomości użytkowników. NER przekształca ten tekst w ustrukturyzowane fakty, nad którymi agent może rozumować, które może przechowywać lub przekazywać do narzędzi.
Dla routingu narzędzi żądanie takie jak „zaplanuj spotkanie z Sarah Chen z Accenture w czwartek o 14:00” może wygenerować PERSON: Sarah Chen, ORGANIZATION: Accenture, DATE: Thursday oraz TIME: 2pm. Resolver kalendarza łączy następnie datę i godzinę w znacznik czasu wymagany przez API. Lokalny encoder pomija podróż do API i często działa znacznie szybciej, ale opóźnienie zależy od modelu, runtime’u, sprzętu, rozmiaru batcha i liczby etykiet. Zmierz obie ścieżki na danych zadań kalendarzowych, zamiast zakładać stałą różnicę wyrażoną w milisekundach.
NER obsługuje również śledzenie encji w obrębie rozmów. Systemy pamięci agenta muszą wiedzieć, że „Sarah” w turze 3 i „Ms. Chen” w turze 12 oznaczają tę samą osobę. NER identyfikuje spany, a rozpoznawanie koreferencji rozstrzyga, czy wzmianki odnoszą się w danym kontekście do tej samej osoby. Entity linking mapuje następnie tę osobę na rekord kanoniczny, jeśli taki rekord istnieje.
W obu przypadkach ograniczeniem jest opóźnienie. Jeśli każdy z dziesięciu sekwencyjnych kroków wykonuje wywołanie NER trwające 200 ms, te wywołania NER dodają łącznie 2 sekundy odczuwalnego opóźnienia. Jedno wywołanie dodaje 200 ms. Modele encoderowe zwykle lepiej mieszczą obsługę encji w pętlach agenta niż ekstrakcja oparta na LLM.
Inteligencja dokumentów: od obrazów do ustrukturyzowanych danych
OCR przekształca obrazy w tekst. NER przekształca ten tekst w ustrukturyzowane pola.
Standardowy pipeline najpierw używa OCR, takiego jak Tesseract, Azure Document Intelligence lub AWS Textract, aby wygenerować tekst i bounding boxy. Następnie NER wyszukuje spany dla pól takich jak invoice_number, vendor_name, total oraz due_date. Krok oparty na schemacie lub ekstrakcji relacji musi pogrupować opisy pozycji, ilości i ceny w line_items. Ta sama sekwencja ma zastosowanie do umów, dokumentacji medycznej i dokumentów regulacyjnych.
Nowoczesne pipeline’y przetwarzania dokumentów mogą łączyć rozumienie układu, ekstrakcję encji i ekstrakcję relacji. OCR lub model dokumentowy uwzględniający układ nadal dostarcza tekst, kolejność czytania, tabele i bounding boxy. Obecny GLiNER2.5 udostępnia encje, relacje, klasyfikację i ustrukturyzowane rekordy za pośrednictwem interfejsu schematu. Oceniaj każde wyjście osobno; starsza publikacja GLiNER2 nie obejmowała benchmarkiem każdego zadania udostępnianego obecnie przez bibliotekę.
O kosztach większości tych pipeline’ów decyduje skala. Wyceń swoje rozwiązanie na podstawie rzeczywistego miesięcznego wolumenu dokumentów, uwzględniając ponowienia i weryfikację. Kompaktowy encoder może działać na CPU, podczas gdy LLM dostępny przez API generuje koszt inferencji i opóźnienie dla każdego dokumentu. Praktyczny test polega na oznaczeniu reprezentatywnego zbioru faktur za pomocą LLM. Dostrój GLiNER na zweryfikowanych rekordach, a następnie porównaj obie ścieżki pod kątem F1 na poziomie pól, opóźnienia i całkowitego kosztu.
Wykrywanie PII i mechanizmy ochronne LLM
Zasady ochrony danych i obowiązki dotyczące bezpieczeństwa wynikające z GDPR (art. 5, 25 i 32), neutralne technologicznie wymagania Security Rule w HIPAA (wytyczne HHS) oraz kalifornijska ustawa CCPA z późniejszymi zmianami wprowadzonymi przez CPRA ustanawiają różne prawa i zabezpieczenia oparte na ryzyku. Przywołane przepisy nie wymagają użycia NER ani konkretnej architektury skanowania przed modelem. To nie jest porada prawna; skonsultuj z prawnikiem wymagania mające zastosowanie do Twoich danych i jurysdykcji. NER może wspierać inwentaryzację danych, minimalizację lub deidentyfikację, ale jest tylko jednym z mechanizmów kontrolnych, a jego recall trzeba zweryfikować dla odpowiednich danych i jurysdykcji.
NER obsługuje ten przypadek bezpośrednio. Modele deidentyfikacji wykrywają fragmenty PERSON, SSN, PHONE, EMAIL i ADDRESS, a następnie je redagują albo zastępują syntetycznymi odpowiednikami. Microsoft Presidio łączy recognizery z operatorami anonimizacji, a jego przykłady obejmują GLiNER jako recognizer. Innym kandydatem jest GLiNER2-PII o 0,3 mld parametrów: w publikacji opisano 42 typy PII rozpoznawane na poziomie fragmentów znakowych. Żadne z tych rozwiązań nie stanowi dowodu zgodności. Przed użyciem dowolnego detektora jako mechanizmu kontrolnego zweryfikuj recall według formatu danych, jurysdykcji, języka i klasy PII.
W porównaniu przeprowadzonym przez dostawcę, John Snow Labs wykorzystano 48 dokumentów opatrzonych adnotacjami ekspertów, obejmujących sześć klas PHI. Etykiety dostawców zostały zmapowane ponownie, a predykcje bez mapowania wykluczono, co ogranicza możliwość interpretacji porównań między dostawcami. Raport Providence opisuje 281 zdarzeń wycieku PHI w przeglądzie 1000 notatek zawierających 34 701 zdań. Zdarzenia nie odpowiadają liczbie odrębnych zdań, których dotyczył wyciek: w ewaluacji prywatności zliczaj zarówno ujawnione wystąpienia, jak i dotknięte dokumenty.
W przypadku mechanizmów ochronnych LLM NER działa jako warstwa wstępnego filtrowania: skanuj dane wejściowe użytkownika pod kątem PII przed wysłaniem ich do zewnętrznego API, a następnie je blokuj lub anonimizuj. Może to być szybsze albo prostsze niż proszenie LLM o samodzielne moderowanie. Traktuj to jako hipotezę wdrożeniową: zmierz obie ścieżki dla swojego modelu, sprzętu, profilu danych wejściowych i docelowego recall. Fałszywie ujemne wyniki są nadal możliwe, dlatego dodaj kolejny mechanizm kontrolny odpowiedni do poziomu ekspozycji PII, którego Twój system nie może zaakceptować. GLiNER jest tu szczególnie użyteczny, ponieważ kategorie PII różnią się w zależności od jurysdykcji. API może przyjąć nową etykietę, taką jak „informacje genetyczne”, bez ponownego trenowania. Nie oznacza to jednak, że recall dla nowej kategorii jest znany; przed poleganiem na takim rozwiązaniu zweryfikuj go na przejrzanych przykładach.
GLiNER: dopasowywanie fragmentów do etykiet w NER z otwartym słownikiem
GLiNER (NAACL 2024, Zaratiana i in.) sprawił, że NER oparty na encoderze stał się konkurencyjny wobec LLM przy ułamku ich kosztu. Zamiast traktować NER jako etykietowanie sekwencji lub generowanie tekstu, GLiNER traktuje go jako problem dopasowania. Ocenia każdy kandydujący fragment tekstu (każdą spójną sekwencję słów, taką jak „Bill Gates” lub „Microsoft”) względem każdego typu etykiety encji, a następnie zachowuje pary z wysokim wynikiem.
Model przyjmuje etykiety typów encji i tekst wejściowy jako jedną sekwencję: [ENT] person [ENT] organization [ENT] date [SEP] Bill Gates founded Microsoft.... Dwukierunkowy transformer (DeBERTa-v3) koduje je wspólnie.
Na podstawie danych wyjściowych model tworzy dwa zbiory reprezentacji. Pierwszy dopracowuje reprezentację każdego typu encji na podstawie pozycji tokenu [ENT], przepuszczając wektor enkodera przez niewielką sieć feed-forward (FFN). Drugi reprezentuje fragmenty tekstu, łącząc wektory słów na początku i końcu fragmentu za pomocą kolejnej sieci FFN. Iloczyn skalarny reprezentacji fragmentu i reprezentacji typu encji daje wynik.
Po zastosowaniu funkcji sigmoid otrzymujemy prawdopodobieństwo, że fragment od pozycji słowa do pozycji słowa należy do typu encji : . Tutaj to wektor fragmentu utworzony przez FFN, a to dopracowany przez FFN embedding typu encji z odpowiadającego mu tokenu [ENT] (Zaratiana et al., 2024, równania 1–2). Liczba kandydackich fragmentów jest ograniczona do 12 słów; tokenizer może podzielić jedno słowo na kilka tokenów subword.
GLiNER przyjmuje opisy etykiet w języku naturalnym podczas inferencji, bez ponownego trenowania, ale jakość ekstrakcji zależy od sformułowania etykiet i ich dopasowania do domeny. Przekazujesz typy encji, takie jak „osoba”, „działanie niepożądane leku” lub „instrument finansowy”, a model ocenia fragmenty względem tych typów. Wymienione poniżej konfiguracje 50M, 90M i 300M to modele z oryginalnej publikacji. Karta modelu v2.1 wymienia natomiast angielskie checkpointy o rozmiarach 166M, 209M i 459M oraz wielojęzyczny checkpoint 209M — wszystkie na licencji Apache 2.0. Nie należy porównywać opóźnienia ani zużycia pamięci między tymi generacjami tak, jakby nazwy parametrów były identyczne (karta modelu GLiNER v2.1).
Aby przeprowadzić rzeczywisty test hard zero-shot, należy wyłączyć ze zbioru zarówno docelowe typy, jak i przykłady docelowe: model nie ma żadnych oznaczonych przykładów dla docelowego zadania. Opis typu, taki jak „medycznie potwierdzony skutek uboczny wywołany przez leczenie”, przekazuje modelowi więcej informacji niż samo adverse event. Nie gwarantuje to transferu, ale ZeroNER sterowany opisami osiągnął lepsze wyniki niż baseline’y korzystające wyłącznie z nazw w benchmarkach z wyłączonymi typami (Cocchieri et al., 2025).
Dane treningowe dla oryginalnego modelu pochodziły ze zbioru Pile-NER: 44 889 fragmentów zawierających 240 tys. fragmentów encji należących do 13 tys. typów encji, wszystkie oznaczone przez ChatGPT. Trenowanie GLiNER-L zajęło około 5 godzin na pojedynczym A100 (Zaratiana et al., 2024).
Wyniki benchmarków
Wyniki zero-shot z pracy Zaratiana et al. (2024), tabele 1 i 2. F1 łączy precision i recall w jeden wynik; wyższy wynik jest lepszy tylko przy tym samym zadaniu i tych samych zasadach ewaluacji. Średnia z siedmiu zbiorów łączy pięć zbiorów CrossNER ze zbiorami MIT Movie i MIT Restaurant:
| Model | Parametry | Średni F1 (CrossNER + MIT) | Średni F1 (20 zbiorów danych) |
|---|---|---|---|
| GLiNER-L | 300M | 60,9% | 47,8% |
| GoLLIE | 7B | 58,0% | — |
| UniNER-13B | 13B | 55,6% | — |
| GLiNER-M | 90M | 55,4% | — |
| UniNER-7B | 7B | 53,7% | 45,7% |
| GLiNER-S | 50M | 52,7% | — |
| ChatGPT (GPT-3.5) | — | 47,5% | 36,5% |
GLiNER-M z 90M parametrów niemal dorównuje UniNER-13B w średniej dla siedmiu zbiorów danych podanej w artykule (55,4% vs 55,6% F1), wykorzystując około 140 razy mniej parametrów. GLiNER-S z 50M parametrów przewyższa raportowany wynik ChatGPT (GPT-3.5) o 5 punktów F1. Wariant wielojęzyczny, trenowany wyłącznie na danych anglojęzycznych, przewyższa tę samą bazową wersję ChatGPT w 8 z 10 języków innych niż angielski (Zaratiana et al., 2024). Porównania te wykorzystują wersje modeli i harness ewaluacyjny z artykułu; nie ustanawiają rankingu względem nowszych LLM-ów.
Warianty GLiNER obejmują teksty biomedyczne, wykrywanie PII, wiadomości oraz obsługę wielojęzyczną.
Materiał towarzyszący zachowuje wersję v2.1 w quickstarcie. W nowym porównaniu cross-encoderów uwzględnij obok niej także utrzymywane checkpointy GLiNER v2.5; numery wersji nie są dowodem na wzrost F1 w konkretnej domenie. GLiNER v2.5 i Fastino GLiNER2.5 poniżej to różne rodziny modeli.
Z scripts/01_gliner_quickstart.py:
from gliner import GLiNER
model = GLiNER.from_pretrained("urchade/gliner_medium-v2.1")
text = "Bill Gates founded Microsoft on April 4, 1975."
labels = ["person", "organization", "date"]
entities = model.predict_entities(text, labels, threshold=0.5)
for entity in entities:
print(f" {entity['text']} => {entity['label']}")
# Bill Gates => person
# Microsoft => organization
# April 4, 1975 => date
Jak GLiNER wypada w porównaniu ze spaCy
spaCy to jedna z najbardziej ugruntowanych bibliotek NLP używanych produkcyjnie. Działa również przy innych ograniczeniach architektonicznych niż GLiNER.
Pipeline’y spaCy (en_core_web_sm, en_core_web_trf) wykonują NER ze słownikiem zamkniętym: używają stałego zestawu typów encji (PERSON, ORG, GPE, DATE itd.) zdefiniowanego podczas trenowania. Rozszerzenie wytrenowanego komponentu ner wymaga oznaczonych przykładów i trenowania. W przypadku identyfikatorów lub kontrolowanego słownika EntityRuler może dodawać niestandardowe etykiety za pomocą wzorców bez ponownego trenowania; sprawdź jego recall poza tymi wzorcami. Przypnij utrzymywaną paczkę modelu 3.8, zamiast zakładać, że niewydana główna linia wersji jest ulepszeniem gotowym do użycia produkcyjnego. Karta modelu en_core_web_trf 3.8.0 podaje 90,19 NER F1 na OntoNotes 5.0, ale tylko dla jego 18 predefiniowanych typów (karta modelu spaCy).
GLiNER wykonuje NER z otwartym słownikiem: przyjmuje tekst nowych etykiet podczas inferencji bez ponownego trenowania. Nie gwarantuje to użytecznej ekstrakcji dla każdej etykiety; nadal znaczenie mają sformułowanie i dopasowanie do domeny. To mocny kandydat, gdy typy encji nie są z góry znane, często się zmieniają lub są specyficzne dla domeny („adverse drug reaction”, „financial instrument”, „threat indicator”).
Moja rekomendacja: używaj spaCy dla standardowych typów encji, gdy pretrained pipelines zostały dobrze zwalidowane. Wybierz GLiNER, gdy potrzebujesz elastycznych typów zero-shot lub gdy pipeline musi dostosowywać się bez ponownego trenowania. Można połączyć je w jednym pipeline: spaCy będzie odpowiadać za tokenizację i podział na zdania, a GLiNER za ekstrakcję encji.
Nadzorowany baseline oparty na Transformerze
W przypadku stabilnych etykiet i reprezentatywnych, adnotowanych spanów zacznij od fine-tuned token classifier, takiego jak RoBERTa lub DeBERTa, jako nadzorowanego baseline’u. Zyskujesz dokładność specyficzną dla zadania kosztem elastyczności etykiet. Porównaj go ze spaCy i GLiNER pod kątem exact-span F1, recallu dla poszczególnych etykiet, kalibracji, opóźnienia i kosztu, używając tego samego zbioru danych domenowych.
UniNER i NuNER: jak mały może być model?
UniNER (ICLR 2024, Zhou et al.) i NuNER (EMNLP 2024, Bogdanov et al.) destylują adnotacje LLM do mniejszych modeli NER — ale różnią się oceną tego, jak mały może być taki model.
UniNER: podejście maksymalistyczne
UniNER fine-tunuje LLaMA-7B/13B na 45 889 parach input-output wygenerowanych przez ChatGPT. Dla każdego typu encji model odpowiada na pytanie „Co opisuje [typ] w tekście?” i zwraca listy JSON. Kluczowy trik treningowy: frequency-based negative sampling zwiększa F1 z 31,5% do 53,4% (Zhou et al., 2024).
UniNER-7B osiąga 41,7% zero-shot F1 na 43 zbiorach danych — o 7 punktów procentowych więcej niż ChatGPT, który uzyskuje 34,9%. Wariant 13B osiąga 43,4%, czyli zaledwie o 1,7 punktu więcej przy niemal dwukrotnie większej liczbie parametrów (Zhou et al., 2024).
Kompromis produkcyjny: konfiguracja UniNER-type z wyższym wynikiem odpytuje każdy typ encji sekwencyjnie. Wariant all-in-one używa jednej odpowiedzi, ale uzyskał średnio o 3,3% niższy wynik. Przy FP16 checkpoint 7B potrzebuje około 14 GB wyłącznie na wagi; kwantyzacja do mniejszej liczby bitów może zmniejszyć ten rozmiar. W checkpointcie UniNER-7B-all podano licencję CC BY-NC 4.0; sprawdź konkretny checkpoint zamiast przypisywać tę licencję każdemu wariantowi.
NuNER: podejście minimalistyczne
NuNER bazuje na RoBERTa-base (125 mln parametrów) i wykorzystuje trening kontrastywny z użyciem 4,38 mln adnotacji GPT-3.5 obejmujących 200 tys. konceptów. Po treningu encoder konceptów jest usuwany; encoder tekstu można wstawić do dowolnego standardowego pipeline’u NER jako zamiennik RoBERTa (Bogdanov et al., 2024).
W tabeli 3 pracy dotyczącej NuNER odnotowano około 6,1–16,2 punktu przewagi nad RoBERTa pod względem macro-average token-classification F1, przy zamrożonych encoderach i liniowych headach, na czterech zbiorach danych i dla próbkowanych rozmiarów zbiorów treningowych. Praca porównuje również fine-tuning specyficzny dla zadania z UniNER-7B; osobna dyskusja dotycząca ponad tuzina przykładów odnosi się do in-context learningu GPT-4, a nie do progu pozwalającego dorównać UniNER (Bogdanov et al., 2024).
Obie prace potwierdzają możliwość uczenia się z adnotacji LLM. Nie dowodzą jednak, że dowolny mniejszy model przewyższy swojego nauczyciela w nowej domenie. Zachowaj osobny, niezależnie zweryfikowany zbiór testowy.
GLiNER2 i GLiNER2.5: oddziel publikację od checkpointu
Pierwotny ekosystem GLiNER rozdzielał NER, ekstrakcję relacji, klasyfikację i ekstrakcję na poziomie dokumentu między osobne modele. Opublikowany na EMNLP 2025 artykuł GLiNER2 połączył NER, klasyfikację i hierarchiczną ekstrakcję w jednym modelu z 205 mln parametrów; nowsze wydania dodały później ekstrakcję relacji do tego samego interfejsu schematu.
Architektura z 2025 roku zachowuje konstrukcję cross-encodera, ale rozszerza kontekst do 2048 tokenów (4 razy więcej niż w oryginale) i dodaje deklaratywne schematy do definiowania zadań ekstrakcji. Do trenowania wykorzystano 135 698 rzeczywistych dokumentów z adnotacjami wygenerowanymi przez GPT-4o oraz 118 636 przykładów syntetycznych (Zaratiana et al., 2025).
W ustawieniu zero-shot na CrossNER GLiNER 2 osiąga 0,590 F1, czyli wynik zbliżony do 0,599 dla GPT-4o w śródrocznym benchmarku z 2025 roku opisanym w artykule. W klasyfikacji uzyskuje średnio 0,72 w 7 benchmarkach, w porównaniu z 0,69 dla DeBERTa-v3-large. Dla CPU artykuł podaje opóźnienie klasyfikacji wynoszące 130–208 ms dla testowanej liczby etykiet. Bazowy model zero-shot DeBERTa wymaga osobnego przebiegu inferencji dla każdej kandydackiej etykiety, a czas rośnie z 1714 ms dla 5 etykiet do 16 897 ms dla 50; nie jest to czas działania nadzorowanego klasyfikatora DeBERTa (Zaratiana et al., 2025).
Poniższy przykład ładuje natomiast GLiNER2.5: 194 mln parametrów, architekturę boundary oraz skonfigurowane okno 4096 tokenów. AutoExtractor wybiera BoundaryExtractor; użycie starszego loadera GLiNER2 jest niewłaściwe. Rzadkie parowanie pozycji początku i końca zmienia zakresy poddawane scoringowi, ale nie znosi skończonego limitu kontekstu. W przypadku długich dokumentów używaj udokumentowanych helperów do przetwarzania nachodzących na siebie chunków i sprawdzaj przemapowane offsety. Powyższe wyniki z 2025 roku nie opisują tego checkpointu.
from gliner2 import AutoExtractor
# Requires `pip install gliner2[local]` and downloads the checkpoint.
extractor = AutoExtractor.from_pretrained("fastino/gliner2.5-base-v1")
# Compose tasks through the current schema interface
schema = (extractor.create_schema()
.entities({"person": "Names of people", "company": "Organization names"})
.classification("sentiment", ["positive", "negative", "neutral"])
.relations(["works_for", "founded", "located_in"])
.structure("product_info")
.field("name", dtype="str")
.field("price", dtype="str"))
text = "Acme launched a $19 widget in Berlin."
results = extractor.extract(text, schema)
Nowsze wydania GLiNER2 udostępniają rozpoznawanie encji, klasyfikację, hierarchiczną ekstrakcję i ekstrakcję relacji za pośrednictwem jednego schematu. Artykuł z EMNLP ocenia NER i klasyfikację; nie przedstawia benchmarku hierarchicznej ekstrakcji i nie obejmuje późniejszego API relacji. Traktuj ścieżkę obejmującą cztery zadania jako możliwość wdrożeniową wymagającą benchmarku, a nie jako dowód, że jeden model zachowuje dokładność czterech wyspecjalizowanych modeli.
Nowości z 2026 roku: wybierz architekturę odpowiadającą wąskiemu gardłu
Ekosystem GLiNER obejmuje obecnie różne architektury. Są one kandydatami do porównania domenowego, a nie elementami jednego rankingu.
| Potrzeba | Kandydat | Co zweryfikować |
|---|---|---|
| Wiele wielokrotnego użytku typów encji | GLiNER bi-encoder | F1 dla dokładnych spanów oraz kalibrację po zcache’owaniu embeddingów typów. |
| Encje i relacje w jednym przebiegu | GLiNER-Relex | F1 zarówno dla spanów, jak i relacji na tych samych dokumentach. |
| Lokalny kandydat do wykrywania PII | GLiNER2-PII | Recall według języka, formatu dokumentu i typu PII. |
| Wielojęzyczny kandydat z otwartym słownictwem | GLiNER-X | Jakość dla poszczególnych języków; jego karta modelu wymienia 23 języki. |
| Typy generowane lub zmienne | GLiNER Decoder | Czy generowane typy są stabilne i użyteczne w dalszym przetwarzaniu. |
Oryginalna publikacja GLiNER, publikacja dotycząca bi-encodera oraz GLiNER-Relex korzystają z własnych modeli i harnessów. Karty modeli GLiNER-X i GLiNER Decoder opisują udostępnione checkpointy, ale nie stanowią porównywalnego benchmarku recenzowanego naukowo. Zachowaj to rozróżnienie w architecture decision record.
Streaming PII zmienia się, gdy możesz zwolnić tekst
GLiNER Streaming PII dodaje inkrementalne wykrywanie z wykorzystaniem przyczynowego backbone’u Qwen3-0.6B i cache’owanego stanu sesji. Jego API zwraca pełny bieżący snapshot sesji wraz z offsetami względem zgromadzonego tekstu. Zachowaj granice chunków, utrzymuj etykiety bez zmian do czasu pełnego przeliczenia i usuwaj zakończone sesje. Wymaga GLiNER w wersji 0.2.28 lub nowszej.
W przypadku redakcji strumieniowej buforowałbym tekst, którego jeszcze nie zwolniono, i testował encje podzielone między chunki. Wykrycie numeru telefonu po wysłaniu jego pierwszej połowy nie pozwala wycofać tych bajtów. Mierz liczbę ujawnionych znaków przed zwolnieniem oraz dodatkowe opóźnienie, a także recall końcowych spanów. Karta modelu raportuje osobno masking F2 dla PIIMB i ścisłe typed-span F1; te metryki odpowiadają na różne pytania. Jego słabość w środowisku wielojęzycznym wyklucza również traktowanie udostępnionego checkpointu jako uniwersalnego filtra prywatności.
Licencje checkpointów są częścią wyboru modelu
Przed wdrożeniem zweryfikuj dokładne warunki dotyczące kodu, wag i datasetów. Obecnie cytowane wydania nie są zamienne:
| Wydanie | Licencja opublikowana | Praktyczne konsekwencje |
|---|---|---|
| GLiNER v2.1 i GLiNER bi | Apache 2.0 | Permisywne warunki model card; nadal sprawdź zależności i dane. |
| GLiNER2 i GLiNER2-PII | Apache 2.0 | Potwierdź wybrany checkpoint, a nie tylko bibliotekę. |
| UniNER-7B-all | CC BY-NC 4.0 | Nie używaj w rozwiązaniu komercyjnym bez odrębnej zgody. |
| NuNER | MIT | Opublikowany model i dataset są objęte warunkami MIT. |
Oznaczenia licencji nie stanowią porady prawnej. Przegląd produkcyjny musi obejmować warunki dotyczące modelu bazowego, danych treningowych i dostawcy.
Bi-encoder: skalowanie NER do milionów etykiet
Oryginalny GLiNER koduje etykiety i tekst wspólnie. Wspólne kodowanie staje się coraz droższe, gdy tekst etykiet zajmuje kontekst i musi być kodowany ponownie dla każdego dokumentu. Punkt przecięcia zależy od checkpointu, opisów etykiet i sprzętu. Gdy ten sam duży katalog typów jest używany dla wielu dokumentów, ustaw GLiNER bi-encoder jako domyślny punkt odniesienia. Rozdziela on kodowanie tekstu i etykiet na dwa oddzielne transformatory (Stepanov et al., 2026).
Enkoder tekstu korzysta z ModernBERT (rodzina Ettin), a enkoder etykiet z sentence transformers (BGE lub MiniLM). Spany i etykiety są oceniane za pomocą iloczynu skalarnego. Taki podział oznacza, że embeddingi typów encji można obliczyć raz i buforować. Podczas inferencji zbuforowane etykiety pozwalają uniknąć wielokrotnego kodowania etykiet. Ocena kandydackich spanów względem tych etykiet nadal wymaga mocy obliczeniowej i pamięci; aplikacja z milionem etykiet potrzebuje również ograniczonego wyszukiwania kandydatów lub batchowania, a recall należy mierzyć dla etykiet odrzuconych przed scoringiem.
Dostępne są cztery rozmiary modeli, wszystkie poddane benchmarkom na CrossNER (Stepanov et al., 2026, Tabela 1):
| Model | Parametry | Średnie F1 (CrossNER + MIT) | Przepustowość (H100) | Z wcześniej obliczonymi etykietami |
|---|---|---|---|---|
| gliner-bi-edge-v2.0 | 60M | 54,0% | 13,64 ex/s | 24,62 ex/s |
| gliner-bi-small-v2.0 | 108M | 57,2% | 7,99 ex/s | 15,22 ex/s |
| gliner-bi-base-v2.0 | 194M | 60,3% | 5,91 ex/s | 9,51 ex/s |
| gliner-bi-large-v2.0 | 530M | 61,5% | 2,68 ex/s | 3,60 ex/s |
Przy 1 024 typach encji dwu-enkoder gliner-bi-edge-v2.0 ze wstępnie obliczonymi etykietami traci tylko 5,2% przepustowości względem pojedynczej etykiety (19,3 → 18,3 ex/s). Porównywalny jedno-enkoder gliner_small-v2.5 traci 98,7% (10,7 → 0,14 ex/s). W testach opisanych w publikacji, przeprowadzonych na pojedynczym H100, z rozmiarem batcha równym 1 i wejściami o długości 64, 256 oraz 512 tokenów, dwu-enkoder ze wstępnie obliczonymi etykietami osiąga do 130× większą przepustowość niż gliner_small-v2.5. Przy 100 typach encji na pojedynczym H100 dwu-enkoder przetwarza 1,96 miliona predykcji dziennie, w porównaniu z 368 tys. dla cross-enkodera (Stepanov et al., 2026).
W publikacji dotyczącej dwu-enkodera raportuje się 61,5% dla gliner-bi-large-v2.0 wobec 60,9% dla gliner_large-v2.5, przy tej samej średniej dla CrossNER i MIT. Oryginalna publikacja GLiNER również podaje 60,9%, ale dla innego checkpointu i innej ewaluacji. Porównanie z publikacji dotyczącej dwu-enkodera należy traktować jako wynik opublikowany, a następnie przetestować obie architektury na zbiorze domenowym. Autorzy rekomendują bi-base-v2.0 (194M) jako najlepszy kompromis — osiąga 98% dokładności dużego modelu przy 2,6× większej szybkości (Stepanov et al., 2026).
from gliner import GLiNER
model = GLiNER.from_pretrained("knowledgator/gliner-bi-base-v2.0")
# Pre-compute embeddings for a reused label set; rebuild this cache when labels or the checkpoint change.
entity_types = ["person", "organization", "date"] # Small example; large inventories need bounded candidate selection
entity_embeddings = model.encode_labels(entity_types, batch_size=8)
# Encode text and score spans against the cached labels
texts = ["Bill Gates founded Microsoft on April 4, 1975."]
outputs = model.batch_predict_with_embeds(texts, entity_embeddings, entity_types)
Test porównawczy kończy się na 1 024 etykietach i został przeprowadzony na H100, z rozmiarem batcha równym 1 oraz dziesięcioma przebiegami forward dla każdej konfiguracji. Nie mierzy on wdrożonej usługi obsługującej milion etykiet. Większe inwentarze biomedyczne lub korporacyjne to zastosowania wymagające osobnej ewaluacji; entity linking jest dostępny za pośrednictwem powiązanego frameworka GLiNKER.
LLM-y jako nauczyciele: studium przypadku $70 i gotowy do wdrożenia pipeline
Wzorzec LLM-as-teacher oddziela kosztowną adnotację od tańszej inferencji. Dwa opublikowane studia przypadku pokazują, jak zespoły stosowały go w różnych warunkach.
Studium przypadku CFM
W studium przypadku Hugging Face firma Capital Fund Management wyodrębniła nazwy przedsiębiorstw z około 900 000 nagłówków wiadomości finansowych. GLiNER w trybie zero-shot uzyskał 87,0% F1. Zespół użył Llama 3.1-70B do adnotowania zbioru w około 8 godzin za około $70, a następnie przejrzał 2 714 próbek za pomocą Argilla w kolejnych 8 godzinach.
Dostrajanie GLiNER na tych danych osiągnęło w analizie przypadku 93,4% F1, w porównaniu z 92,7% uzyskanymi przez nauczyciela Llama-70B. Autorzy podają $0,10 za godzinę na CPU dla dostrojonego modelu oraz $8 za godzinę dla nauczyciela (analiza przypadku CFM). Dane te dotyczą jednego zadania z obszaru wiadomości finansowych i jednej konfiguracji infrastruktury.
Badanie Refuel AI
Raport techniczny Refuel AI porównuje etykietowanie przez LLM na 8 zbiorach danych NLP, w tym CoNLL-2003. Raport podaje 88,4% zgodności z ground truth dla GPT-4 (marzec 2023) oraz 86,2% dla anotatorów w ich konfiguracji, a także 20-krotnie szybsze i 7-krotnie tańsze etykietowanie. W osobnym eksperymencie z ensemble’em na danych proprietary uzyskano ponad 95% zgodności, przy czym najlepszy pojedynczy LLM osiągnął 89%. Routing na podstawie confidence do tańszych lub mocniejszych modeli jest proponowanym zastosowaniem, a nie zmierzonym mechanizmem stojącym za wynikiem dla ośmiu zbiorów danych (raport techniczny Refuel AI). Traktuj te wyniki jako raportowane przez dostawcę rezultaty uzyskane zgodnie z protokołem anotacji opisanym w tym badaniu.
Pipeline produkcyjny
Praktyczny proces produkcyjny obejmuje sześć kroków:
- Spisz wytyczne dotyczące anotacji w języku naturalnym
- Utwórz oznaczone przez ludzi zbiory walidacyjny i testowy typu held-out, których rozmiar wynika z częstości występowania encji, wymagań dotyczących slice’ów dla poszczególnych etykiet oraz oczekiwanej szerokości przedziału ufności. Pilotaż obejmujący 50–200 dokumentów może pomóc skalibrować wytyczne, ale nie jest domyślnym rozmiarem produkcyjnego zbioru ewaluacyjnego.
- Użyj LLM-a z wersjonowanym promptem i jawnym schematem danych wyjściowych, aby zaproponować zbiorcze etykiety treningowe. Zachowaj żądany i faktycznie użyty model, prompt, tekst źródłowy oraz status fallbacku. Odrzucaj nieznane typy i spany, których nie da się wyrównać do tekstu źródłowego; companion obecnie wykonuje fallback po cichu i należy to poprawić, zanim jego dane zostaną potraktowane jako złoty standard treningowy.
- Przejrzyj podzbiór za pomocą Argilla lub Label Studio
- Dostrój kompaktowy encoder (GLiNER, SpanMarker, RoBERTa)
- Wdróż model dopiero po tym, jak encoder przejdzie kontrolę jakości na zbiorze held-out oraz analizę całkowitego kosztu. CFM raportował w swojej konfiguracji 16–80 razy niższy godzinowy koszt infrastruktury; w porównaniu uwzględnij koszty anotacji, review, serwowania i ponownego treningu.
LLM może ograniczyć zakres ręcznej anotacji, ale zespół nadal odpowiada za zbiór walidacyjny, wytyczne dotyczące anotacji, ukierunkowany review i analizę błędów.
Gdzie GLiNER zawodzi, a LLM-y pozostają przydatne
W benchmarku Sease (październik 2025) przetestowano GLiNER w porównaniu z GPT-4.1-mini na 30 zadaniach parsowania zapytań. GPT-4.1-mini uzyskał 100% w pełni poprawnych odpowiedzi. GLiNER uzyskał 53% (16 z 30). GLiNER odpowiadał jednak w 0,08 sekundy, podczas gdy LLM potrzebował 1,21 sekundy — był 15 razy szybszy.
W tym benchmarku obejmującym 30 zadań GLiNER zawodził według trzech powtarzających się wzorców:
- Encje implicytne: wyodrębnienie „wydarzenia” ze zdania „Elton John wystąpił w Madison Square Garden” — tekst nie zawiera dosłownie słowa „wydarzenie”, ale LLM wnioskuje, że chodzi o „koncert”
- Wrażliwość na sformułowanie etykiety: „2022” uzyskuje wynik 0.388 względem „date”, ale 0.958 względem „year” — niewielkie zmiany etykiety powodują duże wahania wyników
- Mapowanie wartości: GLiNER zwraca dokładny tekst powierzchniowy („family houses”) zamiast wartości kanonicznej („Single family house”). LLM może wykonać tę normalizację, gdy prompt i schemat definiują docelowe wartości.
Encje zagnieżdżone i nakładające się
GLiNER domyślnie stosuje płaskie dekodowanie, które tłumi nakładające się span-y. Jego API obsługuje również flat_ner=False, więc predykcje zagnieżdżone są możliwe, choć jakość zależy od checkpointu, etykiet i danych domenowych. Przed wyborem wyspecjalizowanego modelu porównaj oba tryby dekodowania na zagnieżdżonym zbiorze testowym na poziomie spanów.
Używaj GLiNER do jawnej ekstrakcji encji, a przypadki wymagające inferencji, rozumowania lub mapowania do predefiniowanych ontologii kieruj do LLM. Próg routingu powinien wynikać z oznaczonego zbioru danych domenowych.
Ewaluacja NER: metryki, pułapki i zbiory testowe
Model może uzyskać 95% F1 na starannie przygotowanym zbiorze testowym, a mimo to zawodzić na mieszance dokumentów, z którą ma do czynienia po wdrożeniu. Zbuduj zbiór ewaluacyjny na podstawie rozkładu produkcyjnego i zachowaj wycinki dotyczące rzadkich formatów oraz typów encji, które zagregowana wartość F1 może ukrywać.
Podstawowe metryki
Zidentyfikuj każde wystąpienie za pomocą identyfikatora dokumentu, półotwartych offsetów początku i końca oraz typu, a następnie sprawdź, czy text[start:end] odzyskuje wzmiankę. Dwa wystąpienia słowa „John” to dwa cele. Przed dopasowaniem zweryfikuj liczbę dokumentów: brakujące predykcje muszą tworzyć fałszywie ujemne wyniki, a nie znikać wskutek zip(). Nieprawidłowe typy lub offsety licz jako niedopasowaną predykcję i niedopasowany span referencyjny. Raportuj mikro-precision, recall i F1, support oraz recall dla każdego typu, a także zdefiniuj agregację makro i przypadki puste.
- F1 na poziomie encji: Standardowa metryka. Predykcja jest poprawna tylko wtedy, gdy zarówno granice spanu, jak i typ dokładnie odpowiadają danym referencyjnym. To właśnie raportuje większość publikacji.
- F1 na poziomie tokenów: Ocenia każdy token niezależnie. Może sprawić, że częściowo poprawna granica będzie wyglądać lepiej niż wynik dla dokładnego spanu, dlatego gdy poprawność granic ma znaczenie, raportuj F1 dla dokładnych spanów; metryk na poziomie tokenów używaj tylko wtedy, gdy decyzja downstream również jest podejmowana na poziomie tokenów.
- Precision a recall: Koszty tych błędów często są asymetryczne. W deidentyfikacji ważniejszy jest recall — pominięcie nazwiska jest gorsze niż nadmierne usunięcie danych. W ekstrakcji do bazy danych ważniejszy jest precision — fałszywe wpisy zniekształcają dalszą analizę.
Typowe pułapki ewaluacji
- Zawyżanie wyniku przez częściowe dopasowanie: „Bill” wyodrębniony, gdy etykietą referencyjną jest „Bill Gates” — niektóre skrypty liczą to jako częściowe dopasowanie. Jeśli nie masz ku temu uzasadnienia, używaj dokładnego dopasowania spanów.
- Pomylenie typów: „Microsoft” prawidłowo zidentyfikowany jako span, ale oznaczony jako PERSON zamiast ORG, powinien otrzymać zero punktów. Sprawdź, czy kod ewaluacji to obsługuje.
- Przeciek zbioru testowego: Nie umieszczaj w zbiorze testowym zduplikowanych ani niemal identycznych rekordów, dokumentów i adnotacji. Aby wiarygodnie twierdzić, że test jest hard zero-shot, wyklucz również docelowe typy encji ze zbioru treningowego; same powtarzające się stringi powierzchniowe nie stanowią przecieku.
- Niekontrolowane prompty etykiet: Krótka nazwa typu i opis testowanego typu to różne dane wejściowe. Wraz z wynikiem wersjonuj opisy etykiet, progi, rewizje checkpointów i tryb dekodowania.
- Twierdzenia zero-shot oparte na jednym języku: Nie wnioskuj o jakości wielojęzycznej na podstawie angielskiego. OpenNER obejmuje 36 korpusów i 52 języki, a jego baseline’y wykazały, że żaden pojedynczy model nie jest najlepszy w każdym języku (Palen-Michel et al., 2025). W eksperymentach FiNERweb przejście z etykiet angielskich na etykiety w języku docelowym zmieniało F1 o 0,02–0,09 zależnie od ustawienia (Golde et al., 2026). Gdy produkt korzysta z lokalnej terminologii, testuj oba języki etykiet.
- Jeden run jako werdykt: W stosownych przypadkach raportuj zmienność między random seeds, przeglądy progów oraz powtarzane próbki produkcyjne. Mała liczba przykładów w wycinku sprawia, że ranking modeli jest niestabilny.
Traktuj normalizację, entity linking, grupowanie rekordów i endpointy relacji oddzielnie od extractive F1. W kontekście prywatności raportuj wyciekłe instancje i dotknięte nimi automatycznie zaakceptowane dokumenty, fałszywe redakcje oraz odsetek dokumentów skierowanych do weryfikacji. W przypadku serwowania raportuj completion rate, opóźnienie dokumentu p50/p95, przebiegi cold i warm, rozmiary batchy i etykiet, szczytowe zużycie pamięci oraz koszt zaakceptowanego dokumentu.
Budowanie domenowego zbioru testowego
Na potrzeby ewaluacji produkcyjnej zalecam:
- Próbkuj dane produkcyjne, a nie starannie wybrane przykłady. Uwzględnij trudne, nieuporządkowane dokumenty, które model rzeczywiście będzie otrzymywać.
- Dobierz rozmiar zbioru testowego do potrzebnej precyzji oszacowania. Wybierz liczebność na podstawie częstości występowania encji, rozmiarów wycinków dla poszczególnych etykiet oraz wymaganej szerokości przedziału ufności. Raportuj bootstrapowe lub analityczne przedziały ufności.
- Użyj co najmniej dwóch adnotatorów na podzbiorze kalibracyjnym. Rozstrzygaj rozbieżności i raportuj miarę zgodności uwzględniającą spany. Zgodność pozwala diagnozować niejednoznaczność i jakość wytycznych; nie stanowi górnej granicy wydajności modelu.
- Stratyfikuj według trudności — przypadki łatwe (czysty tekst, standardowe typy) i trudne (niejednoznaczne encje, żargon, zaszumiony tekst).
- Zachowaj wycinki dotyczące prywatności i fairness. Dla PII raportuj recall według typu PII, języka, lokalizacji, formatu dokumentu oraz istotnych wycinków demograficznych lub związanych z pochodzeniem nazw. Ogranicz dostęp ewaluatorów do surowego wrażliwego tekstu, ustal limity retencji i analizuj false negatives.
Continual NER wymaga niezmiennego zbioru regresyjnego
Taksonomie produkcyjne się zmieniają. Dodawaj nowe typy bez niejawnej zmiany znaczenia starych typów. Utrzymuj wersjonowany, niezmienny zbiór regresyjny dla istniejących typów, osobny zbiór testowy dla nowego typu oraz changelog zmian w wytycznych adnotacji. Przed zastąpieniem checkpointu raportuj osobno wyniki dla starych i nowych typów. To najprostszy sposób na wykrywanie zapominania i dryfu taksonomii.
Produkcyjne NER w czterech branżach
Poniżej przedstawiono wybrane przykłady branżowe z konkretnymi wartościami liczbowymi uzyskanymi w opisanych warunkach. Źródła obejmują porównania raportowane przez dostawców, studia przypadków opisane przez firmy lub zespoły projektowe, a także recenzowane publikacje i preprinty. Traktuj je jako praktyczne przykłady, a nie ranking dojrzałości.
Ochrona zdrowia
Przykłady John Snow Labs i Providence omówione powyżej pokazują, dlaczego deidentyfikacja wymaga raportowania zarówno na poziomie encji, jak i dokumentu. Ich protokoły ewaluacji są bardziej przydatne przy projektowaniu procesu przeglądu niż przy tworzeniu bezwarunkowego rankingu dostawców.
Retrospektywa OpenMed, opublikowana 6 stycznia 2026 r., opisuje 481 modeli; liczba ponad 380 odnosi się do katalogu modeli z uruchomienia w lipcu. Liczba pobrań mierzy dystrybucję, a nie wdrożenia. Twierdzenie o najlepszych wynikach na 10 z 12 benchmarków pochodzi z osobnego preprintu autorów z sierpnia 2025 r., a nie z niezależnie zweryfikowanych wyników produkcyjnych.
NER w finansach
Ekstrakcja finansowa obejmuje zarówno wzmianki o firmach w wiadomościach, jak i pola w raportach; ich schematy oraz długości dokumentów się różnią. Studium przypadku CFM dotyczy pierwszego z tych zastosowań. FinBERT-MRC ujmuje ekstrakcję jako machine reading comprehension i raportuje 92.78±0.56 F1 na ChFinAnn oraz 96.80±0.38 na AdminPunish — oba zbiory danych są chińskie. Wyniki te nie potwierdzają dokładności na anglojęzycznych raportach SEC. Testuj długie dokumenty i zagnieżdżone encje finansowe w docelowym języku.
E-commerce
W publikacji Walmart z konferencji KDD 2023 wykorzystano wielozadaniowe dane zapytań QU-965M; około 60 etykiet NER to klasy IOB2. W sekcji 6.8 przypisano wzrost GMV o 0,51% bazowemu modelowi MTDNN wytrenowanemu na tych danych, podczas gdy ewaluacja online EAMT pozostała zadaniem na przyszłość. Zmiany biznesowej nie można przypisać wyłącznie NER. W TripleLearn firmy Home Depot raportowano wzrost F1 na zbiorze odłożonym z 69,5 do 93,3, przeprowadzono eksperyment online i utrzymywano rozwiązanie na produkcji przez ponad dziewięć miesięcy. Wnioskiem możliwym do przeniesienia jest iteracyjne nadzorowanie domenowe, a nie ranking aktualnych architektur.
Cyberbezpieczeństwo
iACE to historyczny przykład automatycznej ekstrakcji informacji o zagrożeniach. Publikacja dotycząca CyNER łączy rozpoznawanie neuronowe z innymi źródłami ekstrakcji i raportuje 76.66 span micro-F1 dla XLM-RoBERTa-large, z ewaluacją przy użyciu seqeval. Preprint CyberNER ujednolica cztery zbiory danych do 21 etykiet zgodnych z STIX 2.1 i raportuje dla RoBERTa F1 na poziomie 0.736. Są to wyniki badawcze, a nie dowód wdrożenia produkcyjnego.
Optymalizacja wdrożenia: od Pythona do inferencji o mniejszych opóźnieniach
Repozytorium towarzyszące pokazuje eksport GLiNER do ONNX i pakowanie INT8. Zawiera rozmiary artefaktów, ale nie odtwarza wartości opóźnień ani F1 raportowanych przez zewnętrzne projekty.
Natywne serwowanie GLiNER
Przed przejściem na nowe środowisko wykonawcze przetestuj ścieżkę Ray Serve w projekcie. gliner[serve] zapewnia dynamiczne batchowanie, dobór rozmiaru batcha uwzględniający pamięć, skalowanie do wielu replik oraz klienta HTTP. Batchowanie i repliki mogą zwiększyć przepustowość, ale batchowanie może też wydłużyć czas oczekiwania, a repliki nie eliminują kolejkowania. Przed porównaniem z ONNX lub Rust zmierz opóźnienie w kolejce, opóźnienie po rozgrzaniu, przepustowość oraz exact-span F1 dla używanego profilu żądań.
Eksport do ONNX
GLiNER obsługuje natywną konwersję do ONNX, a wstępnie przekonwertowane modele są dostępne w Hugging Face (onnx-community/gliner_small-v2.1). Zmierz opóźnienie względem tego samego checkpointu PyTorch, rozmiaru batcha, sprzętu i protokołu rozgrzewania.
Uruchom scripts/02_onnx_export.py z repozytorium towarzyszącego, aby wyeksportować model i dynamicznie skwantyzować jego artefakt ONNX. Skrypt wymaga tego środowiska i pobiera checkpoint, dlatego należy uruchamiać go w tym repozytorium, a nie traktować jako samodzielny fragment artykułu:
uv run python scripts/02_onnx_export.py
Kwantyzacja INT8
Kwantyzacja dynamiczna może zmniejszyć wymagania modelu ONNX dotyczące miejsca i pamięci. Wpływ na opóźnienie i F1 dla poszczególnych etykiet zależy od checkpointu i CPU, dlatego skrypt eksportu jest dowodem dotyczącym pakowania modelu, a nie benchmarkiem wdrożeniowym.
from onnxruntime.quantization import quantize_dynamic, QuantType
# Quantize weights dynamically, then evaluate the result
quantize_dynamic("gliner.onnx", "gliner_int8.onnx", weight_type=QuantType.QInt8)
gline-rs: reimplementacja w Rust
gline-rs (Apache 2.0) usuwa środowisko uruchomieniowe Pythona ze ścieżki inferencji. Benchmark projektu w wersji v0.9.0, przeprowadzony w trybie tokenowym na procesorze Intel i9 i z trzema etykietami, raportuje 6.67 seq/s w porównaniu z 1.61 dla Pythona na 100 próbkach NuNER. Oddzielny eksperyment w wersji v0.9.1 na karcie RTX 4080 i 1 000 próbkach raportuje 248.75 seq/s, bez porównywalnego pomiaru Pythona na GPU. Są to warunki użyte przez autorów projektu, a nie wyniki odtworzone przez repozytorium towarzyszące. Biblioteka obsługuje modele span i token, GPU/NPU przez ONNX Runtime oraz jest dostępna jako crate w crates.io.
use gliner::{GLiNER, TokenMode, Parameters, RuntimeParameters, TextInput};
let model = GLiNER::<TokenMode>::new(
Parameters::default(), RuntimeParameters::default(),
"tokenizer.json", "model.onnx")?;
let input = TextInput::from_str(
&["My name is James Bond."], &["person", "vehicle"])?;
let output = model.inference(input)?;
// => "James Bond" : "person" (99.7%)
Pakiet fast-gliner udostępnia bindingi Pythona za pośrednictwem PyO3.
Zakres dowodów dotyczących optymalizacji
| Ścieżka | Dostępne dowody | Co zmierzyć przed wdrożeniem |
|---|---|---|
| Eksport ONNX | Skrypt towarzyszący eksportuje checkpoint GLiNER | Opóźnienie po rozgrzaniu, przepustowość i exact-span F1 |
| Pakiet INT8 | Skrypt towarzyszący tworzy dynamicznie skwantyzowany model | Rozmiar artefaktu, opóźnienie i recall dla poszczególnych etykiet |
| gline-rs | Benchmark projektu w udokumentowanej konfiguracji sprzętowej | Tryb modelu, etykiety, sprzęt i batch używane przez Ciebie |
Ustrukturyzowane dane wyjściowe: natywne schematy, Instructor i lokalne dekodery
Gdy potrzebujesz większej elastyczności niż oferują modele enkoderowe — na przykład obsługi niejawnych encji, rozumowania czy mapowania ontologii — zacznij od natywnego mechanizmu schematów dostawcy. OpenAI obsługuje ścisłe json_schemaformaty odpowiedzi, ustrukturyzowane dane wyjściowe Anthropic obejmują dane JSON i ścisłe dane wejściowe narzędzi, a Gemini API obsługuje podzbiór JSON Schema. Wspólny model Pydantic lub Zod może opisywać kontrakt, ale każdy dostawca akceptuje inny podzbiór schematu i inaczej reaguje na odmowy oraz złożoność.
Zgodność ze schematem sprawia, że parsowanie jest niezawodne. Nie dowodzi jednak, że wyekstrahowany fragment rzeczywiście występuje w tekście źródłowym ani że znormalizowana wartość jest poprawna. Waliduj wartości pól, zachowuj offsety lub cytaty, gdy to możliwe, i oceniaj poprawność semantyczną na oznaczonym zbiorze danych.
Instructor opakowuje klienty dostawców, zapewniając walidację Pydantic i opcjonalne ponowienia po nieudanej walidacji.
Implementacja zaadaptowana ze wzorca Instructor w scripts/05_structured_extraction.py. Wymaga wymienionych pakietów oraz OPENAI_API_KEY; dołączony skrypt przełącza się na GLiNER, gdy klucz nie jest dostępny. Ten artykuł korzysta obecnie z GPT-5.6 Terra, którego karta modelu deklaruje obsługę Chat Completions, wywoływania funkcji, ustrukturyzowanych danych wyjściowych oraz none nakładu na rozumowanie. Przed przełączeniem wysokowolumenowego ekstraktora porównaj go z tańszą starszą bazą; nowsza generacja sama w sobie nie dowodzi lepszej dokładności NER.
import instructor
from pydantic import BaseModel
from typing import List, Literal
from openai import OpenAI
class Entity(BaseModel):
name: str
label: Literal["PERSON", "ORGANIZATION", "LOCATION"]
class ExtractEntities(BaseModel):
entities: List[Entity]
client = instructor.from_openai(OpenAI())
result = client.chat.completions.create(
model="gpt-5.6-terra", reasoning_effort="none",
response_model=ExtractEntities,
messages=[{"role": "user", "content": "BioNTech SE acquired InstaDeep in the U.K."}])
# entities=[Entity(name='BioNTech SE', label='ORGANIZATION'), ...]
Outlines od dottxt stosuje inne podejście: ograniczone generowanie tokenów za pomocą automatów skończonych. Dekoder maskuje tokeny, które naruszałyby docelową gramatykę, zamiast czekać na nieudaną walidację i ponawiać generowanie. Przegląd AWS podaje 98% zgodności ze schematem w porównaniu z 76% dla walidacji po wygenerowaniu. Osobno powtarza deklarację .txt Engineering o generowaniu do 5 razy szybszym dzięki podejściu opartemu na koalescencji; strona nie publikuje wystarczającej metodologii, aby traktować obie liczby jako wynik jednego kontrolowanego benchmarku.
Poniższy niewielki przykład lokalny zachowuje Phi-3 jako historyczny przykład integracji dekodera, a nie rekomendację modelu na 2026 rok. W nowym porównaniu ekstrakcji self-hosted uwzględnij aktualne Qwen3.8-27B lub mniejsze checkpointy Qwen3.5. Użyj udokumentowanego loadera modelu, szablonu czatu i backendu serwującego; sama zamiana poniższego ciągu znaków nie zapewnia zgodności z architekturą multimodalną ani jej formatem rozumowania.
import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer
from pydantic import BaseModel
from typing import Literal
class Entity(BaseModel):
name: str
label: Literal["PERSON", "ORGANIZATION", "LOCATION"]
class ExtractEntities(BaseModel):
entities: list[Entity]
model_id = "microsoft/Phi-3-mini-4k-instruct"
model = outlines.from_transformers(
AutoModelForCausalLM.from_pretrained(model_id),
AutoTokenizer.from_pretrained(model_id),
)
result = model(
"Extract entities from: BioNTech SE acquired InstaDeep in the U.K.",
ExtractEntities,
)
LangExtract jest przydatny, gdy wygenerowane pole musi być ugruntowane w źródle: zwraca przedziały znaków i obsługuje hostowane oraz lokalne backendy LLM. W przypadku self-hosted ekstrakcji dokumentów NuExtract konwertuje schematy JSON na szablony i zawiera multimodalne modele dokumentów. Traktuj oba rozwiązania jako systemy ustrukturyzowanej ekstrakcji, a nie automatyczne zamienniki span NER. Ich cele dotyczące pól, offsetów, układu dokumentu i opóźnień wymagają osobnych testów.
Wybór zależy od tego, gdzie uruchamiasz modele. Natywne schematy to ścieżka wymagająca najmniej pracy w przypadku obsługiwanego providera. Instructor dodaje niezależną od providera warstwę walidacji Pydantic i ponawiania prób. Outlines ogranicza lokalną generację zgodnie ze schematem. LangExtract priorytetyzuje zakotwiczenie w źródle, natomiast NuExtract jest przeznaczony do ekstrakcji dokumentów w środowisku self-hosted. Wszystkie ścieżki LLM nadal obejmują generację autoregresywną. Porównuj każdą ścieżkę z encoderem przy tej samej wielkości batcha, na tym samym sprzęcie, dla tego samego schematu encji i według tych samych kryteriów ewaluacji poprawności semantycznej.
Trójwarstwowa architektura produkcyjna
Kierowałbym produkcyjnym NER-em według charakterystyki zadania, a nie na podstawie jednego rankingu modeli.
Warstwa 1: modele encoderowe do jawnych spanów. Użyj cross-encodera GLiNER dla niewielkiego zbioru typów. Gdy wykorzystywany jest duży zbiór typów, porównaj bi-encoder z buforowanymi embeddingami typów. Dostrój model w ramach pipeline’u LLM-as-teacher, a następnie wdrażaj go z użyciem native serving, ONNX, INT8 lub gline-rs tylko wtedy, gdy dana ścieżka przejdzie benchmark domenowy.
Warstwa 2: zadania wielozadaniowe lub ekstrakcja relacji. Gdy jedno żądanie wymaga NER, klasyfikacji i pól hierarchicznych, przetestuj aktualny checkpoint GLiNER2.5 z 194 milionami parametrów względem osobnych baseline’ów dla poszczególnych zadań. Gdy kluczowym wymaganiem są wspólne spany i relacje, przetestuj GLiNER-Relex. W artykule dotyczącym GLiNER2 raportowano opóźnienie klasyfikacji na CPU wynoszące 130–208 ms dla testowanych liczności etykiet; nie stanowi to dowodu dotyczącego późniejszego API relacji ani innego sposobu wdrożenia.
Warstwa 3: LLM-y do ekstrakcji wymagającej intensywnego rozumowania. Kieruj niejawne encje, wnioskowanie kontekstowe i mapowanie do ontologii do natywnego API obsługującego schematy lub do Instructor w przypadku cloud API, a do Outlines w przypadku lokalnego ustrukturyzowanego wyjścia. Używaj LangExtract, gdy kluczowe są przedziały źródłowe, oraz NuExtract, gdy wejściem jest sam dokument. Rejestruj te przypadki do przeglądu. Tylko jawne spany wyrównane ze źródłem mogą stać się zwykłymi targetami treningowymi warstwy 1; fakty wywnioskowane i wartości znormalizowane wymagają własnych targetów oraz osobnej ewaluacji.
Studium przypadku CFM podaje jeden punkt odniesienia kosztów dla warstwy 1: 93,4% F1 przy zgłoszonym koszcie $0,10 za godzinę na CPU, w porównaniu z 92,7% F1 i kosztem $8 za godzinę dla użytego w tym przypadku nauczyciela Llama-70B. Ceny instancji za godzinę nie wyznaczają kosztu dokumentu bez informacji o przepustowości. Przelicz wynik z uwzględnieniem własnego sprzętu, modelu nauczyciela, zbioru etykiet, wykorzystania zasobów i kosztu przeglądu.
Kompromisy i ograniczenia
W przypadku każdego z poniższych kompromisów warto zapytać, gdzie się ujawnia i czy można go zmierzyć przed wdrożeniem.
Błędy LLM-as-teacher propagują się dalej. Jeśli LLM konsekwentnie błędnie rozpoznaje określony typ encji, np. myli nazwy spółek zależnych ze spółkami nadrzędnymi, dostrojony encoder odziedziczy to obciążenie. Dokładnie analizuj typy o niskiej pewności lub niespójne i zachowuj stratyfikowaną próbę losową, aby wykrywać systematyczne błędy występujące nawet przy wysokiej pewności.
Poprawny schemat może zawierać fałszywe fakty. Natywne ustrukturyzowane dane wyjściowe, Instructor i dekodery z ograniczeniami mogą sprawić, że odpowiedź będzie możliwa do sparsowania. Nie gwarantują jednak, że każde pole ma potwierdzenie w źródle, granica spanu jest poprawna ani że znormalizowana wartość wskazuje właściwy rekord. Zachowuj dowody źródłowe i osobno waliduj poprawność semantyczną.
Straty wynikające z kwantyzacji zależą od checkpointu i danych. Companion tworzy dynamicznie kwantyzowany artefakt INT8, ale nie mierzy jego F1. Aktualne zalecenia dotyczące GLiNER rekomendują trening uwzględniający kwantyzację, gdy trzeba zachować dokładność INT8. Przed wdrożeniem porównaj kwantyzowany i oryginalny checkpoint pod względem exact-span F1 oraz recallu dla poszczególnych etykiet.
Kiedy architektura trójwarstwowa jest przerostem formy nad treścią. Pojedyncza domena ze stabilnymi typami encji i wystarczającą liczbą oznaczonych przykładów może wymagać jedynie dostrojonego RoBERTa lub pipeline’u spaCy. Wzorzec trójwarstwowy sprawdza się w wielu domenach, przy zmieniających się typach encji albo przy zmierzonym połączeniu ekstrakcji jawnej i wymagającej intensywnego rozumowania. Wąski pipeline faktur, który wyodrębnia nazwy i daty, może zakończyć się na warstwie 1.
Jakość bi-encodera różni się w zależności od zbioru danych. Joint encoding może pomagać na niektórych zbiorach, podczas gdy bi-encoder wygrywa porównanie CrossNER opisane w artykule, a uni-encoder nieznacznie wyprzedza go na CoNLL-2003. Zbenchmarkuj oba modele na zbiorze domenowym; wybieraj na podstawie zmierzonej jakości exact-span, kalibracji, liczby etykiet i przepustowości, zamiast traktować „high stakes” jako regułę wyboru rodziny modeli.
Twierdzenia dotyczące PII i wielojęzyczności wymagają analizy slice’ów. Wysoki wynik zagregowany może ukrywać niebezpieczny spadek recallu dla konkretnego locale, formy nazwiska, układu dokumentu lub rzadkiej klasy PII. Traktuj model prywatności jako jeden z elementów obrony warstwowej, ustal proces obsługi false negatives i wykonuj ponowną ewaluację po zmianie taksonomii, proporcji języków lub źródła danych.
Najważniejsze wnioski
- Używaj kompaktowego encodera wyłącznie do jawnych spanów dopiero po zaliczeniu testu domenowego z obsługą poszczególnych typów i przedziałami ufności.
- Używaj GLiNER-a przy zmieniającym się słowniku etykiet. Najpierw porównaj jego bi-encoder, gdy duży zestaw typów jest wielokrotnie wykorzystywany; włączaj
flat_ner=Falsedopiero po zmierzeniu jakości dla zagnieżdżonych spanów. - W przypadku trudnych twierdzeń zero-shot używaj przetestowanych opisów typów, a w produktach wielojęzycznych testuj osobno angielskie i zlokalizowane brzmienie etykiet.
- Zachowuj OCR, NER, ekstrakcję relacji i entity linking jako odrębne etapy ewaluacji, nawet gdy jeden model udostępnia kilka zadań.
- Traktuj nauczyciela LLM jako system proponujący adnotacje. Nadal wymagane są wytyczne dla anotatorów, adjudykacja, niezmienne zbiory regresyjne oraz wydzielony zbiór testowy.
- Korzystaj z natywnych schematów dla obsługiwanych dostawców LLM, ale poprawność semantyczną i grounding względem źródła waliduj oddzielnie od poprawności JSON.
- Benchmarkuj natywne serving, ONNX, kwantyzację i ścieżki Rust osobno oraz łącznie. Nigdy nie mnoż niezmierzonych przyspieszeń.
Referencje
Publikacje
- GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer — Zaratiana et al., NAACL 2024. Bazowa architektura dopasowywania spanów encji.
- GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface — Zaratiana et al., EMNLP 2025 System Demonstrations. Ujednolica NER, klasyfikację i hierarchiczną ekstrakcję; nowsze wydania dodały także ekstrakcję relacji.
- GLiNER Bi-Encoder: Scalable Named Entity Recognition with Bi-Encoder Architecture — Stepanov et al., luty 2026. Rozdzielone kodowanie na skalę milionów etykiet.
- GLiNER-Relex: A Unified Framework for Joint Named Entity Recognition and Relation Extraction — Stepanov et al., 2026. Wspólna, zero-shotowa ekstrakcja encji i relacji.
- GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction — Zaratiana et al., 2026. 42 typy PII w rozdzielczości spanów znakowych.
- ZeroNER: Fueling Zero-Shot Named Entity Recognition via Entity Type Descriptions — Cocchieri et al., ACL 2025. Trudna ewaluacja zero-shotowa z opisami typów.
- OpenNER 1.0: Standardized Open-Access Named Entity Recognition Datasets in 50+ Languages — Palen-Michel et al., EMNLP 2025. 36 korpusów, 52 języki i baseline’y dla wielu ontologii.
- FiNERweb: Datasets and Artifacts for Scalable Multilingual Named Entity Recognition — Golde et al., EACL 2026. Wielojęzyczne etykiety i ewaluacja transferu.
- UniversalNER: Targeted Distillation from Large Language Models for Open Named Entity Recognition — Zhou et al., ICLR 2024. Uniwersalny NER oparty na LLM-ach, uzyskany przez destylację z ChatGPT.
- NuNER: Entity Recognition Encoder Pre-training via LLM-Annotated Data — Bogdanov et al., EMNLP 2024. Badanie enkodera 125M wstępnie wytrenowanego na adnotacjach z LLM-a.
Publikacje branżowe
- EAMT: Entity-Aware Multi-Task Learning for Query Understanding — Walmart, KDD 2023. Badanie wielozadaniowego rozumienia zapytań; wynik online dotyczy baseline’u MTDNN.
- TripleLearn: End-to-End NER for E-Commerce Search — Home Depot, AAAI 2021. Wzrost F1 z 69,5 do 93,3.
- Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence — Liao et al., CCS 2016. Historyczne podejście do ekstrakcji.
- CyberNER: A Harmonized STIX Corpus for Cybersecurity NER — 21 typów encji zgodnych ze STIX 2.1.
- FinBERT-MRC: Financial NER via Machine Reading Comprehension — Sformułowanie MRC ocenione na chińskich zbiorach danych finansowych.
Studia przypadków
- Studium przypadku CFM: dostrajanie GLiNER do finansowego NER - potok etykietowania LLM firmy Capital Fund Management za $70 osiąga 93,4% F1.
- Refuel AI: raport techniczny dotyczący etykietowania przez LLM - GPT-4 osiąga 88,4% zgodności adnotacji, przekraczając wynik ludzkich anotatorów.
- Sease: GLiNER jako alternatywa dla LLM-ów w parsowaniu zapytań - przypadki, w których GLiNER zawodzi, a LLM-y są nadal potrzebne.
- John Snow Labs: benchmark deidentyfikacji tekstu medycznego - badanie dostawcy z remapowaniem etykiet i wykluczeniami.
- OpenMed: podsumowanie roku 2025 - retrospektywa ze stycznia 2026 r.; inwentarz i pobrania nie oznaczają wdrożeń.
Narzędzia i frameworki
- repozytorium demonstracyjne ner-field-guide - materiały towarzyszące temu artykułowi: quickstart GLiNER, eksport do ONNX, LLM jako nauczyciel i ekstrakcja ustrukturyzowana.
- gline-rs: implementacja GLiNER w Rust - oddzielne eksperymenty opiekuna projektu z użyciem CPU i GPU; kod na licencji Apache 2.0.
- serwowanie GLiNER - ścieżka Ray Serve z dynamicznym batchowaniem i wdrażaniem wielu replik.
- potoki języka angielskiego spaCy - metryki wersjonowanego potoku z zamkniętym zestawem etykiet.
- Microsoft Presidio - analiza i anonimizacja danych PII z użyciem niestandardowych recognizerów.
- Instructor - ustrukturyzowana ekstrakcja z LLM za pośrednictwem modeli Pydantic.
- Outlines - ograniczone generowanie tokenów za pomocą FSM, wraz z raportowanym benchmarkiem zgodności ze schematem.
- LangExtract - ekstrakcja ustrukturyzowana oparta na źródłach, z przedziałami znaków.
- NuExtract - samoobsługowa ekstrakcja dokumentów na podstawie schematu i szablonu.
- OpenAI Structured Outputs - dokumentacja formatu odpowiedzi ze ścisłym schematem JSON.
- Anthropic Structured Outputs - dane wyjściowe JSON i ścisłe dane wejściowe narzędzi.
- Gemini Structured Outputs - podzbiór JSON Schema dla ustrukturyzowanych odpowiedzi.
- AWS: Structured Output with Outlines - benchmark zgodności ze schematem na poziomie 98%.