Как правильно измерять точность детекции ПДн: бенчмарки, метрики и разбор ошибок

Как измерять точность детекции ПДн: краткий ответ

Честная оценка детектора персональных данных строится на четырёх элементах: внешнем бенчмарке, собственной golden-выборке, метриках precision, recall и span-level F1, а также разборе ошибок по типам сущностей. Одного процента из презентации вендора недостаточно: без состава документов, схемы разметки и правила сопоставления найденных фрагментов результат нельзя воспроизвести или сравнить с другим инструментом.

Практическая схема выглядит так: прогнать Pigard или другой детектор через внешний бенчмарк hivetrace/pii-bench, собрать эталонную выборку под реальные документы, заранее определить типы ПДн и границы span, затем посчитать true positive, false positive и false negative. После этого нужно отдельно проверить имена и адреса: именно там контекст, сокращения и составные фрагменты часто меняют итоговый результат.

Числа до и после доработок допустимо публиковать только по фактически выполненному прогону. Если тестирование не проводилось, корректнее показать методику и шаблон отчёта, чем подставить привлекательные значения вроде 95%.

Из чего складывается честная оценка

• Тестовые данные. Нужно зафиксировать источник, состав документов, языки, форматы и долю текстов с персональными данными.
• Эталонная разметка. Для каждого span указываются начало, конец и тип сущности. Спорные случаи описываются в отдельной инструкции.
• Формальные метрики. Минимальный набор включает precision, recall и span-level F1. Итоговые значения нужно дополнять разбивкой по классам ПДн.
• Анализ ошибок. Отдельно считаются ложноположительные срабатывания, пропуски и ошибки границ. Для имён и адресов полезно вести собственные категории причин.

В отчёте фиксируют версию Pigard, конфигурацию правил и моделей, режим обработки, пороги, версию разметки и состав тестовой части. Такая дисциплина нужна для сравнения релизов: изменение результата должно объясняться конкретной правкой, а не сменой набора данных.

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

Почему процент точности от вендора ничего не говорит без методики

Фраза «точность детекции 95%» скрывает несколько разных вопросов. Что считали объектом: документ, строку, токен или сущность? Были ли в тесте имена и адреса? Считался ли частично найденный адрес правильным? Учитывались ли пропущенные сущности и лишний текст вокруг них? Пока ответов нет, показатель нельзя сопоставить с результатом другого решения.

Термин «точность» часто используют вместо precision. Это разные вещи. Precision показывает долю корректных срабатываний среди всех найденных сущностей, recall показывает долю найденных эталонных сущностей, а F1 объединяет эти показатели в одно гармоническое среднее.

Какие параметры нужно раскрывать вместе с метрикой

Параметр	Что зафиксировать	Почему это влияет на сравнение
Датасет	Источник, версия, число документов и текстовых фрагментов	Разные корпуса содержат разную долю простых и неоднозначных случаев
Классы ПДн	Имена, адреса, телефоны, документы и другие проверяемые типы	Общий результат зависит от состава классов и их частоты
Схема разметки	Правила начала и конца span, вложенные сущности, спорные случаи	Один и тот же текст может получить разные эталонные границы
Matching	Точное совпадение или разрешённое частичное пересечение	Правило сопоставления меняет число true positive и false positive
Настройки	Версия инструмента, правила, NER-модель, порог и постобработка	Без конфигурации повторный прогон не даст сопоставимый результат
Агрегация	Micro или macro усреднение, результат по каждому классу	Частые сущности могут скрыть провал на редких классах

В техническом отчёте полезно указывать и количество эталонных span. F1, рассчитанный на 40 сущностях, и F1, рассчитанный на нескольких тысячах, несут разный объём информации о стабильности результата. Одного числа без знаменателя недостаточно.

Почему усреднённая оценка скрывает слабые места

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

Результаты нужно смотреть минимум в трёх разрезах:

• по типу ПДн, например отдельно для имени и адреса;
• по жанру документа, например для структурированного поля и свободного текста;
• по виду ошибки, то есть для ложного срабатывания, пропуска и неверной границы.

Среднее значение полезно для общей сводки. Для принятия решения оно должно сопровождаться таблицей по классам. Высокий macro F1 при низком результате на адресах означает нестабильное качество по классам. Высокий micro F1 может означать, что частый и простой класс перевесил редкие сущности.

