Pinecone, Weaviate, Milvus, Qdrant или Chroma: как выбрать векторную базу данных

Все векторные базы данных обещают скорость, масштаб и умный поиск, а рекламные тексты вендоров пестрят похожими фразами. Абстрактного победителя здесь нет. Правильный выбор зависит от объёма данных вашей команды, от того, сколько инфраструктуры вы готовы нянчить, и от того, что должен уметь ваш поиск. Ниже разобраны Pinecone, Weaviate, Milvus, Qdrant и Chroma: каждый маркетинговый термин переведён на простой язык, и для каждой базы отмечено, где она действительно оправдывает себя.

Pinecone: ничего не нужно администрировать

Выбирайте его, если команда вообще не хочет заниматься инфраструктурой. Pinecone — полностью управляемый serverless-сервис со встроенным гибридным поиском, который сочетает плотный и разреженный поиск.

Управляемый и serverless. Не нужно арендовать и настраивать виртуальные машины, не нужно думать о шардах, репликах, настройках памяти или числе узлов по мере роста данных. Вы заводите аккаунт, берёте API-ключ и начинаете отправлять данные. Это ценно, потому что векторный поиск жадно ест CPU и память, а самостоятельно поддерживать такую систему печально известно как хлопотно. Serverless означает, что оплата следует за реально используемым хранилищем и запросами, а Pinecone сам масштабирует бэкенд вверх и вниз.

Нативный гибридный поиск. Здесь объединены два совершенно разных подхода:

• Плотный поиск — семантический. Модели превращают текст в эмбеддинги, которые схватывают понятия, поэтому запрос «кошачьи» находит документы со словом «кот».
• Разреженный поиск — это сопоставление ключевых слов в традиции BM25. Он ищет точные строки: серийные номера, коды ошибок или идентификаторы товаров вроде SKU-8492X.

У каждого есть слепое пятно. Плотный поиск понимает намерение, но безнадёжен в точности. Он может счесть SKU-8492X близким соседом SKU-8492Y, и точный поиск сломается. Разреженный поиск безошибочно находит точные токены, но ничего не знает о контексте. Pinecone хранит оба типа векторов в одном индексе и автоматически объединяет их оценки.

Почему важны нулевые накладные расходы. Если вы разработчик, который выпускает ИИ-функцию, вам лучше заниматься логикой приложения и пользовательским опытом, чем играть в администратора базы, крутить параметры или просыпаться в 3 часа ночи, потому что у базы закончилась RAM.

Подвох. Привязка к вендору и стоимость на экстремальных объёмах. Pinecone — закрытый и только управляемый сервис, развернуть его у себя нельзя. При миллиардах запросов с высокой нагрузкой счёт за SaaS может превысить стоимость самостоятельного запуска open-source системы.

Weaviate: эмбеддинги и гибридный поиск в одной коробке

Выбирайте её, если нужен поиск по ключевым словам и семантический поиск в одной системе.

Встроенная векторизация. Weaviate берёт эмбеддинги на себя. Вам не нужно писать код, который отправляет текст в OpenAI, Cohere или Hugging Face, собирает векторы и сохраняет их самостоятельно. Вы передаёте сырой текст, а модули вроде text2vec-openai или text2vec-transformers создают и обновляют векторы за кулисами. Один раз настройте схему с нужным провайдером моделей, и конвейер эмбеддингов будет работать при загрузке данных и снова во время запроса, что заметно упрощает архитектуру.

BM25 плюс векторы, нативно. Движок одновременно выполняет точный алгоритм поиска по ключевым словам и семантический поиск в одном слое хранения, а затем сводит всё в единый ранжированный список.

• При поиске по ключевым словам артикул ABC-123 не перепутается с ABC-124, потому что BM25 сопоставляет точные токены.
• При векторном поиске запрос «проблемы со сном» находит документы о бессоннице, потому что смысл понимается.

