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

Меня зовут Владимир Ловцов, я специализируюсь на RAG-системах. В статье разберу, когда для векторного поиска достаточно PostgreSQL с pgvector, зачем выносить его в Qdrant и в каких случаях сложная архитектура Milvus действительно оправдана.

Что вообще такое RAG и векторная база

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

В упрощенном виде система работает так. 

• Документы извлекают из источников, очищают и делят на небольшие фрагменты — чанки. 

• Каждый чанк превращают в вектор, то есть числовое представление его смысла. 

• Когда пользователь задает вопрос, система тоже строит для него вектор, находит похожие чанки и передает их языковой модели как контекст для ответа.

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

Представим помощника по внутренней вики. У разных сотрудников есть доступ к разным пространствам, поэтому система не должна использовать закрытый документ в ответе человеку, который не может его прочитать. Значит, нужно не только найти семантически близкие чанки, но и вернуть достаточно результатов после проверки прав.

Как подготовить документы для RAG

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

• Соберите источники. Определите, какие документы войдут в базу знаний, кто их обновляет и какие версии считаются актуальными.

• Извлеките полезное содержимое. Уберите технический шум, сохранив заголовки, списки и структуру таблиц в подходящем формате, например Markdown. Сканы, схемы и изображения можно обработать с помощью OCR/VLM, индексировать напрямую через мультимодальные эмбеддинги, в том числе мультивекторные, или сочетать оба подхода.

• Разделите документы на чанки. Учитывайте заголовки, абзацы, списки и таблицы, а затем ограничивайте максимальный размер фрагмента. Простая нарезка по числу символов может оборвать мысль или таблицу посередине.

• Добавьте метаданные. Зафиксируйте источник, раздел, язык, версию, дату обновления, права доступа и другие признаки, которые понадобятся для фильтрации.

• Постройте эмбеддинги. Используйте одну модель для документов и пользовательских запросов, но учитывайте рекомендованный способ кодирования. Например, instruct-модели могут требовать разных инструкций для запроса и документа. Зафиксируйте модель и настройки — при их смене коллекцию придется пересчитать.

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

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

На что стоит опираться при выборе базы

Универсальной границы в духе «до миллиона векторов берем pgvector, после — Milvus» не существует. Один и тот же объем данных создает разную нагрузку в зависимости от размерности эмбеддингов, частоты запросов, обновлений и фильтров.

Но до сравнения решений полезно описать четыре группы требований.

1. Объем и рост данных

Посчитайте фактическое количество векторов после чанкинга. Оцените, как быстро коллекция будет расти, как часто обновляются документы и придется ли пересчитывать эмбеддинги при смене модели.

2. Профиль нагрузки

Зафиксируйте число одновременных запросов, частоту загрузки новых данных, допустимую задержку и требования к доступности. Одно дело — поиск для нескольких сотрудников, другое — сервис с тысячами параллельных пользователей.

3. Поиск и фильтрация

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

4. Возможности команды

Отдельную векторную СУБД нужно развертывать, обновлять, мониторить, резервировать и восстанавливать после сбоев. Более гибкая архитектура не принесет пользы, если команда не может стабильно ее обслуживать.

После этого выбор обычно сводится к трем вариантам: расширению pgvector внутри PostgreSQL или отдельным векторным СУБД Qdrant и Milvus.

pgvector: векторный поиск внутри PostgreSQL

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

Плюсы pgvector

Не нужно поднимать отдельную систему 

Векторы, текст и метаданные можно связывать через SQL, обновлять в одной транзакции и обслуживать привычными средствами PostgreSQL. Для прототипа и многих прикладных RAG-систем этого достаточно.

Поддерживает точный и приближенный поиск

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

• HNSW строит многослойный граф связей между векторами. Обычно он дает хорошее соотношение скорости и полноты поиска, но дольше строится и требует больше памяти.

• IVFFlat делит векторы на группы и просматривает только часть из них. Он быстрее строится и потребляет меньше памяти, но сильнее зависит от настроек и состава данных.

Не стоит начинать оптимизацию RAG с выбора между HNSW и IVFFlat. Если система плохо отвечает, сначала проверьте парсинг, чанкинг, эмбеддинги и фильтрацию. Индекс имеет смысл менять, когда измерения показывают, что проблема именно в нем.

Минусы pgvector

При приближенном поиске PostgreSQL может сначала получить кандидатов из векторного индекса, а затем применить часть фильтров. Из-за этого результатов останется меньше, чем запросила система. Например, поиск нашел десять близких чанков, но пользователю разрешено читать только два.

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

