Kavach PII 270M: локальный поиск персональных данных и готовые GGUF

Зачем это локальному стеку

Kavach получает документ и возвращает JSON-массив пар label и text: например, имена, телефоны, адреса, номера документов и ключи. В опубликованной конфигурации перечислены 52 типа; карточка заявляет поддержку 29 языков, включая русский. Извлечение на собственной машине полезно там, где исходные тексты нельзя отправлять во внешний сервис. Возвращённые значения можно сопоставлять с оригинальным текстом для маскирования, но модель не выдаёт позиции символов напрямую: приложение должно восстановить смещения и проверить, что каждая найденная строка действительно присутствует во входе. s1 s4

Есть два практических пути:

• Полный BF16-чекпойнт для Transformers; рядом выложен отдельный LoRA-адаптер к исходной Gemma 3 270M. Пример загрузки и точный промпт приведены в карточке. Адаптер сам по себе не заменяет базовые веса. s1
• GGUF для llama.cpp, Ollama или LM Studio. Автор рекомендует Kavach-PII-270M-Q4_K_M.gguf как стартовую квантизацию; файл присутствует в дереве закреплённой ревизии наряду с F16, Q8_0 и вариантами с дополнительно сжатыми embeddings. Размер файла не является минимальным требованием к RAM или VRAM: контекст, буферы runtime и режим offload тоже занимают память. s2 s5

Для llama.cpp автор предлагает llama-server -m Kavach-PII-270M-Q4_K_M.gguf -c 4096 -ngl 99 --port 8080; для CPU-only в карточке есть отдельный пример с -ngl 0. Для Ollama опубликован пример Modelfile с локальным GGUF, temperature 0 и num_ctx 4096. Нужна именно инструкция для извлечения из карточки: автор предупреждает, что перефразирование промпта и случайное сэмплирование ухудшают стабильность JSON. Ни одна из этих команд не проверялась Modelium на собственном оборудовании. s1 s2

Что говорят испытания — и чего они не говорят

По авторскому отчёту, на отложенной части собственного набора из 3372 документов и 13 646 размеченных значений полный вариант показал 88,4 F1 для совпадения типа и значения. Сравнение с GLiNER и Presidio выполнялось автором на этом же корпусе; сопоставление меток было приблизительным, а Presidio работал с англоязычной конфигурацией spaCy. Нельзя переносить разницу с этими baseline на произвольные реальные документы. s1 s6

Для GGUF автор отдельно измерил 400 стратифицированных документов из тестовой выборки: Q4_K_M и F16 получили по 89,2 F1 в этом поднаборе. Замер сделан в llama-server с полным GPU offload, greedy decoding и одинаковыми промптами на RTX 5060 Laptop. Это не тот же объём выборки, что 3372 документа, и не независимое воспроизведение. Автор прямо указывает, что весь корпус синтетический, хотя в него добавляли шум OCR/ASR и фрагменты реальных текстов; собственный генератор данных использовался и для gold-разметки теста. s1 s2 s6

Ограничения важны именно для обезличивания: по отчёту автора, случайная смесь регистра снижает F1 на 15,6 пункта; отдельные типы вроде почтового индекса и индийского PAN распознаются заметно слабее. На тесте были ответы, не совпавшие со строками исходного документа. Поэтому перед выпуском в рабочий конвейер стоит прогнать собственную контрольную выборку, отбрасывать ненайденные в тексте значения и предусмотреть дополнительную проверку для регулируемых данных. Модель — помощь при обнаружении PII, не гарантия выполнения требований по защите данных. s1 s6

Лицензия и вывод

Метаданные обоих пакетов указывают gemma: веса производны от Gemma 3 и распространяются с условиями Gemma Terms of Use и Prohibited Use Policy, которые автор передаёт получателям. Это не лицензия Apache-2.0 для весов; отдельные условия для кода оценки и синтетического датасета не меняют лицензию модели. Перед коммерческим внедрением и дальнейшим распространением следует проверить применимые условия Gemma. s1 s2 s7

Практический итог: веса и готовые GGUF уже доступны для локального прототипа PII-редактора; заявленную точность надо перепроверять на собственных данных, особенно на сложных документах и редких типах идентификаторов. s1 s2