Корпуса персональных данных: 56 тысяч размеченных сущностей и ни одного вызова инструмента
В первой статье мы проверяли, что происходит с агентом после маскирования данных. Здесь другой вопрос: на каких наборах вообще проверять такой шлюз? Эту статью можно читать отдельно.
Допустим, шлюз нашёл телефон в сообщении и заменил его. Проверка детектора прошла. Затем модель вызвала find_customer(phone=...). Какой номер получила CRM? Нашла ли нужного человека?
В корпусе для распознавания сущностей обычно нет ни CRM, ни вызова, ни результата поиска. Там есть текст и разметка телефона. Для проверки детектора этого достаточно. Для проверки всей цепочки нужны дополнительные данные.
Мы делаем Pseudex, шлюз обратимого маскирования данных для LLM-агентов. Поэтому чужие корпуса смотрели со своей задачей: проверить и защиту данных, и работу агента. Расскажу, что удалось измерить, а что осталось за пределами этих проверок.
Три разных вида проверок
Название «бенчмарк для ИИ» мало что говорит о содержимом. Полезнее открыть несколько записей.
В NER-корпусе будут текст и границы сущностей: здесь человек, здесь организация, здесь место. В наборе для маскирования обычно размечены телефоны, документы и другие типы данных. В бенчмарке вызовов инструментов будут описание функции, вопрос пользователя и ожидаемый вызов.
Что хотим проверить | Где искать примеры | Чего такая проверка сама по себе не покажет |
|---|---|---|
Распознавание имён и мест | NEREL, WikiANN | Найдёт ли инструмент нужную запись после маскирования |
Обнаружение ПДн в тексте | PII-Bench, ai4privacy | Как подстановка повлияла на действия агента |
Выбор функции и её аргументов | BFCL, τ-bench | Сохранилась ли работа агента после замены персональных данных |
Сторонние наборы проверяют отдельные свойства. В AgentMask-RU мы связали маскирование с восстановлением значений в вызове инструмента.
Из этого не следует, что существующие корпуса плохие. Они отвечают на свои вопросы. Ошибка начинается, когда результат на одном из них используют как доказательство совсем другого свойства.
NEREL: большой корпус, но не переписка с поддержкой
В NEREL около 56 тысяч сущностей и 39 тысяч отношений, 29 типов разметки. Тексты взяты из новостей. Есть вложенные сущности: например, имя человека может встречаться внутри названия организации.
Проверили и локальную копию: в ней 933 файла разметки, 55 950 сущностей и 38 673 отношения.
Вывод скрипта, который считает сущности и отношения в файлах разметки. Это осмотр локальной копии NEREL-v1.0, не оценка качества Pseudex.
Это полезная проверка для детектора. Корпус сделан не нами, поэтому наш генератор не мог случайно подобрать только удобные движку примеры.
Но новостной текст отличается от сообщения «здрасьте это иванова маша». В новостях чаще соблюдают регистр и пунктуацию, называют публичных людей, упоминают организации и географические объекты. Для поддержки важнее опечатки, неполные имена и адреса без привычных маркеров.
Вот фрагмент разметки одной новости. Обратите внимание на DATE: этим типом обозначены и «в 2009 году», и «через десять дней». Это временные выражения, не обязательно даты рождения.
Первые строки исходного файла разметки: идентификатор, тип, границы в тексте и сама сущность. Пример из открытого NEREL.
Различается и сама разметка. Название города в NEREL может быть сущностью LOC. Это не означает, что в любой переписке город нужно скрывать. «Конференция пройдёт в Москве» и домашний адрес клиента требуют разных решений. Становится ли информация персональной, зависит от контекста и связи с человеком.
Поэтому сравнивать шлюз с NER-разметкой нужно с оговоркой: иногда расхождение показывает ошибку детектора, иногда различие между задачами.
MASSIVE: что меняется на коротких репликах
В русской части MASSIVE 16 521 реплика. Это набор для распознавания намерений и заполнения слотов, а не специально размеченный корпус персональных данных.
Для нашей задачи полезен слот person: можно посмотреть, какие упоминания людей шлюз пропускает в разговорных фразах. При этом отсутствие такого слота нельзя автоматически считать доказательством отсутствия ПДн. Разметчики решали другую задачу.
Такой набор позволяет проверить то, что редко встречается в новостях: короткие обращения без полного имени, заглавных букв и аккуратной пунктуации. Поэтому результат на новостном корпусе нельзя автоматически переносить на переписку с поддержкой.
Имена здесь часто встречаются без подсказки «клиент» или «пациент». Некоторые написаны строчными буквами. Чтобы найти их все, недостаточно просто ослабить фильтр: обычные слова тоже бывают похожи на имена. После такой правки нужно проверять не только пропуски, но и лишние подстановки.
PII-Bench: русский текст с размеченными ПДн
У hivetrace/pii-bench другая задача. В нём 1810 примеров, 13 типов данных и 9 доменов. Он ближе к тому, что ожидаешь от проверки шлюза маскирования: в тексте размечены конкретные персональные данные.
Но и здесь результат зависит от того, какие правила распознавания мы считаем правильными.
В раннем замере 88 из 92 размеченных номеров карт не проходили проверку Луна. Проверка валидных номеров находила четыре, по разметке получалось 4.3%. Это исторический пример расхождения с корпусом, не текущий результат детектора: в более позднем сохранённом прогоне найдено 70.7%, в том числе номера, распознанные по контексту.
Такую цифру нельзя ни спрятать, ни объяснить просто словами «плохой корпус». Сначала нужно определить ожидаемое поведение. Если шлюз должен находить любую строку после слова «карта», это одна проверка. Если он должен отличать валидный номер карты от похожего номера заказа, другая. Ошибка в номере тоже может требовать защиты, но для её обнаружения понадобится контекст, а не только контрольная сумма.
Авторы позднее исправили контрольные суммы. Поэтому рядом с результатом важно указывать версию корпуса. Старый замер на старых данных нельзя выдавать за результат на исправленном наборе.
Ещё один пример: КПП и ОГРН. Это идентификаторы организаций, и их наличие само по себе не делает текст персональными данными физического лица. Однако компания может запретить передавать их наружу своей политикой. Тогда шлюз должен их скрывать, но это уже отдельное условие проверки. Для ОГРНИП, связанного с индивидуальным предпринимателем, рассуждение будет другим.
Что показали последние сохранённые прогоны
Ниже результаты, которые мы сверили с сохранённым выводом измерителей. Это замеры рабочей версии движка: их не следует читать как проверку текущего продового контейнера. MASSIVE и NEREL приведены по прогону от 1 октября, PII-Bench по более позднему отчёту после исправлений обработки адресов.
Корпус и срез | Обнаружено | Целиком | Что проверяется |
|---|---|---|---|
MASSIVE ru-RU, 1215 слотов | 92.8% | 91.5% | Упоминания людей в коротких репликах |
NEREL v1.1, dev+test, 1908 PERSON | 92.6% | не считалось этой метрикой | Обнаружение правильным типом по пересечению с разметкой |
NEREL, кириллический срез PERSON | 93.4% | не считалось этой метрикой | 1713 из 1835 упоминаний |
PII-Bench, 176 адресов | 95.5% | 95.5% | 168 адресов из 176 |
PII-Bench, 228 имён | 99.1% | 99.1% | Распознавание имён |
PII-Bench, 217 телефонов | 99.5% | 99.5% | Распознавание телефонов |
PII-Bench, 173 email | 100% | 98.3% | Обнаружение и защита всей строки |
PII-Bench, 118 ИНН | 99.2% | 99.2% | Распознавание ИНН |
PII-Bench, 97 СНИЛС | 100% | 100% | Распознавание СНИЛС |
PII-Bench, 120 паспортов | 90.0% | 90.0% | Обнаружение и покрытие номера |
Разница между двумя колонками существенна. «Обнаружено» может означать, что нашлось лишь одно слово из имени. Но и «целиком» у разных измерителей считается по-разному: в MASSIVE один найденный спан должен вместить весь слот. Если слот включает предлог или два имени, защищённых по отдельности, такая проверка может не засчитать полное покрытие. Поэтому 81.5% нельзя автоматически переводить в «остальные 18.5% утекли».
В NEREL мы отдельно проверяли поддержку найденных спанов разметкой. В отчёте 9766 из 9831 спана пересекаются хотя бы с одной аннотацией, или 99.3%. Это не точность определения ПДн: проверка допускает пересечение с любой сущностью и не требует совпадения типа или границ. Подменять ей precision шлюза было бы неправильно.
Вывод измерителя после исправлений обработки адресов. «Свой тип» показывает, присвоен ли найденному значению ожидаемый тип; это отдельная проверка, не precision.
На PII-Bench восемь не покрытых адресов в этом прогоне оказались названиями городов, которые продукт намеренно оставляет в тексте. Остальные показатели тоже нужно читать вместе с примерами и правилами разметки, а не как единую оценку качества для любого корпоративного трафика.
Где здесь ai4privacy и бенчмарки инструментов
ai4privacy часто упоминают рядом с задачей маскирования. Мы смотрели на варианты 300k/400k, но в изученном составе не нашли русского языка. Такой набор может быть полезен для другой языковой задачи. Результат на нём ничего не скажет о склонении русской фамилии или адресе со строчными буквами.
BFCL проверяет выбор функций и аргументов. В τ-bench агент взаимодействует с инструментами в сценариях, а результат оценивают с учётом выполненной задачи. Это уже ближе к проверке поведения агента.
Однако использовать эти наборы как готовую проверку шлюза ПДн тоже нельзя. Потребуется добавить данные, которые должны быть скрыты, определить ожидаемое восстановление и проверить, что реальные значения не попали в контекст модели.
В MERA есть GorillaHard: вопросы и наборы инструментов, среди которых модель должна выбрать подходящие. В рассматриваемой постановке инструменты не исполняются. Значит, по такому результату нельзя заключить, что после маскирования инструмент нашёл правильную запись в корпоративной системе.
Наш корпус показан отдельной строкой: внешние наборы дополняют проверку маскирования и возврата, а не делают её ненужной.
Зачем мы сделали отдельный корпус, если чужие уже есть
Именно для проверки маскирования вместе с возвратом значения в вызов инструмента мы создали AgentMask-RU. В первой статье описаны корпус, метод и результаты шести систем.
Клиент сообщает телефон. Шлюз заменяет его, имитатор модели переносит подстановку в аргумент поиска, а шлюз должен вернуть настоящий номер до выполнения инструмента. Проверка видит обе стороны: что отправили модели и что вернулось в аргументе вызова. Отдельно считаются пропуски, частичное маскирование и лишние подстановки.
Это уже работающая проверка, а не план на будущее. Но она не отменяет внешних корпусов. Своими примерами легко не охватить редкую фамилию или непривычную формулировку. Для этого и нужны NEREL, MASSIVE и PII-Bench: они проверяют детектор на текстах, которые мы не составляли.
Есть и обратная граница. Хорошая детекция на чужом корпусе не доказывает, что агент после маскирования выполнит ту же задачу. В рассмотренных сторонних наборах такой проверки шлюза нет: результат NEREL не скажет, какой номер получила CRM.
Публичный прогон AgentMask-RU использует детерминированный имитатор модели. Он позволяет проверить передачу и восстановление данных без случайности генерации, но не доказывает неизменность всех решений живого агента. Например, вернувшийся в вызов телефон ещё ничего не говорит о том, правильно ли модель рассчитала скидку по подставленной дате рождения. Это разные вопросы, и смешивать их в один процент нельзя.
Сравнение нескольких шлюзов на нашем корпусе уже есть в первой статье. На перечисленных здесь чужих корпусах мы пока не проводили такое же сравнение, поэтому их цифры в эту таблицу не переносим.
Получается, выбирать между своим и чужими корпусами не нужно. Они проверяют разные вещи. Один показывает, нашёл ли детектор данные в независимом тексте. Другой проверяет, вернулось ли значение туда, где оно нужно инструменту.
Если использовали другие русскоязычные наборы для проверки ПДн, поделитесь в комментариях. Интересно, какую задачу вы на них проверяли и что пришлось учесть в разметке.
Источники
Корпуса
NEREL: github.com/nerel-ds/NEREL
hivetrace/pii-bench: huggingface.co/datasets/hivetrace/pii-bench
ai4privacy/pii-masking-300k: huggingface.co/datasets/ai4privacy/pii-masking-300k
Вызовы инструментов
τ-bench: github.com/sierra-research/tau-bench
MERA: github.com/MERA-Evaluation/MERA, GorillaHard: PR #46
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.