«Ми зберігаємо вектори, а не ваші документи» — майже завжди неправда

Запитайте постачальника ШІ-рішення, що відбувається із завантаженими документами, і часто почуєте щось на зразок: «Ми не зберігаємо ваші документи. Ми перетворюємо їх на вектори, списки чисел, щоб у них можна було шукати». Звучить заспокійливо. Ніби ваш контент пройшов крізь двері в один бік і вийшов чистою математикою. Той, хто це каже, зазвичай не бреше. Але майже в будь-якій системі пошуку це твердження хибне, і розуміння того, чому, змінює питання, які варто ставити. Перевірити це можна самому хвилини за дві.

Що відбувається із завантаженим файлом

Конвеєр пошуку робить із файлом чотири речі:

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-адрес і телефонів за замовчуванням маскуються, перш ніж щось надсилається в модель. І так, постачальник може прочитати збережений текст, про що добра сторінка про безпеку каже прямо.

Останнє важливо. Альтернатива — фраза, яку перевіряльник спростує одним запитом, а постачальникові, якого спіймали на заспокійливій неправді в простому питанні, не повірять і в складному.

Коротко

Майже жоден продукт із пошуком не перетворює документи на числа, щоб потім викинути слова: щоб вам відповісти, слова треба повернути. Тож з'ясуйте, звідки береться формулювання цитати, а потім оцінюйте постачальника за тим, хто має доступ, що маскується і як працює видалення. Слоган про вектори мало що каже.