На демо все выглядит безобидно: загружаем документы, строим эмбеддинги, подключаем векторный поиск — и 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
Решение | Когда подходит | Сильные стороны | Что учитывать |
pgvector | PostgreSQL уже используется, нагрузка умеренная | Простая архитектура, SQL и транзакции, привычная эксплуатация | Делит ресурсы с основной БД, фильтрация требует настройки |
Qdrant | Поиск нужно вынести, важны фильтры и гибридный поиск | Специализированная СУБД, можно распределять коллекции между одинаковыми узлами | Отдельный контур и синхронизация данных |
Milvus | Нужна крупная распределенная система и раздельное масштабирование | Независимое масштабирование хранения, запросов и загрузки | Больше компонентов и сложнее эксплуатация |
Самый вредный совет здесь — сразу брать наиболее масштабируемое решение. Начните с минимального варианта, который закрывает реальные требования, а усложняйте архитектуру только тогда, когда это реально нужно и команда сможет содержать систему.
Чек-лист: как выбрать базу для RAG и подготовить документы
Если нужен короткий ориентир, я бы не начинал с названия базы. Сначала проверьте данные и нагрузку — а уже потом сравнивайте решения.
Вот чек-лист, который пригодится на старте. Сравнивайте варианты на своих данных и при сопоставимом качестве поиска: более быстрый и легкий алгоритм может просто возвращать менее полную выдачу:
Извлеките из документов текст, таблицы и другие полезные элементы.
Определите правила чанкинга, добавьте метаданные и постройте эмбеддинги.
Проверьте качество поиска на реальных пользовательских вопросах.
Посчитайте фактическое количество векторов и оцените рост коллекции.
Опишите профиль нагрузки: запросы, обновления, задержку и доступность.
Перечислите фильтры и решите, нужен ли гибридный поиск.
Начните с самого простого решения, которое закрывает требования.
Сравнивайте варианты на своих данных и инфраструктуре, а не только по публичным бенчмаркам.
Учтите не только производительность, но и стоимость эксплуатации.
Как считаете, RAG еще решает свои задачи — или технология уже начинает устаревать? Давайте обсудим в комментариях.
