🚀 Live demo · llaim.ru

🇬🇧 English | 🇷🇺 Русский

---

LLAIM Legal NER 🐋 — English

TL;DR

• 🎯 Finds 13 types of personal data and legal identifiers (name, INN, OGRN, SNILS, passport, address, bank account, case number…) in Russian legal documents.
• 🔁 Replaces them with reversible tokens ([PER_1], [INN_1]…) so the document can be sent to an external LLM safely, then restored losslessly from a local mapping.
• ⚡ ~29M parameters, runs on CPU, on-premise — text never leaves your machine. MIT license.
• 📊 Overlap-match micro F1 0.94 (strict exact-match 0.83 with the bundled post-processing) on a small held-out set of 5 real documents — results are meant to be reviewed by a human.
• 🚀 Try the live demo (use fabricated data only).

Jump to: Versions · Entity types · Usage · Metrics · Limitations · License

The only NER model on Hugging Face trained specifically for pseudonymizing Russian-language legal documents — contracts, lawsuits, powers of attorney, court rulings, employment agreements, and other documents from Russian legal practice.

The model finds personal data and legal identifiers in text; they are then replaced with reversible tokens like [ADDRESS_3139392323] — exact restoration happens through a local encrypted mapping dictionary, without involving the model, guaranteeing lossless recovery. This makes it possible to safely send legal documents to external LLM services.

What makes it unique. General-purpose Russian NER models (Natasha/Slovnet, DeepPavlov) only label the general domain — names, organizations, locations. LLAIM Legal NER recognizes what actually appears in Russian legal documents and poses a genuine regulatory risk if leaked, but is completely absent from those models’ schemas: Russian tax ID (INN), state registration number (OGRN/OGRNIP), social insurance number (SNILS), Russian passport series and number, court/arbitration case number, bank account details — 13 entity types total, purpose-built for legal-document pseudonymization rather than general NER.

Fine-tuned from cointegrated/rubert-tiny2 — a compact model (~29M parameters) that runs on CPU, no GPU required, suitable for on-premise deployment without sending documents anywhere during inference.

Versions

¹ Measured with the same code and held-out set as later versions, for a fair comparison. The original v1.0 notes reported 0.826 / 0.472, obtained with an earlier sentence-splitting pipeline without boundary post-processing.

v2.3's strict F1 on this 5-document holdout (0.828) is close to v2.0's (0.839) — the difference is within the noise of a 154-entity sample. The real target of this round was case numbers (CASE_NUMBER), which don't appear at all in this small holdout; a broader 5-fold cross-validation over all 255 real documents shows the actual gain: strict F1 0.63 → 0.75 on case numbers, with no regression on other types (overall strict F1 0.869 → 0.874, overlap 0.960 → 0.967 on the same 225 pre-existing documents). See Metrics below.

How it works

Example built on fully fabricated data (names, INN, phone, email are not real). Left to right: a regular document → the model finds and classifies personal data and legal identifiers → each entity is replaced with a reversible token, and the document can now be safely sent to an external LLM service.

Implementation & customization

This model is part of the LLAIM product line. For pipeline integration, fine-tuning for your industry (other document types, domain terminology), or extending the entity schema for your specific use case — get in touch:

• Website: llaim.ru
• Telegram: @DenisRaz

Entity types

Usage

# Reference helper: greedy decoding + boundary post-processing (splits long documents automatically).
#   huggingface-cli download LLAIMlegal/ru-legal-ner llaim_ner.py --local-dir .
from llaim_ner import load, extract

tokenizer, model = load()          # load(revision="v1.0") pins the original release
text = "Договор между ООО «Ромашка», ИНН 7701234567, и Ивановым Иваном Ивановичем."

for e in extract(text, tokenizer, model):
    print(e["label"], repr(e["text"]), e["start"], e["end"])

The post-processing only adjusts span boundaries (extends an entity that a token classifier stopped in the middle of a word, trims a trailing sentence period) and never creates new entities.

Minimal example without the helper (raw token labels, no boundary fixes)

from transformers import AutoTokenizer, AutoModelForTokenClassification
import torch

tokenizer = AutoTokenizer.from_pretrained("LLAIMlegal/ru-legal-ner")
model = AutoModelForTokenClassification.from_pretrained("LLAIMlegal/ru-legal-ner")

text = "Договор между ООО «Ромашка», ИНН 7701234567, и Ивановым Иваном Ивановичем."
inputs = tokenizer(text, return_tensors="pt", return_offsets_mapping=True)
offsets = inputs.pop("offset_mapping")[0]

with torch.no_grad():
    logits = model(**inputs).logits

labels = [model.config.id2label[p.item()] for p in logits.argmax(dim=-1)[0]]
for (start, end), label in zip(offsets, labels):
    if label != "O" and start != end:
        print(f"{label}: {text[start:end]!r}")

