Детектор PII на базе LLM: модель-агностичный подход с настройкой через промпт

Что такое детектор PII на базе LLM и почему промпт важнее архитектуры

Детектор PII на базе LLM - это система, в которой правила поиска персональных данных описаны текстом в промпте, а языковая модель эти правила исполняет. Список типов сущностей, их определения, примеры, формат ответа и правила для спорных случаев живут в одном артефакте. Архитектура модели при этом не важна: подойдёт проприетарная модель из облака, открытая модель на своём железе или их комбинация.

Ключевое следствие: новый тип сущности добавляется правкой промпта. Крипто-кошелёк, employee ID, внутренний номер договора - всё это строки инструкции плюс пара примеров. Переобучение, новая разметка и повторный деплой модели не требуются. Именно на этой гибкости подход выигрывает у классического NER, и именно за неё платят задержкой и стоимостью инференса.

Цифры для ориентира. На пяти публичных корпусах общим объёмом 49 365 записей и на 8 языках Core F1 детектора лежит в диапазоне 74,9-83,1% и зависит от выбранной модели и бэкенда. Расширенная конфигурация промпта поднимает F1 на доменных сущностях с ~12% до ~73%. Обе цифры получены без дообучения модели.

Чем это отличается от классического NER и regex-подходов

Regex ловит то, что описали шаблоном. Email и телефон формата +7 (999) 123-45-67 он находит дешево и стабильно. Как только появляется новый формат или язык, шаблонов становится двадцать, и каждый нужно поддерживать. Для простых случаев регулярки остаются нормальным выбором, LLM здесь избыточен.

Классический NER (spaCy, дообученный BERT) обобщает лучше, но привязан к разметке. Появился новый доменный тип, нужен датасет, аннотаторы, обучение, замер качества, новый деплой. Цикл растягивается на дни и недели.

Подход	Где живёт логика	Адаптация к новому типу	Слабое место
Regex	Шаблон	Новый шаблон на формат	Хрупкость, рост числа правил
Классический NER	Веса модели	Разметка и обучение	Доменные и редкие типы, мультиязычность
LLM и промпт	Текст инструкции	Правка промпта и прогон тестов	Стоимость, задержка, недетерминизм

Честный расклад: LLM-детектор не отменяет регулярки. В продакшене их часто держат вместе: regex для очевидных форматов, модель для всего, что требует контекста.

Ключевые термины: Core F1, Extended-конфигурация, offset

Core F1 - метрика качества на базовом наборе типов: имена, адреса, телефоны, email, номера документов. Считается на уровне спанов (span-level), а не по документу целиком, иначе цифра теряет смысл.

Extended-конфигурация - расширенный промпт с детальными определениями доменных сущностей и дополнительными примерами. Это не другая модель, а другой текст инструкции.

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

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

Как работает модель-агностичный детектор PII: архитектура и пайплайн

Схема линейная. Текст попадает в сборщик промпта, промпт уходит в модель, ответ парсится в структурированный список сущностей с offset, дальше включается постобработка, и на выходе получается набор интервалов для обезличивания.

1. Входной текст: сообщение чата, лог, документ, строка таблицы.
2. Сборка запроса: системная инструкция со списком типов, few-shot примеры, фрагмент текста.
3. Вызов LLM через адаптер бэкенда.
4. Парсинг JSON: сущности, типы, значения, offset.
5. Постобработка: валидация границ, дедупликация, нормализация, маппинг типов.
6. Результат уходит в DLP-шлюз, модуль маскирования или в пайплайн обезличивания.

Место в архитектуре обычно одно из трёх: инлайн-проверка на входе и выходе LLM-приложения, DLP-шлюз перед отправкой данных во внешние сервисы, batch-прогон архивов и логов. В инлайн-сценарии критична задержка, в batch важны полнота и точность. Один и тот же детектор годится для всех трёх, меняются только требования к модели.

Структура промпта: что именно описывается инструкциями

Промпт для детекции PII - это полноценная спецификация. Фразы «найди персональные данные» недостаточно. В рабочем варианте там есть:

• список типов сущностей с определениями и границами применимости;
• примеры для каждого типа, включая отрицательные (что не считать сущностью);
• формат вывода, чаще всего JSON со схемой;
• правила для спорных случаев: «Иван» как имя человека против названия компании, «Москва» как адрес против места рождения;
• языковые правила, если корпус мультиязычный;
• требование возвращать offset в исходной строке.

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

