Выбор векторной базы без лишней сложности

В проектах RAG поиск по векторам на демо выглядит просто, но при росте документов и фильтров нагрузка быстро меняется. Команда может потратить месяцы на поддержку отдельной системы, хотя для задачи хватило бы расширения внутри PostgreSQL. Разбор помогает понять, когда pgvector решает задачу, а когда стоит переходить к Qdrant или Milvus. RAG здесь означает Retrieval-Augmented Generation — подход, при котором модель получает релевантные фрагменты из базы перед генерацией ответа. Векторная база хранит числовые представления текстов (эмбеддинги) и позволяет быстро находить похожие по смыслу куски документов.

Объём данных и реальная нагрузка

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

Фильтры по метаданным — права доступа, версия документа, раздел вики — тоже влияют на скорость. После применения фильтров должно оставаться достаточно результатов для передачи модели. Если фильтры строгие, даже при умеренном объёме данных требуется индекс, способный работать с комбинацией векторного и скалярного поиска. Для решения «брать или не брать» важно оценить, насколько часто меняются права и версии: частые обновления метаданных могут потребовать перестроения индекса и увеличить время отклика.

Когда pgvector остаётся оптимальным решением

Расширение pgvector добавляет типы векторов и индексы HNSW или IVFFlat прямо в PostgreSQL. HNSW строит граф соседей для быстрого поиска, а IVFFlat делит пространство на кластеры. Команда, уже использующая эту СУБД, получает векторный поиск без развёртывания новых сервисов и без изменения процессов резервного копирования. Запросы можно выполнять в рамках одной транзакции вместе с обычными реляционными данными.

Ограничения проявляются при высокой параллельной нагрузке и размерности эмбеддингов выше 1536. В таком случае растёт потребление памяти и время отклика. Если команда не планирует тысячи одновременных запросов и может жить с задержкой в 100-200 мс, pgvector остаётся разумным выбором на годы. При решении «брать или не брать» стоит проверить текущую версию PostgreSQL и наличие сертифицированной сборки: если инфраструктура уже настроена под строгие политики, добавление расширения минимизирует риски и не требует обучения новых специалистов.

Переход к отдельным векторным системам

Qdrant удобен, когда нужна гибкая фильтрация по метаданным и поддержка гибридного поиска по ключевым словам вместе с векторами. Гибридный поиск сочетает точное совпадение слов с семантической близостью векторов. Система позволяет обновлять отдельные точки без пересчёта всей коллекции и предоставляет удобный REST и gRPC интерфейсы. Для команд, уже имеющих опыт с Kubernetes, развёртывание Qdrant в кластере проходит быстрее, чем настройка сложных индексов внутри PostgreSQL.

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

Особенности эксплуатации в российских проектах

Многие компании уже используют PostgreSQL в контуре с сертифицированными сборками и строгими политиками безопасности. Добавление pgvector в таком случае не требует новых согласований и не увеличивает поверхность атаки. При переходе на Qdrant или Milvus приходится решать вопросы резервного копирования и мониторинга отдельно, а также проверять совместимость с существующими SIEM-системами. SIEM собирает логи и события безопасности из разных источников.

Если данных немного и команда небольшая, разумнее сначала нагрузить pgvector реальными запросами и только потом оценивать необходимость миграции. Такой подход снижает риски перерасхода ресурсов и позволяет быстрее вывести RAG в продакшен. Ключевой фактор решения — наличие в команде экспертизы по конкретной системе и готовность нести расходы на её сопровождение при росте нагрузки.

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Выбор векторной базы без лишней сложности.

Курс по теме — Каталог курсов Школы Больших Данных