Векторные базы данных

01Эмбеддинги: смысл как координаты

Модель эмбеддингов превращает фрагмент контента в вектор, например из 1,024 чисел. Представьте огромную карту, где похожие смыслы находятся рядом: «собака» рядом со «щенком» и далеко от «счёта-фактуры». Модель обучена так, чтобы расстояние на этой карте отражало сходство. Вы один раз превращаете документы в эмбеддинги и сохраняете векторы; во время запроса вы кодируете вопрос той же моделью и ищете ближайших соседей. Сходство измеряется косинусным сходством (угол между векторами), скалярным произведением или евклидовым расстоянием (L2). Большинство текстовых моделей выдают нормализованные векторы, поэтому косинус и скалярное произведение ранжируют одинаково.

• Размерность: сколько чисел в каждом векторе (например, 384, 768, 1024, 1536, 3072).
• Всегда используйте одну и ту же модель для документов и запросов; векторы разных моделей несравнимы.
• Смена модели означает пересчёт всех эмбеддингов, поэтому сохраняйте имя и версию модели вместе с каждым вектором.

02Почему точный поиск не масштабируется и как помогает ANN

Точный поиск сравнивает запрос с каждым сохранённым вектором. Для 10,000 векторов это нормально; для 50 миллионов с 1,024 измерениями — слишком медленно. Индексы приближённого поиска ближайших соседей (ANN) жертвуют небольшой точностью ради огромной скорости. HNSW (Hierarchical Navigable Small World) строит многоуровневый граф: верхние уровни — разреженные магистрали, нижние — плотные местные улицы. Поиск начинается сверху, жадно движется к запросу и спускается вниз. IVF (inverted file) кластеризует векторы и ищет только в ближайших кластерах. Качество измеряется recall — долей настоящих ближайших соседей, которую возвращает индекс. Хорошие настройки дают 95–99% recall за несколько миллисекунд.

• HNSW: лучший баланс recall и скорости, больше памяти, медленнее строится.
• IVF: меньше памяти и быстрее строится, требует обучения на данных и настройки probes.
• Квантизация: хранение векторов в меньшем числе бит (int8, binary) для экономии памяти, с пересчётом оценок для точности.

03Начинаем с pgvector в PostgreSQL

Если у вас уже работает PostgreSQL, pgvector — часто самый простой старт: векторы живут рядом с вашими строками, транзакции, JOIN-ы, бэкапы и контроль доступа достаются бесплатно, а фильтры — обычный SQL. Расширение добавляет тип vector (и halfvec для 16-битного хранения), операторы расстояния (<-> для L2, <=> для косинусного расстояния, <#> для отрицательного скалярного произведения) и индексы HNSW и IVFFlat. Используйте класс операторов, соответствующий вашему расстоянию: индекс, построенный с vector_cosine_ops, помогает только запросам с сортировкой по <=>. Увеличьте hnsw.ef_search для лучшего recall ценой некоторой задержки.

1CREATE EXTENSION IF NOT EXISTS vector;
2 
3CREATE TABLE doc_chunks (
4  id         bigserial PRIMARY KEY,
5  doc_id     bigint NOT NULL,
6  tenant_id  int    NOT NULL,
7  content    text   NOT NULL,
8  embedding  vector(1024) NOT NULL
9);
10 
11CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops)
12  WITH (m = 16, ef_construction = 64);
13 
14SET hnsw.ef_search = 100;
15SELECT id, content, 1 - (embedding <=> $1) AS similarity
16FROM doc_chunks WHERE tenant_id = 7
17ORDER BY embedding <=> $1 LIMIT 10;

04Специализированные векторные базы данных

Специализированные движки вроде Qdrant, Weaviate, Milvus и Pinecone построены вокруг векторного поиска. Они предлагают быстрый поиск с фильтрами, квантизацию, шардирование по узлам, функции multi-tenancy, разреженные векторы для гибридного поиска и managed-облачные варианты. Вы храните точки, состоящие из ID, одного или нескольких векторов и payload (метаданных), по которому фильтруете. Компромисс — ещё одна система, которую нужно запускать, защищать и синхронизировать с основной базой. Практическое правило: до нескольких миллионов векторов при умеренном трафике обычно хватает pgvector или вашего существующего поискового движка; при десятках миллионов векторов, тяжёлой фильтрации или строгих требованиях к задержке специализированный движок оправдывает себя.

1# Qdrant: create a collection and search with a filter (HTTP API)
2curl -X PUT http://localhost:6333/collections/docs -H 'Content-Type: application/json' \
3  -d '{ "vectors": { "size": 1024, "distance": "Cosine" } }'
4 
5curl -X POST http://localhost:6333/collections/docs/points/query \
6  -H 'Content-Type: application/json' -d '{
7    "query": [0.01, 0.12, 0.03],
8    "filter": { "must": [ { "key": "tenant_id", "match": { "value": 7 } } ] },
9    "limit": 10, "with_payload": true
10  }'

05Гибридный поиск и реранкинг

Векторы отлично понимают смысл, но слабы на точных токенах: коды товаров, имена, сообщения об ошибках. Поиск по ключевым словам (BM25) — наоборот. Гибридный поиск выполняет оба и объединяет списки, чаще всего через reciprocal rank fusion (RRF): каждый документ получает 1 / (k + rank) в каждом списке, и итоговый порядок определяют суммы. RRF не требует нормализации оценок, поэтому он так популярен. После слияния cross-encoder реранкер может переоценить топ-50–100 кандидатов, читая запрос и документ вместе; он медленнее, но намного точнее, поэтому запускается только на коротком списке.