Постобработка: зачем она нужна и что делает

Модель может вернуть сущность «EMP-12345», но указать границы на символ шире. Если маскировать по такому offset, в открытом виде останется цифра. Поэтому постобработка ищет значение в исходном тексте, сверяет границы, разрешает пересечения (когда адрес вложен в название организации) и приводит типы к каноническому словарю. Без этого этапа обезличивание ломается на ровном месте.

Добавление новых типов сущностей через промпт: крипто-кошельки, employee ID и другие

Главное практическое преимущество подхода видно на новых типах. Разберём два сценария.

Пример: добавление крипто-кошелька в список детектируемых сущностей

В промпт добавляется определение: адрес крипто-кошелька - строка фиксированного формата с характерным префиксом и длиной, примеры для BTC и ETH, правило вывода с типом CRYPTO_ADDRESS. Дальше прогон на подвыборке, где кошельки размечены, и замер F1 именно по этому типу.

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

Пример: employee ID и внутренние идентификаторы

Employee ID - типичный доменный тип, которого нет ни в одном публичном датасете. Формат у каждой компании свой: EMP-12345, восемь цифр, буквенно-цифровая смесь. Через промпт задача решается так: описать формат, дать примеры из своей организации, задать правило вывода и добавить отрицательные примеры, чтобы под тип не попали номера заказов и артикулы.

Именно на таких сущностях разница между базовым и расширенным промптом максимальна. Базовый вариант даёт около 12% F1, расширенная конфигурация с определениями и примерами поднимает до ~73%. Никакого дообучения между этими цифрами нет, только текст инструкции.

Бэкенд-агностичная архитектура: Amazon Bedrock vs открытые модели на своём GPU

Адаптер к API - единственное, что меняется при смене бэкенда. Промпт, схема вывода и постобработка остаются теми же. Это даёт свободу манёвра: пилот запускается на управляемой модели, а на больших объёмах детектор переезжает на собственный GPU без переписывания логики.

Когда выбирать управляемые модели (Bedrock и аналоги)

Плюсы: не нужно администрировать GPU, автомасштабирование под нагрузку, доступ к сильным моделям, оплата за токены. Минусы: стоимость растёт вместе с объёмом данных, текст покидает ваш периметр, появляется зависимость от провайдера и его регионов. Такой вариант подходит пилотам, командам без GPU-инфраструктуры и небольшим объёмам обработки. Что проверить перед корпоративным запуском на Bedrock, разобрано в отдельной статье про Claude Fable 5.1 в AWS и Enterprise-сценарии работы с данными.

Когда выбирать локальные модели на своём GPU

Плюсы: данные не выходят за периметр, стоимость железа предсказуема, версия модели зафиксирована и не меняется под вами. Минусы: нужен GPU и обслуживание inference-стека, качество открытой модели может уступать топовой проприетарной. Вариант для регулируемых отраслей, больших объёмов и требований к хранению данных внутри страны. Как сравнивать открытые и закрытые модели и где локальные уже практичны, разобрано в материале про паритет open source и закрытых LLM.

Бенчмарки: Core F1 от 74,9% до 83,1% на пяти публичных корпусах

Условия замера: пять публичных корпусов, 49 365 записей, 8 языков. Core F1 детектора лежит в диапазоне 74,9-83,1% и зависит от двух факторов: какая модель вызывает детектор и на каком бэкенде она работает. Разброс около 8 процентных пунктов - заметная величина, её нельзя списать на шум замера.

Что такое Extended-конфигурация и почему она даёт скачок с ~12% до ~73%

Базовый промпт перечисляет стандартные типы PII. Про employee ID конкретной компании там нет ни слова, и модель либо пропускает такие строки, либо путает их с артикулами. F1 по доменному типу около 12%.

Extended-конфигурация добавляет развёрнутые определения, примеры реальных значений, отрицательные примеры и явное правило вывода. F1 по тому же типу растёт до ~73%. Механика простая: модель получает достаточно контекста, чтобы отличить идентификатор сотрудника от похожей строки. Ограничение тоже понятное: под каждый домен нужна своя расширенная конфигурация, универсальной не существует.

