Технічний контекст
Я заглибився в цей paper не з простої цікавості. Коли я розробляю AI-інтеграції або проєктую пошук на основі векторної БД, ембединги зазвичай вважають «менш небезпечною» формою даних. Після vec2vec я б уже так не розслаблявся.
Суть роботи дуже неприємна в хорошому інженерному сенсі: автори показали, що вектори з однієї embedding-моделі можна перевести в простір іншої моделі взагалі без парних прикладів, без доступу до вихідного енкодера і без оригінальних текстів. Вони спираються на ідею спільної геометрії представлень, і, схоже, це не філософія, а цілком робоча атака.
Я б описав це так: у вас стався витік векторної бази, де зберігаються лише embeddings. Раніше багато хто подумки ставив галочку «ну це ж не plaintext». А тут беруть ці вектори, навчають відображення в простір іншої, вже доступної моделі, і далі використовують цю другу модель для inference або часткового відновлення вмісту.
У paper фігурує метод vec2vec. Він будує універсальний латентний простір і вчиться переводити туди embeddings з невідомої моделі, а потім назад у простір відомої. Ключовий момент у тому, що для калібрування вистачає синтетичного тексту та query-доступу до цільової моделі.
Мене особливо зачепило не те, що cosine similarity після перенесення виходить пристойною. Мене зачепило, що цієї якості вже вистачає для практичної атаки: атрибутивна інференція, тематична реконструкція, витягування чутливих ознак з медичних та email-даних. Тобто витекли не документи, а наслідки все одно дуже близькі до витоку сенсу.
І так, це не новина «сьогодні вийшло». Препринт з'явився у травні 2025, остання версія оновлювалася в січні 2026. Але саме зараз його варто читати як нормальний security baseline, а не як красиву дослідницьку екзотику.
Що це змінює для бізнесу та автоматизації
Перше: зберігати embeddings так, ніби це знеособлені дані, на мій погляд, більше не можна. Якщо у вас AI automation зав'язана на RAG, semantic search, support-routing або аналіз листів, векторна БД стає об'єктом такого ж серйозного захисту, як і вихідні тексти.
Друге: ламається наївна архітектура «сховаємо вихідну модель, і цього вистачить». Не вистачить. Якщо геометрія представлень переноситься, то безпека через неясність (security through obscurity) тут працює слабко.
Третє: доведеться обирати між якістю retrieval та захистом. Шум, спотворення геометрії, сегментація доступу, шифрування, більш жорсткі політики retention. Все це б'є по latency, релевантності або вартості, але ігнорувати ризик уже дивно.
Ми в Nahornyi AI Lab якраз розбираємо такі місця на практиці: де AI solutions architecture виглядає красиво на схемі, а потім раптово протікає через embeddings. Якщо у вашому бізнесі вже працює векторний пошук або агентні пайплайни, давайте подивимося на вашу архітектуру тверезо і зберемо AI automation так, щоб вона прискорювала процеси, а не створювала тихий витік даних.