Маскирование персональных данных ломает RAG: как сохранить нужные связи

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

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

Где возникает ошибка

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

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

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

Как воспроизвести проблему

Создайте синтетические записи двух людей с одинаковой фамилией и одного человека в нескольких документах. После преобразования проверьте обе стороны: разные люди не объединены, записи одного объекта не разорваны. Затем задайте вопрос под пользователем с доступом только к одной записи.

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

Что учитывать при переносе

Обнаружение персональных данных не идеально и зависит от языка и формата. Маскирование не заменяет авторизацию. Хранилище соответствий и возможность обратного восстановления требуют отдельной защиты; нельзя публиковать их рядом с обезличенным корпусом.

Presidio предлагает разные операции преобразования обнаруженных сущностей; сохранность поисковых связей проверяется отдельно. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.

Если хотите связать этот разбор с системной практикой, посмотрите программу Vector DB & RAG Developer на Latorn: она охватывает векторный поиск с фильтрами, гибридную выдачу и оценку RAG. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: RAG на практике: документы, поиск и качество ответов. По смежным вопросам: Чанки в RAG теряют заголовки: как сохранить смысл раздела, Плохой OCR ломает поиск RAG: как отличить ошибку распознавания от поиска.