Как интерпретировать Core F1 74,9-83,1%: что это значит на практике

F1 около 80% на детекции PII - рабочий уровень для многих сценариев обезличивания. Для критичных данных этого мало: нужен human-in-the-loop или дополнительный слой проверок на выходе. Разброс 74,9-83,1% означает, что выбор модели влияет на результат заметно, и более дорогая модель не гарантирует лучший F1 именно на вашем корпусе.

Отдельный риск при чтении любых бенчмарков: модель может распознавать тестовую ситуацию и вести себя иначе, чем в реальной работе. Метрики от этого завышаются, и разбор такого эффекта есть в статье про evaluation awareness и расхождение safety-баллов между бенчмарком и продакшеном. Своя валидационная выборка из реальных данных снимает этот вопрос.

Ограничения и слабые места: даты, offset и другие подводные камни

Почему даты - слабое место и что с этим делать

F1 на датах держится около 50% - худший результат среди типов сущностей. Причина в неоднозначности. Одна и та же строка «12.03.2026» может быть датой рождения, датой договора, датой публикации или просто числом в отчёте. Тип сущности определяется контекстом, а модель не всегда его учитывает.

Направления работы: дополнительные правила в промпте с явным перечислением контекстов, эвристики в постобработке (дата рядом с «г.р.» или «родился»), отдельный узкий детектор для дат. 50% - это отправная точка, а не приговор.

Постобработка для точных offset: почему без неё не обойтись

Модель возвращает сущность и позицию, но позиция бывает смещена на один-два символа. При обезличивании это критично: маскируете по неточному offset, и часть ПДн остаётся в тексте. Постобработка решает три задачи: находит значение в исходной строке и уточняет границы, снимает дубли и пересечения, приводит типы к канону. Это обязательная часть пайплайна, без неё обезличивание ломается.

Дальше по списку: задержка и стоимость выше, чем у regex и классического NER; результат недетерминирован при высокой температуре; качество зависит от языка корпуса. Серебряной пули здесь нет.

Как выбрать модель и бэкенд под свои требования

Критерии выбора: точность, задержка, стоимость

Три оси, по которым сравнивают конфигурации.

• Точность. Какой Core F1 приемлем для вашего сценария. Для batch-обезличивания архивов можно взять модель побольше и получить запас. Для онлайн-проверки сообщений требования другие.
• Задержка. Сколько миллисекунд на запрос допустимо. Локальная модель на своём GPU может оказаться быстрее облачной, если она компактнее и не ходит по сети.
• Стоимость. На малых объёмах оплата за токены на Bedrock обычно дешевле собственного железа. На больших объёмах свой GPU может окупиться. Считать нужно на своих объёмах и своём профиле нагрузки.

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

Практический чек-лист перед запуском в продакшен

1. Выписать список типов PII, которые нужно ловить, включая доменные.
2. Собрать валидационную выборку из своих данных с разметкой.
3. Написать базовый промпт с определениями и форматом вывода.
4. Прогнать на двух-трёх моделях, замерить Core F1 на своей выборке.
5. Добавить Extended-конфигурацию для доменных типов и перепроверить базовые.
6. Добавить постобработку offset и дедупликацию пересечений.
7. Замерить задержку и стоимость на реальном профиле запросов.
8. Выбрать бэкенд: управляемая модель или свой GPU.
9. Запустить с мониторингом качества и периодическим прогоном регрессии.

Кому подходит LLM-детектор PII и когда он не нужен

Подходит тем, кому нужна быстрая адаптация к новым типам сущностей, кто работает с мультиязычными данными и у кого классический NER не справляется с доменными типами. Модель-агностичный подход с настройкой через промпт даёт гибкость без переобучения: Core F1 74,9-83,1% на публичных корпусах и рост на доменных сущностях с ~12% до ~73%.

Не подходит, если достаточно регулярок на простых форматах, если задержка критична и LLM в неё не укладывается, если нет ресурсов на постобработку и мониторинг. И помните про слабые места: даты около 50% F1, обязательная постобработка offset, зависимость от модели и бэкенда. Инструмент закрывает класс задач, где нужна гибкость. Заменять им всё остальное не стоит.

Подписаться на канал