1-- Hybrid in PostgreSQL: full-text + vector, merged with RRF (k = 60)
2WITH kw AS (
3  SELECT id, row_number() OVER (ORDER BY ts_rank(tsv, q) DESC) AS r
4  FROM doc_chunks, websearch_to_tsquery('english', $2) q
5  WHERE tsv @@ q ORDER BY r LIMIT 50
6), vec AS (
7  SELECT id, row_number() OVER (ORDER BY embedding <=> $1) AS r
8  FROM doc_chunks ORDER BY embedding <=> $1 LIMIT 50
9)
10SELECT id, sum(1.0 / (60 + r)) AS score
11FROM (SELECT * FROM kw UNION ALL SELECT * FROM vec) s
12GROUP BY id ORDER BY score DESC LIMIT 10;

06Настройка HNSW: m, ef_construction, ef_search

m — число связей на узел. Большее m улучшает recall на данных высокой размерности, но увеличивает память и время построения; 16 — частое значение по умолчанию, 32–64 — для сложных наборов данных. ef_construction — размер списка кандидатов при построении; чем больше, тем лучше граф и медленнее вставки (типично 64–200). ef_search — список кандидатов во время запроса и главный регулятор в рантайме: больше значит лучше recall и выше задержка, и он должен быть не меньше LIMIT. Настраивайте эмпирически: возьмите 1,000 тестовых запросов, вычислите точных соседей последовательным сканированием, затем перебирайте ef_search и стройте график recall at 10 против p95 задержки. Построение HNSW требует много памяти; в PostgreSQL на время построения увеличьте maintenance_work_mem и max_parallel_maintenance_workers.

1-- Build faster with more memory and workers (PostgreSQL)
2SET maintenance_work_mem = '4GB';
3SET max_parallel_maintenance_workers = 7;
4CREATE INDEX CONCURRENTLY idx_chunks_emb
5  ON doc_chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 128);
6 
7-- Filtered queries: keep scanning until enough rows match (pgvector 0.8+)
8SET hnsw.iterative_scan = relaxed_order;

07Память, квантизация и пересчёт оценок

Вектор float32 из 1,024 измерений занимает 4 KB. Десять миллионов таких — около 40 GB без учёта накладных расходов индекса, а HNSW хочет держать горячую часть в RAM. Квантизация это уменьшает. Половинная точность (halfvec в pgvector) вдвое сокращает размер почти без потери recall. Скалярная квантизация в int8 сокращает его в четыре раза. Бинарная квантизация хранит один бит на измерение — в 32 раза меньше — и удивительно хорошо работает на многих современных моделях эмбеддингов в сочетании с пересчётом оценок (rescoring): ищите по компактному индексу, скажем, топ-200 кандидатов, затем переранжируйте их по векторам полной точности. Движки вроде Qdrant, Milvus и Elasticsearch реализуют этот паттерн нативно; в pgvector можно проиндексировать бинарное выражение и пересчитать оценки в SQL.

1-- pgvector: binary-quantized index with full-precision rescoring
2CREATE INDEX ON doc_chunks USING hnsw
3  ((binary_quantize(embedding)::bit(1024)) bit_hamming_ops);
4 
5SELECT id FROM (
6  SELECT id, embedding FROM doc_chunks
7  ORDER BY binary_quantize(embedding)::bit(1024) <~> binary_quantize($1)
8  LIMIT 200
9) candidates
10ORDER BY embedding <=> $1 LIMIT 10;

08Свежесть векторов: загрузка и пересчёт эмбеддингов

Векторы — производные данные. Относитесь к созданию эмбеддингов как к pipeline: когда документ меняется, событие (строка outbox или задача в очереди) запускает разбиение на чанки и создание эмбеддингов, а результат записывается через upsert по стабильному ID, например doc_id плюс номер чанка, с удалением устаревших чанков того же документа. Делайте задачи идемпотентными и с ограничением частоты, потому что у API эмбеддингов есть квоты. Обновление модели требует плана миграции: создайте новую колонку или коллекцию для новой модели, заполните её в фоне, сравните бок о бок, переключите чтение за флагом, затем удалите старые векторы. HNSW-индексы немного деградируют при интенсивных обновлениях и удалениях; планируйте периодическую переиндексацию (REINDEX CONCURRENTLY в PostgreSQL) или полагайтесь на оптимизатор движка.

09Безопасность и приватность эмбеддингов

Эмбеддинги не анонимны. Исследования показали, что текст можно частично восстановить по его эмбеддингу, поэтому относитесь к векторам так же бережно, как к исходному контенту. Обеспечивайте контроль доступа во время запроса: фильтры по тенанту и правам внутри поиска, row-level security в PostgreSQL или отдельные коллекции для строгой изоляции. Отправляя контент во внешний API эмбеддингов, проверьте условия обработки данных и не отправляйте секреты или лишние персональные данные. Удаление документа должно удалять и его векторы — это важно для удаления данных по GDPR. Наконец, найденный контент при использовании в RAG может содержать prompt injection, поэтому считайте извлечённый текст в промпте недоверенными данными.