Внешний бенчмарк hivetrace/pii-bench: точка отсчёта для сравнения

hivetrace/pii-bench нужен как внешняя точка отсчёта. Единый набор текстов и единые правила прогона позволяют сравнить две конфигурации Pigard или проверить, изменился ли результат после обновления правил. Такой тест снижает зависимость от внутренней выборки, которую легко подобрать под сильные стороны конкретного решения.

Внешний бенчмарк не заменяет проверку на рабочих документах. Его состав может не отражать русскоязычные формулировки организации, внутренние шаблоны, переносы строк, сокращения и редкие способы записи адресов. Поэтому результат hivetrace/pii-bench нужно читать как базовый ориентир, а не как доказательство готовности к эксплуатации.

Как зафиксировать условия прогона

1. Запишите версию Pigard и дату запуска. Для изменяемых моделей сохраните название и версию используемого компонента.
2. Перечислите активные регулярные правила, NER-компоненты, словари, пороги и постобработку. Если параметр отсутствует в конкретной конфигурации, это тоже укажите.
3. Зафиксируйте тестовую часть hivetrace/pii-bench и версию эталонной разметки. Нельзя менять тестовые примеры после просмотра результата.
4. Сохраните исходный текст, эталонные span и вывод инструмента. Для каждого найденного фрагмента нужны тип, начало и конец.
5. Посчитайте TP, FP и FN по каждому классу, затем выведите precision, recall и span-level F1. Итоговую строку дополните способом усреднения.

Срез	Эталонные span	TP	FP	FN	Precision	Recall	Span-level F1
Имена	фактическое число	фактическое число	фактическое число	фактическое число	расчёт	расчёт	расчёт
Адреса	фактическое число	фактическое число	фактическое число	фактическое число	расчёт	расчёт	расчёт
Все классы	фактическое число	фактическое число	фактическое число	фактическое число	расчёт	расчёт	расчёт

Такая форма выглядит менее эффектно, чем один крупный процент, зато показывает, что именно измерялось. Конкретные значения для Pigard заполняются после прогона, а не выводятся из описания инструмента.

Что внешний бенчмарк не заменяет

Внешний набор не отвечает на четыре практических вопроса:

• как детектор обрабатывает документы конкретной компании;
• как он ведёт себя на нужном языке и локальных сокращениях;
• какова цена пропуска или ложного выделения каждого типа ПДн;
• может ли команда объяснить и исправить повторяющиеся ошибки.

Эти вопросы закрывает golden-выборка. Сначала внешний бенчмарк помогает увидеть общий уровень и регрессии. Затем собственные документы показывают пригодность решения для конкретного процесса.

Собственная golden-выборка для оценки точности детекции ПДн

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

Что включить в эталонный набор

Состав набора привязывают к фактическому сценарию. Если инструмент получает текст после извлечения из PDF, тест должен содержать особенности именно этого этапа: переносы строк, разорванные слова и потерю структуры. Если на вход поступают таблицы или короткие поля, их проверяют отдельно от длинного свободного текста.

• Положительные примеры с каждым проверяемым типом ПДн.
• Отрицательные примеры, где похожая последовательность не относится к персональным данным.
• Разные формы записи имён: полное ФИО, фамилия с инициалами, обращение, подпись и упоминание в предложении.
• Разные формы записи адресов: сокращения, порядок компонентов, переносы строк и отсутствие отдельных частей.
• Документы разных жанров, если они входят в реальный поток: формы, письма, договорные тексты, обращения и технические журналы.
• Анонимизированные документы, где замена значений сохраняет исходную структуру и контекст.

Нельзя составлять golden-выборку из одних очевидных примеров. Для проверки границ нужны фрагменты, где имя соседствует с должностью, организация похожа на фамилию, а адрес разбит на несколько строк. Для проверки ложных срабатываний нужны числа, названия улиц и географические объекты без связи с конкретным человеком.

Подход к ручной разметке можно организовать в браузерном интерфейсе. В разборе Argilla 2.4 описаны импорт данных, настройка полей и сбор human feedback. Для детекции ПДн потребуется своя схема сущностей и инструкция по границам.

Правила разметки и границ сущностей

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

Для каждого класса ответьте на конкретные вопросы:

