Векторные базы данных (Vector DBs & ANN Search)

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).