Pgvector или Qdrant: где хранить векторы

Выбор хранилища векторов обсуждают так, будто это принципиальное архитектурное решение. В большинстве проектов это не так: на объёмах, типичных для корпоративной базы знаний, работает и то и другое, а разница проявляется в эксплуатации, а не в качестве ответов.

Поэтому вопрос лучше ставить иначе: не «что лучше», а «когда расширения для существующей базы перестаёт хватать». Ответ обычно наступает позже, чем ожидают.

Что это такое

pgvector — расширение для PostgreSQL, добавляющее тип «вектор» и поиск по близости. Никакого нового сервиса: та же база, те же бэкапы, те же права, те же инструменты. Векторы лежат в таблице рядом с обычными полями.

Qdrant и подобные (Weaviate, Milvus, Vespa) — отдельные базы, спроектированные под векторный поиск. Своя инфраструктура, свой протокол, свои бэкапы — и специализированные возможности, которых у расширения нет или они беднее.

Главное преимущество pgvector, о котором забывают

Векторы лежат в одной транзакции с остальными данными.

Это звучит скучно и решает больше проблем, чем скорость поиска.

Когда векторы в отдельной базе, у вас два хранилища, которые обязаны быть согласованы. Документ удалён в PostgreSQL, а его векторы остались в Qdrant — система отвечает по удалённому документу. Обновили документ, обновление векторов упало — система отвечает по старой редакции. Восстановили базу из бэкапа за вторник, а векторное хранилище за среду — расхождение.

Это не теоретические риски, а рутина эксплуатации. С pgvector их просто нет: удаление строки удаляет вектор, откат транзакции откатывает всё, бэкап один.

Тот же аргумент относится к правам доступа: фильтрация по правам — это обычный JOIN с таблицей прав, а не синхронизация меток в два хранилища. Подробно — «Разграничение доступа в RAG».

Что даёт отдельная векторная база

Скорость на больших объёмах. Специализированные структуры и оптимизации проявляются на миллионах векторов. На десятках тысяч разница незаметна.

Развитая фильтрация при поиске. Фильтры применяются внутри процесса поиска, а не до или после него. При жёстких фильтрах — например, поиск только по документам одного отдела — это даёт и скорость, и корректность результата.

Сжатие векторов. Квантизация уменьшает объём памяти в разы с небольшой потерей качества. На больших корпусах это прямая экономия.

Горизонтальное масштабирование. Разнесение по узлам заложено в конструкцию.

Готовые механизмы. Именованные векторы, несколько представлений одного документа, гибридный поиск из коробки.

Сравнение

Ориентиры по объёму

Числа приблизительные и зависят от размера вектора и требований к скорости, но задают порядок.

До 100 тысяч фрагментов. pgvector без раздумий. Это объём корпоративной базы знаний в несколько тысяч документов — типичный случай.

100 тысяч — 1 миллион. pgvector работает, требует внимания к индексам и памяти. Отдельная база даст выигрыш, но не обязательна.

Больше 1 миллиона. Здесь специализированное хранилище начинает оправдываться, особенно при высокой нагрузке и сложной фильтрации.

Для ориентира: 2 000 страниц документации — это примерно 10–20 тысяч фрагментов. То есть типичная корпоративная база знаний находится глубоко в первой строке.

Когда переезд действительно нужен

Не по объёму, а по симптомам:

• Поиск стал заметно медленным, и настройка индексов не помогает.
• Векторы не помещаются в память, база уходит в диск, скорость падает.
• Нужна сложная фильтрация, и она либо медленная, либо даёт неполные результаты.
• Нужно горизонтальное масштабирование — один сервер исчерпан.
• Нужны специфические возможности: сжатие, несколько векторных представлений документа, распределённый поиск.

Если ни один пункт не про вас — переезжать незачем, сколько бы ни было векторов.

Разбор: переезд, который отменили

Задача. Внутренняя база знаний производственной компании: 3 500 документов, около 45 тысяч фрагментов.