Гибридный поиск менее нативный. pgvector отвечает за поиск по векторам, а полнотекстовый поиск выполняет PostgreSQL. Результаты двух выдач приходится объединять и ранжировать отдельно.

Векторный поиск делит ресурсы с остальной нагрузкой PostgreSQL. Если растут задержки, потребление памяти, время записи и транзакций основной системы, поиск может начать мешать бизнес-операциям. Выносить его стоит не после условного миллиона векторов, а когда PostgreSQL перестает выполнять требования или векторный контур нужно масштабировать отдельно.

Qdrant и Milvus: поиск в отдельной системе

Qdrant и Milvus — самостоятельные векторные СУБД. Они выносят поиск из основной PostgreSQL: для него можно выделить отдельные ресурсы, независимо менять конфигурацию и масштабировать нагрузку.

Плюсы отдельной векторной СУБД

• Поиск можно вынести на отдельные ресурсы и изолировать его нагрузку от бизнес-нагрузки PostgreSQL.

• Команда получает специализированные механизмы фильтрации, гибридного поиска, шардирования и репликации. 

• Векторный контур можно развивать и масштабировать независимо от основной базы.

Минусы отдельной векторной СУБД

• В архитектуре появляется еще один компонент, сетевой вызов и новая точка отказа. 

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

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

Qdrant: в меру понятная система

Qdrant хранит вектор вместе с payload — связанными данными, по которым можно фильтровать результаты. Система оценивает, сколько точек останется после фильтрации, и выбирает стратегию поиска: использует HNSW с учетом условий или выполняет точный поиск по небольшому отфильтрованному набору. Это полезно для RAG с большим количеством метаданных и ограничениями доступа. 

Система поддерживает плотные и разреженные векторы и позволяет собирать гибридные запросы, объединяя семантический и полнотекстовый поиск. Коллекцию можно разделить на шарды и распределить между однотипными узлами, а реплики использовать для отказоустойчивости и масштабирования чтения.

Qdrant стоит рассматривать, когда поиск уже нужно вынести из PostgreSQL, но проекту не требуется сложная архитектура с независимо масштабируемыми компонентами.

Milvus: гибкая, но сложная

Milvus поддерживает семантический и полнотекстовый поиск, а также их нативное объединение в гибридном запросе, фильтрацию по скалярным полям и разные типы векторных индексов. Систему можно развернуть в трех вариантах:

• Milvus Lite — для локальной разработки и прототипов.

• Milvus Standalone — основные компоненты работают в одном процессе на одной машине.

• Milvus Distributed — компоненты разнесены по отдельным узлам и могут масштабироваться независимо.

Дальше будем говорить именно о Milvus Distributed: этот вариант дает больше возможностей для масштабирования, но и заметно усложняет эксплуатацию.

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

Цена такой гибкости — более сложная эксплуатация. Компонентов больше, их нужно наблюдать, обновлять и восстанавливать. Если проект не использует преимущества раздельного масштабирования, архитектура превращается в лишнюю работу.

В одном из наших проектов мы сначала попробовали Milvus. На практике его оказалось сложнее поддерживать: отдельные компоненты могли падать и не всегда штатно поднимались, а DevOps-команда тратила время на восстановление. 

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

Из этого кейса не следует, что Milvus хуже Qdrant. Если системе нужно независимо масштабировать хранение и вычисления, его архитектура становится преимуществом. Но брать ее просто «на вырост» не стоит: прогнозируемый миллион запросов в день после запуска может превратиться в несколько десятков.

Как выбрать между pgvector, Qdrant и Milvus

Самый вредный совет здесь — сразу брать наиболее масштабируемое решение. Начните с минимального варианта, который закрывает реальные требования, а усложняйте архитектуру только тогда, когда это реально нужно и команда сможет содержать систему.

Чек-лист: как выбрать базу для RAG и подготовить документы

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

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

• Извлеките из документов текст, таблицы и другие полезные элементы.

• Определите правила чанкинга, добавьте метаданные и постройте эмбеддинги.

• Проверьте качество поиска на реальных пользовательских вопросах.

• Посчитайте фактическое количество векторов и оцените рост коллекции.

• Опишите профиль нагрузки: запросы, обновления, задержку и доступность.

• Перечислите фильтры и решите, нужен ли гибридный поиск.

• Начните с самого простого решения, которое закрывает требования.

• Сравнивайте варианты на своих данных и инфраструктуре, а не только по публичным бенчмаркам.

• Учтите не только производительность, но и стоимость эксплуатации.

Как считаете, RAG еще решает свои задачи — или технология уже начинает устаревать? Давайте обсудим в комментариях.