pgvector тащит или нужна отдельная векторная БД для RAG?

[vadim9808]

Мы как раз прошли этот путь — 1.8 млн чанков, 1536d от text-embedding-3-small, pgvector 0.7.0 на PG 16. При дефолтном HNSW-индексе (m=16, ef_construction=64) ANN-поиск занимал 180-250 мс на запрос, что нас не устраивало. Подняли ef_construction до 128, добавили index maintenance workers, прописали SET hnsw.ef_search = 100 на уровне сессии — упали до 40-60 мс. На 2 млн чанков pgvector вполне тянет, если нет жёсткого требования вроде < 10 мс. Qdrant начинает реально выигрывать только когда надо фильтровать по payload при поиске — там нативные индексы на метаданных, а в pgvector приходится делать pre-filter по WHERE и теряешь скорость.

[yaroslav_hex13]

Важный момент по которому часто спотыкаются: 2 млн чанков * 1536 float32 = ~12 ГБ только на векторы, плюс HNSW-граф ещё столько же сверху. Если у вашего PG-хоста меньше ~30 ГБ RAM, то при cold start поиск будет дёргать диск и латентность улетит в секунды. Проверьте pg_statio_user_indexes — смотрите на blks_read vs blks_hit для вашего векторного индекса. Если hit ratio ниже 0.95, это первопричина тормозов, и никакой Milvus не поможет пока не решите вопрос с памятью.

[bytecode1580]

Ещё один угол: если у вас гибридный поиск (вектор + BM25/full-text), то pgvector + pg_trgm или pgvector + tantivy через paradedb могут дать приличный результат прямо в Postgres без второго хранилища. Мы тестировали paradedb на похожем объёме — reciprocal rank fusion работает из коробки, и не нужно синхронизировать два стора. Qdrant/Milvus имеет смысл когда нужны мультиарендность, десятки миллионов векторов, или кластеризация — для 2 млн чанков это скорее архитектурное усложнение ради усложнения.