Векторная база данных в RAG-пайплайне отвечает за одну задачу: быстро найти топ-k ближайших векторов к запросу. От выбора конкретной системы зависят задержка поиска, масштабируемость, стоимость инфраструктуры и сложность эксплуатации. Ниже — разбор основных вариантов с акцентом на то, что реально влияет на решение.
Прежде чем сравнивать продукты, зафиксируем критерии, которые имеют практическое значение для RAG:
Chroma — легковесная векторная база, написанная на Python с Rust-ядром. Ориентирована на минимальный порог входа.
Сильные стороны:
Ограничения:
Когда выбирать: прототип, хакатон, внутренний инструмент с небольшой базой документов, когда скорость разработки важнее производительности.
Qdrant написан на Rust, предоставляет REST и gRPC API, поддерживает фильтрацию через payload-поля.
Сильные стороны:
Ограничения:
Когда выбирать: продакшен-системы с миллионами документов, где важны фильтрация и низкая задержка. Хороший выбор по умолчанию для большинства RAG-проектов среднего и крупного масштаба.
Milvus — распределённая векторная база, спроектированная для миллиардов векторов. Архитектура разделяет хранение, вычисление и координацию (через etcd, MinIO/S3, Pulsar/Kafka).
Сильные стороны:
Ограничения:
Когда выбирать: когда коллекция превышает 100 млн векторов или требуется мульти-тенантность с изоляцией на уровне partition.
Weaviate выделяется тем, что может самостоятельно вызывать embedding-модель при индексации и запросе (vectorizer-модули).
Сильные стороны:
Ограничения:
Когда выбирать: если хочется минимизировать код пайплайна и использовать готовую интеграцию с провайдером эмбеддингов, а также нужен гибридный поиск без ручной реализации.
pgvector — расширение PostgreSQL, добавляющее тип
Сильные стороны:
Ограничения:
Когда выбирать: если PostgreSQL уже в стеке, коллекция небольшая (до ~5 млн), и команда не хочет добавлять новый компонент.
1. Выбор по бенчмаркам без учёта фильтрации. Большинство публичных бенчмарков (ann-benchmarks и подобные) измеряют чистый ANN-поиск без фильтров. В RAG почти всегда есть фильтр по метаданным, и поведение системы под нагрузкой с фильтрами может отличаться в разы.
2. Игнорирование стоимости памяти. Вектор размерностью 1536 в float32 занимает 6 КБ. Миллион таких векторов — ~6 ГБ только на данные, без учёта индекса. HNSW-индекс добавляет 30–100% сверху. Если память ограничена, смотрите на поддержку квантования или DiskANN.
3. Использование Chroma в продакшене без нагрузочного тестирования. Chroma удобна для разработки, но при конкурентном доступе и больших коллекциях может стать узким местом. Переход на другую базу на позднем этапе болезнен.
4. Смешивание задач. Векторная база — не замена полнотекстовому поиску. Если нужен точный поиск по ключевым словам, артикулам или ID, лучше оставить его в Elasticsearch/PostgreSQL, а векторную базу использовать только для семантического поиска.
Для большинства RAG-проектов с коллекцией от 1 до 50 млн векторов разумный выбор — Qdrant или Weaviate. Если инфраструктура уже построена вокруг PostgreSQL и коллекция небольшая — pgvector. Если масштаб превышает 100 млн — Milvus. Если нужен быстрый прототип — Chroma.
Что определяет выбор векторной базы
Прежде чем сравнивать продукты, зафиксируем критерии, которые имеют практическое значение для RAG:
- Размер коллекции. Сколько векторов планируется хранить: тысячи, миллионы или миллиарды.
- Размерность вектора. Определяется embedding-моделью Как выбрать embedding-модель для RAG: размер вектора, язык, качество и стоимость поиска. Типичные значения: 384 (MiniLM), 768 (BERT-based), 1024–1536 (OpenAI, BGE), 3072 (некоторые мультимодальные модели).
- Требования к задержке. Интерактивный чат требует ответа за десятки миллисекунд; батч-обработка допускает секунды.
- Фильтрация метаданных. Почти всегда нужно ограничивать поиск по источнику, дате, категории документа.
- Масштабирование. Горизонтальное масштабирование, репликация, шардирование.
- Операционная сложность. Сколько усилий нужно на деплой, мониторинг и обновление.
- Гибридный поиск. Поддержка комбинации векторного и ключевого (BM25/keyword) поиска в одном запросе.
Chroma: быстрый старт и прототипирование
Chroma — легковесная векторная база, написанная на Python с Rust-ядром. Ориентирована на минимальный порог входа.
Сильные стороны:
- Запускается в-process (как библиотека) или как отдельный сервер через Docker.
- Не требует внешней конфигурации для старта.
- Подходит для локальной разработки, экспериментов, небольших проектов (до ~1 млн векторов).
Ограничения:
- Горизонтальное масштабирование отсутствует или ограничено (зависит от версии).
- Производительность на больших коллекциях заметно ниже специализированных решений.
- Фильтрация метаданных базовая, без сложных предикатов.
Когда выбирать: прототип, хакатон, внутренний инструмент с небольшой базой документов, когда скорость разработки важнее производительности.
Qdrant: баланс производительности и удобства
Qdrant написан на Rust, предоставляет REST и gRPC API, поддерживает фильтрацию через payload-поля.
Сильные стороны:
- Высокая производительность на коллекциях в десятки миллионов векторов.
- Гибкая фильтрация метаданных: вложенные условия, геопространственные фильтры, полнотекстовый поиск по payload.
- Квантование векторов (scalar, product, binary) для снижения потребления памяти.
- Поддержка sparse-векторов и гибридного поиска (dense + sparse в одном запросе).
- Горизонтальное масштабирование через шардирование и репликацию.
- Snapshot-бэкапы и восстановление.
Ограничения:
- Операционная сложность выше, чем у Chroma: нужен отдельный кластер для продакшена.
- Нет встроенного BM25 — гибридный поиск реализуется через sparse-векторы, а не через классический keyword-индекс.
Когда выбирать: продакшен-системы с миллионами документов, где важны фильтрация и низкая задержка. Хороший выбор по умолчанию для большинства RAG-проектов среднего и крупного масштаба.
Milvus: максимальная масштабируемость
Milvus — распределённая векторная база, спроектированная для миллиардов векторов. Архитектура разделяет хранение, вычисление и координацию (через etcd, MinIO/S3, Pulsar/Kafka).
Сильные стороны:
- Масштабирование до миллиардов векторов.
- Множество индексных типов: IVF_FLAT, IVF_SQ8, HNSW, DiskANN, GPU-индексы.
- Поддержка гибридного поиска (векторный + скалярный фильтр).
- Milvus Lite — встраиваемый режим для разработки.
- Активное комьюнити и интеграция с LangChain, LlamaIndex.
Ограничения:
- Операционная сложность: полноценный кластер требует etcd, объектного хранилища и message broker. Это минимум 3–4 компонента инфраструктуры.
- Для коллекций до 10 млн векторов избыточен — проще взять Qdrant или Weaviate.
- Кривая обучения выше из-за количества конфигурационных параметров.
Когда выбирать: когда коллекция превышает 100 млн векторов или требуется мульти-тенантность с изоляцией на уровне partition.
Weaviate: встроенный ML-пайплайн
Weaviate выделяется тем, что может самостоятельно вызывать embedding-модель при индексации и запросе (vectorizer-модули).
Сильные стороны:
- Встроенные модули для OpenAI, Cohere, HuggingFace и других провайдеров эмбеддингов.
- Гибридный поиск (BM25 + векторный) из коробки.
- GraphQL API для сложных запросов.
- Мульти-тенантность на уровне коллекции.
Ограничения:
- Привязка к модульной архитектуре: если нужна кастомная логика эмбеддинга, приходится обходить встроенные модули.
- Потребление памяти выше, чем у Qdrant при сопоставимых коллекциях (зависит от конфигурации индекса).
Когда выбирать: если хочется минимизировать код пайплайна и использовать готовую интеграцию с провайдером эмбеддингов, а также нужен гибридный поиск без ручной реализации.
pgvector: когда PostgreSQL уже есть
pgvector — расширение PostgreSQL, добавляющее тип
vector и индексы для приближённого поиска (IVFFlat, HNSW).Сильные стороны:
- Не нужно вводить новую систему: векторный поиск живёт рядом с реляционными данными.
- Транзакционность, бэкапы, репликация — всё из PostgreSQL.
- Для коллекций до нескольких миллионов векторов производительность приемлема.
- HNSW-индекс в последних версиях даёт конкурентную скорость.
Ограничения:
- На миллиардах векторов не масштабируется без серьёзного шардирования.
- Фильтрация метаданных — это SQL, что мощно, но не всегда удобно для сложных вложенных условий.
- Нет встроенного гибридного поиска (нужно комбинировать tsvector + vector вручную).
Когда выбирать: если PostgreSQL уже в стеке, коллекция небольшая (до ~5 млн), и команда не хочет добавлять новый компонент.
Сравнительная таблица
| Критерий | Chroma | Qdrant | Milvus | Weaviate | pgvector |
|---|---|---|---|---|---|
| Масштаб | до ~1 млн | десятки млн | миллиарды | десятки млн | до ~5 млн |
| Гибридный поиск | нет | sparse + dense | да | да (BM25 + vector) | вручную |
| Фильтрация метаданных | базовая | гибкая | да | да | SQL |
| Операционная сложность | минимальная | средняя | высокая | средняя | низкая (если PG есть) |
| Встраиваемый режим | да | нет | да (Lite) | нет | да (расширение) |
| Квантование | нет | да | да | нет | нет |
Типичные ошибки при выборе
1. Выбор по бенчмаркам без учёта фильтрации. Большинство публичных бенчмарков (ann-benchmarks и подобные) измеряют чистый ANN-поиск без фильтров. В RAG почти всегда есть фильтр по метаданным, и поведение системы под нагрузкой с фильтрами может отличаться в разы.
2. Игнорирование стоимости памяти. Вектор размерностью 1536 в float32 занимает 6 КБ. Миллион таких векторов — ~6 ГБ только на данные, без учёта индекса. HNSW-индекс добавляет 30–100% сверху. Если память ограничена, смотрите на поддержку квантования или DiskANN.
3. Использование Chroma в продакшене без нагрузочного тестирования. Chroma удобна для разработки, но при конкурентном доступе и больших коллекциях может стать узким местом. Переход на другую базу на позднем этапе болезнен.
4. Смешивание задач. Векторная база — не замена полнотекстовому поиску. Если нужен точный поиск по ключевым словам, артикулам или ID, лучше оставить его в Elasticsearch/PostgreSQL, а векторную базу использовать только для семантического поиска.
Практический алгоритм выбора
- Определите размер коллекции и размерность вектора.
- Оцените, нужна ли фильтрация метаданных и насколько сложная.
- Решите, нужен ли гибридный поиск (семантика + ключевые слова).
- Оцените операционные возможности команды.
- Проведите нагрузочное тестирование на реальных данных с реальными фильтрами.
Для большинства RAG-проектов с коллекцией от 1 до 50 млн векторов разумный выбор — Qdrant или Weaviate. Если инфраструктура уже построена вокруг PostgreSQL и коллекция небольшая — pgvector. Если масштаб превышает 100 млн — Milvus. Если нужен быстрый прототип — Chroma.
Что проверить после развёртывания
- Задержка p95 при конкурентной нагрузке с фильтрами.
- Потребление RAM и диска при целевом объёме данных.
- Поведение при обновлении/удалении векторов (не все базы делают это эффективно).
- Время восстановления из бэкапа.
- Корректность результатов: сравните топ-10 с brute-force поиском на подвыборке, чтобы убедиться, что recall приемлемый.
