GLiFormer от Knowledgator: 575M-энкодер для извлечения данных и вложенного JSON без генерации токенов

Knowledgator Engineering выпустила GLiFormer — фреймворк извлечения информации на основе энкодера, который одинаково решает пять задач: распознавание именованных сущностей (NER), классификацию текста, извлечение связей, сборку вложенного JSON и построение эмбеддингов. Метки и схемы извлечения передаются модели во время инференса, а не зашиты в неё. На Hugging Face выложены две контрольные точки: GLiFormer Base v1 на 264,2 млн параметров и GLiFormer Large v1 на 575,6 млн.

Обе доступны под лицензией Apache 2.0, ставятся командой pip install gliformer и работают как на CPU, так и на GPU.

Зачем понадобился единый энкодер

Типичный конвейер извлечения данных собирают из нескольких моделей: одна размечает сущности, вторая классифицирует документ, третья восстанавливает записи. Исследователи Knowledgator исходят из того, что за этими задачами стоит одна операция: закодировать источник, представить запрошенные понятия и оценить их совместимость.

Большие языковые модели умеют выдавать вложенный JSON, но делают это токен за токеном — вместе с именами полей, пунктуацией и значениями. GLiFormer убирает генерацию из этого пути: значения берутся как спаны прямо из исходного текста.

Как устроен GLiFormer

Фреймворк развивает GLiNER и обобщает сопоставление меток через «якорь» (anchor) — объект, с которым сравнивается каждая метка времени выполнения. Якорем может быть групповой вектор для классификации, пара сущностей для связей или слот записи.

Исходный текст кодируется один раз. Несколько схем для одного документа затем выполняются как локальные для задачи группы поверх общего представления. Вычисления на головах при этом растут вместе с числом групп, меток и якорей.

Для NER голова оценивает начало, конец и внутренние свидетельства для каждой пары «токен — метка». Независимые сигмоидные выходы позволяют сосуществовать вложенным упоминаниям и общим границам.

Структурирование проходит в четыре этапа:

  1. Привязка значений полей к спанам, взятым напрямую из исходного текста.
  2. Назначение спанов неупорядоченным слотам записи — обучение через венгерское сопоставление.
  3. Предсказание направленных связей «родитель — потомок» в пределах путей, разрешённых схемой.
  4. Сборка вложенного JSON детерминированным декодером.

Значения — это исходные спаны, поэтому модель не может выдумать текст, которого нет во входных данных. Ошибиться она всё же способна: в выборе спана, назначении записи и построении иерархии.

Контрольные точки и обучение

Обе версии v1 используют тип модели gliformer-layout с пятью головами: NER, классификация, совместные связи, многоуровневое структурирование и эмбеддинги. В каждой задана максимальная ширина спана в 12 слов и 100 якорей записей.

Параметр Base v1 Large v1
Параметры 264,2 млн 575,6 млн
Слои энкодера 12 24
Размерность эмбеддинга 768 1024
Настроенный max_len 16 384 8 192

GLiFormer-base стартует с backbone DeBERTa, дополнительно предобученного на 100 млрд токенов. В статье указано 1 357 671 пример для широкого мультизадачного обучения и 372 090 — для последующей донастройки под конкретные задачи.

Результаты бенчмарков

Все оценки ниже приводит сама Knowledgator.

На вложенном JSON (500 примеров) Large набирает 91,10 F1, Base — 87,20. GPT-5.6-luna показывает 91,96, GPT-5-mini — 82,56. Метрика здесь не требует точного совпадения JSON: порядок не учитывается, границы допускают погрешность.

На классификации (13 датасетов) Large доходит до 75,03 среднего macro-F1, Base — до 72,36. GLiNER2.5 набирает 64,89, а лидирует GPT-5-mini с 79,79.

На CrossNER (5 доменов) Base в среднем даёт 65,10 F1, Large — 64,35. Gemma-4-31B-IT достигает 70,74.

На связях (4 бенчмарка) Large в среднем показывает 21,33 micro-F1, Base — 18,94. GLiNER-Relex доходит до 25,6, Gemma-4-31B-IT — до 25,08.

По совокупным показателям NER и классификации в статье сказано, что Large обходит Gemma-4-E4B примерно при в 14 раз меньшем числе параметров.

Скорость без генерации токенов

Knowledgator замерила GLiFormer-base на 40 документах структурирования при размере батча 1. Медианная задержка составила 69 мс на GPU NVIDIA RTX PRO 6000 Blackwell в FP16 и 547 мс на CPU AMD EPYC 9B45 с 8 потоками в FP32.