For integration into your own pipeline, fine-tuning for your document types, or reversible token replacement with an encrypted vault — reach out via the contacts above.

Training data

The model was trained on a mix of synthetic data (typical phrasing from Russian legal documents with generated, non-real personal data) and 255 real documents across 15+ types (lease agreements, service agreements, contractor agreements, loan agreements, sale agreements, employment contracts, powers of attorney, statements of claim, court decisions and rulings from arbitration and magistrate courts, motions, demand letters, NDAs, consulting agreements, work-for-hire/copyright agreements, construction contracts, personal-data-processing consent forms), manually labeled and human-reviewed.

v2.0 additionally fixes a training bug: real documents used to be truncated at 192 tokens, so about two thirds of the labeled entities (requisites, e-mails, bank accounts and signature blocks at the end of contracts) were never seen by the model. Long documents are now split into chunks of at most 240 tokens that never cut through an entity.

v2.3 adds 30 more real documents, most of them court rulings and motions chosen specifically to cover formats of case numbers absent from the earlier set (arbitration courts, magistrate courts, unique case identifiers), plus a review pass that fixed inconsistent labeling of job titles (a job title is now always labeled, including when it names a party's role rather than a specific person) and a handful of mislabeled spans (wrong entity type, boundaries cutting into a neighboring word).

Metrics

Evaluated on a held-out test set: 5 real documents fully excluded from training (154 labeled entities). Numbers are for v2.3, computed with the bundled llaim_ner.py. Two metrics: overlap-match (the predicted span intersects the true span of the same type) — appropriate for a practical scenario where detection results are reviewed by a human before any irreversible action — and strict exact-match (span boundaries must coincide).

Same code, same held-out set: v1.0 → v2.0 → v2.3, overlap F1 0.783 → 0.902 → 0.936, strict F1 0.662 → 0.839 → 0.828. v2.3's strict F1 is a touch below v2.0's on this particular 154-entity sample (noise on ORG/ADDRESS boundaries, see below) while overlap F1 keeps improving — meaning the model finds the right span more consistently even when exact boundaries occasionally differ.

Case numbers. This 5-document holdout happens to contain zero case numbers, so it can't show the type v2.3 was built for. A 5-fold cross-validation over all 255 real documents (each document held out and scored exactly once) gives a much larger, less noisy picture:

No regression on the original 225 documents, and case-number strict F1 moves from 0.63 (the same 225-document cross-validation before this round) to 0.75 on the new court documents that were added specifically to cover that type. The 30-document, 784-entity sample is still much smaller than would be needed for tight confidence intervals per type — treat the 0.75 figure as directional, not exact.

For 10 of the 13 entity types (INN, OGRN, SNILS, passport, case number, bank account, etc.), general-domain models like Natasha/DeepPavlov have no direct equivalent to compare against — that’s this model’s niche. On overlapping types (PER, ORG), general-domain models report higher F1 (0.95+), which is expected: they’re trained on vastly more data for a much simpler domain (no boilerplate legal phrasing, tables, abbreviations).

The 5-document holdout is small — figures for rare types (SNILS, PHONE, PASSPORT) are statistically noisy, and exact boundaries (strict metric) are harder to get right than detecting the right span (overlap metric). Known weaker spots in v2.3: exact boundaries of ORG and PASSPORT, PER in signature blocks.

Limitations

• Trained on typical Russian legal documents; quality on strongly non-standard formats (OCR-scanned documents, non-Russian text, narrow industry terminology outside the training set) requires additional validation for your specific case.
• The model is a detector, not a final decision-maker. For legally significant documents, results should go through human review before irreversible actions (deletion, external transmission).
• The model is designed to prioritize recall over precision — an extra false positive is preferable to a missed entity (a miss = risk of a PII leak).

License

MIT — inherited from the base model cointegrated/rubert-tiny2 (also MIT). Fine-tuned weights are distributed under the same terms.

Custom version for your domain

For fine-tuning on your own document set, entity types, or industry specifics — reach out via the contacts in the "Implementation & customization" section above.

---

🇬🇧 English | 🇷🇺 Русский

---

LLAIM Legal NER 🐋 — Русский

Кратко

• 🎯 Находит 13 типов персональных данных и юридических реквизитов (ФИО, ИНН, ОГРН, СНИЛС, паспорт, адрес, банковский счёт, номер дела…) в русских юридических документах.
• 🔁 Заменяет их обратимыми токенами ([PER_1], [INN_1]…): документ можно безопасно отправить во внешний LLM, а затем без потерь восстановить по локальному словарю.
• ⚡ ~29M параметров, работает на CPU, on-premise — текст не покидает вашу машину. Лицензия MIT.
• 📊 Overlap-match micro F1 0.94 (strict exact-match 0.83 с входящей в репозиторий пост-обработкой) на небольшом held-out наборе из 5 реальных документов — результат должен проверяться человеком.
• 🚀 Живое демо (только вымышленные данные).

Быстрый переход: Версии · Типы сущностей · Использование · Метрики · Ограничения · Лицензия

Единственная на Hugging Face NER-модель, обученная специально для псевдонимизации русскоязычных юридических документов — договоров, исков, доверенностей, судебных актов, трудовых договоров и других документов из практики российского юрдокументооборота.

Модель находит персональные данные и юридические реквизиты в тексте, после чего они заменяются обратимыми токенами вида [ADDRESS_3139392323] — точное восстановление происходит через локальный зашифрованный словарь соответствий, без участия модели, что гарантирует восстановление без потерь. Это делает возможной безопасную отправку юридических документов во внешние LLM-сервисы.

В чём уникальность. Универсальные русскоязычные NER-модели (Natasha/Slovnet, DeepPavlov) размечают только общий домен — имена, организации, локации. LLAIM Legal NER распознаёт то, что реально встречается в российском юридическом документе и представляет регуляторный риск при утечке, но чего нет в схемах разметки этих моделей вообще: ИНН, ОГРН/ОГРНИП, СНИЛС, серию и номер паспорта РФ, номер судебного/арбитражного дела, банковские реквизиты — всего 13 типов сущностей, специально спроектированных под задачу псевдонимизации юридического документооборота, а не общий NER.

Дообучена (fine-tuned) от cointegrated/rubert-tiny2 — компактная модель (~29M параметров), работает на CPU без GPU, пригодна для on-premise развёртывания без отправки документов куда-либо вовне при самой разметке.

Версии

¹ Измерено тем же кодом и на том же held-out наборе, что и в остальных версиях, для корректного сравнения. В исходных заметках v1.0 указаны 0.826 / 0.472 — они получены прежним конвейером (нарезка по предложениям, без пост-обработки границ).

Strict F1 версии v2.3 на этом 5-документном held-out (0.828) близок к v2.0 (0.839) — разница в пределах шума выборки из 154 сущностей. Настоящая цель этого раунда — номера дел (CASE_NUMBER), которых в этом небольшом held-out нет вовсе; более широкая 5-кратная кросс-валидация на всех 255 реальных документах показывает реальный прирост: strict F1 номеров дел 0.63 → 0.75, без регресса по остальным типам (общий strict F1 0.869 → 0.874, overlap 0.960 → 0.967 на тех же 225 документах). Подробности — в разделе Метрики ниже.

Как это работает

Пример на полностью выдуманных данных (ФИО, ИНН, телефон, email — не настоящие). Слева направо: обычный документ → модель находит и типизирует персональные данные и юридические реквизиты → каждая сущность заменяется обратимым токеном, документ в таком виде безопасно отправлять во внешний LLM-сервис.

Внедрение и кастомизация

Модель — часть продуктовой линейки LLAIM. Если нужна интеграция в свой пайплайн, дообучение под отраслевую специфику (другие типы документов, доменная терминология) или расширение схемы сущностей под конкретный кейс — пишите:

• Сайт: llaim.ru
• Telegram: @DenisRaz

Типы сущностей

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

# Референсный помощник: жадное декодирование + пост-обработка границ (длинные документы режет сам).
#   huggingface-cli download LLAIMlegal/ru-legal-ner llaim_ner.py --local-dir .
from llaim_ner import load, extract

tokenizer, model = load()          # load(revision="v1.0") — закрепить первый релиз
text = "Договор между ООО «Ромашка», ИНН 7701234567, и Ивановым Иваном Ивановичем."

for e in extract(text, tokenizer, model):
    print(e["label"], repr(e["text"]), e["start"], e["end"])

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

Минимальный пример без помощника (сырые метки токенов, без исправления границ)

from transformers import AutoTokenizer, AutoModelForTokenClassification
import torch

tokenizer = AutoTokenizer.from_pretrained("LLAIMlegal/ru-legal-ner")
model = AutoModelForTokenClassification.from_pretrained("LLAIMlegal/ru-legal-ner")

text = "Договор между ООО «Ромашка», ИНН 7701234567, и Ивановым Иваном Ивановичем."
inputs = tokenizer(text, return_tensors="pt", return_offsets_mapping=True)
offsets = inputs.pop("offset_mapping")[0]

with torch.no_grad():
    logits = model(**inputs).logits

labels = [model.config.id2label[p.item()] for p in logits.argmax(dim=-1)[0]]
for (start, end), label in zip(offsets, labels):
    if label != "O" and start != end:
        print(f"{label}: {text[start:end]!r}")

Для интеграции в ваш пайплайн, дообучения под ваши типы документов или обратимой подстановки токенов с зашифрованным хранилищем — обращайтесь по контактам выше.

Обучающие данные

Модель обучена на смеси синтетических данных (типовые обороты российских юридических документов со сгенерированными, не настоящими персональными данными) и 255 реальных документов 15+ типов (договоры аренды, услуг, подряда, займа, купли-продажи, трудовые договоры, доверенности, исковые заявления, решения и определения арбитражных и мировых судов, ходатайства, претензии, NDA, консалтинговые договоры, договоры авторского заказа, СМР/ строительный подряд, согласие на обработку персональных данных), вручную размеченного и проверенного человеком.

В v2.0 исправлена ошибка обучения: реальные документы раньше обрезались на 192-м токене, и около двух третей размеченных сущностей (реквизиты, e-mail, банковские счета и блоки подписей в конце договоров) модель вообще не видела. Теперь длинные документы режутся на куски до 240 токенов, разрезы не проходят внутри сущностей.

В v2.3 добавлено 30 новых реальных документов, в основном судебные акты и ходатайства, подобранные специально под форматы номеров дел, которых не было в прежнем наборе (арбитражные суды, мировые судьи, уникальные идентификаторы дел), плюс проверка разметки, которая устранила непоследовательность в разметке должностей (должность теперь всегда размечается, включая случаи, когда она называет роль стороны договора, а не конкретного человека) и несколько неверно размеченных фрагментов (неверный тип сущности, границы, задевающие соседнее слово).

Метрики

Оценка на held-out тесте: 5 реальных документов, полностью исключённых из обучения (154 размеченные сущности). Цифры — для v2.3, посчитаны с помощью входящего в репозиторий llaim_ner.py. Две метрики: overlap-match (пересечение предсказанного и истинного спана одного типа) — адекватная для практического сценария, где результат детекции в любом случае проходит контроль человека перед необратимыми действиями, и strict exact-match (границы спана должны совпасть).

Тем же кодом на том же held-out наборе: v1.0 → v2.0 → v2.3, overlap F1 0.783 → 0.902 → 0.936, strict F1 0.662 → 0.839 → 0.828. Strict F1 версии v2.3 чуть ниже, чем у v2.0, на этой конкретной выборке из 154 сущностей (шум на границах ORG/ADDRESS, см. ниже), тогда как overlap F1 продолжает расти — модель всё увереннее находит правильный спан, даже когда точные границы иногда отличаются.

Номера дел. В этом 5-документном held-out номеров дел не оказалось совсем, поэтому по нему нельзя оценить главную цель раунда v2.3. 5-кратная кросс-валидация на всех 255 реальных документах (каждый документ ровно один раз оказывается в отложенной части) даёт куда более полную и менее шумную картину:

Регресса на исходных 225 документах нет, а strict F1 номеров дел вырос с 0.63 (та же кросс-валидация на 225 документах до этого раунда) до 0.75 на новых судебных документах, добранных специально под этот тип. Выборка в 30 документов и 784 сущности всё ещё слишком мала для узких доверительных интервалов по каждому типу — цифру 0.75 стоит воспринимать как направление, а не точное значение.

Для 10 из 13 типов сущностей (ИНН, ОГРН, СНИЛС, паспорт, номер дела, банковский счёт и др.) у общедоменных моделей вроде Natasha/DeepPavlov нет прямого аналога для сравнения — это и есть ниша модели. На пересекающихся типах (PER, ORG) общедоменные модели показывают более высокий F1 (0.95+), что ожидаемо: они обучены на несопоставимо большем объёме данных для существенно более простого домена (без шаблонных канцелярских конструкций, таблиц, сокращений).

5-документный held-out небольшой — по редким типам (SNILS, PHONE, PASSPORT) цифры статистически шумные, а точные границы (strict-метрика) сложнее угадать, чем сам факт находки нужного спана (overlap-метрика). Известные слабые места v2.3: точные границы ORG и PASSPORT, PER в блоках подписи.

Ограничения

• Обучена на типовых российских юридических документах; качество на сильно нестандартных форматах (сканы с OCR-артефактами, документы на других языках, узкоспециализированная отраслевая терминология вне обучающей выборки) требует дополнительной валидации под конкретный кейс.
• Модель — детектор, а не финальное решение. Для юридически значимых документов результат должен проходить контроль человека перед необратимыми действиями (удаление, отправка вовне).
• Модель спроектирована с приоритетом recall над precision — лучше лишнее ложное срабатывание, чем пропущенная сущность (пропуск = риск утечки ПДн).

Лицензия

MIT — унаследована от базовой модели cointegrated/rubert-tiny2 (также MIT). Дообученные веса распространяются на тех же условиях.

Кастомная версия под ваш домен

Для дообучения под собственный набор документов, типов сущностей или отраслевую специфику — обращайтесь по контактам в разделе «Внедрение и кастомизация» выше.