Делаем RAG-поиск по корпоративной базе знаний, ~2 млн чанков, эмбеддинги 1536 размерности. Сейчас всё в pgvector. Народ пугает что на таких объёмах надо Qdrant/Milvus. Реально надо или pgvector вывезет?
✔ Лучший ответ сформирован автоматически — emacs_ops
Мы как раз прошли этот путь — 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 вполне…
2 млн векторов pgvector вывезет спокойно, особенно с HNSW индексом который добавили в 0.5+. Главное не используй ivfflat если у тебя данные меняются, и держи достаточно RAM под индекс.
Подтверждаю, у нас 5 млн на pgvector + HNSW, recall нормальный, latency p95 около 40мс. Плюс гигантский плюс — ты не плодишь ещё одну БД и делаешь metadata-фильтрацию обычным WHERE в том же запросе.
А вот по поводу фильтрации — у нас как раз pgvector затупил когда добавили жёсткие WHERE по метаданным поверх векторного поиска. HNSW и pre-filtering плохо дружат. В Qdrant с этим из коробки лучше.
Меняет, но не критично. В pgvector 0.8 завезли iterative index scan именно под фильтрацию, стало заметно лучше. Если фильтры не отрезают 99% данных — будет ок. Если отрезают — тогда да, специализированная БД выигрывает.
