Векторная база данных хранит многомерные плотные и разреженные эмбеддинги вместе с метаданными, обеспечивая приближённый поиск ближайших соседей (ANN) за миллисекунды как слой памяти и извлечения для RAG, семантического поиска и ИИ-агентов.
| Нагрузка / Ограничение | Рекомендуемая категория | Типичные решения | Почему подходит |
|---|---|---|---|
| Текущий стек PostgreSQL, до ~10 млн векторов | Расширение реляционной БД | pgvector (+ halfvec / HNSW) | Переиспользует ACID-транзакции, SQL JOIN и текущую эксплуатацию без новой инфраструктуры |
| Полнотекстовый BM25 + векторный гибридный поиск | Расширение поискового движка | Elasticsearch / OpenSearch / Vespa | Зрелая экосистема инвертированных индексов и многоэтапного гибридного ранжирования |
| Выделенный сервис с высоким QPS и сложными фильтрами | Специализированная распределённая ВБД | Qdrant / Milvus / Weaviate | Профильный движок хранения, быстрая фильтрация payload и горизонтальное масштабирование |
| Локальная разработка, edge/desktop или чтение data lake | Встраиваемая / колоночная БД | LanceDB / Chroma / FAISS | Работа in-process с zero-copy интеграцией Apache Arrow / Parquet |
| Огромные холодные/тёплые объёмы при минимуме затрат | SaaS на базе object storage | Turbopuffer | Object storage (S3/GCS) как источник истины + локальный NVMe/RAM-кэш |
| Бессерверная работа без DevOps в публичном облаке | Управляемый облачный сервис | Pinecone / Vertex AI Vector Search / Azure AI Search | Эластичное serverless-масштабирование и нативная интеграция с облачным IAM |
🔗 Связанные шпаргалки: Концепции LLM и ИИ-агентов · Современные алгоритмы ИИ · Команды PostgreSQL · Команды Redis · Команды MongoDB
1. Ключевые понятия и метрики расстояния
1.1 Базовая терминология
| Термин | Определение | Инженерные нюансы |
|---|---|---|
| Embedding (эмбеддинг) | Массив чисел с плавающей точкой фиксированной длины, кодирующий смысл текста, фото или звука | Типичные размерности: 384 / 768 / 1024 / 1536 / 3072; память и вычисления растут линейно |
| ANN (Approximate Nearest Neighbor) | Индексный поиск, меняющий долю полноты (95%–99%) на ускорение в 100×–1000× | Базовый баланс задержка vs полнота (recall) в отличие от точного перебора k-NN |
| Metadata Filtering | Ограничение векторного поиска по скалярным полям (тенант, дата, права, категория) | Важно различать Pre-filtering, Single-stage / Inline и Post-filtering |
| Hybrid Search | Сочетание плотных векторов (семантика) и разреженных векторов / BM25 (точные слова) | Устраняет промахи чистой семантики на артикулах, кодах ошибок и аббревиатурах |
| Sparse Vector | Высокоразмерный вектор, почти полностью состоящий из нулей (SPLADE, веса BM25) | Хранит только ненулевые индексы и веса; естественно дополняет плотный поиск |
1.2 Три основные метрики расстояния и сходства
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Метрика | Смысл | Математическая связь | Типичное применение |
|---|---|---|---|
| Косинусное сходство (Cosine) | Оценивает только угол без учёта длины (−1..1; расстояние = 1 - cos) |
Ранжирование совпадает со скалярным произведением при L₂-нормализации | Семантический поиск текста, RAG, эмбеддинги предложений (по умолчанию) |
| Скалярное произведение (IP / Dot) | Учитывает угол и длину; минимальная стоимость расчёта | На единичных векторах заменяет Cosine без корней и делений | Двухбашенные рекомендации, нормализованные эмбеддинги (напр. OpenAI) |
| Евклидово расстояние (L₂) | Прямое геометрическое расстояние; меньше = ближе | Для единичных векторов: L₂² = 2 − 2 · cos(u, v) |
Эмбеддинги изображений/лиц, пространственная кластеризация, учёт длины |
2. Алгоритмы ANN-индексации и квантование
2.1 Сравнение векторных индексов
| Тип индекса | Механизм | Память (RAM) | Задержка и Полнота | Масштаб и движки |
|---|---|---|---|---|
| Flat (Точный перебор) | Полный расчёт расстояний по всем векторам | Умеренная (только исходные/сжатые векторы) | 100% recall; задержка резко растёт >~100k | Небольшие наборы (<100k), эталонные бенчмарки |
| IVF-Flat (Инвертированный файл) | Кластеризация K-Means на nlist корзин; сканирование nprobe ближайших |
Низкая (нет накладных расходов на граф) | Регулируется nprobe; средняя/высокая полнота |
1M–10M при жёстком лимите RAM (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Product Quantization) | Разбиение на корзины + сжатие подпространств кодовыми книгами | Очень низкая (сжатие 16×–64×) | Сверхбыстро; базовый recall ниже (нужен rescoring) | 100M+ в памяти (FAISS / Milvus / LanceDB) |
| HNSW (Иерархический граф) | Многослойный граф близости по типу skip-list (верх грубый, низ точный) | Высокая (векторы + рёбра графа в RAM или hot mmap) | Миллисекунды + 95%–99% recall; отраслевой стандарт | 1M–100M+ в реальном времени (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Граф Vamana) | Граф под SSD: сжатые векторы в RAM, полный граф и данные на NVMe | Низкая (экономия RAM в 5×–10×) | 100M+ на узел за мс; зависит от быстрых NVMe IOPS | 100M–1B+ при дефиците RAM (Milvus / LanceDB / Azure) |
| ScaNN | Анизотропное векторное квантование + древовидное разбиение | Низкая–Умеренная | Лучшее соотношение recall/задержка для IP | Крупномасштабный поиск и рекомендации (Vertex AI Vector Search / OSS) |
Ключевые параметры настройки HNSW:
M(макс. двунаправленных связей на узел, обычно16–64): большееMповышает recall на высоких размерностях ценой RAM и времени построения.efConstruction(размер списка кандидатов при сборке, обычно100–400): влияет только на скорость построения и качество графа.efSearch(ширина луча поиска при запросе, ≥top_k): единственный параметр, меняемый на уровне запроса; рост повышает recall и снижает QPS.
2.2 Квантование и оценка памяти
Базовый ориентир для 10 млн векторов × 1536 измерений (исходный FP32):
Исходный объём ≈ N × D × 4 Байта (граф HNSW добавляет ~1.2×–1.5× накладных расходов RAM)
| Квантование | Бит / измер. | Сжатие | Объём 10M × 1536-dim | Баланс точности и применение |
|---|---|---|---|---|
| FP32 (Без сжатия) | 32 бит (4 Б) | 1× | ~57.2 ГБ | Эталонная точность; дорого держать целиком в RAM |
| FP16 / BF16 (Полуточность) | 16 бит (2 Б) | 2× | ~28.6 ГБ | Почти без потери recall (напр. pgvector halfvec), высокая выгода |
| SQ8 (Скалярное Int8) | 8 бит (1 Б) | 4× | ~14.3 ГБ | Обычно сохраняет 97%+ recall; стандарт для продакшена |
| PQ (Product Quantization) | Подпространства | 16×–64× | ~1–4 ГБ | Требует обучения codebook; сочетать с oversampling + rescore |
| BQ (Бинарное 1-бит) | 1 бит | 32× | ~1.79 ГБ | Сверхбыстрый скан Хэмминга; нужен rescore 3×–5× (эффективно при ≥1024 dim) |
3. Многоуровневое сравнение систем
3.1 Специализированные нативные векторные БД
| Продукт | Лицензия / Развёртывание | Язык и Хранилище | Индексы и особенности | Сценарий применения |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Self-hosted & Cloud | Rust; RAM, mmap-диск и дисковое квантование | HNSW + SQ8/BQ; нативные разреженные векторы и быстрые индексы payload | Выделенный сервис с высоким QPS, мультитенантностью и фильтрами |
| Milvus | Apache 2.0 / Распределённая & Zilliz Cloud | Control plane на Go + ядро C++; разделение object storage и MQ | IVF, HNSW, DiskANN, GPU CAGRA; мультитенантные партиции | Корпоративные платформы миллиардного масштаба |
| Weaviate | BSD-3-Clause (часть enterprise-модулей закрыта) | Go; встроенное объектное хранилище + инвертированный индекс | HNSW + динамическое/PQ/BQ квантование; GraphQL/REST, модули векторизации | RAG-системы со встроенным пайплайном эмбеддингов |
| Chroma | Apache 2.0 / Embedded & Client-Server | Ядро Python / Rust; SQLite + локальное/распределённое хранилище | HNSW; минималистичный API, тесная связка с LangChain / LlamaIndex | Быстрое прототипирование и малый/средний Python RAG |
| LanceDB | Apache 2.0 / Embedded & Enterprise | Rust; колоночный формат Lance и Apache Arrow | IVF-PQ, HNSW, DiskANN; zero-copy I/O, нативная мультимодальность (аудио/видео/таблицы) | Локальные embedded-приложения, serverless чтение из S3, data lake |
| Pinecone | Проприетарный Serverless SaaS | Управляемый распределённый движок (эволюция от Pods к Serverless) | Разделённый проприетарный индекс; sparse-dense гибрид, изоляция Namespace | Облачные команды zero-ops с фокусом на управляемый сервис |
| Turbopuffer | Проприетарный SaaS / BYOC | Rust; object storage (S3/GCS) как источник истины + кэш NVMe/RAM | Центроидный индекс (типа SPFresh) без случайных переходов графа по диску; текст + вектор | Массивы с неравномерным доступом (индексация кода) по минимальной цене |
3.2 Библиотеки векторного поиска (не полноценные БД)
| Продукт | Лицензия | Границы возможностей | Применение |
|---|---|---|---|
| FAISS (Meta) | MIT | C++ / Python библиотека поиска (без персистентности метаданных, распределённых транзакций и сервера авторизации); CPU SIMD & multi-GPU | Офлайн-расчёты батчами, ML-исследования, ядро внутри собственных движков |
3.3 Расширения классических БД и поисковых систем
| Продукт | Основа | Векторные возможности | Плюсы и ограничения |
|---|---|---|---|
| pgvector | Расширение PostgreSQL (вкл. Supabase) | Типы vector / halfvec / sparsevec / bit; HNSW и IVFFlat |
Плюсы: ACID, SQL JOIN, ноль новой эксплуатации; Минусы: усиление записи и нагрузка на RAM >10M–50M строк |
| Elasticsearch / OpenSearch | Инвертированный индекс Lucene + HNSW | Нативный гибрид Dense Vector + BM25, RRF, вложенные фильтры | Плюсы: переиспользование стека поиска; Минусы: большой расход off-heap RAM JVM и слияние сегментов |
| Redis (Query Engine) | In-memory KV-хранилище | Flat и HNSW, субмиллисекундная задержка, потоковые обновления | Плюсы: идеально для семантического кэша и feature store; Минусы: высокая цена RAM на больших объёмах |
| MongoDB Atlas Search | Документная БД (Atlas / Local CLI) | HNSW на базе Lucene рядом с BSON-документами | Плюсы: не нужна двойная запись документ/вектор; Минусы: ключевой функционал привязан к Atlas |
| SingleStore | Распределённая HTAP SQL-БД | SQL + нативные векторные операции (dot / L₂), колоночное + строковое хранение | Корпоративные задачи с аналитикой в реальном времени и транзакциями |
| Vespa | Big-data движок Apache 2.0 | HNSW + точный/приближённый гибрид, многофазный ML-ранжир (Tensor/XGBoost/ONNX) | Крупнейшие поисковые и рекомендательные платформы; высокий порог входа |
3.4 Полностью управляемые облачные сервисы
| Сервис | Облако | Архитектура и особенности |
|---|---|---|
| Vertex AI Vector Search (ранее Matching Engine) | Google Cloud (GCP) | На базе ScaNN; потоковые обновления на миллиардах векторов и гибрид sparse-dense |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Управляемые serverless-кластеры и расширения RDS/Aurora с нативной интеграцией Amazon Bedrock |
| Azure AI Search | Microsoft Azure | Встроенный Semantic Ranker, пайплайны векторизации и корпоративный контроль доступа RBAC |
4. Стратегии фильтрации и гибридный поиск
4.1 Режимы фильтрации метаданных
| Стратегия | Порядок выполнения | Риск и инженерное решение |
|---|---|---|
| Pre-filtering | Сначала вычисляет битовую карту ID по скалярному индексу, затем ищет по векторам | При жёстких фильтрах (<1% выборки) граф распадается; Решение: автооткат к точному сканированию |
| Post-filtering | Берёт глобальный Top-K по вектору и отсеивает неподходящие записи | Может вернуть меньше K записей (или 0); Решение: не применять отдельно без большого oversampling |
| Single-stage / Inline | Динамически проверяет битовую карту фильтра на каждом шаге обхода графа HNSW | Современный стандарт (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan) с балансом recall и задержки |
4.2 Reciprocal Rank Fusion (RRF)
Поскольку оценки плотного поиска и BM25 имеют разные шкалы, RRF объединяет списки напрямую по рангам без калибровки весов:
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (стандартная константа сглаживания k = 60)
5. Примеры для продакшена
5.1 Схема pgvector, индекс HNSW и итеративное сканирование (SQL)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
tenant_id INT NOT NULL,
content TEXT NOT NULL,
embedding halfvec(1536), -- float16 экономит 50% памяти по сравнению с float32
fts tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);
CREATE INDEX idx_docs_emb_hnsw ON documents
USING hnsw (embedding halfvec_cosine_ops)
WITH (m = 16, ef_construction = 128);
CREATE INDEX idx_docs_fts ON documents USING gin (fts);
SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;
SELECT id, content, 1 - (embedding <=> $1::halfvec) AS cosine_sim
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::halfvec
LIMIT 10;
Операторы расстояния pgvector:
<->Евклидово (L₂) ·<=>Косинусное расстояние (1 - cos) ·<#>Отрицательное скалярное произведение ·<+>Манхэттен (L₁).
5.2 Qdrant: бинарное квантование и фильтрация Payload (Python)
from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="knowledge_base",
vectors_config=models.VectorParams(
size=1536,
distance=models.Distance.COSINE,
on_disk=True,
),
quantization_config=models.BinaryQuantization(
binary=models.BinaryQuantizationConfig(always_ram=True)
),
)
client.create_payload_index(
collection_name="knowledge_base",
field_name="tenant_id",
field_schema=models.PayloadSchemaType.KEYWORD,
)
hits = client.query_points(
collection_name="knowledge_base",
query=[0.012, -0.045, ...],
query_filter=models.Filter(
must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="org_a"))]
),
search_params=models.SearchParams(
quantization=models.QuantizationSearchParams(rescore=True, oversampling=3.0)
),
limit=10,
).points