• Входят ли инициалы в span имени?
• Входит ли должность рядом с ФИО?
• Считается ли почтовый индекс частью адреса?
• Включаются ли регион, город, подпись поля и служебные слова?
• Нужно ли выделять вложенные сущности внутри составного адреса?
• Как размечать неоднозначное географическое название без номера дома или квартиры?

Удобно хранить границы как полуинтервал [start, end): начальный индекс входит в span, конечный не входит. Тогда длина фрагмента считается как end - start, а расхождения на один символ видны в отчёте. Пробелы и знаки препинания нужно обрабатывать по заранее установленному правилу.

Спорные примеры размечают повторно и добавляют в инструкцию. Если два разметчика по-разному выделяют подпись или индекс, автоматический подсчёт не исправит проблему. Сначала нужно решить, какой вариант считается эталонным.

Разделение данных для проверки и доработки

Документы для разработки, отладки и финальной оценки разводят по разным частям. На development-части выбираются правила и модели. На отладочной части ищутся причины ошибок. Финальный test-набор остаётся закрытым для настройки и меняется только по формальной причине, например при исправлении самой эталонной разметки.

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

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

Span-level F1: как честно считать метрики детекции персональных данных

Span-level F1 оценивает сущности как фрагменты текста с типом и границами. Детектор должен найти нужный участок и присвоить ему правильный класс. Попадание в соседнее слово или частичное пересечение не считается полным совпадением при строгом matching.

Как считать совпадение найденного span с эталоном

Для основной таблицы удобно выбрать строгое правило:

• True positive. Найденный span совпал с эталонным по началу, концу и типу сущности.
• False positive. Детектор выделил фрагмент, для которого нет соответствующего эталонного span, либо присвоил неверный тип.
• False negative. Эталонная сущность отсутствует в выводе детектора или её границы не дают допустимого совпадения.

Пример: эталон содержит Петрова Анна Сергеевна, а детектор выделил только Анна Сергеевна. При строгом правиле это ошибка границ. Если детектор выделил весь фрагмент как ORGANIZATION, это ошибка типа и одновременно отсутствие корректного совпадения с PERSON.

Частичное пересечение можно считать отдельным диагностическим показателем, но его нельзя без пояснения смешивать со строгим F1. Иначе два отчёта с одинаковым названием метрики будут измерять разные результаты.

Для составных адресов особенно важно выбрать политику заранее. Вариант 1: весь адрес, включая город, улицу, дом и квартиру, считается одним span. Вариант 2: каждый компонент получает отдельную метку. Оба подхода допустимы для разных задач, но сравнивать их напрямую нельзя.

Micro и macro усреднение по классам

Для каждого класса рассчитываются:

precision = TP / (TP + FP)
recall = TP / (TP + FN)
F1 = 2 * precision * recall / (precision + recall)

При micro-усреднении TP, FP и FN складываются по всем классам до расчёта итоговых значений. Частые сущности получают больший вклад. При macro-усреднении F1 рассчитывается отдельно для каждого класса, после чего значения усредняются. Редкий класс получает такой же вес, как частый.

Показатель	Что отвечает	Риск неверной интерпретации
Micro F1	Как детектор работает на всех сущностях вместе	Частые классы скрывают слабый результат на редких
Macro F1	Насколько равномерно работают классы	Малое число примеров делает редкий класс нестабильным
F1 по классу	Какие типы ПДн требуют доработки	Без числа эталонных span трудно оценить надёжность

В публикации лучше указывать общий span-level F1, способ усреднения и таблицу по классам. Для имён и адресов нужны отдельные precision, recall и F1, а при заметных расхождениях, ещё и число ошибок границ.

Какие цифры показывать до и после доработки

Сравнение должно использовать один и тот же тестовый набор, одинаковое matching-правило и сопоставимые настройки. Минимальная таблица содержит базовую конфигурацию, изменённую конфигурацию, precision, recall и span-level F1. Рядом указывают число эталонных span для каждого класса.

Конфигурация	Набор	Precision	Recall	Span-level F1	Изменение
Базовая	hivetrace/pii-bench и golden test	фактическое значение	фактическое значение	фактическое значение	исходная точка
После правки	тот же набор	фактическое значение	фактическое значение	фактическое значение	расчёт разницы

