Почему набор чисел всё ещё может быть персональными данными

Векторное представление, или эмбеддинг, — это массив чисел, который кодирует смысл текста для семантического поиска. В локальном RAG-контуре такие векторы обычно лежат рядом с идентификатором чанка, служебными метаданными и иногда с самим фрагментом документа. Из-за числового вида их легко принять за обезличенные данные. Это опасное упрощение.

Эмбеддинг создаётся из исходного текста и сохраняет достаточно информации, чтобы близкие по смыслу фрагменты находились рядом. Исследование Text Embeddings Reveal (Almost) As Much As Text показало, что специально обученная модель Vec2Text в изученных условиях могла восстанавливать исходные короткие тексты по их векторным представлениям. Авторы сообщили о точном восстановлении 92% текстов длиной 32 токена для одного из исследованных сценариев и продемонстрировали извлечение полных имён из клинических заметок.

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

Где возникает реальный риск в локальном RAG

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

  • Векторная база доступна из лишнего сегмента сети или слушает публичный интерфейс.
  • Аутентификация не включена. Документация Qdrant отдельно предупреждает, что самостоятельно развёрнутый открытый экземпляр по умолчанию небезопасен.
  • Общий API-ключ используется приложением, разработчиками и сервисными заданиями, поэтому его компрометация открывает слишком широкий доступ.
  • Фильтр арендатора или подразделения передаётся клиентом и может быть пропущен либо подменён.
  • Вместе с вектором возвращается payload: исходный чанк, имя файла, ФИО, номер договора или внутренний путь.
  • Снимки коллекций, экспорт и резервные копии хранятся слабее основной базы.
  • В логи попадают запрос пользователя, найденные фрагменты или результаты переиндексации.
  • Сотрудник с техническим доступом может выгрузить коллекцию целиком, хотя для его задачи достаточно нескольких результатов поиска.

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

Базовая архитектура защищённого индекса

Надёжная схема начинается до вычисления вектора. Если лишние данные попали в чанк, последующее ограничение выдачи не исправляет сам факт их хранения.

1. На этапе загрузки документ проходит классификацию и минимизацию. Из текста удаляются поля, которые не нужны для поиска: подписи, банковские реквизиты, персональные контакты, служебные комментарии. Для особо чувствительных полей лучше хранить ссылочный идентификатор, а значение подставлять только после проверки прав.
2. Каждый чанк получает владельца, арендатора, класс чувствительности, идентификатор исходного документа, версию и срок хранения. Эти поля формирует серверный конвейер, а не браузер пользователя.
3. Векторная база размещается в закрытом сегменте и не публикуется в интернет. Межсервисный трафик защищается TLS, включается аутентификация, а ключи разделяются по сервисам и операциям. Публичное приложение обращается к поисковому шлюзу, а не к базе напрямую.
4. Шлюз извлекает идентичность пользователя из проверенной сессии и сам добавляет обязательный фильтр арендатора и ACL. Модель не решает, какие права применить, и не может отменить фильтр текстовой инструкцией.
5. База возвращает ограниченное число разрешённых чанков. Реранкер и генеративная модель получают только уже отфильтрованный набор. В запросах и ответах действует лимит размера, а массовое чтение требует отдельной роли.
6. Диски, снимки и хранилище резервных копий шифруются средствами платформы. Доступ к backup отделяется от рабочего ключа базы, а восстановление регулярно проверяется в изолированной среде.
7. Аудит фиксирует субъект, арендатора, коллекцию, тип операции, число результатов и объём выгрузки. Сам текст запроса и содержимое чанков журналируются только при обоснованной необходимости и с собственным сроком хранения.

Qdrant поддерживает ключи только для чтения и более гранулярные варианты, TLS и приватную сетевую привязку; Milvus — аутентификацию, TLS и роли. Эти функции нужно включить и проверить вместе с политикой приложения.

Почему одного фильтра по tenant_id недостаточно

Поле tenant_id не заменяет авторизацию. Клиент может подменить его, индексатор — записать чанк без арендатора, а общий широкоправный ключ позволяет обратиться к API в обход приложения.

Минимальная защита состоит из трёх слоёв:

  • сетевой слой не допускает пользовательские устройства к базе;
  • сервисная учётная запись имеет только необходимые операции и коллекции;
  • поисковый шлюз принудительно добавляет серверный ACL-фильтр и проверяет результат перед передачей модели.

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

Удаление должно проходить по всей цепочке

Удалить исходный PDF недостаточно. В системе могут остаться чанки, векторы, payload, кэш ответов, поисковые журналы и снимки. Нужна единая операция удаления по идентификатору документа.

Рабочий процесс выглядит так:

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

Если регламент требует срочного физического удаления из всех backup, архитектура резервирования должна поддерживать это заранее. Иначе обещание «удалим по запросу» окажется невыполнимым именно там, где хранится самая полная копия.

Помогут ли шум и квантизация

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

Поэтому шум нельзя считать заменой аутентификации, изоляции и контроля выдачи. Если команда рассматривает такую защиту, её следует оценивать на своих данных сразу по двум метрикам: насколько падает риск установленной атаки и насколько ухудшаются recall, precision и ответы RAG. Без этого получается дорогая иллюзия защиты.

Модельная экономика для небольшого контура

Представим базу из 100 тысяч документов, в среднем по шесть чанков: около 600 тысяч векторов. Само хранение такого объёма обычно не является главным расходом. Больше времени съедают инвентаризация данных, настройка идентичностей, разделение ключей, серверные ACL, безопасные backup и проверка удаления.

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

Это модельный расчёт, а не прайс-лист. В пилоте считайте стоимость защищённого сценария: роли, ротацию ключей, восстановление, аудит изоляции и доказуемое удаление.

Что проверить до запуска

За две недели можно провести ограниченный пилот без подключения всей корпоративной базы.

  • Возьмите один процесс и 500–2000 документов с известными владельцами и классами доступа.
  • Проверьте вход без ключа и с просроченным ключом: база не должна отвечать данными.
  • Выполните поиск от имени двух арендаторов и намеренно подмените tenant_id.
  • Добавьте тестовый чувствительный маркер и проверьте его отсутствие в логах и чужой выдаче.
  • Удалите документ и найдите все его производные: чанк, вектор, payload, кэш и записи в очереди.
  • Восстановите backup в изолированной среде и проверьте, кто реально получает к нему доступ.
  • Настройте тревогу на массовое чтение, необычный объём ответа и запросы через непривычную учётную запись.

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

Практический вывод

Локальное размещение закрывает важную внешнюю границу, но векторный индекс остаётся базой производных данных. Его нельзя автоматически объявить обезличенным только потому, что человек не читает вектор глазами. Минимизируйте текст до индексации, закрывайте сетевой доступ, включайте TLS и аутентификацию, разделяйте ключи, применяйте ACL на сервере, защищайте payload и snapshots, проверяйте массовые выгрузки и проектируйте полное удаление.

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