Векторна база даних зберігає не просто текстові записи чи поля таблиць, а числові представлення змісту — ембединги. Вона індексує такі дані та швидко знаходить об’єкти, близькі до заданого вектора. Нижче розглянуто будову векторного пошуку, метрики, ANN-алгоритми, відмінності від класичних СУБД і практичне використання у RAG та системах на основі LLM.
Що таке векторна база даних і навіщо вона потрібна
Векторна база даних — це спеціалізована СУБД, призначена для збереження, індексації та швидкого семантичного пошуку багатовимірних числових векторів, або ембедингів. Ембединг — це масив чисел фіксованої розмірності, який кодує зміст тексту, зображення, аудіофайлу чи іншого об’єкта. Нейромережа перетворює вхідні дані на такий масив під час роботи моделі-енкодера.
Наприклад, модель для тексту може подати речення у вигляді вектора з сотнями або тисячами координат. Схожі за змістом речення зазвичай опиняються близько одне до одного у векторному просторі, навіть якщо в них немає однакових ключових слів. Для зображень і аудіо діє той самий принцип: модель виділяє ознаки та кодує їх у числове представлення.
Векторний простір можна уявляти як карту, де кожен об’єкт має власну точку. У двовимірній схемі відстань між точками легко побачити, а в реальній системі таких координат може бути 384, 768, 1536 або більше. База даних отримує вектор запиту, порівнює його з індексом і повертає найближчі записи разом із метаданими.
Таке зберігання потрібне тоді, коли запит має знаходити не точний збіг, а релевантний зміст. Пошук «як оформити відпустку» може повернути документ із фразою «порядок подання заяви на щорічну відпустку», хоча слова запиту та документа відрізняються. Це робить векторні бази корисними для пошуку знань, рекомендацій і генеративних застосунків.
Відмінності векторних баз даних від класичних реляційних СУБД
Реляційні СУБД добре працюють із чітко структурованими даними: рядками, числами, датами та зв’язками між таблицями. Запити на кшталт WHERE id = 5 або фільтрація за точним значенням використовують індекси B-Tree та повертають записи, що відповідають заданій умові. Запит LIKE '%текст%' шукає збіг символів, але не розуміє змісту фрази.
Векторна база орієнтована на пошук найближчих сусідів у просторі з великою кількістю вимірів. Результат визначається метрикою близькості, а не рівністю значень у конкретному полі. Документ може бути релевантним через спільну тему, навіть коли в ньому немає дослівного повторення запиту.
Документні сховища зберігають записи у гнучких структурах на кшталт JSON і зручні для даних зі змінною схемою. Однак сам факт зберігання JSON не забезпечує ефективного пошуку семантично близьких ембедингів. Векторний рушій використовує спеціальні індекси та обчислення для багатовимірних масивів.
| Критерій | Реляційні СУБД (SQL) | Векторні бази даних |
|---|---|---|
| Тип даних | Табличні поля: числа, рядки, дати, зв’язки | Вектори фіксованої розмірності разом із метаданими |
| Тип запиту / пошуку | Точні умови, діапазони, JOIN, текстовий збіг | Пошук k найближчих сусідів за вектором запиту |
| Структура індексів | B-Tree, Hash, повнотекстові індекси | HNSW, IVF, PQ, LSH та їхні комбінації |
| Обчислювальне навантаження | Виконання умов над полями та операцій над таблицями | Порівняння багатовимірних векторів і навігація спеціальним індексом |
| Результат видачі | Рядки, що відповідають умові запиту | Впорядкований список найбільш схожих об’єктів із оцінкою близькості |
На практиці часто застосовують гібридний пошук. Спочатку система знаходить семантично близькі записи, а потім відкидає документи, які не відповідають фільтрам за мовою, датою, відділом або рівнем доступу. Такий підхід поєднує змістовну релевантність із контролем структурованих атрибутів.
Як працює векторний пошук: метрики відстані та схожості
Щоб порівняти два ембединги, система обчислює відстань або міру подібності між ними. Вибір формули впливає на порядок результатів, поріг релевантності та поведінку індексу. Одна й та сама пара векторів може отримати різні оцінки за косинусною, евклідовою метрикою або скалярним добутком.
Косинусна схожість порівнює напрямки векторів, а евклідова відстань враховує їхнє положення та довжину. Скалярний добуток також залежить від магнітуди, якщо вектори не нормалізовані. Тому метрику задають не довільно, а відповідно до того, як навчалася модель ембедингів.
- Косинусна схожість (Cosine Similarity): косинус кута між векторами зі значенням від -1 до 1; не враховує довжину вектора та часто застосовується для NLP-ембедингів.
- Евклідова відстань (Euclidean Distance / L2 norm): пряма геометрична відстань між точками; чутлива до магнітуди, тобто довжини векторів.
- Скалярний добуток (Dot Product / Inner Product): добуток довжин двох векторів і косинуса кута між ними; особливо зручний для нормалізованих векторів.
- Мангеттенська відстань (Manhattan Distance / L1 norm): сума абсолютних різниць координат за всіма вимірами.
Для нормалізованих векторів косинусна схожість і скалярний добуток можуть давати однаковий порядок результатів, хоча числові значення інтерпретуються по-різному. Якщо модель генерує ембединги з інформацією про магнітуду, заміна метрики на косинусну може погіршити релевантність. Перевіряти вибір слід на тестовому наборі запитів із розміченими правильними відповідями.
Алгоритми індексації векторів та пошук найближчих сусідів (ANN)
Точний пошук k-NN порівнює вектор запиту з усіма N записами, тому його базова складність зростає як O(N). Для мільйонів або мільярдів ембедингів повний перебір створює неприйнятну затримку. Через це в продакшені застосовують Approximate Nearest Neighbor, або ANN, — наближений пошук найближчих сусідів із контрольованим компромісом між швидкістю та повнотою результатів.
Ключовий інженерний компроміс ANN має три сторони: latency, recall і RAM footprint. Нижча затримка часто означає, що алгоритм перевіряє менше кандидатів, тому може пропустити частину справді найближчих векторів. Підвищення recall зазвичай потребує більшого графа, ширшого пошуку або додаткової пам’яті.
HNSW (Hierarchical Navigable Small World) будує багатошаровий граф. Верхні шари містять довгі зв’язки для швидкого переходу в потрібну область, а нижні дають детальнішу навігацію між сусідніми векторами. Параметри побудови та пошуку визначають обсяг пам’яті, час індексації й recall.
IVF (Inverted File Index) спочатку ділить простір на кластери, зазвичай через центроїди. Для нового запиту система визначає найближчі кластери та шукає кандидатів лише в них, а не в усій колекції. Що більше кластерів перевіряється, то вищою може бути повнота видачі, але зростає latency.
PQ (Product Quantization) розбиває вектор на частини та кодує кожну частину компактним числовим представленням. Стиснення скорочує RAM footprint і дає змогу зберігати більші індекси, хоча втрата точності може зменшити recall. PQ часто комбінують з IVF для масштабних колекцій.
LSH (Locality-Sensitive Hashing) використовує спеціальні хеш-функції, які з високою ймовірністю відправляють схожі вектори в один бакет. Пошук обмежується відповідними бакетами, що зменшує кількість порівнянь. Якість залежить від кількості хеш-таблиць, розмірів бакетів і вибраної схеми хешування.
Параметри ANN підбирають на реальних даних, а не лише за документацією рушія. Для цього вимірюють p95 або p99 latency, recall@k, обсяг пам’яті та час оновлення індексу. Оптимальна конфігурація для коротких текстів може виявитися невдалою для зображень або довгих документів.
Огляд популярних векторних баз даних та плагінів
Вибір рішення залежить від обсягу колекції, кількості запитів, вимог до фільтрації та допустимої складності інфраструктури. Частина продуктів спеціалізується на векторному пошуку, інші додають його до вже наявної пошукової або реляційної платформи. Нижче наведено основні варіанти.
Під час оцінювання перевіряйте не тільки швидкість пошуку. Для продакшену також мають значення механізми резервування, оновлення індексів, масштабування, фільтрація за payload або метаданими та спосіб контролю витрат.
- Pinecone: повністю керована хмарна серверлес-СУБД із закритим кодом для високопродуктивного продакшену.
- Milvus: розподілена система з відкритим кодом за ліцензією Apache 2.0, оптимізована для масивів на мільярди векторів.
- Qdrant: швидка векторна база на Rust із відкритим кодом за ліцензією Apache 2.0, складною фільтрацією та payload.
- Weaviate: модульна векторна база з відкритим кодом за ліцензією BSD 3-Clause, вбудованими ML-пайплайнами та гібридним пошуком.
- Chroma: легковагове сховище з відкритим кодом за ліцензією Apache 2.0 для локального прототипування AI-застосунків.
- PostgreSQL з pgvector: розширення з відкритим кодом, яке додає зберігання ембедингів і векторний пошук до реляційної бази PostgreSQL.
- Elasticsearch: розподілений пошуковий рушій із підтримкою векторних запитів і гібридного пошуку.
- Redis Vector Similarity: in-memory база для низьколатентного пошуку векторів; доступна також як частина Redis Cloud.
- Vespa: рушій обробки великих даних і векторного пошуку з відкритим кодом за ліцензією Apache 2.0, що походить із пошукових технологій Yahoo.
- SurrealDB: багатомодельна СУБД із нативною підтримкою векторних операцій.
pgvector зазвичай достатньо для невеликих і середніх навантажень, коли основні дані вже живуть у PostgreSQL. Ви зберігаєте транзакції, права доступу та ембединги в одному середовищі без окремого кластера. Це спрощує розробку, але під час зростання RPS потрібно окремо перевіряти вплив індексації на основні SQL-запити.
Виділена база на кшталт Qdrant, Milvus або Pinecone доречна для високих RPS, мільйонних і більших векторних просторів та незалежного масштабування пошукового шару. Qdrant і Milvus дають більше контролю під час самостійного розгортання, а Pinecone зменшує операційне навантаження завдяки керованій моделі. Остаточний вибір варто робити після навантажувального тестування з вашими розмірами векторів і фільтрами.
Сценарії застосування векторних баз даних у штучному інтелекті
Станом на 2026 рік векторні СУБД стали базовим інфраструктурним рівнем корпоративного ШІ. Їх використовують як окреме сховище ембедингів або як векторний шар у PostgreSQL, Elasticsearch чи іншій платформі. Ключова роль бази — швидко повернути релевантні об’єкти для наступного етапу обробки моделлю.
Векторна база не замінює LLM і не генерує відповідь самостійно. Вона відповідає за зберігання представлень даних, пошук кандидатів і повернення пов’язаних метаданих. Якість усієї системи залежить також від моделі ембедингів, розбиття документів на фрагменти, фільтрів і шаблону запиту до генеративної моделі.
В архітектурі RAG (Retrieval-Augmented Generation) документи компанії розбивають на фрагменти, перетворюють їх на ембединги та записують у векторну базу. Після запиту користувача система створює вектор запиту, знаходить релевантний контекст і передає його у вікно контексту LLM. Модель отримує доступ до приватних даних без повторного навчання на всій корпоративній базі, а посилання на знайдені фрагменти допомагають зменшити галюцинації.
Для агентного ШІ векторна база може зберігати історію дій, стани завдань і корисні відомості з попередніх взаємодій. Агент дістає не всю історію, а лише записи, близькі до поточної ситуації. Поряд із ембедингом зазвичай зберігають час, ідентифікатор сесії, тип події та права доступу.
Семантичний пошук по документації, коду й внутрішніх базах знань знаходить інформацію за змістом та наміром запиту. Він корисний, коли користувачі формулюють одну проблему різними словами або коли терміни в документах змінюються. Для точних назв функцій, кодів помилок і номерів версій його часто поєднують із повнотекстовим пошуком.
У рекомендаційних системах вектори можуть описувати профіль користувача, товар або контент. Пошук найближчих товарних векторів дає змогу будувати персоналізовану видачу та оновлювати її під час нових дій користувача. Окремі бізнес-фільтри відсіюють недоступні, розпродані або несумісні позиції.
Мультимодальний пошук працює через спільний простір ембедингів для різних типів даних. Модель на кшталт CLIP дає змогу зіставляти текстовий опис із візуальним вмістом, а подібний підхід застосовують і до аудіо. Користувач може ввести текстовий запит, а система поверне найближчі медіаоб’єкти з урахуванням їхнього змісту.
У RAG і пам’яті агентів особливо важливі актуальність та ізоляція даних: застарілі фрагменти потрібно оновлювати, а результати — обмежувати правами доступу. Без цих перевірок навіть точний векторний пошук може передати LLM неправильний або недозволений контекст. Тому векторний індекс має бути частиною повного контуру роботи з даними, а не єдиним механізмом контролю якості.