Ключевая цифра «до 95,8× быстрее» — аналитическая оценка, а не измеренный прогон языковой модели. Она исходит из prefill на 2 000 входных токенов в секунду и генерации на 60 выходных токенов в секунду, не учитывает очередь, сетевые задержки и скрытые рассуждения и ничего не предполагает о равенстве точности.

Как этим пользоваться

В репозитории на GitHub и карточке модели показан короткий вызов структурирования:

records = model.structure(
    "Alice works at Acme.",
    {"employee": ["name", "company"]},
)
print(records)

Вложенные схемы Pydantic подходят для многоуровневых записей. Один вызов инференса может одновременно вернуть сущности, классы и структуры. Для связей используйте joint_relations: в контрольных точках v1 нет открытой головы отношений.

Что это значит для локального инференса

Для администратора, которому нужно вытаскивать сущности и записи из писем, тикетов или счетов, важны два свойства GLiFormer. Первое — веса под Apache 2.0 и установка через pip: модель разворачивается на своём железе, без обращения к внешним API и без передачи данных наружу. Второе — работа на CPU: 547 мс на документ при 8 потоках означает, что небольшой поток задач можно обрабатывать без GPU. Если же в хозяйстве уже есть ускоритель, медианные 69 мс дают запас по throughput. При этом стоит помнить, что извлечение связей у GLiFormer отстаёт и от GLiNER-Relex, и от крупных языковых моделей — там, где связи критичны, энкодер в одиночку задачу не закроет. Похожие компромиссы между локальным запуском и облачными моделями разбирались в материале про маршрутизатор локального инференса NVIDIA PAIR. А если задача — не извлечение структуры, а генерация кода, стоит посмотреть на кодинг-модель Cognition SWE-2, собранную на базе Kimi K3.

Частые вопросы

Кого касается эта новость?

Разработчиков и инженеров данных, которым нужно извлекать структурированную информацию из текстов, и администраторов, разворачивающих такие модели на своём железе. Модель открытая, поэтому решение принимается внутри компании, без договора с вендором.

Чем GLiFormer отличается от обычной языковой модели, выдающей JSON?

Он не генерирует текст. Значения полей — это спаны, взятые прямо из исходного документа, поэтому модель не может придумать значение, которого нет на входе. Языковая модель выводит JSON токен за токеном, включая имена полей и пунктуацию.

Какие задачи решает одна модель?

Пять: распознавание именованных сущностей, классификацию текста, извлечение связей, сборку вложенного JSON и построение эмбеддингов. Схемы и метки задаются во время инференса.

Сколько параметров у контрольных точек?

GLiFormer Base v1 — 264,2 млн, GLiFormer Large v1 — 575,6 млн. У Base 12 слоёв энкодера и размерность эмбеддинга 768, у Large — 24 слоя и 1024.

Можно ли запустить модель без GPU?

Да. Замер Knowledgator на CPU AMD EPYC 9B45 с 8 потоками в FP32 дал медианные 547 мс на документ. На GPU NVIDIA RTX PRO 6000 Blackwell в FP16 — 69 мс.

Насколько цифра «до 95,8× быстрее» подтверждена?

Это аналитическая оценка, а не измеренный прогон языковой модели. Она предполагает prefill на 2 000 входных токенов в секунду и генерацию на 60 выходных токенов в секунду, не учитывает очередь, сетевые задержки и скрытые рассуждения.

Что с точностью на вложенном JSON?

GLiFormer Large набирает 91,10 F1 против 91,96 у GPT-5.6-luna и 82,56 у GPT-5-mini. Важно, что метрика не требует точного совпадения JSON: порядок не учитывается, а границы допускают погрешность. Оценки приводит сама Knowledgator.

Где GLiFormer проигрывает?

На извлечении связей: 21,33 micro-F1 у Large против 25,6 у GLiNER-Relex и 25,08 у Gemma-4-31B-IT. На классификации он тоже не первый — там лидирует GPT-5-mini с 79,79 против 75,03 у Large.

Под какой лицензией выложены веса?

Обе контрольные точки — Apache 2.0. Устанавливаются командой pip install gliformer.

Как задать схему извлечения?

Схема передаётся в вызове model.structure вместе с текстом. Для многоуровневых записей подходят вложенные схемы Pydantic, а для связей используется joint_relations — открытой головы отношений в версиях v1 нет.

Источник: marktechpost.com