AWS превратила LLM в настраиваемый детектор персональных данных

Персональные данные определяет инструкция, а не фиксированный классификатор

AWS представила open-source пакет pii-detector для поиска personally identifiable information в текстах перед fine-tuning. Авторы исходят из практической угрозы: обучающие корпуса содержат имена, адреса, телефоны, банковские реквизиты и другие сведения, которые модель может запомнить и позднее воспроизвести. Особенно сложны свободные поля — обращения в поддержку, HR-документы и чаты, где чувствительные фрагменты встречаются в разных форматах и языках.

В классическом token-classification подходе перечень сущностей закреплён во время обучения. Новый employee ID или адрес криптокошелька требует разметки и переобучения. В предложенной архитектуре пятнадцать категорий, определения, исключения и few-shot примеры находятся в system prompt. Чтобы изменить предметную схему, разработчик редактирует инструкции, не меняя веса модели и не разворачивая отдельный классификатор.

Задача LLM специально ограничена: прочитать текст и вернуть JSON-массив с типом сущности и точным найденным значением. Модель не должна вычислять позиции символов — AWS считает такой результат недостаточно надёжным. Post-processing ищет возвращённое значение в исходной строке регулярным выражением, добавляет start и end, удаляет дубликаты и пытается сопоставить близкие названия категорий с разрешённым словарём. Нераспознанная метка остаётся UNK, а не маскируется принудительным соответствием.

Backend заменяется через короткий контракт

Детектор отделён от конкретной модели интерфейсом Inferencer: на вход подаётся список сообщений, на выходе ожидается текст ассистента. В опубликованном пакете есть adapter к Amazon Bedrock Converse API, но тот же контракт допускает собственную реализацию для open model на Amazon EC2 или в закрытом VPC. Так отдельно выбираются две оси системы: backend определяет accuracy, latency и cost, а prompt определяет, какие сущности считать PII.

В walkthrough используется Python 3.11+, Boto3 и модель, доступная через Amazon Bedrock. Для замены модели достаточно другого model_id; пример показывает openai.gpt-oss-20b-1:0, а среди альтернатив называет Amazon Nova и Mistral. Сам пакет не управляет self-hosted инфраструктурой: если команда подключает собственный GPU backend, его жизненный цикл, безопасность и остановка остаются её ответственностью.

Model-agnostic здесь не означает одинаковое качество любой модели. Это свойство программного интерфейса и схемы инструкций: реализацию можно заменить без переписывания детектора. Перед производственным использованием всё равно нужен локальный test set с реальными форматами документов, языками и политикой организации. Иначе удобная смена backend может незаметно изменить recall именно для редких и критичных идентификаторов.

Девять детекторов сравнили на 49 365 записях

AWS оценила девять LLM-based конфигураций на пяти публичных PII-корпусах. Выборка включает 49 365 записей и 222 114 размеченных core spans на восьми языках: немецком, английском, испанском, французском, хинди, итальянском, нидерландском и телугу. Поскольку исходные datasets и детекторы используют несовпадающие labels, авторы свели их к двенадцати общим категориям и считали точным только совпадение start, end и label.

По headline-метрике span-level Core F1 результат находился от 74,9% у Nova Lite 2 до 83,1% у Mistral Large 3; OpenAI PrivacyFilter получил 80,7%, а OSS-GPT 20B на EC2 — 81,6%. Эти числа относятся к опубликованной выборке и процедуре нормализации категорий. Они не доказывают, что один вариант будет лучшим для внутренних договоров, медицинских записей или коротких сообщений конкретной компании.

Latency тоже не следовала простому правилу «меньше параметров — быстрее». В таблице OSS-GPT 20B на EC2 оценён примерно в 1,17 секунды на detection, а Qwen3.6-27B — в 12,79 секунды; авторы связывают разницу с verbosity reasoning и архитектурой. Значения экстраполированы из параллельной обработки многих записей и прямо названы ориентировочными, а не строгим временем одного последовательного вызова.

Расширяемая схема помогает редким сущностям, но не заменяет redaction

Отдельный эксперимент проверяет dataset-specific категории: профессии, названия компаний, crypto-wallet addresses, vehicle identifiers, user-agent strings, sex и gender. В базовом prompt модели почти не знали о них. Extended-конфигурация добавила определения и примеры, одновременно убрав конфликтующие запреты. Для OSS-GPT 20B Extended-entity F1 вырос с 12,1% до 73,3%, для Qwen3.6-35B-A3B — с 9,4% до 80,5%, а для Mistral Large 3 — с 17,3% до 72,7%.

Рост показывает полезность instruction-level адаптации, но не превращает prompt в универсальную privacy policy. У категории должны быть однозначное определение, примеры и ожидаемое поведение на границах span; затем её нужно повторно проверить на данных нужного домена. Опубликованные результаты также показывают общую слабость DATE примерно на уровне 50% для одного языкового разбора OSS-GPT 20B — неоднозначность форматов и границ остаётся реальной проблемой.

Финальный detector output — только список найденных фрагментов с позициями. AWS предлагает передать его в отдельный redaction step, чтобы уже очищенный текст поступал в training pipeline. Производственная цепочка поэтому должна проверять не только F1 модели, но и маскирование всех совпадений, обработку повторяющихся значений, журналирование без утечки исходного PII и fail-closed поведение при невалидном JSON или недоступном backend.