Отримання за асоціацією: когнітивна модель, заснована на пам’яті, для векторного пошуку

Можуть минути роки, і не з’явиться жодної думки про вчителя з дитинства. А потім аромат порошку від крейди, запах шкільної їдальні чи пісня, яка лунала під час поїздки додому автобусом, миттєво та яскраво повертають цю людину у пам’яті. Імена ніхто не шукав — з’явилась щось схоже, і спогад сам по собі виник.

Саме це намагаються відтворити семантичні пошукові системи, технології отримання інформації з підкріпленням (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 — це приклади таких бібліотек. Ви завантажуєте в них ембеддинги документів, описи продуктів, зображення, перетворені на вектори, або шаблони поведінки користувачів, і вони підтримують індекс, щоб пошук залишався швидким навіть у міру зростання колекції.

Кожен збережений запис зазвичай складається з трьох частин:

• ID, який унікально ідентифікує елемент.
• Вектор, який представляє його значення.
• Необов’язкові метадані, такі як назва, дата, категорія чи URL джерела, які можна використовувати для фільтрації результатів.

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

Повний процес отримання даних

Незалежно від того, чи це система RAG, функція семантичного пошуку чи будь-який інший додаток, який використовує збережені знання, процес отримання даних складається з однакових чотирьох кроків.

1. Вбудовування контенту. Кожен документ, стаття, опис продукту чи запис, які потрібно зробити пошуковими, проходять через модель вбудовування, а отриманий вектор зберігається разом із початковим контентом. Довгі документи зазвичай спочатку розділяються на частини, оскільки один вектор для всього посібника змішує занадто багато ідей.
2. Вбудовування запиту за допомогою тієї ж моделі. Це не є факультативним. Різні моделі вбудовування створюють вектори у непов’язаних просторах, тому порівняння запиту від однієї моделі з документами іншої призводить до беззмістовних значень відстаней. Зміна моделі означає повторне вбудовування всього набору даних.
3. Пошук. Вектор запиту надсилається до бази даних, алгоритм пошуку найближчих сусідів знаходить найближчі збережені вектори, і повертаються найкращі результати, зазвичай разом із показниками схожості.

Використовуйте результати. У підході RAG отримані уривки тексту передаються мовній моделі як контекст, тож відповідь ґрунтується на реальних документах, а не на припущеннях. У системах рекомендацій результати — це самі рекомендації. У функціях пошуку вони — це результати пошуку, які відображаються користувачеві.

З точки зору користувача, релевантна відповідь з’являється протягом кількох секунд. По-перше, значення перетворюються на числа; ці числа порівнюються з мільйонами збережених елементів, повертаються найбільш схожі результати, а потім формується відповідь на основі справжнього контенту.

Чому векторний пошук зараз всюди

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

Якщо ви розробляєте продукти на основі великих мовних моделей у промислових умовах, існує велика ймовірність того, що ви вже користуєтесь векторним пошуком або скоро почнете це робити. Позитивно те, що основна ідея вже знайома: ще з давніх-давен пам’ять знаходила найближчі асоціації до того, що потрапляло на наші відчуття. Векторна база даних робить те саме з числами, протягом кількох мілісекунд, з мільйонами елементів.

Де руйнується аналогія з пам’яттю

• Пам’ять постійно адаптується; модель ембеддингу залишається незмінною. Якщо змінюється словниковий запас вашої галузі, вектори не оновлюються самостійно.
• Пам’ять легко поєднує контекст; вектор фіксує лише те, що потрапило до нього. Погано розділений або зі шумом джерельний текст створює погані «сусіди».
• Схожість не означає релевантності. Два уривки можуть бути схожими за змістом, проте лише один насправді відповідає на запитання, тому багато систем додають пошук за ключовими словами або етап переранжування.

Практичні вправи

• ChromaDB працює локально всередині Python без необхідності створення облікового запису, API-клуча чи розгортання, і для його встановлення та налаштування потрібно лише кілька рядків коду. Він ідеально підходить для навчання та невеликих проектів.
• Qdrant пропонує безкоштовний хмарний рівень та зручний Python-клієнт, що є гарним вибором, якщо потрібно щось близьке до продакшн-середовища без необхідності самостійного керування серверами. Перед тим, як покладатися на ці можливості, перевірте поточні обмеження рівня.
• pgvector — це розширення для Postgres. Якщо ви вже використовуєте Postgres, воно додає функції векторного пошуку без створення окремої бази даних, що спрощує архітектуру.

Який би варіант ви не обрали, процес роботи залишається однаковим: обираєте модель ембеддингу, ембеддують ваш контент, зберігаються вектори, ембеддуються вхідні запити та виконується пошук. Концепції залишаються незмінними; змінюється лише бібліотека клієнта.

Та сама модель з обох боків оцінки

Косинусна близькість має сенс лише коли запит і фрагмент закодовані однією моделлю.

def cosine(a: list[float], b: list[float]) -> float:
    dot = sum(x * y for x, y in zip(a, b))
    na = sum(x * x for x in a) ** 0.5
    nb = sum(y * y for y in b) ** 0.5
    if na == 0 or nb == 0:
        return 0.0
    return dot / (na * nb)

# query and passage must come from the same embedding model
score = cosine(embed(query), embed(passage))

Фільтр метаданих стоїть до пошуку сусідів: він вирішує, хто потрапляє в набір кандидатів.

hits = collection.query(
    query_embeddings=[embed(query)],
    n_results=8,
    where={"tenant_id": tenant_id},
)

Основні висновки

• Ембеддинги перетворюють значення на координати, тож схожі елементи опиняються поруч один з одним.
• Оцінки схожості визначають порядок кандидатів; налаштовуйте пороги на основі власних даних.
• Індекси ANN, такі як HNSW, жертвують невеликою частиною точності заради значного прискорення при великих обсягах даних.
• Фільтри метаданих перетворюють первинну інформацію про схожість у відповіді, які дотримуються правил щодо часу, джерела та доступу.
• Запити та документи мають використовувати одну й ту саму модель ембеддингів, а якість пошуку залежить так само від способу розділення даних та їхньої якості, як і від самої бази даних.