Векторні бази даних (Vector DBs & ANN Search)(Векторні бази даних та алгоритми ANN)

1. Огляд концепції та системна проблема

З появою ембеддінгів інженери зіткнулися з новою проблемою: як зберігати та швидко шукати дані у векторному просторі, де розмірність кожного запису становить сотні чи тисячі координат:

1. Непридатність класичних B-Tree індексів: Класичні B-Tree індекси ефективно сортують одновимірні числа чи рядки, але математично безсилі перед 1536-вимірними геометричними векторами («Прокляття розмірності» / Curse of Dimensionality).
2. Величезний обсяг пам'яті: Збереження масивів дійсних чисел float32 вимагає гігабайтів оперативної пам'яті та спеціалізованого апаратного прискорення (інструкції AVX-512, SIMD чи CUDA).
3. Потреба у зв'язці з метаданими: Знайти вектор недостатньо — система повинна миттєво повернути пов'язаний текст, автора, дату, URL першоджерела та рівень доступу користувача.

Векторні бази даних (Vector Databases) перетворили векторний семантичний пошук на надійний інфраструктурний примітив, здатний знаходити найбільш схожі сутності серед мільярдів записів за лічені мілісекунди.

2. Архітектурна таксономія та ментальна модель

У світі векторних сховищ домінують дві концептуальні моделі організації даних та відповідні структури індексів:

• 1. Індекс HNSW (Hierarchical Navigable Small World): Золотий стандарт векторного пошуку. Будує багатошаровий граф, аналогічний алгоритму Skip-List: верхні шари містять довгі зв'язки для швидкого стрибка в потрібний кластер простору, а нижній шар (Layer 0) здійснює детальну навігацію між найближчими сусідами. Забезпечує найкращий баланс між швидкістю та повнотою пошуку (Recall > 98%).
• 2. Індекс IVF (Inverted File Index): Простір ділиться на комірки Вороного через K-Means кластеризацію. Запит спочатку визначає кілька найближчих центроїдів, після чого сканує лише вектори всередині цих кластерів. Вимагає менше оперативної пам'яті, ніж HNSW, але має меншу точність.
• 3. Архітектурні формати баз:
  • Спеціалізовані автономні векторні СУБД (Dedicated Vector DBs): Qdrant (Rust), Milvus (Go/C++), Chroma, Pinecone. Оптимізовані під масштаб, шардинг і паралельні GPU-обчислення.
  • Реляційні векторні розширення (Integrated Extensions): pgvector для PostgreSQL, sqlite-vec / Turso для SQLite. Забезпечують збереження ACID-транзакцій та звичний SQL-синтаксис.
• 4. Квантування та стиснення пам'яті: Використання Scalar Quantization (SQ) або Product Quantization (PQ) для стиснення векторів у пам'яті до 8-бітних або 1-бітних уявлень.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл збереження та пошуку у векторній базі даних:

1. Ingestion & Payload Attachment (Запис та прив'язка корисного навантаження): Клієнт передає вектор разом із JSON-метаданими (text, document_id, created_at, tenant_id).
2. Graph Insertion & Edge Linking (Вбудовування в HNSW): Алгоритм знаходить для нового вектора найближчих сусідів на кожному шарі графа і створює двосторонні ребра зв'язків з урахуванням ліміту ступеня вершин $M$.
3. Query Ingestion & Multi-layer Traversal (Пошуковий запит): При надходженні вектора запиту алгоритм починає жадібний пошук (Greedy Search) із верхнього шару, спускаючись на нижчі рівні в міру локалізації кластера.
4. Single-Stage Filtered Retrieval (Вибірка з фільтрацією): Якщо запит містить SQL/JSON-фільтр, перевірка відповідності метаданих відбувається безпосередньо під час переходу по графу (Filtered HNSW), гарантуючи повернення строго релевантних записів.

4. Практичні інженерні сценарії в продакшені

01. Довготривала пам'ять агентів (Agent Memory Storage)

Автономний агент зберігає факти про розробника у колекцію Qdrant чи pgvector: [vector, payload: { user_id: 104, fact: "віддає перевагу bun замість npm" }]. Перед початком сесії агент витягує 5 найрелевантніших фактів.

02. Виробничий RAG для технічної підтримки

Векторна база зберігає 500 000 чанків документації. Запит клієнта за 12 мілісекунд знаходить 20 найбільш релевантних фрагментів інструкцій, які передаються на реранкер.

03. Семантичний каталог E-Commerce з фасетною фільтрацією

Пошук одягу за запитом: «легка куртка для бігу восени» з обов'язковим попереднім фільтром price <= 3000 AND in_stock = true AND size = 'L'.

5. Підводні камені, типові помилки та безпека

• Невідповідність розмірності (Dimension Mismatch Error): Спроба виконати пошук вектором моделі OpenAI (1536 вимірів) в індексі, створеному під модель Cohere (1024 виміри), призводить до фатальної помилки рантайму бази даних.
• Сплеск споживання пам'яті під час побудови індексу (HNSW Build RAM Spike): Створення HNSW-індексу над 5 мільйонами векторів потребує в 2–3 рази більше оперативної пам'яті під час побудови, ніж для фінального зберігання. Будуйте індекси з урахуванням буфера RAM або використовуйте зовнішнє дискове квантування.
• Забування вакуумізації та дефрагментації: Часті операції UPDATE та DELETE створюють у векторних графах порожні вузли-сироти. Регулярно запускайте оптимізацію індексів (Vacuum / Segment Compaction).