Изменение итогового F1 само по себе не доказывает улучшение. Recall мог вырасти за счёт лишних срабатываний, а precision, наоборот, снизиться. Результат нужно читать вместе с FP, FN и ошибками границ по каждому ключевому классу.

Разбор ошибок детекции имён и адресов

Итоговая метрика показывает масштаб проблемы, но не говорит, какую строку правила или компонент модели нужно менять. Для инженерной работы ошибки делят на три группы: ложноположительные срабатывания, пропуски и неверные границы. У каждой группы должна быть причина, а не только счётчик.

Ошибки на именах

Имя зависит от контекста. Последовательность слов с заглавными буквами может обозначать человека, организацию, город, название документа или часть подписи.

• Ложное срабатывание. Название организации или географический объект принимается за имя. Например, слово из названия компании совпадает с распространённой фамилией.
• Пропуск в свободном тексте. ФИО упоминается без маркера «клиент» или «подписант», поэтому правило не видит устойчивого шаблона.
• Неполная граница. Из Петрова Анна Сергеевна выделяется фамилия или только имя.
• Инициалы. Конструкция А. С. Иванов обрабатывается иначе, чем полная запись, особенно при переносе строки.
• Соседний контекст. В span попадает должность, обращение или служебная подпись, хотя инструкция относит их к обычному тексту.

Для каждого случая нужно выбрать тип исправления. Устойчивый формат может закрываться регулярным правилом. Частотные варианты написания полезно добавить в словарь. Ошибки, где правильный класс определяется соседними словами, требуют контекстного признака или NER-модели. Сначала проверяется причина, затем выбирается механизм.

Ошибки на адресах

Адрес состоит из нескольких компонентов, которые могут менять порядок, сокращаться или разделяться переносом строки. Набор слов ул. Лесная, д. 10 похож на адрес, но качество зависит от того, где начинается сущность и где она заканчивается.

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

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

Матрица ошибок для приоритизации доработок

Ошибки удобно группировать по классу, причине, частоте и влиянию на метрику. Приоритет определяется не числом исправленных строк, а сочетанием частоты и цены ошибки для процесса.

Класс	Причина	Тип ошибки	Что проверить	Ожидаемый эффект
Имена	Нет контекста	Пропуск	NER или контекстные признаки	Рост recall
Имена	Пересечение с организацией	Ложное срабатывание	Правила соседних слов и словари	Рост precision
Имена	Инициалы и составное ФИО	Ошибка границ	Нормализация и правило span	Рост strict F1
Адреса	Перенос строки	Пропуск или граница	Объединение строк перед детекцией	Рост recall и span F1
Адреса	Неоднозначное географическое слово	Ложное срабатывание	Контекст и составной шаблон	Рост precision

После каждой правки нужен повторный прогон golden-выборки. В отчёте связывают изменение с конкретным эффектом: например, правило уменьшило FP на адресах, но добавило FN на переносах строк. Такая запись помогает не потерять регрессии.

Регулярные выражения против NER-моделей: что сравнивать на практике

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

Где регулярки дают предсказуемый результат

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

Сильные стороны регулярного подхода:

• прозрачная логика, которую можно объяснить по символам и группам;
• предсказуемая скорость на больших объёмах текста;
• простая корректировка отдельного паттерна;
• отсутствие отдельного этапа обучения модели.

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

Где нужен контекст NER-модели

NER-модель анализирует слова вместе с окружением. Это помогает отличить имя человека от названия организации или географического объекта, если в тексте есть подходящие признаки.

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

Результат NER из другого корпуса нельзя переносить на документы организации без проверки. Даже одинаковый класс PERSON может иметь разные правила для подписи, обращения и реквизитов.

Гибридный подход и единая процедура сравнения

Для практического сравнения запускают три варианта на одной golden-выборке: регулярный, NER и гибридный. У всех конфигураций должны совпадать классы ПДн, входные документы и правило span matching.

Подход	Сильная сторона	Типичная проблема	Что измерять
Регулярный	Форматные сущности и прозрачные правила	Лишние срабатывания при свободном тексте	Precision и ошибки границ
NER	Контекст и вариативные формулировки	Пропуски редких форм и зависимость от домена	Recall и F1 по классам
Гибридный	Сочетание формата и контекста	Конфликты правил, модели и постобработки	Общий F1 и матрицу конфликтов