Для каждого объекта строятся инвертированный индекс для ключевых слов и векторный индекс для смысла. Параметр alpha, например alpha: 0.5, сдвигает баланс между буквальными ключевыми словами и абстрактным смыслом.

Почему важна одна система. До того как нативная гибридная поддержка созрела, команды держали Elasticsearch для ключевых слов рядом с отдельным векторным хранилищем, синхронизировали данные между ними и писали собственный код для объединения оценок. Weaviate снимает эту операционную нагрузку, будучи обоими движками сразу.

Чем отличается от Pinecone. Развёртыванием. Pinecone — только закрытый SaaS. Weaviate — open source и cloud-native: её можно использовать как управляемый сервис (Weaviate Cloud Services), внутри собственного VPC в AWS или GCP или полностью on-premises с Docker или Kubernetes. Такой контроль над тем, где живут данные, очень много значит для корпоративной безопасности и соответствия требованиям.

Milvus: создан для огромного масштаба

Выбирайте его, если строите платформы корпоративного уровня с миллиардами векторов. Если Pinecone — про простоту, а Weaviate — про удобство разработчика, то Milvus — про грубый инфраструктурный масштаб и чистую производительность.

Распределённый и горизонтально масштабируемый. Это не один монолит, а набор микросервисов без состояния, разделённых на слои:

• Узлы запросов читают и ищут
• Узлы данных пишут и принимают данные
• Узлы индексов строят поисковые графы

Такая архитектура даёт два преимущества. Вы масштабируетесь вширь, добавляя дешёвые машины, а не переходя на одну большую и дорогую. И части масштабируются независимо, поэтому продукт с упором на чтение, например рекомендательный движок с миллионами пользователей, может добавить только узлы запросов и не трогать мощности загрузки, сохраняя разумные расходы.

Ускорение на GPU. Расчёт расстояний между миллиардами многомерных векторов изнуряет CPU. Milvus подключает библиотеки ускорения (NVIDIA RAPIDS, FAISS-GPU и графовые индексы вроде CAGRA), чтобы передать эту работу GPU, которые выполняют тысячи матричных операций параллельно. В результате задержка остаётся ниже миллисекунды на наборах из десятков миллиардов эмбеддингов, а узкое место смещается со скорости вычислений на пропускную способность памяти.

Почему всё дело в масштабе. Любительскому проекту с несколькими тысячами документов это ни к чему. Milvus нацелен на платформы, которые управляют миллиардами векторов и терабайтами данных. На таком объёме базы поменьше задыхаются, пытаясь держать всё в RAM. Milvus использует многоуровневое хранение: горячие данные лежат в RAM или на SSD, холодные — в объектном хранилище вроде S3 или MinIO. Он также применяет квантизацию векторов, например 1-битное сжатие RaBitQ, чтобы сократить потребность в памяти до 70%. Кроме того, вы получаете глубокий контроль над стратегиями индексации (HNSW, IVF-Flat, DiskANN), и инфраструктурные команды могут настраивать компромисс между скоростью и полнотой.

Подвох. Сложность. Это сильно распределённая система на Kubernetes, зависящая от Etcd, S3 и Pulsar или Kafka, поэтому развёртывание, мониторинг и сопровождение требуют серьёзных усилий DevOps.

Qdrant: контроль над точностью и скоростью

Выбирайте его, когда важен контроль над ранжированием и задержкой. Он заметно закрепился в продакшене благодаря упору на эффективность и точный контроль, тогда как Pinecone делает ставку на простоту, Weaviate — на удобство, а Milvus — на огромные кластеры.

Написан на Rust. Qdrant создан с нуля на системном языке, известном безопасностью работы с памятью, скоростью и отсутствием сборщика мусора. Это важно, потому что базы на Java или Go периодически останавливаются, чтобы освободить память, и под высокой нагрузкой эти паузы превращаются во внезапные всплески задержки — пресловутую проблему p99. Без сборщика Qdrant даёт стабильное, предсказуемое время ответа в субмиллисекундном диапазоне даже при большой конкурентной нагрузке и часто расходует меньше RAM и CPU, чем конкуренты.

