Векторные БД: pgvector, Qdrant, Chroma — что выбрать под RAG

В RAG-системе (Retrieval-Augmented Generation) пользователь задаёт вопрос, мы ищем релевантные куски документов по эмбеддингу и подмешиваем их в промпт. Узкое место — не LLM, а векторный поиск: 200 мс на embed + 50 мс на retrieve + 1.5 с на LLM. Если retrieve деградирует до 800 мс — система ощущается медленной. Разбираем три популярных хранилища: pgvector, Qdrant, Chroma.

Что вообще должна уметь векторная БД для RAG

• Approximate Nearest Neighbour (ANN) поиск по cosine / dot product / L2. Точный k-NN на миллионе векторов — это секунды, ANN — миллисекунды.
• Метаданные и фильтры на запросе. «Найди похожие куски, но только из документов клиента X, опубликованных после марта». Без этого RAG превращается в «нашёл что-то релевантное, но не то».
• Гибридный поиск — комбинация BM25 (по словам) и эмбеддингов. Семантика ловит «как», полнотекст — точные коды, артикулы, имена.
• Инкрементальные апдейты — добавлять и удалять документы без переиндексации.
• Управление версиями. Эмбеддинги старой модели и новой несовместимы. Нужен пересчёт + миграция.

pgvector — расширение PostgreSQL

Когда брать. У вас уже Postgres в стеке, и данных — до 10 миллионов векторов с размерностью 768–1536. Хочется одной БД, одного бэкапа, одного админа.

Плюсы. JOIN с обычными таблицами «из коробки» — фильтры по любым полям работают как стандартный SQL. HNSW-индекс с версии 0.5.0 даёт миллисекунды на запросе. Бэкап и репликация — те же, что у Postgres. Знакомые админы.

Минусы. На 50+ миллионах векторов индекс HNSW начинает занимать десятки гигабайт RAM. Скейлинг — только вертикальный (или партиционирование вручную). На 10× меньшая throughput, чем у специализированных решений на сопоставимом железе.

Стек. Managed PostgreSQL от Yandex Cloud, VK Cloud, Selectel — pgvector доступен в свежих версиях. Локально — Docker-образ или сборка из исходников.

Qdrant — специализированная, на Rust

Когда брать. Векторов 10+ миллионов, нужны быстрые фильтры по метаданным, планируется рост.

Плюсы. HNSW + payload-индексы (на метаданные) дают фильтрацию без падения скорости. Распределённый режим — шардирование и репликация. Гибридный поиск (sparse + dense) из коробки с версии 1.10. REST + gRPC. Self-hosted бесплатно, есть Qdrant Cloud (платно).

Минусы. Отдельный сервис в стеке — отдельный бэкап, отдельный мониторинг. Sync между основной БД и Qdrant ложится на приложение. Дев-команде придётся учить новый клиент.

Стек. Self-host в Yandex Cloud / VK Cloud через Docker или k8s. Cloud-версия Qdrant на серверах в РФ напрямую не доступна, но можно self-managed в managed k8s.

Chroma — embedded, для прототипов

Когда брать. Прототип, MVP, исследовательский RAG, до 1 миллиона векторов. Однопользовательский режим или маленькая команда.

Плюсы. Запускается одной строкой Python. Идеально для Jupyter, для локальной разработки, для быстрого PoC. Простой API, минимум настроек.

Минусы. В однопроцессном режиме плохо переживает прод-нагрузку. Метаданные-фильтры медленнее, чем у Qdrant. На больших объёмах деградирует. Это не «база для продакшена», это «удобная штука для R&D».

Сравнение в таблице

Условия: 5 млн векторов, размерность 1024, top-k=10, фильтр по 2 полям metadata, железо — 8 ядер 32 ГБ RAM.

• pgvector. p95 ~50–80 мс на запросе. Индекс ~12 ГБ RAM. Throughput ~150 QPS.
• Qdrant. p95 ~10–25 мс. Индекс ~9 ГБ RAM. Throughput ~600 QPS.
• Chroma. p95 ~80–200 мс (sqlite-backed). Throughput ~50 QPS. Для прода не подходит.

Цифры ориентировочные, зависят от sparse/dense настройки и параметров HNSW (m, ef_construct). Меряйте на своих данных.

Что упускают при выборе

• Стоимость пересчёта эмбеддингов. При смене модели (новый text-embedding) надо пересчитать всё. Для 10 млн чанков через OpenAI API — это $200–500. Локальные модели (multilingual-e5, bge-m3) дешевле, но медленнее.
• Размерность. 1536 (OpenAI ada-002) даёт 6 ГБ на миллион векторов. 768 (e5-base) — 3 ГБ. Если БД толстеет — уменьшение размерности через PCA / Matryoshka даёт −40–60% дешевле.
• Мониторинг качества retrieve. Без него непонятно, насколько RAG отвечает по делу. Recall@k, hit rate по золотой выборке, ручная проверка — должна быть инфраструктура для оценки.
• Дельта-индексация. При обновлении документов — пересоздать только их чанки. Часто реализуют через soft-delete + nightly cleanup.

Как выбрать в три вопроса

1. У вас уже Postgres? Да → начинайте с pgvector. На <10 млн векторов всё взлетит без зоопарка.
2. Векторов >20 млн и нужны быстрые фильтры? Qdrant. Self-hosted в Yandex Cloud или VK Cloud.
3. Это прототип на ноутбуке? Chroma. Без раздумий, потом мигрируете.

Итог: pgvector — дефолт для тех, у кого Postgres. Qdrant — когда переросли. Chroma — для R&D. Узким местом RAG быстро становится не векторная БД, а качество чанкинга и оценка результатов — но это уже другая статья.