AGIMA собрала PII-детектор для русского языка: 6 слоёв на миллион запросов в месяц

Андрей Непряхин, технический директор AGIMA, опубликовал детальный разбор внутреннего контура безопасности, через который проходит почти миллион запросов в месяц от примерно ста активных сотрудников. Контур стоит между пользователем и языковой моделью, ищет промпт-инъекции (попытки подменить инструкции модели текстом, который приходит как обычные данные) и джейлбрейки (частный случай, когда цель именно снять ограничения ассистента), маскирует персональные данные и пишет инциденты. Начинался он как внутренний инструмент, позже у него появились внешние пользователи. Разбор строится на собственных замерах AGIMA и прямо предупреждает: метод переносится, конкретные проценты нет.

Почему одной модели оказалось мало?

Первая и самая частая гипотеза при построении такой системы: взять одну хорошую модель и прогонять через неё весь поток. AGIMA от неё отказалась, и Непряхин называет это самым важным решением проекта.

Слоёная схема «регулярные выражения плюс NER (Named Entity Recognition, автоматическое распознавание именованных сущностей: имён, организаций, адресов в тексте) плюс разрешение конфликтов» существует давно. Так устроен, например, Microsoft Presidio. Но для кириллицы пришлось добавить три вещи, которых в готовых решениях нет:

• Закрытие кириллических «слепых зон», мест, где англоязычная модель систематически не видит российские форматы данных.
• Обучаемый слой семантики с обратной связью от аналитика.
• Обратимое маскирование, которое переживает контакт с языковой моделью (об этом ниже).

Контур решает четыре разные задачи, и каждая требует своего инструмента.

Форматные персональные данные (паспорт, ИНН, СНИЛС, номер карты, телефон, банковский счёт) имеют строгий формат, часто с контрольной суммой. Регулярное выражение здесь точнее любой модели, которую команда пробовала, и работает за доли миллисекунды. Модель, по словам Непряхина, не просто избыточна, а хуже: путает СНИЛС с номером счёта, спотыкается на российских адресах.

Имена, организации, география формата не имеют, нужен контекст. Здесь работает NER, конкретно Natasha, связка морфологического разбора русского языка: Razdel для токенизации (разбиения текста на слова), Navec для эмбеддингов (числовых представлений слов), Slovnet для самой разметки.

Семантика атак не ложится ни в формат, ни в шаблон, это смысл. Поэтому нужна модель-классификатор: открытая guard-модель на архитектуре GLiNER плюс собственные адаптеры AGIMA поверх.

Слепые зоны модели закрывает отдельный слой правил, который ловит то, что модель систематически пропускает.

Плюс два вспомогательных источника: декодер (распаковывает base64, hex, URL-кодирование и прогоняет результат заново) и отдельная PII-модель, дообученный GLiNER на том же энкодере, для типов, которые не ложатся ни в регулярные выражения, ни в Natasha.

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

Аргументы за такую архитектуру

• Точность на форматных данных выше, чем у любой модели. Регулярные выражения с проверкой контрольных сумм не галлюцинируют (не выдумывают несуществующие совпадения) и не путают типы документов.
• Обучаемость на собственных ошибках. Команда начинала с готового NER, но ушла от него именно потому, что модель не получалось учить на своих ошибках в том цикле, который реально работает в компании.
• Открытый стек. Базовый энкодер обучен Microsoft, архитектура GLiNER открыта, guard-модель выложена под пермиссивной лицензией. Собственный вклад AGIMA начинается на «четвёртом этаже»: адаптеры, обученные на своём трафике.
• Безопасность раскрытия. Базовые веса (открытые веса, то есть параметры модели, доступные для скачивания) может скачать кто угодно, но поведение PII детектора в бою определяют адаптеры, которые не опубликованы. Несколько раундов дообучения (fine-tuning, обучение модели на ваших примерах под узкую задачу) меняют детектор, по словам Непряхина, «до неузнаваемости».

Честные контраргументы

• Сложность эксплуатации. Шесть компонентов вместо одного означают шесть точек отказа, шесть мест, где нужно следить за версиями, и шесть потенциальных конфликтов между сигналами. Для небольшой команды без выделенного ML-инженера (инженера машинного обучения) это может оказаться неподъёмным.
• Непереносимость метрик. Все числа из статьи Непряхина, это внутренние замеры на собственном трафике AGIMA. На другом домене они будут другими, и автор прямо об этом предупреждает. Повторить архитектуру можно, повторить результат без аналогичного объёма размеченных данных нельзя.
• Существующие решения не были протестированы на тех же данных. Непряхин честно говорит: Microsoft Presidio на данных AGIMA не мерили, поэтому не берётся утверждать, что он бы не справился. Аргумент «для кириллицы нет коробочного решения» держится на опыте команды, а не на сравнительном бенчмарке.
• Зависимость от аналитика. Обучаемый слой семантики с обратной связью от аналитика, это ручной труд. Масштабировать его на компании с тысячами сотрудников дорого.

Мы начинали с готового NER, но ушли от него: качество распознавания было не главной проблемой — модель не получалось учить на своих ошибках в том цикле, который у нас работает. : Андрей Непряхин, технический директор AGIMA

Что делать с этим прямо сейчас, по ролям?

Автору на Дзене и копирайтеру. Если вы вставляете в промпт фрагменты клиентских документов, контракты, ТЗ с контактами, адреса, считайте, что PII детектора у вашего сервиса нет. Проверяйте вручную каждый промпт перед отправкой: убирайте телефоны, ФИО, реквизиты. Это неудобно, но это единственная защита, пока ваш инструмент не показывает, что именно утекло.

Маркетологу и руководителю. Если ваша команда использует языковые модели через корпоративный шлюз, спросите у технического отдела один вопрос: «Есть ли у нас журнал того, что уходит наружу?» Ответ «нет» или «не знаю» означает, что проблема AGIMA ваша тоже.

Разработчику и предпринимателю в РФ. Опыт AGIMA показывает конкретную цепочку: регулярные выражения для форматов, Natasha для русскоязычного NER, GLiNER с адаптерами для семантики атак. Весь стек открытый. Готового «коробочного» PII детектора для русского языка, который можно поставить и забыть, на момент публикации не существует, но собрать рабочий контур из открытых компонентов реально, если есть размеченные данные и инженер, готовый жить с шестью слоями вместо одного.

Компании продолжат наращивать внутренний трафик к языковым моделям, а регуляторное давление на защиту персональных данных в России только усиливается. Ждать готового «коробочного» PII детектора для кириллицы можно долго, и разбор AGIMA показывает, почему: слишком много слепых зон, которые английские модели просто не видят. Те, кто начнёт собирать свой контур сейчас, на открытых компонентах и собственных размеченных данных, получат фору, которая через год будет стоить заметно дороже.