Плотные, разреженные векторы и метаданные вместе. Поддержка нескольких векторов встроена. Каждая сохранённая точка может содержать:

• Плотный вектор для семантического контекста
• Разреженный вектор для точных ключевых слов
• Структурированный JSON-payload с метаданными, например userId, creationDate или status

Многие векторные базы фильтруют по метаданным (скажем, только документы, где status == active) либо после векторного поиска, что искажает результаты, либо до него, что замедляет запрос. Qdrant строит структурные индексы прямо по payload, поэтому сопоставление ключевых слов, семантическая оценка и фильтрация происходят одновременно при обходе векторного графа.

Рычаги, которые другие системы прячут. Выделяются три:

• Собственная оценка с нативным Reciprocal Rank Fusion (RRF), чтобы вы сами решали, как именно объединяются оценки ключевых слов и векторов.
• Настройки квантизации: настройте Scalar Quantization (SQ) или Product Quantization (PQ), чтобы пожертвовать небольшой точностью ради примерно вчетверо меньшего расхода RAM и более быстрых запросов.
• Где он работает: как один небольшой бинарник, как распределённый кластер или как облачный сервис.

Chroma: самый быстрый путь к прототипу

Выбирайте её для локальных RAG-прототипов и экспериментов. Если Milvus и Pinecone нацелены на миллиарды объектов в облаке, то Chroma целиком нацелена на опыт разработчика без трения.

Встраиваемая. Она работает в том же процессе, поэтому это не тяжёлый фоновый сервис вроде MySQL или Docker-контейнера. Она живёт внутри вашего Python-скрипта или Jupyter-ноутбука. Значит, никаких строк подключения, пользователей базы, файрволов или облачных инстансов. Начать действительно настолько просто:

import chromadb
# Start a local, persistent database on your hard drive
client = chromadb.PersistentClient(path="./my_local_db")
collection = client.get_or_create_collection("my_docs")
# Add raw text - Chroma handles the embedding automatically
collection.add(
    documents=[
        "Retrieval-Augmented Generation relies on good context.",
        "Chroma runs in-process."
    ],
    ids=["id1", "id2"]
)

Запускайте её в эфемерном режиме, целиком в RAM, когда данные исчезают после завершения скрипта, или укажите папку, чтобы сохранять данные на диск.

Почему она подходит для прототипов. По двум причинам. Во-первых, в ней есть встроенные функции эмбеддингов, по умолчанию — лёгкая локальная модель all-MiniLM-L6-v2. Обычно вы вызываете API эмбеддингов, ждёте векторы и сопоставляете их сами, а здесь вы отдаёте сырой текст, и Chroma делает остальное. Во-вторых, отличная поддержка инструментами. Откройте почти любой туториал по LangChain или LlamaIndex, и хранилищем там окажется Chroma, так что скопированный пример RAG-конвейера, скорее всего, уже её использует.

Она повзрослела. Chroma больше не просто инструмент для прототипов. Теперь в ней есть мультимодальный поиск, гибридный поиск (плотный плюс BM25) и клиент-серверный режим (chroma run) для больших многопользовательских сценариев.

Её предел. Масштаб и высокая доступность. Для критичной для бизнеса системы с миллиардами векторов, жёсткими целями по задержке на 99-м перцентиле и автоматическим переключением между регионами локальная файловая архитектура не подойдёт. Если же цель — проверить RAG-идею на нескольких тысячах или миллионах документов на своей машине, быстрее стартовать не получится.

Вердикт

Лучшей базы данных вообще не существует, есть лучшая для вашего текущего этапа. Частый путь — прототип на Chroma и переход на Qdrant, Weaviate, Milvus или Pinecone, когда понадобится надёжность продакшен-уровня.