Выбор начинается не с бенчмарков

Большинство сравнений векторных баз сводится к графику QPS при фиксированном recall. В реальном RAG-проекте решают другие факторы: где физически лежат данные, кто будет обновлять индекс, сколько стоит гигабайт RAM на миллион векторов и как база ведёт себя при жёсткой фильтрации по метаданным. Поэтому вопрос «что быстрее» почти всегда вторичен по отношению к «что мы сможем эксплуатировать через год без выделенной команды».

pgvector: когда Postgres уже в контуре

pgvector — разумный дефолт, если в инфраструктуре есть Postgres, а коллекция не превышает нескольких миллионов чанков. HNSW-индексы, тип halfvec и бинарное квантование в актуальных версиях позволяют уложиться в приемлемую память, а транзакционность и привычный бэкап снимают целый класс проблем с консистентностью. Главные ограничения — конкуренция за ресурсы с OLTP-нагрузкой и слабая горизонтальная масштабируемость: шардировать придётся вручную.

Для российских проектов это часто оптимальный путь. Postgres Pro или сборка под Astra Linux уже проходят согласование с ИБ, а данные не покидают контур, что критично при работе с персональными данными и коммерческой тайной.

Qdrant: баланс для продакшн-RAG

Qdrant выигрывает там, где нужны быстрые фильтры по payload и гибридный поиск. Разреженные векторы и объединение dense+sparse в одном запросе закрывают задачу поиска по артикулам, номерам договоров и аббревиатурам, где чистые эмбеддинги стабильно проваливаются. Квантование и хранение векторов на диске через mmap снижают стоимость RAM в разы.

Типичный сценарий — 5–50 млн чанков, мультитенантность через коллекции или payload-фильтры, требование p95 ниже 100 мс. Qdrant предсказуемо разворачивается в Kubernetes и в закрытом on-prem контуре без внешних зависимостей вроде объектного хранилища.

Milvus: масштаб и сегментация

Milvus выбирают, когда коллекция измеряется сотнями миллионов векторов или нужна изоляция тенантов на уровне партиций. Разделение compute и storage, GPU-индексы и DiskANN дают гибкость, которую pgvector не воспроизводит в принципе. Плата — операционная сложность: etcd, S3-совместимое хранилище, координаторы и отдельный кластер под нагрузку.

Для российских заказчиков это часто узкое место. Объектное хранилище и GPU-парк нужно где-то разместить, а сопровождение требует выделенной команды — при дефиците кадров это редко оправдано на старте.

Гибридный поиск важнее выбора СУБД

Качество RAG на 80% определяется не базой, а подготовкой данных: чанкингом по структуре документа, нормализацией, метаданными и реранкером. Ни одна из трёх баз не спасёт, если в индекс попадают обрывки таблиц, колонтитулы и дубли. Практический минимум — гибрид BM25 + dense, кросс-энкодер на топ-50 кандидатов и «золотой» набор из 100–200 реальных вопросов пользователей для замеров.

Как выбирать на практике

1. Зафиксируйте SLO: p95 задержки, recall@10, объём и темп роста коллекции.
2. Соберите 10–20 тыс. реальных чанков и замерьте на них, а не на датасетах из интернета.
3. Посчитайте стоимость RAM и диска на горизонте двух лет с учётом реплик.
4. Проверьте, как база переживает реиндексацию, удаление документов и обновление эмбеддингов.
5. Убедитесь, что решение встаёт в ваш контур: Astra Linux, Postgres Pro, CPU-only или отечественные ускорители.

В большинстве проектов, которые мы видим, старт на pgvector с последующей миграцией на Qdrant оказывается дешевле и быстрее, чем сразу поднимать Milvus «на вырост».

Как мы можем помочь

Мы проектируем и внедряем RAG-контуры под ключ: подбираем векторную базу под ваши SLO, настраиваем гибридный поиск и реранкинг, разворачиваем всё в закрытом контуре и интегрируем с 1С, CRM и внутренними порталами. Проведём замеры на ваших данных и покажем, где именно теряется качество ответов. Обсудить проект.