Что происходило. Система работала на pgvector. Поиск занимал больше двух секунд, пользователи жаловались. Команда предложила переезд на выделенную векторную базу — оценили в несколько недель работы.

Что показал разбор.

Первое: индекс не был построен. Поиск шёл полным перебором всех 45 тысяч векторов. При таком объёме это ещё работает, но медленно. Построение индекса заняло минуты и сократило время поиска примерно на порядок.

Второе: фильтр по правам применялся после поиска. Система брала 50 ближайших, затем отбрасывала недоступные пользователю — и иногда оставалось три фрагмента из пятидесяти. Приходилось искать повторно с большим лимитом. Перенос фильтра в условие запроса убрал повторные поиски.

Третье: векторы хранились в полном размере, хотя модель позволяла укоротить их без заметной потери качества. Сокращение уменьшило объём индекса, и он целиком поместился в память.

Итог. Время поиска сократилось с двух с лишним секунд до величины, которая перестала быть заметной. Переезд отменили. Затраты — один день работы вместо нескольких недель.

Что стоит из этого забрать. Прежде чем менять хранилище, проверьте три вещи: построен ли индекс, как применяются фильтры, помещаются ли векторы в память. В моей практике это закрывает большинство жалоб на скорость при объёмах ниже миллиона.

Это не значит, что специализированные базы не нужны. Это значит, что до них надо дорасти, а не начинать с них.

С чего начинать

Если PostgreSQL уже есть — начинайте с pgvector. Нет новой инфраструктуры, нет проблемы согласованности, права работают обычным SQL. Переехать позже можно, и это не катастрофа: векторы пересчитывать не придётся, если модель не меняется.

Отдельную базу берите сразу, если заранее известно, что объём измеряется миллионами, или если нужны возможности, которых у расширения нет.

Чего не стоит делать — выбирать хранилище раньше, чем настроены нарезка и поиск. Качество ответов определяется ими, а не тем, где лежат векторы. Разница между хорошей и плохой нарезкой видна невооружённым глазом; разница между хранилищами на типичных объёмах — нет.

Частые вопросы

Что выбрать для RAG: pgvector или отдельную векторную базу?

Если PostgreSQL уже используется, начинайте с pgvector: не нужна новая инфраструктура, векторы согласованы с данными в одной транзакции, права доступа работают обычным SQL. Отдельная база оправдана на миллионах векторов, при сложной фильтрации или когда нужно горизонтальное масштабирование.

На каком объёме pgvector перестаёт справляться?

Ориентировочно после миллиона фрагментов, и то не всегда — многое зависит от размера вектора, настройки индексов и объёма памяти. Для сравнения: 2 000 страниц документации дают примерно 10–20 тысяч фрагментов, то есть типичная корпоративная база знаний до этого предела не доходит.

Придётся ли пересчитывать векторы при переезде?

Нет, если не меняется модель векторизации: векторы переносятся как есть. Пересчёт нужен только при смене модели эмбеддингов, потому что векторы разных моделей несравнимы.

Почему поиск медленный, хотя данных немного?

Три частые причины: не построен индекс и поиск идёт полным перебором; фильтры применяются после поиска, а не в его условии; векторы не помещаются в память. Проверять стоит именно в этом порядке — часто этого достаточно, и переезд не требуется.

Можно ли хранить векторы и документы в разных местах?

Можно, но появляется задача их согласования: удаление документа должно удалять векторы, обновление — обновлять, восстановление из бэкапа — восстанавливать оба хранилища на одну точку. Это рутинный источник ошибок вида «система отвечает по удалённому документу».

Влияет ли выбор хранилища на качество ответов?

Практически нет. Качество определяется нарезкой документов, моделью векторизации и настройкой поиска. Хранилище влияет на скорость, стоимость и удобство эксплуатации.

Что дальше

На качество влияют другие звенья: «Чанкинг документов», «Эмбеддинги для русского», «Гибридный поиск». Как хранилище связано с обновлением корпуса — «Обновление базы знаний без переиндексации».

Выбор и настройка хранилища под ваш объём и требования — часть работы по разработке и внедрению ИИ.