В итоговом отчёте указывают precision, recall, span-level F1 и категории ошибок для каждого подхода. Победитель определяется рабочим сценарием. Например, высокий recall гибридной конфигурации может быть бесполезен, если ложные срабатывания создают слишком большой объём ручной проверки.

Pigard: как оценить эффект доработок без самообмана

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

От базового результата к гипотезе о причине ошибки

Сначала фиксируется исходная конфигурация. Затем ошибки имён и адресов группируются по механике:

• если пропускаются полные ФИО в свободном тексте, проверяется контекстный компонент или NER;
• если имя захватывается вместе с должностью, проверяются границы и постобработка;
• если адрес теряется после переноса строки, проверяется подготовка текста перед детекцией;
• если название города даёт ложное срабатывание, проверяются составной шаблон и соседние признаки.

Каждая гипотеза должна иметь ожидаемый эффект. Правка контекста должна увеличить recall имён. Уточнение границ должно поднять strict span-level F1. Ограничение шаблона адреса должно снизить FP, но его влияние на recall нужно проверить отдельно.

Как оформить сравнение до и после

Таблица до и после должна содержать одинаковые наборы, версии конфигурации, число эталонных span, TP, FP, FN, precision, recall и span-level F1. Для имён и адресов нужны отдельные строки. В примечании указывается, что именно изменилось: правило, NER-модель, нормализация, разметка или постобработка.

Параметр	До правки	После правки	Проверка
Конфигурация Pigard	версия и настройки	версия и настройки	изменения перечислены
Имена	precision, recall, F1, TP, FP, FN	precision, recall, F1, TP, FP, FN	ошибки границ просмотрены
Адреса	precision, recall, F1, TP, FP, FN	precision, recall, F1, TP, FP, FN	компоненты адреса сопоставлены
Внешний бенчмарк	фактический результат	фактический результат	тестовая часть не менялась
Golden test	фактический результат	фактический результат	документы независимы от настройки

Конкретные метрики Pigard до и после нельзя получить из общего описания методики. Их публикуют после запуска с сохранением исходных результатов. Улучшение на одном наборе не считается достаточным, если на независимой golden-части выросло число false positive или ухудшились границы адресов.

Чек-лист оценки любого инструмента детекции ПДн

Перед сравнением инструментов или покупкой решения проверьте, есть ли у результата воспроизводимая методика. Ответы удобно сохранять в техническом отчёте, а не в рекламной таблице с одним процентом.

Минимальный набор данных для публикации результата

• Какой датасет использовался, сколько в нём документов и эталонных span?
• Какие типы ПДн проверялись, включая имена и адреса?
• Кто размечал данные и по какой инструкции?
• Как определены начало и конец сущности?
• Как обрабатываются вложенные сущности и спорные случаи?
• Как сопоставляются найденный и эталонный span?
• Как рассчитаны precision, recall и span-level F1?
• Показаны ли micro, macro и результаты по отдельным классам?
• Какие версии инструмента, моделей, правил и порогов использовались?
• Можно ли повторить прогон на той же тестовой части?
• Есть ли отдельный разбор ложноположительных срабатываний, пропусков и ошибок границ?
• Сравнивались ли регулярные выражения, NER-модель и гибридная конфигурация на одинаковых условиях?

Когда результат можно считать полезным для эксплуатации

Высокий общий F1 не даёт автоматического разрешения на запуск. Решение оценивают по документам реального процесса, стабильности классов, цене FP и FN, воспроизводимости и понятности поддержки.

Для финального решения нужны четыре проверки:

1. Внешний бенчмарк даёт понятную точку отсчёта, а условия прогона зафиксированы.
2. Golden-выборка содержит реальные или корректно анонимизированные сценарии, положительные и отрицательные примеры.
3. Имена и адреса имеют отдельные метрики и классификацию ошибок.
4. После каждой доработки результат подтверждён на независимой части данных, а рост одной метрики не сопровождается скрытой регрессией.

Так точность детекции ПДн превращается из рекламного процента в проверяемую инженерную характеристику. Для Pigard и любого другого инструмента схема одинакова: внешний hivetrace/pii-bench, собственная golden-выборка, единое span-level matching, метрики по классам и разбор причин ошибок.

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