«Мы храним векторы, а не ваши документы» — почти всегда неправда

Спросите поставщика ИИ-решения, что происходит с загруженными документами, и часто услышите что-то вроде: «Мы не храним ваши документы. Мы превращаем их в векторы, списки чисел, чтобы по ним можно было искать». Звучит успокаивающе. Будто ваш контент прошёл через дверь в одну сторону и вышел чистой математикой. Тот, кто это говорит, обычно не врёт. Но почти в любой системе поиска это утверждение ложно, и понимание того, почему, меняет вопросы, которые стоит задавать. Проверить это можно самому минуты за две.

Что происходит с загруженным файлом

Конвейер поиска делает с файлом четыре вещи:

1. Извлекает текст.
2. Режет текст на чанки, обычно по несколько сотен слов, потому что весь документ слишком велик, чтобы отдать его модели.
3. Строит эмбеддинг для каждого чанка, превращая его в список чисел, который примерно передаёт, о чём этот фрагмент.
4. Сохраняет чанки, чтобы по ним можно было искать.

Именно эмбеддинги заставляют поиск работать. Ваш вопрос тоже превращается в эмбеддинг, и система ищет чанки, чьи числа ближе всего к числам вопроса.

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

Как это выглядит в базе данных

Таблица, где живут чанки, скучная, и в этом весь смысл: почти у каждого продукта для поиска есть таблица примерно такого вида:

create table document_chunks (
  id           uuid primary key,
  document_id  uuid not null,
  chunk_index  integer not null,
  content      text not null,      -- the passage, as text
  embedding    vector(1024),       -- the numbers, alongside it
  metadata     jsonb
);

Посмотрите на две колонки. В content лежат ваши слова, в embedding — числа. Хранятся они рядом.

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

Почему успокаивающую версию повторяют

Редко из нечестности. Обычно причина одна из трёх.

Говорящий имеет в виду файл. Многие продукты действительно удаляют загруженный PDF, как только извлечение закончено. Это хорошая практика, и «мы не храним ваши документы» — допустимое сокращение, когда все понимают, о чём речь. Беда в том, что слушатель понял нечто гораздо более сильное.

Эмбеддинги звучат необратимо, поэтому люди решают, что текста больше нет. Обратить эмбеддинг действительно трудно. Но то, что числа трудно обратить, ничего не говорит о том, сохранились ли слова, а в системе поиска они сохранились, иначе продукт перестал бы работать.

Никто не задал уточняющий вопрос. «Мы храним векторы» завершает разговор на приятной ноте. Полезный вопрос не в том, хранятся ли векторы. А в том, что ещё лежит в той же строке.

Проверка за две минуты

Так можно проверить любого поставщика, и для этого не нужно быть технарём.

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

Спросите, могут ли сотрудники с доступом к продакшену прочитать текст загруженного вами документа. Почти для любого продукта с поиском честный ответ — да, с ограничениями по правам и журналами аудита. Если поставщик говорит «нет», выясните, за счёт чего. Правдоподобный механизм — ключи шифрования, которых у поставщика никогда нет. Эмбеддинги не в счёт.

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

Это не ловушки. Они дают точную картину вместо удобной.

О чём спрашивать вместо этого

Как только вы принимаете, что текст хранится, вопрос «наш контент правда там?» перестаёт быть главным. Важнее вот эти:

• Кто может до него добраться? Доступ должен выдаваться на уровне проекта или документа, а не всей компании.
• Что ушло за пределы системы? Какие фрагменты отправлялись в вызове модели и что было замаскировано перед отправкой?
• Что удаляется и когда? Распространяется ли удаление на производные данные или только на исходную загрузку?
• Правильно ли понимается заявление о шифровании? Шифрование при хранении защищает от украденного диска или утечки слоя хранилища. Оно ничего не говорит о том, может ли сам поставщик открыть ваш текст, и поставщик, который позволяет вам думать иначе, вводит вас в заблуждение умолчанием.

На все эти вопросы можно ответить и всё это можно проверить, и именно это по-настоящему защищает документ. «Это просто числа» не защищает ничего, потому что защищало никогда не это.

Как звучит честный ответ

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

Последнее важно. Альтернатива — фраза, которую проверяющий опровергнет одним запросом, а поставщику, пойманному на успокаивающей неправде в простом вопросе, не поверят и в сложном.

Коротко

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