Векторные базы данных: обзор и как выбрать

Как только вы начинаете строить поиск по смыслу, а не по словам — чат-бот по документации, подсказки «похожие товары», RAG-помощник по внутренней базе знаний, — появляется вопрос: где хранить эмбеддинги и как быстро искать по ним ближайших соседей. Ответ на этот вопрос и есть векторная база данных. Разбираем, что это за класс инструментов, чем варианты отличаются друг от друга и как выбрать под свою задачу, не переплатив и не упершись в потолок через полгода.

Что такое векторная база данных

Модель-эмбеддер превращает текст, картинку или аудио в вектор — массив из нескольких сотен или тысяч чисел. Близкие по смыслу тексты дают близкие векторы. Чтобы найти документ, похожий на запрос, нужно посчитать расстояние между вектором запроса и векторами всех документов и взять топ-N ближайших. Это задача поиска ближайших соседей (nearest neighbor search).

Векторная база данных — хранилище, которое умеет три вещи: держать миллионы векторов вместе с их метаданными, строить по ним индекс для быстрого приближённого поиска и отдавать топ-N результатов за десятки миллисекунд, а не за минуты полного перебора. Всё остальное — гибридный поиск, фильтры, шардирование, репликация — надстройки над этой основой.

Ключевое слово — приближённый (ANN, approximate nearest neighbor). Точный перебор по миллиону векторов по 1536 чисел — это миллиарды операций на каждый запрос. Индекс жертвует малой долей точности ради стократного ускорения: вместо «гарантированно верных 10 документов» вы получаете «10 документов, из которых 9–10 верных». Для поиска по смыслу это честная сделка.

Чем это отличается от обычного поиска

Полнотекстовый поиск (тот же MATCH ... AGAINST в MySQL или BM25 в Elasticsearch) ищет по совпадению слов. Запрос «не приходит письмо с чеком» не найдёт документ «проблемы с доставкой уведомлений о заказе» — общих слов почти нет. Векторный поиск такую пару находит, потому что работает со смыслом.

Обратная сторона: векторный поиск плохо работает с точными идентификаторами. Артикул WX-7741, номер заказа, фамилия — здесь выигрывает обычный текстовый индекс. Поэтому в продакшене почти всегда используют гибридный поиск: параллельно запускаются векторный и полнотекстовый поиск, а результаты склеиваются по формуле RRF (Reciprocal Rank Fusion) или взвешенной суммой. Наличие гибридного поиска «из коробки» — один из главных критериев выбора.

Если вы только подступаетесь к теме, начните с разбора того, как устроен RAG — векторная база там ровно один из блоков конструктора.

Как устроен индекс: HNSW, IVF и квантизация

HNSW

Hierarchical Navigable Small World — многослойный граф, где каждый вектор связан с несколькими соседями. Поиск начинается на верхнем разреженном слое и «спускается», каждый раз переходя к более близкому соседу. Это стандарт де-факто: лучшее соотношение скорости и точности, поддерживается практически везде. Минус — граф целиком хочет жить в оперативной памяти и медленно строится.

Два параметра, которые придётся крутить: m (число связей на узел, обычно 16–32 — больше точность и больше память) и ef_search (сколько кандидатов держать при обходе — прямой рычаг «точность против скорости», меняется на лету без перестройки индекса).

IVF

Inverted File Index: векторы кластеризуются, при поиске просматриваются только несколько ближайших кластеров. Строится быстрее HNSW и ест меньше памяти, но проседает по точности и требует заранее знать примерный объём данных, чтобы выбрать число кластеров. Разумный выбор, если данных много, а память дорогая.

Квантизация

Самый практичный способ сэкономить. Скалярная квантизация сжимает каждое число из 4 байт до 1 байта (в 4 раза меньше памяти, потеря точности обычно в пределах процента), бинарная — до 1 бита (в 32 раза, но нужна перепроверка кандидатов по исходным векторам). В Qdrant с версии 1.18 появился режим TurboQuant, который заявляет восьмикратное сжатие практически без потери полноты выдачи. В pgvector похожую роль играет тип halfvec — половинная точность, вдвое меньше места.

Прикинуть аппетиты просто: миллион векторов по 1536 измерений в обычном float32 — это примерно 6 ГБ только под сами векторы, плюс граф HNSW сверху. С квантизацией те же данные умещаются в 1,5 ГБ и спокойно живут на недорогом VPS.

Обзор вариантов

pgvector — расширение для PostgreSQL

Если у вас уже есть PostgreSQL, начинать нужно отсюда. pgvector добавляет типы vector, halfvec, bit и sparsevec, индексы HNSW и IVFFlat и операторы расстояний: <-> (евклидово), <=> (косинусное), <#> (скалярное произведение), <+> (манхэттенское). Максимум для типа vector — 16 000 измерений, но индексируется не больше 2 000 (для halfvec — 4 000). Для популярных эмбеддеров на 768–1536 измерений этого достаточно.

Главный плюс — векторы лежат в той же транзакции и той же таблице, что и бизнес-данные: никакой синхронизации двух хранилищ, обычный JOIN, обычный WHERE, обычный бэкап. Долгое время слабым местом была фильтрация: при жёстком WHERE индекс мог вернуть меньше строк, чем просили. С версии 0.8.0 это решается итеративными сканами индекса — база сама расширяет просмотр, если после фильтра результатов не хватило. Актуальная ветка — 0.8.x.

