Демо прошло, начались проблемы
Первый прототип на RAG обычно собирается за вечер: документы загрузили, эмбеддинги посчитали, векторный поиск подключили. Вопросы он вроде бы понимает. Проблемы начинаются позже. Поиск замедляется на реальных объёмах. После фильтрации по метаданным результаты внезапно пропадают. Команда тратит недели на систему, которая проекту не нужна.
Выбор базы для векторного поиска — это не гонка за самым навороченным решением. Это ответ на вопрос, какая нагрузка у вас на самом деле. Разберу три варианта: PostgreSQL с pgvector, Qdrant и Milvus.
Когда хватит PostgreSQL с pgvector
pgvector — расширение для PostgreSQL, которое добавляет тип для хранения векторов и поиск по ним. Если данные уже лежат в Postgres, вы получаете векторный поиск без нового сервиса. Один бэкап, одна система мониторинга, знакомый SQL.
Этого достаточно, когда:
- объём векторов небольшой или средний;
- фильтры по метаданным простые и хорошо ложатся на обычные индексы;
- команда уже умеет работать с Postgres;
- к векторному поиску не предъявляют жёстких требований по задержке.
Главная выгода здесь — меньше движущихся частей. Не нужно синхронизировать данные между двумя хранилищами, не нужно писать отдельный слой доступа. Для многих внутренних RAG-систем этого хватает с запасом.
Но есть предел. Когда векторов становится много, а фильтры усложняются, Postgres начинает упираться. Поиск с фильтрацией по нескольким полям может отдавать пустой результат или заметно тормозить. Это повод проверить архитектуру, а не сразу менять базу.
Qdrant: когда поиск пора выносить
Qdrant — отдельная векторная база. Её смысл в том, чтобы взять на себя именно задачу поиска по векторам с фильтрацией, не таща за собой всю нагрузку реляционной СУБД.
Выносить поиск в Qdrant имеет смысл, если:
- объём векторов растёт и Postgres перестаёт держать задержку;
- фильтрация по метаданным стала основной болью: результаты пропадают или запросы замедляются;
- нужна более предсказуемая работа поиска под нагрузкой.
Цена решения — новая инфраструктура. Появляется второй сервис, который надо разворачивать, обновлять и мониторить. Данные приходится синхронизировать между основным хранилищем и Qdrant. Это реальная работа, и её стоит закладывать заранее.
Если фильтры у вас простые, а объёмы скромные, Qdrant добавит сложности без ощутимой отдачи.
Milvus: когда сложность оправдана
Milvus — тяжёлая распределённая система для векторного поиска. Она рассчитана на большие объёмы и серьёзную нагрузку, но и требует соответствующей инфраструктуры.
Сложная архитектура Milvus оправдана, когда:
- векторов действительно очень много;
- нагрузка высокая и распределённая;
- требования к масштабированию нельзя закрыть одной машиной.
Для типичного проекта с документами и внутренним чатом Milvus почти всегда избыточен. Развернуть его несложно, а вот сопровождать — отдельная задача. Команда будет тратить силы на систему, которая больше, чем нужно продукту.
Как выбрать без лишней архитектуры
Порядок действий простой. Сначала проверьте, хватает ли pgvector. Если данные уже в Postgres, начните с него и измерьте задержку на реальных запросах с реальными фильтрами. Не на демо-данных.
Если упёрлись в предел, переходите к Qdrant. Вынос поиска в отдельную базу решает проблемы с фильтрацией и нагрузкой, но добавляет сервис и синхронизацию. Это разумный шаг, когда боль уже измерена.
Milvus выбирайте только тогда, когда масштаб действительно требует распределённой системы. Не «на вырост».
Главная ошибка здесь — строить архитектуру под предполагаемую нагрузку, а не под текущую. Начните с простого, измерьте, где болит, и усложняйте по факту. Так RAG останется рабочим инструментом, а не проектом по сопровождению инфраструктуры.
