Как выбрать векторную базу для RAG

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

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

Правило выбора в четырёх вопросах

Четыре вопроса отсекают большую часть вариантов до всякого сравнения.

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

Критерии: что сравнивать и о чём спросить

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

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

Сравнение вариантов: pgvector, Qdrant, Weaviate, облачные сервисы

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

Существуют и другие варианты: библиотеки вроде FAISS (это не база данных, а набор алгоритмов поиска), встраиваемые хранилища для быстрых прототипов. Для рабочей системы с правами и обновлениями их обычно не берут, но для эксперимента на ноутбуке они удобны.

Права доступа: фильтровать до поиска или после

Это самый частый источник тихих ошибок. Допустим, сотрудник видит только документы своего отдела. Есть два способа применить это ограничение.

• Фильтр после поиска. Система находит десять ближайших фрагментов по всему индексу, затем выбрасывает те, что сотрудник видеть не вправе. Остаётся два-три, и ответ бедный, а если все десять чужие, система скажет «не нашла», хотя нужный документ есть. Чужие фрагменты при этом побывали в памяти приложения и могут попасть в журнал.
• Фильтр вместе с поиском. Условие по отделу или уровню доступа входит в сам запрос к базе, и ближайшие фрагменты ищутся только среди разрешённых. Ответ полный, чужое не обрабатывается.

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

Приёмка прав — отдельный прогон: из-под каждой роли просим закрытый документ прямым вопросом, переформулировкой и вопросом, который пересказывает его косвенно. Для SaaS с отдельными индексами клиентов к этому добавляется тест изоляции, описанный в статье «Мультиарендность в SaaS».

Сколько места и памяти понадобится: расчёт порядка

Не нужно искать чужие цифры. Порядок объёма вы посчитаете сами.

1. Оцените число фрагментов: общий объём текста, делённый на средний размер фрагмента. Один документ даёт от нескольких до многих десятков фрагментов, в зависимости от разбиения.
2. Умножьте на размерность вектора вашей модели эмбеддингов и на размер одного числа (обычно четыре байта, если не сжимать). Получится объём сырых векторов.
3. Прибавьте индекс для быстрого поиска: он занимает дополнительную память, а его размер зависит от настроек.
4. Прибавьте тексты и метаданные фрагментов, которые хранятся рядом.
5. Умножьте на запас для роста и для пересборки индекса, при которой старый и новый существуют одновременно.

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

Как проверить выбор на своих данных за неделю

Не нужно строить всю систему, чтобы сравнить два хранилища. Нужны данные, вопросы и пять простых замеров.

1. Соберите образец. Репрезентативная часть ваших документов, обработанная одним и тем же разбиением и одной моделью эмбеддингов для всех кандидатов.
2. Возьмите двадцать-тридцать реальных вопросов с известными документами-ответами, включая несколько вопросов с артикулами и номерами, и несколько вопросов без ответа.
3. Сравните полноту поиска. Для каждого вопроса: нужный фрагмент попал в число найденных или нет. Сравнивайте кандидатов по одним и тем же вопросам.
4. Измерьте скорость с фильтром. Ваш самый строгий фильтр прав, а не поиск без условий. Смотрите и на типичный, и на худший по времени запрос.
5. Проверьте жизненный цикл. Замените документ новой редакцией, удалите документ, остановите базу и восстановите из копии. Запишите, сколько это заняло и что пришлось делать руками.

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

Как не привязаться к одной базе

Решение, принятое сегодня, может поменяться через год: вырастет объём, изменится политика размещения, выйдет новая версия. Заранее сделайте четыре вещи, и смена обойдётся дешевле.

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

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

Ошибки, из-за которых выбор оказывается неудачным

• Выбирают по рекламе и обзорам. Скорость на чужих данных ничего не говорит о ваших фильтрах и вашем объёме.
• Начинают с самой тяжёлой архитектуры «на вырост». Кластер из нескольких узлов для коллекции, которая помещается в память одной машины, добавляет эксплуатацию, но не качество.
• Не проверяют фильтры. Поиск без условия быстр, а с условием по правам медленнее или возвращает пустой результат.
• Меняют модель эмбеддингов, не пересобрав индекс. Векторы от разных моделей несравнимы, и поиск начинает работать случайно.
• Считают, что база решит задачу качества. Если документы разобраны плохо, никакая база не вернёт из них точный ответ.
• Размещают индекс у внешнего провайдера, не оценив данные. Индекс содержит смысловое представление текстов, и для данных ограниченного доступа это решение должно быть осознанным.

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за один набор источников и сценарий, 350 000 ₽ и 3–4 недели при нескольких системах и ролях. На выходе документ с выбором хранилища и причинами выбора, правилами разбиения, схемой прав, эталонной выборкой и вилкой бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.

Дальше лёгкий пилот (150 000–400 000 ₽, 2–8 недель) или тяжёлый (400 000–1 200 000 ₽, 2–3 месяца), затем вывод в эксплуатацию этапами, и на любой ступени можно остановиться. Мы берём один контур, а не внедрение по всей компании, и не дежурим круглосуточно. Исходный код и индексы остаются в вашем контуре, репозиторий ваш с первого коммита. Цены и сроки — на странице «Тарифы», описание услуги — на странице «RAG-система на заказ». Если вам нужен готовый ассистент для сотрудников, а не разработка, смотрите ИИ-ассистента по документам.