Як працює база даних векторів: ембеддинги, пошук векторів та людська пам’ять
Модель мислення, заснована на пам’яті, для пошуку векторів: як працюють ембеддинги, подібність, індекси найближчих сусідів та фільтри метаданих у базі даних векторів для RAG.
Джерела: Your Brain Is a Vector Database. It Just Doesn’t Call Itself That.
Можуть минути роки, і не з’явиться жодної думки про вчителя з дитинства. А потім аромат порошку від крейди, запах шкільної їдальні чи пісня, яка лунала під час поїздки додому автобусом, миттєво та яскраво повертають ту людину. Імена ніхто не шукав — з’явилось щось схоже, і спогад сам по собі виник.
Саме це намагаються відтворити семантичні пошукові системи, системи генерації з підтримкою пошуку (RAG) та системи рекомендацій ШІ, хоча й недосконало, але серйозно, а ключовим елементом, який це уможливлює, є векторна база даних. Механізм відтворення спогадів через асоціації створює гарну уявну модель для пояснення того, що таке вектори, як вимірюється схожість, як функціонує пошук найближчих сусідів та як усі ці елементи утворюють процес пошуку інформації. Він також вказує на ті місця, де аналогія більше не працює, адже саме там системи виробничого призначення схильні до помилок.
Зберігання за значенням замість за назвою
Людська пам’ять не має алфавітного індексу. Не існує психічної папки під назвою „Їжа“, яка б містила підпапку „Італійська“ з файлом під назвою „Піца“. Саме така сувора ієрархія використовується традиційними базами даних для організації інформації: кожен запис знаходиться за відомою адресою та може бути знайдений за точним ключем.
Натомість пам’ять організована за значенням та асоціаціями: за контекстом, почуттями, способом взаємозв’язку різних речей. Ідея піци асоціюється з п’ятничними вечорами, поїздкою до Неаполя, затишною їжею, смужками сиру, ароматом орегано, а можливо, ще й з сусідом по кімнаті в коледжі, який зіпсував кожну порцію домашнього тіста. Думки про піцу не відкривають окремий файл — вони активують цілу мережу пов’язаних спогадів, причому спочатку ті, що асоціюються найсильніше.
База даних векторів ґрунтується саме на цьому принципі. Елементи зберігаються відповідно до їхнього значення, а їх отримують за критерієм схожості з запитом, а не за тим, чи точно збігається ключ.
Що кодує вектор вбудовування
Щоб зрозуміти базу даних, спочатку потрібно зрозуміти, що вона містить. Вектор тут — це просто впорядкований список чисел, який представляє значення.
Машина не має живого розуміння того, що таке піца. Модель вбудовування може навчитися, обробляючи величезні обсяги тексту, того значення, яке слово несе. Слово „піца“ з’являється поруч із словами „сир“, „італійський“, „тісто“, „духовка“ та „скибка“. Це оточення відрізняється від оточення слова „суші“, але сильно перетинається з оточенням слів „плоский хліб“ чи „кальцоне“.
Модель сконденсує ці закономірності у список чисел фіксованої довжини — зазвичай від кількох сотень до кількох тисяч значень; типовими розмірами є 384 та 1 536. Жодне окреме число не має читабельної позначки, проте разом вони точно визначають положення елемента у високорозмірному просторі. Важлива властивість полягає у наступному: вхідні дані з схожим значенням утворюють вектори, які знаходяться близько один до одного. „Піца“ опиняється поблизу „плоского хліба“ та дуже далеко від „квартального звіту про прибутки“.
Іншими словами, значення перетворюється на відстань. Усе інше тут випливає з цього єдиного кроку.
Схожість як спектр, а не збіг
Традиційний запит є бінарним: рядок або відповідає умові, або ні. Якщо фільтрувати за „собакою“, отримаються рядки, які містять саме „собаку“, але не буде нічого для „цуценята“, „золотистого ретривера“ чи „вірного чотирилапого супутника“.
Семантична схожість замінює цю відповідь „так“ чи „ні“ на оцінку, яка показує, наскільки близькі два значення. За ілюстративною шкалою „цуценя“ може мати оцінку 0,94 порівняно з „собакою“, „вовк“ — приблизно 0,71, а „рахунок-фактура“ — близько 0,08. Як правило, використовується косинусна схожість або пов’язана відстань, така як скалярний добуток чи евклідова відстань, причому правильний вибір залежить від того, як була навчена модель вбудовування.
Це відображає ефект порошку від крейди: це не точне збіг, а сигнал, який активує сусідні спогади, а ті, у свою чергу, активують ще сусідні. У векторній базі даних механізм є числовим. Запит перетворюється на вектор, і база даних повертає збережені елементи, вектори яких знаходяться найближче до нього. „Близько“ означає схожість у значенні.
Ось чому пошук фрази „як виправити повільний запит до бази даних“ може вивести документ під назвою „оптимізація продуктивності запитів у великих масштабах“, хоча ці дві фрази майже не мають спільних слів. Їхні вектори знаходяться близько один до одного, тому що вони виражають однакову мету.
Зауваження щодо чисел
Оцінки схожості є відносними, а не абсолютними. Значення 0,8 від однієї моделі ембеддингів не можна порівнювати з значенням 0,8 від іншої, а навіть у межах однієї моделі типовий діапазон залежить від сфери застосування. Використовуйте ці оцінки як спосіб класифікації кандидатів, а якщо ви встановлюєте поріг, налаштовуйте його на основі власних даних, а не обираючи кругле число.
Пов’язана корекція: звичайний SQL, заснований на ключових словах, не може виражати семантичну схожість, але це не означає, що бази даних SQL виключаються з використання. Розширення, такі як pgvector, про які йтиметься далі, додають до Postgres векторні стовпці та оператори схожості, тож ця функціональність може існувати всередині реляційної бази даних.
Пошук найближчого сусіда у масштабі
Як саме база даних знаходить найближчі вектори? Основною операцією є пошук найближчого сусіда, і саме швидкість виконання цієї операції є головною причиною існування векторних баз даних.
Уявіть кожен збережений елемент як зірку в галактиці, розташовану відповідно до її значення, причому пов’язані елементи збираються в одному регіоні. Запит додає нову зірку до цієї галактики та запитує, які п’ять існуючих зірок знаходяться найближче.
Простий підхід вимірює відстань від запиту до кожного збереженого вектора, сортує результати та повертає кілька найкращих. Для тисяч векторів це швидко та цілком достатньо. Однак для мільйонів чи мільярдів порівняння з усіма елементами дуже швидко стає дорогим.
Тож системи обробки даних спираються на алгоритми найближчого сусіда з наближеним підрахунком. Замість того, щоб перевіряти кожну зірку, вони використовують індекс, який звужує пошук до перспективних регіонів, йдучи на незначну втрату точності заради значного прискорення. Найпоширенішим алгоритмом сьогодні є HNSW — скорочення від Hierarchical Navigable Small World. Щоб користуватися базою даних векторів, не обов’язково знати її внутрішню структуру, але варто знати, що саме цей алгоритм дозволяє отримати результати пошуку серед сотень мільйонів ембеддингів протягом кількох мілісекунд.
Поняття „приблизний“ заслуговує уваги. Індекс ANN іноді може пропустити справжнього найближчого сусіда, а швидкість знаходження справжніх найкращих результатів, яку називають реколом, залежить від параметрів індексу, які досягають балансу між пам’яттю, затримкою та точністю. Якщо якість пошуку здається незрозуміло нерівномірною у великих масштабах, варто перевірити налаштування індексу; наш посібник з налаштування індексів HNSW для виробничих систем RAG детально розглядає ці параметри.
Усередині векторної бази даних
По суті, векторна база даних — це сховище, оптимізоване для однієї задачі: зберігання векторів та дуже швидкого виконання пошуків найближчих сусідів серед них.
Уявіть бібліотеку, яка ігнорує Деуїву десяткову систему та розміщує книги за їхнім внутрішнім змістом. Книги про скорботу знаходяться поруч із книгами про втрату, які, у свою чергу, знаходяться поруч із книгами про самотність, потім про ізоляцію, а далі — з мемуарами про сольові експедиції. Ніхто не присвоював ці категорії вручну; така структура виникла тому, що читачі, які цікавляться однією темою, зазвичай хочуть ознайомитися й з іншими.
Pinecone, Weaviate, Chroma та Qdrant — це приклади таких бібліотек. Ви завантажуєте в них ембеддинги документів, описи продуктів, зображення, перетворені на вектори, або патерни поведінки користувачів, і вони підтримують індекс, щоб пошук залишався швидким навіть у міру зростання колекції.
Кожен збережений запис зазвичай складається з трьох частин:
- Ідентифікатор, який унікально визначає елемент.
- Вектор, який представляє його значення.
- Необов’язкові метадані, такі як назва, дата, категорія чи URL джерела, які можна використовувати для фільтрації результатів.
Метадані мають більшу цінність, ніж здається на перший погляд. Реалістичний запит виглядає так: знайти п’ять документів, які найбільш схожі на запит, але лише ті, що були створені протягом останніх 30 днів та знаходяться лише у базі знань інженерної команди. Це поєднання векторного пошуку та фільтра метаданих, і більшість продакшн-систем спираються саме на таке поєднання. Також важливо, як застосовується фільтр: фільтрація після пошуку схожості може залишити менше результатів, ніж ви просили, тому перевірте, чи ваша база даних фільтрує під час самого пошуку.
Повний процес отримання даних у RAG
Незалежно від того, чи це частина системи RAG, функції семантичного пошуку чи будь-якого додатку, який використовує збережені знання, процес отримання даних проходить за однаковими чотирма кроками.
- Вбудовування контенту. Кожен документ, стаття, опис продукту чи запис, які потрібно зробити пошуковими, проходять через модель вбудовування, а отриманий вектор зберігається разом із початковим контентом. Довгі документи зазвичай спочатку діляться на частини, оскільки один вектор для всього посібника змішує занадто багато ідей.
- Вбудовування запиту за допомогою тієї самої моделі. Це не є необов’язковим. Різні моделі вбудовування створюють вектори у непов’язаних просторах, тому порівняння запиту від однієї моделі з документами від іншої дає беззмістовні значення відстаней. Зміна моделі означає повторне вбудовування всієї колекції.
- Пошук. Вектор запиту надсилається до бази даних, алгоритм пошуку найближчих сусідів знаходить найближчі збережені вектори, і повертаються найкращі результати, зазвичай із показниками схожості.
З точки зору користувача, релевантна відповідь з’являється протягом кількох секунд. Під час цього значення перетворюються на числа, ці числа порівнюються з мільйонами збережених елементів, повертаються найбільш близькі результати, а відповідь формується на основі справжнього контенту.
Чому векторний пошук зараз всюди
Не так давно векторні бази даних були нішевим інструментом, який використовували лише під час створення семантичних пошукових систем чи спеціалізованих рекомендаційних механізмів. Тепер вони є стандартною частиною багатьох ШІ-застосунків. Технологія RAG потребує місця для зберігання та пошуку ембеддингів документів. Агенти здійснюють пошук у базах знань на основі значень. Масштабні рекомендації працюють за принципом векторної схожості. Багатомодальний пошук, наприклад пошук зображень за текстовим описом чи товарів за завантаженою фотографією, також здійснюється за допомогою векторів.
Якщо ви розробляєте продукти на основі великих мовних моделей у промислових умовах, існує велика ймовірність, що ви вже використовуєте векторний пошук або скоро почнете це робити. Позитивним моментом є те, що основна ідея вже знайома: ще з давніх-давен пам’ять знаходила найближчі асоціації до того, що потрапляло до наших відчуттів. Векторна база даних робить те саме з числами, протягом кількох мілісекунд, з мільйонами елементів.
Де руйнується аналогія з пам’яттю
Порівняння з мозком корисне для інтуїції, але на практиці мають значення деякі відмінності:
- Пам’ять постійно адаптується; модель ембеддингів залишається незмінною. Якщо змінюється словниковий запас вашої галузі, вектори не оновлюються самостійно.
- Пам’ять легко поєднує контекст; вектор фіксує лише те, що потрапило до нього. Погано розділений або зі шумом джерельний текст створює погані «сусіди».
- Схожість не означає релевантності. Два уривки можуть бути схожими за змістом, проте лише один насправді відповідає на запитання, тому багато систем додають пошук за ключовими словами або етап переранжування.
Практичні вправи
Ви можете експериментувати, не створюючи жодної інфраструктури:
- ChromaDB працює локально всередині Python без необхідності створення облікового запису, API-клуча чи розгортання, і для його встановлення та налаштування потрібно лише кілька рядків коду. Він ідеально підходить для навчання та невеликих проектів.
- Qdrant пропонує безкоштовний хмарний рівень та зручний Python-клієнт, що є гарним варіантом, якщо ви хочете щось на кшталт продакшн-середовища, не керуючи серверами особисто. Перевірте поточні обмеження рівня перед тим, як покладатися на них.
- pgvector — це розширення для Postgres. Якщо ви вже використовуєте Postgres, воно додає функції векторного пошуку без необхідності створення окремої бази даних, що спрощує архітектуру.
Який би варіант ви не обрали, процес роботи залишається однаковим: обираєте модель ембеддингу, ембеддуєте свій контент, зберігаєте вектори, ембеддуєте вхідні запити та здійснюєте пошук. Концепції залишаються незмінними; змінюється лише бібліотека клієнта.
Короткий опис ментальної моделі
- Ембеддинги перетворюють значення на координати, тож схожі елементи опиняються поруч один з одним.
- Оцінки схожості визначають порядок кандидатів; налаштовуйте пороги на основі власних даних.
- Індекси ANN, такі як HNSW, жертвують певною частиною точності заради значного прискорення при великих обсягах даних.
- Фільтри метаданих перетворюють первинні показники схожості на відповіді, які дотримуються правил щодо часу, джерела та доступу.
- Запити та документи мають використовувати одну й ту саму модель ембеддингів, а якість пошуку залежить як від бази даних, так і від способу розділення даних на частини та їхньої якості.
Пов’язана література
- Як насправді працюють векторні бази даних: від ембеддингів до гібридного пошуку: Пояснює, як ембеддинги кодують значення, як масштабуються пошук за схожістю та індексування, та коли гібридний пошук та векторні бази даних справді підходять для корпоративних систем штучного інтелекту.