Минус честный: на десятках миллионов векторов и высокой нагрузке специализированные движки будут быстрее.

Qdrant

Написан на Rust, разворачивается одним контейнером, конфигурируется через понятный REST/gRPC API. Сильные стороны — продвинутая фильтрация по метаданным (метод ACORN-1 держит точность даже при жёстких фильтрах), гибридный поиск с RRF, мультитенантность и богатый набор режимов квантизации. Актуальная ветка — 1.18.x. Есть облако с бесплатным кластером на 1 ГБ RAM и 4 ГБ диска — хватит, чтобы пощупать без карты. Хороший выбор, когда хочется отдельный векторный движок, но не хочется тащить в проект распределённую систему.

Milvus

Тяжёлая артиллерия: распределённая архитектура с раздельным масштабированием хранения и вычислений, множество типов индексов, GPU-ускорение. Актуальная ветка — 2.6.x. Оправдан на сотнях миллионов векторов и выше. На типичном проекте с парой миллионов документов вы получите мощный кластер, который дорого обслуживать, и не получите выигрыша.

Weaviate

Отличается модулями векторизации: база сама ходит в модель эмбеддингов и превращает текст в вектор на вставке — вам не нужно писать этот шаг. Плюс встроенный гибридный поиск и GraphQL-подобный API. Актуальная ветка — 1.39. Удобно, когда хочется меньше кода в приложении, менее удобно, когда нужен полный контроль над пайплайном.

Chroma

Встраиваемая база для прототипов: pip install chromadb, три строки кода — и поиск работает. Отлично для демо и локальных экспериментов, но переезд в продакшен обычно означает переезд на что-то другое. Актуальная ветка — 1.5.x.

Pinecone

Полностью управляемый SaaS: серверов нет, индексов не касаетесь, платите за использование. Тарифы — бесплатный Starter (до 2 ГБ хранилища), Builder за 20 $ в месяц, Standard от 50 $ в месяц с оплатой по факту и Enterprise от 500 $. Экономит время команды, но данные уезжают наружу, а расходы растут вместе с трафиком. Отдельно стоит учитывать доступность зарубежного SaaS и требования к хранению данных.

Redis, Elasticsearch, OpenSearch

Векторный поиск здесь — дополнительная возможность поверх основной. Логика та же, что с pgvector: если инструмент уже в стеке и объёмы умеренные, не заводите шестую систему ради одной функции. Elasticsearch и OpenSearch особенно хороши, когда сильный полнотекстовый поиск нужен вам в любом случае, а вектор — приправа к нему. Кстати, если Redis у вас крутится как объектный кеш, поиск по векторам — соседний модуль того же сервера.

Как выбрать: короткий алгоритм

1. Уже есть PostgreSQL и меньше нескольких миллионов векторов? Берите pgvector и не усложняйте. Это закрывает подавляющее большинство задач малого и среднего проекта.
2. Нужен отдельный движок с сильной фильтрацией и гибридным поиском? Qdrant — оптимальный баланс возможностей и простоты эксплуатации. Развернуть можно рядом с приложением, на том же сервере, где живёт локальная модель через Ollama.
3. Не хотите администрировать вообще ничего и готовы платить? Pinecone или облачные версии Qdrant и Weaviate.
4. Сотни миллионов векторов, отдельная команда инфраструктуры? Milvus.
5. Прототип на выходные? Chroma, потом переезд.

На что смотреть, кроме скорости

Бенчмарки продают, а живут с эксплуатацией. Перед решением проверьте:

• Фильтрация по метаданным. Почти всегда нужно искать «похожее, но только у этого клиента и только за последний год». Уточните, как база ведёт себя при жёстких фильтрах и не проседает ли полнота выдачи.
• Гибридный поиск. Есть ли он встроенный или придётся склеивать выдачи руками.
• Обновление и удаление. Многие индексы дешевле построить заново, чем менять. Если документы правятся часто, узнайте цену обновления заранее.
• Бэкапы и восстановление. Банально, но у отдельного векторного движка это отдельный процесс, а не строчка в общем pg_dump.
• Переносимость. Смена модели эмбеддингов означает пересчёт всей базы. Держите исходные тексты отдельно, чтобы переиндексация была рутиной, а не катастрофой.
• Память. Посчитайте объём заранее по формуле «число векторов × размерность × 4 байта» и сразу решите вопрос с квантизацией.

Вывод

Векторная база — не магия, а специализированный индекс поверх обычного хранилища. Выбор почти всегда сводится к одному вопросу: достаточно ли расширить то, что уже есть, или задача переросла этот путь. Начинайте с pgvector, если PostgreSQL в стеке; переходите на Qdrant, когда упрётесь в фильтрацию, скорость или объём; смотрите в сторону Milvus и SaaS-решений, когда счёт векторов пойдёт на сотни миллионов. Ошибиться на первом шаге не страшно — исходные тексты у вас останутся, а переиндексация в новую базу занимает часы, а не недели. Дальше поверх этого слоя собирается всё остальное: поиск, рекомендации и собственный AI-агент, который отвечает по вашим данным.